Řešení, které hledáte, se bude opírat o model účetního stylu a několik kusovníků (BOM). Mezi vaše hlavní typy entit patří:
-
SKU Toto je seznam věcí, které prodáváte. Jeho vlastnosti budou zahrnovat věci, jako je popis produktu a aktuální maloobchodní cena. Můžete získat fantazii a rozdělit cenu do podřízené tabulky, která uvádí ceny v průběhu času. Předpokládejme, že tuto vrásku prozatím vynecháte. Některé SKU mohou být „komba“ typu, o kterém mluvíte.
-
KOMPONENT Toto je seznam věcí, které tvoří SKU, jako jsou ubrousky, kelímky, buchty, placičky, koksový sirup atd. – abych použil váš příklad. Stejně jako má SKU popisy a ceny, KOMPONENTY mají popisy a jednotkové náklady. (Kterou lze také historizovat v podřízené tabulce.) Do této tabulky byste také obvykle ukládali svůj ROP.
-
KOMPOZICE Toto je kusovník, který protíná SKU a KOMPONENTU a říká, kolik jednotek každé KOMPONENTY jde do jednotky SKU. Jeden z nich potřebujete také k protnutí dvou SKU (pro komba). K tomu můžete použít jeden stůl nebo dva stoly. Dva stoly udrží puristy šťastnými, jeden stůl bude výhodný z pohledu kodéra.
-
PRODEJ Toto je tabulka transakcí, která poskytuje záhlaví pro záznam prodeje jedné nebo více SKU. Tato tabulka by obsahovala věci jako datum transakce, ID pokladníka a další položky záhlaví.
-
SALE_ITEM Toto je tabulka podrobností transakce, která by zahrnovala, která SKU byla prodána (a kolik) a za kolik. Kolik je denormalizace ceny SKU v době prodeje, ale může také zahrnovat jakékoli speciální změny ceny. Skutečně účtovanou cenu za SKU je dobré denormalizovat, protože někdo by mohl upravit katalogovou cenu v SKU a pak byste ztratili přehled o tom, kolik bylo za položku v té době skutečně účtováno.
-
INVENTORY_HDR Toto je transakční tabulka, která je koncepčně podobná SALE, ale je to hlavička pro transakci zásob, jako je příjem nových zásob, spotřebování zásob (jako při jejich prodeji) a pro úpravy zásob. Opět by se jednalo o datum/popis, ale může obsahovat přímý odkaz na SALE_ITEM pro pohyby zásob, které jsou prodejem, chcete-li. Nemusíte to tak dělat, ale někteří lidé rádi vytvářejí spojení mezi výnosy a náklady na bázi transakce po transakci.
-
INVENTORY_DTL Toto je detail transakce zásob. To označuje, která KOMPONENTA vstupuje nebo vystupuje, množství, které vstoupilo nebo odešlo, a transakci INVENTORY_HDR, které se tento pohyb týkal. Zde také uchováte skutečné náklady zaplacené za položku součásti.
-
LOCATION Můžete (pokud si přejete) také sledovat fyzické umístění inventáře, který přijímáte a používáte/prodáváte. V restauraci to nemusí být důležité, ale pokud máte řetězec nebo pokud má vaše restaurace sklad komponentů mimo místo, může vám to být jedno.
Zvažte následující ERD: 
Chcete-li provést zaúčtování příjmů, sčítali byste peníze zaznamenané v tabulce SALE_ITEM.
Úrovně zásob se počítají na základě sečtení INVENTORY_DTL vstupů a výstupů pro každou KOMPONENTU. (Neukládejte aktuální stavy zásob do tabulky – to je odsouzeno k problémům se sladěním.)
Chcete-li provést své nákladové účetnictví, sečetli byste peníze zaznamenané v tabulce INVENTORY_DTL. Všimněte si, že obvykle nebudete přesně vědět, který ubrousek nebo drdol, který jste prodali, takže nebude možné propojit účtenky konkrétních součástí s konkrétním prodejem SKU. Místo toho musíte mít konvenci pro určování, které komponenty byly použity pro danou SKU. Můžete mít účetní pravidla, která určují, jaké konvence jste povinni používat. Většina lidí používá FIFO. Některá odvětví používají LIFO a dokonce jsem viděl vážené průměrné nákladové účetnictví.