Italo Giurizzato Junior

Bom dia Wagner, O cliente da sua cliente não pensou na hipótese que ele pode receber um CT-e e uma NF-e com o mesmo nome, ou seja, 10500.xml e ao salvar o segundo XML vai ocorrer a sobreposição. Página 130 do Manual do CT-e versão 3.00 temos: 6.2 Padrão de Nomes para os Arquivos Visando facilitar o processo de guarda dos arquivos pelos legítimos interessados, criou-se um padrão de nome para os diversos tipos de arquivos utilizados pelo sistema CT-e. São eles: • CT-e: O nome do arquivo será a chave de acesso completa com extensão “-cte.xml”; (...)

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

Bom dia Lopes, Vai ai uma dica: Como e quando usar o SVC - SEFAZ-Virtual de Contigência

Bom dia Carlos, O componente ACBrNFe esta 100% compatível com todas Notas Técnicas e Manuais publicados pelo ENCAT e disponibilizados pelo Portal Nacional da NF-e. Os manuais que você mencionou estão desatualizados e não tem previsão de atualização. Sugiro que você se baseie pelos Manuais e Notas Técnicas do ENCAT.

Bom dia mysyfy, Com essa alteração não vai gerar efeito colateral ao consultar os eventos: 2050, 2060 e 3010? Visto que esses três eventos que mencionei também devemos informar o nrInscEstab.

Boa tarde Ângelo, Os componentes ACBrNFe, ACBrCTe, ACBrMDFe o LoadFromFile (por exemplo) que se utiliza do LoadFromString possui um parâmetro que determina se é apendas para carregar o XML ou se é para gerar o XML novamente, veja: function LoadFromFile(const CaminhoArquivo: String; AGerarNFe: Boolean = False): Boolean; function LoadFromStream(AStream: TStringStream; AGerarNFe: Boolean = False): Boolean; function LoadFromString(const AXMLString: String; AGerarNFe: Boolean = False): Boolean; function LoadFromIni(const AIniString: String): Boolean; Note que somente o LoadFromIni não tem o parâmetro AGerarNFe os demais tem e o seu valor padrão é False. Como o Elton disse, o LoadFromString (que é utilizado pelo LoadFromFile e LoadFormStream) tem por objetivo carretar o XML de terceiros, ou seja, não foi gerado pelo componente. Neste caso o componente checa se o XML esta assinado ou não, caso não esteja será assinado, validado e por fim salvo em disco, dai o motivo do SaveToFile. Já o LoadFromStringIni tem como objetivo carregar os dados do evento que se encontram em um arquivo INI, gerar o XML, assinar, validar e salvar em disco. Logo não devemos em hipótese nenhuma remover o SaveToFile. Se esta ficando dois XML na pasta referente ao mesmo evento, isso significa que a sua aplicação esta gerando e salvando o XML com uma nomenclatura e o componente com outra. Se você adotar a mesma nomenclatura, mesmo o componente salvando novamente só teremos um arquivo, visto que o Windows não aceita dois ou mais arquivos com o mesmo nome.

Boa tarde, Analisando os XMLs aparentemente esta correto o que você fez. Mas tentou fazer a o pedido de Download informando o ID do evento em vez do numero do recibo?

