Решението, което търсите, ще разчита на модел на счетоводен стил и няколко сметки за материали (BOM). Основните ви типове обекти ще включват:
-
SKU Това е списъкът с нещата, които продавате. Неговите свойства ще включват неща като описание на продукта и текуща цена на дребно. Можете да получите фантазия и да разбиете цената в дъщерна таблица, която дава цени с течение на времето. Да предположим, че засега ще оставите тази бръчка. Някои SKU могат да бъдат "комбота" от вида, за който говорите.
-
КОМПОНЕНТ Това е списъкът с неща, които съставляват SKU, като салфетки, чаши, кифлички, банички, сироп от кока-кола и т.н. - за да използвам вашия пример. Точно както SKU има описания и цени, КОМПОНЕНТИТЕ имат описания и единични разходи. (Което също може да бъде архивирано в дъщерна таблица.) Тази таблица е мястото, където обикновено съхранявате и своя ROP.
-
СЪСТАВ Това е спецификация, която пресича SKU и КОМПОНЕНТ и казва колко единици от всеки КОМПОНЕНТ влизат в единица от SKU. Имате нужда от едно от тях, за да пресечете и две SKU (за комбинации). Можете да използвате една или две таблици за това. Две маси ще зарадват пуристите, една маса ще бъде целесъобразна от гледна точка на кодера.
-
РАЗПРОДАЖБА Това е таблица с транзакции, която предоставя заглавка за записване на продажба на един или повече SKU. Тази таблица ще съдържа неща като дата на транзакцията, идентификатор на касиера и други елементи в заглавката.
-
SALE_ITEM Това е таблицата с подробности за транзакциите, която включва кой SKU е продаден (и колко) и за колко. Колко е денормализиране на цената на SKU към момента на продажба, но може да включва и всякакви специални промени в цената. Цената, която действително се начислява за SKU, е добре да се денормализира, защото някой може да редактира каталожната цена в SKU и тогава ще загубите представа колко действително е била таксувана за артикула по това време.
-
INVENTORY_HDR Това е транзакционна таблица, която е подобна на SALE концептуално, но е заглавието на транзакция за инвентаризация, като например получаване на нов инвентар, използване на инвентара (както при продажбата му) и за корекции на инвентара. Отново, това би било дата/описание, но може да включва директна връзка към SALE_ITEM за движения на инвентара, които са продажби, ако желаете. Не е нужно да го правите по този начин, но някои хора обичат да установяват връзката между приходите и разходите на база транзакция по транзакция.
-
INVENTORY_DTL Това е детайлът за транзакция за инвентаризация. Това показва кой КОМПОНЕНТ влиза или излиза, количеството, което е влязло или излязло, и транзакцията INVENTORY_HDR, за която се отнася това движение. Това също ще бъде мястото, където съхранявате действителните разходи, платени за елемента на компонента.
-
МЕСТОПОЛОЖЕНИЕ Можете (ако желаете) също да проследявате физическото местоположение на инвентара, който получавате и използвате/продавате. В ресторант това може да не е важно, но ако имате верига или ако вашият ресторант има склад за компоненти, тогава може да ви е грижа.
Помислете за следния ERD: 
За да извършите отчитането на приходите си, трябва да добавите парите, записани в таблицата SALE_ITEM.
Изчисляват се нивата на запасите въз основа на сумиране на INVENTORY_DTL входове и изходи за всеки КОМПОНЕНТ. (Не съхранявайте текущите нива на запасите в таблица – това е обречено да причини проблеми при съгласуването.)
За да извършите отчитането на разходите си, трябва да добавите парите, записани в таблицата INVENTORY_DTL. Имайте предвид, че обикновено няма да знаете точно кое салфетка или кифличка, които сте продали, така че няма да е възможно да се свържат рецепти за конкретни компоненти с конкретни продажби на SKU. Вместо това трябва да имате конвенция за определяне кои компоненти са били използвани за даден SKU. Може да имате счетоводни правила, които определят каква конвенция трябва да използвате. Повечето хора използват FIFO. Някои индустрии използват LIFO и дори съм виждал отчитане на среднопретеглените разходи.
