Pesquisar na Comunidade

Referente ao tópico acima CNPJ alfanumérico: campos contendo inscrições do Cadastro Nacional da Pessoa Jurídica (CNPJ) passam a permitir o formato incluindo letras e números nos termos da Instrução Normativa RFB nº 2.229/2024. Relacionado a tarefa mencionada no tópico acima (ACBR-9420) para essa finalidade, existe uma data ou previsão para sair essa correção?

Olá comunidade ! Visando adequação ao CNPJ alfanumérica na EFD-Reinf, foi publicada a Nota Técnica 03/2026 e seus respectivos schemas. Alterações CNPJ alfanumérico: campos contendo inscrições do Cadastro Nacional da Pessoa Jurídica (CNPJ) passam a permitir o formato incluindo letras e números nos termos da Instrução Normativa RFB nº 2.229/2024. Foi adicionado nos leiautes R-4010 e R-4020 respectivamente o campo opcional cpfOrigRecurso nos grupos infoRRA e infoProcJud respectivamente. Datas As alterações entram em produção a partir de Julho em data ainda a ser divulgada. E como fica o ACBr? Alterações na solução ACBr serão necessárias. Foi criada a tarefa ACBR-9420 para essa finalidade. Assim que houver novidades será divulgado aqui neste tópico. Leia a nota técnica completa AQUI. Veja a notícia original na qual este tópico se baseou AQUI.

Prezados, Com a publicação da Receita Federal sobre a adoção do CNPJ alfanumérico a partir de julho de 2026, gostaríamos de esclarecer alguns pontos relacionados ao REINF e ao uso do ACBr. Atualmente, ao realizar o envio do evento evtTomadorServicos (v2_01_02), estamos enfrentando a seguinte rejeição: Erro: 1824 - Element 'cnpjPrestador': '941000181' is not a valid value of the local atomic type. Entendemos que: Os schemas atuais do REINF ainda seguem o padrão de CNPJ numérico (14 dígitos) A validação está sendo feita com base nesses schemas vigentes Diante disso, gostaríamos de saber: O ACBr já possui alguma adequação planejada para suportar o novo formato de CNPJ alfanumérico? Existe previsão de atualização dos componentes REINF para atender essa mudança? Haverá necessidade de alteração manual por parte dos desenvolvedores ou será tratado automaticamente via atualização de schemas? Já existe alguma branch, beta ou orientação para adaptação antecipada? Nosso objetivo é nos antecipar à mudança e evitar impactos nas integrações com o REINF quando a obrigatoriedade entrar em vigor. Ficamos no aguardo de um posicionamento. Atenciosamente, Kelyanne

Olá comunidade ! A nota técnica 01/2026 do Reinf incorpora mudanças que visam atender a redução de benefícios fiscais estabelecida pela Lei Complementar nº 224/2025, regulamentada pelo Decreto nº 12.808/2025 e pela IN RFB nº 2.305/2025. Dentre as mudanças temos: Registro R-9001: Campo {CRComl} do grupo {RComl}: alterações das alíquotas a partir de 04/2026. Campo {CRAquis} do grupo {RAquis}: alterações das alíquotas a partir de 04/2026. Campo {vlrCRAquis} do grupo {RAquis}: Inclusão da regra de maior valor. E como fica o ACBr? Como a nota técnica não traz alterações de leiaute e os campos mencionados na mesma já são do tipo string e float respectivamente não possuindo assim nenhuma restrição, modificações na solução ACBr não se fazem necessárias. Leia a nota técnica na íntegra AQUI. Esta notícia foi baseada em publicação originalmente encontrada AQUI.

Prezados, uma dúvida que chegou até nós que usamos os componentes ACBr para transmissão do REINF, foi que com o fim da obrigatoriedade do envio anual do DIRF e passará a ser enviado pelo Reinf tem alguma informação a mais a ser enviada em relação aos dados do DIRF? Com o fim da DIRF, empregadores devem estar atentos às obrigações relativas ao eSocial e à EFD-Reinf — Receita Federal Agradeço.

Olá comunidade ! Foi publicado no dia 31/12/2025 a Nota Técnica 04/2025 para o Reinf trazendo os seguintes ajustes na tabela da versão 2.1.2: Criação do Código de Natureza de Rendimento (CNR) 10011; Criação do CNR 11008 — "Decorrente de Decisão da Justiça do Trabalho - IRRF pertencente aos Estados/Municípios" Ajustes no CNR 12001 (Lucros e Dividendos) E como fica o ACBr? O campo já do tipo string no componente e por isso modificações não se fazem necessárias. Leia a Nota Técnica na íntegra AQUI.

Olá comunidade ! Foi disponibilizada a versão 2.1.2.b dos leiautes do Reinf. A nova versão traz as alterações até a Nota Técnica 3/2025. De acordo com o controle de alterações também disponibilizado, essas são as mudanças em relação a versão anterior: E como fica o ACBr? Foi criada a tarefa ACBR-8373 em nosso backlog para análise da documentação disponibilizada e adequação das soluções ACBr. Assim que houver novidades a respeito será divulgado aqui neste tópico.

Olá comunidade ! Foi publicada a versão 2.7 do Manual de orientação ao desenvolvedor do Reinf. Esta versão remove as menções ao modo de envio síncrono.

Olá, pessoal! Foi publicada a Nota Técnica 03/2025 do Reinf. Essa atualização adiciona novos valores possíveis na Tabela 01 – Natureza de Rendimentos do Anexo I dos leiautes e também na Tabela de Natureza de Rendimentos x Código de Receita do Anexo I do Manual de Orientação do Usuário, versão 2.1.2.1, a ser utilizada no registro R-4020. O campo natRendimento já é do tipo string no componente ACBrReinf, portanto, não são necessárias modificações no componente. Leia a Nota Técnica na íntegra [AQUI]