Boa tarde Milton, O que diz a NT (vou colocar em negrito o que considero importante): Sendo assim, a partir dessa Nota Técnica será possível um contribuinte cancelar uma NFC-e que foi emitida em duplicidade. Esse tipo de situação pode acontecer quando um contribuinte emite uma NFC-e (NFC-e 1), porém, por algum motivo, não obtém resposta, ficando pendente de retorno, e em seguida emite outra NFC-e (NFC-2), normalmente em contingência, para acobertar a operação. Depois é verificado que a “NFC-e 1” também foi autorizada, e sendo assim temos duas NFC-e acobertando a mesma operação. Acontecendo isso, o contribuinte poderá solicitar o cancelamento, no prazo não superior a 168 horas, da NFC-e emitida em duplicidade e que não acobertou a operação (NFC-e 1), tendo que referenciar a NFC-e que substituiu (NFC-2) aquela que está sendo cancelada. Resumindo: Foi emitida a NFC-e 1 segundo o tipo de emissão Normal ( 1 ) para acobertar a venda 1. Como o estabelecimento comercial não obter resposta da SEFAZ informado que a nota foi autorizada ou não, foi emitida uma a NFC-e 2 exatamente igual a anterior, mas segundo o tipo de emissão Contingência ( 9 ). Verificou-se depois que ambas as notas foram autorizadas, logo uma tem que ser cancelada dentro do prazo de 168 horas. Conforme o descrito a nota a ser cancelada é a NFC-e 1, vide rotina abaixo: ACBrNFe1.EventoNFe.Evento.Clear; with ACBrNFe1.EventoNFe.Evento.Add do begin infEvento.chNFe := ' Chave da NFC-e cujo tpEmis = 1 (Normal), portanto é a nota a ser cancelada '; infEvento.CNPJ := CNPJ; infEvento.dhEvento := now; infEvento.tpEvento := teCancSubst; infEvento.detEvento.xJust := ' Justificativa, minimo 15 e máximo 255 caracteres '; infEvento.detEvento.nProt := Protocolo; infEvento.detEvento.cOrgaoAutor := 35; // Código da UF do emitente da nota infEvento.detEvento.verAplic := '1.0'; infEvento.detEvento.chNFeRef := ' chave de acesso da NFC-e substituta, tpEmis = 9 (Contingência offline), portanto nota a prevalecer '; end; ACBrNFe1.EnviarEvento(StrToInt(idLote)); Espero ter ajudado.

Boa noite Carlos, É preciso "debugar" para saber o local exato que ocorre o AV.

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

Bom noite Milton, O Cancelamento por Substituição é um evento como é o evento de Cancelamento, a única diferencia é que o tipo do evento é outro e tem algumas informações a mais. Realmente o programa exemplo não tem um botão para cada tipo de evento.

Bom noite Werner, Acredito que a troca deveria ser automática para todos os serviços, mas analisar os fontes do componente. Encontrei o problema, era no arquivo INI do provedor. Favor atualizar os fontes, note que fiz uma alteração no arquivo INI.

Bom dia Anderson, Para imprimir o DABPE é necessário ter o XML, caso contrario não tem como, uma vez que as informações a serem impressas se encontram no XML. Agora se o funcionário deletou o XML, deve ser punido pois rasgou um documento fiscal com validade jurídica.

Use as DLLs da pasta: ...\DLLs\OpenSSL\1.0.2.13\x86

Bom dia, O DANFE gerado tanto pelo Fortes quanto pelo Fast Report não prevê a impressão da chave da nota em código de barras no canhoto, apenas o numero e a série conforme consta nos modelos que se encontram no Manual da NF-e. Para uma transportadora, no meu entendimento isso seria interessante no canhoto do CT-e, para que a mesma pudesse realizar a baixa e dar como finalizado o serviço de transporte daquela mercadoria. Quando todos os destinatário passarem a realizar a manifestação do destinatário (evento envidado para a SEFAZ pelo destinatário da mercadoria) o canhoto que consta na nota não vai fazer mais sentido, pois a manifestação nada mais é do que o canhoto eletrônico. O emitente da nota através do serviço DistribuicaoDFe poderá obter os eventos (manifestação do destinatário) e fazer uma baixa automática em seu sistema.

Alexandre, A ideia que esta por de traz do DistribuicaoDFe e Manifestação do Destinatário é exatamente essa. 1. Criar uma aplicação que a cada 1 minuto execute o método DistribuicaoDFePorUltNSU (sempre passado o valor do UltNSU retornado pela execução anterior). Se o valor de UltNSU for igual a MaxNSU a próxima execução vai ocorre somente depois de 30 minutos de espera. Como apresentado nos meus dois artigos que você já leu, o método acima retorna tanto os resumos quanto as notas completas. A ideia é ter uma tabela no banco de dados, onde devemos salvar as informações do resumo, para que sejam apresentados em um grid, desta forma um funcionário poderá manifestar corretamente cada uma das notas. Se no retorno temos a nota completa isso significa que a nota foi manifestada, neste caso devemos salvar na mesma tabela, no registro referente ao resumo dessa nota, o caminho onde esta o XML completo da nota, ou até mesmo o XML da mesma. 2. Cria uma outra aplicação onde o funcionário possa ver o grid (relação dos resumos) e realizar a manifestação. Abaixo a tela da minha aplicação, eu preciso mudar, pois ainda a "consulta" é manual e não automática como descrevi acima.

