mbbortolini

Pessoal, segue uma resposta aceitável para o que estava acontecendo, para todos que são atendidos pela SEFAZ-RS : De qualquer forma, para NFe 4.0 pode ficar marcado somente TLS 1.2.

Pessoal depois de muita insistência com a SEFAZ-RS, agora pouco me responderam, segue a resposta : Então esperamos que da mesma forma como o erro passou a aparecer o mesmo seja eliminado. Porém pode ocorrer um pouco de demora na emissão, visto que é quase a metade dos servidores disponíveis. Mas poderemos tomar aquela mais tranquilos hoje []s

Leandro, com está a sua implementação ? Não é o mesmo caso, mas estou implementando o consumo da API da Safe2Pay, consegui fazer GET e POST com os componentes indy(idHTTP) e rest(RestClient) neste caso a autenticaçaõ deve ir no header de comunicação e graças a dica do colega @Projeto6 consegui fazer com o RESTClient e com o idHTTP fiz da seguinte forma : idHttp.Request.CustomHeaders.Clear; idHttp.Request.CustomHeaders.AddValue('NOME_CHAVE','STR_CHAVE'); Para o POST o que me ajudou muito além do Postman foi o https://webhook.site/ aqui neste eu consigo ver como o html chega no server, pois eu estava com dificuldades de geração do meu JSON. Se precisar de ajuda o que sei aprendi na última semana mas posso dar uma força.

realmente, o meu problema é a numeração. Agora sim faz sentido usar Cancelamento por substituição. Obrigado @BigWings pela luz

continuando... Nestas duas chaves a diferença é o tag TpEmiss (e o digito verificador) Então qual nota é válida, a que processou na SEFAZ (chave1) ou a que o cliente levou impressa (chave2) ? Solução 1 : No retorno de duplicidade temos o seguinte retorno : Seria possível quebrar o retorno pegar a chave que retornou e executar uma consulta na tentativa de recuperar o XML, Problema : a nota em contingência que o cliente levou, a qual tem uma chave e ao consultar nunca será válida. Ao meu ver isso seria fraude passível de penalizações LOGO SOLUÇÃO 1 é INVÁLIDA. Solução 2 : Com o retorno acima, pegar a chave da duplicidade e executar o evento de Cancelamento Por Substituição, aqui temos uma explicação do que é. Eu ainda não implementei este evento, estou ainda fazendo análise do caso. Mas aí me deparei com as rejeição para o referido evento : O que me preocupa é a Rejeição 912 pois a contingência não foi transmitida, logo não vai existir Problema : ainda estou montando ambiente para verificar o caso, assim que tiver resultado posto aqui.

Senhores, estou enfrentando o mesmo problema, conforme já constatado a maldita instabilidade de internet é o que vem causando isso. Caso é o seguinte : - Cliente emitindo NFCe (RS) e em algum momento do dia a conexão de internet se torna instável; - No log do sistema é possível ver o erro retornado ao executar o serviço de autorização na webservice : 12002 - Time Out; - No meu tratamento, esse erro é encarado como demora na resposta, logo continuarei invocando o serviço de autorização, no entanto o erro 12002 fica recorrente as vezes por vários minutos até conseguir executar a autorização; - No entanto em alguns casos após várias tentativa e muitos retornos 12002, o weservice responde diferente, em algum desses momentos a internet de instável passou a falecida ai o retorno é 12007 "O nome do servidor não pode ser resolvido" opa, ai pra mim no meu modesto intendimento isso quer dizer que a internet está OFF, e neste caso, mudo o tipo de emissão para OFF-LINE imprimindo a NFCe em contingência e guardando para posterior transmissão. Até ai nada de anormal. - Mas aí tem a transmissão da contingência, ai temos Duplicidade, detalhe, com DIFERENÇA NA CHAVE, mas e ai o que isso quer dizer ? conforme já constatado anteriormente, em algumas das transmissões a nota chegou na SEFAZ e foi processada, mas eu não obtive, nem o retorno, nem o XML. - Na emissão OFF-LINE a recomendação é alterar somente o TIPO de emissão e informar data e motivo da contingência, logo a numeração não é alterada. Ao meu ver isso é o que resulta na Duplicidade com diferença na chave pois vejam as chaves abaixo 43190507885188000141650010001331131041390949 - Chave da nota emitida na SEFAZ 43190507885188000141650010001331139041390944 - Chave da nota em contingência a ser transmitida, a qual recebeu o retorno de duplicidade

