Italo Giurizzato Junior

Boa tarde Douglas, Entre em contato com a SEFAZ-MG o problema é la.

Orlando, Eu não tenho um exemplo de rotina para lhe dar uma vez que ainda não implementei o EPEC na minha aplicação. Mas lembre-se que o EPEC é um evento e a estrutura é igual para todos os eventos, alguns tem algumas informações a mais do que outros, mas a estrutura é igual. Não existe nenhum método especifico para esse evento.

Boa tarde Allan, Qual é a rotina que esta com o erro?

Juliano, Se você faz a consulta somente pela chave o que temos como resposta é o resultado da consulta. Por outro lado se você carregar o componente com todos os dados da NF-e que deseja consultar, você terá nas propriedades que mencionei o XML completo, ou seja, assinado e protocolado.

Boa tarde Douglas, Só realizamos alterações dessa natureza mediante a publicação de Nota Técnica, assim que for publicada tenha certeza que faremos os ajustes necessários.

Boa tarde Juliano, Já tentou algo do tipo: ACBrNFe.NotasFiscais.Items[J].XMLAssinado ou ACBrNFe.NotasFiscais.Items[J].XMLOriginal

Boa tarde Ronaldo, Essa alteração não será aplicada pois tivemos diversos problemas com outros desenvolvedores que estavam atribuindo valores inválidos a propriedade ID. Chegamos a conclusão que o conteúdo da propriedade ID tem que ser gerada pelo próprio componente com os dados atribuídos as outras propriedades usadas na geração do mesmo. Te faça uma pergunta, você gera por fora o conteúdo da propriedade ID do Inutilizar Numeração? Acredito que não, sendo assim por que você quer gerar por fora a chave que é o conteúdo do atributo ID da nota? Não faz nenhum sentido, você pode muito bem deixar o componente gerar essa informação e depois ler: chave := ACBrNFe.NotasFiscais.Items[ X ].NumID;

Boa tarde Orlando, Se a rejeição diz que foi informado indevidamente isso significa que mais alguma coisa esta faltando. Primeiro o grupo de ICMSUFDest para ser aceito tem que atender uma meia duzia de condições. Lhe convido a ler a regra NA01-30 que encontra-se na página 11 da Nota Técnica 2015/003 versão 1.40 Verifique se o XML que esta sendo gerado satisfaz todas as condições impostas por essa regra.

Boa tarde Orlando, Lhe convido a ler a Nota Técnica 2014/001 versão 1.10 que trata sobre o EPEC. São apenas 20 páginas, leia com muita atenção a página 5. O fluxo é mais ou menos esse que você postou, mas leia a NT para obter mais alguns detalhes.

Boa tarde, Não existe mais no XML os grupos de retirada e de entrega, logo se existe alguma coisa nesse sentido no DACTE tem que ser removido.

Orlando, Não vai funcionar a data de emissão tem que ser igual a do servidor da SEFAZ e este esta com a data de hoje.

Fechado por duplicidade.

Orlando, Não adianta você alterar a data do computador ou a data de emissão que consta no XML o servidor da SEFAZ vai comparar a data do servidor com a data de emissão que consta no XML e elas tem que ser iguais, inclusive a hora tem que ter uma variação máxima de 1 minuto ou 5 dependendo da UF. Você esta realizando os testes em ambiente de homologação?

Bom dia, Editei a sua postagem. Não informe o nome de ninguém da Secretaria da fazenda ou do fisco, eles não lhe dão essa autorização, no máximo coloque a resposta deles.

Graça, Os arquivos que você mencionou são de envio e resposta mas note que eles possuem a palavra soap no nome. Eles contem a estrutura completa do XML enviado e recebido da SEFAZ que nos auxiliam em muito para detectar erros. Para que os mesmos não sejam salvos basta: ACBrCTe1.Configuracoes.WebServices.Salvar := True;

Como você esta falando em offline estou entendendo que a nota seja uma NFC-e, correto? Sendo assim, não existe essa história de enviar offline. Você gera a Nota segundo o tipo de emissão offline e imprime o DANFE. Depois a nota tem que ser enviada sem nenhuma alteração para SEFAZ quando os problemas forem sanados. Não se deve alterar o tipo de emissão para normal ao ser enviada para SEFAZ. Só é necessário a consulta caso a nota que foi enviada não recebeu o protocolo de autorização, por motivo de falha no retorno.

