Campo Nitemped - Integer Para String

[SISVALE SISTEMAS]

Boa Tarde a todos.

 

Com base nesses 2 tópicos:

 

O cliente do meu cliente uma empresa grande e importante para meu cliente exige o preenchimento da tag nItemPed no seguinte formato 00010, 00020 e assim por diante.

Tanto nós como eles sabemos que pelo manual o conteúdo deste campo deve ser obrigatoriamente númerico e sem zeros a esquerda. Porém essa empresa já recebe esse campo preenchido de outros clientes dela da forma como eles querem e perguntam porque somente nós se negamos a preencher da forma como eles querem, Inclusive recebi um xml deles onde esse campo realmente foi aceito em formato string e também fiz um teste pelo emissor gratuito onde também permite gerar o xml com esse campo no formato string.

 

Então seria bom no acbr também ser possível gerar como string aberto e pelo programa controlamos como gerar, pois ficando fixo integer fica impossível de personalizar esse campo.

Desde já agradeço.

 

Ps.: esqueci de comentar que antes o acbr colocava os zeros na frente e no tópico que mencionei acima resolveram tirar os zeros da esquerda.

Porem nem isso vai resolver pois eles querem com tamanho 5 : 00010, 00020 .... 

por isso acredito que deixar string aberto resolve tudo.

[Italo Giurizzato Junior]

Boa tarde Fabio,

 

Se compararmos os campos:

 

#126 - nSeqAdic tipo Numérico cujo tamanho é: 1-3, ou seja, varia de 1 até 3 dígitos.

 

#128n - nItemPed tipo Numérico cujo tamanho é 6.

 

Baseado nas informações acima chego a seguinte conclusão:

 

1. Por ser campo numérico o conteúdo só pode ter dígitos.

2. Se o tamanho esta definido como sendo 6 e não 1-6, isso significa que o campo tem que ser preenchido com 6 dígitos.

 

Mas se analisarmos o schema temos:

 

<xs:element name="nItemPed" minOccurs="0">

  <xs:annotation>

    <xs:documentation>Número do Item do Pedido de Compra - Identificação do número do item do pedido de Compra</xs:documentation>

  </xs:annotation>

  <xs:simpleType>

    <xs:restriction base="xs:string">

      <xs:whiteSpace value="preserve"/> 

      <xs:pattern value="[0-9]{1,6}"/>

    </xs:restriction>

  </xs:simpleType>

</xs:element>

 

Note que o elemento nItemPed é opcional e o seu valor é formando somente por dígitos [0-9] e cujo tamanho é variável {1,6}.

 

Resumindo:

 

Segundo o manual o conteúdo da TAB nItemPed é um número com 6 dígitos, mas segundo o schema o conteúdo é um número com tamanho variável de até 6 dígitos. 

[SISVALE SISTEMAS]

Sim, sabemos disso e está correto.

Porem como falei acima a empresa exige o preenchimento do campo nItemPed assim: 00123 

Eles recebem centenas de nfe toda semana e a grande maioria vem preenchido dessa forma mas pelo Acbr não conseguimos, no acbr o resultado do campo será apenas 123 eles não aceitam assim, se meu cliente não fizer da forma como eles querem 00123 ele não poderá mais fornecer produtos para essa empresa.

Pelo emissor gratuito dá certo, eu digito 00123 e no xml exportado autorizado aparece 00123.

Se não me engano eles usam sistema sap que dá todo um tratamento especial a essas tags de pedidos...

Se não puder alterar no componente me diga em que lugar posso alterar nos fontes que tenho, já alterei onde tem as variaveis nitemped de integer para string mas só isso não adiantou, pois quando gera o xml ele transporma em integer novamente...

 

no xml gerado pelo emissor gratuito:

.............

 <xPed>321</xPed>

 <nItemPed>00123</nItemPed>

............

 

Desde já agradeço.

[Italo Giurizzato Junior]

Fabio,

 

Primeiramente, essa empresa esta agindo de forma errada, obrigando a gerar um XML que nem sequer tem o tamanho estabelecido no manual é 6 dígitos e não 5.

 

