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.

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.