clever-x

Tag dEmi => NF-e 2.00 Tag dhEmi => NF-e 3.10 Porém, no ACBrNFe foi mantido o nome da tag "dEmi" na versão 3.10, por compatibilidade com a versão 2.00, em referência a dhEmi. Logo, use dEmi como se fosse dhEmi.

Estou tentando gerar o registro E113 e ao colocar modelo 02 o PVA não valida. A mensagem de que o modelo 02, 2D e 2E não deve ser usado aparece no relatório de erros. Alguém sabe como proceder?

É isso mesmo que você falou, está tudo certo. 1) O literal "ISENTO" não é mais permitido na versão 3.10. 2) Enviar sem informar IE para destinatário que tem IE gera o erro: 213->Rejeição: IE do destinatário não informada.

Igualmente Reverson!

Não. Melhor você estudar melhor essa parte pois está confundindo as coisas. Essa propriedade é o retorno de um envio de evento, informado como teCancelamento no seu caso. Items[0] indica que o evento tem apenas um retorno de resposta. Se você não salvar esse protocolo nesse momento, o que você irá fazer depois é uma consulta de situação da nota por meio de ACBrNFe.WebServices.Consulta.Executar. Na consulta irá retornar todos os eventos da NF-e além da situação da mesma. Tendo todos os eventos, então você pode acessar ACBrNFe.WebServices.Consulta.procEventoNFe.Items[X].RetEventoNFe onde X vai de 0 até o número de eventos que você enviou. Ai sim, se o terceiro evento é de cancelamento você usa ACBrNFe.WebServices.Consulta.procEventoNFe.Items[2] e pega os valores que desejar como o protocolo por meio de ACBrNFe.WebServices.Consulta.procEventoNFe.Items[2].RetEventoNFe.InfEvento.detEvento.nProt. Bom, acho que é isso. No meu sistema eu não implementei essa consulta de eventos após serem enviados.

AcbrNFe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.nProt. Verifique se é isso.

Atente-se que cancelamento agora é um evento. Logo, esse trecho (ACBrNFe1.WebServices.Cancelamento.Protocolo) não deve mais existir no seu sistema, pois o mesmo está relacionado ao jeito antigo de se cancelar uma NF-e.

Pelo que eu entendi você está enviando um evento EPEC, correto? Nesse caso, esse retorno (136 - Evento Registrado, mas não vinculado a NFE) é o normal e o correto a ocorrer em um envio de EPEC. Veja que o evento é registrado, tudo certo com ele. E ele não é vinculado à NF-e justamente por não existir uma NF-e emitida até o momento. Você envia o evento EPEC e só depois é que transmite a NF-e para a SEFAZ. E quando você envia a NF-e referente a um EPEC a SEFAZ faz a chamada conciliação, vinculando o evento à nota, creio eu que por meio da chave de acesso. Portanto está tudo certo e isso não é um erro. Agora só falta enviar a NF-e, após cessado os problemas que levaram à emissão do EPEC, caso haja realmente um problema e não esteja só testando o desenvolvimento.

Você pode colocar esses detalhes na informação complementar do produto.

Bom dia. Obrigado pela sugestão mas o problema é que dessa forma não seria automatizado o processo. Estava procurando algo que não exigisse a intervenção do cliente, sendo que o mesmo já informou os códigos LC116. Me parece não ter como escapar disso mesmo, mas se alguém souber de algo, tiver alguma ideia ou já possuir uma tabela pronta com as conversões de um para o outro e puder disponibilizar, ficarei agradecido.

Bom dia. Com a alteração da lei De Olho no Imposto, a nova tabela disponibilizada pelo IBPT não contempla mais a LC116, somente a NBS. Na NF-e, quando enviamos um item ISSQN informamos o serviço que consta na LC116 pois NBS não é permitido. Assim, ao pesquisar a alíquota na nova tabela do IBPT, o valor do imposto não seria encontrado. Somado a isso, no SPED ICMS/IPI (Registro 0200) também não se pode informar os códigos presentes na NBS. Portanto se eu informar uma NF-e com item ISSQN daria erro no SPED Fiscal. Alguém sabe o que deve ser feito perante a essas situações ou se eu estou fazendo alguma confusão? Como conciliar o trio NF-e, IBPT, SPED quanto ao código de serviço? Obrigado.

Eu tive esse problema em um cliente. No caso, era porque ele tinha dois gerenciadores de cartão instalados na mesma máquina, o SafeSign e o Charismathics. Pelo que parece, um gerenciador dava conflito com o outro.

