Italo Giurizzato Junior

Bom dia, Os documentos que você emite, ou seja, a nota, carta de correção, cancelamento entre outros não é possível baixar através do DistribuicaoDFe. Pelo simples fato de que se você emitiu, você tem por obrigação legal de ter os XMLs desses documentos. Se você emite a nota, você tem que ter o XML da nota (*-nfe.xml). Se você emite uma carta de correção, tem que ter o XML da carta de correção (*-procEventoNFe.xml). Através do DistribuicaoDFe você consegue baixar os documentos emitidos por outras pessoas, por exemplo: a nota do seu fornecedor, os eventos de manifestação do destinatário emitido pelo destinatário da mercadoria. Para que a impressão de um evento seja completa, lembrando que a Carta de Correção é um evento temos os seguintes passos. 1. Carregar o XML da nota (*-nfe.xml) 2. Carregar o XML do processamento do evento desejado (*-procEventoNFe.xml) 3. Executar o método que imprime evento. Repito, se você é o emitente da nota, também é o emitente do evento de carta de correção, logo tem por obrigação legal possuir os XMLs de ambos os documentos.

Bom dia Caetano, Sim, esta é a solução para saber qual é o tipo de documento retornado pelo DistribuicaoDFe.

Bom dia Marcelo, O ano e mês que aparece na chave é obtido da data/hora de emissão, campo: dhEmi. Favor verificar a data/hora que esta sendo informada nesse campo.

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

Boa tarde, Pelo retorno me parece que ocorreu uma falha no servidor do provedor.

Boa tarde Israel, Uma coisa é o numero e série do RPS e outra é o numero e série da NFS-e. A sua aplicação vai gerar e enviar o RPS para o provedor e este por sua vez vai gerar e retornar a NFS-e. O numero e série do RPS deve ser controlado pela sua aplicação. Por outro lado o numero e série da NFS-e é controlado pelo provedor.

César, No caso do A3 como dito é um cartão ou token (pen-drive) não existe arquivo PFX salvo na maquina. Sendo assim você só informa o numero de série do certificado no componente. E toda vez que for estabelecer a primeira conexão será pedido a senha.

Boa tarde Dércio, Até o momento não foi disponibilizado no DistribuicaoDFe a possibilidade de baixar o XML completo da NFC-e, somente NF-e. Não sei se no Site da SEFAZ-Autorizadora da NFC-e tem alguma opção que seja possível baixar o XML.

Douglas, Você concorda que se o campo é dhEmi a SEFAZ espera que o conteúdo seja a data e hora de emissão e não somente a data, pois se fosse só a data a tag chamaria dEmi e não dhEmi. Tudo o que parece funcionar hoje mesmo fazendo errado, amanhã pode não vir a funcionar.

Boa tarde César, Faz anos que o componente ACBrNFe permite o uso dos certificado A1 e A3 (Cartão ou Token). O único problema do A3 é que não será possível o uso do OpenSLL e sim do WinCrypt e isso faz com que dependendo da versão do Windows bem como as suas atualizações vai funcionar ou não.

Boa tarde, Do dia 31/10 para hoje ocorreu atualização na sua aplicação? Se sim, ela foi devida a atualização dos fontes do componente? Se sim, chegou a comparar o XML do RPS de uma nota emitida com sucesso no dia 31/10 com o XML de um RPS emitido hoje para saber se existem diferenças estruturais no mesmo?

Boa tarde Caetano, Eu movi a sua postagem pois estava dentro de ACBrMDFe que não tem nada haver com Manifestação do Destinatário e muito menos com a NF-e. Outra coisa, você utiliza o componente ou o ACBrMonitor?

Boa tarde Douglas, Porque a hora da emissão esta zerada? dhEmi deve conter a data e hora da emissão e você esta informando somente a data.

Boa tarde Carlos, Veja se o link abaixo lhe ajuda:

Bom dia, Note que no seu arquivo INI foi informado o código 35 em cOrgao. Por outro lado a chave começa com 26, veja a chave informada em chNFe. Quem tem que emitir a CC-e é o próprio emitente da nota, se o código da UF deste é 26 porque foi informado 35 em cOrgao?

Boa tarde Werley, Favor atualizar todos os fontes, note que inclui a cidade em questão no arquivo Cidades.ini Faça os testes usando o programa exemplo do componente ACBrNFSe.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Boa tarde Marcos, Aconselho que a sua aplicação tenha um tela onde você pode definir qual é a melhor configuração para uma determinada cidade.

Boa tarde Manoel, A diferença é que o envio do CT-e OS é síncrono, sendo assim o retorno do protocolo já ocorre no retorno do envio.

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

Boa tarde Fábio, De manhã checando as postagens no fórum li relatos que o provedor Ginfes estava com problemas a alguns dias e parece que agora esta voltando ao normal. Eu acredito que o problema seja o provedor, por conta de problemas técnicos e ter chegado a parar agora o processamento deve estar no gargalo ocasionando essa lentidão.

Bom dia Ronie, Esse erro esta sendo retornado pela SEFAZ? Se sim, favor anexar o XML do CT-e que foi enviado.

Marcos, Atribua o valor xsLibXml2 a SSLXmlSignLib. Não vejo a necessidade da linha abaixo: AACBrNFSe.SSL.SSLXmlSignLib

Bom dia a todos, Outra coisa, notem a postagem do Marcos Rodrigues a tag <dhEmi> só contem a data, a hora esta toda zerada, isso esta errado. O correto é atribuir ao campo dEmi ao alimentar o componente a data e hora, em vez de atribuir somente a data em dEmi e a hora em hEmi.

Bom dia Marcos, É bem provável que seja a configuração do componente.