database design - Facturación versus cotización o estimación
database-design quoting (5)
En el último sistema en el que trabajé, la única diferencia entre presupuestos y facturas (en términos de db) era una bandera en la tabla que indicaba si la cotización había sido aceptada por el cliente (en ese momento se generó otra declaración con todo el mismo información excepto que era una factura en lugar de una cotización)
Si las facturas pueden ser anuladas, ¿deberían usarse como cotizaciones?
Tengo una tabla de Invoices que se crea a partir del inventario asociado a un Job o Order . Podría tener una tabla de Quotes como un punto intermedio entre el inventario y las facturas, pero parece que tendría estructuras de datos y lógica duplicadas solo para manejar un "¿Esto es una cita?" poco.
Desde una perspectiva comercial, las cotizaciones son diferentes a las facturas: se envía una cotización antes de una empresa y se envía una factura una vez que se completa y se vence el pago, pero cómo representar esto en mi repositorio y modelo.
- ¿Cuál es una manera elegante de almacenar y administrar presupuestos y facturas en una base de datos?
Editar: Job indicado === Order para esta instancia particular.
Hay 3 enfoques:
Almacene las facturas y las cotizaciones en tablas separadas.
Este es un buen diseño si las facturas y las cotizaciones tienen pocos campos por duplicado (de lo contrario, use la opción n. ° 3 con 3 tablas), y si hay una relación de 1-muchos o muchos-muchos entre ellos (para 1-1, use la opción n. ° 2 )
Esta es también una buena opción si es común que la información "compartida" entre los dos pueda realmente mutar cuando la cotización se convierte en la factura (aunque algunas de estas mutaciones deben manejarse adecuadamente con campos / tablas separadas, como descuentos aplicados, etc. .).
Una pequeña variación de esta opción, obviamente, se necesita hacer cuando las cotizaciones múltiples se convierten en una sola (o múltiples) facturas. Esto agrega una tercera tabla que es un mapeo entre un conjunto de presupuestos y una factura (o un conjunto de facturas si se vuelve tan complicado) para ellos.
Guárdelos en la misma tabla, con bandera adicional "Factura o presupuesto" y cualquier campo adicional de ambos almacenados. Esto se puede hacer con facturas y citas en distintas filas, o con ellas compartiendo filas (con indicador que también tenga "ambos" valores).
El último (la misma fila puede ser tanto la factura como la cotización) es una buena opción si están mapeados de 1 a 1 , y hay pocos campos que los distingan.
El primero (filas separadas para las facturas y las cotizaciones) no es un buen diseño en general y mejor con las opciones n. ° 3 o n. ° 1.
Tiene 3 tablas, una para los campos comunes entre las dos y dos solo para las facturas y las comillas.
Esta es una buena opción si las facturas y las cotizaciones se asignan 1-1, o si son 1-muchas, pero cada una de las muchas facturas tiene exactamente los mismos valores de campo para los campos que sean comunes. De lo contrario, use # 1.
Se puede hacer una pequeña variación de esta opción cuando las cotizaciones múltiples se convierten en una sola factura. Esto agrega una 4ta tabla que es un mapeo entre un conjunto de presupuestos y una factura (o un conjunto de facturas si se vuelve tan complicado) para ellos. Una vez más, la suposición aquí es que hay una gran cantidad de información común entre todas las citas y facturas vinculadas / combinadas juntas, de lo contrario, solo vaya con # 1.
Las citas son más análogas a las órdenes. He visto varios sistemas de distribución / venta minorista con una tabla de pedidos que tiene una bandera booleana llamada algo así como IsQuote. Esto puede parecer simple ya que hace que sea trivial convertir una cotización en una orden. Nunca me gustó porque los pedidos que salen de las cotizaciones no siempre son exactamente como se mencionan. Como resultado, sistemas como esos pierden información que puede ser de alguna utilidad (es decir, un informe que compara presupuestos con pedidos). Por lo tanto, prefiero los sistemas en los que las tablas de cotización y orden son más o menos iguales. En los sistemas de distribución, esto a menudo conduce a tablas como OrderHeader, OrderLine (se refiere a la tabla de artículos / inventario), QuoteHeader y QuoteLine. También puede tener una tabla para modelar una relación en la que una cotización puede correlacionarse con varias órdenes.
Las facturas suelen ser el resultado de pedidos. En ocasiones, más de un pedido se facturará en una única factura. Por ejemplo, hay casos en los que he visto que las empresas facturan mensualmente a sus buenos clientes. También lo he visto funcionar a la inversa, donde un pedido grande con múltiples envíos se factura en varias facturas (una por cada envío).
Finalmente, los pagos generalmente tienen una relación muchos a muchos con la factura. Algunas veces, un pago cubre múltiples facturas. A veces, una factura se paga en un par de pagos.
Yo recomendaría ser lo más flexible posible. Use las siguientes tablas
Tabla de trabajo, tabla de facturas, tabla de cotización
En su tabla de facturas y tabla de cotización, almacene el Id. De trabajo, proporciónele un índice y cree una restricción de clave externa. Deje el índice agrupado en la identificación de la oferta y la identificación de la factura.
[Producto único, y servicios ignorados, por simplicidad.]
Una oferta de venta es una propuesta para vender un bien por un precio en una ventana de tiempo (rango de fechas) a otra parte. Este activo no necesita existir todavía Podría citar la especificación del activo (el bien).
Una cotización debe vencer en algún momento y puede o no aceptarse antes de su vencimiento.
Una orden de venta es un compromiso de vender un bien por un precio en una fecha a otra parte. Se puede crear a partir de una cita aceptada.
Una orden o presupuesto puede tener condiciones de pago, como "puede pagarnos 30 días después de la entrega".
Un pedido puede ser para un bien que aún no existe (usted vende el bien, no el activo). Quizás lo estás construyendo. Tal vez lo vas a comprar a otra persona.
Una orden de venta conduce a la adquisición (tomar de inventario, hacer o comprar) de un activo físico, y luego el envío del activo físico, que puede o no terminar en una entrega. A veces, el cliente "llamará" al vendedor para retirar el activo.
En términos generales, debe transferirse un activo antes de que pueda contar la línea de pedido como ingresos (esto depende de los términos de envío, puede ser en el envío o la entrega o en el medio).
Se puede cancelar una orden de venta (por ejemplo, algunas industrias tienen períodos de enfriamiento).
Una factura de venta es una solicitud de pago para productos pedidos. Puede suceder antes de la entrega, en el momento de la entrega o después de la entrega, o puede que no suceda en absoluto (como en la cola de McDonald''s). Un pedido puede tener una o más facturas, y una factura puede ser para varios pedidos.
Una factura con suerte conduce a uno o más pagos , que se aplican a una cuenta . Un pago a menudo conduce a uno o más recibos de pago . Un pago no es necesariamente lo mismo que los ingresos, si se utiliza la contabilidad de ejercicio.