Struktura databáze pro sklad

Kit

Re:Struktura databáze pro sklad
« Odpověď #45 kdy: 20. 11. 2018, 11:50:21 »
Nemusí to být tak náročné, jak to vypadá. Kdysi jsem dělal skladové hospodářství pro jednu strojírnu včetně evidence polotovarů, zakázek a převodu do účetnictví. Byla v tom i kompletní evidence dílů a operací. Vedoucímu stačilo jen definovat zakázku a vylezlo mu z toho i nacenění.


agent

Re:Struktura databáze pro sklad
« Odpověď #46 kdy: 20. 11. 2018, 12:16:26 »
"Asi se většinou shodneme v doporučení zakladateli diskuze, že programovat sám takový systém je v lepším případě vstupenka do blázince. Vyberte nebo požádejte někoho, komu věříte a má zkušenosti, aby vám pomohl s výběrem vhodného systému."
Já měl pocit že první příspěvek tazatele začínal "Ze studijních důvodů bych chtěl nahradit Excelovskou tabulku PHP a databází..."
Takže rada "kup si něco hotové, nebo si najmi firmu" ten problém, že se to autor chce hlavně naučit, moc neřeší.

linuxovykral

Re:Struktura databáze pro sklad
« Odpověď #47 kdy: 20. 11. 2018, 12:46:54 »
Tak trošku z jiného konce. Jak to dělají ERP systémy:

1. Seznam skladů (BranchMaster). Někde tomu říkají warehouse, jinde branch plant. Pokud je sklad jediný, pak to není třeba rozlišovat. Ale i tak bych tu tabulku, byť s jediným ID, doporučil. Protože pokud ten produkt bude úspěšný, tak dříve nebo později někdo přijde s požadavkem typu "a mohli bychom do toho systému dát i pobočku co je na Petrské?" Pokud systém s ID skladu pracuje, pak je to triviální jak z hlediska rozdělení dat (podle ID skladu vidím, o který jde), tak případně z hlediska přístupových práv (aby nikdo nelezl do dat z jiné pobočky).
Atributy: ID skladu a název, plus klidně mraky věcí jako ID společnosti, adresa, nastavení pro AWS apod.)

2. Seznam skladových položek (ItemBranch).
Atributy: ID skladu, ID položky, název položky, měrná jednotka položky (ks/m/kg/..), příznak zda sledujeme číslo dávky a typ položky (vyráběná/komponenta/neskladová/fantom - to má vazbu na účetnictví, pokud neúčtujete, tak není třeba typ rozlišovat), plus zase mraky dalších věcí, co by nás mohly zajímat - hmotnost, rozměry, trvanlivost (pro výpočet datumu spotřeby), nastavení pro inventuru, primární dodavatel, nákupčí atd.

Tohle je základ pro evidenci položek a jejich komponent. Někdo z diskutujících měl pro výrobky a komponenty různé tabulky, jenže to se nedělá. Není k tomu důvod a ve chvíli, kdy zjistíte, že máte i polotovary nebo funkční celky, které jsou zároveň výrobkem i komponentou, si budete jen nadávat. Tabulku tedy jedinou. A pokud chcete výrobky a komponenty odlišit, tak typem položky. Váš účetní vám ty typy rád nadiktuje, zákon o účetnictví na to má celkem jasný názor.

Přidáme si pár tabulek k tomu, ať můžeme evidovat stav skladu.

3. Seznam skladových lokací (LocationMaster). Tedy míst, která chceme v rámci systému rozlišovat. Klidně můžeme jít na úroveň paletových míst, nebo se držet na úrovni regálů apod.)
Atributy: ID skladu, ID skladové lokace a popisek, případně mraky dalších údajů jako rozměry, kde je (hala, řada, patro apod.)

