Arcos exclusivos

[exo123]

Estuve leyendo sobre arcos exclusivos, creo que eso se aplica a un problema que estoy planteando.
Por ejemplo, una empresa de telefonía vende servicios de telefonía, venta de equipos y asistencia técnica.

Para realizar un sistema de facturación tendría una tabla factura y otra items
como en los items puedo tener la venta de un equipo, una asistencia y un servicio tendría que dividir:

Items en: ItemsServicio, ItemsEquipos, ItemsAsistencias y la tabla factura con un campo tipo_items... esta creo que no sirve porque voy a tener campos comunes repetidos

¿o crear en la tabla items una columna para saber qué tipo de artículo es? Equipo, Asistencia y Servicio.

Espero sugerencias, gracias

[gnzsoloyo]

Para no caer en un largo debate, es mejor que le des una visita a este hilo reciente, donde apareció ese mismo tema:

http://www.forosdelweb.com/f21/duda-...-otra-1071131/
Ten en cuenta, especialmente el post Nº 9.

Te recomiendo que sigas hasta le final la discusión porque es un tema algo enredado.
Si luego no se entiende algo, pregunta.

Lo que si te puedo decir, anticipándome, es que el modelo de datos en BBD relacionales para sostener la lógica de negocio que mencionas (telefonía), no se resuelve con un par de tablas. Los esquemas para administrar Servicios, Equipos, Asistencias y otro largo etcétera, implica la existencia de más de una docena de tablas, las que quedan "escondidas" detrás del OMR o FMWK que uses luego en programación (asunto off-topic acá).
Y puedo asegurarlo con certeza porque trabajo precisamente en el área de desarrollo de una empresa de ese tipo.

[exo123]

si gnzsoloyo, me imagino que el esquema ni llega a ser funcional jeje pero es para ejemplo como un auto-ejercicio, porque siempre veo en ejemplos item relacionado con producto y estaba pensando en qué pasaría si se empieza a vender servicios. O sea que necesito que me quede en claro como resolver el problema de relacionar los items de cada factura. Podría ser como otro ejemplo una casa de repuestos que vende repuestos y también reparaciones de vehículos.

Leí el post que me pasate...
Puedo decir entonces que un servicio, una asistencia y un equipo son cosas distintas pero para el item de una factura son lo mismo, cada uno tiene un costo, impuesto, descuento, etc.
No creo que tenga que hacer una división ni colocar tipo para diferenciar.

La empresa vende servicios de telefonía e internet. Las facturas llegan al hogar del cliente cada mes.
Modelo 1


Modelo 2
La empresa empieza a vender teléfonos celulares. Se crea otra tabla para los item que sean de venta de celulares. La venta se agrega a la factura mensual junto con el valor de servicio mensual que tiene contratado


Modelo 3
Se empieza a cobrar las asistencias a los domicilios que pueden ser para reparaciones o verificaciones, etc. Por cada cosa que se va a cobrar no se puede crear otra tabla entonces todos los items en una tabla y el campo articulo_id es la referencia que puede ser de un servicio, de una asistencia o de un equipo. La factura del final de mes incluye el sericio mensual que tienen contratado, algún equipo que haya comprado y el costo de las asistencias o reparaciones que haya solicitado.



como lo ven?

[jlct]

En mi opinión, tienes redundancia para definir el articulo, ya que pudieses crear una tabla articulo solo con su Id, Descripción y Valor. en vez de crear las tablas servicios, asistencias y equipo que tienen los mismos atributos.

Al fin de cuenta en la tabla items_factura se ve reflejado cada uno de los artículos que vayas a facturar, y si vas a agregar el valor del articulo en el detalle de la factura no es necesario que exista ese atributo en la tabla artículos.

Saludos.

[gnzsoloyo]

Construir un sistema que facture elementos clasificados en varios tipos de item, es algo complicado, y no se puede resolver bien simplemente agregando relaciones a diferentes tablas, porque lo único que se obtiene es una vinculación con N atributos diferentes.
A la hora de emitir la factura, se complica muchísimo.
Lo que debe hacerse es partir de un concepto mucho más abstracto: Un Producto, que no necesariamente es un objeto físico. Un producto comercial puede ser tanto un servicio, un producto, o una bonificación sobre algún precio por alguna razón.
La idea de esto es abstraer todo una capa mas al menos, cosa que cuando se emita la factura, la clasificación del producto por categorización, permita al stored procedure (si, se necesitarán para eso), reconstruir la logica de cada item de modo más coherente y consistente.
Entonces, el detalle de la factura lleva solamente la indicación del producto, y el la lógica del SP quien se encarga de determinar si el item es de una clase u otra, e incluso si es una imputación de cargo, o un beneficio.
esta noche te avanzo un poco sobre esto (ahora estoy trabajando), porque es en realidad algo más simple de lo que parece, y más complejo de lo que tienes en mente.
Pero te aseguro que funciona bien.