Resposta da SEFAz - RS sobre o questionamento quanto a aplicação da regra :

@charles.libano executa somente o ACBrNFeServicos.rc (duplo click, compilador do delphi(BRCC32 se encarregará de resolver a questão e transformar o ACBrNFeServicos.ini no ACBrNFeServicos.RES. Pra conferir a alteração abra o ACBrNFeServicos.RES e verifique a URL na seção do seu estado.

@Juliana Tamizou, creio que a regra esteja ativa somente em homologação, caso contrário todos meus clientes estariam rejeitando. No caso estou falando especificamente da SEFAZ-RS

Senhores, a alteração em AcbrNFeServicos.ini dever ser a seguinte : DE PARA

Obrigado @MFincotto pelo retorno, no entanto não satisfeito com a causa, fui mais afundo. (já estou me preparando pra quando meu guri chegar na idade dos porquês ) Causa de tudo isso : Maldita regra de validação ZX03-20 incluída na NT 2016-002 v1.61 (NT sem fim). Nesta NT a regra diz que : Em Observações1 em consulta a URL no endereço http://nfce.encat.org/consumidor/consulte-nota/ temos a seguinte URL, no caso RS : Rio Grande do Sul www.sefaz.rs.gov.br/nfce/consulta Até aqui tudo em conformidade, mas note que que acessar a URL você será direcionada para https://www.sefaz.rs.gov.br/NFCE/NFCE-COM.aspx mas isso não é mistério, redirecionamento de URL é normal. Mas e ai ? E a regra ??? Então para sanar a rejeição devemos alterar a URL para uma que não está prevista na NT. Só que, não para por aqui, vocês tentaram consulta o QrCode gerado ? Aqui não deu : Solicitei informações ao SEFAZ e irei aguardar posicionamento, mas já estou deixando um versão pronta caso entre a validação em produção. Mais uma vez obrigado @MFincotto

Boa noite pessoal, estou com o mesmo perrengue aqui. Já vi que alterando o INI vai funcionar, mas debugando o componente pude notar que quando vai montar a URL, o nome do do serviço passado para a função está sendo alterado. em ACBrDFe.pas é chamada a procedure LerServicoChaveDeParams com os seguinte parâmentros : NomeSessao 'NFCe_RS_H' NomeServico 'URL-ConsultaNFCe' Versao 2 URL '' Ocorre que na linha 454 e 455 este código monta a Chave e ChaveBase com a versão junto : ChaveBase := UpperCase(NomeServico + '_'); Chave := ChaveBase + FloatToString(VersaoAtual,'.','0.00'); ficando assim : Chave 'URL-CONSULTANFCE_2.00' ChaveBase 'URL-CONSULTANFCE_' abaixo, na linha 448 existe o seguinte código : Assim a minha condição está lendo o INI com os seguintes parâmetros : NomeSessao 'NFCe_RS_H' e Chave 'URL-CONSULTANFCE_2.00' Logo o INI está assim : gerando o XML com a referida inconsistência. Baseado nisso temos : 1 - Alterar o INI; 2 - O estagiário da SAFAZ aplicou a validação hoje, uma vez que ontem emiti sem problemas. 3 - Hoje é em homologação e amanhã será o de produção ???

@William F. L. verifique se as DLLs(libXML2 e XMLSec) estão atualizadas nestes clientes,

@DSilva o XML parece estar válido conforme a validação do SEFAZ-rs, a não ser pelo CNPJ, o qual não é do RS. Por se tratar de NFCe e como a mensagem de erro que você reportou não tem muitos detalhes, revise os seguintes itens : - schemas atualizados da v 4.0; - DDLs atualizadas, isso costuma dar problemas com o TLS v1.2; - verificar se windows do pc está com todas as atualizações em dia, incluindo a do protocolo TLS 1.2; - se não me falhe a memória, para Win XP não ha atualização que instale o protocolo TLS 1.2 (logo não funciona para NFe 4.0);

Não, CSC somente é necessário para emissão da NFCe - Nota Fiscal de Consumidor Eletrônica modelo 65, que é diferente da NFe - Nota Fiscal Eletrônica modelo 55. Veja o demo do ACBr em ...ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFe Configurando corretamente o componente, veja exemplo anterior; Veja respostas anteriores.