Luis Lambranho

Concordo, realmente é preocupante. Eu oriento nossos clientes aqui a consultarem de 30 em 30 minutos a situação. Ontem esse problema ocorreu por volta de 14hs e a cliente só conseguiu o sucesso quase lá pelas 18hs.

Bom dia, pessoal. Percebi nos últimos meses que sempre que está chegando próximo do dia 15 ocorrem essas situações. Não chega a ser um problema, pois é uma situação prevista na documentação (afinal é um evento assíncrono), mas o cliente sempre fica apreensivo. Ontem tivemos um caso desses e no fim do dia a cliente conseguiu obter o status de transmitido com sucesso. Enquanto eles não estabilizarem eu creio que o que nos resta é orientar e acalmar o cliente. Dos nossos clientes aqui nenhum ficou sem entregar dentro do prazo por essa situação até agora.

Agora pela manhã nossos clientes conseguiram consultar a situação e obter o TRANSMITIDO no fechamento.

Boa tarde a todos. Estamos com o mesmo problema em nossos clientes. Alguém já conseguiu retorno como transmitido no fechamento nesses últimos dias?

Depende do seu contrato com o cliente. Aqui nós temos contratos em que o cliente tem todas as atualizações do SPED e outros em que é vendido a parte. Agora, se o seu sistema tem ou não as informações pra gerar, aí é outra história....

Boa noite, Italo. Tem sim e você tem razão. Estou postando novamente, creio que agora esteja de acordo. Qualquer coisa só falar que ajusto novamente. Segue: pcnReinfR1070.pas

Boa noite, Senhores. Comecei recentemente a revisão do nosso sistema para a versão 1.4 da Reinf e até o momento consegui transmitir R1000, R2010, R2020 e R2099 sem precisar alterar nada no componente. Alterei apenas um campo no banco referente ao idVara do R1070. E é justamente por conta do idVara que precisei alterar um fonte do componente. Segue a unit para validação. Mudei apenas a chamada da Poem_Zeros para compor 4 dígitos na linha 371. Gerador.wCampo(tcStr, '', 'idVara', 2, 2, 1, Poem_Zeros(FinfoProcesso.IdeProcesso.DadosProcJud.idVara, 4)); pcnReinfR1070.pas

http://sped.rfb.gov.br/pagina/show/2807

Então... Pelo que consta aqui (https://portalspedbrasil.com.br/forum/efd-reinf-aprovado-o-leiaute-1-4-ato-declaratorio-executivo-no-64-de-6-de-setembro-de-2018/) o novo layout será exigido já a partir da competências de setembro deste ano. Mesmo não sendo grandes mudanças, me parece pouco tempo. Ainda mais que nem publicaram os schemas ainda.

Segue: http://sped.rfb.gov.br/pagina/show/2782 A princípio o evento R-2070 deixa de existir.

Resolvido! Estava passando errado o indicador de CPRB.

Bom dia, senhores. Um dos nossos clientes está tendo erro abaixo ao enviar um evento R-2010 com processos vinculados. Alguém aqui já passou por isso? Acredito que as informações estão informadas corretamente, sendo que no R-1000 o cliente é CPRB=0: <ideRecRetorno> <ideStatus> <cdRetorno>1</cdRetorno> <descRetorno>ERRO</descRetorno> <regOcorrs> <tpOcorr>1</tpOcorr> <localErroAviso>Registro: infoTpServ - XPATH: /Reinf/evtServTom/infoServTom/ideEstabObra/idePrestServ/nfs/infoTpServ</localErroAviso> <codResp>MS1051</codResp> <dscResp>O valor informado não pode ser superior ao valor da retenção (11% da base de cálculo ou 3,5% da base de cálculo (para Contribuinte da Contribuição Previdenciária sobre a Receita Bruta), deduzido o valor da retenção destacada na nota fiscal relativo aos serviços subcontratados).</dscResp> </regOcorrs> </ideStatus> </ideRecRetorno> Seguem também os xmls de envio e retorno. ID1005474370000002018072009375993647_envio.xml D1005474370000002018072009375993647_retorno.xml Obrigado.

Boa tarde, Diogo. Você atualizou o repositório e reinstalou o ACBr? O Italo disponibilizou a alteração do numeroReciboFechamento para numeroProtocoloFechamento ontem. É justamente o que corrige esse problema.

Bom dia, pessoal. Alterei a ACBrReinfWebServices para utilizar o novo parâmetro. Segue para inclusão no svn. ACBrReinfWebServices.pas

No meu caso foi um R-2010. E sim, continuou retornando o erro dizendo que já existia informações pro período.

Boa tarde a todos. Vejo duas situações: 1. Entrega de eventos periódicos (R-2010,R-2020, R-2050, R-2060) com extravio de recibo; 2. Entrega de evento de fechamento (R-2099). Essa solução: funcionaria nos dois casos? Com R-2010 não consegui.

Também já registrei lá.

Tenho aqui uma situação que não tinha encontrado: O cliente inicialmente enviou um R2010, mas tinha notas lançadas erradas e deu divergência no valor da retenção Campo: vlrTotalRetPrinc - XPATH: /Reinf/evtServTom/infoServTom/ideEstabObra/idePrestServ/vlrTotalRetPrinc Código......: MS1032 Descrição...: O valor informado deve corresponder a soma do valor da retenção das notas fiscais de serviço emitidas para o contratante menos a soma do valor da retenção destacada na(s) nota(s) fiscal(ais), relativo aos serviços subcontratados, se houver. Depois tentamos enviar novamente (outro id evento) e ele deu a mensagem de que já existem dados lá: Registro: evtServTom - XPATH: /Reinf/evtServTom Código......: MS1028 Descrição...: Não é permitido o envio de mais de um evento para o mesmo contribuinte, num mesmo período de apuração para um mesmo estabelecimento e prestador, exceto se for para retificação de um evento enviado anteriormente ou se o evento anterior tiver sido excluído Aí tentei reenviar o arquivo pra ver se retornava o recibo, mas não retorna. Nem com o primeiro nem com o segundo. Alguma sugestão?

Boa! No meu caso como foi R1000 eu consegui excluir sem o número de recibo. Nos R20... vou usar essa técnica.

Senhores, Alguns dos nossos clientes tiveram problemas no envio pro ambiente de produção. Em um deles ontem fizemos todo o envio, mas depois de fechar o período (R2099) não conseguimos ter o status através da consulta situação. A ultima situação foi "em processamento" retornado no R2099. Aí hoje pela manhã consultamos e deu tudo certo. Agora em outro cliente não estou conseguindo nem enviar o R1000. Dá time out já de cara. Mais alguém passando por isso? Será que tá congestionado mesmo ou instável o ambiente de produção? Obrigado!

hahaha.... exatamente o que aconteceu comigo.

Legal, Italo. Obrigado!

Maravilha... segue a unit pcnReinfRetEventos.pas

Boa noite, Italo. Depois de uma semana agitada consegui parar para fazer mais testes. Creio que os memory leaks estavam ocorrendo por conta desse overload. Da forma como está hoje não passava no TeventoCollectionItem.destroy. Mudei para override (adicionando o inherited no corpo do método pra executar a definição ancestral) e não houve mais problemas de vazamento de memória, ao menos até onde consegui identificar. Não sei se essa seria a melhor saída, pois não conheço tão bem os fontes como você. Portanto, coloco aqui pra tentar ajudar na melhoria do componente.

Sem problemas, Italo... eu estou estudando os fontes na medida em que as demandas me permitem e se conseguir alguma solução posto no fórum pra ajudar também. Obrigado!