[exo123]

jlct: el valor en item es por si el valor de un producto cambia en el futuro, o mejor un historial de precios?

gnzsoloyo: sería fantástico conocer la forma que lo planteas, ya estoy ansioso jeje

¿hay patrones de diseño en base de datos? algo general que siempre es usado como partida para casos particulares

[jlct]

Eso es dependiendo de como lo veas, lo que si debería ser fijo es que el precio vaya en el detalle de la factura, para mantener el histórico.

Porque podrías tener una lista de precios, donde manejes el precio base de los productos, y en el detalle tienes el precio con el cual se facturó.

Saludos.

[gnzsoloyo]

Normalmente, por necesidades precisamente de trazabilidad histórica de precios, los precios se manejan en una tabla o conjunto de tablas, donde cada actualizacion es un registro nuevo con fecha y hora de alta, y con fecha y hora de baja el que se descarta.
Este tipo de cosas las define las necesidades del sistema y el nivel de detalle buscado.
No es una muy buena idea guardarlo en la tabla de detalle de factura porque cualqueir manipulación externa a la aplicación puede adulterar el dato, y hacer perder consistencia e integridad de la operación. La seguridad de los datos comerciales es crítica.
Lo que se suele hacer, también, es que el proceso almacenado que genera la factura, realice todas las verificaciones necesarias previas a la emisión final, donde no sólo se suman los importes de precio del producto al momento de emitir el comprobante, sino también todas las cargas impositivas que según el caso afecten la operación.
Es usual que el procedimiento de generación de estos importes sea algo complejo, por lo que no te asustes.
Donde sí se imputa el precio total de lo facturado es en alguna tabla o tablas donde se asienten los movimientos de dinero y pagos respectivos.
En referencia a los pagos, incluso estos no componen parte de los datos de la factura, ya que una factura no es un pago. puede ser un comprobante de pago, pero el pago puede tener varias formas y no sólo efectivo. De allí la necesidad posible de la existencia de una tabla específica de documentos de pago, y ocasionalmente de otra referida a los métodos de pago habilitados.
Mucho de esto lo tiene que definir el cliente final, ya que es él quien usará el sistema, y estas cosas sólo se resuelven de un modo: Preguntandole.

[exo123]

se extiende bastante jeje pero mejor tener en claro primero el tema de los items asi por lo menos se confecciona una buena factura jeje

[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.

[exo123]

Muchas gracias! :) saqué muchas cosas, de verdad.

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.

Claro, el clásico "un sistema de stock es fácil, vendés y restas" pero también se puede descontar porque son materiales que se usan, que se devuelven, etc. todo depende, stock de una libreria, de un taller, de un restaurante, etc y a qué nivel de registro se quiera llegar je y "un sistema de stock es fácil, vendés y restas" ya deja de ser tan fácil.

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?

Entiendo que un producto facturable o un "algo" que corresponde a un item no es solamente un objeto tangible, también puede ser un servicio u otra cosa que se facture, bonificaciones, cargos, etc.

Cosas que se pueden facturar
1. Productos (teléfono celular, teléfono inalámbrico, un router)
3. Servicios (Internet, Telefonía fija y móvil, reparación, asistencias)
4. Cargos (pago por mora, reconexión)
5. Bonificaciones (por algo mal cobrado, por días sin servicio)
Todos estos (y ni me imagino que más tiene una empresa grande) son tipos de cosas que se puede facturar.

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?

Sisi entiendo que es diferente, no voy a pensar en poo o en comparar un diagrama de clases con el esquema de una base de datos

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.

A la factura le interesa sus item. A cada item le interesa el artículo y no las características o tipos. El artículo es quien debe armarse bien con sus datos para que pueda ser un item facturable y a su vez la factura pueda confeccionarse correctamente.
¿es eso?

Lo que pienso es:
Primero se comienza en sistema para un negocio que vende teléfonos y quiere un sistema de facturación. Como para estar preparado al cambio y al crecimiento de la empresa no hay que pensar en un sistema de facturación para teléfonos, sino en facturar artículos. Que artículo abarque un teléfono celular o una reparación, por más que la empresa no se dedique a la reparación de celulares, en un futuro lo querrán ofrecer y no habrá inconvenientes, ni siquiera si implementan servicio de telefonía.

Entonces si hago facturación para celulares:
ItemsFacturas>Telefonos
Si quiero agregar reparaciones, tendría que agregar una tabla "Reparaciones" y tendría que modificar ItemsFacturas y agrega otras tablas más.

