IT rekvalifikace s garancí práce. Seniorní programátoři vydělávají až 160 000 Kč/měsíc a rekvalifikace je prvním krokem. Zjisti, jak na to!
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.

Diskuze: Návrh struktury MySQL databáze

Aktivity
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Jaroslav Smrž:25.2.2019 10:36

Ahoj, rád bych vás požádal o názory ohledně struktury databáze k projektu skladového hospodářství pro gastronomii. Systém se skládá z několika částí, přiblížím vám tu nejpodstatnější a nejpekelnější - inventury. U nich je potřeba ke každé skladové položce zapsat datum, příjem/odpis, zůstatek. Prodej a tržba se počítají automaticky. Jen doplním, že se jedná o OOP webovou aplikaci v PHP s použitím PDO. Položek je cca 120 a není předpoklad, že by se číslo nějak zásadně navýšilo.

Zkusil jsem: V současném návrhu mám tabulky:
items (id, name, category, unit, price, status, balance, key)
inventory (id, key, date, balance_in, income, balance_out, sale, revenue)

Toto řešení je sice funkční, ale přijde mi dost nekomfortní. Inventury se v gastronomii dělají 3x do týdne, takže po roce by DB měla zbytečně vysoký počet řádků. Přemýšlel jsem i o exportu do pdf souboru a v DB uchovávat pouze poslední inventuru, ale to je pro zákazníka nepřijatelná varianta.

Chci docílit: Komfortního ukládání inventur do DB s jednoduchou filtrací podle data. Budu vděčný za každý nápad. Už se s tím trápím 3. den a tudíž se mi na to nedaří už koukat "zvenčí". Všem moc děkuji.

Odpovědět
25.2.2019 10:36
/* Life runs on code */
Avatar
Tomáš Novotný
Člen
Avatar
Tomáš Novotný:25.2.2019 10:50

Ahoj, zrovna budu řešit také jeden sklad... pokud správně chápu, tak máš tabulku položek a pak tabulku inventur osobně tam postrádám tabulku s pohyby příjem, výdej, prodej, odpis atd...
novou inventuru bych poté koncipoval jako součet pohybů a stavu předchozí inventury + případně speciální položky pro rozdíl 'má být' vs. 'je' záleží na koncepci jestli to třeba zákazník chce nějak vidět zvlášť třeba zpětně za rok.. tak, aby se tím lépe pracovalo..

Akceptované řešení
+20 Zkušeností
+2,50 Kč
Řešení problému
Nahoru Odpovědět
25.2.2019 10:50
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Tomáš Novotný
Člen
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:25.2.2019 11:23

Ještě jsem si všiml, že na položce máš cenu... takže inventuru patrně můžeš udělat jen na ks, litry atd... bohužel asi neuděláš inventuru v Kč... lepší by bylo mít cenu na pohybu, jelikož např. nakoupíš saláty od Standy na 50 Kč/ks dnes,, ale v úterý už máš jen 2ks, takže ve středu půjdeš k Jirkovi a přikoupíš za 60 Kč/ks mezi tím nějaké odepíšeš protože prostě nebyly čerstvé... Pak v rámci inventury vznikne otázka, kolik salátu a za jakou cenu máme na skladě? nebude to ani 50 Kč ani 60 Kč ale někde mezi tím..

Nahoru Odpovědět
25.2.2019 11:23
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:25.2.2019 11:31

item (id_zbozi, zbozi_data)
sklad (id_sklad, id_zbozi, pohyb_data - kdo, kdy, jaky druh pohybu, pocet kusu...)
1, 98, 0, 5, ... -- nakup 5 kusu
1, 98, 1, 5, ... -- prodej 5 kusu
1, 98, 2, 5, ... -- spotreba 5 kusu
1, 98, 3, 5, ... -- vyroba 5 kusu

A inventura je vypis za urcite obdobi, ne? To potrebujes tez ukladat do tabulky? Nestaci to vytahnout sql dotazem? Jako, muzes, to je na tobe. Pseudokod dotazu

SELECT SUM(cislo)
(SELECT +SUM(kusu) AS cislo, id_zbozi ... WHERE pohyb_typ IN (nakup, vyroba)
UNION
SELECT -SUM(kusu) AS cislo, id_zbozi ...  WHERE pohyb_typ IN (prodej, spotreba))
GROUP BY id_zbozi
Editováno 25.2.2019 11:32
 
Nahoru Odpovědět
25.2.2019 11:31
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Jaroslav Smrž:25.2.2019 11:32

Ahoj, ano, chápeš to správně. Já právě řešil všechno v tabulce inventury (tam jsem ukládal ty pohyby a ve výpisu filtroval podle data, sčítal a násobil podle klíče položky). Moc děkuji za tvoje řešení. Tohle jsem přesně potřeboval, ale jak jsem už psal, tak po 3 dnech jsem se v tom totálně utopil a už neviděl, co to potřebuje. Ještě jednou díky.

Nahoru Odpovědět
25.2.2019 11:32
/* Life runs on code */
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Jaroslav Smrž:25.2.2019 11:37

Všem moc děkuji za pomoc. Předělám tabulky, vložím testovací data a hodím sem výsledek. Pokud někdo budete pracovat na podobném systému, napište. Je tam několik zákeřností, které jsem již vyřešil a rád pomůžu ostatním.

Nahoru Odpovědět
25.2.2019 11:37
/* Life runs on code */
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:25.2.2019 11:43

Položka cena je v tabulce "polozky" a slouží jako prodejní cena (tržba) nikoliv jako nákupní cena.

