bnobre

Olá Sérgio, Na verdade essa realmente seria a solução mais lógica, gravar só após a certeza da nota ter sido emitida. Mas a problemática não é só essa, ao menos que eu tenho observado nesses únicos dois clientes A3 que tenho, o problema maior é o fato do certificado ficar "travado" e gerar os problemas que relatei, não enviar a nota no comando ENVIAR e as vezes pedir até a senha gravada. Com isso vou checar a nota, ver que ela não foi enviada e vou continuar NÃO conseguindo enviar. Quanto ao fator internet, não quis dizer que bloqueia, só observei que coincidentemente tenho esses problemas com o certificado após certas falhas com a internet. Você emite sem problemas com o A3? Sua rotina no envio é similar a minha (explicada na abertura do tópico)? Nesses 2 clientes, por exemplo, logo que instalei recebi o erro 12057, coisa que no A1 não tenho, resolvi pela dica em http://scansist.blogspot.com.br/2015/02/corrigindo-erro-requisicao-12031-e.html, existe mais algum procedimento específico à se realizar para se trabalhar com o A3?

Eu fiz o seguinte... Como não gerava o xml... logo após assinar e antes de validar, eu mandei copiar o conteúdo de ACBrNFe1.NotasFiscais.Items[0].XML para o Clipboard. Com isso colei em um xml e verifiquei o mesmo. O problema era o CRT errado, gerando ICMSSN ao inves de ICMS00. Após isso os outros erros passaram a gerar XML na pasta de Logs. Pelo que pude entender esse tipo de erro do CRT (por hora), ao menos, não grava log.

Olá Italo... Conforme sua orientação, tentei localizar o arquivo efetuando a busca do explorer por todo o HD. Realmente não criou o XML.

Olá a todos, estou tento um sério problema com certificados do tipo A3 na emissão de NFC-e. Basicamente meu aplicativo executa os comandos para inserção dos dados da venda no banco e tenta enviar a NFC-e, em caso de erro de internet ele emite em contingência, do contrário ele descarta as mudanças feitas no banco. Tal rotina funciona perfeitamente em todos os meus clientes, exceto em 1 que possui esse tipo de certificado. É um comércio pequeno, onde o próprio dono é o vendedor. O que ocorre no mesmo é que em um momento qualquer ele tenta enviar a nota, a mesma não é enviada, não retorna erro nenhum e as mudanças no banco são concretizadas. Vira e mexe dá isso e sou obrigado a desfazer as alterações, além de voltar a numeração da NFC-e. Achei que o problema fosse no Windows dele e como esse problema só ocorre as vezes, não dei muita importância. Agora acabo de implantar o aplicativo em outro cliente bem maior que usa esse tipo de certificado. Simplesmente no segundo dia começou dar esse problema. O aplicativo executa os comandos de inserção dos dados no banco, tenta enviar, não dá erro nenhum e grava as mudanças. Eu vi pessoalmente, o problema realmente se dá no certificado pois em dado momento o aplicativo até pediu a senha do mesmo, mesmo já estando configurada, tive que reiniciar para parar de pedir. Formatei a máquina e o problema persiste. As cadeias e o certificado em si estão aparentemente instalados normalmente, acesso os portais do governo sem problema. Uma coisa que observei no problema citado, em ambos o clientes, é que o mesmo começa a surgir quando ocorre uma falha na internet, e as vezes mesmo voltando a internet, sou obrigado a reiniciar o micro para cessar o problema, como se o certificado tivesse travado. Os amigos com experiência nessa modalidade de emissão com A3 possuem essa problemática ou alguma outra? Alguma dica para solucionar o problema? Já estou quase desistindo de trabalhar com esse tipo de certificação . Desde já agradeço a atenção de todos.

Oi Italo... Acabei de fazer... Continua não salvando

Olá a todos, Estou recebendo a mensagem "Falha na validação dos dados da nota" ao tentar emitir uma NF-e. Apesar da propriedade ACBrNFe1.Configuracoes.Arquivos estar setada como True, o XML não está sendo salvo na pasta Logs, consequentemente eu não consigo checar o mesmo para analisar o problema. Não deveria salvar lá?

Para os que estão passando pelo mesmo problema, dica é: 1º - Liberem o acesso para TODOS na guia de Segurança da pasta C:\Windows\system32\spool, incluindo o seu conteúdo Não sendo o suficiente, façam também: 2º - Criem um mesmo usuário, exemplo TESTE, em ambas as máquinas. Testem, funcionando podem excluir o usuário em ambas as máquinas que continuará funcionando. Abraços

Bem... Finalmente todas as notas foram enviadas... Como o SVRS ficou amarelo o dia todo, e as notas foram enviadas agora pouco... Suponho que tenha sido um problema no servidor da SEFAZ... Desde já agradeço a atenção de todos

