Ir para conteúdo
  • Cadastre-se

dev botao

  • Este tópico foi criado há 4459 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Postado

Bom dia pessoal

Atualizei o componente via svn ontem a noite, hoje de manha compilei o projeto e quando fui testar envio e cancelamento me deparei com dois erros. Lembrando que estou emitindo notas em homologação.

Ao cancelar uma nota aparece o seguinte erro

Falha na validação dos dados do Envio de Evento

Validate failed because the document does not contain exactly one root node.

E ao enviar uma nota

Falha na validação dos dados da nota 1084

'0' violates enumeration constraint of '1 2'.

The element '{http://www.portalfiscal.inf.br/nfe}tpImp' with value '0' failed to parse.

Allan

  • Consultores
Postado

Bom dia Pessoal,

Foi realizado algumas alterações em alguns tipos utilizados pela NFe, um deles é o tipo de impressão do DANFE.

Antes tinhas somente os valores tiRetrato e tiPaisagem, agora temos uma meia duzia de tipos, por conta da nova versão que vem por ai.

O compotente ACBrNFe possui uma propriedade chamada tpImp, utilizada para gerar a respectiva tag no XML.

E no Componente ACBrNFeDANFE temos uma outra propriedade chamada tipoDANFE, utilizada para determinar se o DANFE vai ser impresso no modo Retrato ou Paisagem.

Como muitos não tem o costume de alimentar a propriedade tpImp do componente ACBrNFe, agora esta obtendo um erro ao validar o XML.

Porque antes não ocorria o erro e agora ocorre?

Simples a propriedade não era alimentada e ao gerar o XML o componente atribuia o primeiro valor disponivel para essa propriedade ou seja 1, só que agora o primeiro valor disponivel é 0 (zero).

Logo, para corrigir esse problema basta alimentar o componente corretamente, ou seja atribuir o valor correto para tpImp.

Espero ter ajudado.

Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • Moderadores
Postado

Pessoal só para ajudar no esclarecimento.

Esta opção não é uma novidade, mas sim uma nova crítica aplicada ao XML.

'0' violates enumeration constraint of '1 2'. (veja que 0 viola as opções permitidas que são: 1 ou 2)

The element '{http://www.portalfiscal.inf.br/nfe}tpImp' with value '0' failed to parse. (Há uma falha ao analisar tpImp com 0)

Agora vamos para o Manual. Versão 5.00

Pág. 151

ID-B21-Campo tpImp - Descrição: Formato de Impressão do DANFE.

Opções permitidas: 1-Retrato/2-Paisagem.

Veja que não existe opção 0.

Porém tenho notado o seguinte: Se a SEFAZ não aplica críticas ou validações nas schemas muitos fazem a nota errada e não estão se preocupando com o resultado final.

Exemplo quando não havia a validação nos totais, vi muitas notas que o total não batia com a somatória dos itens. Isto aconteceu com os itens, com os descontos, com os valores de base de cálculo, com valores de icms etc, até o dia que começam a validar e rejeitar notas com os cálculos errados. Então parece que alguns só se preocupam a partir deste momento, pois as notas não são mais autorizadas e eles precisam emitir.

Já vi ocorrer situações aqui no forum em que devido a um problema (pode ser temporário no webservice) o XML é anexado para a procura do provável erro. Analisando o XML é apontado alguma falha, porém se mais tarde a pessoa faz um teste e o servidor autorizou a nota então notamos comentários como: "Era um problema no servidor" e parece que fica por isto, continuando a emitir a nota com o XML errado, pois afinal o Web Service está autorizando, logo pensam que está tudo certo.

Cada vez mais será aplicado validações nos schemas devido a estes problemas.

Outro exemplo: Há algum tempo atrás saiu um comunicado sobre o consumo indevido dos Web Services.

Vejam que na NT 2012.003 - Página 8 é comentado novamente sobre o consumo indevido e me parece que surgiram outras maneiras: (coloquei 2 exemplos)

