EFD-Reinf

Manual de Orientao do Desenvolvedor

Verso 1.1
Julho de 2017
ndice
1. INTRODUO..............................................................................................................4
2. CONSIDERAES INICIAIS.......................................................................................4
2.1. OBJETIVOS DO PROJETO..........................................................................................4
2.2. VISO GERAL..........................................................................................................4
2.3. LEGISLAO............................................................................................................5
2.4. PESSOAS OBRIGADAS A DECLARAR........................................................................5
2.5. PRAZOS DE ENTREGA..............................................................................................6
2.6. PROCEDIMENTOS DE CONTINGNCIA INDISPONIBILIDADE DOS SERVIDORES........7
3. DEFINIES GERAIS SOBRE EVENTOS.................................................................7
3.1. ASSINATURA............................................................................................................7
3.2. LOTES DE EVENTOS.................................................................................................8
3.3. VALIDAO DO CERTIFICADO DIGITAL...................................................................8
3.4. NVEIS DE VALIDAO DOS EVENTOS....................................................................9
3.5. RECIBO E PROTOCOLO DE RECEBIMENTO DOS EVENTOS......................................10
3.6. VERSIONAMENTO DOS LEIAUTES DOS EVENTOS....................................................10
4. PADRES TCNICOS................................................................................................11
4.1. PADRO DE DOCUMENTO XML............................................................................11
4.2. DECLARAO NAMESPACE....................................................................................12
4.3. SCHEMA XML.......................................................................................................13
4.4. PADRO DE COMUNICAO..................................................................................14
4.5. PADRO DE CERTIFICADO DIGITAL........................................................................15
4.6. PADRO DE ASSINATURA DIGITAL.........................................................................17
4.7. PROCESSO DE VALIDAO DE ASSINATURA DIGITAL.............................................19
4.8. RESUMO DOS PADRES TCNICOS.........................................................................21
5. WEBSERVICES...........................................................................................................22
5.1. PADRO DE MENSAGENS DOS WEBSERVICES.......................................................22
5.2. VALIDAO DA ESTRUTURA DA MENSAGEM NO WEBSERVICE............................23
5.3. WEBSERVICE DE ENVIO DE LOTE DE EVENTOS.....................................................24
a) Dados para a chamada ao Webservice de Envio de Lote de Eventos..................24
b) Fluxo de Envio de Lote de Eventos......................................................................25
c) Leiaute Mensagem de Entrada.............................................................................27
d) Leiaute Mensagem de Retorno do Envio do Lote.................................................29
e) Validaes aplicadas na Recepo do Lote..........................................................33
5.4. WEBSERVICE DE CONSULTA DO EVENTO DE TOTALIZADOR..................................35
a) Dados para a chamada ao Webservice de Consulta do Evento de Totalizador...35
b) Fluxo de Envio de Lote de Eventos......................................................................35
c) Leiaute da Mensagem de Entrada........................................................................35
d) Leiaute da Mensagem de Retorno........................................................................36
e) Retorno dos Totalizadores....................................................................................36
6. ARQUITETURA DE COMUNICAO.....................................................................36
6.1. MODELO OPERACIONAL.........................................................................................36
6.2. ETAPAS DO PROCESSO IDEAL.................................................................................37
7. EVENTOS....................................................................................................................38
7.1. ESTRUTURA DO EVENTO........................................................................................39

2
 7.2. IDENTIFICAO DO EVENTO..................................................................................43
7.3. ASSINATURA DO EVENTO.......................................................................................44
7.4. ESTRUTURA DO RETORNO DE PROCESSAMENTO DO EVENTO................................44
8. RECOMENDAES E BOAS PRTICAS................................................................44
8.1. RESPEITAR A ORDEM DE PRECEDNCIA NO ENVIO DOS EVENTOS EM LOTES.........44
8.2. EVITAR O ENVIO DE EVENTOS DURANTE O PROCESSAMENTO DO EVENTO DE
FECHAMENTO.....................................................................................................................45
8.3. OTIMIZAO NA MONTAGEM DO ARQUIVO...........................................................45
8.4. VALIDAO DE SCHEMA.......................................................................................46
9. ORIENTAES PARA UTILIZAO DO AMBIENTE DE PRODUO
RESTRITA............................................................................................................................46
9.1. SOBRE A PRODUO RESTRITA.............................................................................46
9.2. EVENTOS................................................................................................................47
9.3. RESTRIES...........................................................................................................48
9.4. TEMPO DE GUARDA DOS DADOS............................................................................48
9.5. VALIDAES..........................................................................................................49
9.6. REGRA PARA IDENTIFICAO DO AMBIENTE.........................................................50
9.7. URL DOS WEB SERVICES......................................................................................50
9.8. Da data de disponibilizao do ambiente..............................................................50

3
1. Introduo

Este documento tem por objetivo definir critrios e especificaes tcnicas

necessrios para a integrao entre o Sistema dos empregadores, pessoas fsicas e/ou
jurdicas, e o Sistema EFD-REINF.

2. Consideraes Iniciais

2.1. Objetivos do Projeto

A EFD-Reinf abarca todas as retenes do contribuinte sem relao com o trabalho,

bem como as informaes sobre a receita bruta para a apurao das contribuies
previdencirias substitudas. A nova escriturao substituir as informaes contidas em
outras obrigaes acessrias, tais como o mdulo da EFD-Contribuies que apura a
Contribuio Previdenciria sobre a Receita Bruta (CPRB), dentre outras.

2.2. Viso Geral

A Escriturao Fiscal Digital de Retenes e Outras Informaes Fiscais (EFD-

Reinf) uma obrigao acessria que rene diversas informaes relativas a escrituraes
de retenes e outras informaes fiscais de interesse da Secretaria da Receita Federal do
Brasil (RFB). A obrigao constituda por um conjunto de arquivos a serem entregues em
leiautes especficos, por meio do ambiente do Sistema Pblico de Escriturao Digital
(Sped), utilizando certificado digital vlido, emitido por entidade credenciada pela
Infraestrutura de Chaves Pblicas Brasileira (ICP-Brasil) e ser considerada vlida aps a
confirmao de recebimento e validao do contedo dos arquivos que a contm.

Os arquivos devero estar assinados digitalmente pelo representante legal da

entidade declarante ou procurador constitudo nos termos da Instruo Normativa (IN) RFB
n 1701 de 14 de maro de 2017.

4
 Nos casos de procurao eletrnica, o declarante dever habilitar poderes
especficos para esta obrigao acessria, no portal do e-CAC, conforme orientaes
descritas no item Error: Reference source not found - Error: Reference source not found
deste manual.

2.3. Legislao

A EFD-Reinf foi instituda pela IN RFB n 1701 de 14 de maro de 2017, tendo em

