BigWings

Isso é alguma instabilidade no webservice da SEFAZ-MG: Fiz teste de envio do teu XML e aconteceu como você disse, hora funcionava com a rejeição do NCM, hora retornava o seguinte XML: Arquivo: *-rec-soap.xml. <?xml version="1.0" encoding="UTF-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unmarshalling Error: Unexpected close tag </COF>; expected </COFINSOutr>. at [row,col {unknown-source}]: [1,8186] </soap:Text></soap:Reason></soap:Fault></soap:Body></soap:Envelope> Quando o retorno do webservice vem em formato não esperado pelo ACBr, ocorre a mensagem de exceção em branco.

Atualize os fontes.

Além do .ini desatualizado, nenhuma ideia. Tente o debug.

Enviei alteração para o repositório para gerar novamente os campos: Favor atualizar os fontes e testar novamente.

Está usando o DANFE em FastReport? Qual arquivo .fr3 está carregando?

O seu arquivo está correto. Faça o teste informando a configuração de versão do QR-Code no componente: ACBrNFe.Configuracoes.Geral.VersaoQrCode := veqr100; Veja também se não há um arquivo ACBrNFeServicos.ini desatualizado no diretório da aplicação.

A resposta não faz sentido já que a mensagem de rejeição foi introduzida na NT 2016.002 v. 1.50. Se a SEFAZ não implantou as novas regras, a rejeição não deveria existir. Quanto aos prazos de implantação, homologação e produção foram prorrogados para 21/05 e 04/06, respectivamente, então ainda pode haver novos atrasos.

Como estão as configurações SSL?

Se está usando o DANFE em FastReport use o arquivo DANFENFCe4_20.fr3.

Tente informar cOrgao = 91 para a manifestação. Ao contrário dos outros eventos, a manifestação do destinatário é enviada ao ambiente nacional e não à SEFAZ do estado.

A mensagem de contingência é normal visto que ela é gerada no XML no momento da emissão. Mas esse modelo de DANFE NFCe é antigo e não é mais usado no componente.

O arquivo está validando normalmente. Tente atualizar a pasta de Schemas.

O arquivo está validando normalmente. Atualize a pasta de Schemas.

Esse erro pode ocorrer se você estiver enviado um XML da NFe 3.10 para um webservice da 4.00 ou vice-versa, então é possível que você esteja forçando a geração do XML na versão errada ou esteja com o arquivo .ini desatualizado nos fontes do ACBr ou no diretório da aplicação.

Mas está persistindo esse valor em banco de dados por exemplo? Que saiba só há mensagem de consumo indevido caso você informe 0 nesse parâmetro, coisa que você precisa fazer uma única vez para o CNPJ, quando você não sabe o valor do último NSU. Se não me engano o prazo de bloqueio é de 1h.

Enviado ao repositório. Obrigado pelo retorno.

Está armazenando o NSU retornado pelo método para ser informado como o parâmetro ultimoNSU na próxima consulta?

Pra te falar a verdade, um CNPJ com duas IE ativas no estado é novidade pra mim... Pelo que vi a diferença que talvez justifique isso é o CNAE de cada uma. Não há nada no manual que indique a ordem de retorno dos cadastros.

Essa tag é de entrada, onde você informa a IE a consultar. Para obter a IE de retorno use: ACBrNFe.WebServices.ConsultaCadastro.RetConsCad.IE

Aparentemente a URL está exigindo TLS 1.2 para o acesso, mesmo sendo da versão 3.10. Além disso parece estar funcionando normalmente.

Teste com os arquivos anexos. ACBrNFeServicos.ini ACBrNFeServicos.res

A mensagem é tão parecida com a de validação pelos schemas que não percebi. Nesse caso o problema é na SEFAZ, que não atualizou os schemas e novas regras da NT 2016.002 v. 1.50.

Fiz teste com essa configuração e está respondendo normalmente. Teste outras configurações SSLLib. Verifique se o Windows tem todas as atualizações instaladas.

Entendi que queriam opção de imprimir ou não. Claro que uma venda sem documento fiscal é sonegação.