BigWings

Pode ocorrer esse erro se a pasta de schemas estiver em uma pasta compartilhada na rede e configurada no formato \\servidor\compartilhamento, e usando SSLXmlSignLib = xsLibXML2. Se for esse o caso, você pode tentar: - Mapear a pasta compartilhada para uma letra de unidade local - Copiar os schemas da rede para uma pasta local - Usar SSLXmlSignLib = xsMsXML (não recomendado para A3).

Esse erro pode acontecer se você estiver usando DLLs erradas, por exemplo, DLLs de 64 bits para uma aplicação compilada para 32 bits. Você marcou a opção de copiar as DLLs no ACBrInstall_Trunk2.exe?

Tente retornar as URL anteriores ao ajuste: Homologação: http://www.nfce.go.gov.br/post/ver/214413/consulta-nfc-e-homologacao Produção: http://www.nfce.go.gov.br/post/ver/214344/consulta-nfce

Tente com o arquivo anexo. ACBrNFeServicos.ini

Não é apenas o RS que passou a validar a URL, aconteceu com a maioria dos estados. O que parece é que está sendo exigido das SEFAZ a adequação conforme a informação abaixo: Com a exigência em produção a partir do dia 20/05/2019 havia o risco de rejeição das NFCe a partir desse dia caso não fosse feito a correção. Infelizmente as SEFAZ não estão informando essas mudanças, a mensagem foi postada num grupo fechado, o que deixa nós programadores no escuro para fazer as correções. Repetindo, o melhor seria a SEFAZ fazer a adequação da URL de consulta ser a mesma que a divulgada no ENCAT, seria bom entrar em contato com eles pra questionar essa discrepância.

Esse não é o prazo para a NT 2018.005? A validação da URL de consulta foi implementada na NT 2016.002, com prazo para 01/04/2019. Por favor informe o link com a informação oficial se tiver. O melhor seria a SEFAZ-MS divulgar a URL correta na página do ENCAT conforme orienta a NT 2016.002.

Você tem essa informação?

A mensagem indica que o componente recebeu o retorno do webservice, mas ele não é um retorno válido: o grupo nfeResultMsg do XML está vazio.

Alguns arquivos onde não era dado manutenção foram movidos para a pasta Obsoletos. Os arquivos da pasta Report realmente ainda não imprimem o QRCode lateral.

As URLs de consulta por chave de acesso foram todas ajustadas de acordo com o publicado na página do ENCAT, com base nesta determinação: No caso de MG, aparentemente a URL que estão exigindo não é a mesma publicada na página do ENCAT: http://nfce.encat.org/consulte-sua-nota-qr-code-versao-2-0/ Comparando a URL anterior do ACBrNFeServicos.ini com o ajustado, a diferença é pequena: Antes: http://hnfce.fazenda.mg.gov.br/portalnfce Após: http://hnfce.fazenda.mg.gov.br/portalnfce/ A princípio você pode apenas voltar a URL anterior no arquivo ACBrNFeServicos.ini: [NFCe_MG_H] ... URL-QRCode_2.00=https://nfce.fazenda.mg.gov.br/portalnfce/sistema/qrcode.xhtml URL-ConsultaNFCe_2.00=http://hnfce.fazenda.mg.gov.br/portalnfce Para uma solução definitiva, seria bom entrar em contato com a SEFAZ para saber se vão aplicar a regra de validação conforme consta na NT, validando a tag urlChave com exatamente a URL publicada na página do ENCAT. A data para ativação da regra em produção é 20/05/2019.

O PDF mostra um DANFE bem diferente do gerado com o DANFeNFCe.fr3. Com o .fr3 do repositório, que inclusive está desatualizado com relação ao novo layout, os acréscimos aparecem. Provavelmente você está usando um arquivo .fr3 modificado.

Qual arquivo .fr3 está usando?

Não existe CST de ICMS 102. CST pode ser 00, 10, 20, 30, 40, 41, 50, 51, 60, 70 ou 90. Isso no regime normal, que é como você está informando o regime de emissão: [Emitente] CRT = 3 102 pode ser um CSOSN, quando o emitente é optante pelo Simples Nacional, e o item é "tributado pelo simples nacional sem permissão de crédito", nesse caso você deve informar CRT = 1, e CSOSN = 102.

Correção enviada para o repositório, rev. 16962. Obrigado pela contribuição.

Pode anexar o XML e PDF/imagem para verificação?

Foi removida. Como disse, as propriedades eram rendundantes. Se quer o DANFE NFCe detalhado basta definir ImprimeItens como True.

É um evento do CTe, assim como o cancelamento, carta de correção... A diferença é que o evento de prestação em desacordo deve ser emitido pelo tomador e não pelo emitente do CTe. Então a aplicação ERP do tomador deve ser capaz de transmitir esse evento para o CTe que foi destinado a ele como tomador, mesmo que ele mesmo não emita CTe.

Já foi enviado ao repositório atualização do ACBrNFeServicos.ini e ACBrNFeServicos.res com as URL ajustadas de acordo com o publicado na página do ENCAT, homologação e produção.

A mensagem está clara. O tomador para o qual o CTe foi emitido incorretamente precisa enviar um evento do tipo "Prestação de serviço em desacordo" para o CTe a ser anulado.

Esse componente é para NFe e não NFCe. Veja o exemplo na pasta ACBr\Exemplos\ACBrDFe\ACBrNFe\Delphi DANFe FR. // --- Configurações específicas para NFCe --- // Mostra itens na NFCe, caso False emite a NFCe resumida ACBrNFeDANFCEFR1.ImprimeItens := ckImprimeItens.Checked;

Que classe é vACBR_DANFE? Tem vários no repositório. Qual componente DANFE está usando?

Tente definir ACBrMDFe1.Configuracoes.Arquivos.AdicionarLiteral como False.

Essas propriedades eram redundantes, foram renomeadas para ImprimeItens nos componentes DANFE para NFCe.

Fiz teste pelo demo e a consulta funcionou normalmente: Por favor descreva melhor o problema com o retorno da consulta e seu ambiente de desenvolvimento e testes.