Conception de firebase database d’inventaire

Il ne s’agit pas vraiment d’une question de “programmation” (qui n’est pas spécifique à un langage ou à une firebase database), mais plutôt de conception et d’architecture. C’est aussi une question du type “Quelle est la meilleure façon de faire X”. J’espère que ne cause aucune controverse «religieuse».

Dans le passé, j’ai développé des systèmes qui, d’une manière ou d’une autre, conservent une certaine forme d’inventaire des articles (peu importe quels articles). Certains utilisent des langages / DB qui ne supportent pas les transactions. Dans ces cas, j’ai choisi de ne pas enregistrer la quantité d’ articles en main dans un champ de la fiche article. Au lieu de cela, la quantité disponible est calculée en calculant le total des stocks reçus – total des stocks vendus. Cela a eu pour résultat presque aucune divergence dans l’inventaire en raison du logiciel. Les tables sont correctement indexées et les performances sont bonnes. Il y a un processus d’archivage au cas où la quantité d’enregistrement commence à affecter les performances.

Il y a quelques années, j’ai commencé à travailler dans cette société et j’ai hérité d’un système de suivi des stocks. Mais la quantité est enregistrée dans un champ. Lorsqu’une entrée est enregistrée, la quantité reçue est ajoutée au champ de quantité de l’article. Lorsqu’un article est vendu, la quantité est soustraite. Cela a entraîné des divergences. A mon avis, ce n’est pas la bonne approche, mais les programmeurs précédents ne jurent que par elle.

J’aimerais savoir s’il existe un consensus sur la manière de concevoir un tel système. Quelles ressources sont disponibles, imprimées ou en ligne, pour obtenir des conseils à ce sujet.

Merci

J’ai vu les deux approches dans mon entreprise actuelle et je me tournerais certainement vers la première (calcul des totaux en fonction des transactions sur actions).

Si vous stockez seulement une quantité totale dans un champ, vous n’avez aucune idée de la manière dont vous êtes arrivé à ce nombre. Il n’y a pas d’historique transactionnel et vous pouvez vous retrouver avec des problèmes.

Le dernier système que j’ai écrit suit le stock en stockant chaque transaction comme un enregistrement avec une quantité positive ou négative. J’ai trouvé que cela fonctionne très bien.

  • Le livre de ressources du modèle de données, vol. 1: Une bibliothèque de modèles de données universels pour toutes les entresockets
  • Le livre de ressources du modèle de données, vol. 2: une bibliothèque de modèles de données pour des indussortinges spécifiques
  • Le livre de ressources du modèle de données: modèles universels pour la modélisation des données

J’ai Vol 1 et Vol 2 et ceux-ci ont été très utiles par le passé.

Cela dépend, les systèmes d’inventaire sont beaucoup plus que de simplement compter les articles. Par exemple, pour des raisons de comptabilité, vous devrez peut-être connaître la valeur comptable des stocks sur la base du modèle FIFO (premier entré, premier sorti). Cela ne peut pas être calculé par une simple formule de «total des stocks reçus – total des stocks vendus». Mais leur modèle peut le calculer facilement, car ils modifient la valeur comptable au fur et à mesure. Je ne veux pas entrer dans les détails, car ce n’est pas un problème de programmation, mais s’ils ne jurent que par cela, vous n’avez peut-être pas compris toutes les exigences auxquelles ils doivent répondre.

les deux sont valables, selon les circonstances. Le premier est le meilleur lorsque les conditions suivantes sont réunies:

  • le nombre d’articles à sum est relativement petit
  • il y a peu ou pas de cas exceptionnels à prendre en compte (retours, ajustements, etc.)
  • la quantité d’articles en stock n’est pas nécessaire très souvent

d’autre part, si vous avez un grand nombre d’articles, plusieurs cas exceptionnels et un access fréquent, il sera plus efficace de maintenir la quantité d’articles.

Notez également que si votre système présente des anomalies, il contient des bogues qui doivent être détectés et éliminés.

J’ai fait des systèmes dans les deux sens, et les deux méthodes peuvent fonctionner très bien – à condition de ne pas ignorer les bogues!

