Preenchimento da tag qVol no xml da NFe

[Gabriel Rogelin]

Bom dia!
Estamos com uma situação aonde é preciso informar a quantidade de volumes no xml da NFe (qVol) com zero no início, por se tratar de uma quantidade que seria fracionada na situação de alguns clientes, teria que gerar conforme imagem, este é o xml do sistema anterior de um cliente. Por ser inteiro esta informação no componente, não aceita zeros no início. Lembrando que não queremos quantidade fracionada, até por que conforme manual a sefaz não vai aceitar. A questão é permitir o zero antes da quantidade, o que não infringe as regras de validação e atende a necessidade dos nossos clientes.

Abaixo um exemplo de xml do sistema anterior

 

[Juliomar Marchetti]

Bom dia

olhando o manual o mesmo informa que deve ser numerico o campo e que por sua vez ele deve ignorar zeros a esquerda

Será que esse software não está lendo de forma equivocada?

[Gabriel Rogelin]

O manual já olhei. Informa que é numérico, de 1 a 15, mas não proibe o uso de zeros na esquerda, ou seja, o fato de ser numérico não necessáriamente é obrigátorio ser inteiro. Pode aceitar do 0 ao 9 normalmente, é o que acontece com o sistema anterior do cliente, se não aceitasse a nota seria rejeitada. Estou batendo nesse ponto pois vamos perder alguns clientes que migramos por esse motivo, eles precisam que tenha essa possibilidade, e isso não vai contra o manual da NFe.

[Victor H. Gonzales - Panda]

5 minutos atrás, Gabriel Rogelin disse:

O manual já olhei. Informa que é numérico, de 1 a 15, mas não proibe o uso de zeros na esquerda, ou seja, o fato de ser numérico não necessáriamente é obrigátorio ser inteiro. Pode aceitar do 0 ao 9 normalmente, é o que acontece com o sistema anterior do cliente, se não aceitasse a nota seria rejeitada. Estou batendo nesse ponto pois vamos perder alguns clientes que migramos por esse motivo, eles precisam que tenha essa possibilidade, e isso não vai contra o manual da NFe.

Bom dia,

primeiro ponto, isso não influencia 00000500 para 500 se é Quinhentos, zeros a esquerda não são significativos.

Imagina que se mudar isso no componente, irá influenciar todos os usuários que utilizam o componente, isso irá ter uma quebra em todos que tem isso em produção, isso tem um impacto severo no componente.

os Schemas deve utilizar como String apenas porque o campo integer com 15 dígitos haverá estouro de memória, o correto mesmo seria int64 nos schemas, mas o mesmo foi construído como string, ou erro de construção.

[Italo Giurizzato Junior]

Bom dia Gabriel,

O questionamento desses clientes é referente ao XML que no campo qVol não conter o zero a esquerda?

No seu exemplo temos o numero 02658 como sendo a quantidade.

Se a quantidade for 15263, também deverá constar 015263 no XML?

Ou o problema é na leitura dessa informação do XML para salvar no banco de dados?

Desculpa, mas não estou conseguindo entender qual é a real importância desse zero a esquerda.

[Gabriel Rogelin]

Bom dia Victor, sou programador faz alguns anos, sei que zeros a esquerda não muda nada em um campo do tipo inteiro, conheço os manuais e sei como funciona toda essa parte. Quando eu recebi essa questionamento de imediato já imaginei o tamanho da complexidade da alteração, inclusive no meu sistema que o campo é do tipo inteiro também. O fato é, a SEFAZ permite, pois vai estar dentro do espeicifado para o campo que é numérico, por mim, entendo perfeitamente; O problema é perder cliente por esse motivo. Verifiquei qual era o sistema anterior, e eles usam TecnoSPED, que trabalha desta forma conforme a imagem que anexei.

5 minutos atrás, Italo Giurizzato Junior disse:

Bom dia Gabriel,

O questionamento desses clientes é referente ao XML que no campo qVol não conter o zero a esquerda?

No seu exemplo temos o numero 02658 como sendo a quantidade.

Se a quantidade for 15263, também deverá constar 015263 no XML?

Ou o problema é na leitura dessa informação do XML para salvar no banco de dados?

Desculpa, mas não estou conseguindo entender qual é a real importância desse zero a esquerda.

Olá Italo. A quantidade de volumes deste cliente não chega a 1. Por isso precisa do 0 a esquerda. Seria por exemplo 0200 que iria no Xml. Ele não pode colocar 0,200 de forma alguma, pois a regra de validação é clara que não pode ser decimal. O que precisaria é permitir o zero a esquerda justamente por que a sefaz não deixa ter virgula. TecnoSPED funciona desta forma, gerando no xml com 0200.

Se não for possível atender tudo bem, já vamos informar as empresas que solicitaram e perder estes clientes que necessitam desta situação. Como já mencionei, entendo a complexidade e possível quebra de código para algumas aplicações. 

