Silvair L Soares
-
Total de ítens
11 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Silvair L Soares
-
-
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.
-
2
-
-
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.asmxAtual
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:
QuoteInformamos que os processamentos estão sendo realizados normalmente.
Importante:Todos os envios via integração precisam ter um cabeçalho com o "User agent" da solicitação, para que consiga comunicar com o webservice. Não se trata da estrutura do SOAP do XML, mas sim da requisição HTTP, ou seja, ao enviar um pacote de comunicação via HTTP, este pacote deve ter sua identificação para que não seja bloqueado.
Verificamos que muitos envios estão sendo feitos com requisições anônimas.
Anteriormente, era aceito envios com o User Agent anônimo.
Por questões de segurança, seguindo a LGPD (Lei nº 13.709/2018), passamos a validar somente as requisições com cabeçalho válido, ou seja, precisa conter os dados do User Agent.
Exemplo de sintaxe: User-Agent: <product> / <product-version> <comment>
Caso o erro persista, por favor, encaminhar os dados da empresa e um print do erro.
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.asmxAtual H.: https://abrasf.issnetonline.com.br/webserviceabrasf/homologacao/aparecidadegoiania/servicos.asmx
Atual P.: https://abrasf.issnetonline.com.br/webserviceabrasf/aparecidadegoiania/servicos.asmxNo 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.
-
10 hours ago, Renato Rubinho said:
Boa noite,
Não entrou em homologação ainda.
O Daniel falou sobre isso no vídeo de hoje, veja abaixo.
Acompanhe este outro tópico, também citado no vídeo, para maiores informações.
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
Para o webservice de homologação:
https://hom1.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx E recebo a seguinte resposta:
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); } } }
-
1
-
1
-
-
On 3/6/2019 at 6:08 PM, Italo Jurisato Junior said:
Boa tarde Pedro,
Não vejo necessidade de criar uma propriedade de configuração por conta de uma tag obrigatória que já é para ser aceita em ambiente de homologação e não esta sendo aceita em ambiente de produção.
Eu comentaria a linha que gera essa tag e usuária os Schemas que não contem essa tag.
A partir de 29/04/2019, removeria o comentário das linhas para que a tag seja gerada.
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/2019Entã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
NFC-e SEFAZ-GO validando incorretamente os CSC
em NFC-e - Nota Fiscal do Consumidor Eletrônica
Postado · Editado por 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 SEFAZAo 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.