Bem, acabo de consultar as notas 3286 e 3287 em "http://www4.fazenda.rj.gov.br/consultaDFe/paginas/resultadoChaveAcesso.faces?cid=4" A 3286 foi enviada e autorizada 10 minutos após ter sido emitida offline. A 3287 foi enviada e autorizada 20 minutos após ter sido emitida offline. As outras duas ainda não foram enviadas. Quantos as 2 primeiras, deveria receber erro de DUPLICIDADE, e as outras 2 enviar normalmente. Mas só recebo o erro EM BRANCO.

Entendi Régys, mas para eliminar tais hipóteses testei em minha própria máquina e em outro micro também, como estou conseguindo enviar outras notas não pode ser bloqueio na internet nem certificado vencido ou demais problemáticas. Essas notas não "saem" de micro algum. :-/

Olá Daniel, Bem, para resumir focarei em uma das 4 notas... Estou anexando o XML na mensagem. Como pode observar o mesmo foi emitido de forma OFF-LINE e se encontra válido. Com os comandos acima não consigo enviar a nota de forma online. Recebo o erro já mencionado. Observei que o SVRS encontra-se em amarelo o dia todo. Sou do RJ. Poderia ser essa a causa do problema? Desde já agradeço a atenção 3286.xml

Olá a todos, Acabo de receber a ligação de um dos meus clientes... Ficaram 4 notas em contingência e tenho um aplicativo que fica tentando enviar as mesmas de 5 em 5 minutos, mas não estão indo. O mesmo possui um log em caso de erros, e ao analisar o log do mesmo para checar os erros me espantei com a mensagem "EM BRANCO". O código do app é bem simples e funciona a meses, nunca deu problema, executando de 5 em 5 minutos nas notas que foram emitidas OFF-LINE: ACBrNFe1.NotasFiscais.Clear; ACBrNFe1.Configuracoes.Geral.FormaEmissao := teNormal ; ACBrNFe1.NotasFiscais.LoadFromString(z_read_nfcevendasxml.AsString); ACBrNFe1.Enviar(lote,True,True); Peguei a base do cliente e tentei enviar direto da minha máquina, para confirmar que não é nada no cliente e o que o Delphi me retornaria... Realmente o erro está em branco, "Project contingencia.exe raised exception class EACBrDFeException with message ''. Process stopped. Use Step or Run to continue" E agora??? O que fazer??? Desde já agradeço a atenção de todos

OK... Só um detalhe... Estou fazendo o procedimento correto de compartilhar e usar o endereço como porta? Se sim, vocês usam normalmente no Windows 7 dessa forma?

Entendi Daniel... A questão é que após descobrir essa "excepcionalidade" eu fiz questão de testar em outros 4 clientes... Troquei as impressoras de modelos e fabricantes distintos de lugar, colocando em micros com o Windows 7 para reproduzir o problema, o compartilhamento via driver de spool funciona normalmente, imprimindo DANFE NFC-e do Fortes, tudo perfeito... Só não pega via ACBrPosPrinter. Concordo contigo que tudo leva a crer ser permissionamento no Windows 7, mas qual? Via driver de spool funciona normalmente... Acesso os compartilhamentos de arquivos normalmente. Firewall desativado. O que mais fazer?

Então esse problema é um fato??? Se sim, na prática não posso usar o componente ACBrPosPrinter nesse caso??

Olá a todos, Eu possuo uma aplicação que efetua impressões através do ACBrPosPrinter em rede. Até hoje nos clientes que uso, nunca tive problemas. Basicamente instalo em uma máquina, compartilho a mesma e tanto na máquina principal, quanto nas outras estações, configuro em porta o seguinte endereço: "\\ip_maquina_impressora\compartilhamento_impressora". Só que hoje ao tentar instalar em um cliente, descobri um problema... Se a mesma for instalada em um micro com Windows 7, simplesmente não imprime das estações Windows 7 em rede. Nunca percebi porque até então a máquina nos clientes onde instalava as impressoras "por sorte" eram sempre Windows XP. O "interessante" é que se a máquina com impressora tiver Windows 7, apenas as estações que tiverem Windows XP conseguem imprimir...Resumindo: Impressora em Windows XP - Qualquer estação Windows conseguem imprimir Impressora em Windows 7 - Somente estações Windows XP conseguem imprimir Já estou a tempos usando o trunk2, e nesse momento estou na Revisão 10481. O que pode ser esse problema? Desde já agradeço a atenção de todos

Perfeito sua observação Italo... A princípio, pelo que analisei todos os XMLs de cancelamentos são formados, como já havia dito, na primeira linha com "<?xml version="1.0" encoding="UTF-8"?>" e o restante com a tag <procEventoNFe> obtida pela consulta da chave de acesso. Farei a montagem dessa forma. Mas alguém sabe confirma essa informação referente a montagem? Minha lógica está certa?

Agradeço Régys

Olá a todos, Estou querendo fazer um procedimento na saída do aplicativo, onde o aplicativo checa a validade do certificado da máquina e avisa se o mesmo estiver para expirar em até 30 dias. Até aí tudo bem, estou usando a função ACBrNFe1.SSL.CertDataVenc, mas a questão é que salvo o serial do certificado em minha base. Nas máquinas que possuem certificado funciona corretamente, mas nas outras que não o possuem, o aplicativo gera uma exceção devido o certificado ser inexistente no micro em questão. Portanto gostaria de saber se existe alguma função no aplicativo que checa a existência do certificado no micro? Desde já agradeço a atenção

