NFE DE SERVI?O
Olá pessoal,
Alguém consegue me afirmar se o número de uma nota fiscal de serviço eletrônica é limitado a 8 carácteres em qualquer estado brasileiro?
Alguém consegue me afirmar se o número de uma nota fiscal de serviço eletrônica é limitado a 8 carácteres em qualquer estado brasileiro?
Colega,
A nota de serviços eletrônica não é por estado, é por municÃpio e cada municÃpio regula o seu caso em particular.
Alguns padrões no mercado, como Ginfes e Betha, por exemplo, dominam mais aqui a região Sul de SC, mas há mais de 30 padrões de NFS-e.
Especificamente quanto ao número, como não há padrão nacional (como existe com NFe), nem mesmo estadual, então eu diria 8 espaços é bem razoável, sobretudo que quando chegar ao limite troca-se a série (passando de 1 para 2) e assim reinicia-se a numeração.
Mas não há porque preocupar-se com a quantidade de caracteres, visto que é um número sequencial e não uma string sequencializada.
Tudo de bom!
A nota de serviços eletrônica não é por estado, é por municÃpio e cada municÃpio regula o seu caso em particular.
Alguns padrões no mercado, como Ginfes e Betha, por exemplo, dominam mais aqui a região Sul de SC, mas há mais de 30 padrões de NFS-e.
Especificamente quanto ao número, como não há padrão nacional (como existe com NFe), nem mesmo estadual, então eu diria 8 espaços é bem razoável, sobretudo que quando chegar ao limite troca-se a série (passando de 1 para 2) e assim reinicia-se a numeração.
Mas não há porque preocupar-se com a quantidade de caracteres, visto que é um número sequencial e não uma string sequencializada.
Tudo de bom!
Mas porque se preocupar com número de espaços se o campo é numérico? Mesmo serializando ou desserializando para XML se for campo numérico simplesmente será serializado e desserializado normalmente.
Obrigado amigos,
No entanto, meu software é somente de cunho gerencial, estou tentando evitar que o usuário lance duas vezes a mesma nota, pensei em fazer uma combinação entre o número da nota e o CNPJ do emitente e guardar em um campo para indexar, dai a a necessidade de um padrão.
No entanto, meu software é somente de cunho gerencial, estou tentando evitar que o usuário lance duas vezes a mesma nota, pensei em fazer uma combinação entre o número da nota e o CNPJ do emitente e guardar em um campo para indexar, dai a a necessidade de um padrão.
Um número é um padrão. Se fizer um campo numérico na tabela, ele serve até mesmo como chave primária, evitando assim duplicação. A necessidade de uso de tipagem correta de dados é essencial para a integridade de dados. Se é número, use o tipo numérico correspondente, nunca um string.
Citação::
Um número é um padrão. Se fizer um campo numérico na tabela, ele serve até mesmo como chave primária, evitando assim duplicação. A necessidade de uso de tipagem correta de dados é essencial para a integridade de dados. Se é número, use o tipo numérico correspondente, nunca um string.
Então, justamente o que quero fazer, mas fornecedores diferentes podem emitir uma nota com o mesmo número, por isso não posso deixa-lo como chave primaria, claro que eu poderia fazer uma verificação entre o CNPJ e o número da nota antes de gravar, mas quero facilitar o select com somente um campo.
Não sei fui claro rsrsr
Colega,
Sei que desejas facilitar o select com apenas um campo, seria o ideal, mas para isto você teria que ter uma tabela para cada fornecedor, o que é impraticável.
Na sua tabela de NF de entrada, sua chave deverá ser o número da NFe + CNPJ do emitente, caso queria. Se deixar apenas o número como chave, vai dar problemas, a menos que use Ãndices ao invés de chaves, porque toda chave é Ãndice mas nem todo Ãndice é chave.
De qualquer maneira, formatar o número para 8 posÃções com zeros à esquerda não seria solução, não resolveria o problema. Deixe como campo numérico que será melhor, tanto para selects quanto para Ãndices, de forma geral, para velocidade do banco.
A menos que... você use um campo tamanho 22 posições string sendo as 8 primeiras o número NFe formatado com zeros a esquerda seguido do CNPJ sem formatação, mas na hora de listar NFe por número, por exemplo, seus selects ficarão complicados, fazer relatórios seria custoso, procurar uma NFe pelo número sem saber qual o fornecedor, sabendo apenas o número seria outro de muitos problemas que você enfrentaria, além de cair drasticamente o desempenho do banco. O barato vai sair carÃssimo.
A natureza do negócio é realmente número da NFe + CNPJ, seja como chave ou como Ãndice.
Nas NFe, inclusive, o número não pode ser formatado com zeros à esquerda, sob pena de não ser validado nos schemas.
Tudo de bom.
Sei que desejas facilitar o select com apenas um campo, seria o ideal, mas para isto você teria que ter uma tabela para cada fornecedor, o que é impraticável.
Na sua tabela de NF de entrada, sua chave deverá ser o número da NFe + CNPJ do emitente, caso queria. Se deixar apenas o número como chave, vai dar problemas, a menos que use Ãndices ao invés de chaves, porque toda chave é Ãndice mas nem todo Ãndice é chave.
De qualquer maneira, formatar o número para 8 posÃções com zeros à esquerda não seria solução, não resolveria o problema. Deixe como campo numérico que será melhor, tanto para selects quanto para Ãndices, de forma geral, para velocidade do banco.
A menos que... você use um campo tamanho 22 posições string sendo as 8 primeiras o número NFe formatado com zeros a esquerda seguido do CNPJ sem formatação, mas na hora de listar NFe por número, por exemplo, seus selects ficarão complicados, fazer relatórios seria custoso, procurar uma NFe pelo número sem saber qual o fornecedor, sabendo apenas o número seria outro de muitos problemas que você enfrentaria, além de cair drasticamente o desempenho do banco. O barato vai sair carÃssimo.
A natureza do negócio é realmente número da NFe + CNPJ, seja como chave ou como Ãndice.
Nas NFe, inclusive, o número não pode ser formatado com zeros à esquerda, sob pena de não ser validado nos schemas.
Tudo de bom.
é como o ZEUZEBIO3 falou. Se são dois campos que diferem um registro do outro, você precisa usar esses dois campos, ainda que eles estejam em uma tabela separada, serão sempre esses dois campos.
Tópico encerrado , respostas não são mais permitidas