REINF - versão lote 1.04.00

[Jorge Lauand]

Prezados,

Ao executar a transmissão do REINF deparei com o seguinte erro no retorno : MS00092 Versão do lote inválida. Deve ser utilizada a versão 1.04.00.

Como devo proceder, já fiz a atualização pelo composer ?

Grato pela orientação

Jorge Lauand

[Roberto Machado]

Ainda não temos as versões atualizadas para 1.04 !!

Está em andamento !

Roberto

[Roberto Machado]

Atualizei alguns eventos da versão 1.04 MAS NÃO TODOS

Faltam ainda o 5001 e o 5011

Roberto

[Jorge Lauand]

Caro Roberto,

Muito obrigado pela sua pronta atualização. Com o que fez já resolveu meus problemas.

Atenciosamente,

Jorge Lauand

[Fábio Ananias]

Boa tarde pessoal.

Estou com uma certa dificuldade em perceber meu erro na validação do arquivo do REINF.
Estou tendo o erro: This XML is not valid. Element '{http://www.reinf.esocial.gov.br/schemas/evtInfoContri/v1_04_00}Reinf': No matching global declaration available for the validation root. 

Eu não uso as classes de criação do XML do projeto. Uso apenas apartir da assinatura, validação, transmissão, etc. (Faço o mesmo no eSocial, e lá obtive exito).

Em anexo está uma "versão reduzida" do meu código onde acredito que esteja meu erro. Será que alguém consegue percebê-lo, ou ao menos me indicar a forma certa de assinar o XML sem usar as estancias da Factory?]

Obrigado.

--
--
Você recebeu esta mensagem porque está inscrito no Grupo "NFePHP".
Para Postar: nfe...@googlegroups.com
Para Sair do Grupo: nfephp+un...@googlegroups.com
Link: http://groups.google.com.br/group/nfephp?hl=pt-BR
-------
Repositórios: https://github.com/nfephp-org
---
Você recebeu essa mensagem porque está inscrito no grupo "NFePHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para nfephp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Fábio Ananias]

A quem possa interessar, acabei descobrindo aqui meu erro BEM BÁSICO. (não deve ocorrer com quem usa a API para montar o XML):

No xml anterior eu estava usando o nome da TAG principal do XML para montar o NAMESPACE. Mas assim como os XSDs disponibilizados pelo REINF, os namespaces também tem nomes diferentes das TAGs principais:

Anterior(incorreto):
http://www.reinf.esocial.gov.br/schemas/evtInfoContri/v1_04_00  
Atual(correto):

http://www.reinf.esocial.gov.br/schemas/evtInfoContribuinte/v1_04_00  

Outro detalhe alterado (que não causava o erro em questão) é o atributo "id" que estava como "Id" ("i" minúsculo é o correto).

Obrigado.

[Higor Morbini]

A nível de atualizações da versão 1.4, foi disponibilizado ontem (12/12/2018) a nova versão do Manual de Orientação ao Desenvolvedor da EFD-Reinf - Versão 1.4. 

Segue abaixou o que foi publicado, assim como o link de acesso da publicação http://sped.rfb.gov.br/pagina/show/2898 (acessado em 13/12/2018).

Publicado em 12/12/2018

Foi disponibilizado a versão 1.4 do Manual de Orientação ao Desenvolvedor da EFD-Reinf.

A novidade desta versão são os novos WebServices de consulta de informações dos eventos enviados para o ambiente da EFD-REINF, incluindo o número do recibo de entrega.

Essas consultas serão disponibilizadas em breve nos ambientes de produção e produção restrita da EFD-REINF

Para ter acesso, clique aqui

Atenciosamente,
Higor Morbini.

[Roberto Machado]

Opa !  Valeu Higor !! assim que der vou ler e atualizar o repositório.

Grande ajuda !

Abraço

Roberto

[Higor Morbini]

Boa tarde,,

A nível de atualizações da versão 1.4, foi disponibilizado no dia 15/01/2019, a nova URL Web Service para a consulta do evento de totalizações.
Segue a publicação, assim como o link de acesso da publicação http://sped.rfb.gov.br/pagina/show/2946 (acessado em 24/01/2019).

