Schéma de base de données de point de vente et d'inventaire

Je suis en train de créer un de base Point de Vente et le système de gestion des Stocks.

Certaines choses à prendre en compte:

  • Les produits sont toujours les mêmes (même ID) à travers l'ensemble du système, mais l'inventaire (unités disponibles à la vente par produit) est unique pour chaque emplacement. Emplacement de Y et Z ont tous deux pour des unités de vente du produit X, mais si, par exemple, deux unités sont vendues à partir de l'adresse Y, emplacement Z inventaire ne devrait pas être affectée. Son approvisionné unités sont encore intacts.
  • De la vente d'une (1) unité de produit X à partir de l'adresse Y, les moyens de l'inventaire de l'emplacement de Y soustraire une unité à partir de son inventaire.

De cela, j'ai pensé à ces tableaux:

  • endroits
    • id
    • nom
  • produits
    • id
    • nom
  • transactions
    • id
    • description
  • inventories_header
    • id
    • location_id
    • product_id
  • inventories_detail
    • inventories_id
    • l'identificateur de la transaction
    • unit_cost
    • unit_price
    • quantité
  • orders_header
    • id
    • date
    • total (calculé à partir de orders_detail quantité * prix; seulement pour l'avenir, la validation des données)
  • orders_detail
    • order_id
    • l'identificateur de la transaction
    • product_id
    • quantité
    • prix

Bon, alors, y at-il des questions? Bien sûr.

  1. Comment puis-je suivre les changements dans les parts coût? Si un jour j'ai commencer à payer plus pour un produit donné, j'aurais besoin de garder une trace de l'utilité marginale ((cost*quantity) - (price*quantity) = marginal utility) d'une certaine façon. J'ai pensé à inventories_detail principalement pour cette. Je n'aurais pas pris soin autrement.
  2. Sont des relations bien établies? J'ai encore une difficulté à penser si les lieux ont des stocks, ou si les stocks ont plusieurs emplacements. C'est exaspérant.
  3. Comment voulez-vous garder/connaître vos niveaux de stocks en cours? Depuis que j'ai eu pour séparer la table des stocks de garder en place avec le coût des mises à jour, je suppose que je voudrais juste ajouter toutes les quantités indiquées dans inventories_detail.
  4. Toutes les suggestions que vous voulez partager?

Je suis sûr que j'ai encore quelques questions, mais elles sont pour la plupart ceux que j'ai à traiter. Aussi, depuis que je suis en utilisant Ruby on Rails pour la première fois, en fait, comme une expérience d'apprentissage, c'est une honte d'être arrêté lors de la conception, de ne pas me laisser percer à travers la mise en œuvre plus rapide, mais je suppose que c'est la façon dont il devrait être.

Merci d'avance.

source d'informationauteur Andrés Botero

  1. 18

    La partie la plus délicate ici, c'est que vous êtes vraiment faire plus qu'une solution POS. Vous êtes également fait une gestion des stocks & base du système de comptabilité analytique.

    Le premier scénario, vous devez répondre est ce que la méthode de la comptabilité que vous allez utiliser pour déterminer le coût de tout article vendu. Les options les plus courantes serait FIFO, LIFO, ou d'Identification Spécifiques (tous les termes qui peuvent être Googlé).

    Dans tous les 3 scénarios, vous devez enregistrer vos achats, de vos biens dans une structure de données (généralement appelé PurchaseOrder, mais dans ce cas, je vais l'appeler SourcingOrder à différencier de vos tables de commandes dans la question d'origine).

    La structure ci-dessous, on suppose que chaque sourcing ligne de commande sera pour une localisation (sinon, les choses deviennent encore plus complexes). En d'autres termes, si j'achète 2 widgets pour stocker Un et 2 pour le magasin B, j'aimerais ajouter 2 lignes à la commande de la quantité 2 pour chaque, pas une ligne avec la quantité 4.

    SourcingOrder
 - order_number
 - order_date

SourcingOrderLine
 - product_id
 - unit_cost
 - quantity
 - location_id

    Inventaire peut être d'un niveau...

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

    Chaque fois qu'un SourcingOrderLine est reçu dans un magasin, vous allez créer un InventoryTransaction avec une quantité positive et FK références à la sourcing_order_line_idproduct_id et location_id.

    Chaque fois qu'une vente est faite, vous allez créer un InventoryTransaction avec une quantité négative et FK références à la order_line_idproduct_id et location_idsource_inventory_transaction_id.

    La source_inventory_transaction_id serait un lien à partir de la quantité négative InventoryTransaction retour à la postiive quantité InventoryTransaction calculé à l'aide de la méthode de comptabilisation à vous de choisir.

    Inventaire actuel pour un emplacement serait SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ?
    GROUP BY product_id, location_id    .

    Coût Marginal serait calculée en remontant à partir de la vente, par le biais de l'2 inventaire des transactions à la SourcingOrder ligne.

    REMARQUE: Vous avez à gérer le cas où vous allouer une ligne de commande sur 2 transactions de stock en raison de la quantité commandée a été plus importante que ce qui a été laissé dans l'inventaire de la transaction à être affecté. Cette structure de données permettra de gérer cela, mais vous aurez besoin de travailler la logique et de la requête de vous-même.

  2. 2

    Brian est correcte. Juste pour ajouter des informations supplémentaires. Si vous travaillez dans un système complet pour votre entreprise ou votre client. Je voudrais vous suggérer de commencer à travailler sur le plan organisationnel qu'au niveau du processus d'ENCAISSEMENT et de la comptabilité. Que ferait votre expérience de base de données plus vaste... 😛 Dans mon expérience dans le système de développement, de l'Inventaire des modules de toujours commencer avec le stock de prendre+(achats-achat retourne)=SKU disponibles à la vente. POS n'est pas directement connecté au module d'Inventaire, mais plutôt de se réconcilier quotidiennement par le superviseur des ventes. Total des Ventes Quotidiennes quantités seront ensuite déduits de SKU disponibles à la vente. vous travaillerez également sur le calcul des coûts et tarification des modules. Corriger la normalisation de la base de données est toujours un must.