04.2 Consumo Indevido

Observado um comportamento indevido da aplicação de algumas empresas no consumo dos diferentes Web services do Serviço de Autorização da NF-e. Seguem alguns exemplos de “Consumo Indevido” dos Web services existentes:

Consulta Situação da NF-e - Algumas empresas utilizam esta consulta para verificar a disponibilidade dos serviços da SEFAZ Autorizadora, consultando a mesma Chave de Acesso, em “loop”.

Algumas empresas mantém em “loop” uma consulta as Chaves de Acesso de NF-e destinadas para sua empresa. Em alguns casos, fica sendo consultada uma Chave de Acesso inexistente durante meses.

Consulta Status Serviço - Aplicação em “loop” consumindo o Web service em uma frequência maior do que a prevista.

Resultado, criaram um código de rejeição 656

Verificação de Consumo Indevido (NT 2012.003)

A critério da SEFAZ Autorizadora, as mensagens com erro poderão ser rejeitadas com o erro “656-Rejeição: Consumo indevido”, independentemente de outras medidas saneadoras do erro detectado.

Veja que se estão novamente comunicando é porque tem desenvolvedores que estão praticando isto e não estão se preocupando com a situação.

Daqui uns dias vai ter gente apavorado porque estão recebendo mensagem de "Consumo indevido"

Com isto quero deixar aqui um conselho:

Procurem ler um pouco mais as informações que estão no Manual, não despreze ele, tem gente que sente um desânimo em ler, em procurar entender cada campo, mas tenha esta preocupação em saber se a sua nota esta correta, pesquise, procure analisar outros XML's de grandes fornecedores dos seus clientes, vejam como eles fazem etc. Com isto o seu sistema estará sendo valorizado e vcs não terão dor de cabeça mais tarde.


logoacbr.pngConheça o Portal do Projeto ACBr

Ajude o Projeto ACBr crescer - Assine o SAC ACBr
Assine um dos planos de longa duração do SAC ACBr, obtenha Descontos Especiais, Parcele no Cartão e ainda ganhe Brindes Exclusivos. Saiba mais aqui

Conheça o ACBrLib, o ACBr de forma nativa para qualquer linguagem de programação. Saiba mais aqui

 

 

 

 

  • Consultores
Postado

Bom dia a Todos,

Mais uma vez, vamos as explicações, pois cada dia que passa percebo que é mais facil escrever o problema que esta enfrentado do que pesquisar sobre o mesmo.

Quando é executada a linha: nfe.DANFE.TipoDANFE:=tiRetrato;

simplismente estamos configurando o componente para imprimir o DANFE no papel ou gerar o respectivo PDF no formato Retrato e nada mais.

Agora quando é executada a linha: Ide.tpImp := tiRetrato;

simplismente estamos passando o valor tiRetrato a propriedade tpImp e consequentemente ao gerar o XML a tag vai conter o valor 1 e nada mais.

Logo devemos incluir as 2 linhas na nossa aplicação e devemos atribuir valores iguais a ambas, porque:

Se você coloca no XML que o tipo de impressão é Retrato, é de se esperar que o DANFE vai ser impresso no modo Retrato e não em Paisagem.

Fica estranho informar a SEFAZ que o tipo de impressão é Retrato e fornecer ao cliente o DANFE em Paisagem, vocês não acham?

Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

Postado

Boa tarde.

Estou aqui hoje apenas para agradecer. Tive o mesmo problema depois que atualizei o ACBR. Fiquei maluco aqui pois estava com o faturamento da empresa parado.

E numa pesquisa rápida aqui achei a resposta que procurava.

Parabéns a todos, e vamos tornar essa nossa arma mais forte ainda, a colaboração.

Valeu !!!!!!!

Denis

  • Este tópico foi criado há 4459 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
×
×
  • 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.

The popup will be closed in 10 segundos...