vista o disposto no art. 16 da Lei n 9.779, de 19 de janeiro de 1999, e no Decreto n 6.022,
de 22 de janeiro de 2007.

2.4. Pessoas Obrigadas a Declarar

EFD-Reinf dever ser entregue por:

Pessoas jurdicas que prestam e que contratam servios realizados mediante cesso
de mo de obra;

Pessoas jurdicas responsveis pela reteno da Contribuio para o PIS/Pasep, da

Contribuio para o Financiamento da Seguridade Social (Cofins) e da Contribuio
Social sobre o Lucro Lquido (CSLL);

Pessoas jurdicas optantes pelo recolhimento da Contribuio Previdenciria sobre a

Receita Bruta (CPRB);

Produtor rural pessoa jurdica e agroindstria quando sujeitos a contribuio

previdenciria substitutiva sobre a receita bruta proveniente da comercializao da
produo rural;

Associaes desportivas que mantenham equipe de futebol profissional que tenham

recebido valores a ttulo de patrocnio, licenciamento de uso de marcas e smbolos,
publicidade, propaganda e transmisso de espetculos desportivos;

5
 Empresa ou entidade patrocinadora que tenha destinado recursos a associao
desportiva que mantenha equipe de futebol profissional a ttulo de patrocnio,
licenciamento de uso de marcas e smbolos, publicidade, propaganda e transmisso
de espetculos desportivos;

Entidades promotoras de eventos desportivos realizados em territrio nacional, em

qualquer modalidade desportiva, dos quais participe ao menos 1 (uma) associao
desportiva que mantenha equipe de futebol profissional;

Pessoas jurdicas e fsicas que pagaram ou creditaram rendimentos sobre os quais

haja reteno do Imposto sobre a Renda Retido na Fonte (IRRF), por si ou como
representantes de terceiros.

2.5. Prazos de Entrega

Conforme a IN RFB n 1701, de 14 de maro de 2017. A EFD-Reinf dever ser

transmitida:

A partir de 1 de janeiro de 2018, caso o faturamento da pessoa jurdica no ano de

2016 tenha sido superior a R$ 78.000.000,00 (setenta e oito milhes de reais) ou;

A partir de 1 de julho de 2018, caso o faturamento da pessoa jurdica no ano de

2016 tenha sido de at R$ 78.000.000,00 (setenta e oito milhes de reais).

Em Ato especfico do Comit Gestor do Simples Nacional estabelecer condies

especiais para cumprimento do disposto neste artigo, a serem observadas pela pessoa
jurdica optante pelo Regime Especial Unificado de Arrecadao de Tributos e
Contribuies devidos pelas Microempresas e Empresas de Pequeno Porte (Simples
Nacional), institudo pela Lei Complementar n 123, de 14 de dezembro de 2006.

A EFD-Reinf ser transmitida mensalmente at o dia 20 do ms subsequente ao que

se refira a escriturao, observado o disposto no pargrafo nico deste artigo.

6
 As entidades promotoras de espetculos desportivos a que se refere o inciso VII do
art. 2 devero transmitir ao Sped as informaes relacionadas ao evento no prazo de at 02
(dois) dias teis aps a sua realizao.

2.6. Procedimentos de contingncia Indisponibilidade dos servidores

O procedimento de contingncia para a indisponibilidade dos Webservices de

recepo ser o Portal Web da EFD-REINF . Entretanto nas etapas iniciais de implantao
da EFD-REINF esse portal ainda no estar disponvel para uso.

3. Definies Gerais sobre Eventos

3.1. Assinatura

Para enviar informaes para a EFD-REINF o contribuinte dever gerar eventos em

arquivos eletrnicos denominados eventos. Os eventos devero ser assinados digitalmente,
transformando este arquivo em um documento eletrnico nos termos da legislao
brasileira, de maneira a garantir a integridade dos dados e a autoria do emissor.

Os eventos devero ser assinados digitalmente utilizando o e-CNPJ do contribuinte

ou o e-CPF de seu representante legal ou procurador.

No caso de procurador, a procurao eletrnica para a pessoa fsica dever ser