De fato é uma situação complicada e como têm outros que fazem, ficamos nesse impasse. Só preciso de uma parecer se vai ou ser possível contornar a situação de alguma forma.

[Victor H. Gonzales - Panda]

50 minutos atrás, Gabriel Rogelin disse:

Bom dia Victor, sou programador faz alguns anos, sei que zeros a esquerda não muda nada em um campo do tipo inteiro, conheço os manuais e sei como funciona toda essa parte. Quando eu recebi essa questionamento de imediato já imaginei o tamanho da complexidade da alteração, inclusive no meu sistema que o campo é do tipo inteiro também. O fato é, a SEFAZ permite, pois vai estar dentro do espeicifado para o campo que é numérico, por mim, entendo perfeitamente; O problema é perder cliente por esse motivo. Verifiquei qual era o sistema anterior, e eles usam TecnoSPED, que trabalha desta forma conforme a imagem que anexei.

Olá Italo. A quantidade de volumes deste cliente não chega a 1. Por isso precisa do 0 a esquerda. Seria por exemplo 0200 que iria no Xml. Ele não pode colocar 0,200 de forma alguma, pois a regra de validação é clara que não pode ser decimal. O que precisaria é permitir o zero a esquerda justamente por que a sefaz não deixa ter virgula. TecnoSPED funciona desta forma, gerando no xml com 0200.

Se não for possível atender tudo bem, já vamos informar as empresas que solicitaram e perder estes clientes que necessitam desta situação. Como já mencionei, entendo a complexidade e possível quebra de código para algumas aplicações. 

De fato é uma situação complicada e como têm outros que fazem, ficamos nesse impasse. Só preciso de uma parecer se vai ou ser possível contornar a situação de alguma forma.

Boa tarde, acredito que a concepção desse campo está sendo usada de forma errada.

O intuito ao meu ver seria no caminhão esse volume é composto por quantas peças? 25? Então esse seria o valor informado, e não o metrô cúbico que forma a carga, mas sim a quantidade de unidades de caixas, pallets, etc. que formam a carga solta no caminhão.

[Juliomar Marchetti]

1 hora atrás, Gabriel Rogelin disse:

Bom dia Victor, sou programador faz alguns anos, sei que zeros a esquerda não muda nada em um campo do tipo inteiro, conheço os manuais e sei como funciona toda essa parte. Quando eu recebi essa questionamento de imediato já imaginei o tamanho da complexidade da alteração, inclusive no meu sistema que o campo é do tipo inteiro também. O fato é, a SEFAZ permite, pois vai estar dentro do espeicifado para o campo que é numérico, por mim, entendo perfeitamente; O problema é perder cliente por esse motivo. Verifiquei qual era o sistema anterior, e eles usam TecnoSPED, que trabalha desta forma conforme a imagem que anexei.

Olá Italo. A quantidade de volumes deste cliente não chega a 1. Por isso precisa do 0 a esquerda. Seria por exemplo 0200 que iria no Xml. Ele não pode colocar 0,200 de forma alguma, pois a regra de validação é clara que não pode ser decimal. O que precisaria é permitir o zero a esquerda justamente por que a sefaz não deixa ter virgula. TecnoSPED funciona desta forma, gerando no xml com 0200.

Se não for possível atender tudo bem, já vamos informar as empresas que solicitaram e perder estes clientes que necessitam desta situação. Como já mencionei, entendo a complexidade e possível quebra de código para algumas aplicações. 

De fato é uma situação complicada e como têm outros que fazem, ficamos nesse impasse. Só preciso de uma parecer se vai ou ser possível contornar a situação de alguma forma.

Nada impede de tu mudar local. e manter algo caso não seja modificado por nós.

[Gabriel Rogelin]

Boa tarde!

1 hora atrás, Victor H. Gonzales - Panda disse:

Boa tarde, acredito que a concepção desse campo está sendo usada de forma errada.

O intuito ao meu ver seria no caminhão esse volume é composto por quantas peças? 25? Então esse seria o valor informado, e não o metrô cúbico que forma a carga, mas sim a quantidade de unidades de caixas, pallets, etc. que formam a carga solta no caminhão.

Concordo perfeitamente com isso, esse é o funcionamento que deveria seguir. A quantidade do produto vendido é uma, a quantidade de volumes é outra. O problema é tirar um costume que vêm de outro sistema.

Não vamos nos desgastar com essa questão. Vamos conversar novamente com o cliente, tentar fazer com que seja compreendido o uso da quantidade de volumes e mudar o preenchimento para que informe os volumes de fato que estão sendo transportados e que seja um número inteiro. Em última situação, vamos realizar o ajuste local nos fontes do acbr para contornar essa questão.

Agradeço a atenção e ajuda de todos no tópico.

Pode fechar! 

[Victor H. Gonzales - Panda]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.