[SOLUCIONADO] Dos maestros un detalle

[jc_moj]

Hola

Estoy con una DB, muy muy sencillita, pero me surgió una duda:

Tengo dos tablas maestro/detalle que son muy similares, de hecho, el detalle es el mismo para las dos y el maestro difiere muy poco:

maestra 1: ID autoincremental, código, fecha.
maestra 2: ID autoincremental, código, fecha, vencimiento, estado.

Y la tabla detalle sería igual para las dos tablas, los mismo campos con el mismo significado.

Entonces me surge la duda si es mejor así, crear las 4 tablas o crear una maestra a la que se le añada un campo para diferenciar unos datos de otros (o simplemente, como la primera no usa algunos campos, pues si estos están a null, ya sé que es del tipo 1).

Voy a usar SQLite, como digo, será muy sencillita y cada tabla no tendrá muchos datos.

Saludos

[gnzsoloyo]

Eso, conceptual mente es un error muy grave.
Una relación maestro - detalle es el resultado de la normalizacion de una tabla, no es arbitrario. Si tienes eso es porque hay dos entidades iguales en datos con diferentes usos, y habla de un muy mal modelado del sistema.
Explícanos que representa cada una y veremos, pero desde ya, si representan cosas diferentes, NO se pueden unificar.
Las tablas no se fusionan pos similitudes entre datos, sino por lo que representan en el sistema.

[jc_moj]

Iniciado por gnzsoloyo

Eso, conceptual mente es un error muy grave.
Una relación maestro - detalle es el resultado de la normalizacion de una tabla

Sí, te entiendo, el caso es que es un programa que ya está funcionando y estoy dándole vueltas para modificarlo escribiendo lo menos posible XD

Actualmente tiene lo que puse como maestro1, que guarda los ticket regalo que genera la tienda, ya que es una característica que el software que actualmente tenemos no da opción y mientras llega el nuevo que nos van a a hacer a medida, pues hice una solución chapucera:

la tabla maestra tickets:
ID autoincremental
codigo: que se corresponde con el código del ticket del software de la tienda
fecha: igual, la fecha del ticket que generó el otro software

la tabla detalle
ID autoincremental
ID_COD: código del ticket al que pertenece
articulo.
precio.
cantidad.

Ahora quieren que les haga lo mismo pero para los vales, es decir, cuando alguien devuelve un artículo, se les da un vale por el importe devuelto.

El detalle sería el mismo, pues tengo que guardar los mismos datos, y la maestro varía un poco, pues tengo que guardar la fecha y el vencimiento y también el estado, para saber si ese vale ya se canjeó o no, por ejemplo.

Entiendo que son dos entidades diferentes, una es un ticket de venta y la otra un vale por el importe de un artículo devuelto.

Mi lio viene por tratar de modificar el programa lo mínimo posible para adaptarlo al nuevo requerimiento.

Un saludo

[gnzsoloyo]

En tu descripción, un "vale" no es una extensión de un "ticket", por lo que no puede estar representado en la misma tabla.
Para hacerlo en una sola tabla, de todos modos necesitarías tres, en una relación padre->hijos, donde la tabla principal fuese algo así como "DocumentosDeCredito", y las hijas "Ticket" y "Vale". Si no es una jerarquía NO CORESPONDE usar una misma tabla maestra.
Si intentases hacerlo en un solo par Maestro-Detalle, en realidad deberías hacer tres de todos modos, ya que estás aclarando que tickets y vales no tienen exactamente la misma cantidad de campos, por lo que requeriría una tercera tabla, dependiente de la segunda, para vincular en forma opcional aquellos datos que sólo corresponden a uno de ellos.

Adicionalmente, te comento, que esto:

la otra un vale por el importe de un artículo devuelto.

en algunos países (como el mío, Argentina) eso es ilegal, ya que toda devolucion de un artículo genera una Nota de Crédito, no un ticket, dado que debe ser imputada a la anulación de una venta facturada, y sólo se puede compensar una Factura usando una NC.
¿Se entiende?
Usar un "ticket" de cambio para eso no anula la obligación de usar una NC (el ticket es un documento de uso interno), por lo que no registrar la NC se tomaría como fraude en una auditoría.

[jc_moj]

Hola

Iniciado por gnzsoloyo

En tu descripción, un "vale" no es una extensión de un "ticket", por lo que no puede estar representado en la misma tabla.

Creo que me había obsesionado con la idea de reutilizar al máximo lo que ya tenía hecho. Como son dos cosas independientes y separadas, cada una va a tener su tabla correspondiente.

Iniciado por gnzsoloyo

en algunos países (como el mío, Argentina) eso es ilegal, ya que toda devolucion de un artículo genera una Nota de Crédito, no un ticket, dado que debe ser imputada a la anulación de una venta facturada, y sólo se puede compensar una Factura usando una NC.
¿Se entiende?
Usar un "ticket" de cambio para eso no anula la obligación de usar una NC (el ticket es un documento de uso interno), por lo que no registrar la NC se tomaría como fraude en una auditoría.

Pues a pesar de que trabajo como dependiente en una de nuestras tiendas, te puedo decir que desconozco completamente la legislación al respecto (España). En mi caso te hablo del pequeño comercio, en nuestro caso no emitimos facturas, únicamente le damos al cliente el ticket de compra. Nosotros, y todas las tiendas que conozco de la zona, funcionamos de la siguiente manera:

- El cliente compra un artículo y se le entrega un ticket de compra.
- Si por el motivo que sea decide devolverlo, lo que hacemos es una nueva venta, un nuevo ticket, pero en negativo, lo único que no solemos devolver el dinero, si no que le damos un "vale" por el importe devuelto con el que podrá hacer una compra en la tienda.

Aunque, al menos en nuestra tienda, las devoluciones son muy raras, lo normal es que se lleven otro artículo, por lo que en el nuevo ticket consta el artículo que se llevan y como negativo el artículo que entregaron y en esos casos, como la diferencia a devolver, si la hay, suele ser muy poca, pues se devuelve ese resto de dinero y ya está.

Un saludo

[gnzsoloyo]

El dispositivo impresor que emite ese ticket suena parecido a lo que acá se denomina "impresora fiscal", de uso general obligatorio para comercios con ventas por debajo de cierto importe.
Esos dispositivos tienen también un modo de "anulación" o "devolución de compra", que en definitiva se imputan en los libros bajo el mismo concepto de NC.

Como sea, lo importante en este caso es que se entienda que el modelo de datos no puede mezclar cosas. Los tickets son una cosa, y los vales otra.