tracker source software open online management app database design inventory

database - source - Diseño de la base de datos



inventory tracker (13)

Esta no es realmente una cuestión de "programación" (no es específica de ningún idioma o base de datos), sino más de diseño y arquitectura. También es una cuestión del tipo "Cuál es la mejor manera de hacer X". Espero que no cause mucha controversia "religiosa".

En el pasado, he desarrollado sistemas que de una manera u otra mantienen algún tipo de inventario de artículos (no relevante qué artículos). Algunos utilizan lenguajes / bases de datos que no admiten transacciones. En esos casos, opté por no guardar la cantidad de artículos a mano en un campo en el registro del artículo. En cambio, la cantidad disponible se calcula sumando el inventario recibido: total del inventario vendido. Esto ha resultado en casi ninguna discrepancia en el inventario debido al software. Las tablas están indexadas correctamente y el rendimiento es bueno. Existe un proceso de archivo en caso de que la cantidad de registro comience a afectar el rendimiento.

Ahora, hace algunos años comencé a trabajar en esta empresa y heredé un sistema que rastrea el inventario. Pero la cantidad se guarda en un campo. Cuando se registra una entrada, la cantidad recibida se agrega al campo de cantidad para el artículo. Cuando se vende un artículo, se resta la cantidad. Esto ha resultado en discrepancias. En mi opinión, este no es el enfoque correcto, pero los programadores anteriores aquí lo juran.

Me gustaría saber si existe un consenso sobre cuál es la forma correcta de diseñar dicho sistema. También qué recursos están disponibles, impresos o en línea, para buscar orientación al respecto.

Gracias

Creo que esta es en realidad una pregunta general sobre las mejores prácticas sobre hacer un recuento (relativamente) caro cada vez que necesita un total vs. hacerlo que cuenta cada vez que algo cambia, luego almacenar el conteo en un campo y leer ese campo cada vez que necesite un total.

Si no pudiera usar las transacciones, iría con el recuento en vivo cada vez que necesitara un total. Si hay transacciones disponibles, sería seguro realizar las operaciones de actualización del inventario y el ahorro del total contabilizado dentro de la misma transacción, lo que garantizaría la precisión del conteo (aunque no estoy seguro de que esto funcione con múltiples usuarios). golpeando la base de datos).

Pero si el rendimiento no es realmente un gran problema (y las bases de datos modernas son lo suficientemente buenas para contar filas que rara vez me preocuparía por esto), me quedaría con el conteo en vivo cada vez.

Depende, los sistemas de inventario son mucho más que solo contar elementos. Por ejemplo, para fines contables, es posible que necesite conocer el valor contable del inventario en base al modelo FIFO (Primero en entrar, primero en salir). Eso no se puede calcular por simple fórmula de "totalización de inventario recibido - total de inventario vendido". Pero su modelo podría calcular esto fácilmente, porque modifican el valor contable a medida que avanzan. No quiero entrar en detalles porque esto no es un problema de programación, pero si lo juran, quizás no entendieron completamente todos sus requisitos que deben cumplir.