Você deve alterar a unit pcnNFeW, alem de altear o tipo tem que alterar o tamanho minimo e máximo deixando ambos com o valor 6.

[SISVALE SISTEMAS]

Obrigado Italo, vou tentar fazer isso.

 

Acabei de receber também o posicionamento do TI da empresa:

 

Entendi a colocação do parceiro de negócio, entretanto, temos que entender essa informação (Núm. Pedido e Item) no contexto da Nota Fiscal Eletrônica (NF-e).

Em um dado momento da história da NF-e, por solicitação das empresas que participaram nos projetos piloto de implantação, a SEFAZ passou a permitir a geração de duas TAGs novas no XML, mas, em momento algum ela valida o conteúdo dessas TAGs. Podemos confirmar essa minha informação com base no manual do contribuinte –> leia-se a última coluna do manual. ... Observação: Informação de interesse do emissor para controle do B2B (v2.0

Veja alguns casos que nós mesmos geramos, com ou sem ‘Zeros’ nos números, tanto de “Pedido” quanto de “Item”, para alguns processos internos em que precisamos dessas informações.

Em momento algum a SEFAZ valida ou toma qualquer ação sobre o conteúdo dessas informações, isso eu posso garantir. A única coisa que a SEFAZ valida é a posição correta das TAGs dentro do esquema do arquivo XML da NF-e. E, o tamanho da informação, que não pode passar de 6 casas (dígitos).

Na verdade o número do Item de Pedido em qualquer sistema pode ser “1”, por exemplo. Mas, na hora de montar a informação no arquivo XML da SEFAZ, qualquer sistema pode informar “01”, “001”, “000001”, etc...

Espero ter ajudado.

[SISVALE SISTEMAS]

Valeu Italo, deu certinho.

Mas não preciso alterar o tamanho só o tipo mesmo:

De tcInt para tcStr

[Italo Giurizzato Junior]

Boa noite Fabio,

 

Entendo perfeitamente que o nItemPed não tem utilidade nenhuma para a SEFAZ.

 

Para esta empresa o pedido dela não deva ultrapassar mais de 99.999 itens, mas e se o seu cliente passar a ter um cliente cujo pedido possa a chegar a ter uma quantidade maior do que 99.999 e exigir que no XML da nota seja informado o numero do item.

 

Como você vai resolver o problema?

[SISVALE SISTEMAS]

Neste campo vai aceitar até 999999.

No xml o número máximo do item é 990.

No caso dessa empresa eles tem programa personalizado de pedidos onde até o numero do item do pedido é personalizado não é um número sequencial e no programa deles o tamanho máximo deste campo é 6.

O número do item meu usuário tem que digitar manualmente conforme a empresa envia a confirmação do pedido com os números dos itens

[beckershow]

DocFabio e Italo,

 

O problema de mexermos no componente é sempre a atualização! 

 

Quando vem uma nova "leva" de alterações, sempre temos que acabar mexendo nesses fontes e alterando. 

 

Vejo que o DocFabio teve que mexer em pcnNfe, pcnFnew, pcnNFER e pcNFeRtxt.

 

Pois só o fato de mexer no pcnNFeW e trocar para string não resolve, sendo que a entrada de dados se dá da seguinte forma:

 

Produto.nItemPed := valordigitadonainteface.

 

Sendo assim, se digitar 00001 o sistema vai suprimir para 1.

 

A propriedade nItemPed, também terá que ser alterada para string, para aceitar o que você digitou. 

 

Se mexer somente no pcnNFeW, vai ficar engessado, ele vai por teu zeros, mas sempre com uma quantidade fixa determinada pelo parametro max.

 

Será que não temos como por isto com string, e o usuário trata isto na inteface? Ou até mesmo por uma propriedade para tratar como string ou inteiro. Ou melhor um atributo nItemPed: Variant.  e tratar da seguinte forma if (VarOf(nItemPed) = Int) then ..... else String...

 

Alguma sugestão?