cadastrada no portal do e-CAC
(https://cav.receita.fazenda.gov.br/eCAC/publico/login.aspx), utilizando o acesso via
certificado digital e indicando, especificamente, poderes referentes ao Reinf, conforme
exemplificado na figura abaixo:

7
3.2. Lotes de Eventos

Os eventos devero ser transmitidos pela Internet para o Ambiente Nacional em

agrupamentos denominados lote de eventos. Lotes so arquivos eletrnicos que encapsulam
um conjunto de eventos. A quantidade mxima de eventos permitidos por lote para envio
para a EFD-REINF de 100 (cem) eventos.

No Ambiente Nacional, os eventos sero extrados dos lotes, e submetidos a

validaes quanto ao contedo e quanto aos outros eventos recebidos anteriormente,
garantindo a qualidade da informao.

3.3. Validao do Certificado Digital

Os certificados digitais podem ser utilizados tanto nas conexes TLS de transmisso
dos lotes de eventos para a EFD-REINF, quanto para a assinatura dos eventos. Neste caso,

8
os efeitos da validao podem se dar para todo o lote (no caso do erro ser gerado a partir do
certificado de transmisso) como para um evento especfico (no caso do erro ser gerado a
partir de uma assinatura de um documento XML, enviado EFD-REINF, que representa o
evento).

Os Certificados Digitais utilizados no acesso aos servios disponibilizados pelo

sistema EFD-REINF e na assinatura dos arquivos XML enviados a ele devero atender aos
critrios estabelecidos na seo Error: Reference source not found - Error: Reference source
not found.

3.4. Nveis de Validao dos Eventos

Os arquivos enviados para a EFD-REINF sero validados em 3 etapas, conforme

descrito abaixo:

Validao do lote: Ser executada no momento da recepo do lote de eventos,

quando sero verificados, inicialmente, o certificado da conexo, a estrutura e
verso do lote. Caso ocorra erro na validao do lote este no ser recebido, o
arquivo ser recusado e no sero realizadas as demais validaes, descritas abaixo.
Caso contrrio, para cada evento contido no lote sero feitas as seguintes validaes
(validao dos eventos contidos no lote):

Validao de estrutura: Validao do evento em relao estrutura do arquivo, de

acordo com o tipo de evento. Caso ocorra erro na validao de estrutura, o evento
no ser recebido e no sero realizadas as demais validaes do evento.

Validao de contedo: Validaes dos valores informados no evento. Caso seja

detectada alguma inconsistncia, o evento no ser recebido. As validaes
realizadas e a lista das mensagens retornadas pode ser encontrada no portal do Sped
na internet, em http://sped.rfb.gov.br.

9
3.5. Recibo e Protocolo de Recebimento dos Eventos

Para cada evento contido em um determinado lote e que for processado com sucesso
a EFD-REINF retornar o respectivo nmero de recibo ou um Protocolo de Recebimento,
conforme detalhado na seo Error: Reference source not found - Error: Reference source
not found.

3.6. Versionamento dos leiautes dos eventos

O versionamento dos leiautes dos eventos ser por tipo de evento. Assim, a
alterao do leiaute de um determinado tipo de evento no afeta a verso dos demais tipos
de eventos.

Os leiautes vlidos em um determinado perodo sero empacotados e distribudos

atravs dos "Pacotes de liberao". Cada pacote de liberao tem os leiautes dos tipo de
eventos suportados pela EFD-REINF com as suas respectivas verses.

Seguem abaixo os princpios que sero considerados no versionamento dos leiautes:

O leiaute do tipo de evento compreende apenas a sua estrutura. Assim um

mesmo leiaute pode ter diferente conjunto de regras e valores vlidos durante o
seu perodo de vigncia. A alterao dos valores vlidos ou do conjunto de
regras de um leiaute, sem alterao de sua estrutura, ser realizada atravs da
atualizao desse manual, ou seja, no haver alterao da verso do leiaute.

Para cada tipo de evento haver apenas uma verso de leiaute vigente em um
determinado perodo.

Cada XSD identificado por um nico Namespace e cada XSD representa

apenas um leiaute.

10
 O Sistema EFD-REINF identificar a verso do leiaute do evento atravs do
namespace do Xml do evento.

Padro de identificao da verso de Leiaute ser X.Y e do Schema XML -

XSD X_Y_Z

Onde:

X -> utilizado para representar mudanas muito significativas (Reestruturao do

evento)

Y -> utilizado para representar mudanas estruturais comuns (Incluso/excluso de

campos, dente outras).

Z -> utilizados para corrigir erros em XSD publicados e, possivelmente, j

utilizados. Neste caso haver uma substituio do "Pacote de liberao" do referido
perodo.

Obs: A necessidade de alterao da verso do leiaute de um determinado tipo de

evento, sem a alterao da sua estrutura, o que representa uma exceo, implicar a
criao de um novo XSD. Assim, no haver qualquer modificao estrutural no XSD,
apenas o namespace ser modificado para acompanhar a nova verso do leiaute.

4. Padres Tcnicos

4.1. Padro de Documento XML

A especificao do documento XML adotada a recomendao W3C para XML

1.0, disponvel em http://www.w3.org/TR/REC-xml.

A codificao dos caracteres ser em UTF-8, assim todos os documentos XML

sero iniciados com a seguinte declarao:

11
 <?xml version="1.0" encoding="UTF-8"?>

Um arquivo XML poder ter uma nica declarao <?xml version="1.0"

encoding="UTF-8"?>. Mesmo nas situaes em que um documento XML contenha outros
documentos XML, como ocorre no documento de Lotes de Eventos, deve-se atentar para
que exista uma nica declarao no incio do documento.

Os caracteres especiais abaixo quando forem inseridos como dado de contedo

devero ser substitudos pelos seus respectivos caracteres de escape conforme detalhado a
seguir:

Caractere Escape

> (sinal de maior) &gt;

< (sinal de menor) &lt;

& (e comercial) &amp;

Demais caracteres especiais no so aceitos como informao relativa a contedo.

4.2. Declarao namespace

Cada evento XML dever ter uma nica declarao de namespace no elemento raiz
do documento, conforme tipo do evento, com o seguinte padro:

<REINF xmlns="http://www.reinf.esocial.gov.br/schemas/NOME_DO_EVENTO/v1_01_01" >

O trecho NOME_DO_EVENTO deve ser substitudo pelo nome do evento

enviado, conforme o leiaute vigente para a EFD-REINF1. No permitido o uso de
declarao de namespace diferente do padro estabelecido. O trecho referente verso do

12
leiaute (v1_01_01) deve ser atualizada sempre que necessrio, quando houver atualizaes
do Schema .xsd.

A declarao do namespace da assinatura digital dever ser realizada na prpria tag

<Signature>, conforme exemplo abaixo:

<Reinf xmlns="http://www.reinf.esocial.gov.br/schemas/NOME_DO_EVENTO/v1_01_01">

<!-- Xml do Evento -->

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<.../>

</Signature>

</Reinf>

1
Essa considerao tambm valida para exemplos apresentados em sees mais
adiante nesse manual.

4.3. Schema XML

A estrutura dos XML recebidos pela EFD-REINF especificada e checada por

um Schema, que uma linguagem que define a estrutura do documento XML, descrevendo
os seus elementos e a sua organizao, alm de estabelecer regras de preenchimento de
contedo e de obrigatoriedade de cada elemento ou grupo de informao. Este Schema
XML representado, fisicamente, por um arquivo de extenso XSD.

A validao da estrutura XML da mensagem realizada por um analisador sinttico

(parser) que verifica se a mensagem atende as definies e regras de seu Schema XML.
Qualquer divergncia da estrutura XML da mensagem em relao ao seu Schema XML
provoca um erro de validao.

13
4.4. Padro de Comunicao

A comunicao ser baseada em Webservices, disponibilizados pelo sistema EFD-

REINF.

O meio fsico de comunicao utilizado ser a Internet, com o uso do protocolo

HTTPS (TLS 1.1 ou 1.2), com autenticao mtua, que alm de garantir um duto de
comunicao seguro na Internet, permite a identificao do servidor e do cliente atravs de
certificados digitais.

Caso seja necessrio transmitir vrios eventos em sequncia sugere-se a utilizao

de conexo HTTPS persistente, conforme estabelecido na verso 1.1 do protocolo HTTP,
evitando assim fechar e reestabelecer a conexo HTTPS para cada evento enviado.

O modelo de comunicao segue o padro de Webservices definido pelo WS-I Basic

Profile.

A troca de mensagens entre os Webservices do ambiente do sistema EFD-REINF e

os aplicativos dos contribuintes ser realizada no padro SOAP verso 1.1, com troca de
mensagens XML no padro Style/Enconding: Document/Literal.

Exemplo de uma mensagem SOAP:

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header></soap:Header>

<soap:Body>CORPO DA MENSAGEM SOAP</soap:Body>

</soap:Envelope>

14
4.5. Padro de certificado digital

O certificado digital utilizado no sistema EFD-REINF dever ser emitido por

Autoridade Certificadora credenciada pela Infraestrutura de Chaves Pblicas Brasileira
ICP-Brasil.

Este dever pertencer srie A. Existem duas sries as quais os certificados podem
pertencer, a srie A e a S. A srie A rene os certificados de assinatura digital utilizados na
confirmao de identidade na Web, em e-mails, em redes privadas virtuais (VPN) e em
documentos eletrnicos com verificao da integridade de suas informaes. A srie S
rene os certificados de sigilo que so utilizados na codificao de documentos, de bases de
dados, de mensagens e de outras informaes eletrnicas sigilosas.

O certificado digital dever ser do tipo A1 ou A3. Certificados digitais de tipo A1

ficam armazenados no prprio computador a partir do qual ele ser utilizado. Certificados
digitais do tipo A3 so armazenados em dispositivo porttil inviolvel 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 operao realizada pelo chip existente no
dispositivo, sem qualquer acesso externo chave privada do certificado digital.

Para que um certificado seja aceito na funo de transmissor de solicitaes este

dever ser do tipo e-CPF (e-PF) ou e-CNPJ (e-PJ).

A recomendao de uso que o tamanho mximo da chave pblica do certificado

seja de 2048 bits, o que fornece um nvel adequado de segurana sem comprometer a
performance das aplicaes.

Os certificados digitais sero exigidos em dois momentos distintos:

1. Transmisso: antes de ser iniciada a transmisso de solicitaes ao sistema EFD-

REINF, o certificado digital do solicitante utilizado para reconhecer o transmissor
e garantir a segurana do trfego das informaes na INTERNET.

15
 2. Assinatura de documentos: para garantir o no repdio e a integridade das
informaes os documentos eletrnicos enviados para a EFD-REINF so assinados
digitalmente seguindo a especificao descrita em 4.6 - Padro de assinatura digital
e as orientaes estabelecidas neste Manual.

Os certificados digitais devem ser utilizados tanto nas conexes SSL/TLS de

transmisso dos lotes de eventos para a EFD-REINF, quanto para a assinatura dos eventos.
No caso de problemas com o certificado utilizado para a transmisso todo o lote de eventos
poder no ser preenchido, independentemente do certificado utilizado para a assinatura
dos eventos especficos estiver correto.

Os certificados digitais utilizados no acesso aos servios disponibilizados pelo

sistema e na assinatura dos arquivos XML enviados devero atender aos seguintes critrios:

Critrio Mensagem Efeito

A formao da cadeia de MS0003 Rejeio do lote ou do evento.

certificao at sua raiz deve
ser confivel.

A raiz da cadeia dever MS0004 Rejeio do lote ou do evento.

pertencer a Autoridade
Certificadora Raiz Brasileira
(ICP-Brasil).

O certificado no poder MS0005 Rejeio do lote ou do evento.

estar revogado.

O certificado no poder MS0006 Rejeio do lote ou do evento.

estar expirado na data da
verificao.

16
O certificado dever ser do MS0007 Rejeio do lote ou do evento.
tipo e-CNPJ, e-PJ, e-CPF ou
e-PF.

Deve ser utilizado certificado MS0013 Rejeio do lote ou do evento.

digital para transmisso dos
eventos.

O certificado digital deve ser MS0015 Rejeio do lote ou do evento.

do tipo e-CNPJ ou e-PJ cujo
CNPJ base seja o mesmo do
contribuinte responsvel pela
informao, ou do tipo e-
CPF ou e-PF cujo CPF
pertena ao representante
legal do contribuinte ou
qualquer certificado que
pertena a um procurador
devidamente habilitado no
sistema de Procurao
Eletrnica da RFB.

4.6. Padro de assinatura digital

O sistema EFD-REINF utiliza um subconjunto do padro de assinatura XML

definido pelo http://www.w3.org/TR/xmldsig-core/.

1. Padro de assinatura: XML Digital Signature, utilizando o formato Enveloped

(http://www.w3.org/TR/xmldsig-core/)

17
 2. Certificado digital: emitido por AC credenciada no ICP-Brasil
(http://www.w3.org/2000/09/xmldsig#X509Data)

3. Cadeia de certificao: EndCertOnly (Incluir na assinatura apenas o certificado do

usurio final)

3.1. Tipo do certificado: A1 ou A3

4. Tamanho da chave criptogrfica: compatvel com os certificados A1 e A3

5. Funo criptogrfica assimtrica: RSA (http://www.w3.org/2001/04/xmldsig-

more#rsa-sha256)

6. Funo de message digest: SHA-256.

(http://www.w3.org/2001/04/xmlenc#sha256)

7. Codificao: Base64 (http://www.w3.org/2000/09/xmldsig#base64)

8. Transformaes exigidas: til para realizar a canonicalizao do XML enviado

para realizar a validao correta da assinatura digital. So elas:

8.1. Enveloped (http://www.w3.org/2000/09/xmldsig#enveloped-signature)

8.2. C14N (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)

As informaes necessrias a identificao do assinante esto presentes dentro do

certificado digital, tornando desnecessria a sua representao individualizada no arquivo
XML. Portanto, o arquivo XML assinado deve conter apenas a tag X509Certificate nas
informaes que dizem respeito ao certificado.

Abaixo temos um exemplo de um evento assinado digitalmente:

<?xml version="1.0" encoding="UTF-8"?>

18
<Reinf xmlns="http://www.reinf.esocial.gov.br/schemas/NOME_DO_EVENTO/v01_01_01">
<!-- Xml do Evento -->
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-
c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-
more#rsa-sha256"/>
<Reference URI="">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature "/>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-
20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2001/04/xmlenc#sha256 "/>
<DigestValue>fLTJL1BLGP9giKdsEGP9xSVyeWBlPzkvyy78GtbsC9I=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</Reinf>

4.7. Processo de validao de assinatura digital

O Procedimento de validao da assinatura digital adotado pelo sistema EFD-

REINF :

1) extrair a chave pblica do certificado;

2) verificar o prazo de validade do certificado utilizado;

3) montar e validar a cadeia de confiana dos certificados validando tambm a LCR

(Lista de Certificados Revogados) de cada certificado da cadeia;

19
4) validar o uso da chave utilizada (assinatura digital) de forma a aceitar certificados
somente do tipo A (no sero aceitos certificados do tipo S);

5) garantir que o certificado utilizado de um usurio final e no de uma autoridade

certificadora;

6) adotar as regras definidas pelo RFC 3280 para as LCR e cadeia de confiana;

7) validar a integridade de todas as LCR utilizadas pelo sistema;

