Modelagem de Dados para NFe

[Alexsander]

Vocês modelaram a NFe como uma verdadeira árvore, com tabelas externas para os grupos ide, emit, avulsa, dest, etc ou colocaram todos os grupos num tabelão "nfe" e apenas os itens (grupo "det") ficaram numa tabela separada? No caso de usar um tabelão, fica cheio de campos NULL quando um grupo não é usado (ex: avulsa, retirada, entrega, etc). Alguma sugestão?

O layout da NFe tem vários campos repetidos e/ou vinculados (ex: cUF é parte de cMun e cMunFG). O ideal seria gravar todos estes campos para ter um "espelho" da NFe ou dá pra gravar apenas o mínimo necessário e gravar apenas o XML como "espelho"?

[peterson161]

Consulte o DEMO e verá que o componente forma o XML com os valores que são passados para ele. Apenas os campos obrigatórios são inseridos no XML mesmo estes não tendo valor. Por exemplo, se você não inserir local de entrega, o grupo "entrega" não será inserido no XML.

Você deve ler o manual e emitir algumas notas fiscais de teste com várias situações pelo DEMO para entender o funcionamento do mesmo.

[Alexsander]

Estou me referindo à modelagem do banco de dados (modelo E-R), não ao XML.

[Adilson Moretti]

Você não tem nota fiscal no seu sistema?

Se você tem é só modificar para gerar o XML.

Se não tem, a modelagem é basicamente a mesma para um sistema emissor de nota. Não tem nada de exclusivo por ser NF-e.

[Alexsander]

A minha modelagem atual não tem lugar para gravar informações como "Tipo de Emissão da NF-e" (tpEmis) ou "Quantidade Tributável" (qTrib) nas NF de entrada dos fornecedores, entre outros. Pelo que vi, para emitir a NF-e de venda no comércio vou precisar de muitas informações que vêm nos XML das NF-e dos fornecedores -- por exemplo, cada produto vendido com CST 060 tem que informar BC e valor do ICMS-ST retido, que foi informado na NF-e do fornecedor, onde ele veio com CST 010.

Antes de simplesmente sair adicionando campos em tabelas conforme a necessidade, pensei em aproveitar o momento para fazer uma REFORMA na modelagem para suportar todos os tipos de NF-e possíveis, inclusive de produtos que nenhum cliente meu vende hoje como carros 0 km e armamentos. Parece interessante ter um "espelho" da NF-e do fornecedor no banco de dados -- importado a partir do XML.

[Alexsander]

Continuando: quando vocês importam os XML recebidos dos fornecedores, como armazenam? Gravam o XML bruto em algum lugar e pesquisam dentro dele (usando as tags) conforme a necessidade ou decodificam o arquivo e gravam num banco de dados?

[ronnei]

Olá Alexsander, interessante sua pergunta. Eu passei pelas mesmas dúvidas, segui um caminho tortuoso e hoje me vejo retornado e alterando meu sistema, primeira dica, procure manter os nomes dos campos em sua tabela igual ao nome do manual de integração, isso facilitará muito para possíveis intercâmbios entre diferentes sistemas bem como para codificar a Nfe com o ACBR pois eles mantiveram esse padrão, quanto a tabela "gigante" eu aderi a ela, pois campos como modalidade do frete, que tem 3 ou 4 opções, não compensaria fazer uma outra tabela e referenciar via chave estrangeira, estou apenas colocando um combo e jogando as informações dentro e gravando apenas o numérico referente a opção. Agora tem campos que eu optei por não replicar na TabNfe como por exemplo os dados dos clientes/fornecedores, pois essas informações eu já tenho em suas respectivas tabelas, neste caso apenas uso uma chave estrangeira para elas, pensando em futuro, o que importa é o XML, por mais que mudemos os dados dos clientes no sistema, o XML estará intacto, e no caso de alguma importação desses dados usa-se o XML, eu por exemplo gravo uma cópia fiel do XML em um BLOB dentro a minha tabela TABNFE, além do arquivo físico que fica em uma pasta com opção de backup de tempos em tempo ou upload para meu servidor FTP de segurança.

Sei que isso vai "inchar" o banco, mas preferi fazer assim e sempre ter uma cópia em mãos. A tabela de DET que no meu caso é a TABPRODUTONFE eu coloquei todos os campos de impostos, tenho mais de 90 colunas nesta tabela, padronizei a parte de impostos da seguinte maneira, adiciono o prefixo do imposto a frente do nome do campo. Exemplo:

icms_orig

icms_cst

pis_cst

pis_vbc

pis_ppis

...

Assim campos que tem o mesmo nome como o CST não terão problemas e fica mais fácil de entender o código e a tabela.

Não sei se te ajudou mas tentei, fica uma dica no fórum de postarmos imagens das nossas telas de cadastro, assim poderia ajudar a todos em idéias de como melhorar a usabilidade de nossos sistemas, as vezes por uma "simples" tela temos idéias que podem nos ajudar, hoje eu sigo o emissor gratuito para me basear em como construir minha tela de NFE.

Passo também por uma dificuldade que é a quantidade de informações adicionadas na NFE que não existiam na M1, como por exemplo a parte de IPI, PIS E COFINS com informações específicas, isso prejudica demais a implantação, pois nossos cadastros de produtos não tem essas informações e atualizar todos os produtos antes de usar é quase impossivel, então estou padronizadno situacoes em que mesmo que não tenha no cadatro de produto preencho com vazio na hora e dou a opção de gravar o que foi digitado como default no cadastro de produto, isto tem aliviado um pouco a barra para o início. Fica aí o tópica para dicas!!

Atenciosamente

Ronnei Peterson

Invictos Tecnologia

[Alexsander]

Estou pensando em criar tabelas separadas para ICMS, IPI, II, ISSQN, PIS, COFINS, etc. Elas teriam como chave primária um ID resumido da NFe + a seqüência do item. Por exemplo, id_imposto = cod_imposto(2) + campos AAMM (4) + cNF da chave (8) + nItem (3) concatenados num BIGINT. Assim, na tabela de itens eu poderia ter uma coluna "icms" com NULL ou id_imposto, outra coluna "ipi" com NULL ou id_imposto e assim por diante.

[Alexsander]

Outra pergunta: estão salvando o XML da Nf-e no banco de dados?

Se sim, em campo TEXT ou BLOB?