4. Historie skladových transakcí (InventoryTransaction). Tady se eviduje vše, co mění stav skladu. Má to velmi úzkou vazbu na účetnictví a je to provázané s nákupními objednávkami, výrobními zakázkami a sales ordery (český název neznám, prostě expedice). Některé transakce jsou dvouřádkové, typicky přesun mezi lokacemi. Přesuny mezi různými sklady obecně nejsou povolené. To je speciální typ transakce, se kterým není legrace - protože v každém skladu může mít položka jinou cenu atd.
Atributy: ID skladu, ID transakce, ID řádku transakce, typ transakce, ID položky, ID skladové lokace, číslo dávky (viz níže) a množství. Plus reference na nákupní/výrobní/expediční zakázky nebo inventuru.
Jaké mohou být typy transakcí: OP = příjem, OV = vratka dodavateli, IT = přesun (má dva řádky, každý s jinou lokací, jeden s + a druhý s - v množství), IM = výdej materiálu do výroby, IC = příjem materiálu z výroby, SO = expedice materiálu zákazníkovi, RV = vratka od zákazníka, IA = ruční editace množství (adjustment), PI = změna množství podle výsledku inventury, IB = změna hodnoty bez změny množství. Obvykle v několika variantách podle toho, jak se má transakce účtovat (expedice zadarmo, expedice s fakturou atd.)

5. Stav skladu (InventoryLocation). Aktuální stav skladu. ERP systémy mají takovou vlastnost, která docela mate hlavu - neplní záznamy dopředu, řádek se objeví až když se položka na dané lokaci objeví. Ale ani nemažou zpětně, takže pokud položka z lokace zmizí, tak řádek zůstane s množstvím 0. Mazání starých záznamů je pak poněkud složitější problém.
Atributy: ID skladu, ID skladové lokace, ID položky, číslo dávky (LotNumber/BatchNumber), množství (jen číslo, měrná jednotka je uvedena u položky). Plus mraky dalších věcí typu datum naskladnění, datum exspirace, skutečná hmotnost apod. Prostě co je potřeba a co lze (kupříkladu ta hmotnost nebude 95% zákazníků zajímat a ani nebudou mít vysokozdvihy s váhou).

Poznámka k číslu dávky: na položce je nastaveno, zda se sleduje. Pokud ne, tak vkládáme nějaký jinak neplatný default (NULL nám databáze nedovolí, je to součást primárního klíče). Položka pak na lokaci může mít jen jeden záznam. U některých položek ale chcete sledování čísla dávky zapnout. Buď zvolíte že ručně, nebo že se má generovat. Používají se generátory třebas podle čísla zakázky nebo datumu. Pak se vám budou generovat čísla dávky typu 20181119001234. Ty se generují transakcemi, které vytváří záznam ve skladě. Například příjem nákupní objedávky nebo naskladnění z výroby. Protože je číslo dávky součástí primárního klíče, tak můžete mít skladem na jedné lokaci více různých dávek dané položky. Používá se to třebas tak, že se ten údaj použije jako číslo palety. Tiskne se to na skladové štítky, musí se to zadávat při vyskladnění nebo přeskladnění atd. Zda to chce zákazník použít nebo ne záleží na tom, zda chce vědět, že má skladem 2000 gumiček, nebo potřebuje vědět, že má skladem 3 palety po 600 a jednu paletu s 200 kusy. A u každé být schopen se podívat, kdy ta konkrétní paleta přišla a od koho. Nastavení zda sledovat/nesledovat se nastavuje u položky.

Tak, tohle stačí na evidenci skladu. V dotazu je cosi o komponentách, takže předpokládám, že chceme zabrousit i do oblasti výroby.

6. Kusovník (BOM). Zde se uvádí komponenty, ze kterých se skládají polotovary, funkční celky a nakonec samotné výrobky. Kusovníků mohu evidovat více, například pro výrobu, pro demontáž, alternativní kusovník pro výrobu, pro opravu atd. Pokud si to nechci komplikovat, tak budu vyplnňovat jen jeden typ, například M (Manufacturing). Kusovníky jsou jednoúrovňové - pokud do výrobku vstupuje nějaký polotovar, pak se uvede polotovar. A pro ten polotovar pak bude založen jeho vlastní BOM. Získat kompletní seznam komponent pro daný výrobek pak znamená poskládat strom z jednotlivých BOMů.
Atributy: Typ kusovníku, ID skladu, ID nadřazené položky, číslo řádky kusovníku, ID položky komponenty, typ řádku komponenty, množství ke kompletaci