8) validar datas inicial e final do prazo de validade de cada LCR utilizada.

20
 4.8. Resumo dos padres tcnicos

A tabela a seguir resume os principais padres de tecnologia utilizados:

Caracterstica Descrio

Padro definido pelo WS-I Basic Profile 1.1 (http://www.ws-

Webservices i.org/Profiles/BasicProfile-1.1-2004-08-24.html)

Meio lgico de
Webservice (s) disponibilizado (s) pelo sistema EFD-REINF.
comunicao

Meio fsico de
INTERNET
comunicao

HTTPS (TLS 1.1 ou 1.2 com criptografia AES), com autenticao

Protocolo Internet mtua atravs de certificados digitais.

Padro de troca de
SOAP verso 1.1
mensagens

Padro da mensagem XML no padro Style/Encoding: Document/Literal

X.509 verso 3, emitido por Autoridade Certificadora credenciada

pela Infraestrutura de Chaves Pblicas Brasileira ICP-Brasil, do
Padro de certificado tipo A1 ou A3, devendo ser um e-CPF (e-PF) ou e-CNPJ (e-PJ).
digital
Para transmisso, utilizar o certificado digital do responsvel pela
transmisso.

21
 XML Digital Signature, Enveloped, com certificado digital X.509
verso 3, com chave privada de tamanho varivel, conforme o
Padro de assinatura
padro da ICP-Brasil, com padres de criptografia assimtrica RSA,
digital
algoritmo message digest SHA-256 e utilizao das transformaes
Enveloped e C14N.

