Rozwiązanie, którego szukasz, będzie opierać się na modelu stylu księgowego i kilku zestawieniach materiałów (BOM). Twoje główne typy jednostek obejmują:
-
SKU To jest lista rzeczy, które sprzedajesz. Jego właściwości będą obejmować takie rzeczy jak opis produktu i aktualną cenę detaliczną. Możesz wymyślić i podzielić ceny na tabelę podrzędną, która podaje ceny w czasie. Załóżmy, że na razie zostawisz tę zmarszczkę. Niektóre jednostki SKU mogą być „kombinacjami”, o których mówisz.
-
SKŁADNIK Oto lista rzeczy, które składają się na SKU, takich jak serwetki, kubki, bułeczki, paszteciki, syrop z coli itp. – na przykładzie. Tak jak SKU ma opisy i ceny, SKŁADNIKI mają opisy i koszty jednostkowe. (Która może być również przechowywana w postaci historii w tabeli podrzędnej). Ta tabela jest miejscem, w którym zwykle przechowujesz również swój ROP.
-
SKŁAD Jest to BOM, który przecina SKU i SKŁADNIK i mówi, ile jednostek każdego SKŁADNIKA wchodzi w jednostkę SKU. Potrzebujesz jednego z nich, aby przeciąć również dwie jednostki SKU (dla kombinacji). Możesz użyć do tego jednego lub dwóch stołów. Dwa stoliki uszczęśliwią purystów, jeden stolik będzie korzystny z punktu widzenia programisty.
-
WYPRZEDAŻ Jest to tabela transakcji zawierająca nagłówek do rejestrowania sprzedaży jednej lub większej liczby jednostek SKU. Ta tabela zawierałaby takie informacje, jak data transakcji, identyfikator kasjera i inne elementy nagłówka.
-
SALE_ITEM Jest to tabela ze szczegółami transakcji, która zawiera informacje o tym, który kod SKU został sprzedany (i ile) i za ile. Wartość denormalizacji ceny SKU w momencie sprzedaży, ale może również obejmować wszelkie specjalne nadpisania ceny. Rzeczywistą cenę naliczoną za jednostkę SKU warto zdenormalizować, ponieważ ktoś może edytować cenę katalogową w SKU, a wtedy stracisz kontrolę nad tym, ile faktycznie naliczono za przedmiot w danym momencie.
-
INVENTORY_HDR Jest to tabela transakcyjna, która koncepcyjnie jest podobna do SPRZEDAŻ, ale jest nagłówkiem transakcji magazynowej, takiej jak otrzymanie nowych zapasów, wykorzystanie zapasów (np. sprzedaż) i korekty zapasów. Ponownie, będzie to data/opis, ale może zawierać bezpośredni link do SALE_ITEM dla ruchów magazynowych, które są sprzedażą, jeśli chcesz. Nie musisz tego robić w ten sposób, ale niektórzy ludzie lubią ustalać związek między przychodami a kosztami dla każdej transakcji.
-
INVENTORY_DTL To jest szczegół transakcji magazynowej. Wskazuje to, który SKŁADNIK wchodzi lub wychodzi, ilość, która została przyjęta lub wyprowadzona, oraz transakcję INVENTORY_HDR, której dotyczył ten ruch. Będzie to również miejsce, w którym zachowasz rzeczywisty koszt zapłacony za element składowy.
-
LOKALIZACJA Możesz (jeśli chcesz) również śledzić fizyczną lokalizację inwentarza, który otrzymujesz i używasz / sprzedajesz. W restauracji może to nie być ważne, ale jeśli masz sieć lub jeśli twoja restauracja ma magazyn składników składników poza siedzibą, może cię to obchodzić.
Rozważ następujący ERD: 
Aby przeprowadzić księgowanie przychodów, musisz dodać pieniądze zapisane w tabeli SALE_ITEM.
Poziomy zapasów są obliczane na podstawie sumowania wejść i wyjść INVENTORY_DTL dla każdego KOMPONENTU. (Nie przechowuj aktualnych stanów magazynowych w tabeli — jest to skazane na problemy z uzgadnianiem.)
Aby wykonać rachunek kosztów, sumujesz pieniądze zapisane w tabeli INVENTORY_DTL. Pamiętaj, że zwykle nie wiesz dokładnie, który sprzedanej serwetki lub bułki, więc nie będzie możliwe powiązanie kwitów określonych komponentów z określonymi sprzedażami SKU. Zamiast tego musisz mieć konwencję określającą, które składniki zostały użyte dla danej jednostki SKU. Możesz mieć reguły księgowe, które określają, jakiej konwencji musisz użyć. Większość ludzi używa FIFO. Niektóre branże używają LIFO i widziałem nawet rachunkowość kosztów średnich ważonych.
