La solution que vous recherchez s'appuiera sur un modèle de style comptable et quelques nomenclatures. Vos principaux types d'entités comprendront :
-
SKU C'est la liste des choses que vous vendez. Ses propriétés incluront des éléments tels que la description du produit et le prix de détail actuel. Vous pouvez faire preuve de fantaisie et répartir le prix dans une table enfant qui donne les prix au fil du temps. Supposons que vous allez laisser cette ride de côté pour le moment. Certains SKU peuvent être des "combos" du type dont vous parlez.
-
COMPOSANT Voici la liste des éléments qui composent un SKU, tels que des serviettes, des tasses, des petits pains, des galettes, du sirop de coke, etc. - pour utiliser votre exemple. Tout comme les SKU ont des descriptions et des prix, les COMPOSANTS ont des descriptions et des coûts unitaires. (Qui peut également être historisé dans une table enfant.) Cette table est l'endroit où vous stockez également votre ROP.
-
COMPOSITION Il s'agit d'une nomenclature qui croise le SKU et le COMPOSANT et indique combien d'unités de chaque COMPOSANT entrent dans une unité d'un SKU. Vous en avez également besoin pour croiser deux SKU (pour les combos). Vous pouvez utiliser une table ou deux tables pour cela. Deux tableaux feront le bonheur des puristes, un tableau sera opportun du point de vue du codeur.
-
VENTE Il s'agit d'une table de transactions qui fournit un en-tête pour enregistrer une vente d'un ou plusieurs SKU. Ce tableau contiendrait des éléments tels que la date de transaction, l'ID du caissier et d'autres éléments d'en-tête.
-
SALE_ITEM Il s'agit du tableau des détails de la transaction qui inclurait quel SKU a été vendu (et combien) et pour combien. Le montant correspond à une dénormalisation du prix SKU au moment de la vente, mais peut également inclure toute modification spéciale du prix. Le prix réellement facturé pour le SKU est une bonne chose à dénormaliser, car quelqu'un pourrait modifier le prix catalogue dans le SKU et vous perdriez alors la trace du montant réellement facturé pour l'article à ce moment-là.
-
INVENTORY_HDR Il s'agit d'une table transactionnelle similaire à la VENTE sur le plan conceptuel, mais il s'agit de l'en-tête d'une transaction de stock, telle que la réception d'un nouveau stock, l'utilisation du stock (comme pour le vendre) et les ajustements de stock. Encore une fois, ce serait des éléments de date/description, mais cela peut inclure un lien direct vers un SALE_ITEM pour les mouvements de stock qui sont des ventes si vous le souhaitez. Vous n'êtes pas obligé de le faire de cette façon, mais certaines personnes aiment établir le lien entre les revenus et les coûts transaction par transaction.
-
INVENTORY_DTL Il s'agit du détail d'une transaction de stock. Cela indique quel COMPONENT entre ou sort, la quantité qui est entrée ou sortie et la transaction INVENTORY_HDR à laquelle ce mouvement s'applique. C'est également là que vous conservez le coût réel payé pour le composant.
-
EMPLACEMENT Vous pouvez (si vous le souhaitez) également suivre l'emplacement physique de l'inventaire que vous recevez et utilisez/vendez. Dans un restaurant, cela peut ne pas être important, mais si vous avez une chaîne ou si votre restaurant dispose d'un entrepôt hors site pour les composants, cela peut vous intéresser.
Considérez l'ERD suivant : 
Pour faire votre comptabilité des revenus, vous additionnerez l'argent enregistré dans la table SALE_ITEM.
Les niveaux de stock sont calculés basé sur l'addition des entrées et sorties INVENTORY_DTL pour chaque COMPOSANT. (Ne stockez pas les niveaux de stock actuels dans un tableau - Cela est voué à causer des problèmes de réconciliation.)
Pour faire votre comptabilité analytique, vous additionnerez l'argent enregistré dans la table INVENTORY_DTL. Notez que vous ne saurez généralement pas exactement quel serviette ou petit pain que vous avez vendu, il ne sera donc pas possible de lier des reçus de composants spécifiques à des ventes de SKU spécifiques. Au lieu de cela, vous devez avoir une convention pour déterminer quels composants ont été utilisés pour un SKU donné. Vous pouvez avoir des règles comptables qui précisent quelle convention vous devez utiliser. La plupart des gens utilisent FIFO. Certaines industries utilisent LIFO et j'ai même vu la comptabilisation des coûts moyens pondérés.
