Italo Giurizzato Junior

Bom dia a todos, Vamos ao nosso velho e amigo Nota Técnica 2013/005 versão 1.22 página 46 campo #14 ( dhSaiEnt ) na coluna observação temos qual é o formato desse campo e uma observação extra. Por favor leiam o que esta escrito nessa observação extra.

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.

Nilson, Já esta no repositório favor testar. Detalhe achei por bem manter o mesmo nome, tanto as notas autorizadas como as denegadas vão ter o seguinte nome: <chave>-nfe.xml Com a alteração do nome iriamos ter dois XMLs o <chave>-nfe.xml sem o protocolo e o <chave>-den.xml com o protocolo. E isso poderia causar muita confusão. Outra coisa se em um lote com 10 notas uma for denegada o DANFE não será impresso automaticamente, pois o componente não trata as notas denegadas como confirmadas, somente as notas autorizadas são tratadas como confirmadas e somente estas o DANFE é impresso automaticamente. Mas nada impede que depois você carregue o XML de uma nota denegada e imprima o seu DANFE, que por sinal tem que constar que a mesma esta denegada.

Nilson, Pelo manual o status 302 aparecia como sendo uma rejeição e não como uso denegado. Vamos incluir o 302 para que o XML receba o protocolo de denegação. Muito obrigado pelos arquivos em anexo, assim fica muito mais fácil.

Boa tarde Cleiver, Muito obrigado pela colaboração, já esta disponível a correção.

Boa tarde Luis, Quando você checa a chave retornada em items[ I ].resNFe.chNFe <> '', esta pegando o resumo das notas destinadas a você, é isso que você quer? Você deixou claro que deseja obter os eventos de manifestação do destinatário, sendo assim você deve checar se Items[ I ].procEvento.Id <> '' Abra a unit pcnRetDistDFeInt.pas para saber quais são propriedades alimentadas quando é retornado um Evento.

Boa tarde Nilson, Você esta com todos os fontes atualizados? Pois acabo de verificar e pelo que vi se a SEFAZ retornar o status 110 - Uso Denegado será incluído sim o protocolo de denegação ao XML da nota.

Alexandre, Você chegou a abrir esse XML com o bloco de notas? Então abra para confirmar o que vou mostrar: <?xml version='1.0' encoding='UTF-8'?><nfeProc versao='3.10' xmlns='http://www.portalfiscal.inf.br/nfe'><NFe xmlns="http://www.portalfiscal.inf.br/nfe"><infNFe versao="3.10" Id="NFe41151104675210000130650020000000041002659809">(...) Esta vendo a diferença? Esse XML com certeza não foi gerado pelo ACBr. Esta vendo a bagunça ao gerar o XML o valor da atributo versão (grupo infNFe) é colocado de forma correta entre aspas, mas após receber o protocolo de autorização da SEFAZ o XML recebe o grupo nfeProc até ai esta correto, mas os atributos versão e xmlns tem os seus valores entre apostrofe e isso esta errado.

Alexandre, Post como anexo o XML.

Boa tarde Pedro, No componente não existe nada que possa definir ou não a criação da TAG a não ser se a propriedade IEST for alimentada com uma string vazia. Sendo assim, verifique na sua rotina se após alimentar a mesma não existe nenhuma outra linha que esteja "zerando" o seu conteúdo.

Boa tarde a todos, Régys, desculpa mas tenho que descordar, na NT 2015/003 versão 1.40 consta sim a TAG vICMSUFRemet - Valor do ICMS interestadual para a UF do remetente (Nota: A partir de 2019 esse valor será zero). Essa TAG esta presente no novo grupo <ICMSUFDest> por sinal é a última TAG e esta presente também nos totais. O ACBrNFe já contempla essa TAG.

Boa tarde Alexandre, Você tem certeza que ao ler o atributo chamado versao esta retornando o conteúdo do atributo xmlns ?

Boa tarde Edison, O componente ACBrNFe possui uma propriedade de configuração chamada VersaoDF, qual é o valor atribuído a ela? Tem que ser ve310.

Bom dia Murilo, O componente esta configurado para salvar? Configuracoes.Arquivos.Salvar := True; Se sim, é para salvar um arquivo chamado: <chave>-resNFe.xml este arquivo contem o resumo da nota que foi emitida contra o CNPJ do destinatário. Favor verificar se a data de emissão que consta nesse arquivo realmente é a data de emissão da nota. Ao obter o retorno do DistribuicaoDFe você pode ler a propriedade Schema, esta vai conter os seguintes valores: schresNFe, schresEvento, schprocNFe e schprocEventoNFe Se você deseja somente os resumos e as notas você pode filtrar por schresNFe e schprocNFe através de um IF ou CASE.

Bom dia Marcio, Ontem em casa fiz um teste com o provedor Betha que também existe tanto RPS quanto Lote assinados e o resultado foi positivo. Como foi necessário fazer alterações nas classes do ACBrDFe, estou aguardando uma aprovação da equipe ACBr para estar liberando os fontes alterados.

Bom dia Daniel, Ocorreram varias alterações nos fontes, caso não esteja com os fontes atualizados, por favor atualize e teste novamente.