O que coloquei abaixo é parte de um movimento de estoque, e não foje ao que postei.
Por favor, qual o real objetivo que deverá atender ?, pois no mencionado abaixo não coloquei movimentação por cupom fiscal e negociação com clientes onde envolve custo de última entrada com várias classes para formação de preço. Acredito que seria interessante ter qual o objetivo final deste trabalho, o quê ele irá atender e informar. On Wednesday 25 June 2008 08:00:08 Alexsandro Haag wrote: > Como comentei antes, acho que seria interessante trabalharmos sobre o > ER, pois somente assim conseguiremos demonstrar melhor o que falamos. > Se for relatar todo o detalhamento de tabelas de movimento e filhas > vai ficar longo e nosso tempo geralmente é curto. > > Do contrário acabamos falando de um único ponto sem demonstrar toda a > estruturação do ER, e parece como comentado abaixo, que se está > falando de um único tabelão para tudo. E com certeza não é disso que > estou falando. > > Jocimar de Oliveira escreveu: > > On Tuesday 24 June 2008 16:52:50 Alexsandro Haag wrote: > >> Leandro DUTRA escreveu: > >>> 2008/6/24 Alexsandro Haag <[EMAIL PROTECTED]>: > >>>> Pode ser sim. Dá prá fazer separado. Mas normalmente é uma mesma > >>>> tabela, pois é tudo movimento de estoque. > >>> > >>> Então há uma tabela com movimento de estoque, e outra específica > >>> para cada tipo de movimento de estoque. Se não, vira bagunça. > >> > >> Não entendi por que bagunça? teria apenas uma campo indicando > >> a CFOP e dentro da tabela de CFOPs um qualificador de saída ou > >> entrada. > > > > Como ficaria a movimentação no momento do faturamento para entrega > > futura (não baixa estoque), e o faturamento que acompanha as > > mercadorias referente a entrega futura (baixa estoque) ? > > > > O movimento dos produtos num único arquivo é interessante para > > registrar apenas a movimentação, da qual vêm das saídas (NF, Ordem > > de Serviço/Ordem de produção, etc ...) e das entradas (NF, > > Romaneios de entrada, entrada por produção). > > > > Não consigo ver um único arquivo para controlar várias origens de > > entradas e saídas de produtos, isto fazendo referências com vários > > campos para tal identificação. Aconselho fazer a movimentação dos > > produtos num arquivo separado, mas que tal arquivo não seja a > > tabela filha de várias origens, realmente ficaria uma tabela com > > uma infinidade de campos. > > > > Na questão de códigos fiscais, é algo muito complicado para > > simplificar como entrada e saída de mercadoria, já que existe > > muitos códigos fiscais que não geram tal movimentação, por exemplo, > > como ficaria as entradas dos documentos com modelo: > > 06 - Energia elétrica, > > 08 a 11 que são conhecimentos de fretes que acompanham mercadoria > > ou que realmente são documentos de faturamento de transportadoras, > > modelo 22 - Telecomunicação, que pode ser compra ou venda da mesma. > > > > Imagina que teríamos que cruzar modelo fiscal x código fiscal x > > situação tributária x alíquota de ICMS x alíquota de IPI. > > > > Venho desenvolvendo há quase 20 anos, e não consigo ver uma > > centralização de tabelas para "diminuir", pois isto vai aumentar e > > muito o tamanho de registros e irá gerar muitos, mas muitos > > problemas para gravar e ler estas informações, que no meu ponto de > > vista seria um trabalho para ser jogado e iniciado um novo. > > > > Vou continuar acompanhando estes e-mail's, pois achei interessante > > o ponto de vista de cada um que foi postado. legal ! > > Esta mensagem foi verificada pelo E-mail Protegido Terra. > Atualizado em 25/06/2008 -- Saudações, Jocimar de Oliveira www.jocimar.com.br (42) 8402-3035 _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
