bnobre

Ola Régys, obrigado pelo contato. Não o tentei fazer, nem sei como faz para ser sincero. Muda muito o código para a forma assíncrona? Teria um exemplo? Irei realizar o teste conforme sua sugestão, mas ainda é estranho o fato de tal comportamento anormal ocorrer apenas nos clientes com cartão. Seus clientes com cartão funcionam normalmente?

Excelente... Valeu mesmo

Olá Régys, Grato pelo retorno. Para que possar ter uma visão bem completa, anexarei 2 units que uso. Na u_nfce_pdv.pas é que ocorre o envio, mas precisamente na procedure spb_finalizavendaClick. No ato do envio, observe que chamo dtm_banco.CarregaParametrosNFCe, presente em u_banco. u_nfce_pdv.pas u_banco.pas

Delphi 7, build 4.453

Olá a todos, Estou desenvolvendo um emissor de NF-e. No ato da emissão da NF-e e também em um posterior cancelamento da mesma, é necessário informar um número de lote. Para facilitar, estou pensando em usar como número do lote, o número da própria NF-e. O que resultaria em repetir o número do lote quando fosse enviar e posteriormente cancelar a NF-e. Aos mais experientes... Existe algum problema quanto a isso? Posso repetir o número? A legislação obriga a fazer algum controle do mesmo? Desde já agradeço a atenção

Olá a todos, Estou tentando usar esse 2 componentes. O ConsultaCPF me retorna o erro "[Fatal Error] uPrincipal.pas(6): File not found: 'PNGImage.dcu'" O ConsultaCNPJ retorna o erro "JPEG Error #53" Meus componentes encontram-se atualizados até a presente data e uso o Delphi 7. Desde já agradeço a atenção de todos

Um outro detalhe importante que observei Sérgio... Durante esse "travamento", o meu aplicativo detectou ausência da internet na emissão de 4 notas, consequentemente tentou gerá-las de forma OFF-LINE, mas o componente simplesmente não retornou nenhum conteúdo do XML ao final da procedure GenaNFCe(similar a do demo) e também nenhum erro. Tal comportamento anormal só cessou após reiniciar tal máquina. Por isso simplesmente checar o sucesso do envio da nota não irá resolver o problema, que é bem maior do que isso.

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