bnobre
-
Total de ítens
1.480 -
Registro em
-
Última visita
-
Days Won
4
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por bnobre
-
-
1 hora atrás, Régys Silveira disse:
Quanto a tabela o Cantu fez a conversão e postou no blog dele, veja o link: http://www.firebase.com.br/artigo.php?id=2862, talvez lhe ajude.
Obrigado Régys...
Então basicamente, pelo que entendi, cada NCM tem um CEST respectivo? Se sim, vocês estão indicando o CEST automaticamente baseado no NCM que o cliente indicou OU estão deixando a cargo do cliente de vocês indicar o CEST do produto?
-
Olá a todos,
Conforme anunciado, a partir de abril de 2016 será obrigatório a informação dessa tag.
Como informo a mesma através do componente?
Também gostaria de saber se existe algum local onde possa baixar a mesma em EXCEL ou outro formato para importar ao meu banco, assim como ocorre na IBPT para os NCMs?
Desde já agradeço a atenção de todos
-
Olá a todos,
Algumas poucas vezes, quando tento cancelar uma NFC-e, por algum motivo a mesma é cancelada mas eu não recebo retorno. Com isso ao tentar cancelar dinovo, recebo o erro "Rejeição: Duplicidade de Evento", ai tenho que considerar a mesma já cancelada e reescrever o XML de cancelamento com os dados de retorno.
Mas algumas vezes ainda mais raras, como hoje, além de não receber o retorno e ter o problema "Rejeição: Duplicidade de evento", eu tenho o problema de consultar a nota e ela aparecer para mim como se ainda não estivesse cancelada. Aí tenho que aguardar algumas horas até ela finalmente aparecer como cancelada na consulta para só então reescrever o XML com os dados do retorno.
Como vocês tratam esse tipo de problema?
-
Olá a todos,
Acabo de desenvolver um emissor de NF-e, mas eu só consigo visualizar e imprimir o DANFE no micro onde o mesmo foi desenvolvido, nos clientes sempre recebo o erro abaixo:
"RLNFe: Erro durante a preparação do relatório. EDataBaseError(Não é possível realizar esta operação em um arquivo fechado)"
O que poderia ser isso?
-
Olá a todos,
Ao iniciar o ano reparei que alguns NCMs que eram usados até então no envio de NFC-e, passaram a retornar o erro de NCM inválido.
Alguém sabe dizer se foram removidos NCMs no início desse ano em relação ao ano passado?
Desde já agradeço a atenção
-
Em 30/12/2015 at 21:03, Régys Silveira disse:
Poderia nos posicionar se nas últimas versões ainda ocorre o relatado?
Olá Régys, tudo bom?
Desculpe a demora, mas só vi a sua mensagem agora. Na verdade estava aguardando um pouco mais de tempo para lhes posicionar com 100% de certeza, mas vamos lá.
Na verdade deixei a conexão como síncrona mesmo, pois assim que ia seguir a sua idéia eu tive um insight sobre o problema e acho que descobri a real causa, bem, ao menos até agora resolveu.
Seguinte, conforme relatei, se meu aplicativo detecta erro de conexão ao tentar enviar a NFC-e ele emite em contingência, até ai tudo bem. Só que tem um detalhe, eu tenho um outro aplicativo (contingencia.exe) rodando na máquina que tenta enviar as notas em contingência de 5 em 5 minutos, aí que tive uma "iluminação", percebi que poderia estar acontecendo de na hora que a nota em contingencia estivesse sendo enviada pelo contingencia.exe, o meu cliente poderia estar no mesmo instante enviando outra nota pelo meu aplicativo principal. Nos testes que realizei em certificados A1 não tive problemas com essa situação, mas lembrei que nunca testei essa possibilidade em certificados A3.
Daí imaginei que essa seria a causa do problema, o contingencia.exe usa o cartão para assinar a nota no mesmo momento que o aplicativo principal tenta usá-lo e pronto, o componente se perde. Então nesses clientes com A3 desativei o envio automático e eles são obrigados a enviar manualmente pelo programa principal, para garantir que não tenha outro envio de nota paralelo a esse.
Até agora não tive mais problemas.
Acha que minha teoria pode estar certa???
-
15 horas atrás, Sérgio Assunção disse:
Você não terá problemas com a ordem em que as notas forem transmitidas, mas terá rejeição se qualquer nota tiver a data de emissão superior a 30 dias.
Grato pela assistência Sérgio... Sempre achei que tinha que seguir a ordem certinho.
Abraços
-
Olá a todos.
Estou desenvolvendo um emissor de NF-e e estou com uma dúvida referente a como se controla a numeração e data de emissão, creio que os amigos com maior experiência sobre o assunto podem me ajudar.
É meu primeiro emissor de NF-e e a pouca experiência que eu possuo do assunto vem do emissor de NFC-e que desenvolvi em agosto, sendo que no mesmo é um pouco diferente, pois a digitação da nota e envio da mesma para autorização ocorrem no mesmo momento no ato da venda pelo PDV, com a numeração e data/hora de emissão geradas em tempo real, portanto não tenho problemas.
No emissor de NF-e é diferente, pois o usuário primeiro digita toda a nota (onde eu sugiro a numeração e data/hora de emissão) e posteriormente envia, se quiser e lembrar, com isso ele pode esquecer ela gravada sem enviar, cadastrar outra e enviar essa outra primeiro(pulando a seqüência da numeração).
Portanto minha dúvida é:
1 - se o usuário gravar a nota 10 e 11, enviar a 11 primeiro e a 10 depois, tem problema?
2 - se o usuário levar, digamos 30 dias, após a data de emissão da nota 10 para envia-la, tem problema?
Desde já agradeço a atenção de todos
-
12 minutos atrás, Régys Silveira disse:
Você quer retornar o número de inscrição estadual ligado a um CNPJ, é isso?
Correto
-
Olá a todos,
Assim como consultamos os dados de uma empresa pelo componente ConsultaCNPJ, existe algum outro componente na paleta do ACBr que consulte também a inscrição estadual através do CNPJ?
Desde já agradeço a atenção de todos
-
Olá, gostaria de expor outro detalhe que verifiquei referente ao relato exposto acima.
Conforme podem observar no log de erros do post superior, no dia do erro citado (14-15-15) foram emitidas apenas as notas 61, 62, 63 (que deu erro), 64 e 65... Todas foram em contingência, devido a ausência de internet no dia do problema.
No dia seguinte, enviei todas normalmente, menos a 63 conforme já relatado. A questão é que agora observei que o componente por alguma razão simplesmente não gerou os XMLs das notas 61, 62, 64 e 65. Tive que fazer manual. Mais um detalhe do caso acima que queria compartilhar com vocês para abranger o assunto e ajudar a descobrir o X dessa questão.
-
Ok Régys,
Fiz conforme você falou, deixei como configuração e nos 2 clientes com A3 acabo de deixar como assíncrono, vamos ver no que dá.
Ontem um desses clientes ficou sem internet o dia todo e deu o problema que citei apenas na nota 63. Estou enviando o arquivo de log que meu aplicativo faz para você analisar, além da função GravaXML.
Existem 2 tipos de erro no log, um descrito como "Erro: " e outro como "Erro de Contingencia: ", o primeiro é gerado na tentativa de envio da nota pelo aplicativo emissor, já o segundo é gerado pelo aplicativo que envia as notas em contingência de 5 em 5 minutos.
Observe o erro da linha 17580, referente a nota 63, a mesma gerou um log de erro (Ação cancelada pelo usuário). Se observar a u_nfce_pdv, supõe-se que o aplicativo fez o seguinte:
- Executou o "dtm_banco.ACBrNFe1.Enviar(lote,False,True); //linha 630"
- Logo após entrou na exceção referente a outros erros que não sejam de "requisição não enviada", linha 694, pois logou esse erro.
- Não descartou as alterações, linha 695, pois logo em seguida se vê no log, linha 17585, um erro de internet referente a nota 64.
- Após esse erro de internet da nota 64, ele gerou em contingência normalmente.
- Na linha 17594, vemos que o aplicativo simplesmente tentou enviar uma nova nota dinovo como 63, onde obteve erro de "requisição não enviada". O que não tem explicação, pois a próxima na contagem seria 65.
- Observa-se que ele então executou a linha 665 já que logou o erro da contingência, a 667 e 668 que converte a venda para CONTINGENCIA também foi executada normalmente. Já as linhas 670 a 678 não retornaram nada, pois a 685 "GravaXML" não efetua gravação nenhuma (o que é estranho, já que deveria disparar uma exceção por tentar gravar em branco com campos vazios).
- Por fim ele salva as alterações, linha 686. Logo em seguida, nas linhas 688 a 691 ele tenta imprimir e nada sai (isso eu sei porque já vi acontecer).
- Já na linha 18067 do log, observa-se a tentativa de envio da próxima nota pelo emissor, que saiu corretamente como 65 seguindo a sequência, a mesma gerou também normalmente em contingência.
Bem, esse é um exemplo do que ocorre, mas varia. O fato é que algo acontece ao executar o .Enviar da linha 630, normalmente quando existe algum tipo de falha da internet, fazendo com que o código se perca. Vamos observar agora se pára no envio ASSÍNCRONO.
-
Grato pela ajuda Italo,
Uma pergunta, eu nunca enviei via modo ASSINCRONO, fiz como você falou, apenas alterei o TERCEIRO parâmetro para False.
Eu achei que ia mudar alguma coisa, que eu precisasse enviar um comando posteriormente para consultar o recibo da nota, mas a mesma foi normal, autorizou e logo em seguida imprimiu, igual no modo SINCRONO. É assim mesmo? A forma de usar os 2 é igual?
-
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.
-
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.
-
43 minutos atrás, Sérgio Assunção disse:
Creio que o problema não seja com o A3, até mesmo pelo fato que a falta de internet não iria "bloquear" as funçoes do certificado.
Passe a gravar no banco após a certeza que a nota foi emitida, seja em modo normal ou contingência.
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.
NFC-e atraso cancelamento
em NFe/NFCe - Nota Fiscal Eletrônica
Postado
Sim meu amigo, não encontrei nada.
O que fiz foi avisar ao cliente para aguardar um pouco...
Assim que o programa obter o retorno com os dados do cancelamento aí eu crio o XML do cancelamento manualmente, já que o componente não faz automaticamente a criação do XMLs de cancelamento ao consultar.