Italo Giurizzato Junior

Bom dia a todos, Favor atualizar os fontes, fiz uma alteração na rotina que lê o retorno, acredito que agora o componente vai conseguir ler corretamente os dados de retorno.

Boa tarde Narlem, Se tratando de Offline, você não deve enviar, apenas gerar o XML e mandar imprimir em duas vias.

Ricardo, O que tudo indica o numero da nota é o que realmente o que consta no XML. Se mesmo passando o numero que consta no XML o webservice não realiza o cancelamento, então tem algo de errado no webservice do provedor. Favor entrar em contato com ele e pedir explicação.

Boa tarde Moacir, Você esta usando o programa exemplo para os testes? Configurou o mesmo para usar o libWinCrypt (conforme imagem que anexei em uma postagem anterior)?

Boa tarde Juliano, Favor verificar se a cidade em questão ainda continua usando o provedor Actcon.

Boa tarde Ricardo, Consultando essa nota através do site, ela esta com qual numero?

Boa tarde Reinado, Favor anexar o arquivo ACBrMDFeServicos.ini que deve se encontrar na mesma pasta do executável.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Webservice implementado por incompetentes, não são capazes de gerar um resposta de rejeição apontando a verdadeira causa, simplesmente retorna uma mensagem genérica e o desenvolvedor que se F@#$% para descobrir o que esta errado.

Boa tarde Stefano, Esse erro ocorre em qual momento (gerar o XML, ao assinar, ao validar, ao enviar, ...)? Os XMLs de envio e de retorno foram gerados? Se sim, favor anexar.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Mateus, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e faça os testes usando o programa exemplo. Note que acrescentei a cidade no arquivo Cidades.ini e no arquivo Pronimv2.ini a URL. Uma pergunta essa URL é de homologação ou de produção? Esse erro ocorre quanto usamos schemas errados para validar o lote antes do seu envio.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde a todos, Você estão utilizando o arquivo Cidades.ini e NotaBlu.ini que se encontram no repositório? Pelo jeito não estão, pois acabei de fazer um teste de envio e não tive esse erro.

Boa tarde Claudio, O componente esta configurado para salvar os arquivos XML? Se não estiver não vai salvar a atualização do mesmo. Configuracoes.Arquivos.Salvar := True;

Boa tarde Osvaldo, O seu problema é que o XML esta sendo gerado de forma correta, mas os seus schemas (arquivos XSD) estão desatualizados. Favor utilizar os schemas que se encontram na pasta: ...\Exemplos\ACBrDFe\Schemas\MDFe

Boa tarde Marcio, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia a todos, Primeiramente peço para não copiar a postagem do colega anterior, isso acaba deixando a sua postagem mais longa e o que interessa esta em apenas uma linha. Se esta com o mesmo problema simplesmente escreva, estou com o mesmo problema do colega fulano de tal. Segundo, estão com o componente com a seguinte configuração?

Bom dia Hugo, Por favor não poste como texto o conteúdo de arquivos, anexe o arquivo. Primeiramente remova do seu arquivo a seção referente ao local de coleta, pois não existe mais essas informações no XML do CT-e: [locColeta] CNPJCPF= xNome= xLGr= nro= xCpl= xbairro= cMun= xMun= UF= Segundo, acredito que o seu problema se encontra na descrição do logradouro: xLgr=AV BRASIL BOX 24,26 E 28 PAVILHAO 34, 19001 nro=19001 Possível correção: xLgr=AV BRASIL BOX 24,26 E 28 PAVILHAO 34 nro=19001 Remover: ", 19001" Faça essas correções e tente novamente.

Bom dia Jorge, Você esta usando o capicom? O calculo do Hash usando capicom não resulta em uma string de 172 caracteres?

Bom dia Claudio, Se ao imprimir o DAMDFE esta aparecendo a mensagem que o MDF-e não foi enviado, isso significa que o XML que você carregou esta sem o protocolo de autorização. Para acrescentar o protocolo de autorização ao XML é muito simples. 1. você carrega o XML usando o LoadFromFile; 2. executa o método Consultar. Qual é o erro que aparece ao tentar cancelar o MDF-e? Observação: todos os MDF-e de todos os Estados brasileiros são enviados para a SEFAZ-Virtual do Rio Grande do Sul, portanto a SEFAZ-SP não tem nada haver com o que possa estar ocorrendo.

Bom dia William, Favor atualizar todos os fontes de todas as pastas, reinstale a suíte ACBr e inicie os testes usando o programa exemplo do componente ACBrNFSe.

Bom dia Stefano, Qual é o problema que você esta enfrentando?

Bom dia Ricardo, Você tentou cancelar a nota informando somente 666 como sendo o numero da mesma?

Olá pessoal, Se tratando do MDF-e só temos apenas uma SEFAZ-Autorizadora que é a SEFAZ-Virtual do Rio Grande do Sul. A versão mais recente chamada de 3.00a tem como diferencial a tag que contem a string do QR-Code. O ambiente de produção passou a exigir essa tag a partir do dia 15/07/2019, sendo assim não faz mais sentido a propriedade de configuração: GerarInfMDFeSupl que dependendo do seu valor gerava ou não o grupo <infMDFeSulp que contem a tag <qrCodMDFe>. Foi removido a condição para gerar ou não o grupo <infMDFeSupl>, pois agora esse grupo tem que existir no XML e a partir do dia 01/10/2019 não teremos mais a propriedade de configuração. Ao atualizar os fontes a partir do dia 01/10/2019 poderá ocorrer erro de compilação e ou de execução por conta dessa propriedade que não vai mais existir. A solução para esse problema é muito simples: 1. remover dos fontes da sua aplicação todas as linhas que fazem referencia a propriedade GerarInfMDFeSupl. 2. abrir os arquivos DFM que contem o componente ACBrMDFe e remover a linha que contem a propriedade GerarInfMDFeSupl. Feito isso basta compilar a sua aplicação com a opção Build.