Olá... Rapaz, no momento que você consegue fazer o envio ONLINE da sua nota, que inicialmente foi emitida OFFLINE, o próprio componente salva o XML com o protocolo no diretório especificado por você. Dá uma conferida ai

Entendi Régys... Eu faço exatamente isso, só leio o XML (que fica gravado em minha base) pelo ACBrNFe1.NotasFiscais.LoadFromString. O "interessante" disso tudo é que como falei, se eu gerar sem pular o nItem ele assina normal, passa normal no Validar Assinatura do projeto de exemplo do ACBR. Mas se eu, com o mesmo código, pular o item, aí já era, ele dá erro na assinatura, testado no Validar Assinatura. Enfatizando, só em emissões OFFLINE, ONLINE tanto faz pular ou não. A única coisa que mudei no meu código foi isso, ao invés de: Prod.nItem := dtm_banco.z_produtos_itensitem.AsInteger; //podendo pegar um valor "pulado" Agora faço Prod.nItem := x; // Número sequencial, para cada item deve ser incrementado Só isso bastou para parar de dar erro.

Entendo Regys, mas pode ter certeza quanto as afirmações que fiz acima... Eu testei e retestei isso o dia todo... Só não sei exatamente qual revision estava usando anteriormente no momento em que o componente ignorava a minha programação ao gerar o XML OFFLINE. E atualmente está como eu falei, se gerar o XML OFFLINE e apenas nesse caso, pulando a numeração, o componente assina errado, gerando o erro Rejeicao: "Assinatura difere do calculado". Seguiu a sequência, assina certo. Pode testar ai.

Entendi Italo, Mas você me orientou no passo 3. "Extrair desse retorno os dados do registro do evento desejado" e no passo 4. "Montar o *-procEventoNFe.xml se utilizando do conteúdo do *-ped-eve.xml mais os dados que foram extraídos no item 3." Se não posso extrair a tag <procEventoNFe> desse retorno, quais dados devo extrair para concatenar com o "*-ped-eve.xml" afim de montar o "*-procEventoNFe.xml"?

Olá a todos, descobri o que ocorre... Eu meu aplicativo no ato da venda, conforme o usuário vai inserindo os itens, o software vai adicionando a numeração referente ao número do item... Por exemplo: 1 - Produto 1 2 - Produto 2 3 - Produto 3 Durante a venda, ele pode excluir um dos itens, e a numeração fica "pulada", como no exemplo abaixo onde ele exclui o item 2: 1 - Produto 1 3 - Produto 3 Eu sempe usei essa numeração "pulada" na tag <det nItem="X"> de cada produto e até ontem nunca tive problema. Observando agora os XMLs do dia 17-11-15 para trás, observei que as notas emitidas ONLINE gravam no XML a numeração do item pulada mesmo (conforme eu programei) e sempre passaram normal. Mas eu tive uma surpresa ao observar os XMLs de notas emitidas OFFLINE, vi que a numeração dos itens não pulou mesmo eu programando para pular (creio que o componente fez isso automaticamente ao ver que era emissão OFFLINE) e também nunca tive problema. No dia 18-11-15 atualizei o componente e meu aplicativo. Após isso que comecei a receber o tal erro "Rejeicao: Assinatura difere do calculado" em algumas notas emitidas OFFLINE apenas. Como não vi nenhuma outra anormalidade além da numeração do item "pulada", resolvi testar "sem pular" pois agora observei que no caso da CONTINGÊNCIA ele parou de ignorar minha programação e "pulou". Ao seguir a sequência corretamente o problema foi sanado. Mas as notas emitidas ONLINE, que sempre pularam, não estão apresentando erro nenhum até o momento. Depois de toda essa análise, me surgiram as seguintes dúvidas: 1º - O componente realmente gera o erro "Rejeicao: Assinatura difere do calculado" em emissão OFFLINE quando a sequencia da numeração dos itens é "pulada"? 2º - Se sim para a pergunta anterior, porque em emissão ONLINE não ocorre tal problema? 3º - Porque antes o componente sequenciava a numeração (ignorando a minha programação) apenas nas emissões OFFLINE e agora não mais o faz? Desde já agradeço a atenção

Olá a todos, Sou do RJ, desde ontem as 15:00 em um cliente estou com um NFC-e em contingência preso, ao tentar enviar ele retorna "Rejeicao: Assinatura difere do calculado". Após emitir tal nota, de ontem para hoje ele só emitiu mais 2 notas em contingência e todas apresentaram o mesmo defeito e não consigo enviar. Os envios em modo normal estão perfeitos. Não existe nenhum caracter especial nas notas. Estou perdendo o prazo de 24 horas da primeira e daqui a pouco vou perder das outras, o que poderia ser?