Silvair L Soares

Além deste problema da NFC-e. Existe um outro problema que afeta a NF-e, que é o fato de as notas autorizadas, não serem retornadas quando se tenta fazer uma consulta, ou registrar algum evento (Cancelamento ou carta de correção). Ao tentar registar estes eventos, em uma NF-e autorizada, está dando as rejeições. Carta de correção: Rejeição 494: Chave de Acesso inexistente Cancelamento: Rejeição 217: NF-e não consta na base de dados da SEFAZ Ao pesquisar as chaves de acesso no site ambiente nacional (https://hom.nfe.fazenda.gov.br/portal/consultaRecaptcha.aspx), está gerando a resposta: "NF-e INEXISTENTE na base nacional, favor consultar esta NF-e no site da SEFAZ de origem." Ou seja, a SEFAZ GO, nem está repassando as notas para o ambiente nacional de homologação. Aparentemente existe um problema bem grave acontecendo por lá. Pois enviei um e-mail reclamando destes problemas no dia 10/08/2023 (neste dia, o problema já estava ocorrendo há uns 4 dias) e até hoje (15/08/2023), não recebi nenhuma resposta deles. Obs.: Não utilizamos o componente da ACBR.

Boa tarde a todos. Era problema no ambiente da prefeitura, o qual já foi resolvido. Conseguimos voltar a emitir normalmente. Obs.: Não usamos o componente ACBrNFSe.

Informei os endereços incorretamente, na resposta anterior. Os corretos são: Anterior Homologação: https://www.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx Produção: https://www.issnetonline.com.br/webserviceabrasf/aparecidadegoiania/servicos.asmx Atual Homologação: https://abrasf.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx Produção: https://abrasf.issnetonline.com.br/webserviceabrasf/aparecidadegoiania/servicos.asmx

Boa tarde a todos. Não utilizo o ACBR, temos a nossa própria integração com os webservices aqui na empresa e passamos pelos mesmos problemas, desde o dia de 29/03/2023. Em contato com suporte do ambiente autorizador da prefeitura, fomos informados que: Mas na prática, o que identificamos, foi um retorno de código http 301 (Movido Permanentemente), indicando que o serviço foi removido permanentemente da url que estávamos utilizando anteriormente. Usando o SoapUI em conjunto com o Fiddler, constatamos que a url que recebe as notas fiscais, foi modificada. Abaixo a relação de urls anteriores e as atuais: Anterior H.: https://www.issnetonline.com.br/webserviceabrasf/homologacao/servicos.asmx Anterior P.: https://www.issnetonline.com.br/webserviceabrasf/servicos.asmx Atual H.: https://abrasf.issnetonline.com.br/webserviceabrasf/homologacao/aparecidadegoiania/servicos.asmx Atual P.: https://abrasf.issnetonline.com.br/webserviceabrasf/aparecidadegoiania/servicos.asmx No nosso caso, não fizemos a migração do ambiente (1.0 para 2.04), apenas a substituição das urls antigas pelas novas, solucionou o problema. Por enquanto. Vou deixar aqui registrado, para ajudar algum colega que também não utilize o ACBR e que, por ventura, caia neste post futuramente.

Muito obrigado. Não tinha me atentado para esta nova versão da NT. Vamos aguardar e companhar os próximos capítulos.

Boa tarde pessoal. Estou implementando o evento: Ator Interessado na NF-e – Transportador no software aqui da empresa. Não utilizo os componentes ACBR, mas estou sempre por aqui, contribuindo ou sendo ajudado por esta comunidade. Estou utilizando como base, a Nota Técnica 2020.007. Esta nota técnica, prevê a seguinte mensagem de entrada: Estou enviando a seguinte mensagem de entrada XML Enviado.xml Para o webservice de homologação: https://hom1.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx E recebo a seguinte resposta: XML Recebido.xml Algum colega já passou por este mesmo problema?

Para o pessoal que precisar fazer este arredondamento usando c#, segue o método, já com testes usando Xunit: using System; using Xunit; namespace XUnitTestProject1 { public class ArredondamentoTest { [Theory] [InlineData(0.342, 0.34)] [InlineData(0.346, 0.35)] [InlineData(0.3452, 0.35)] [InlineData(0.3450, 0.34)] [InlineData(0.332, 0.33)] [InlineData(0.336, 0.34)] [InlineData(0.3352, 0.34)] [InlineData(0.3350, 0.34)] [InlineData(0.3050, 0.30)] [InlineData(0.3150, 0.32)] public void TestRoundAbnt5891(decimal valorOriginal, decimal arredondadoEsperado) { decimal arredondadoMetodoABNT = RoundAbnt5891(valorOriginal, 2); Assert.Equal(arredondadoEsperado, arredondadoMetodoABNT); } /// <summary> /// Método de arredondamento "round-half-even" /// Ou "arredondamento do banqueiro" /// </summary> /// <param name="value"></param> /// <param name="digits"></param> /// <returns></returns> private decimal RoundAbnt5891(decimal value, int digits) { return Math.Round(value, digits, MidpointRounding.ToEven); } } }

Italo não uso o ACBrNFe, mas estou acompanhando (gostando bastante) e contribuindo com esta discussão pois estou passando pelo mesmo problema no software desenvolvido pela nossa empresa. O grande problema (pelo menos nosso caso) é ter que atualizar centenas de clientes de um dia para o outro (28/04/19 para 29/04/19). Pois até dia 28/04/19 a tag "vICMSSubstituto" não é aceita e exatamente no dia 29/04/19 se torna obrigatória. Se tivéssemos a garantia que as Sefaz cumprirão à risca o cronograma de implantação, poderíamos verificar a data corrente para utilizar automaticamente o shema novo. Mas, pelo menos no caso de Goiás, não cumpriram o cronograma de implantação no ambiente de homologação. Então já não podemos ter certeza que cumprirão para o ambiente de produção.

Aqui vão meus dois centavos para a discussão. Não utilizo o ACBr. Mas estou enfrentando este mesmo problema aqui em Goiás. A Nota Técnica 2018.005 Versão 1.10 define o seguinte cronograma de implantação, para a geração tas tags infRespTec (opcional) e vICMSSubstituto (obrigatório nos grupos ICMS60 e ICMSSN500): Implantação Teste: 25/02/2019 Implantação Produção: 29/04/2019 Então lá fomos nós, felizes da vida e criamos estas tags em nosso sistema. Ao tentar enviá-las em ambiente de homologação (no dia 12/04/19, 15 dias após o previsto na NT) fomos surpreendidos por uma falha no shema. Ao validar no Validador de Mensagens do Projeto NF-e, obtivemos as seguintes falhas: Então, enviamos um e-mail para a Sefaz de Goiás, informando do problema no ambiente autorização em homologação, e outro e-mail para a Sefaz do Rio Grande do Sul, informando do problema no validador online de testes. A Sefaz do RS, nos respondeu, informando que o validador online só será atualizado em abril, mas que o ambiente de autorização já estava atualizado para a Nota Técnica 2018.005 Versão 1.10. Fiz um teste transmitindo a tal NF-e para o SVC-RS e realmente estão aceitando as tags infRespTec e vICMSSubstituto. Após algumas trocas de e-mail com a Sefaz de Goiás, o pessoal da Sefaz atualizou o ambiente homologador (15 dias após o previsto na NT) e agora estão aceitando, apenas em homologação as tags infRespTec e vICMSSubstituto. As opções que vislumbramos foram: 1º - Não incluimos a tag <vICMSSubstituto> E caso no dia 29/04/2019 a Sefaz de Goiás, passe a exigi-la em produção, assim como determina a NT 2018.005 v1.10, todos os nossos clientes terão seu faturamento interrompido. 2º - Incluimos a tag <vICMSSubstituto> E caso no dia 29/04/2019 a Sefaz de Goiás, continue a não aceitá-la em produção, todos os nossos clientes terão seu faturamento interrompido. Ou seja, teremos problemas de qualquer forma. Diante de toda esta confusão, provavelmente criaremos um parâmetro de configuração, para habilitar (em tempo de execução) a criação ou não, das benditas tags

Conseguimos resolver o problema atualizando a versão do Dot.Net Framework para a 4.5 (a versão 4.0 que utilizávamos não suporta TLS 1.2) e setamos (via Vb.Net) o TLS para 1.2 com o seguinte comando: ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

Bom dia pessoal. Estamos fazendo a atualização de nosso sistema para emissão da NF-e 4.0 aqui no estado de Goiás. Porém não estamos conseguindo estabelecer a comunicação com nenhum dos webservices disponibilizados pelo estado de Goiás. NfeInutilizacao 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeInutilizacao4?wsdl NfeConsultaProtocolo 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeConsultaProtocolo4?wsdl NfeStatusServico 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeStatusServico4?wsdl NfeConsultaCadastro 4.00 https://homolog.sefaz.go.gov.br/nfe/services/CadConsultaCadastro4?wsdl RecepcaoEvento 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeRecepcaoEvento4?wsdl NFeAutorizacao 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeAutorizacao4?wsdl NFeRetAutorizacao 4.00 https://homolog.sefaz.go.gov.br/nfe/services/NFeRetAutorizacao4?wsdl Ao tentarmos qualquer tipo de comunicação, recebemos o erro "The request failed with HTTP status 495: Unknown Code". Stack Trace at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at NFeStatusServico4.NFeStatusServico4.nfeStatusServicoNF(XmlNode nfeDadosMsg) in C:\Users\henriquerg\source\Workspaces\MSTIDOT\MSTIDOT\Sefaz\WebServices\4.0\NFeStatusServico4.vb:line 80 at MSTIDOT.Sefaz.NFE.ConsStatServ(XmlDocument XML, String URLWebService, X509Certificate2 Certificate) in C:\Users\henriquerg\source\Workspaces\MSTIDOT\MSTIDOT\Sefaz\NFE.vb:line 1033 at MSTIDOT.Sefaz.NFE.CONSULTASTATUSSERVICO() in C:\Users\henriquerg\source\Workspaces\MSTIDOT\MSTIDOT\Sefaz\NFE.vb:line 1110 at frmTeste.btnNFEStatus_Click(Object sender, EventArgs e) in C:\Users\henriquerg\source\Workspaces\MSTIDOT\MSTIDOT\frmTeste.vb:line 204 at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg) at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData) at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context) at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context) at frmTeste.Main() O mais estranho, é que, se alterarmos os endereços dos webservices para o SVC-RS, a comunicação ocorre sem problemas. Também fizemos testes utilizando os webservices de outros estados e a comunicação também ocorre normalmente (obviamente nestes último caso, recebemos a "Rejeição: Código da UF informada diverge da UF solicitada") Gostaria de saber se algum colega, já passou por este problema no ambiente autorizador do Estado de Goiás, ou em algum outro estado, e o que foi feito para solucioná-lo. Qualquer dica será muito bem vinda. Silvair L. Soares EVIDÊNCIAS DE ERRO NA COMUNICAÇÃO COM WS SEFAZ GO.pdf