Jetez un coup d’œil au modèle de données ARTS (Association for Retail Technology Standards) ( http://nrf-arts.org ). Il utilise une table StockLedger avec un enregistrement chaque article et les modifications apscopes à l’inventaire sont toutes suivies dans InventoryJournalEnsortinges.

Il est important de prendre en compte le système existant et le coût et le risque de le changer. Je travaille avec une firebase database qui stocke un inventaire un peu comme le vôtre, mais il comprend des cycles d’audit et des ajustements de magasins, tout comme les reçus. Cela semble bien fonctionner, mais toutes les personnes impliquées sont bien formées et le personnel de l’entrepôt n’est pas très rapide pour apprendre de nouvelles procédures.

Dans votre cas, si vous recherchez un peu plus de suivi sans modifier toute la structure de la firebase database, je vous suggère d’append une table de suivi (un peu comme dans votre solution de transaction), puis de consigner les modifications au niveau de l’inventaire. Il ne devrait pas être trop difficile de mettre à jour la plupart des modifications apscopes au niveau de l’inventaire afin qu’elles permettent également de conserver un enregistrement de transaction. Vous pouvez également append une tâche périodique pour sauvegarder le niveau d’inventaire dans la table des transactions toutes les deux heures environ, de sorte que même si vous manquez une transaction, vous pouvez détecter le changement ou revenir à un état antérieur.

Si vous voulez voir comment une application volumineuse se penche sur SugarCRM , elle possède un module de gestion des stocks, mais je ne sais pas comment elle stocke les données.

J’opterais pour la première manière, où

la quantité en stock est calculée en totalisant l’inventaire reçu – total des stocks vendus

La bonne manière, IMO.

EDIT: Je voudrais également prendre en compte toutes les pertes de stock / dommages dans le système, mais je suis sûr que vous avez couvert.

Je pense qu’il s’agit en fait d’une question générale sur les meilleures pratiques pour effectuer un décompte (relativement) coûteux chaque fois que vous avez besoin d’un total ou d’un décompte chaque fois que quelque chose change. total.

Si je ne pouvais pas utiliser les transactions, j’irais avec le compte en direct chaque fois que j’avais besoin d’un total. Si des transactions sont disponibles, il serait prudent d’effectuer les opérations de mise à jour de l’inventaire et l’enregistrement du total recompté dans la même transaction, ce qui garantirait l’exactitude du décompte (bien que je ne sois pas certain que cela fonctionnerait avec plusieurs utilisateurs) bash la firebase database).

Mais si les performances ne sont pas vraiment un gros problème (et que les bases de données modernes sont assez bonnes pour compter les lignes que je ne craindrais même pas du tout), je me contenterais du compte en direct à chaque fois.

J’ai travaillé sur des systèmes qui résolvent ce problème auparavant. Je pense que la solution idéale est une colonne précalculée, qui vous procure le meilleur des deux mondes. Votre total serait un champ quelque part, donc pas de recherches coûteuses, mais il ne peut pas se synchroniser avec le rest de vos données (la firebase database conserve son intégrité). Je ne me souviens plus quels RDMS prennent en charge les colonnes précalculées, mais si vous ne disposez pas de transactions, cela peut ne pas être disponible non plus.

Vous pourriez potentiellement simuler des colonnes précalculées (très efficacement … Je ne vois aucun inconvénient) en utilisant des déclencheurs. Vous auriez probablement besoin de transactions cependant. IMHO, garder l’intégrité des données lorsque vous faites ce type de dénormalisation contrôlée est la seule utilisation légitime d’un déclencheur.

Je peux voir certains avantages à avoir les deux colonnes, mais je ne suis pas la partie sur les divergences – vous semblez laisser entendre que le fait d’avoir les deux colonnes (in et out) est moins sujet à une divergence qu’une seule colonne (current). Pourquoi donc?

Django-inventory est davantage axé sur les immobilisations, mais pourrait vous donner quelques idées.

IE: ItemTemplate (classe) -> ItemsOnHand (instance)

ItemsOnHand peut être lié à d’autres ItemTemplates; Exemple L’imprimante et les cartouches d’encre sont nécessaires. Cela permet également de définir des points de réapprovisionnement pour chaque ItemOnHand.

Chaque ItemsOnHand est lié à InventoryTransactions, ce qui facilite les audits. Pour éviter de calculer des articles en main à partir de milliers de transactions, les points de contrôle ne sont qu’un solde + une date. Calculer les éléments à la demande pour trouver le sharepoint contrôle le plus récent et commencer à append ou à soustraire des éléments pour trouver le solde actuel des articles. Définir de nouveaux points de contrôle périodiquement.

Ne pas avoir une ou deux colonnes, ce que je voulais dire avec “inventaire total reçu – total des stocks vendus” est quelque chose comme ceci:

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

puis

 Qunatity_on_hand = inventory_received - inventory_sold 

S’il vous plaît gardez à l’esprit que j’ai trop simplifié cela et mon explication initiale. Je sais qu’il y a beaucoup plus à inventorier qu’il suffit de garder une trace des quantités, mais dans ce cas, c’est le problème qui se pose et ce que nous voulons corriger. À ce stade, la raison de le changer est précisément le coût de la prise en charge des problèmes causés par la conception actuelle.

Je voulais aussi mentionner que bien que ce ne soit pas une question de “codage”, celle-ci est liée à des algorithmes et à la conception, dont IMHO est un sujet très important.

Merci à tous pour vos réponses jusqu’ici.

Nelson Marmol

Nous résolvons différents problèmes, mais notre approche de certains d’entre eux pourrait vous intéresser.

Nous permettons au système de faire une “meilleure estimation” et de donner aux utilisateurs des informations régulières sur toutes les suppositions qui semblent erronées.

Pour appliquer ceci à l’inventaire, vous pouvez avoir 3 champs:

 inventory_received inventory_sold estimated_on_hand 

Ensuite, vous pouvez exécuter un processus (quotidien?) Selon les critères suivants:

 SELECT * FROM Inventory WHERE estimated_on_hand != inventory_received - inventory_sold 

Bien sûr, cela dépend des utilisateurs qui regardent cette alerte et qui font quelque chose.

De plus, vous pourriez avoir une fonction pour réinitialiser certains inventeurs, soit en mettant à jour inventory_sold / received, soit en ajoutant un autre champ “inventory_adjustment”, qui pourrait être positif ou négatif.

… juste quelques reflections. J’espère que c’est utile.