Veja:

A função NotasFiscais.Valida faz a validação da estrutura do xml gerado utilizando o esquema XSD para isto. Mesmo a estrutura estando correta, o webservice pode retornar outros erros, por exemplo, erros referentes à lógica do negócio.

Creio que uma opção seria você tentar enviar a nota normalmente. Caso haja falha no envio, mude o tpEmis e envie off line.

Então, como o Kiko disse, não existe CSOSN 290. Creio que o que você quer informar seja um CST 90 - Outras, com Origem da Mercadoria 2 - Estrangeira, adquirida no mercado interno. Esses dois dados juntos formam o código 290 (Origem + CST) que querem que apareça na nota. CSOSN é usado para empresas optantes pelo Simples Nacional apenas. Os outros utilizam CST.

Por nada. []'s.

O e-CPF pode ser usado como certificado digital para a NF-e? E o e-CNPJ? O certificado digital a ser utilizado deverá ser de pessoa jurídica, do tipo A1 ou A3. O e-CPF não pode ser utilizado para a NF-e; já o e-CNPJ pode, no entanto não é o mais indicado. Fonte: www.nfe.fazenda.gov.br/portal/perguntasFrequentes.aspx?tipoConteudo=k/E5BakB80o= (segunda pergunta)

Entendido. Obrigado pela resposta Juliomar.

Pessoal, como o último post já tem uma semana, resolvi postar novamente. Ainda continuo sem solução para o meu caso. Teria como alguém testar e analisar se está passando pelo mesmo problema? E se possível encontrar uma solução, eu por si só não estou conseguindo. Obrigado

Estou com um problema de impressão de DANFE em loop quando nenhuma impressora padrão é encontrada (removi as minhas para fazer este teste). Utilizo o DANFE via Rave baseado em código. Alguém já passou por isso ou sabe como resolver? Minha intenção não é cadastrar uma impressora e sim, permitir a visualização mesmo não tendo uma impressora padrão configurada.

No sistema que implementamos, quando uma nota sofre uma tentativa de emissão, sinalizo um campo no banco de dados e mudo a cor da mesma no grid. Quando não consigo o retorno e o cliente tenta enviar novamente, o sistema analisa o campo e se está sinalizado que houve tentativa de envio mas não recebeu a resposta, ele faz a consulta primeiro antes de deixar o cara enviar. Nessa consulta o protocolo é capturado e o XML atualizado. Em situação normal, com internet e web service respondendo perfeitamente, essa nota, se realmente autorizada, é colorida no grid com uma outra cor, após a consulta, informando que foi enviada com sucesso. Logo, o processo de reenvio não seguirá em frente e a mensagem de duplicidade não chegará a ser mostrada. Como o protocolo foi capturado, o DANFE será impresso corretamente. Só estou compartilhando uma ideia do que o meu sistema faz para controlar isso. Penso em, futuramente, criar um método para consultar automaticamente (em uma thread) todas as notas que tiveram uma tentativa de emissão sem o retorno da resposta.

Sim, não tem valor jurídico sendo necessário corrigir os dados cadastrais e só assim fazer outra. Mas ela é armazenada no banco de dados da SEFAZ e é uma situação válida para a nota (igual autorizada e cancelada) retornando todos os valores (cStat, dhRecbto, nProt). Por ser válida a operação é que penso que ao invés de lançar uma exceção na função ACBrNFe.Enviar(ALote, Imprimir, Sincrono) deveria apenas setar a propriedade ACBrNFe.NotasFiscais.Items.Confirmada para False. Do jeito que está o funcionamento atual, precisamos fazer um tratamento para notas autorizadas dentro de um try..except e de denegadas dentro do except..end como segue: try enviar if confirmada then if cStat = ... then trata autorizada else ... else ... except if cStat = ... then trata denegada else mensagem de erro de envio end; Assim, fica parecendo que deu problema na função Enviar. Acho que o certo seria tratar assim: try enviar if confirmada then if cStat = ... then trata autorizada else ... else if cStat = ... then trata denegada else ... except mensagem de erro de envio end; Só uma sugestão.

Quando tento enviar uma NF-e com CNPJ denegado, resultando no cStat 302, a função Enviar do componente lança uma exceção falando que a nota está denegada. A questão é: é certo lançar uma exceção já que o envio foi feito corretamente e ser denegada é um estado válido? Obrigado.

Pelo que sei, esta informação não faz parte do XML da NF-e.