Respondendo ao argumento do Alexsander: Se o CNPJ é o mesmo, o cliente é o mesmo, sempre. Não existe clientes diferentes com CNPJ igual. Pergunte ao seu contador e ele responderá.
O preencher a nota é uma questão de como o sistema está organizado. Tu pode preencher a nota como bem entende (se bem que não é o correto perante a lei). Histórico de compras, perfil de cliente, é a mesma coisa. Tu pode ter tudo pelo endereço de entrega, por exemplo. Agora, se é tão diferente a modelagem de clientes diferentes, crie grupos. Com isso crie tabelas separadas. O correio (que não é o melhor exemplo) tem tabelas separadas de CEP, dependendo do estado, e inclusive uma tabela específica para grandes clientes com CEP próprio. Alecindro Quoting Alexsander Rosa <[EMAIL PROTECTED]>: > Claro. > > E depois, quando seu cliente quiser vender milhões de reais para 100 escolas > estaduais diferentes, todas com o mesmo CNPJ (da Secretaria de Educação), > você explica que "o sistema não permite". O mesmo ocorre com hospitais, > universidades, etc. Não é apenas um "endereço de entrega" diferente, mas o > destinatário da NF diferente. Se a NF não for emitida EXATAMENTE como o > pessoal da licitação pede, você pode ter problemas na hora de receber o > empenho. > > Além disso você vai misturar o histórico de compras, perfil do cliente etc > de todas as escolas. Mas isso é apenas um detalhe, claro. > > 2008/7/17 <[EMAIL PROTECTED]>: > >> Desculpa, mandei para o Assunto errado. >> >> Tá mas no caso da duplicação de dados, o CNPJ ou CPF pode ser criado um >> index >> unique. Segunda coisa: CNPJ usado por mais de um cliente: o endereço do >> CNPJ é >> um só. Não existe o mesmo CNPJ com 2 endereços diferentes (Isso é lei). É >> só pedir o cartão de CNPJ para o cliente. Crie uma tabela com endereço de >> entrega. Resolverá o teu problema. >> >> Alecindro >> >> >> Quoting Leandro DUTRA <[EMAIL PROTECTED]>: >> >> > 2008/7/17 Alexsander Rosa <[EMAIL PROTECTED]>: >> >> No fim das contas todo mundo usa um "código de cliente" sequencial... >> > >> > E 'todo mundo' tem problemas de duplicação de dados... >> > >> > >> >> primeiro, porque é mais fácil de manipular um código que em geral fica >> com 5 >> >> ou 6 dígitos do que um CPF/CNPJ com 14 ou 15 dígitos. >> > >> > Creio que já ficou claro que há muitas circunstâncias ? melhor seria >> > dizer muitas entidades ? para as quais CNP[FJ] não serve. Mas isso >> > não é importante; o importante é ter pelo menos uma chave natural em >> > cada relação. >> > >> > >> >> Segundo, porque há >> >> casos em que o mesmo CNPJ é usado por mais de um cliente. Será que vale >> a >> >> pena criar um monte de tabelas pra isso? >> > >> > Se você quer organização e consistência de dados, precisa normalizar. >> > >> > -- >> > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra >> > +55 (11) 3040 7300 r155 gTalk: >> xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]> >> > +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 >> > +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] >> > _______________________________________________ >> > pgbr-geral mailing list >> > [email protected] >> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > >> >> >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > > > -- > Atenciosamente, > Alexsander da Rosa > Linux User #113925 > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
