Arcos exclusivos

[gnzsoloyo]

Si. por desgracia todo sistema que idees en teoría o en papel, nunca se transfiere de un modo fácil, porque lo que no es fácil es la realidad.
Al comenzar a mirar lo que tienes que considerar, mas lo que agregan los usuarios, se van agregando cada vez más cosas, hasta el punto (en muchas ocasiones), de tener que hacer reingienería de todo, simplemente porque desde el comienzo no se tuvo en cuenta la posibilidad de que el sistema crezca, o que el entorno cambie.
Ten en cuenta que todos los proyectos vinculados con comercialización están afectados por las regulaciones, nacionales, internacionales e incluso locales. Si tu sistema y BBDD no está preparada para adaptarse y evolucionar, en poco tiempo tendrás que empezar a pensar en rehacer todo el trabajo...

Nos pasa a todos.

Volviendo al tema de los productos, que al final no te comenté del todo, la idea central es que todo lo que se provee a un cliente es, conceptualmente, un producto. En ese sentido son productos los servicios contratados, los aparatos vendidos, los accesorios, pero también son productos el soporte técnico provisto, los asesoramientos on-line, y cualquier acción que pueda representar un item legalmente facturable.
¿Se entiende la idea?
En ese sentido, lo que tienes es una estructura de herencia, semejante a la de clases en POO, pero que se implementa de un modo algo distinto en una BBDD relaiconal.
Como cada "producto" de diferente tipo reconocible, representa una entidad que hereda de una entidad superior (Producto), existirán unos pocos atributos propios de esa entidad, y unos muchos que dependerán de la entidad hija (entidad débil).
Ahora bien, en POO este esquema implica que se instancia una entidad hija, pero no la entidad padre (superior), porque en programación no se instancian las clases abstractas, como "Producto", sino "ProductoServicio", "ProductoTeléfono", "ProductoLinea".
Pero cuando pasas a la base de datos, la cosa cambia: Para que se pueda crear un registro de ProductoTelefono, debe crearse primero un registro en Producto, porque la PK en Producto es la PK que el ProductoTelefono hereda al ser la que determina la dependencia del registro en esa tabla respecto al Producto.
¿Se entiende?
Eso es obligatorio en BBDD, y es una de las cosas que causa problemas a los programadores.
Ahora bien, ¿¿Como se llega de tener N tipos de productos de varias clases diferentes, a una única fctura?
En realidad es sencillo, y complicado al mismo tiempo:
- Las facturas no se relacionan directamente con cada tabla hija, sino con la tabla padre.
- La tabla padre debe tener un atributo o flag que determine de qué tipo de producto se trata.
- Según el tipo de producto, los stored procedures generan la lectura de la tabla correspondiente a ese o esos items.
- En la propia tabla o en la lógica del Sp se incluye el considerar si es un item de cobrar, de impuesto o de bonificación o beneficios.
- Es muy habitual que en realidad lo que se haga es un único query que, por medio de un UNION ALL, condicionado en base a algunos criterios en cada subselect, genere en una sola llamada toda la lista de importes de los items de la factura.

¿Se va entendiendo esa lógica?

La idea es que dejando la logida de datos encapsulada en la base por medio de SP, la aplicación simplemente accede al controlador de datos (modelo MVC), y recibe lo necesario para emitir la factura. Todo el resto es responsabilidad de los SP, que también manejan la logica de impuestos que se registran, las formas de pago, y los manejos de caja.

Consejo sabio y prudente: No intentes manejar esa lógica en la aplicación. Llenarás tu programa de mucha complicación y basura, que la base puede manejar mejro. Además, si lo pones en la aplicación, haces al sistema esclavo de un modelo de datos y viceversa, y una de las reglas del desarrollo es que debes poder mudar el modelo de datos sin afectar al programa, y cambiar el programa sin afectar la estructura de datos.

Ese es el paradigma que los que nos dedicamos a BBDD tratamos de lograr.

Saludos.

PD: Una nota final: Los beneficios tales como descuentos, bonificaciones por antigüedad, por mercado, por cantidad de compras, etc, siguen siendo productos y deben tener su propia tabla, en la cual se extraerá el porcentual o la suma fija que aplique a ese beneficio, o incluso determine si el beneficio descontado es manualmente ingresado.
Adicionalmente a esto, todo precio, costo, impuesto o bonificación que se modifique debe dar de baja el registro activo y crear uno nuevo, porque toda acción comercial que afecte items facturables debe ser trazable en el tiempo.
Piensalo así: Si una venta se paga luego de X días, y durante esos días se produjo una variación de precios, ¿qué se le cobra? ¿El precio nuevo o el anterior?
La respuesta es simple: A menos que se le haya advertido al cliente que los precios se actualizarán al momento del pago, al momento de hacer la venta, deberás cobrar el precio histórigo, y para eso necesitas saber cuál fue el precio al momento de esa venta...
¿Se entiende?

No sé si tu sistema llegará a tener tales requerimientos, pero por consejo de experiencia: Preparate para crecer.
Los sistemas comerciales no se hacen para el hoy. Se construyen para dentro de cinco años, como mínimo.