Publicado em 15/01/2019

A partir de hoje, 15/01/2019, o Web Service para consulta do evento de totalizações com o resultado do processamento do fechamento, deverá ser acessado através de novos endereços.

A partir de hoje, 15/01/2019, o Web Service para consulta do evento de totalizações com o resultado do processamento do fechamento, deverá ser acessado através dos endereços abaixo:

Ambiente de Produção: https://reinf.receita.fazenda.gov.br/WsReinfConsultas/ConsultasReinf.svc

Ambiente de Produção Restrita:https://preprodefdreinf.receita.fazenda.gov.br/WsReinfConsultas/ConsultasReinf.svc

A URL que está sendo usada atualmente ficará disponível temporariamente até 03/02/2019. Sendo assim, a partir de 04/02/2019 a URL antiga será desativada e as consultas somente poderão ser utilizadas através dos endereços acima.

Atenciosamente,

Higor Morbini 

[Roberto Machado]

Oi Igor esses endereços já foram atualizados no repositório (branch master) 

Roberto

--

--
Você recebeu esta mensagem porque está inscrito no Grupo "NFePHP".
Para Postar: nfe...@googlegroups.com
Para Sair do Grupo: nfephp+un...@googlegroups.com
Link: http://groups.google.com.br/group/nfephp?hl=pt-BR
-------
Repositórios: https://github.com/nfephp-org
---
Você recebeu essa mensagem porque está inscrito no grupo "NFePHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para nfephp+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

--

Roberto

Nisi utile est quod facimus stulta est gloriae (Julius Phaedous)

[Higor Morbini]

Roberto,

Perfeito, ainda não realizei as atualizações no meu projeto, pois retornei de férias ontem e somente hoje consegui me inteirar sobre os destaques no portal do SPED. Irei conferir o repositório e realizar as devidas atualizações.

Grato pela atenção.

Higor.

[Higor Morbini]

Boa tarde,

Estou testando o evento da Consulta Consolidada conforme os exemplos na pasta Fake, porém me surgiram algumas dúvidas, e problemas.

Estou testando já na transmissão para a produção restrita.

Segue abaixo o trecho do código conforme o exemplo, 

//Consolidada 
$std = new stdClass();
$std->numeroprotocolofechamento = $nrProtocolo;
$std->tipoinscricaocontribuinte = 1;
$std->numeroinscricaocontribuinte = '92017516';
$response = $tools->consultar($tools::CONSULTA_CONSOLIDADA, $std);

Minha dúvida, esta relacionada ao campo $std->tipoinscricaocontribuinte, o mesmo deve/pode seguir as informações passadas na variável $config, respeitando os valores atribuídos ao contribuinte, como o tpInsc e nrInsc? 

Ao executar minha aplicação o mesmo retorna erro de validação: "numeroinscricaocontribuinte contêm um valor invalido [92017516]."

Executei os testes informando o $std->tipoinscricaocontribuinte com os valores 1 ou 2, e a mensagem de erro é a mesma informada acima.

Tentei informar junto com o raiz base, porém ele retorna o aviso do WS ERRO1MS0009.

Não sei se meus procedimentos estão corretos, ou falta alguma configuração a mais a ser ajustada. 

Se possível alguma orientação para dar prosseguimento aos testes. 

Grato.

Higor.

[Roberto Machado]

Higor;

O manual não é claro se deve ser um numero de CNPJ reduzido ou completo !

A API espera o completo ou seja o CNPJ com 14 digitos ou um CPF com 11 digitos

No caso de outras consultas como R1000 ou R1070 a API coleta esses dados diretamente do config. Pois nesses casos está claro que o campo terá 8 posições, por exemplo.

Mas sua colocação foi boa e revendo alguns dados, fiz algumas complementações no código dessas consultas.

Roberto

[Higor Morbini]

Boa tarde Roberto,

Grato pelas complementações.

Venho novamente relatar alguns problemas que foram aparecendo ao realizar alguns testes na transmissão dos eventos para o SPED.
Vamos ao levantamento das dúvidas e questionamentos:

1. Evento de Consulta Consolidada
• Ao realizar o procedimento da consulta, o evento R2099 retorna a inconsistência MS1074 -  Foram enviados eventos R-2070 - Retenções na Fonte (IR,CSLL,Cofins,PIS/PASEB) - Pagamento diversos no período de apuração informado ou o período de apuração é superior a 2018-10.
  Após analisar a documentação do SPED e revisar os códigos, dos quais eu havia já realizado alguns testes com sucesso no final de 2018, antes da disponibilização do manual de orientação ao desenvolvedor versão 1.4, encontrei a seguinte orientação em um portal com relação a mensagem de erro MS1074.
  Para corrigir, as empresas deverão reenviar o evento R-2099 conforme consta na validação do leiaute, sem preencher o campo evtPagtos no evento R-2099 para competências a partir de 10.2018.
  Para isso realizei alguns testes, aonde passei a variável $std->evtpgtos = 'N', $std->evtpgtos = '' aonde passando os valores o mesmo dava a mensagem de erro MS1074 ou obrigava a informar um valor [S|N], também tentei comentar o trecho do $std->evtpgtos, não informando o campo e retornou erro na validação da API.
  Realizando mais alguns testes, realizei a seguinte alteração no ..\src\Factories\EvtFechaEvPer.php
  Aonde tínhamos para o campo evtpgtos: 
  
     $this->dom->addChild($infoFech, "evtPgtos", $this->std->evtpgtos, true);
  Alterei o código fazendo a validação se o campo é preenchido ou não, ficando igual ao campo comSemMovto, conforme abaixo:
  
     $this->dom->addChild($infoFech, "evtPgtos", !empty($this->std->evtpgtos) ? $this->std->evtpgtos : null, false);
  
  
  
