dynamické namísto standardní ceny sklenic piva:

1. + méně zapisovaných údajů (střední argument)
2. + méně manuálních výpočtů (střední argument)
3. + cena závisí od sudu, takže v případě menší akce kde se narazí jen malá bečka (15l) něčeho co teoreticky normálně prodáváme z 30l/50l je vše funkční a nemusí se přepisovat statická položka v systému (malý argument)
4. - pokud se nám rozchází cena piva za běžné prodávané 50l/30l sud, budeme vypadat jako šašci. Jak ošetřit, že vždycky jasně uvidíš že by takový problém nastal (nastavuješ cenu jiného sudu… A kdo vlastně nastavuje cenu sudu? Barman? Admin? – jeho UI by mu mělo poskytnout nějaké srovnání)
5. – implementačně to zesložiťuje cenový reporting

Kotyho roadmapa backend projektu jak jí vidí potřebnou jako vedoucí:

1. API modely objektů pro barman API
2. Mockup barman API
3. Implementace Autentizace, eduID-reg, paper-reg |Celý, popsaný, OpenAPI
4. Implementace barman API
5. Implementace admin API |Implementace admin FE

Rozdělení práce v BE:

- Pracujeme podle roadmapy
- Na 90% udělá vše Jakub (krom toho, kde bude chtít pomoct)
- Michal může klidně udělat mockup barman API, jde v postgREST+nginx udělat opravdu rapidně
- Pokud by to Michal chtěl ve fázi implementace barman/admin API převzít, pracoval bych s existující OpenAPI specs, kterou bych případně v admin části upravil.

O položce hlásíme sklad-info jako číslo + suffix

K jednotkám --- stále uvažuju o tom vyhnout se v DB destiným číslům (nebo decimals)…. Floaty budou generovat pačísla, které budem muset stejně manualně oříznout…. Decimaly byly by nejjednodušeí řešení… ale jsou dost slow (SW implementace BCD), takže to bude zhoršovat výkon agregačních dotazů. …

To už můžeme do backendu dát konverzi / 1000 mL=>l na views a \*1000 na L=>mL na vstupech, pokud budeme chtít nějak lidsky oříznout tu desetinou část (a ta se bude chovat všelijak, protože to je float, takže při sčítání se ta aproximace může všelijak měnit)

Dodatek:

----------------------------------------

Proč Michal říká že jednotkový produkt dává smysl:

Jako běžné produkty

- --v případě kofoly a okurek – opravdu vyjadřuje složku prodejního produktu
- --v případě naskladňování přímo v základních jednotkách a ne v baleních by takový produkt opravdu existoval

V případě N:N vztahů jako pivo jasně identifikuje to, co hledám, při počítání statistik prodejů podle typu piva.

Entita existuje skutečně samostatně, a není reprezentována jen povýšením jiné entity do role „group mastera"

Je zde samozřejmě (obecně ) velmi důležité

- --jak vyváženě je zvoleno rozložení tabulek v katalogu,
- --jak se zpracovávají a chápají objednávky derivovaných a základních produktů
  - z pohledu skladu
  - z pohledu prodejů
  - e.g. pokud objednám odvozený produkt „kofola 0.2 + džus 0.2"
    - mám jen tento záznam,
    - nebo se rozloží na 3 – odvozený produkt, kofola 0.2l, džus 0.2l
    - nebo se rozloží na 2, a ten původní se vůbec nezaeviduje
    - to v jednotlivých případech ovlivní i logiku výpočtů stavu skladu, prodejů atd.
    - je třeba myslet jak na redundanci, tak ale i na zbytečnou složitost všech procesů (objednávání, filtrování statistik, stornování, …)
    - také to může potenciálně vést na dvě tabulky: tabulku „objednávky" a tabulku „sklad", kde v objednávkách by bylo vždy 1:1 co bylo objednáno, a do skladu by se odvozené produkty propsali jen svými složkami