Punto de venta y esquema de base de datos de inventario

Question

Estoy tratando de crear un básico Punto de venta y sistema de gestión de inventario.

Algunas cosas a tener en cuenta:

• Los productos son siempre los mismos (el mismo ID) a través de todo el sistema, pero el inventario (unidades disponibles para la venta por producto) es único para cada ubicación. La ubicación Y y Z pueden tener unidades para la venta del producto X, pero si, por ejemplo, se venden dos unidades de la ubicación Y, el inventario de la ubicación Z no debería verse afectado. Sus unidades almacenadas están todavía intactas.
• Vender una (1) unidad de producto X de la ubicación Y, significa que el inventario de la ubicación Y debe restar una unidad de su inventario.

partir de eso, pensé en estas tablas:

• lugares

  • Identificación
  • nombre

• productos

  • Identificación
  • nombre

• transacciones

  • Identificación
  • Descripción

• inventories_header

  • Identificación del
  • LOCATION_ID
  • product_id

• inventories_detail

  • inventories_id
  • TRANSACTION_ID
  • unit_cost
  • UNIT_PRICE
  • cantidad

• orders_header

  • Identificación del
  • fecha
  • total (calculado a partir de la cantidad orders_detail * precio; sólo para la validación de datos futuros)

• orders_detail

  • ORDER_ID
  • transaction_id
  • product_id
  • cantidad
  • precio

Bien, entonces, ¿hay alguna pregunta? Por supuesto.

1. ¿Cómo realizo un seguimiento de los cambios en el costo por unidad? Si algún día empiezo a pagar más por un determinado producto, tendría que hacer un seguimiento de la utilidad marginal ((cost*quantity) - (price*quantity) = marginal utility) de alguna manera. Pensé en inventories_detail principalmente para esto. No me hubiera importado lo contrario.
2. ¿Están bien establecidas las relaciones? Aún me cuesta pensar si las ubicaciones tienen inventarios o si los inventarios tienen varias ubicaciones. Es enloquecedor.
3. ¿Cómo mantendría/conocería sus niveles de stock actuales? Como tenía que separar la tabla de inventario para estar al día con las actualizaciones de costos, supongo que tendría que sumar todas las cantidades indicadas en inventory_detail.
4. Cualquier sugerencia ¿quieres compartir?

Estoy seguro de que todavía tengo algunas preguntas, pero estas son principalmente las que necesito abordar. Además, dado que estoy usando Ruby on Rails por primera vez, en realidad, como experiencia de aprendizaje, es una pena que me detengan en el diseño, sin permitirme acelerar la implementación más rápido, pero supongo que así es como debería ser.

Gracias de antemano.

Answer 1

La parte difícil aquí es que realmente está haciendo más que una solución POS. También está haciendo un sistema de contabilidad de costos básicos de administración de inventario &.

El primer escenario que debe resolver es el método de contabilidad que utilizará para determinar el costo de cualquier artículo vendido. Las opciones más comunes serían FIFO, LIFO o Identificación específica (todos los términos que se pueden buscar en Google).

En los 3 escenarios, debe registrar sus compras de sus bienes en una estructura de datos (normalmente llamada PurchaseOrder, pero en este caso la llamaré SourcingOrder para diferenciarla de sus tablas de pedidos en la pregunta original).

La siguiente estructura asume que cada línea de orden de aprovisionamiento será para una ubicación (de lo contrario las cosas se vuelven aún más complejas). En otras palabras, si compro 2 widgets para tienda de A y 2 B para la tienda, me gustaría añadir 2 líneas a la orden con una cantidad de 2 para cada uno, no una línea con la cantidad 4.

SourcingOrder 
- order_number 
- order_date 

SourcingOrderLine 
- product_id 
- unit_cost 
- quantity 
- location_id 

inventario se puede un nivel ...

InventoryTransaction 
- product_id 
- quantity 
- sourcing_order_line_id 
- order_line_id 
- location_id 
- source_inventory_transaction_id 

Cada vez que un SourcingOrderLine se recibe en una tienda, vamos a crear un InventoryTransaction con una cantidad positiva y las referencias a la FK sourcing_order_line_id, product_id y location_id.

Cada vez que se realiza una venta, que va a crear un InventoryTransaction con una cantidad negativa y las referencias a la FK order_line_id, product_id y location_id, source_inventory_transaction_id.

El source_inventory_transaction_id sería un enlace de la cantidad negativa InventoryTransaction de nuevo a la cantidad positiva InventoryTransaction calculada utilizando el método de contabilidad que elija.

El inventario actual para una ubicación sería SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id.

El costo marginal se calcularía mediante el rastreo de la venta, a través de las 2 transacciones de inventario relacionadas a la línea SourcingOrder.

NOTA: Debe manejar el caso en el que asigna una línea de pedido en 2 transacciones de inventario porque la cantidad pedida fue mayor que lo que quedaba en la próxima transacción de inventario que se asignará. Esta estructura de datos manejará esto, pero deberá trabajar la lógica y consultar usted mismo.

Answer 2

Brian es correcto. Solo para agregar información adicional. Si está trabajando en un sistema completo para su negocio o cliente. Sugeriría que empiece a trabajar en el nivel organizacional hasta el proceso de POS y contabilidad. Eso haría que tu experiencia con la base de datos sea más extensa ...: P En mi experiencia en el desarrollo de sistemas, los módulos de inventario siempre comienzan con la toma de existencias + (compras-devoluciones de compras) = ​​SKU disponible para ventas. El POS no está directamente conectado al módulo de inventario, sino que el supervisor de ventas lo conciliará diariamente. Las cantidades totales de ventas diarias se deducirán de SKU disponible para las ventas. también trabajará en los módulos de cálculo de costos y precios. La correcta normalización de la base de datos siempre es imprescindible.