Graça, Independente do ambiente devemos deixar: ACBrCTe1.Configuracoes.Arquivos.Salvar := True; Uma vez que o problema de a SEFAZ não retornar o protocolo após o envio também pode ocorrer no ambiente de homologação.

Quando você emite uma nota Offline, depois ela tem que ser enviada para SEFAZ. Ela foi enviada? Você alterou algum dado dessa nota ao envia-la para SEFAZ, por exemplo o tipo de emissão?

Bom dia Graça, Os arquivos de envio e de retorno só são salvos se: Configuracoes.Geral.Salvar := True; Os arquivos que consideramos como documentos, ou seja, *-cte.xml, *-procEventoCTe.xml e *-procInutCTe.xml só são salvos se: Configuracoes.Arquivos.Salvar := True; Quais são os arquivos de envio e de retorno que estão sendo salvos quando a propriedade acima esta com o valor True?

Bom dia José, Você esta com todos os fontes de todas as pastas atualizados? Recompilou a sua aplicação com a opção Build? Tem algum fonte cujo ícone possui uma bolinha vermelha ou triangulo amarelo?

Bom dia Marcos, O b.o. é sim o apostrofe colocado de forma errada. Faz a troca que você vai ver que vai funcionar. Temos como premissa deixar os componentes ACBr em conformidade com os manuais e notas técnicas. Se os outros vazem tudo nas coxas, já não é problema nosso. Não podemos ficar arrumando um jeito de contornar os erros dos outros. Versão 5.0 do Manual da NF-e temos na página 13 item 3.2.1.1 Padrão de codificação, note que é usado aspas e não apostrofe ao declarar a codificação de caracteres, o namespace (valor de xmlns), a versão entre outras coisas. Se você folear todas as páginas desse manual, todos os exemplos de XML mostram sempre os valores dos atributos entre aspas e não entre apostrofe. Em nenhum lugar esta escrito que você pode trocar a aspas por apostrofe. Concluo que esse XML que o seu cliente recebeu esta errado.

Bom dia, Para que o DigestValue que esta no XML da NF-e ser diferente do que consta no retorno da consulta é simples, algum dado do da NF-e foi alterado, o XML foi gerado e assinado novamente, consequentemente o seu DigestValue é recalculado. Vamos a um exemplo: 1. suponha que o XML foi gerado, assinado, valido e enviado para a SEFAZ. 2. Por algum motivo não ocorreu o retorno do protocolo de autorização. 3. Para corrigir esse problema o XML é carregado e é feita a consulta. 4. Mas surge o erro informando que o DigestValue não confere. No passo 3 o XML é carregado com o LoadFromFile (por exemplo) só que esse método possui 2 parâmetros, o primeiro informamos o caminho mais nome do XML que desejamos carregar e o segundo que é opcional tem como valor padrão True, isso faz com que o XML seja gerado e assinado novamente. Por outro lado se for False, o XML é apenas carregado exatamente como ele esta gravado. Mas tem pessoas que preferem alimentar novamente o componente lendo as informações do banco de dados para gerar e assinar e depois consultar, tudo bem, mas e se nesse meio tempo alguém realizar uma pequena alteração no cadastro do destinatário, por exemplo acrescentar uma virgula no endereço ou trocar um Z por S. Isso já é suficiente para que o DigestValue seja diferente. Concluímos que é preciso avaliar como esta sendo feita essa rotina e muda-la, no meu entendimento devemos apenas ler o XML através do LoadFromFile e atribuir o valor False para o segundo parâmetro e não recriar do zero o XML. Espero ter ajudado.

Bom dia Marco, Não existe nenhuma TAG especifica para informar a Data de Embarque. Sendo assim essa informação deve ser colocada no campo de observação. Mas para que você não precise fazer esse ajuste duas vezes peça a seguradora um XML que contenha a informação.

Régys, O nome correto da TAG é vICMSUFRemet estava faltando a letra U de UF no fragmento de código postado acima.

Boa tarde, O correto é versao="3.10" o numero da versão entre aspas e não entre apostrofe ou aspa simples como alguns chamam.