Ir para conteúdo
  • Cadastre-se

bnobre

Membros Pro
  • Total de ítens

    1.480
  • Registro em

  • Última visita

  • Days Won

    4

Posts postados por bnobre

  1. 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á?

  2. 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

    • Curtir 2
  3. 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.

  4. 22 minutos atrás, Régys Silveira disse:

    O erro em branco acontece comigo geralmente quando existe algum bloqueio na internet (firewall, antivirus ou similar) e também quando o certificado está vencido, mal instalado ou com problemas nas cadeias.

    Outra coisa que já vi fazer esse comportamento acontecer são as configurações avançadas do IE não estarem corretas para o certificado.

    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.  :-/

  5. 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

  6. 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

     

  7. 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?

  8. 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

  9. 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?

  10. 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

  11. Em 19/11/2015 15:03:46, desenvolvedor2 disse:

    Olá amigos, boa tarde!
    Estou com um problema com relação à contingência e talvez alguém desse tópico possa me ajudar.
    Quando o meu aplicativo emite a NFC-e em contingência o arquivo.xml  armazenado não possui o protocolo de autorização.
    Quanto eu envio o mesmo arquivo.xml em um segundo momento, eu recebo o protocolo de autorização e armazeno no registro da venda no banco de dados.
    Existe uma forma de recuperar esse arquivo.xml com o protocolo no corpo no momento em que envio o xml da nota Offline?

    Alguns sistemas contábeis só importam o arquivo.xml se o o mesmo estiver autorizado, ou seja, estiver com o protocolo de autorização no corpo do arquivo.

    Algum amigo pode me informar algo a respeito?
     

    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

  12. 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.

  13. 1 hora atrás, Régys Silveira disse:

    Este erro em particular só ocorre quando você altera o XML após a geração. O ACBr não renumera ou troca informações passadas ao componente. 

    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.

  14. 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"?

  15. 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

  16. 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?

  17. Olá Italo... Com sua dica parou de dar o problema no projeto ao compilar, agora voltando ao assunto do cancelamento...

    Estava analisando as respostas obtidas no projeto de exemplo do ACBR ao consultar a NFC-e cancelada pela chave, e comparando as mesmas com um arquivo "*-procEventoNFe.xml" gerado normalmente pelo componente ACBR.

    Ao observar o arquivo "*-procEventoNFe.xml" gerado normalmente, vi que ele é todo formado pela tag <procEventoNFe>, exceto apenas pela primeira linha do mesmo, que sempre vem com o conteúdo "<?xml version="1.0" encoding="UTF-8"?>".

    Essa tag <procEventoNFe> também existe na resposta da consulta pela chave, seja no campo RESPOSTAS ou no campo RETORNO COMPLETO WS, e seu conteúdo a princípio é idêntico a mesma tag no arquivo "*-procEventoNFe.xml" gerado normalmente.

    Isso me gerou algumas dúvidas:

    1º - Realmente o arquivo "*-procEventoNFe.xml" sempre é formado na primeira linha com "<?xml version="1.0" encoding="UTF-8"?>" e o restante com a tag <procEventoNFe>?

    2º - Se a resposta da primeira pergunta for SIM, o conteúdo da tag <procEventoNFe> do retorno dado pela consulta (nas guias mencionadas) sempre será igual ao conteúdo da tag <procEventoNFe> do arquivo "*-procEventoNFe.xml" gerado normalmente?

    3º - Se sim para a primeira e segunda pergunta, suponho que para criar o arquivo "*-procEventoNFe.xml" basta apenas gerar um XML em que seu conteúdo na primeira linha tenha o texto "<?xml version="1.0" encoding="UTF-8"?>" e o restante tenha a tag <procEventoNFe> obtida pela consulta, sem a necessidade de utilizar o arquivo "*-ped-eve.xml" como mencionou anteriormente... Estou certo?

    4º - Por fim, se sim para todas as perguntas anteriores... Como obtenho somente o texto da tag <procEventoNFe> do retorno da consulta?

    Desde já agradeço a atenção sempre dada

  18. Olá a todos,

    Italo... Estou tentando efetuar o passo 3 estudando o projeto de exemplo do ACBR, mas sempre que tento compilar o projeto recebo o erro "WARNING: Duplicate resources(s)" e não consigo executá-lo. Tentei atualizar o componente agora, revisão 10481, mas o problema ainda persiste.

    Uso o Delphi 7.

    erro.JPG

×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.