Validao de assinatura Ser validada alm da integridade e autoria, a cadeia de confiana

digital com a validao das LCR.

Campos no obrigatrios do Schema que no possuam contedo

tero suas tags suprimidas no arquivo XML.

Nos campos numricos inteiros, no incluir vrgula ou ponto

Padres de
decimal.
preenchimento XML

Nos campos numricos com casas decimais, utilizar a vrgula na

separao das casas decimais, observando a definio do leiaute
especfico do evento a ser enviado.

5. Webservices

5.1. Padro de Mensagens dos Webservices

Os mtodos de solicitao de processamento e de consultas dos Webservices do

sistema EFD-REINF foram projetados para receber mensagens no padro XML como
parmetro de entrada dos mtodos, assim como retornar mensagens no padro XML.

Os Schemas que definem os XML recebidos pelo sistema EFD-REINF sero

disponibilizados no stio http://sped.rfb.gov.br/.

Haver dois pacotes de Schemas:

22
 Comunicao: contm os Schemas envolvidos no processo de comunicao com a
EFD-REINF (Schema do Envio Lote de Eventos, Schema do Retorno do
Evento, Schema do Retorno de Processamento de Lotes). Os Schemas deste
pacote esto descritos nas sees 5.3 - Webservice de Envio de Lote de Eventos
e Error: Reference source not found - Error: Reference source not found.

Eventos: contm os Schemas dos eventos de negcio previstos para a EFD-

REINF.

5.2. Validao da Estrutura da Mensagem no Webservice

Os Webservices disponibilizados pelo sistema EFD-REINF, possuem como

entrada de dados mensagens utilizando a linguagem de marcao XML, as quais so
validadas com os Schemas que as define, e rejeitadas caso seja encontrada alguma
inconsistncia.

Assim, os aplicativos que fazem solicitaes ao sistema EFD-REINF devem estar

preparados para gerar lotes de eventos no formato definido pelo XSD em vigor.

As alteraes da estrutura de dados XML realizadas nas mensagens so controladas

atravs da verso definida no namespace do Schema. A identificao da verso dos
Schemas ser realizada com o acrscimo do nmero da verso como sufixo no namespace
do XML e no nome do arquivo, conforme o exemplo abaixo:

Namespace:

http://www.reinf.esocial.gov.br/schemas/envioLoteEventos/v1_01_01

Nome arquivo:

envioLoteEventos-v1_01_01.xsd (Schema XML para o lote de eventos, verso

1.01.01)

23
 As modificaes de leiaute das mensagens do Webservice podem ser causadas por
necessidades tcnicas ou em razo da modificao de alguma legislao. As modificaes
decorrentes de alterao da legislao devero ser implementadas nos prazos previstos no
ato normativo que introduziu a alterao. As modificaes de ordem tcnica sero
divulgadas pela e podero ocorrer sempre que se fizerem necessrias.

5.3. Webservice de Envio de Lote de Eventos

A funo deste Webservice receber um lote de eventos, valid-lo e retornar o

Protocolo de Envio, que dever ser armazenado pelo empregador para, em outro momento,
consultar o resultado do processamento do lote.

Neste Webservice sero as executadas as validaes de nvel 1, conforme descrito

na seo Error: Reference source not found - Error: Reference source not found

Cada evento enviado, atravs do lote de eventos, deve ser assinado individualmente
dentro do lote.

a) Dados para a chamada ao Webservice de Envio de Lote de Eventos

Nome do mtodo ReceberLoteEventos

Assinatura Xml: ReceberLoteEventos (xml: loteEventos)

Sim.

Observao: O certificado deve atender a uma das

seguintes exigncias:

Requer Certificado de Cliente? Ser o responsvel pela informao.

Ser representante legal do responsvel pela

informao.

Ser procurador do responsvel pela informao.

24
Schema Parmetro loteEventos envioLoteEventos-v1_01_01.xsd

Schema Retorno retornoLoteEventos-v1_01_01.xsd

https://reinf.receita.fazenda.gov.br/WsREINF/Recepcao
URL
LoteReinf.svc

b) Fluxo de Envio de Lote de Eventos

Abaixo descrito detalhadamente o processo de envio de lote de eventos:

25
 c) Leiaute Mensagem de Entrada

A mensagem de entrada definida pelo Schema EnvioLoteEventos-v1_01_01.xsd,

cuja estrutura apresentada abaixo:

tag: REINF

descrio: Tag raiz do documento

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

xmlns obrigatrio 1 Namespace do XSD do

http://www.reinf.esocial.go
do envio de lote de
v.br/schemas/envioLoteEv
eventos.
entos/v1_01_01

tag: loteEventos

descrio: Contm a relao de eventos que compe o lote.

obrigatrio? Sim

ocorrncia nica

26
tag: evento

descrio:
Contm cada evento individual que ser processado pela EFD-REINF.
obrigatrio? Sim

ocorrncia 1..100

campo obrigatoriedade ocorrncia valores vlidos descrio

obrigatrio 1 - Define os campos de um evento

TArquivoeReinf conforme seu tipo.

Informaes complementares
podem ser obtidas atravs do
XSD correspondente.
campo obrigatoriedade ocorrncia valores vlidos descrio

Id obrigatrio 1 - Contm chave de acesso do

evento.

Importante: Esta informao

fundamental para que o prprio
XSD consiga detectar se existe
mais de um evento com mesmo
ID no lote, e caso exista, negue
sua recepo.
Observaes:

O contedo do campo evento deve ser o XML do evento a ser enviado para processamento na
EFD-Reinf. Este campo pode ser repetido at 100 vezes, isto quer dizer que o lote de eventos
pode ser composto no mximo por 100 eventos. Existem diferentes estruturas XML e leiautes
para a representao dos eventos recebidos pela EFD-Reinf.

d) Leiaute Mensagem de Retorno do Envio do Lote

A mensagem de retorno definida pelo Schema RetornoLoteEventos-v1_01_01.xsd,

cuja estrutura apresentada abaixo:

27
tag: REINF

descrio: Tag raiz do documento

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

xmlns obrigatrio 1 http://www.reinf.esocial.go Namespace do XSD do

v.br/schemas/retornoLoteE retorno do envio de lote
ventos/v1_01_01 de eventos.

28
tag: retornoLoteEventos

descrio: Contm o resultado da operao de recepo de um lote de eventos.

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

id obrigatrio 1 -
Contm o identificador do
retorno do lote.
Informao utilizada
apenas pelo mecanismo
de assinatura XML.

tag: ideTransmissor

descrio: Contm a identificao do transmissor.

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

idTransmissor obrigatrio 1 -
Contm a identificao do
transmissor.

tag: status

descrio: Contm o status atual do lote.

obrigatrio? Sim

ocorrncia nica

tipo obrigatoriedade ocorrncia valores vlidos descrio

TStatus obrigatrio 1 - Tipo que ir definir o

status do lote.

29
campo obrigatoriedade ocorrncia valores vlidos descrio

cdStatus obrigatrio 1 - Cdigo do status da

resposta do
processamento do lote.
-
descRetorno obrigatrio 1 Descrio literal do
status da resposta do
processamento do lote.

dadosRegistroO No obrigatrio 0..N - Tipo

correnciaLote TRegistroOcorrencias
que ir definir as
ocorrncias registradas
para o lote.

tag: ocorrencias

descrio: Contm as ocorrncias registradas para o lote.

obrigatrio? No

ocorrncia 1..N

tipo obrigatoriedade ocorrncia valores vlidos descrio

TregistroOcorre No obrigatrio 0..N - Tipo que define uma

ncias ocorrncia encontrada
no processamento de
um arquivo.
campo obrigatoriedade ocorrncia valores vlidos descrio

1 - Aviso
tipo obrigatrio 1 Contm o tipo da
ocorrncia.
2 - Erro
-
localizacaoErro No obrigatrio 1 Campo onde ocorreu o
Aviso aviso/erro.

codigo obrigatrio 1 - Cdigo do status da

resposta do
processamento do
evento.

descricao obrigatrio 1 Descrio da resposta

do processamento do
evento.

30
tag:
retornoEventos
descrio: Contm o(s) resultado(s) do processamento dos eventos do lote.

obrigatrio? No

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

evento obrigatrio 1...100 - Define os dados de um arquivo

do Reinf (evento).

tag: signature

descrio: Contm a assinatura do sistema do Reinf no retorno do envio de lote de

eventos.

obrigatrio? Sim

ocorrncia nica

e) Validaes aplicadas na Recepo do Lote

As seguintes validaes so aplicadas pela EFD-REINF no processamento do lote

de eventos:

Critrio Mensagem Efeito

Foi identificado um erro na estrutura do lote. 0028 Rejeio do lote

Verso do lote invlida. Deve ser utilizada a verso

0092 Rejeio do lote
mais recente.

Erro na cadeia do certificado digital do signatrio ou do

0003 Rejeio do lote
solicitante da informao.

A raiz do certificado digital do signatrio ou do

solicitante da informao dever pertencer a Autoridade 0004 Rejeio do lote
Certificadora Raiz Brasileira (ICP-Brasil).

31
O certificado digital do signatrio ou do solicitante da
0005 Rejeio do lote
informao encontra-se revogado.

O certificado digital do signatrio ou do solicitante da

0006 Rejeio do lote
informao encontra-se expirado.

O certificado digital do signatrio ou do solicitante da

informao no vlido. Somente sero aceitos os
0007 Rejeio do lote
certificados do tipo e-Aplicao, e-CNPJ, e-PJ, e-CPF
ou e-PF.

Deve ser utilizado certificado digital para transmisso

0013 Rejeio do lote
dos eventos.

Deve ser utilizado certificado digital do tipo e-CNPJ ou

e-PJ cujo CNPJ base seja o mesmo do contribuinte
responsvel pela informao, ou do tipo e-CPF ou e-PF
cujo CPF pertena ao representante legal do 0015 Rejeio do lote
contribuinte ou qualquer certificado que pertena a um
procurador devidamente habilitado no sistema de
Procurao Eletrnica da RFB.

32
 5.4. Webservice de Consulta do evento de Totalizador

a) Dados para a chamada ao Webservice de Consulta do Evento de

Totalizador

Nome do mtodo ConsultaInformacoesConsolidadas

Sim.

Observao: O certificado deve atender a uma das

seguintes exigncias:

Requer Certificado de Cliente? Ser o responsvel pela informao.

Ser representante legal do responsvel pela

informao.

Ser procurador do responsvel pela informao.

Tipo de Inscrio do Contribuinte

Parmetros da Consulta Nmero de Inscrio do Contribuinte

Nmero do Recibo de Fechamento

Schema Retorno retornoTotalizadorContribuinte-v1_01_01.xsd

https://reinf.receita.fazenda.gov.br/WsREINF/
URL
ConsultasReinf.svc

b) Fluxo de Envio de Lote de Eventos

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

c) Leiaute da Mensagem de Entrada

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

33
d) Leiaute da Mensagem de Retorno

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

e) Retorno dos Totalizadores

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

6. Arquitetura de comunicao

6.1. Modelo operacional

O processamento de eventos ser executado atravs de Web Service de forma

sncrona para todos os eventos, exceto para o evento de R-2099. No processamento
sncrono os eventos sero recebidos, processados e recebero o resultado do processamento
do lote em uma mesma conexo.

O processamento do evento R-2099 ser executado de forma assncrona atravs de

dois Webservices. Neste cenrio o processamento dos eventos no acontecer na mesma
conexo, tornando necessria a realizao de uma nova conexo para a obteno do
resultado do processamento.

Ao recepcionar um evento R-2099 no Ambiente Nacional a EFD-REINF retornar

ao transmissor um Protocolo de Envio que posteriormente poder ser usado para consultar
o resultado do processamento do evento de fechamento.

34
6.2. Etapas do processo ideal

Os lotes de eventos enviados pelos contribuintes sero recebidos no ambiente

Nacional do SPED EFD-REINF. Apenas os eventos vlidos so aceitos e armazenados. A
EFD-REINF retornar um arquivo eletrnico contendo uma lista de inconsistncias
encontradas no caso de eventos invlidos.

A seguir so exibidas e descritas as etapas do processo ideal:

35
 1) O aplicativo da instituio declarante inicia a conexo enviando uma mensagem de
solicitao de processamento de lote de eventos para o Web Service de Recepo de
Lote de Eventos;

2) O Web Service de Recepo de Lote de Eventos recebe a mensagem de solicitao

de processamento. Em seguida, a EFD-REINF valida o lote e os eventos contidos
nele. Os eventos vlidos so armazenados no banco de dados da EFD-REINF;

