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.

@anderson.belino ao que me consta a inutilização é diferente de cancelamento. Inutilização é quando um número ou faixa de números da nota não foi utilizado. Antigamente era comum os contadores "pularem" alguns números de notas nos blocos no final de cada fechamento contábil, para que se precisassem fazer notas de ajustes ou alguma outra elas seguissem na mesma sequencia de números do mês em questão ai quando não precisavam mais destas notas elas era inutilizadas no bloco mesmo, creio que foi por isso que a inutilização foi criada. Para a nossa realidade pode ser que por um problema técnico o sistema não seguiu a sequencia de numeração e assim é necessário fazer a inutilização destes números. Cancelamento a partir da 2013 é um evento, e deve ser enviado par o WS como tal através da função ACBrNFe1.EnviarEvento com tpEvento := teCancelamento. logo os Serviços são diferentes Reveja seu processo, qualquer dúvida há o demo do ACBr para consulta.

Veja se não há DLLs desatualizadas nas pastas do windows. Certifique-se que estas DLLs estejam em apenas um local. Se win 32 em "C:\Windows\System32" OU na pasta do exe. se win 64 em "C:\Windows\SysWOW64" OU na pasta do exe.

@thiagosantanna10 conseguiu resolver ? Tive agora pouco o mesmo problema, e estava aqui neste tópico buscando a solução, e eis que na tentativa consegui resolver: Certificar que o schema seja o último, configurar NFe versão 4.0 e qrcode 2.0 Solução : atualizar as dlls libXML (trunk2\DLLs\XMLSec) No meu caso funcionou 100%;

@Alessandra.imofficer esse assunto foi bastante recorrente esta semana no fórum, tem bastante postagens sobre o assunto, mas vamos lá. A partir de 03/09/2018 torna-se obrigatório a informações de todos os campos de fatura (nFat, vOrig, vDesc e vLiq). Certifique-se que seu componente e seus schemas estejam atualizados. Marque no componente conforme encontra-se neste tópico, ao qual você também comentou a mesma dificuldade.

Anderson, veja a configuração da impressora no componente do ACBrDanfeFr, pra mim sempre que saiu cortado foi pq a impressora não estava definida no componente.

@Sergio Tucano Clemente Da Silva Filho não entendi a necessidade de gerar uma outra nota para a contingência. Eu faço da seguinte forma : 1 - geraNFce 2 - Transmite normal 3 - Retornou 100, processa devidas gravações e impressões Senão: 4 - Trato contingência, mas somente se os retornos contiverem as seguintes mensagens : Pois como o colega Roberto falou, não tem como ter certeza onde ocorreu o problema de comunicação, e com estes retornos até hoje não tive problema. Assim, altero o tipo de emissão, data hora de contingência e justificativa. 5 - Guardo xml para transmissão. Mas tudo isso da mesma nota, pois só dou o número da nota na hora de emitir, não de gravar a venda no banco de dados.

@Helton Sampaio Retorno 563 - quando enviado pedido de utilização para uma faixa que já existe pedido de inutilização seria, a meu ver, semelhante à duplicidade com mesma chave na NFe. Ex.: enviar duas vezes a inutilização para as faixas incial 50 final 52. Retorno 256 - quando uma das notas da faixa informada já está inutilizada. Seguindo o exemplo anterior : enviar a inutilização para as faixas incial 50 final 52, e posteriormente enviar para inicial 52 e final 55, note que o 52 ficou nas duas faixas. Para consultar inutilização pode se usar os seguintes passo : Mais info em : http://tsdn.tecnospeed.com.br/base-de-conhecimento/post/rejeicao-256-uma-nf-e-da-faixa-ja-esta-inutilizada-na-base-de-dados-da-sefaz http://tdn.totvs.com/pages/releaseview.action?pageId=192104220

Veja este tópico : Creio que a solução apresentada pelo @Felipe E. Resende Mesquita seja o que você procura.

O campo foi criado no mês de julho conforme commit do SVN : Tentou usar apagarAcbr e reinstalar os componentes ?