Olá pessoal! Foi publicada notícia no portal Sped > Efd-Reinf informando que a partir de 20/08/2025 o web service do Reinf não vai mais aceitar conexões utilizando os protocolos TLS 1.0 e TLS 1.1. Para evitar problemas de conexão softwares deverão atualizar seus sistemas para versão 1.2 ou superior. Vale mencionar que o ACBr já atende a este protocolo, bastando apenas definir a propriedade: ACBrReinf.SSL.SSLType := LT_TLSv1_2; Caso haja alguma dúvida ou queira testar sua aplicação, o ambiente de produção restrita do Reinf já está aplicando está restrição, aceitando apenas versão 1.2 ou superior. Leia a notícia na íntegra AQUI.

Olá pessoal! Foi publicado no dia 11/06/2025 a Nota Técnica 02/2025 para o EFD-Reinf. A mesma traz alterações no evento R-1000 adicionando um novo campo opcional indPertIRRF para servir como indicador de pertencimento ao IRRF. O novo campo é de preenchimento exclusivo para o contribuinte cuja natureza jurídica seja igual a [126-0, 127-9, 129-5, 130-9]. E como fica o ACBr? Foi criada a #TK-7221 para adequação do componente adicionando o novo campo. Qualquer novidade será divulgada aqui neste tópico. Leia a nota técnica na íntegra AQUI ou em nosso Tools

Olá pessoal! No dia 21/03/2025 foi publicada a versão 2.6 do Manual de Orientação ao Desenvolvedor da EFD-Reinf. A nova versão traz a informação de que o ambiente de produção restrita vai passar a receber um máximo de 1000 eventos para cada contribuinte e tipo de evento. Qualquer tentativa que ultrapasse este limite será rejeitada com a orientação para que o contribuinte limpe a base de testes. Vale lembrar que isso já avisado previamente. Além disso, a nova versão do manual também traz a informação de que pelo fato de o ambiente de produção restrita ser utilizado para testes e não possuir validade jurídica, os eventos enviados a esse ambiente serão completamente excluídos periodicamente ou quando houver necessidade de manutenção. Leia o aviso da publicação da versão 2.6 do manual AQUI. Leia a versão 2.6 do manual AQUI.

Olá pessoal, Foram disponibilizados na Rev-37915 os programas de exemplo em PHP, Singlethread e Multithread utilizando a ACBrLibReinf. ..\ACBr\Projetos\ACBrLib\Demos\PHP\Reinf\ACBrReinfDemoST.php ..\ACBr\Projetos\ACBrLib\Demos\PHP\Reinf\ACBrReinfDemoMT.php Lembrando que os programas de exemplo em php utilizam a ACBrComum.php que contém métodos em comum entre os modos (ST e MT) e para todas as libs. ..\ACBr\Projetos\ACBrLib\Demos\PHP\ACBrComum\ACBrComum.php Até mais!!!

Olá pessoal! No dia 20/02/2025, todos os dados do ambiente de produção restrita do Reinf serão removidos da base de dados e a partir desta data serão armazenados no máximo 1.000 arquivos por tipo de evento por contribuinte. Esta modificação visa garantir a otimização do ambiente para todos os contribuintes que visam realizar testes com o mesmo. Caso contribuinte receba retorno de que atingiu o limite permitido, o mesmo deverá executar o processo para limpar a base da dados conforme orientação retirada do Manual Orientacao Desenvolvedor-REINF-v2.5: Este tópico foi criado a partir de aviso publicado originalmente AQUI.

Olá pessoal! No dia 07/10/2024 foi publicada a versão 2.1.2.a do leiaute do Reinf. Esta nova versão consolida as alterações descritas nas notas técnicas 01/2023, 02/2023, 03/2023, 04/2023, 01/2024, 02/2024 e 03/2024. Na mesma data, também foram publicados novos schemas para atender a última nota técnica 03/2024. As alterações já estão disponíveis tanto no ambiente de produção restrita quanto no ambiente de produção. Os novos documentos relacionados a nova versão do leiaute podem ser encontrados AQUI. Com destaque ao arquivo Controle de alteracoes Leiautes da EFD-Reinf v2.1.2a base v2.1.2.pdf, que traz um compilado das alterações desta nova versão em relação a anterior. E como fica o ACBr? Dentre as modificações, há alteração de ocorrências de campos já existentes e adição de novos, portanto, serão necessárias modificações no componente ACBrReinf que posteriormente serão refletidas na Lib e no Monitor. Criada a #TK-6070 para adequação dos fontes. Qualquer novidade será relatada neste tópico.

A Receita Federal do Brasil - RFB publicou em 15/05/2024 a versão 2.5 do Manual de Orientação ao Desenvolvedor da EFD-Reinf que contém a atualização de url para consulta de recibos para produção. Segue link da publicação. Segue link da versão 2.5 do Manual de Orientação ao Desenvolvedor. Já estamos analisando a mudança para adequar o Componente, a Lib e o Monitor e atualizaremos o tópico quando as alterações estiverem disponíveis.

Olá pessoal, Ficamos felizes em dizer que foi disponibilizada a mais nova biblioteca do pacote ACBrLib, a ACBrLibReinf !! O projeto havia sido iniciado há um tempo e, por fazer parte do grupo de componentes de DFe, logicamente tem a assinatura inicial do @Italo Giurizzato Junior .... Méritos também para o @antonio.carlos que contribuiu nas implementações... A ACBrLibReinf está disponível para download e já estão no SVN os programas de exemplo em c# e node.js. Segue o link da documentação da biblioteca e contamos com a comunidade, caso tenham disponbilidade e possam compartilhar exemplos em outras linguagens, que venham a ajudar outros colegas. Até mais!!!