2. Evento Consulta R2010
• Ao realizar o procedimento da consulta, o evento R2010, seguindo os exemplos disponibilizados na pasta FAKE, ao tentar realizar a consulta em produção restrita, comunicando com o WS do SPED o mesmo me retorna a seguinte mensagem de erro: 
  
  An error occurred while trying to communication via soap, [https://preprodefdreinf.receita.fazenda.gov.br/WsReinfConsultas/ConsultasReinf.svc] HTTP Error code: 500 - The message with Action 'http://sped.fazenda.gov.br//ConsultasReinf/ConsultaReciboEvento2010' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
  
  Neste caso da consulta ao evento R2010, não sei se meus procedimentos estão corretos, ou falta alguma configuração a mais a ser ajustada. 

• Se possível alguma orientação para dar prosseguimento aos testes. 
  
  

Grato pela atenção.
Higor 

[Higor Morbini]

Boa tarde,

Referente ao questionamento do item 2, do qual fiz o levantamento, segue abaixo a correção para poder realizar a consulta do evento R-2010.

Em ..\src\Tools.php na function consultR2010 a variável está

$this->action = "{$this->namespace}/ConsultasReinf/{$this->method}";

Aonde o correto para realizar a consulta é

$this->action = "{$this->namespace}ConsultasReinf/{$this->method}";

O erro citado, era ocasionado por uma barra a mais na construção da url de ação.

Grato.

[Roberto Machado]

Eita !!! BUG !!!

Corrigindo 

Muito obrigado pela AJUDA, se quiser colaborar mais com código me avise !

É útil ter alguém que pelo menos investiga o problema e acha a "caca" !

Abraço 😀

Roberto

[Fábio Ananias]

Boa tarde Pessoal,

alguém pode me dar uma luz sobre como consulto o resultado de lote em processamento no REINF?

Já dei uma olhada nas classes e no manual e não consegui me esclarecer. 

Quando eu faço o envio de um evento e ele já é processado na mesma conexão, me retornando o status do processamento e número de recibo já está tudo certo para mim.

O problema é quando recebo um retorno dizendo que o lote ainda não foi processado.

Por exemplo neste retorno do R-2099:

Como eu faço para consultar se este lote foi processado com sucesso?

Há algum método como há no eSocial em que eu passe esse protocolo de entrega para ele me devolver o retorno do processamento, com recibo e tudo mais?

Fiz a consulta abaixo mas acredito que estas consultas sejam pra outra coisa, certo? Ou devido à situação do EVENTO com o mesmo ID do retorno acima estar = 1 (ativo) eu devo considerar que o REINF o aceitou e guardar o número do recibo indicado? (acredito que não seja isso..)

Consulta:

$std = new stdClass();

$std->perapur = 2019-04;
$response = $tools->consultar($tools::CONSULTA_R2099, $std);

Desde já, muito obrigado.

[Fábio Ananias]

Desculpem... acabei de perguntar e encontrei algo que talvez seja a resposta... Só me confirmem se é isso mesmo por favor.. mas de qualquer forma eu vou tentar:

No trecho abaixo do manual diz para "retransmitir o mesmo lote ou evento novamente".

Nesse caso eu preciso mandar novamente o mesmo arquivo e ele entenderá que é para me devolver o retorno do lote enviado anteriormente?

Onde eles escrevem que "a instituição receberá um retorno do tipo Protocolo que deverá ser utilizado posteriormente na consulta" é que me confunde... 😓

[Roberto Machado]

Fabio;

Acredito que essa seja a forma correta !

Tanto no eFinanceira, como no eSocial e acredito que no REINF caso não tenha sido retornado o recibo, eles pendem para que seja novamente enviado o mesmo evento.

A resposta será uma REJEIÇÃO por duplicidade caso o evento original tenha sido aceito e nessa resposta deve retornar o RECIBO do envio anterior.

Roberto

[Fábio Ananias]

Muito obrigado pelo retorno Roberto.

Fiquei com medo de estar interpretando errado...

É só eu que acho que eles fizeram "caca" nesse procedimento... mais alguém pensa assim?

Pelo seguinte:

1- Eles pedem um tempo tão grande para uma nova consulta do resultado do R-2099, acredito que para tentar garantir o retorno do processamento.

    Mas e se depois de 5 minutos o lote ainda não estiver processado? Não parece haver no manual a especificação de um retorno de "Lote em processamento" novamente.

2- E se o lote entrou para processamento e durante o processamento do lote houver algum erro que impeça o fechamento?

    Onde eles me retornarão o código do erro e a mensagem do erro? Também parece não estar previsto algo assim.

Por favor me corrijam se eu estiver errado =)

Bom.. vamos trabalhando com as ferramentas que nos dão...

Obrigado mais uma vez.

trecho que trata da minha duvida do email anterior, a quem possa vir a interessar:

--
--
Você recebeu esta mensagem porque está inscrito no Grupo "NFePHP".
Para Postar: nfe...@googlegroups.com
Para Sair do Grupo: nfephp+un...@googlegroups.com
Link: http://groups.google.com.br/group/nfephp?hl=pt-BR
-------
Repositórios: https://github.com/nfephp-org
---
Você recebeu essa mensagem porque está inscrito no grupo "NFePHP" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para nfephp+un...@googlegroups.com.

Para ver essa discussão na Web, acesse https://groups.google.com/d/msgid/nfephp/CAEj7DHn0rCY85ghQ8-NmVTK02Cq7-46mq-JGSoiCYQ8HWCHGpQ%40mail.gmail.com.

[Roberto Machado]

Fabio;

Esses cara fizeram o mesmo em vários projetos, claro que isso não está CLARAMENTE documentado, muitas coisas só sabemos quando acontecem e vamos procurar uma explicação sobre o ocorrido.

Quanto mais empresas são obrigadas a atender essas OBRIGAÇÕES acessórias, mais congestionados ficam os servidores, então ocorrem PICOS de requisições que eles não dão conta então fazem esse "LOTE EM PROCESSAMENTO".

Eles não usam um cloud Amazon, com escalabilidade por carga, mas mesmo se usassem esse  tipo de ocorrência ainda seria  notada, pois o aumento de processamento é reativo e não pre ativo.

Dito isso, vamos ajustando os sistemas para lidar com isso.

Roberto