Si hago para articulos
ItemsFacturas>Articulo>Telefono
Un teléfono es un artículo que se factura y cualquier cosa que se factura va a ser un artículo. Por lo tanto, si quiero empezar a facturar las reparaciones no tendría que modificar la estructura.
Ahí es como entiendo lo que dices de: "Según el tipo de producto, los stored procedures generan la lectura de la tabla correspondiente a ese o esos items."

Artículo puede ser de tipo "Teléfono" o "Reparación". Ahora también podría pensar en reparación, es un servicio


Al menos eso entendí de lo que dices de abstraer al menos una capa

La idea de esto es abstraer todo una capa mas al menos, cosa que cuando se emita la factura, la clasificación del producto por categorización, permita al stored procedure (si, se necesitarán para eso), reconstruir la logica de cada item de modo más coherente y consistente.

Me queda esto:

[exo123]

Acá encontré algo que usa herencia para descomponer los productos de bebidas y comidas

http://www.databaseanswers.org/tutor...ata_modelling/

Esos ejemplos son los que le quiero agregar otras cosas que salga un poco del clásico "producto tangible", como este que agrega 2 tipos de productos

Si la empresa quiere vender menú diarios, ¿sería un producto?
Crearía un tabla "menues" con campos precio, el la tabla Products estaría el nombre y la descripción, no?

Si la empresa quiere vender servicio mensual de viandas, este también sería un producto, agregaría una tabla "viandas" con relacion 1:1 con productos, no?


Entonces en el ejemplo, las ordenes dependen de Products y no de todos sus tipos.

[gnzsoloyo]

Si la empresa quiere vender menú diarios, ¿sería un producto?
Crearía un tabla "menues" con campos precio, el la tabla Products estaría el nombre y la descripción, no?

Si los menúes componen un mismo conjunto invariable de elementos, el menú es un producto. Es el caso de las ventas de McDonalls, por ejemplo. cada "combo" es un menú. Y los "adicionales", son agregados al pedido que aumentan el precio pero aplican beneficios sobre el importe del Combo.

Si la empresa quiere vender servicio mensual de viandas, este también sería un producto, agregaría una tabla "viandas" con relacion 1:1 con productos, no?

El servicio es un producto, y cada elemento que lo compone (menúes, entrega, adicionales) es un item del producto.
Ese esquema implica que hay una categoría nueva de producto que es capaz de incluir productos. Es un interesante caso para analizar.

Entonces en el ejemplo, las ordenes dependen de Products y no de todos sus tipos.

Exacto. Las ordenes y las facturas son en ese punto semejantes, pero pertenecen a entidades y tablas distintas.
En ese sentido, si existe un concepto "orden", lo que se factura es una Orden o un conjunto de ellas. Entonces, la relación de la factura con los productos pasa a ser indirecta (la orden está entremedio), aunque en la factura vaya la lista de las cosas que están en las ordenes abarcadas.
Como verás, a medida que vas al detalle, empiezan a aparecer cosas que no eran visibles a gran escala.

[exo123]

A ver gnzsoloyo si te sigo con mis modificaciones, tomando como ejemplo el modelo de pedidos anterior elaboré este:




Tengo productos que pueden ser las comidas y las bebidas. Esos productos se pueden pidir en forma individual, como una hamburgesa, lomito, coca-cola, sprite, etc.

La casa tiene menús. Un menú puede ser hamburguesa+papas, 2 hamburguesas+Coca-Cola, etc. Algunos menús tienen definidos descuentos para algunos productos extras que piden.

En las ordenes tengo clientes que pueden ser los que están en el local (una mesa) o alguien que pidió por teléfono, para los que piden en el local el "cliente" sería número de mesa ¿puede ser así?
Edito: clientes con mesa está mal, no tienen realación en nada

Si los menúes componen un mismo conjunto invariable de elementos, el menú es un producto. Es el caso de las ventas de McDonalls, por ejemplo. cada "combo" es un menú. Y los "adicionales", son agregados al pedido que aumentan el precio pero aplican beneficios sobre el importe del Combo.

En mi diagrama veo que cada vez que se pida un menu se debería crear primero un producto "especial" como para saber a que menú pertenece, qué comidas y adicionales se solicitó. ¿ya no sería producto?
Edito: me respondo y a la vez haciendo otra pregunta: En el caso de los adicionales se agrega al pedido una linea con el menu pedido y las demás lineas con los productos individuales pero modificado el precio establecido en los adicionales, funcionaria no?

Para los delivery no es más que agregar al item de pedidos el costo del delivery, no? lo mismo que para el costo de mesa.