Olá pessoal, A seguir colocamos os tópicos deste workshop do Dia do ACBr 2023 e um resumo do que foi abordado. 1. Documentação, Manuais e NTs Sempre indicamos a leitura dos Manuais e NTs, pois são as fontes de onde o ACBr extrai informações para o desenvolvimento dos componentes 1.1. Todos os documentos relacionados ao Reinf https://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ 1.2. Manual de Orientação ao Desenvolvedor: Leitura essencial para entender como funciona o Reinf e seus métodos https://svn.code.sf.net/p/acbr/code/tools/DFe/Reinf/ManDesenvolvedor/ManualOrientacaoDesenvolvedor-REINF-v2.3.pdf 2. Sequência lógica: Consta no Manual de Orientação ao Desenvolvedor (item 1.2) 3. TLS 1.2 A partir de janeiro de 2024 a comunicação será exclusiva com TLS 1.2 Isso seria implementado em outubro de 2023, mas foi postergado Existem relatos de certificados A3 que não estão funcionando com o TLS 1.2 e isso é um problema recorrente com alguns DFes e alguns certificados 4. Qual a diferença entre as versões? A versão 1.5 é Síncrona e SOAP, a 2.1 é Assíncrona e REST Ambas trabalham com envio e retorno via XML A versão 1.5 seguirá ativa por 6 meses após o início da versão 2.1, que foi em 09/2023 A versão 1.5, por ser síncrona, recebe o retorno do processamento automaticamente ao enviar os eventos e a versão 2.1, por ser assíncrona, devolve o número do protocolo para ser consultado posteriormente e obter o resultado do processamento A consulta de protocolo já existia na versão 1.5 para o registro R2099, que era o único assíncrono nesta versão 5. Registros 4000 São exclusivos da versão 2.1, não sendo possível o envio na versão 1.5 6. Consulta de Recibo O número do recibo, além de um comprovante do processamento, será necessário para a retificação ou exclusão de um evento Ao consultar o protocolo, o número do recibo e devolvido e se for armazenado neste momento, não será necessária a utilização da Consulta de Recibo para este fim O método possui diversos parâmetros, pois para cada tipo de registro são necessários dados específicos. No Manual de Orientação ao Desenvolvedor (item 1.2) é possível iedntificar os parâmetros para cada tipo de registro 7. Processo padrão Na versão o processo é dividido em: Preenchimento do Componente, Envio e Consulta do Protocolo 7.1. Preenchimento do componente Pode ser feito via código alimentando as propriedades do componente, através de leitura de arquivo INI seguindo o padrão ACBr ou de XML seguindo o leiaute do Reinf O preenchimento através de arquivo INI, suporta o limite de 50 eventos por lote e o preenchimento lendo XML no leiaute do Reinf exige que seja lote de apenas 1 evento 7.2. Envio Quando o componente estiver preenchido com uma das opções do item 7.1 o lote deverá ser enviado Ao enviar o lote, será recebido o número do protocolo para que seja feita a consulta, que retornará o resultado do processamento 7.3. Consulta do Protocolo Ao consultar o protocolo recebido no item 7.2 será recebido o retorno do processamento Caso ocorram erros, será retornada uma lista contendo 1 ou mais erros identificados pelo serviço Caso o lote tenha sido processado com sucesso, será retornado o número do recibo e demais informações relacionadas a cada tipo de evento 8. Método de Limpeza da base de Produção Restrita (Homologação) Lembrando que este método só é possível ser utilizado na base de testes, conforme destacado no item Enviar o Registro R1000 Como evento de Alteração IdeEvento.VerProc = 'RemoverContribuinte' ClassTrib = ct00 // ct00 é um enumerado utilizado somente para este fim 9. Informações adicionais Existe um limite estipulado pelo serviço de 50 eventos por lote A RFB recomenda que os Registros R2099 e R4099, de fechamento, sejam enviados em lotes isolados, após a consulta e confirmação de processamento de todos os demais registros