Eche un vistazo al modelo de datos ARTS (Asociación para los Estándares Tecnológicos Minoristas) ( http://nrf-arts.org ). Utiliza una tabla StockLedger con un registro de cada elemento y los cambios en el inventario se rastrean en InventoryJournalEntries.

Es importante considerar el sistema existente y el costo y el riesgo de cambiarlo. Trabajo con una base de datos que almacena un tipo de inventario como el tuyo, pero incluye ciclos de auditoría y ajustes de tiendas al igual que los recibos. Parece que funciona bien, pero todos los involucrados están bien capacitados, y el personal del almacén no es exactamente rápido para aprender nuevos procedimientos.

En su caso, si está buscando un poco más de seguimiento sin cambiar toda la estructura de db, le sugiero que agregue una tabla de seguimiento (similar a la de su solución de "transacción") y luego registre los cambios en el nivel de inventario. No debería ser demasiado difícil actualizar la mayoría de los cambios en el nivel de inventario para que también dejen un registro de transacción. También puede agregar una tarea periódica para hacer una copia de seguridad del nivel de inventario en la tabla de transacciones cada dos horas aproximadamente para que, incluso si pierde una transacción, puede descubrir cuándo sucedió el cambio o volver a un estado anterior.

Si quiere ver cómo funciona una aplicación grande, eche un vistazo a SugarCRM , tienen un módulo de administración de inventario, aunque no estoy seguro de cómo almacena los datos.

He visto ambos enfoques en mi compañía actual y definitivamente me inclinaría hacia el primero (cálculo de totales basado en transacciones de acciones).

Si solo está almacenando una cantidad total en un campo en algún lugar, no tiene idea de cómo llegó a ese número. No hay historial de transacciones y puede terminar con problemas.

El último sistema que escribí hace un seguimiento del stock almacenando cada transacción como un registro con una cantidad positiva o negativa. He encontrado que funciona muy bien.

No tener una o dos columnas, lo que quise decir con "totalizar el inventario recibido, el total del inventario vendido" es algo como esto:

Select sum(quantity) as inventory_received from Inventory_entry Select sum(quantity) as inventory_sold from Sales_items

entonces

Qunatity_on_hand = inventory_received - inventory_sold

Tenga en cuenta que simplifiqué esto y mi explicación inicial. Sé que hay mucho más para inventariar que simplemente hacer un seguimiento de las cantidades, pero en este caso, ese es el problema y lo que queremos solucionar. En este punto, el motivo para cambiarlo es precisar el costo de soportar los problemas causados ​​por el diseño actual.

También quería mencionar que, aunque esta no es una cuestión de "codificación", está relacionada con los algoritmos y el diseño, que en mi humilde opinión son temas muy importantes.

Gracias a todos por sus respuestas hasta ahora.

Nelson Marmol

Optaría por la primera manera, donde

la cantidad disponible se calcula sumando el inventario recibido - total del inventario vendido

El camino correcto, IMO.

EDITAR: También me gustaría tener en cuenta las pérdidas / daños en el sistema, pero estoy seguro de que tiene eso cubierto.

Puedo ver algunos beneficios de tener las dos columnas, pero no estoy siguiendo la parte sobre las discrepancias: parece implicar que tener las dos columnas (dentro y fuera) es menos propenso a la discrepancia que una sola columna (actual). ¿Porqué es eso?

Resolvemos diferentes problemas, pero nuestro enfoque para algunos de ellos puede ser interesante para usted.

Permitimos que el sistema haga una "mejor conjetura" y les proporcionamos a los usuarios comentarios frecuentes sobre cualquiera de esas conjeturas que parecen incorrectas.

Para aplicar esto al inventario, puede tener 3 campos:

inventory_received inventory_sold estimated_on_hand

Entonces, podría ejecutar un proceso (¿al día?) En la línea de:

SELECT * FROM Inventory WHERE estimated_on_hand != inventory_received - inventory_sold

Por supuesto, esto depende de que los usuarios miren esta alerta y hagan algo al respecto.

Además, podría tener una función para restablecer el inventario de algún modo, ya sea actualizando inventory_sold / received, o quizás agregando otro campo "inventory_adjustment", que podría ser positivo o negativo.

... solo algunos pensamientos. Espero que sea útil.

Trabajé en sistemas que resuelven este problema antes. Creo que la solución ideal es una columna precalculada, que te ofrece lo mejor de ambos mundos. Su total sería un campo en algún lugar, por lo tanto, no hay costosas búsquedas, pero no se puede desconectar con el resto de sus datos (la base de datos mantiene la integridad). No recuerdo qué RDMS admiten columnas precalculadas, pero si no tiene transacciones, es posible que tampoco estén disponibles.

Es posible que falsifique columnas precalculadas (de manera muy efectiva ... no veo inconvenientes) utilizando desencadenantes. Sin embargo, probablemente necesites transacciones. En mi humilde opinión, mantener la integridad de los datos cuando se está haciendo este tipo de desnormalización controlada es el único uso legítimo para un desencadenante.

ambos son válidos, dependiendo de las circunstancias. Lo primero es mejor cuando se cumplen las siguientes condiciones:

  • la cantidad de elementos a sumar es relativamente pequeña
  • hay pocos o ningún caso excepcional a considerar (devoluciones, ajustes, etc.)
  • la cantidad del artículo del inventario no se necesita con mucha frecuencia

por otro lado, si tiene una gran cantidad de artículos, varios casos excepcionales y acceso frecuente, será más eficiente mantener la cantidad del artículo

También tenga en cuenta que si su sistema tiene discrepancias, entonces tiene errores que deben rastrearse y eliminarse.

He hecho sistemas en ambos sentidos, y ambas maneras pueden funcionar bien, ¡siempre y cuando no ignores los errores!

Django-inventory orientó más a los activos fijos, pero podría darle algunas ideas.

IE: ItemTemplate (clase) -> ItemsOnHand (instancia)

ItemsOnHand se puede vincular a más ItemTemplates; Ejemplo de impresora y los cartuchos de tinta son necesarios. Esto también permite establecer puntos de Reorden para cada ItemOnHand.

Cada ItemsOnHand está vinculado a InventoryTransactions, esto permite una auditoría fácil. Para evitar el cálculo de artículos reales de miles de transacciones inventadas, se utilizan puntos de control que son solo un saldo + una fecha. Para calcular elementos en consulta manual, busque el punto de control más reciente y comience a agregar o sustraer elementos para encontrar el saldo actual de los artículos. Definir nuevos puntos de control periódicamente.