sql >> Base de Datos >  >> RDS >> Mysql

Diseño de base de datos:inventario y sistema de ventas?

La solución que está buscando se basará en un modelo de estilo de contabilidad y un par de listas de materiales (BOM). Sus principales tipos de entidades incluirán:

  • SKU Esta es la lista de cosas que vendes. Sus propiedades incluirán cosas como la descripción del producto y el precio minorista actual. Puede ser elegante y desglosar el precio en una tabla secundaria que proporcione precios a lo largo del tiempo. Supongamos que va a dejar esa arruga fuera por ahora. Algunos SKU pueden ser "combos" del tipo del que hablas.

  • COMPONENTE Esta es la lista de cosas que componen un SKU, como servilletas, vasos, bollos, empanadas, jarabe de coca cola, etc., para usar su ejemplo. Así como SKU tiene descripciones y precios, los COMPONENTES tienen descripciones y costos unitarios. (Que también se puede crear un historial en una tabla secundaria). Esta tabla es donde normalmente también almacenaría su ROP.

  • COMPOSICIÓN Esta es una lista de materiales que se cruza con SKU y COMPONENTE y dice cuántas unidades de cada COMPONENTE entran en una unidad de SKU. También necesita uno de estos para cruzar dos SKU (para combos). Puede usar una tabla o dos tablas para esto. Dos tablas mantendrán contentos a los puristas, una tabla será conveniente desde el punto de vista del programador.

  • VENTA Esta es una tabla de transacciones que proporciona un encabezado para registrar una venta de uno o más SKU. Esta tabla tendría cosas como la fecha de la transacción, la identificación del cajero y otros elementos del encabezado.

  • SALE_ITEM Esta es la tabla de detalles de la transacción que incluiría qué SKU se vendió (y cuántos) y por cuánto. El cuánto es una desnormalización del precio del SKU en el momento de la venta, pero también podría incluir cualquier anulación especial del precio. Es bueno desnormalizar el precio realmente cobrado por el SKU porque alguien podría editar el precio de lista en SKU y luego perdería la noción de cuánto se cobró realmente por el artículo en ese momento.

  • INVENTARIO_HDR Esta es una tabla transaccional que es similar conceptualmente a SALE, pero es el encabezado de una transacción de inventario, como recibir nuevo inventario, usar inventario (como venderlo) y para ajustes de inventario. Nuevamente, esto sería material de fecha/descripción, pero puede incluir un enlace directo a SALE_ITEM para movimientos de inventario que son ventas, si lo desea. No es necesario que lo haga de esa manera, pero a algunas personas les gusta establecer la conexión entre los ingresos y los costos transacción por transacción.

  • INVENTARIO_DTL Este es el detalle de una transacción de inventario. Esto indica qué COMPONENTE está entrando o saliendo, la cantidad que entró o salió y la transacción INVENTARIO_HDR a la que se aplicó este movimiento. Aquí también sería donde guarda el costo real pagado por el componente.

  • UBICACIÓN También puede (si lo desea) rastrear la ubicación física del inventario que recibe y usa/vende. En un restaurante, esto puede no ser importante, pero si tiene una cadena o si su restaurante tiene un almacén externo para los componentes, entonces podría interesarle.

Considere el siguiente ERD:

Para hacer su contabilidad de ingresos, estaría sumando el dinero registrado en la tabla SALE_ITEM.

Se calculan los niveles de existencias basado en la suma de las entradas y salidas INVENTORY_DTL para cada COMPONENTE. (No almacene los niveles de existencias actuales en una tabla; esto está condenado a causar problemas de conciliación).

Para hacer su contabilidad de costos, estaría sumando el dinero registrado en la tabla INVENTARIO_DTL. Tenga en cuenta que normalmente no sabrá exactamente cuál servilleta o bollo que vendió, por lo que no será posible vincular recibos de componentes específicos con ventas de SKU específicas. En su lugar, debe tener una convención para determinar qué componentes se usaron para cualquier SKU determinado. Es posible que tenga reglas contables que especifiquen qué convención debe usar. La mayoría de la gente usa FIFO. Algunas industrias usan LIFO e incluso he visto contabilidad de costo promedio ponderado.