Italo Giurizzato Junior

Bom dia, Muito obrigado pela colaboração, já esta no SVN.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Leandro, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia a todos, Uma dica: Se o provedor não responde os e-mail, ligações, etc. Pede para os seus clientes protocolarem uma reclamação junto a prefeitura relatando o problema ao consultar. Quanto mais contribuinte protocolarem a reclamação, mais rápido o problema vai ser resolvido, pois desta forma a prefeitura vai ficar sabendo que a coisa não esta funcionando como deveria.

Bom dia Renato, No momento temos disponível somente o componente ACBrNFSeX para quem utiliza o Delphi ou Lazarus. Já esta sendo desenvolvido a DLL ACBrLibNFSeX, mas não sei te precisar quando ela vai ficar pronta. Só depois da DLL pronta é que a Equipe ACBr vai avaliar se implementa a NFS-e no ACBrMonitor ou não.

Bom dia Leandro, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia Vilmondes, Que eu saiba para informar os valores referente o diferencial de alíquota ST é no grupo <ICMSUFDest>, que foi implementado no componente a um bom tempo. O que ocorreu recentemente foi a reativação de algumas regras de validação na SEFAZ. Essas regras já estão ativadas no ambiente de homologação e serão ativas em produção no dia 03/04/2023, conforme Nota Técnica 2022/005 versão 1.10

Boa tarde Matheus, Você esta configurando corretamente a pasta Schemas? Veja este tópico:

Ademar, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3568

Boa tarde a todos, Já esta no SVN as alterações realizadas tanto para atender a versão 2.1.1 quanto ao novo ambiente de recepção dos eventos que agora é uma API Rest. Favor atualizarem todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes. Foram feitas alterações nos programas exemplos (Delphi e Lazarus), eles trazem dicas de como obter o retorno tanto do envio quando das consultas.

Leandro, Já fiz a correção e enviei para o SVN. Favor atualizar os fontes, reinstalar o ACBr e faça novos testes.

Boa tarde Alex, Já esta no SVN.

Boa tarde Fabio, Notei que o provedor ISSNet esta migrando outras cidades para a versão 2.04, pois até então as outras cidades atendidas pelo provedor usavam a versão 1 do layout da ABRASF. Seria interessante que esse DANFSE que você propôs pudesse ser utilizado por qualquer cidade desse provedor.

Boa tarde Ademar, Não compreendi: "método IndexOfName e mesmo contendo o parâmetro ele retornava o contrário". Explique melhor esse: retornava o contrário, citando um exemplo.

Boa tarde Fabio, Analisando o novo schema que consta como realizar essa consulta e o que é retornado, notei o seguinte: É possível realizar vários tipos de consulta, por exemplo: pelo numero do Rps ou pelo numero da nota entre outras possíveis opções. Como retorno temos um lista com até 50 URLs que acredito seja a URL para acessar o DANFSE da nota em questão. Não sei até que ponto isso é util.

Boa tarde Bill, Não seria o caso de entrar em contato com o provedor e relatar essa situação? Pois no meu entendimento o provedor deveria retornar um erro acusando que o Rps consulta não existe em sua base de dados e não retornar um XML de uma nota com todas as tags vazias.

Leonard, Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Boa tarde Rodrigo, Favor atualizar os fones, reinstale o ACBr e faça novos testes.

Boa tarde Rogério, No arquivo ACBrNFSeXServicos.ini temos o seguinte: [3145208] Nome=Nova Serrana UF=MG Provedor=SigCorp Versao=2.03 ProRecepcionar=http://abrasfnovaserrana.sigbancos.com.br/servico.asmx HomRecepcionar=http://testeabrasfnovaserrana.sigbancos.com.br/servico.asmx Isso diz que a cidade utiliza o provedor SigCorp cujo webservice esta baseado na versão 2.03 do layout da ABRASF. E você propõe uma alteração na procedure de configuração da versão 2.04 Primeiramente, essa cidade migrou para a versão 2.04 como outras já migraram? Se sim, precisamos alterar o arquivo INI informando a versão correta e as URLs dessa nova versão. Você poderia verificar isso para nós?

Boa tarde Leandro, Qual é o valor da variável Codigo ao ler o conteúdo da tag <Erro> na linha abaixo? Codigo := ObterConteudoTag(ANodeArray[I].Childrens.FindAnyNs('Erro'), tcStr); Que se encontra na procedure: ProcessarMensagemErros

Boa tarde Leonard, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-3565

Boa tarde Claudio, Já esta no SVN.

Olá pessoal, Como temos anunciado a algum tempo, o REINF vem passando por um processo de mudanças, que envolve inclusive a tecnologia utilizada na recepção das informações por parte da receita. Chegada da versão 2.1.1 Nesta versão não foram somente mudanças de layouts ou inclusão de novos eventos, a versão 2.1.1 do REINF trouxe uma mudança na forma de envio e recepção dos eventos, passando a adotar a integração via API Rest e em modo assincrono. Apesar do documento descrevendo o funcionando ter sido publicado no inicio de 2022, NÃO havia até poucas semanas atrás, a definição de QUANDO tais mudanças entrariam em vigor. Sobre as datas Divulgação das Mudanças O Manual de orientação e ambientes de produção restrita (foram liberados no inicio de 2022, mas ainda havia indefinição de datas de inicio da vigência de tais mudanças Implantação Detalhamos melhor neste artigo, mas em resumo seriam: Fevereiro/2023 - Limite para aceitação dos eventos do layout 1.5.1 em produção restrita (Ambiente de Homologação) Março/2023 - Vigência do layout 2.2.1 para a competência de março/2023 Setembro/2023 - Envio da recepção dos eventos somente em forma Assíncrona Link do Manual do REINF Manual de Orientação ao Desenvolvedor da EFD-Reinf – Lote Assíncrono - Versão 1.00.00 (rfb.gov.br) Detalhando as Mudanças Muito bem, até a versão 1.5.1 o ambiente que recepcionava os eventos trabalhava no modo síncrono, isso significa que ao enviar um evento do Reinf o webservice processava e caso estivesse tudo correto já era retornado o resultado do processamento, caso contrario era retornado a lista de erros. A partir da versão 2.1.1 o ambiente que recepciona os eventos trabalha no modo assíncrono, isso significa que ao enviar um evento será retornado um numero de protocolo que usaremos em uma consulta para poder obter o resultado do processamento. Como vocês podem ver agora se faz necessário 2 passos para obter o resultado do processamento do evento enviado. Os fragmentos abaixo comprovam o que eu escrevi acima. Além do modo de envio passar a ser assíncrono a forma de comunicação também mudou, até a versão 1.5.1 tínhamos um ambiente baseado em WebService Soap, agora a partir da versão 2.1.1 teremos um ambiente baseado em API Rest conforme consta no fragmento abaixo. Estas informações foram extraídas na página do REINF A documentação sobre este assunto está um pouco "escondida" no portal do REINF, mas para aqueles que desejarem conhecer, clique aqui. http://sped.rfb.gov.br/projeto/show/1196 Sobre os componentes ACBr Acompanhe as atualizações deste assunto no artigo a seguir.

Boa tarde Igor, Você poderia anexar o XML de uma nota para que eu possa fazer um teste?