[Php-avanzado] datos tesis

[Leonardo Tadei - Pegasus Tech Supply]

Hola Federico,

El mar, 30-12-2008 a las 11:05 +0000, Federico Rafaelli escribió:
> Leo, gracias por el comentario, la verdad no me di cuenta al momento
> de armar el esquema de datos que las ordenes de pago(OP) son un
> comprobante mas, y las tome como otra entidad, me salio asi.

	Te repito que tanto el esquema de una tabla por comprobante como el de
una tabla para todos y un discriminante son válidos.
	Lo que no "suena bien" es la mezcla de criterios.

> Si lo analizamos las OP son un documento interno, no son un documento
> comercial como una fc, nc, nd, rto, etc... pero para mi esquema lo
> puedo tomar como un tipo de comprobante mas. 

	"Comprobantes" al ser un término genérico te permite reflejar
comprobantes fiscales como internos (op, remitos internos, despachos,
tickets de empaque, etc) sin que la palabra suene mal o se aplique a
algo que no son.

> Pensandolo ahora, quiza lo haya tomado aparte porque las OP son un
> poco mas complejas que otro comprobante ya que tienen un estado,
> retenciones, uno o mas comprobantes involucrados, y uno o mas
> depositos tambien. 

	Mmmm.... todos los comprobantes tienen esta misma complejidad: un
remito puede estar entregado o no,una factura pagada o pendiente, las
facturas tienen retenciones, una factura puede hacer referencia a varios
remitos, un recibo a varias facturas.
	En tu sistema no estás modelando esto, pero en rigor, todos los
comprobantes tienen las mismas variaciones, y en algunos casos esos
valores son vacío o cero y la cosa funciona igual.

> Ademas para el detalle de cada pago (de cada OP), tengo que tener en
> cuenta que una OP puede tener mas de un comprobante y que un
> comprobante puede estar en mas de una OP (ya que existen pagos a cta),

	Tal y como te decía arriba de los recibos y facturas, o de las facturas
y remitos...

>  necesito una nva tabla para reflejar este detalle, con una relacion
> de muchos a muchos, creo que este ultimo requisito es el que me
> complica,

	A nivel de datos, efectivamente esta es la parte más compleja de
pensar, pero como bien decís, es una relación muchos a muchos, lo que
simplemente implica otra tabla para establecer la relación.
	Sin embargo el caso puntual de los comprobantes es el más fácil, ya que
a esa tabla solo se agregan datos, y nunca se editan o borran.

>  ya que los demas los manejo, por ej, en las tablas de retenciones o
> depositos en vez de tener la referencia "nro_op" tendra el id de
> comprobante (que sera la OP).
> Puedo tomar las OP como un tipo mas de comprobante, pero
> necesito una sugerencia para manejar el detalle de las mismas, quiza
> una nva tabla de "pagos" por ej?

	Como decís vos mismo arriba, si es una relación n-a-n, efectivamente te
hace falta otra tabla para la relación.
	No sé si "pagos" es un nombre feliz, ya que parece que ahí van los
pagos, cuando lo que tenés que guardar, es por cada OP las facturas
afectadas.

	Con tu esquema de "tabla universal" se ve raro, porque esa tabla de
relaciones tiene IDs siempre de la misma tabla, excepto que unos
corresponderán a las OP y otros a las Facturas.

	Pensalo, dibujalo y contame.
	Saludos!

-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key