Typ řádku komponenty a množství spolu úzce souvisí. Běžně si lidé představí, že vezmu kus trubky a z ní něco uříznu. Jenže už od pohledu nebude sedět hmotnost. Ono totiž při řezání vznikne i odpad nebo vedlejší produkt. U řady výrob to nikoho nezajímá, ale pokud jsou to nebezpečné (plasty) nebo drahé (kovy) materiály, tak to evidovat chcete. Do BOMu se to píše jako komponenta se záporným množství (nespotřebovává se, ale naopak vzniká) a typem řádku komponenty byproduct/coproduct apod. Do výroby se pak nevydává, ale naopak se naskladňuje. Plus je možno přidat neskladové položky nebo nástroje - čistě pro evidenci toho, že jsou potřeba. Na ty pak skladové transakce nevznikají.

7. Pracovní postup (Routing). Ten jde ruku v ruce s kusovníkem. Zatímco kusovník říká "hřídel XY, matice ABC, závlačka KLF", tak routing říká, jaké operace se v jakém pořadí dělají. Jak dlouho která trvá než začne, jak dlouho trvá jeden kus, jak dlouho konec. Kolik vlastně lidí, v jaké mzdové třídě, jaká je nutná kvalifikace a na jakém typu pracoviště se to dělá. Rozepisovat ho nebudu, protože to většina zákazníků nepoužívá. Má to vliv prakticky jen na účetnictví a plánování výrobních zdrojů. Některé ERP evidují nástroje a pomůcky zde, místo v BOMu. Plánovací moduly pak ví, kdy a na kterou operaci ten nástroj bude potřeba. Ve chvíli, kdy některé operace trvají hodiny (lakování apod.) to může být důležité.

8. Hlavička výrobní zakázky (WorkOrderHeader). Říká co a v jakém množství chceme vyrobit.
Atributy: Typ zakázky, ID zakázky, ID skladu, ID skladové položky, množství, stav, dokončené množství

9. Komponenta výrobní zakáky (WorkOrderPartsList). Seznam komponent, naplněné dle BOMu
Atributy: Typ zakázky, ID zakázky, číslo řádky, ID skladu, ID skladové položky, ID skladové lokace, číslo dávky, množství, vydané/přijaté množství
Poznámka: komponenta se eviduje až na úroveň skladové lokace. Do jistého stavu zakázky můžete mít lokaci nevyplněnou, ale nejpozději ve chvíli výdeje materiálu se do komponent zapíše údaj o lokaci. Občas je kvůli tomu potřeba řádek rozdělit.
Poznámka 2: do hlavičky výrobní zakázky se údaj o lokaci buď nepíše vůbec, nebo se tam zapisuje údaj z poslední transakce, kterou byl výrobek naskladněn. Běžně se totiž děje, že se výroba naskladňuje postupně, třebas po paletách. A narozdíl od řádku komponent není hlavičku možné rozdělit na více řádků.
Poznámka 3: a ještě je tam WorkOrderRouting (pracovní postup), na který se pak vykazuje vykonaná práce.

Tak, a to jsme pořád vzdálení skutečnosti. Třebas ta skladová položka není tabulka jedna, ale běžně tabulek několik. Já bych si jimi práci zatím nekomplikoval, ale pokud by v budoucnu byla potřeba, tak tady je inspirace:

1. ItemMaster = ID položky, název - slouží jako jednotný číselník napříč všemi sklady
2. ItemBranch = ID skladu, ID položky, atributy pro daný sklad - zde je definice pro daný sklad. Běžně se děje, že v každém skladě má položka některá data jiná (například bude jiný primární dodavatel a nákupčí, jiný typ inventury apod.)
3. ItemUOM = ID položky, ID měrné jednotky, ID druhé měrné jednotky, množství - definice převodů mezi jednotkami (1 ks=2 kg, 1 paleta = 15 krabic, 1 krabice = 25 kusů, ...)
4. ItemBranchUOM = stejně jako ItemUOM, ale na úrovni ItemBranch (tedy s ID skladu). Některé ERP systémy to mají jen na úroveň ItemMaster, jiné jen na ItemBranch, no a některé mají k neskonalé radosti PDM tabulky obě (JD Edwards)
5. ItemCost = ID skladu, ID položky, typ ceny, datum od, datum do, měna, částka - evidence ceny položky v čase. Typ ceny = skladová/nákupní/průměrná atd.
6. ItemExtensionCodes = ID skladu, ID položky, typ hodnoty, hodnota - ve skutečnosti totiž můžeme potřebovat mraky dalších údajů o položkách. Místo přidávání sloupečků do ItemBranch se píší řádky nebo sloupce do ItemExtensionCodes. Takže EAN kódy, id produktu, id zákazníka atd. se obvykle najdou tady. Zda řádek nebo sloupec je věcí ERP - některé to řeší pomocí řádků, jiné mají třebas 90 genericky pojmenovaných sloupců (text1 až text20, date1 až date20 atd.)
7. ItemCrossReferences = ID skladu, ID položky, typ reference, ID partnera, hodnota - překladová tabulka čísel položek. Já si eviduji položku třebas pod číslem 60020. Jenže dodavatel jí říká L0604T. Nebo mám výrobek 3731053, kterému ale jeden zákazník říká SAS146SFF10K a na expediční papíry chce ještě psát "Model ER654124-3". Tohle všechno se zadává sem. Typ reference bývá číslo položky dodavatele, číslo položky zákazníka, model dodavatele, model zákazníka, id produktu zákazníka, atd. Pokud někoho napadlo, čím se liší ItemExtensionCodes a ItemCrossReferences, pak jen v tom ID partnera. Zatímco do ItemCrossReference mohu připisovat další a další dodavatele a zákazníky, tak v případě ItemExtensionCodes to znamená nové a nové sloupce/řádky, které nejsou svázané s ID zákazníka, ale já si to musím pamatovat (např. že text5 je Model# pro zákazníka 182614)

A úplně jiný level to dostane ve chvíli, kdy budete chtít dělat účetnictví. Najednou musíte sledovat i ceny, jejich změny v čase, hodnotu skladu atd. Přibudou vám transakce přecenění (nemění množsví skladem, jen jeho cenu) a začnou platit dodatečná pravidla pro inventury apod. Pro příjem nákupu budete muset účtovat rozdíly mezi nákupní cenou a skladovou cenou. U výroby budete účtovat variance, kdy spotřeba neodpovídá cenou výstupu (například kvůli zmetku musíte dovydat více materiálu). Do toho se každopádně nepouštějte, tam jde o kriminál. Nejdál kam bych zašel je poskytování výpisu stavu skladu a skladových transakcí pro účetního, ten ať si zbytek ošéfuje sám.
Podle dékly příspěvku by to chtělo si najít holku ... .

Kit

Re:Struktura databáze pro sklad
« Odpověď #48 kdy: 20. 11. 2018, 13:33:56 »
Prvotní pokus s vytvořením MySQL tabulky ala excelovská tabulka se ukázal jako blbost. Nastudoval jsem nějakou teorii a objevil normalizaci databáze, ale pořád moc netuším jak na to. Rozebral jsem jednu velkou tabulku na vic malých provázaných pomocí cizích klíčů. Zasekl jsem se na tom, že výrobky jsou z různých součástí o různém počtu. Mít v tabulce výrobků položku s polem součást/počet mi nepřijde správné.

Jdeš na to správně, jen součást/počet patří do další tabulky.

materiál(id, název, vlastnosti) AS polotovar
součást(polotovar_id, materiál_id, počet)

vazba bude M:N, protože polotovar může být z více druhů dílů a jeden díl může být vstupem pro více druhů polotovarů.

Podobně můžeš na polotovar navázat i pracovní postup a jeho nacenění.

Štefan

Re:Struktura databáze pro sklad
« Odpověď #49 kdy: 20. 11. 2018, 14:02:28 »
Zdravím,
ze studijních důvodů bych chtěl v php nahradit excelovskou tabulku kterou požíváme ve výrobe pro evidenci materiálu. Přijde mi rozumnější se učit na něčem reálném než na virtuální knihovně z tutoriálů.
Ahoj,
začal bych tady: http://databaseanswers.org/data_models/index.htm
Dále bych si celou věc zjednodušil na:
  • kusovník materiálu
  • kusovník výrobků
  • montážní list výrobku
  • seznam skladů
  • skladová karta výrobku
  • příjemka/výdejka ze skladu
Tolik k datovému modelu. Procesně to ošetříš v php aplikaci. Budeš potřebovat základní funkce typu přidat/ubrat položku, vypsat seznam položek.
Ze začátku můžeš ignorovat oprávněného uživatele aplikace.. ale zřejmě to budeš muset časem take řešit..


Re:Struktura databáze pro sklad
« Odpověď #50 kdy: 20. 11. 2018, 22:54:07 »
Tyjo, když tady čtu ty bezvadné popisy co je třeba modelovat/podchytit a proč, začíná mi dávat smysl spousta zákoutí, která vidím v modulu skladů v i6. Fakt toho i6 neumí málo. Bohužel jedna konkrétní a v dané aplikaci zřejmě důležitá věc, která v i6 prakticky chybí (pokud moje chabé znalosti nelžou) jsou "sestavy s BOMem" = agregátní skladová položka skládající se s více detailních skladových položek. Alespoň v té i6 co provozujeme pro "šoupání krabic" to zjevně není. Přicházíme do styku s některými dodavateli, kteří jedou na SAPu a jejich systém tuhle věc patrně umí.

Na i6 mi přijde kouzelné, že je uživatelské rozhraní hodně blízko surovému datovému modelu, prostě bohaté formuláře nad tabulkami. Lokální klient zrovna neoplývá blbovzdornými wizardy "next - next - finish". Naopak: máte veliký formulář a často o integritních omezeních "workflow" nevíte, dokud nějaké neporušíte :-) = vyskočí chybová hláška. Jasně, práva konkrétního uživatele se dají sešněrovat, aby nemohl napáchat škodu. Míru svobody lze nakonfigurovat per uživatel. Což se hodí, když je třeba řešit nějaký přehmat: musí pomoct někdo, kdo má vyšší práva / větší svobodu. Obvykle je na výběr, zda řetízek několika kroků vrátit zpátky přibližně do situace "vůbec se to nestalo" (smazat nově vytvořené záznamy od určitého bodu) vs. provést komplementární krok opačným směrem (třeba klasické storno) s tím, že v systému zůstane "hrobeček", podrobný záznam, co se dělo. Je na uživatelské organizaci, aby si stanovila interní pravidla podle svých potřeb. V různých modulech/tabulkách/atributech je správný postup různý. Samozřejmě ta relativní svoboda předpokládá, že s ní dotyčný musí umět uvážlivě pracovat.

Jinak rozlišení "produkt necertifikovaný vs. přesně tatáž věc s certifikátem": podle mého není nic jednoduššího. Prostě budou mít každý svůj objednací kód, navzájem odlišný třeba jenom v jednom písmenku. Dvě různé "skladové karty". Tzn. je to spíš věc tvorby objednacích kódů a taky věc pečlivého značení zboží na skladě. Totiž tvorba objednacích kódů je dost věda a je to problém spíš "lidský" z oblasti řízení, systematizace a pořádku, než z oblasti IT implementace.

A že šéf skladu by měl být pedant, to je další věc. Pokud jsou skladníci lemplové, tak to žádný IT systém do pořádku nedá... Pořádek je do značné míry věc sebekázně, pečlivé práce. Softwarový systém tomu jenom dodá určité pohodlí. A pokud má mít pedantský šéf skladu šanci udržet si pořádek, nesmí mu do skladu lézt každý kdo jde okolo... Pokud je pro to v organizaci podpora, tak to může fungovat. I bez drastické hmotné odpovědnosti.