Olá, sou novo aqui no fórum, esta é a minha primeira postagem. Se estiver no local incorreto peço desculpas. Estou enfrentando um problema ao atualizar nosso sistema próprio para a versão 2.01.02 do EFD-REINF. O problema parece estar relacionado à estrutura do XML enviado para o webservice do EFD-REINF. Antes de enviar o XML, fazemos uma validação para garantir que a estrutura está correta, de acordo com o arquivo XLSX fornecido pelo EFD-REINF. Até agora, não encontrei uma solução adequada para esse problema nos fóruns e sites relacionados, pois as mensagens de erro retornadas são bastante genéricas. Em resumo, após consultar o protocolo da situação do documento no endpoint https://reinf.receita.economia.gov.br/recepcao/lotes, recebemos um retorno que indica que o arquivo não foi enviado corretamente. Aqui está o XML enviado para o endpoint: <Reinf xmlns="http://www.reinf.esocial.gov.br/schemas/envioLoteEventosAssincrono/v1_00_00"> <envioLoteEventos> <ideContribuinte> <tpInsc>1</tpInsc> <nrInsc>00000000</nrInsc> </ideContribuinte> <eventos> <evento Id="IDXXXXXXXXXXXXXXXXXXXXXXXXXXX"> <ns2:Reinf xmlns:ns2="http://www.reinf.esocial.gov.br/schemas/evtInfoContribuinte/v2_01_02" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#"> <ns2:evtInfoContri id="IDXXXXXXXXXXXXXXX"> <ns2:ideEvento> <ns2:tpAmb>1</ns2:tpAmb> <ns2:procEmi>1</ns2:procEmi> <ns2:verProc>2.01.02</ns2:verProc> </ns2:ideEvento> <ns2:ideContri> <ns2:tpInsc>1</ns2:tpInsc> <ns2:nrInsc>00000000</ns2:nrInsc> </ns2:ideContri> <ns2:infoContri> <ns2:inclusao> <ns2:idePeriodo> <ns2:iniValid>2023-10</ns2:iniValid> <ns2:fimValid>2023-10</ns2:fimValid> </ns2:idePeriodo> <ns2:infoCadastro> <ns2:classTrib>99</ns2:classTrib> <ns2:indEscrituracao>0</ns2:indEscrituracao> <ns2:indDesoneracao>0</ns2:indDesoneracao> <ns2:indAcordoIsenMulta>0</ns2:indAcordoIsenMulta> <ns2:indSitPJ>0</ns2:indSitPJ> <ns2:contato> <ns2:nmCtt>THAIS XXXXXX</ns2:nmCtt> <ns2:cpfCtt>00000000000</ns2:cpfCtt> <ns2:foneFixo>0032000000</ns2:foneFixo> <ns2:foneCel>0032000000</ns2:foneCel> <ns2:email>[email protected]</ns2:email> </ns2:contato> <ns2:softHouse> <ns2:cnpjSoftHouse>80400000000000</ns2:cnpjSoftHouse> <ns2:nmRazao>XXXXXX INFORMATICA LTDA</ns2:nmRazao> <ns2:nmCont>SUPORTE</ns2:nmCont> <ns2:telefone>0003006611</ns2:telefone> <ns2:email>[email protected]</ns2:email> </ns2:softHouse> </ns2:infoCadastro> </ns2:inclusao> </ns2:infoContri> </ns2:evtInfoContri> <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="#ID18260000000000000000000000001"> <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>zdnff+xXXXXXXXXXXXXA1y8KVXQvTrk436Z8=</DigestValue> </Reference> </SignedInfo> <SignatureValue>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&#xd; </X509Certificate> </X509Data> </KeyInfo> </Signature> </ns2:Reinf> </evento> </eventos> </envioLoteEventos> </Reinf> E aqui está o XML de retorno da consulta do protocolo: https://reinf.receita.economia.gov.br/consulta/lotes/ <Reinf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.reinf.esocial.gov.br/schemas/retornoLoteEventosAssincrono/v1_00_00"> <retornoLoteEventosAssincrono> <ideContribuinte> <tpInsc>1</tpInsc> <nrInsc>XXXXXXXXX</nrInsc> </ideContribuinte> <status> <cdResposta>3</cdResposta> <descResposta>Lote processado com sucesso - Possui um ou mais eventos com ocorrências de erro.</descResposta> </status> <dadosRecepcaoLote> <dhRecepcao>2023-10-25T14:58:51.447</dhRecepcao> <versaoAplicativoRecepcao>2.0.1-1600512</versaoAplicativoRecepcao> <protocoloEnvio>1.202310.0000000</protocoloEnvio> </dadosRecepcaoLote> <dadosProcessamentoLote> <versaoAplicativoProcessamentoLote>2.0.1-1608191</versaoAplicativoProcessamentoLote> </dadosProcessamentoLote> <retornoEventos> <evento Id="IDXXXXXXXXXXXXXXX5000001"> <retornoEvento> <Reinf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.reinf.esocial.gov.br/schemas/evtTotal/v2_01_02"> <evtTotal id="IDXXXXXXXXXXXX0294038679"> <ideEvento> <perApur /> </ideEvento> <ideContri> <tpInsc>1</tpInsc> <nrInsc>00000000</nrInsc> </ideContri> <ideRecRetorno> <ideStatus> <cdRetorno>1</cdRetorno> <descRetorno>ERRO</descRetorno> <regOcorrs> <tpOcorr>1</tpOcorr> <localErroAviso> - Campo: xmlns - XPATH: /Reinf/@xmlns</localErroAviso> <codResp>MS0055</codResp> <dscResp>O campo 'xmlns' é obrigatório e não foi informado.</dscResp> </regOcorrs> <regOcorrs> <tpOcorr>1</tpOcorr> <localErroAviso>Registro: idePeriodo - XPATH: /Reinf/evtInfoContri/infoContri/inclusao/idePeriodo</localErroAviso> <codResp>MS1005</codResp> <dscResp>Já existe outro registro com período conflitante com o período informado.</dscResp> </regOcorrs> </ideStatus> </ideRecRetorno> <infoRecEv> <dhRecepcao>2023-10-25T14:58:51.447</dhRecepcao> <dhProcess>2023-10-25T14:58:51.5717635-03:00</dhProcess> <tpEv>1000</tpEv> <idEv>ID1213XXXXXXXXXXXXXXX14584900001</idEv> <hash>1jxSew1pZmXXXXXXXXXXXXXXXXyg87jkYn03PqQ2/teE=</hash> </infoRecEv> </evtTotal> <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="#ID90010000000XXXXXXXXXXXX679"> <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>989hxPJXXXXXXXXXXXXXXXOcVLUy+N2Q=</DigestValue> </Reference> </SignedInfo> <SignatureValue>F716jvXXXXXXXXXXXXXXXXXXXXXXXXXZTQvwtbNp7lnMRj6R2G14biNqOu+zbDwS4LMlActrgy/974u8i0u44VFdrqd3wIaUng+xXx30u+skKyp1OOpc3fOa804RdOPT+4QnxwvVOcW6KrF3FdbU5U4NV9fK8BZYXiH5KGzLdR93uKP1ERpOBErmn+iQv0CbTT6xf5TgTyQLEEv1iheIXfivA2FHKKGw8V1Vns0yQNW3qMp0RO8n3wNNX6RfVZsooA0oZkl41RZGW8Bcc3x2BHH7iQZmYRD62GqZBw==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIIcDCCBligAwIBAgIMLwj8Ba6fwpuyKikgMXXXXXXXXXXXXXXXXXGA1UECwwsQXV0b3JpZGFkZSBDZXJ0aWZpY2Fkb3JhIFJhaXogQnJhc2lsZWlyYSB2MTAxMTAvBgNVBAMMKEF1dG9yaWRhZGUgQ2VydGlmaWNhZG9yYSBkbyBTRVJQUk8gU1NMdjEwHhcNMjMwNzA0MTY1MzM1WhcNMjQwNzAzMTY1MzM1WjCB4DELMAkGA1UEBhMCQlIxCzAJBgNVBAgMAk1HMRcwFQYDVQQHDA5CRUxPIEhPUklaT05URTE7MDkGA1UECgwyU0VSVklDTyBGRURFUkFMIERFIFBST0NFU1NBTUVOVE8gREUgREFET1MgKFNFUlBSTykxFzAVBgNVBAUTDjMzNjgzMTExMDAwMTA3MSYwJAYDVQQDDB1yZWluZi5yZWNlaXRhLmVjb25vbWlhLmdvdi5icjEYMBYGA1UEDxMPQnVzaW5lc3MgRW50aXR5MRMwEQYLKwYBBAGCNzwCAQMTAkJSMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/JL5f6YLKJn04L+Vq+K9hB8BU7KAO29ESl6vwuM9oN74gJJUOOeaSUdFA1MPrxyEbV3X60cFzPUeekF6reqvcLMnvLObjGF3x1vdcGllu58f2UXW9R12Dx83h6QUz33nUbleHUS2mppWzFhDfkviyKjGhif2fdx+8oZb4Hk4N8B9tammGVNFoe+76mQnZkDZggsb6PEXqOWaC5ksO3mLxKmNtuF5lhgWzwXJSS/bZfDAoPb+x/SLZt6SZjInxgK7nGP4LO+d9uH7E0lmbnZTCZGMs89/T9R6CBRSZJfGnbdm7aVGlzwFmp0A5V9PQEsX6xkx04c1gEzxrqgBUWO1QIDAQABo4IDejCCA3YwHwYDVR0jBBgwFoAUrRZPS/EMvsKKooUY1w1GJZMi480wgYgGA1UdHwSBgDB+MDygOqA4hjZodHRwOi8vcmVwb3NpdG9yaW8uc2VycHJvLmdvdi5ici9sY3IvYWNzZXJwcm9zc2x2MS5jcmwwPqA8oDqGOGh0dHA6Ly9jZXJ0aWZpY2Fkb3MyLnNlcnByby5nb3YuYnIvbGNyL2Fjc2VycHJvc3NsdjEuY3JsMIGHBggrBgEFBQcBAQR7MHkwQgYIKwYBBQUHMAKGNmh0dHA6Ly9yZXBvc2l0b3Jpby5zZXJwcm8uZ292LmJyL2NhZGVpYXMvc2VycHJvc3NsLnA3YjAzBggrBgEFBQcwAYYnaHR0cDovL29jc3Auc2VycHJvLmdvdi5ici9hY3NlcnByb3NzbHYxMCgGA1UdEQQhMB+CHXJlaW5mLnJlY2VpdGEuZWNvbm9taWEuZ292LmJyMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwYwYDVR0gBFwwWjAIBgZngQwBAgIwTgYGYEwBAgFpMEQwQgYIKwYBBQUHAgEWNmh0dHA6Ly9yZXBvc2l0b3Jpby5zZXJwcm8uZ292LmJyL2RvY3MvZHBjc2VycHJvc3NsLnBkZjCCAX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHcA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGJIdMnDwAABAMASDBGAiEA+5xCsS1hRXm52Xok9PXS2/SDDs+/P13buqyJwHP43mUCIQCsZiap0oPwZAonHHciWFrWA0gj5qD4HrHrP12MUqyg6gB1AHb/iD8KtvuVUcJhzPWHujS0pM27KdxoQgqf5mdMWjp0AAABiSHTLDsAAAQDAEYwRAIgPCpKFidq70sXCZS2rOaqJllFmF+CI3Q85jec1tPmrZECIC1lauZMb+yM7XsJwxQ5+2/aPa+6GwnuoqxFmZf0BeloAHYAh0+1DcAp2ZMd5XPp8omejkUzs5LTiwpGJXS/D+6y/B4AAAGJIdNfDQAABAMARzBFAiBowWmCQfnFdyOYlqhjanZDQoI6tHzekX3pCz7jdy5uRwIhAN42kXqpKQKzEhgwHg4C1S/97bKoGexfWFwav3MlPZl8MA0GCSqGSIb3DQEBCwUAA4ICAQBMdJYqCCTHH+sjz+RZujkWVzm6LKY2OhdRzMjXnE/3TLz84uZIt4RvbWdd2s8JCMJpkcrTHsS059Uia1TOsTRgWlJU8iD+ttRIYtY2OcSgIWiBnF4dP02hGB7OfERDImSewjuBxeNHGr69NmMUwkYm+wqfBF/IPTNkr846YHYv9e8c5SgWjvb8OtPm/ZmibPYE6kzV9iMJ4pTHlTcBYj4ihmNe0hFP+cK3yyiPflpJCmxipvf7MyVRV4oadZcXhA2s7R76Uly9BWcqbP0UHriYL9l8tnyGN1EsVnu6q1E4Uhp7t7dtL3Yy4ZSsBR6+XTFESvl0eofh4JdqH+z99e3howAM0IfF5I6+FUqwIDW6ASIeKwLsLlhIp+6fGBfoIBUD+XxjrOOUZfBSo7A6SVX6ez1zRctwJAEb6ZO/pyNnMQRGVmuhJXnSTjJsNRqNaWOhg1IjHY0REkIvnJ8d+6ZlTUsGYEGtqk012wILpol5x8PQzyWxXyWr56ULJBMWzORgmW2Y/p6OVHc8xIs2hKas7frfHaZxQZLRRbfJ7BIUzwxR2M7l4zjSEFmajPuxea1mZ4J6KlZbm4WFJOHc4sSBgyPMetfOH0xopyiRAhnWWxI0kVp0pbLHSEUNq0/Jqo5PiQgMH9F3epeH5xpX72thPP4ic5YHskr5KOT1IbkyQw==</X509Certificate> </X509Data> </KeyInfo> </Signature> </Reinf> </retornoEvento> </evento> <evento Id="ID121301475XXXXXXXXXXXXXX4585000002"> <retornoEvento> <Reinf xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.reinf.esocial.gov.br/schemas/evtTotal/v2_01_02"> <evtTotal id="ID90010XXXXXXXXXX509XXXX9"> <ideEvento> <perApur>2023-10</perApur> </ideEvento> <ideContri> <tpInsc>1</tpInsc> <nrInsc>21XXXXXXXX5</nrInsc> </ideContri> <ideRecRetorno> <ideStatus> <cdRetorno>1</cdRetorno> <descRetorno>ERRO</descRetorno> <regOcorrs> <tpOcorr>1</tpOcorr> <localErroAviso> - Campo: xmlns - XPATH: /Reinf/@xmlns</localErroAviso> <codResp>MS0055</codResp> <dscResp>O campo 'xmlns' é obrigatório e não foi informado.</dscResp> </regOcorrs> </ideStatus> </ideRecRetorno> <infoRecEv> <dhRecepcao>2023-10-25T14:58:51.447</dhRecepcao> <dhProcess>2023-10-25T14:58:51.6791257-03:00</dhProcess> <tpEv>2010</tpEv> <idEv>ID1213XXXXXXXXXXX005243</idEv> <hash>+6FSHh5dXXXXXXXXXXXXuFQ5dTIXMu4=</hash> </infoRecEv> </evtTotal> <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="#ID90010000000XXXXXXXXXXXXX629"> <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>xuGXjE61AVyXXXXXXXXXXXXXXv6jU++hlBE/4=</DigestValue> </Reference> </SignedInfo> <SignatureValue>aCr6JEfE18HvGwU2tXXXXXXXXXXXXXXXXXXXXidFg305X+tCFOXOHPHT2LOP5WF6x/EGARPC5snOKFyaqpt1W0D7pkFyMHOgsB2WJnKnGGjKYW7PgMwUAC7Q/uiOuIhQmSPTTKIK/zQsEkNcf0080Wx9EEaA2o2ezEgTSrrEyxLD/Aq4+WTCTykGhlgBugtUSTcuCzoIqtD4n4c/0lQS4ZB74VJltvwC5iBftfUrJgv82luAuOo9Gt8sqq+e53qYimawA/R1fsAHzHFRKGYhrNA==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIIcDCCBligAwIBAgIMLwj8BaXXXXXXXXXXXXXXXXXXDZXJ0aWZpY2Fkb3JhIFJhaXogQnJhc2lsZWlyYSB2MTAxMTAvBgNVBAMMKEF1dG9yaWRhZGUgQ2VydGlmaWNhZG9yYSBkbyBTRVJQUk8gU1NMdjEwHhcNMjMwNzA0MTY1MzM1WhcNMjQwNzAzMTY1MzM1WjCB4DELMAkGA1UEBhMCQlIxCzAJBgNVBAgMAk1HMRcwFQYDVQQHDA5CRUxPIEhPUklaT05URTE7MDkGA1UECgwyU0VSVklDTyBGRURFUkFMIERFIFBST0NFU1NBTUVOVE8gREUgREFET1MgKFNFUlBSTykxFzAVBgNVBAUTDjMzNjgzMTExMDAwMTA3MSYwJAYDVQQDDB1yZWluZi5yZWNlaXRhLmVjb25vbWlhLmdvdi5icjEYMBYGA1UEDxMPQnVzaW5lc3MgRW50aXR5MRMwEQYLKwYBBAGCNzwCAQMTAkJSMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw/JL5f6YLKJn04L+Vq+K9hB8BU7KAO29ESl6vwuM9oN74gJJUOOeaSUdFA1MPrxyEbV3X60cFzPUeekF6reqvcLMnvLObjGF3x1vdcGllu58f2UXW9R12Dx83h6QUz33nUbleHUS2mppWzFhDfkviyKjGhif2fdx+8oZb4Hk4N8B9tammGVNFoe+76mQnZkDZggsb6PEXqOWaC5ksO3mLxKmNtuF5lhgWzwXJSS/bZfDAoPb+x/SLZt6SZjInxgK7nGP4LO+d9uH7E0lmbnZTCZGMs89/T9R6CBRSZJfGnbdm7aVGlzwFmp0A5V9PQEsX6xkx04c1gEzxrqgBUWO1QIDAQABo4IDejCCA3YwHwYDVR0jBBgwFoAUrRZPS/EMvsKKooUY1w1GJZMi480wgYgGA1UdHwSBgDB+MDygOqA4hjZodHRwOi8vcmVwb3NpdG9yaW8uc2VycHJvLmdvdi5ici9sY3IvYWNzZXJwcm9zc2x2MS5jcmwwPqA8oDqGOGh0dHA6Ly9jZXJ0aWZpY2Fkb3MyLnNlcnByby5nb3YuYnIvbGNyL2Fjc2VycHJvc3NsdjEuY3JsMIGHBggrBgEFBQcBAQR7MHkwQgYIKwYBBQUHMAKGNmh0dHA6Ly9yZXBvc2l0b3Jpby5zZXJwcm8uZ292LmJyL2NhZGVpYXMvc2VycHJvc3NsLnA3YjAzBggrBgEFBQcwAYYnaHR0cDovL29jc3Auc2VycHJvLmdvdi5ici9hY3NlcnByb3NzbHYxMCgGA1UdEQQhMB+CHXJlaW5mLnJlY2VpdGEuZWNvbm9taWEuZ292LmJyMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwYwYDVR0gBFwwWjAIBgZngQwBAgIwTgYGYEwBAgFpMEQwQgYIKwYBBQUHAgEWNmh0dHA6Ly9yZXBvc2l0b3Jpby5zZXJwcm8uZ292LmJyL2RvY3MvZHBjc2VycHJvc3NsLnBkZjCCAX4GCisGAQQB1nkCBAIEggFuBIIBagFoAHcA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGJIdMnDwAABAMASDBGAiEA+5xCsS1hRXm52Xok9PXS2/SDDs+/P13buqyJwHP43mUCIQCsZiap0oPwZAonHHciWFrWA0gj5qD4HrHrP12MUqyg6gB1AHb/iD8KtvuVUcJhzPWHujS0pM27KdxoQgqf5mdMWjp0AAABiSHTLDsAAAQDAEYwRAIgPCpKFidq70sXCZS2rOaqJllFmF+CI3Q85jec1tPmrZECIC1lauZMb+yM7XsJwxQ5+2/aPa+6GwnuoqxFmZf0BeloAHYAh0+1DcAp2ZMd5XPp8omejkUzs5LTiwpGJXS/D+6y/B4AAAGJIdNfDQAABAMARzBFAiBowWmCQfnFdyOYlqhjanZDQoI6tHzekX3pCz7jdy5uRwIhAN42kXqpKQKzEhgwHg4C1S/97bKoGexfWFwav3MlPZl8MA0GCSqGSIb3DQEBCwUAA4ICAQBMdJYqCCTHH+sjz+RZujkWVzm6LKY2OhdRzMjXnE/3TLz84uZIt4RvbWdd2s8JCMJpkcrTHsS059Uia1TOsTRgWlJU8iD+ttRIYtY2OcSgIWiBnF4dP02hGB7OfERDImSewjuBxeNHGr69NmMUwkYm+wqfBF/IPTNkr846YHYv9e8c5SgWjvb8OtPm/ZmibPYE6kzV9iMJ4pTHlTcBYj4ihmNe0hFP+cK3yyiPflpJCmxipvf7MyVRV4oadZcXhA2s7R76Uly9BWcqbP0UHriYL9l8tnyGN1EsVnu6q1E4Uhp7t7dtL3Yy4ZSsBR6+XTFESvl0eofh4JdqH+z99e3howAM0IfF5I6+FUqwIDW6ASIeKwLsLlhIp+6fGBfoIBUD+XxjrOOUZfBSo7A6SVX6ez1zRctwJAEb6ZO/pyNnMQRGVmuhJXnSTjJsNRqNaWOhg1IjHY0REkIvnJ8d+6ZlTUsGYEGtqk012wILpol5x8PQzyWxXyWr56ULJBMWzORgmW2Y/p6OVHc8xIs2hKas7frfHaZxQZLRRbfJ7BIUzwxR2M7l4zjSEFmajPuxea1mZ4J6KlZbm4WFJOHc4sSBgyPMetfOH0xopyiRAhnWWxI0kVp0pbLHSEUNq0/Jqo5PiQgMH9F3epeH5xpX72thPP4ic5YHskr5KOT1IbkyQw==</X509Certificate> </X509Data> </KeyInfo> </Signature> </Reinf> </retornoEvento> </evento> </retornoEventos> </retornoLoteEventosAssincrono> </Reinf> A parte do erro que preciso corrigir inicialmente seria: <localErroAviso> - Campo: xmlns - XPATH: /Reinf/@xmlns</localErroAviso> <codResp>MS0055</codResp> <dscResp>O campo 'xmlns' é obrigatório e não foi informado.</dscResp> Gostaria de saber se alguém já enfrentou esse problema ou tem alguma sugestão sobre como corrigi-lo. Todas as informações e dicas são muito bem-vindas. Agradeço desde já pela ajuda!

