Naučit se HTML & CSS, JS a Bootstrap Sleva na školení
Získej 500 Kč na naše školení. Více zde
Probíhá výprodej HTML & CSS, JavaScript a Bootstrap
Avatar
Jaroslav Smrž
Redaktor
Avatar
Jaroslav Smrž:25. února 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. února 10:36
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Tomáš Novotný:25. února 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í
+1 bodů
Řešení problému
Nahoru Odpovědět  +1 25. února 10:50
∞ ... the exact amount of possibilities how to deal with the situation ... so by calm, your solution is one of many
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:25. února 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. února 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. února 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. února 11:32
 
Nahoru Odpovědět 25. února 11:31
Avatar
Jaroslav Smrž
Redaktor
Avatar
Jaroslav Smrž:25. února 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. února 11:32
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Jaroslav Smrž
Redaktor
Avatar
Jaroslav Smrž:25. února 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. února 11:37
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Jaroslav Smrž
Redaktor
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:25. února 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. února 11:43
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:25. února 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. února 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ž
Redaktor
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:26. února 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. února 8:35
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Odpovídá na Jaroslav Smrž
Tomáš Novotný:26. února 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. února 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ž
Redaktor
Avatar
Jaroslav Smrž:26. února 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. února 10:41
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:26. února 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. února 10:44
Avatar
Odpovídá na Peter Mlich
Tomáš Novotný:26. února 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. února 11:21
Nahoru Odpovědět 26. února 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ž
Redaktor
Avatar
Jaroslav Smrž:26. února 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. února 11:38
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Jaroslav Smrž
Redaktor
Avatar
Odpovídá na Tomáš Novotný
Jaroslav Smrž:26. února 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. února 11:43
I have no idea what it is doing but I´m scared to delete it... xD
Avatar
Peter Mlich
Člen
Avatar
Peter Mlich:26. února 14:42

Ok, jen mne to tak zaujalo.

 
Nahoru Odpovědět 26. února 14:42
Avatar
macop
Člen
Avatar
Odpovídá na Jaroslav Smrž
macop:4. dubna 15:33

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

 
Nahoru Odpovědět 4. dubna 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.