3) O Web Service retorna para a instituio declarante um arquivo contendo um

retorno do processamento, que poder ser do tipo Recibo, Protocolo de Envio ou
Lista de Erros. Nesse ponto a transmisso do lote finalizada.

Observao: Caso a instituio no receba retorno ela dever aguardar no mnimo

300 segundos em relao ao incio da requisio para tentar retransmitir o mesmo
lote ou evento novamente. O no respeito a este prazo poder ser considerado uso
abusivo do sistema.

7. Eventos

As informaes relativas a elaborao dos documentos XML contendo o Evento e o

Retorno do processamento esto detalhados abaixo:

36
 7.1. Estrutura do evento

Cada evento tem sua prpria estrutura, obedecendo ao leiaute estabelecido nesse
manual. A verificao da estrutura dos eventos, conforme os seus respectivos leiautes, ser
realizadas atravs de XSD (Xml Schema Definition).

Cada XSD que representa um leiaute tem o seu prprio Namespace.

Ex: http://www.reinf.esocial.gov.br/schemas/evtInfoContribuinte/v1_01_01

http://www.reinf.esocial.gov.br/sch Estabelece que o XSD de um evento da EFD-

emas/
REINF.
evtInfoContribuinte Identificao do tipo do evento.
v1_01_01 Identificao da verso do XSD e do Leiaute.

A imagem abaixo ilustra a estrutura bsica de um evento:

37
tag: REINF

descrio: Tag raiz do documento da EFD-REINF

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

xmlns obrigatrio 1 Namespace Namespace do Xsd que

representa o leiaute do tipo do
evento.

tag: evtInfoContri

descrio: Tag que identifica o tipo do evento (O nome dessa tag est presente tambm
no namespace do Xsd da estrutura do evento).

Em cada tipo de evento essa tag tem um nome especfico.

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

Id obrigatrio 1 - Identificao nica do evento.

Conforme definido em Error:
Reference source not found Erro
r: Reference source not found.

tag: ideEvento

descrio: Contm informaes gerais do evento.

obrigatrio? Sim

ocorrncia nica

38
campo obrigatoriedade ocorrncia valores vlidos descrio

tpAmb obrigatrio 1 1=Produo; Identificao do ambiente para o

qual o evento est sendo
2=Pr-produo -
transmitido.
dados reais;

3=Pr-produo -
dados fictcios.

procEmi obrigatrio 1 1 - Aplicativo do Origem do documento.

contribuinte;

2 - Aplicativo
governamental.

verProc obrigatrio 1 - Verso do aplicativo emissor do

evento.

tag: ideContri

descrio: Contm identificao e informaes do contribuinte.

obrigatrio? Sim

ocorrncia nica

campo obrigatoriedade ocorrncia valores vlidos descrio

tpInsc obrigatrio 1 1 CNPJ; Contm o tipo de inscrio do

contribuinte.
2 CPF

nrInsc obrigatrio 1 - Contm o nmero de inscrio

do contribuinte.

tag: infoContri

descrio: Identificao da operao (incluso, alterao ou excluso) e das respectivas

informaes do Contribuinte.

Em cada tipo de evento essa "tag" tem um nome especifico.

obrigatrio? Sim

39
ocorrncia nica

tag: Signature

descrio: Contm a assinatura do evento.

obrigatrio? Obrigatrio

ocorrncia nica

Observaes:

O padro de assinatura do evento est descrito em 4.6 - Padro de assinatura digital.

7.2. Identificao do evento

Cada evento da EFD-REINF possui uma identificao nica, gerada pelo prprio
declarante, conforme o padro abaixo:

Campo Fixo Parte Numrica

ID Conforme regra de formao abaixo:

T - Tipo de Inscrio do Contribuinte (1 - CNPJ; 2 - CPF);

NNNNNNNNNNNNNN - Nmero do CNPJ ou CPF do empregador -

Completar com zeros direita;

AAAAMMDD - Ano, ms e dia da gerao do evento;

HHMMSS - Hora, minuto e segundo da gerao do evento;

QQQQQ - Nmero sequencial da chave. Incrementar somente quando ocorrer

gerao de eventos na mesma data/hora.
2 posies 34 posies

40
 Exemplo: ID2333901700001892014020213424700001. (36 posies)

7.3. Assinatura do evento

O documento Xml do Evento dever ser assinado com um certificado digital do tipo
e-CPF (e-PF) ou e-CNPJ (e-PJ)., conforme a especificao definida em 4.6 - Padro de
assinatura digital e os critrios estabelecidos nesse manual.

A assinatura do evento dever ser realizada sobre todo documento Xml e inserida no
local estabelecido no Schema (XSD) de cada tipo de evento, ou seja, no elemento
"Signature".

7.4. Estrutura do retorno de processamento do evento

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

8. Recomendaes e boas prticas

O objetivo desta seo orientar os usurios dos Webservices a utilizarem a EFD-

REINF seguindo boas prticas, facilitando a integrao com o sistema.

8.1. Respeitar a ordem de precedncia no envio dos eventos em lotes

A EFD-REINF controla a precedncia do recebimento dos eventos, de acordo com

as regras estabelecidas pelo leiaute, com o objetivo de garantir a integridade dos dados
declarados.

Os eventos iniciais e de tabelas so dados que constituem o contribuinte na EFD-

REINF, sendo referenciados por praticamente todos os eventos. Por isso, quando so
processados, requerem maior ateno quanto as regras de precedncia.

41
 Recomenda-se fortemente que o transmissor faa primeiramente a transmisso dos
seus eventos iniciais e de tabelas. Em seguida, envie os eventos peridicos. Caso as regras
de precedncia no forem seguidas, a EFD-REINF rejeitar o evento.

8.2. Evitar o envio de eventos durante o processamento do evento de

fechamento

Durante o processamento do evento R-2099 - Fechamento dos Eventos Peridicos

a EFD-REINF no recepcionar nenhum evento daquele contribuinte, com o objetivo de
garantir a integridade dos dados no Sistema. Caso algum evento seja enviado durante o
processamento do fechamento ele ser rejeitado. Nesta situao, o transmissor deve
aguardar o trmino do fechamento e retransmitir o(s) evento(s).

8.3. Otimizao na montagem do arquivo

No dever ser includa a tag de campo com contedo zero (para campos tipo
numrico) ou vazio (para campos tipo caractere) na gerao do arquivo XML para servir de
insumo e de resposta para os servios disponibilizados pela EFD-REINF. Exceto para os
campos identificados como obrigatrios no modelo, neste caso, dever constar a tag com o
valor correspondente (mesmo que este seja zero ou vazio) e, para os demais campos,
devero ser eliminadas as tags.

Para reduzir o tamanho final do arquivo XML a ser transportado alguns cuidados de
programao devero ser assumidos:

no incluir "zeros no significativos" para campos numricos, exceto quando o

campo possuir um universo definido de valores vlidos;

no incluir "espaos" no incio ou no final de campos numricos e alfanumricos;

no incluir comentrios no arquivo XML;

42
 no incluir anotao e documentao no arquivo XML (tag annotation e tag
documentation);

no incluir caracteres de formatao.

8.4. Validao de Schema

Para garantir minimamente a integridade das informaes prestadas e a correta

formao dos arquivos XML, o consumidor dos servios dever submeter as mensagens
XML para validao pelo Schema do XML (XSD XML Schema Definition),
disponibilizado no portal do SPED, antes do seu envio.

9. Orientaes para utilizao do ambiente de Produo Restrita

9.1. Sobre a Produo Restrita

O ambiente de Produo Restrita da EFD-REINF tem o objetivo de disponibilizar

uma infraestrutura para as empresas realizarem os testes funcionais de suas aplicaes.

A Produo Restrita ter a mesma verso da EFD-REINF que ser disponibilizada

em ambiente de produo. Toda evoluo da EFD-REINF ser implantada primeiramente
no ambiente de Produo Restrita, onde ficar disponvel para os testes das empresas por
um determinado tempo a ser definido de acordo a caracterstica/tamanho da mudana. Em
seguida, ser implantada no ambiente de Produo.

Com isso, as empresas faro uso do ambiente de produo, somente aps as suas
aplicaes estarem amadurecidas e estabilizadas diante dos testes realizados na Produo
Restrita.

muito importante ressaltar que a Produo Restrita no um ambiente para as

Empresas realizarem testes de carga ou de performance antes de transmitirem para a
Produo.

43
 Seguem abaixo as caractersticas dos ambientes:

Ambiente de Produo Restrita Ambiente de Produo

Menor capacidade de processamento Grande capacidade de processamento

Disponibilidade 24 x 7 (com maior Disponibilidade 24 x7

flexibilidade para realizao de janelas de
manuteno)
Tempo limitado de guarda dos dados. Tempo de guarda dos dados conforme
(ver seo "Tempo de guarda dos dados" legislao.
deste documento)
Este ambiente no d validade jurdica s As informaes recebidas possuem validade
informaes recebidas. Dessa forma, os jurdica.
dados transmitidos pelas empresas podem
ser reais ou fictcios.
Testes funcionais -

9.2. Eventos

Inicialmente, o ambiente de Produo Restrita ser disponibilizado contendo os

eventos abaixo que foram implementados de acordo com a verso 1.1 do leiaute e da verso
1_01_01 dos schemas XML:

1. R-1000 - Informaes do Empregador/Contribuinte

2. R-1070 - Tabela de Processos Administrativos/Judiciais
3. R-2010 Reteno Contribuio Previdenciria - Servios Tomados
4. R-2020 Reteno Contribuio Previdenciria - Servios Prestados
5. R-2030 Recursos Recebidos por Associao Desportiva
6. R-2040 Recursos Repassados para Associao Desportiva
7. R-2098 Reabertura dos Eventos Peridicos
8. R-2099 Fechamento dos Eventos Peridicos
9. R-9000 Excluso de Eventos

As datas para disponibilizao de verses futuras da EFD-REINF nos ambientes de

Produo Restrita e Produo sero divulgadas oportunamente.

44
9.3. Restries

A Produo Restrita limitar a utilizao do ambiente ao envio de 50 eventos por

contribuinte por dia.

O ambiente de Produo Restrita da EFD-REINF obrigar que o certificado digital

usado para assinar os eventos seja do mesmo contribuinte (CNPJ) declarado nos eventos a
serem enviados. No sero aceitos certificados digitais do representante legal nem do
procurador do contribuinte declarante.

Especificamente para os eventos abaixo sero aplicadas as seguintes restries:

R-2010 Reteno Contribuio Previdenciria - Servios Tomados:

o grupo idePrestServ poder ter no mximo 5 ocorrncias;

o grupo nfs poder ter no mximo 10 ocorrncias;

R-2020 Reteno Contribuio Previdenciria - Servios Prestados

o grupo ideTomador poder ter no mximo 5 ocorrncias;

o grupo nfs poder ter no mximo 10 ocorrncias;

9.4. Tempo de guarda dos dados

Considerando que a Produo Restrita um ambiente para realizao de testes

funcionais para os empregadores testarem suas aplicaes e que os dados recebidos no
possuem validade jurdica, no existe a necessidade de armazenamento da mesma forma
que previsto para o ambiente de produo.

45
 Nesse sentido, todos os eventos enviados ao ambiente de Produo Restrita sero
completamente excludos periodicamente ou quando houver a necessidade de manuteno
que gere impacto significativo para o sistema.

9.5. Validaes

Segue abaixo o comportamento da EFD-REINF, no ambiente de Produo Restrita,

em relao s validaes com outros Sistemas:

CNPJ - Cadastro Nacional de Pessoa Jurdica

Descrio simplificada: O CNPJ compreende as informaes cadastrais das

entidades de interesse das administraes tributrias da Unio, dos Estados, do Distrito
Federal e dos Municpios.
Orientao de uso: Os CNPJ informados nos eventos da EFD-REINF Produo
Restrita, no sero validados contra o ambiente de produo do Sistema CNPJ, na primeira
etapa de uso do ambiente de Produo Restrita.

Procurao Eletrnica

Descrio simplificada: um documento eletrnico de procurao assinado

digitalmente por um Certificado Digital vlido.

Orientao de uso: Inicialmente o ambiente de Produo Restrita no aceitar o uso

de procurao eletrnica.

CNO - Cadastro Nacional de Obras

Descrio simplificada: Refere-se ao registro, perante a RFB, das informaes

especficas de obras de construo civil, seja para pessoas fsicas ou para pessoas jurdicas.

Orientao de uso: Inicialmente o ambiente de Produo Restrita no far qualquer

validao a respeito do CNO.

46
9.6. Regra para identificao do ambiente

Todos os eventos gerados para o ambiente de Produo Restrita devero ter a

informao de identificao do ambiente, conforme abaixo:

A tag tmAmb deve ser preenchida com o valor 2 Produo Restrita Dados Reais
ou 3 Produo Restrita Dados Fictcios.

9.7. URL dos Web Services

Seguem as URL par acesso aos Web Services da EFD-REINF:

URL do Web Service de envio de lotes:

https://preprodefdreinf.receita.fazenda.gov.br/RecepcaoLoteReinf.svc

URL do Web Service de consulta de resultado de processamento de lotes:

Em elaborao. Ser disponibilizado na prxima verso desse Manual.

9.8. Da data de disponibilizao do ambiente

O ambiente de Produo Restrita estar disponvel para uso pelas empresas a partir
do dia 17/07/2017.

47