Estou realizando a homologação do Reinf 2.1.2 e no evento R2099 consulta de protocolo parece estar retornando a estrutura do XML diferente dos demais eventos com isso não esta carregando as informações do evtTotal onde contem um dos dados mais importantes que é o Recibo (nrRecArqBase) no trecho a seguir da função LerRetornoEventos: if leitor.rExtrai(4, 'evtTotal') <> '' then ele não encontra o evtTotal no XML, eu tentei mudar o nível e o nome conforme olhei no XML pra ver se conseguia retornar o dado correto mas sem sucesso. Segue um exemplo da consulta de protocolo do evento R1000 onde funciona corretamente na 1ª imagem: e segue outro exemplo da consulta de protocolo do evento R2099 onde não retorna na 2º imagem: os fonte estão atualizados na data de hoje 30/09/2023 e o teste foi feito na minha aplicação e no ACBrReinf_Exemplo ambos ocorre o mesmo problema. alguém já passou por isso ?

Bom dia, Acho que há um erro nas funções de conversão tpDependenteToStr e StrToTpDependente da unit pcnConversaoReinf. O elemento "8" não existe no tipo TtpDependente: TtpDependente = ( ttdConjuge, // 1 - Cônjuge ttdUniaoEstavel, // 2 - Companheiro(a) com o(a) qual tenha filho ou viva há mais de 5 (cinco) anos ou possua declaração de união estável; ttdFilhoOuEnteado, // 3 - Filho(a) ou enteado(a); ttdIrmaoNetoBisneto, // 6 - Irmão(ã), neto(a) ou bisneto(a) sem arrimo dos pais, do(a) qual detenha a guarda judicial do(a) qual detenha a guarda judicial; ttdPaisAvoBisavo, // 9 - Pais, avós e bisavós; ttdMenorComGuarda, // 10 - Menor pobre do qual detenha a guarda judicial; ttdIncapaz, // 11 - A pessoa absolutamente incapaz, da qual seja tutor ou curador; ttdExConjuge, // 12 - Ex-cônjuge; ttdAgregadoOutros // 99 - Agregado/Outros ); O correto seria: function tpDependenteToStr(const t: TtpDependente): string; begin result := EnumeradoToStr2(t, ['1', '2', '3', '6', '9', '10', '11', '12', '99']); end; function StrToTpDependente(var ok: boolean; const s: string): TtpDependente; begin result := TtpDependente(StrToEnumerado2(ok , s, ['1', '2', '3', '6', '9', '10', '11', '12', '99'])); end;

Pessoal, eu tenho uma software house onde eu gero os arquivos Sintegra e Sped Fiscal/Contribuições, mas até o momento não sabia do arquivo Reinf. A minha dúvida é em relação a obrigatoriedade da Software House gerar em seu ERP. Estas informações algumas são oriundas de nota fiscal de entrada, outras de serviços prestados ou tomados e alguns dos registros são para situações específicas, nichos de negócios específicos. Poderiam me tirar esta dúvida, como vocês fazem? Geram isto em seus ERP vinculado as notas fiscais de entradas, saída, serviços ou é um cadastro a parte onde a pessoa informa os valores e gera pelo sistema? Link: https://fenacon.org.br/noticias/empresas-que-usam-maquina-de-cartao-de-credito-estao-obrigadas-a-entregar-a-efd-reinf/

Oi pessoal recentemente tenho recebido esse retorno do Reinf ao tentar enviar eventos, onde o retorno do webservice retorna nulo! Alguém já passou por algo parecido ? Desde ja agradeço a atenção!

Foi criado no dia 16/08/2022 tópico para correção do erro MS1010 ID inválido: ACBrReinf Evento R-1000 - Erro MS1010 ID inválido Conforme conversado com os consultores a correção estava certa e foi para o SVN: revision 27675 dia 06/12/2022 porem foi revertida no dia 26/12/2022 esse caso foi o mesmo do tópico: Reinf - MS1528 - O Grupo infoEFR não pode ser informado para natureza jurídica do contribuinte declarante Onde a correção aprovada subiu para o SVN dia 06/12/2022 e revertida 26/12/2022 Realizei as correções novamente, só que desta vez de uma forma diferente, ao invés de verificar se o Contribuinte é órgão publico foi verificado o tipo de documento CPF ou CNPJ, para ficar mais claro a condição. Na função que gera a chave foi adicionado o tipo de inscrição TpInsc function GerarChaveReinf(const emissao: TDateTime; const CNPJF: string; sequencial: Integer; --------> TpInsc: TtpInsc): String; desta forma em todas as units de cada evento (pcnReinfR1000.pas, pcnReinfR1050.pas, pcnReinfR1070.pas, pcnReinfR2010.pas, pcnReinfR2020.pas, pcnReinfR2030.pas, pcnReinfR2040.pas, pcnReinfR2050.pas, pcnReinfR2055.pas, pcnReinfR2060.pas, pcnReinfR2070.pas, pcnReinfR2098.pas, pcnReinfR2099.pas, pcnReinfR3010.pas, pcnReinfR4010.pas, pcnReinfR4020.pas, pcnReinfR4040.pas, pcnReinfR4080.pas, pcnReinfR4099.pas, pcnReinfR9000.pas) que usa a função foi alterada para passar o novo parâmetro GerarChaveReinf(now, self.ideContri.NrInsc, self.Sequencial, self.ideContri.TpInsc); e na função verificando esse tipo para definição de 1 ou 2 (Tipo de Inscrição do Contribuinte (1 - CNPJ; 2 - CPF)) if TpInsc = tiCNPJ then Result := Result + IntToStr(1) else Result := Result + IntToStr(2); Verificar viabilidade da correção. Obrigado. reinf.rar

Ao definir na propriedade TipoContribuinte o enum tcOrgaoPublico do evento R-1000 é gerado a tag infoEFR conforme código abaixo: procedure TevtInfoContri.GerarInfoEFR; begin if TACBrReinf(FACBrReinf).Configuracoes.Geral.TipoContribuinte in [tcOrgaoPublico] then begin Gerador.wGrupo('infoEFR'); Gerador.wCampo(tcStr, '', 'ideEFR', 1, 1, 1, SimNaoToStr(infoContribuinte.infoCadastro.infoEFR.ideEFR)); Gerador.wCampo(tcStr, '', 'cnpjEFR', 14, 14, 0, infoContribuinte.infoCadastro.infoEFR.cnpjEFR); Gerador.wGrupo('/infoEFR') end; end; porem na regra esta faltando outra verificação de acordo com o manual de resposta do webservice: MS1184 - O CNPJ do Ente Federativo Responsável é obrigatório se o Órgão Público {ideContri} não é o Ente Federativo Responsável e não pode ser informado caso contrário. O CNPJ informado deverá ser validado com a informação referente ao Ente Federativo Responsável (EFR) existente no cadastro do CNPJ da RFB. MS1185 - O grupo infoEFR é Obrigatório se a Natureza Jurídica = [102-3, 103-1, 105-8, 106-6, 108-2, 117-1, 118-0, 123-6, 124-4]. Não deverá ser informado nos demais casos. e conforme a mensagem adicionada no titulo: MS1528 - O Grupo infoEFR não pode ser informado para natureza jurídica do contribuinte declarante a tag não deveria ser informada por conta da validação da Natureza Jurídica. quem puder ajudar com alguma solução. Obrigado