Silvair L Soares

Até o dia de hoje (12/01/26) nem o webservice de homologação (https://nfse.issnetonline.com.br/wsnfsenacional/homologacao/nfse.asmx) está funcionando ainda. Por enquanto, só está funcionando o serviço de validação de schemas: Lembrando que a prefeitura (no comunicado) se compromente a manter o sistema atual, somente até dia 31/01/2026. Oremos.

Estes que você postou, são exemplos de XML a serem enviados para os respectivos serviços, não são os endereços dos webservice. Pelo menos por enquanto (com o modelo ABRASF 2.04), os endereços do webservice de Goiânia, são: Homologação: https://www.issnetonline.com.br/homologaabrasf/webservicenfse204/nfse.asmx Produção: https://nfse.issnetonline.com.br/abrasf204/goiania/nfse.asmx Como no novo manual, eles não falam nada sobre um possível novo endereço de webservice, deve permanecer o mesmo.

Não utilizo o ACBR, criei este tópico aqui só pra alertar a comunidade [sinta-se a vontade para mover o tópico para outra sessão mais adequada]. E para quem utiliza o ACBR, acredito que não será apenas uma configuração. Pois o padrão adotado aqui por Goiânia, é um verdadeiro Frankenstein. Um webservice SOAP, com envelope específico, mas o conteúdo do envelope, é um XML no padrão da NFS-e Nacional. Não sei se há algum sistema, atualmente preparado para este cenário tão estranho. Acabamos de iniciar a implementação em nossos sistemas.

Uma novidade interessante para os emissores de NFS-e em Goiânia. No final de 2025, Goiânia passou a utilizar o sistema da Nota Control, utilizando o padrão ABRASF 2.04. Agora, uma outra novidade ainda mais impactante. Como o padrão ABRASF não será evoluido para contemplar os novos campos da RTC, o pessoal da Nota Control, resolveu fazer um puxadinho, vão manter o padrão SOAP. Mas em vez do antigo envelope: <EnviarLoteRpsEnvio xmlns="http://www.abrasf.org.br/nfse.xsd"> <LoteRps Id="LOTE129" versao="2.04"> <NumeroLote>129</NumeroLote> <Prestador> <CpfCnpj> <Cnpj>99999999999</Cnpj> </CpfCnpj> <InscricaoMunicipal>9999999</InscricaoMunicipal> </Prestador> <QuantidadeRps>1</QuantidadeRps> <ListaRps> <Rps> // dados do RPS </Rps> </ListaRps> </LoteRps> </EnviarLoteRpsEnvio> Agora, o envelope será o seguinte: <EnviarLoteDpsEnvio xmlns="http://www.sped.fazenda.gov.br/nfse" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#"> <LoteDps Id="Lote1" versao="1.01"> <NumeroLote>1</NumeroLote> <!-- Grupo de informações obrigatório. IDENTIFICAÇÃO DO PRESTADOR DE SERVIÇOS. --> <Prestador> <!-- Informação obrigatória. Informe CPF ou CNPJ do prestador. NÃO ENVIAR ESTAS TAGS SIMULTANEAMENTE. --> <CNPJ> ? </CNPJ> <CPF> ? </CPF> <!-- Informação obrigatória. Número de inscrição municipal do prestador do serviço. --> <IM> ? </IM> </Prestador> <!-- Informação obrigatória. Informe a quantidade de DPS do lote. --> <QuantidadeDps> ? </QuantidadeDps> <ListaDps> <!-- DECLARAÇÃO DA PRESTAÇÃO DO SERVIÇO - INFORMAÇÕES GERADAS PELO PRESTADOR DE SERVIÇOS--> <DPS versao="1.01"> <!-- Informação obrigatória. Informe no id: "DPS" + Cód.Mun (7) + Tipo de Inscrição Federal (1) + Inscrição Federal (14 - CPF completar com 000 à esquerda) + Série DPS (5)+ Núm. DPS (15). Complete com zeros à esquerda para completar os itens da composição até o tamanho exigido. --> <infDPS Id="DPS999999999999999999999999999999999999999999"> // Informação do DPS aqui, no mesmo formato da NFS-e Nacional </infDPS> </DPS> </ListaDps> </LoteDps> <!-- Assinatura digital do prestador de serviços ou de seu preposto para o Lote de DPS. --> </EnviarLoteDpsEnvio> https://www.notaeletronica.com.br/goiania/Login/Login_NFE.aspx https://www.notacontrol.com.br/download/nfse/Manual_integracao_v101.pdf Muita atenção a esta parte do comunicado: Ou seja, a partir do dia 01/02/2026, deverá ser consumido o webservice SOAP da Nota Control com o cabeçalho SOAP atualizado, mas o conteúdo do XML será o mesmo da NFS-e Padrão Nacional. Isso que eu chamo de gambiarra. E por fim, mas não penos importante, criaram um validador para nos ajudar: https://nfse.issnetonline.com.br/wsnfsenacional/homologacao/validarxml COMUNICADO - Reforma Tributária e Nota Fiscal de Serviço eletrônica – NFS-e.pdf schema_v101.xsd XML Exemplo - EnviarLoteDpsEnvio.xml

Cidade/UF: Goiânia/GO Previsão de Mudança: Outubro 2025 Tipo de Mudança: Adoção do padrão ABRASF 2.04 Fonte/Documentação: https://abrasf.org.br/biblioteca/arquivos-publicos/nfs-e/versao-2-04 / https://www.goiania.go.gov.br/html/gabinete_civil/sileg/dados/legis/2025/dc_20250825_000002824.html Portais oficiais para acompanhar NFS-e emitidos: Produção: https://www.issnetonline.com.br/goiania/Online/Login/Login.aspx Homologação: https://www.issnetonline.com.br/homologaabrasf/online/login/login.aspx Já foi implementado o novo webservice do provedor.

Em meio à atualizações frenéticas para atender à reforma tributária e às atualizações para integração com o novo padrão nacional da Nota Fiscal Eletrônica de Serviços, a Prefeitura de Goiânia publica o decreto Nº 2.824, DE 2025, passando a adotar o padrão ABRASF 2.04 para emissão da NFS-e no município. O decreto foi publicado em 22/08/2025 e a previsão é que o atual portal usado por vários contribuintes, já seja desligado já em 01/10/2025. Lembrando que a partir de 2026, todas as prefeituras serão obrigadas à adotar o padrão nacional da NFS-e. Qual seria o motivo desta mudança tão repentina, neste momento de extrema pressão para o contribuinte e o pior de tudo, para um padrão que será descontinuado em um futuro não muito distante?

Olá pessoal. Não utilizo os componentes ACBR, vou incluir este tópico aqui, pois pode ser útil para os demais colegas. Estou desenvolvendo a integração do sistema da empresa que trabalho, para gerar os novos "Eventos apuração do IBS e da CBS" Especificamente no evento: Solicitação de Apropriação de crédito presumido, aparentemente, há uma inconsistência entre o que está definido no schema (e211110_v1.00.xsd) <xs:element name="tpAutor"> <xs:annotation> <xs:documentation>Informar 1=Empresa emitente Valores: 1=Empresa Emitente, 2=Empresa destinatária; 3=Empresa; 5=Fisco;6=RFB; 9=Outros Órgãos; </xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:element> E a documentação do MOC: Função: Evento a ser gerado pelo adquirente em relação às notas fiscais de aquisição de emissão de terceiros e que lhe gerem o direito à apropriação de crédito presumido. Autor: Adquirente/Destinatário (quando os dois estiverem preenchidos, devem ser iguais) da nota fiscal Modelo: NF-e modelo 55 Código do Tipo de Evento: 211110 "quando os dois estiverem preenchidos, devem ser iguais". Esta observação, não tem nenhum significado pra mim. Não consegui entender, quem pode/deve emitir este evento, se é o destinatário como diz o MOC, ou o emitente (como diz o schema "<xs:restriction base="xs:string"><xs:enumeration value="1"/></xs:restriction>"). No MOC, inclusive há a documentação da rejeição: Se tpAutor=2-Empresa Destinatário: - CNPJ/CPF do Autor diverge do CNPJ/CPF do Destinatário da NF-e Obrig 575 Rejeição: Autor do evento diverge do destinatário da NF-e Se algum colega tiver uma interpretação mais clara sobre a documentação deste evento, e puder compartilhar, ficarei muito grato. Obs.: Me desculpem se este não for o fórum mais adequado para esta questão. Silvair L. Soares

Resposta recebida da Secretaria da Economia de Goiás no dia 11/06/25:

Bom dia pessoal. Não utilizo os componentes ACBr, trabalho em uma empresa que tem sua própria solução de emissão de NF-e/NFC-e. Estou passando pelos mesmos problemas, aqui em Goiás. Observando a string do QrCode em uma NFC-e que estou tentando emitir aqui em ambiente de homologação: <qrCode>http://homolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe?p=52250605462662000105650030000002941196607112|3|2</qrCode> <?xml version="1.0" encoding="utf-8"?><enviNFe versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe"><idLote>2314</idLote><indSinc>1</indSinc><NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="4.00" Id="NFe52250605462662000105650030000002941196607112"><ide><cUF>52</cUF><cNF>19660711</cNF><natOp>VENDA DE MERCADORIA ADQ DE TERCEIROS</natOp><mod>65</mod><serie>3</serie><nNF>294</nNF><dhEmi>2025-06-09T10:22:09-03:00</dhEmi><tpNF>1</tpNF><idDest>1</idDest><cMunFG>5208707</cMunFG><tpImp>4</tpImp><tpEmis>1</tpEmis><cDV>2</cDV><tpAmb>2</tpAmb><finNFe>1</finNFe><indFinal>1</indFinal><indPres>1</indPres><procEmi>0</procEmi><verProc>01.01.000</verProc></ide><emit><CNPJ>05462662000105</CNPJ><xNome>MICROSUM TECNOLOGIA DA INFORMAÇÃO LTDA</xNome><xFant>MICROSUM TECNOLOGIA DA INFORMAÇÃO</xFant><enderEmit><xLgr>RUA 90</xLgr><nro>1</nro><xCpl>SN</xCpl><xBairro>SETOR SUL</xBairro><cMun>5208707</cMun><xMun>GOIANIA</xMun><UF>GO</UF><CEP>74610260</CEP><cPais>1058</cPais><xPais>Brasil</xPais><fone>39419681</fone></enderEmit><IE>103580867</IE><CRT>1</CRT></emit><dest><CPF>69838861006</CPF><xNome>NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xNome><enderDest><xLgr>RUA XV DE NOVEMBRO, N 01</xLgr><nro>0</nro><xCpl>BRANCO</xCpl><xBairro>CENTRO</xBairro><cMun>5208707</cMun><xMun>GOIANIA</xMun><UF>GO</UF><CEP>76420000</CEP><fone>32338040</fone></enderDest><indIEDest>9</indIEDest><email>[email protected]</email></dest><autXML><CNPJ>15976632000162</CNPJ></autXML><det nItem="1"><prod><cProd>7000001000002</cProd><cEAN>SEM GTIN</cEAN><xProd>NOTA FISCAL EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xProd><NCM>97069000</NCM><CEST>1234567</CEST><indEscala>S</indEscala><CFOP>5101</CFOP><uCom>GR</uCom><qCom>1.0000</qCom><vUnCom>17.8396</vUnCom><vProd>17.84</vProd><cEANTrib>SEM GTIN</cEANTrib><uTrib>GR</uTrib><qTrib>1.0000</qTrib><vUnTrib>17.8396</vUnTrib><indTot>1</indTot></prod><imposto><vTotTrib>0</vTotTrib><ICMS><ICMSSN102><orig>0</orig><CSOSN>102</CSOSN></ICMSSN102></ICMS><PIS><PISOutr><CST>49</CST><vBC>0.00</vBC><pPIS>0.00</pPIS><vPIS>0.00</vPIS></PISOutr></PIS><COFINS><COFINSOutr><CST>49</CST><vBC>0.00</vBC><pCOFINS>0.00</pCOFINS><vCOFINS>0.00</vCOFINS></COFINSOutr></COFINS></imposto></det><total><ICMSTot><vBC>0.00</vBC><vICMS>0.00</vICMS><vICMSDeson>0.00</vICMSDeson><vFCP>0.00</vFCP><vBCST>0.00</vBCST><vST>0.00</vST><vFCPST>0.00</vFCPST><vFCPSTRet>0.00</vFCPSTRet><vProd>17.84</vProd><vFrete>0.00</vFrete><vSeg>0.00</vSeg><vDesc>0.00</vDesc><vII>0.00</vII><vIPI>0.00</vIPI><vIPIDevol>0.00</vIPIDevol><vPIS>0.00</vPIS><vCOFINS>0.00</vCOFINS><vOutro>0.00</vOutro><vNF>17.84</vNF><vTotTrib>0.00</vTotTrib></ICMSTot></total><transp><modFrete>9</modFrete></transp><pag><detPag><tPag>01</tPag><vPag>17.84</vPag></detPag><vTroco>0.00</vTroco></pag><infAdic><infCpl>- CLIENTE......: 5 NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL - MENSAGEM PROMOCIONAL: OBRIGADO E VOLTE SEMPRE - MENSAGEM PROCON: TELEFONE PROCON: 151 - PERMITE APROVEITAMENTO DE CREDITO DE ICMS NO VALOR DE: 0,00 CORRESPONDENTE A ALIQUOTA DE 3,15% NOS TERMOS DA LEI TAL..</infCpl></infAdic></infNFe><infNFeSupl><qrCode>http://homolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe?p=52250605462662000105650030000002941196607112|3|2</qrCode><urlChave>http://homolog.sefaz.go.gov.br/nfeweb/sites/nfce/danfeNFCe</urlChave></infNFeSupl><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /><Reference URI="#NFe52250605462662000105650030000002941196607112"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /><Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" /></Transforms><DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /><DigestValue>6hmsCudc6htc40fSdyxg/7ApmAY=</DigestValue></Reference></SignedInfo><SignatureValue>Tpp4ol4RABz9T+qSXuPxaGvjalF0fz9OqV095docDKivvCM/B00lIEQeAjIvLpZYpzKXvfomlaJhRYW1SBvZrpzflO0oH0xPeg6UH4pVNMjdt7Bj0QoZD1IkQ57cwWAHhKXHYZz00P7kFm4RTsr29godbBvcHSFavmO2bbUfmk9Zmfdlgz73xmuG4ErjPJxzakETjIBPMiUK7eNleUAP0FRdggHHGAPlCplVw8fgR7GbYrOJdsotNBwWSwc9g01vSCYZp3yuUDqVY5BLZ8awMFvLo1EhrgZX/+Q/4FqRgpN44DSFhtvPWVFM9eJKqDrzuwcXJ1wYA/TibnYee9hpww==</SignatureValue><KeyInfo><X509Data><X509Certificate>MIIH7TCCBdWgAwIBAgILAPvm44Z9gavhJ4QwDQYJKoZIhvcNAQELBQAwWzELMAkGA1UEBhMCQlIxFjAUBgNVBAsMDUFDIFN5bmd1bGFySUQxEzARBgNVBAoMCklDUC1CcmFzaWwxHzAdBgNVBAMMFkFDIFN5bmd1bGFySUQgTXVsdGlwbGEwHhcNMjUwMzE3MTEyNjE1WhcNMjYwMzE3MTEyNjE1WjCB1TELMAkGA1UEBhMCQlIxEzARBgNVBAoMCklDUC1CcmFzaWwxIjAgBgNVBAsMGUNlcnRpZmljYWRvIERpZ2l0YWwgUEogQTExEzARBgNVBAsMClByZXNlbmNpYWwxFzAVBgNVBAsMDjI5MDk4NzQ3MDAwMTA2MR8wHQYDVQQLDBZBQyBTeW5ndWxhcklEIE11bHRpcGxhMT4wPAYDVQQDDDVNSUNST1NVTSBURUNOT0xPR0lBIERBIElORk9STUFDQU8gTFREQTowNTQ2MjY2MjAwMDEwNTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuY2ns57WbOI4Xoi8F72/eG9hq9nuo0vSI5OFgmxTxGYvHD72alFqgSMcqtIFE/Vkjs+7ITLXl9Ki5YleQaoTVcVNsS1l1+CXtMtwXxdc2ADTxGKI2Ic9QjizO0Y1T2kQcIp2vwgLbJtP3Q2SCLzz0ibRVE8KOg03MnYt//GF7w5wbCds6POhOx2NPnE8S7pQXFr7prZGH9y0NBckfpe0voId3lls9+J0qZx16MEgDpvJVrTLrQtlXQ02z+2u1MoEU5gHagcia9YGmQBadHOAWcx2JrOBSfvqtkrDpiP3Jg2y01iYvZR9OQcCNOc66zapH4TegvasXpmnvazH089gUCAwEAAaOCAzUwggMxMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwCQYDVR0TBAIwADAfBgNVHSMEGDAWgBST4f9+HeX15E3hOWKLIWmV5q9yFjAdBgNVHQ4EFgQUJRqiDSMXWSAm/gYfLIUtWOp3mzwwfwYIKwYBBQUHAQEEczBxMG8GCCsGAQUFBzAChmNodHRwOi8vc3luZ3VsYXJpZC5jb20uYnIvcmVwb3NpdG9yaW8vYWMtc3luZ3VsYXJpZC1tdWx0aXBsYS9jZXJ0aWZpY2Fkb3MvYWMtc3luZ3VsYXJpZC1tdWx0aXBsYS5wN2IwgYIGA1UdIAR7MHkwdwYHYEwBAgGBBTBsMGoGCCsGAQUFBwIBFl5odHRwOi8vc3luZ3VsYXJpZC5jb20uYnIvcmVwb3NpdG9yaW8vYWMtc3luZ3VsYXJpZC1tdWx0aXBsYS9kcGMvZHBjLWFjLXN5bmd1bGFySUQtbXVsdGlwbGEucGRmMIHJBgNVHREEgcEwgb6gIwYFYEwBAwKgGgQYRkFCSU8gU09BUkVTIERBIFNJTFZFSVJBoBkGBWBMAQMDoBAEDjA1NDYyNjYyMDAwMTA1oEIGBWBMAQMEoDkENzIzMTIxOTc4ODYwODkxOTYxMzQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDCgFwYFYEwBAwegDgQMMDAwMDAwMDAwMDAwgR9BUkRJUkVUT1JJQUVDT01FUkNJQUxAR01BSUwuQ09NMIHiBgNVHR8Egdowgdcwb6BtoGuGaWh0dHA6Ly9pY3AtYnJhc2lsLnN5bmd1bGFyaWQuY29tLmJyL3JlcG9zaXRvcmlvL2FjLXN5bmd1bGFyaWQtbXVsdGlwbGEvbGNyL2xjci1hYy1zeW5ndWxhcmlkLW11bHRpcGxhLmNybDBkoGKgYIZeaHR0cDovL3N5bmd1bGFyaWQuY29tLmJyL3JlcG9zaXRvcmlvL2FjLXN5bmd1bGFyaWQtbXVsdGlwbGEvbGNyL2xjci1hYy1zeW5ndWxhcmlkLW11bHRpcGxhLmNybDANBgkqhkiG9w0BAQsFAAOCAgEAfOdBg0R1SC0NVLmHGIpScrmS9x1ic/4GbOn8HtngzDNsRa/fx40dEKylwySARCXHJXaFbqP43b272X0dyMAvrkW8IMJHlHpsnWcsqqWJ841ZwSrRlaUSvkC6tct5svhy7WhoFg59d5gkrPlXow0cOq9GIbHKTb1yyjcu/oC5KCjcMhIJUuMAh1jgnd7dUbZz+J4UySCShLP1Jo6j9dW8oLwu84JtEEotT7tvfdTMpqyyeumY+fGwAsEcTla98cmEoGmOTwZtd/1e1cnceWPsCSG1JHXQ1zJww/XvL4OhQS53aprMiF5lEX3cCyEhrp4hhwHxV1EpfnuH/AceE5/WQ9iaAtDX0PVYB/GhESsemLvP/0odvQfgrldNeg3QiwIuJmzKDOnuOZ9iTR6PecBj26H+3ILziw8Gfb8I1JYGz23QyfWQA05zBQkNmMEAPjlXQ5K1F9z8xIjeX8hkcVpKKhmHN7H2rTS5/GUcfYVHCjFXjVXy4iIZIimAzjAF1Io+MiZ+vIa0eGigb0yi53kv7FkSSD6XiDuLYOyyMt6B32LvQtKvE8Kq1cAwg2L6RqILwQL7I3u0qj60PuI4li+W22/jhRwz+uamoeSRdYYGjs1ujzMjIpPoOzKzoUM7n4Xm/Yu272WB/4CM6ALlirXWwdaY+xg2euOm8KXX8mg/cIo=</X509Certificate></X509Data></KeyInfo></Signature></NFe></enviNFe> Fazendo uma validação desta string, de acordo com o manual: Aparentemente, estaria correto. De acordo com o novo pacote de schemas disponível no site: https://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=BMPFMBoln3w= https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=lxjvtPfGzo8= Que segundo o próprio site, é compatível com a NT 2025.001. A regra de validação definida neste schema, é compatível com o manual de especificação do qrcode: O validador da Sefaz RS, já aceita este XML: Mas a SEFAZ Goiás, ainda está retornando falha de schema para esta tentativa de emissão: <retEnviNFe versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe" xmlns:ns0="http://www.w3.org/2000/09/xmldsig#"> <tpAmb>2</tpAmb> <verAplic>GO4.0</verAplic> <cStat>225</cStat> <xMotivo>Rejeição: Falha no Schema XML do lote de NFe</xMotivo> <cUF>52</cUF> <dhRecbto>2025-06-09T10:23:38-03:00</dhRecbto> </retEnviNFe> Mesmo após passados 7 dias do cronograma definido na nota técnica: Algum colega já chegou a acionar a SEFAZ-GO sobre este problema? Atenção! Uma observação importante para os colegas que emitem NFC-e aqui em Goiás. O endereço de consulta ao QrCode daqui não funciona há mais de dois anos, nem em produção nem em homologação. Já tentei de todas as formas acionar a administração estadual mas nunca tomaram nenhuma providência, nem na ouvidoria. Portanto, caso algum cliente reclame deste problema, nem perca tempo tentando resolver, o problema é lá na SEFAZ. Um consumidor que tente acessar uma NFC-e através do QrCode impresso no danfe aqui em goiás, se deparará com a seguinte mensagem:

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