Nahoru Odpovědět
25.2.2019 11:43
/* Life runs on code */
Avatar
Tomáš Novotný
Člen
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:25.2.2019 11:49

Ok, ale jak víš, že prodejní cena není nižší než cena položky z inventury? Tj. v procesu naskladnění nedošlo ke správné aktualizaci prodejní ceny? Nebo se cena aktualizuje jen když nová nákupní + marže je vyšší než současná prodejní?

Nahoru Odpovědět
25.2.2019 11:49
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:26.2.2019 8:35

Prodejní cena je fixní, respektive mění se maximálně 1x za rok při zdražení ze strany dodavatelů a slouží pouze k výpočtu tržby u dané položky (aby personál věděl, kolik peněz má odevzdat majiteli). Např. 1 panák rumu stojí 50kč a jeho obsah je 4cl, počáteční stav rumu je 200cl, zůstatek při inventuře 184cl, prodej tedy vychází na 16cl = 4 panáky = tržba je 200kč. Nákupní ceny se řeší v další části aplikace "finance". Zákazník neměl zájem o podrobný report čistého zisku podle položek. Vše se počítá dohromady (tržba - nákup = profit). Výplaty zaměstnanců, nájem prostor atd jsou odděleny typem příjmu/výdeje peněz.

Nahoru Odpovědět
26.2.2019 8:35
/* Life runs on code */
Avatar
Tomáš Novotný
Člen
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:26.2.2019 9:43

Aha, takže tak častou inventarizací se neřeší ani tak změna cen jako spíše to... jak to říci zda se nekrade. :-)

Nahoru Odpovědět
26.2.2019 9:43
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Jaroslav Smrž:26.2.2019 10:41

V podstatě ano, přesněji to funguje následovně. Jsou 2 směny, každá z nich pracuje krátký(st-čt) - dlouhý(po-út, pá-ne) týden proti sobě. Je tedy důležité, aby směna, co začíná svůj první den (např pátek) zkontrolovala fyzicky stav jednotlivých položek na provozovně a porovnala s počátečním zůstatkem (konečným zůstatkem směny předešlé), zda všechno sedí. V den, kdy jsou v práci naposledy ( v našem případě neděle) musejí všechny položky opět fyzicky spočítat, zadat do systému, ten vypočítá prodané kusy a podle toho i celkovou tržbu k odevzdání majiteli. Jejich konečné stavy opět překontroluje druhá směna, které jde další den do práce a tak pořád dokola. V dnešní době se používají (musejí) fiskální pokladny s EET, ovšem co si budeme povídat, každý kouká, jak to co nejvíc obcházet, takže pokud nejsou markovány a evidovány všechny prodané položky v kase, tak není jiná cesta než vše fyzicky počítat a zadávat data do podobného systému. Dříve se to ani jinak nedělalo, jen místo aplikace se používala tužka, papír a občas i šanon :)

Nahoru Odpovědět
26.2.2019 10:41
/* Life runs on code */
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:26.2.2019 10:44

Proc resite prodejni cenu? Jako, treba s mou tabulkou to nedava smysl. Tam je sklad, nakoupeno za cenu, prodano za cenu. Ze je nekde v eshopu u zbozi nejaka cena ho nezajima, to zajima script, ktery vklada radek do tehle tabulky. Nikoliv script pro zobrazeni inventury.

 
Nahoru Odpovědět
26.2.2019 10:44
Avatar
Tomáš Novotný
Člen
Avatar
Odpovídá na Peter Mlich
Tomáš Novotný:26.2.2019 11:21

Však ano, ptal jsem se proto, že nemá cenu jednotlivých příjmů. Osobně mne zajímalo jak tedy řeší prodejní cenu. Odpověď byla, že to neřeší a přeceňují jednou za rok. To že to nemá souvislost s kusovou inventurou je snad všem jasná. Toto spíše souviselo s inventurou v Kč... kterou také neřeší a pro finanční toky postačují celkové součty výdajů a příjmů jak píše Jaroslav. Asi je prodejní cena dosti vysoko o proti nákupu, že je výkyvy příliš nezajímají, nebo by administrativa s tím spojená (náklady) převyšovaly přínos. A konečně poznámka, takže tohle celé se neděje primárně kvůli finančním záležitostem a stavu skladu z pohledu účetního, ale spíše proto, aby byl klid mezi směnami.

Editováno 26.2.2019 11:21
Nahoru Odpovědět
26.2.2019 11:21
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Jaroslav Smrž:26.2.2019 11:38

Přesně, jak píše Tomáš. Celé je to z důvodu dvojí kontroly nad zbožím = financemi. Nikdo si nepřejme chybějící zboží, jinak by ho musel zaplatit sám. Prodejní cena je podstatou celého systému - převést zboží na peníze.

Nahoru Odpovědět
26.2.2019 11:38
/* Life runs on code */
Avatar
Jaroslav Smrž
Tvůrce
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:26.2.2019 11:43

Ano, prodejní cena je vysoko. Až na pár položek jako např pivo odpovídá vzorci: cena nákupu + 100% + DPH = prodejní cena.

Nahoru Odpovědět
26.2.2019 11:43
/* Life runs on code */
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:26.2.2019 14:42

Ok, jen mne to tak zaujalo.

 
Nahoru Odpovědět
26.2.2019 14:42
Avatar
macop
Člen
Avatar
Odpovídá na Jaroslav Smrž
macop:4.4.2019 15:33

Ahoj, nechces sem pastnut celu DB schemu? Celkom ma zaujima ako si to vyriesil. Dik.

 
Nahoru Odpovědět
4.4.2019 15:33
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 17 zpráv z 17.