Bom dia, Deve ter alguma coisa errada com os seus fontes ou configuração do componente, pois acabo de fazer um testes e não ocorreu nenhum erro. Tente mudar o valor do SSLType para TLS 1.2

Milton, Esse é um erro de validação. Ele ocorre no programa exemplo ou na sua aplicação? No programa exemplo temos um botão para Validar o XML que contem a seguinte linha: ACBrNFe1.NotasFiscais.Validar; Esse é o método que realiza a validação do XML que foi previamente carregado. Temos o botão Criar e Enviar que contem a seguinte linha: ACBrNFe1.Enviar(vNumLote,True); Se formos analisar o método Enviar que se encontra na unit ACBrNFe temos os seguintes linhas: NotasFiscais.Assinar; NotasFiscais.Validar; Result := WebServices.Envia(ALote, Sincrono, Zipado); Note que primeiro o método Enviar executa o método Assinar para que o XML seja assinado, depois executa o método Validar (o mesmo que é executado pelo botão Validar XML), por fim é executado o método Envia que se encarrega de estabelecer a conexão com a SEFAZ e enviar o Lote contendo as notas. Como você pode ver ambos os botões do programa exemplo se utilizam do mesmo método para realizar a validação do XML.

Bom dia Werner, Acabei de fazer um teste, no ambiente de homologação ao consultar a situação do lote ocorreu o erro 400, mas ao fazer o mesmo teste no ambiente de produção, funcionou e me retornou: Numero do protocolo de recebimento do lote inexistente na base de dados.

Milton, Na sua ultima postagem é dito que ocorre problema ao enviar, correto? Qual seria esse problema ou erro?

Bom dia Alysson, A ideia é boa, vamos incluir na nossa lista de melhorias.

Bom dia, Após alterar o arquivo ACBrCTeServicos.ini você executou o BAT: Compila_RES ? Se sim, reinstalou os componentes usando o ACBrInstall_Trunk2?

Bom dia Milton, Uma coisa é erro de validação outra é rejeição. Erro de validação ocorre antes do envio e faz com que o mesmo não ocorra. O que pode provocar erro de validação: 1. XML gerado de fora do layout; 2. Dados não validos, por exemplo CNPJ com 15 dígitos sendo que o correto é 14; 3. Schemas (arquivos XSD) errados (desatualizados), neste caso devemos sempre utilizar os schemas que se encontram na pasta: ...\Exemplos\ACBrDFe\Schemas\NFe Se não ocorrer erro de validação a nota é enviada para SEFAZ, esta por sua vez faz a sua checagem que pode resultar em: 1. Nota Autorizada, todos os dados estão corretos e a venda esta autorizada; 2. Nota Denegada, todos os dados estão corretos, mas a venda não esta autorizada pois o Destinatário ou o Emitente esta com alguma pendencia no Fisco; 3. Nota Rejeitada, uma ou mais dados estão incorretos, por exemplo foi informado o CNPJ da matriz e a IE da filial; Quando uma nota é rejeitada devemos providenciar a correção da informação errada apontada pela rejeição (campo xMotivo) e enviar novamente.

Bom dia a todos, Junior, o XML esta sendo gerado corretamente inclusive com a tag <infAdProd>, conforme consta no XML que o Laudelino anexou, que por sinal foi até autorizada pela SEFAZ. A questão é a impressão no DANFE dessa informação, acredito que alguma propriedade de configuração do DANFE esteja desabilitada.

Bom dia Alexandre, Antes tínhamos os métodos ConsultarNFeDest e DownloadNFe, para obter o resumo e a nota completa respectivamente. Lembrando que para obter a nota completa era necessário enviar o evento de Manifestação do Destinatário. A SEFAZ desativou esses dois serviços (Consulta e Download) e criou um novo, chamado DistribuicaoDFe. No componente ACBrNFe temos 3 métodos: DistribuicaoDFePorUltNSU, DistribuicaoDFePorNSU e DistribuicaoDFePorChaveNFe. O serviço DistribuicaoDFe disponibilizado pela SEFAZ permite ao mesmo tempo obter o resumo como também a nota completa do fornecedor. Para obter a nota completa ainda se faz necessário o envio do evento de Manifestação do Destinatário. Acredito que tudo o que escrevi acima você já saiba, sendo assim peço que leia os dois artigos que se encontram em: Como obter o XML do Fornecedor Caso ainda tenha duvidas é só perguntar.