Fórum Root.cz
Hlavní témata => Server => Téma založeno: Ijacek 16. 11. 2018, 18:50:14
-
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ů. A to, že by mohl být výsledek i někomu užitečný poskytne i nějakou motivaci.
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é.
Hledal jsem inspiraci jak vypadá databáze u podobných opensource projektů, ale asi se neumím správně zeptat. Nacházím jen velké ERP systémy. Poradil by někdo jak má ta databáze vypadat případně nějaký obdobný opensource projekt z kterého by se dalo inspirovat?
Jde o sklad dílů a výrobků z něho. Chci databázi v které bude sklad výrobků a seznam z kterých součástí jsou vyrobené. K tomu skladovou evidenci těch součástí. Jednotlivé díly se mohou vyskytovat ve více výrobcích. A databáze by měla být rozšiřitelná. Na tom ztroskotala jedná velká tabulka ala excel...
Diky za jakékoliv nakopnutí.
-
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. ... Na tom ztroskotala jedná velká tabulka ala excel ... ale asi se neumím správně zeptat. Nacházím jen velké ERP systémy.
Nevim jak chceš něco dělat když nemáš intelekt ani na položení dotazu v google.
Chápu, že je někdy hledání dřina, ale zkusils něco jako "php pro začátečníky" a pak třeba "mysql pro začátečníky" a pak se můžeš přesunout k výživnému "jak navrhnout databázi pro začátečníky".
-
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ů. A to, že by mohl být výsledek i někomu užitečný poskytne i nějakou motivaci.
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 o sklad dílů a výrobků z něho. Chci databázi v které bude sklad výrobků a seznam z kterých součástí jsou vyrobené. K tomu skladovou evidenci těch součástí. Jednotlivé díly se mohou vyskytovat ve více výrobcích. A databáze by měla být rozšiřitelná. Na tom ztroskotala jedná velká tabulka ala excel...
Diky za jakékoliv nakopnutí.
Nástřel schematu:
vyrobek
- id
- name
... další vlastnosti
cast
- id
- name
... další vlastnosti
vyrobek2cast
- id_vyrobek
- id_cast
- kusů
Domnívám se, že tvůj problém je právě ten počet kusů ve vazební tabulce
-
Ono by postacil jenom strom, jelikoz se nemusi rozlisovat mezi tridou vyrobku a komponent. I komponent muze byt vyrobek sam o sobe:
produkt
- id
- name
... další vlastnosti
sestava
- id_sestava
- id_komponent
- reference
- kusů
Sestava i Komponent se odkazuje do tabulky produktu. Samozrejme nejaka logika musi vyresit to, abys nemohl udelat smycku :)
-
Mít v tabulce výrobků položku s polem součást/počet mi nepřijde správné.
Výrobek a jeho položky bych dal samostatně. Takový model mi přijde v pohodě:
Šroubek ...
Krabička ...
Krabička šroubků ...
Krabička, 1x
Šroubek, 10xJde hlavně o to, jak se ti to hodí. Nebo si nainstaluj Pohodu nebo něco a inspiruj se, co tak nějak sklady mají umět a jak to ukládají (tak jak jsem popsal).
-
1. tabulka - Výrobek (id, název, početNaSkladě, další informace)
2. tabulka - Součástka (id, název, početNaSkladě, daší informace)
Pak si musíš uvědomit typ vzájemné vazby. Výrobek může obsahovat více druhů součástek, stejná součástka může být v několika typech výrobků => vazba M:N (to je databázová teorie) a tahle vazba se řeší vazební tabulkou:
3. tabulka - VýrobekSoučástka (id, idVýrobku, idSoučástky, početSoučástekVeVýrobku, další informace)
Ten početSučástekVeVýrobku není principiální nutnost, ale jen praktické zjednodušení, jinak bys musel místo toho zakládat pro X součástek v jednom výrobku X vazebních záznamů (což by ale mohlo zase mít výhodu, pokud bys chtěl popsat umístění každé z těch součástek ve výrobku)
-
1. tabulka - Výrobek (id, název, početNaSkladě, další informace)
2. tabulka - Součástka (id, název, početNaSkladě, daší informace)
Pak si musíš uvědomit typ vzájemné vazby. Výrobek může obsahovat více druhů součástek, stejná součástka může být v několika typech výrobků => vazba M:N (to je databázová teorie) a tahle vazba se řeší vazební tabulkou:
3. tabulka - VýrobekSoučástka (id, idVýrobku, idSoučástky, početSoučástekVeVýrobku, další informace)
Ten početSučástekVeVýrobku není principiální nutnost, ale jen praktické zjednodušení, jinak bys musel místo toho zakládat pro X součástek v jednom výrobku X vazebních záznamů (což by ale mohlo zase mít výhodu, pokud bys chtěl popsat umístění každé z těch součástek ve výrobku)
Mohl sis usetrit cas a napsatze RDa ma pravdu ... jeho reseni bylo naprosto stejne.
-
Ale pro začátečníka mi připadlo moc stručné a bez vysvětlení proč.
-
Nastříhej si papírové kartičky a "simuluj". Až pochopíš jak sklad vůbec funguje, můžeš něco navrhovat.
-
Nebo si vygoogluj neco o BOM - billing of materials
-
Potřebuješ řešení o 2 tabulkach
Vetsinou prodacas i materiál. Skladovou zásobu bys měl vést jen u něj a dostup ost výrobků hledat dynamicky(nebo počítat triggerem). Rozhodně se inspiruj v hotových programech.
-
Excel nahrad Accessem, u tak maly veci nema cenu delat sql..
-
Nastříhej si papírové kartičky a "simuluj". Až pochopíš jak sklad vůbec funguje, můžeš něco navrhovat.
Přesně tak, analýzou totiž zjistíš jak to funguje a zároveň ti pomůže odhalit slabá místa a pak můžeš navrhnout úpravy, jimiž vyřešíš to, co uživatele nejvíce pálí. Před lety jsem se takhle potýkal se skladovým hospodářstvím výdejny ve strojírenském podniku. Tam je situace řádově složitější, protože krom toho, že nástroje a nářadí vydáváš, také je i přijímáš, posíláš na kontrolu (elektrické nástroje, měřidla...) a odepisuješ (zlomený vrták, fréza...).
V lékárně se například řeší navíc rozdíl mezi expirací a šarží (stejné kapky do nosu nejsou stejné).
-
A az si zacnes hrat, tak velmi rychle zjistis, ze tech tabulek v ty databazi bude 30, kdyz malo. Protoze tech skladu mas zcela zarucene vic, pripadne chces vedet, kde v tom skladu dana vec je. Pak chces taky delat inventury a porovnavat to co se naslo s tim co by tam melo byt. Chces trebas taky videt kdo co a kdy kam daval, chces resit fifo atd atd.
-
Warehouse management systemy ktery jsem doposud videl, byly zalozeny na dvou klicovych tabulkach. Jedna obsahovava seznam veci, ktery se do skladu privezly, druha seznam veci ktery se vyskladnily. Zbyle tabulky popisovaly procesy ve skladu, objednavky, konfiguraci, uzivatele, prava, ...
-
Trošku mi v těch navrhovaných modelech chybí informace o lokacích (každý element může být uložen na více místech), kapacitach lokaci a balících jednotkách.
-
Excel nahrad Accessem, u tak maly veci nema cenu delat sql..
Neco mi rika ze k php aso nechce sql server ... mozna spis mysql a tam neni duvod ho nepouzit. Access ho bude limitovat na stanici s windows.
-
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ů. A to, že by mohl být výsledek i někomu užitečný poskytne i nějakou motivaci.
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 o sklad dílů a výrobků z něho. Chci databázi v které bude sklad výrobků a seznam z kterých součástí jsou vyrobené. K tomu skladovou evidenci těch součástí. Jednotlivé díly se mohou vyskytovat ve více výrobcích. A databáze by měla být rozšiřitelná. Na tom ztroskotala jedná velká tabulka ala excel...
Diky za jakékoliv nakopnutí.
Nástřel schematu:
vyrobek
- id
- name
... další vlastnosti
cast
- id
- name
... další vlastnosti
vyrobek2cast
- id_vyrobek
- id_cast
- kusů
Domnívám se, že tvůj problém je právě ten počet kusů ve vazební tabulce
Dík,
toto řešení mne napadlo jako první. Ale když jsem si představil počet položek v té vazební tabulce které budou v podstatě totožné, tak jsem myslel, že tudy cesta nevede a měl bych to nějak přidat k výrobku. V každém výrobku bude hromada stejných šroubů a každý bude znamenat řádek ve vazební tabulce, tak mne napadlo to pole...
-
Nástřel schematu:
vyrobek
- id
- name
... další vlastnosti
cast
- id
- name
... další vlastnosti
vyrobek2cast
- id_vyrobek
- id_cast
- kusů
Domnívám se, že tvůj problém je právě ten počet kusů ve vazební tabulce
Dík,
toto řešení mne napadlo jako první. Ale když jsem si představil počet položek v té vazební tabulce které budou v podstatě totožné, tak jsem myslel, že tudy cesta nevede a měl bych to nějak přidat k výrobku. V každém výrobku bude hromada stejných šroubů a každý bude znamenat řádek ve vazební tabulce, tak mne napadlo to pole...
IMHO to je myšleno tak, že v té vazební tabulce bude jen jeden řádek a v něm bude uveden počet, kolik těch stejných šroubků výrobek obsahuje.
-
Pole v tabulce výrobků pro součástí je na první pohled líbivé řešení jehož nevýhody se projeví v okamziku, kdy zjistíš, že výrobek může mít podsestavy.
-
To xffefef:
Tutorialy apd, jsem prostudoval, ale tento problem nepochopil. Respektive dle zdejších odpovědí pochopil, ale považoval to za chybný přístup.
To Radovan.
Nemusím si stříhat kartičky. Léta denně ten materiál a výrobky vozím tam a zpět a vím co jak funguje. Proto jsem to zvolil oproti imaginární knihovně z tutoriálů.
To RDa:
To jsem nějak nepochopil... V sestavě může být různý počet komponent a dělat pro každou vlastní sloupec se už ukázalo jako blbost.
To Oooo: Díky, vygooglím.
To je jedno : Nevím jak to myslíš. U hotových řešení jsem se díval, ale nalezl jsem právě jen velké ERP kde byl počet tabulek v třímístných číslech kterými jsem se nedokázal prokousat.
To romanz :
Potrebuji to online. A s MS jsem skoncil i desktopu.
To Dr. Heinz Doofenshmirtz, j :
Klobouk dolů. Kdyby jste se chtěl strukturou té DB pochlubit, uvítal bych to. Tohle bude také poněkud složitější, výrobek na více místech, občas se některé výrobky rozeberou aby se nějaký díl použil tam kde to víc hoří, zmetkovitost dílů, inventury, důvod odepsání, z jednoho dílu se uděljí dva jiné případně se použije jiný než tam patří, apd.
To Ivan:
Zajímavé... přivedl jste mne na myšlenku, že by bylo se mohlo hodit zpětně zjistit co, kdy a kdo změnil stav na skladu. Díky
To Ondrej Nemecek:
Jasně, ale ten řádek bude u některých položek klidně v každém výrobku, a nebude sám. Množství těch podobných řádků mne přivedlo na myšlenku že to je špatně.
To gnat: Na první pohled mi přišlo dobré řešení široká tabulka s výrobkem v řadku a díly jako sloupci. To je momentální řešení v excelu. A ukázalo se jako úplně scestné. Struktura DB je základ, když je špatně, musí se začít od základu. I když vynalézáním kola se nejvíc naučim, tady se mi to opakovat nechce a tak se raději ptám.
Děkuji BoneFlute, agent a všem ostaním.
-
Warehouse management systemy ktery jsem doposud videl, byly zalozeny na dvou klicovych tabulkach. Jedna obsahovava seznam veci, ktery se do skladu privezly, druha seznam veci ktery se vyskladnily. Zbyle tabulky popisovaly procesy ve skladu, objednavky, konfiguraci, uzivatele, prava, ...
Tohle jsem měl v jedné tabulce. Oddělovat příjem od výdeje mi nedávalo smysl.
-
Aby to vubec nejak fungovalo, musi byt pro kazdy vyrobek BOM napriklad jako vyrobek = jedna tabulka - idkomponenty, pocet kusu
Pak staci velka tabulka skladu komponent -klic1- Id komponenty-ks-misto etc
Oddelil bych sklad vyrobku - klic2 -Id vyrobku-ks-misto, etc.
Pak kdyz smena vyrobi x ks vyrobku a uskladni je nekam, dle BOM se odecte prislusny pocet komponent ze skladu...
takto primitivne zacit a postupne dodavat dalsi ficury - tabulka objednaneho- material na ceste - atp...
cus bambus
-
S kolika položkami se bude ve skladu operovat, jestli by nebylo lepší (v případě zmiňovaných sestav) použít dokumentovou databázi.
-
S kolika položkami se bude ve skladu operovat, jestli by nebylo lepší (v případě zmiňovaných sestav) použít dokumentovou databázi.
Dokumentovou databázi bych do toho netahal - nadělá s tím víc škody než užitku.
-
S kolika položkami se bude ve skladu operovat, jestli by nebylo lepší (v případě zmiňovaných sestav) použít dokumentovou databázi.
Dokumentovou databázi bych do toho netahal - nadělá s tím víc škody než užitku.
Fakt? Čím napríklad?
-
Asi jsem mimo, ale ohnout document management system na skladové hospodářství? A proboha proč? Relační databáze je mnohem spíš to správné kladivo, pokud není na pořadu dne, koupit na to hotový software (s databází uvnitř / na pozadí).
No fakt je, že už jsem viděl webový document management systém ohnutý na downloads section u jednoho výrobce... uživatelský dojem byl "přes koleno" a stejně tam nedokázali nacpat data tak, aby struktura "odkazů" odpovídala rodinám HW produktů, které sdílejí společné ovladače apod. Ale to bylo spíš o sebekázni správců.
-
Mimo autora dotazu tady nikdo neznáme s jak velkým množstvím jakých dat ten sklad operuje.
Část si tu asi představuje sklad nějakého obchodu - navezu paletu, odvezu paletu, všechno pěkně v krabičkách. Uvědomte si ale, jestli má sestavu, třeba tepelné čerpadlo a potřebuje z něj ad-hoc nějakou součást (například kvůli urgentní opravě) kanibalizovat a pak ji zase vrátit, jak složitá by vám vznikla struktura databáze. Kolik myslíte, že ten sklad může těch čerpadel držet? Dva kusy? Jestli to doteď drželi v Excelovské tabulce, tak se podívejte kolik je ta schopná zvládnout záznamů a vyjde vám z toho, že to nebyly statisíce položek a hledáte se tu řešení na problém, který neexistuje.
-
Asi jsem mimo, ale ohnout document management system na skladové hospodářství? A proboha proč? Relační databáze je mnohem spíš to správné kladivo, pokud není na pořadu dne, koupit na to hotový software (s databází uvnitř / na pozadí).
On nepsal DMS ale dokumentovou databázi :) Třeba MongoDB nebo tak..
-
To RDa:
To jsem nějak nepochopil... V sestavě může být různý počet komponent a dělat pro každou vlastní sloupec se už ukázalo jako blbost.
Asi se nechapeme, nebo ty nechapes co je databaze. Ty potrebujes ukladat 2 druhy informaci: seznam fyzickych veci, at uz sestav nebo komponent ze kterych se to sklada = produkty (Tabulka 1). A pak informaci, kolikrat se ktera vec nachazi v jine veci (Tabulka 2 - sestava), s nejakou referenci, jestli to tam bude obsazeno na vice mistech:
produkty:
1. auto
2. koleso
:
sestava:
1 2 "provozni" 4x
1 2 "nahradni" 1x
:
Kde je tady vlastni sloupec? Jsou to dve primitivni tabulky.
-
To je jedno : Nevím jak to myslíš. U hotových řešení jsem se díval, ale nalezl jsem právě jen velké ERP kde byl počet tabulek v třímístných číslech kterými jsem se nedokázal prokousat.
ja mluvil pouze o tom material - vyrobek (tedy v podstate kusovniky). Pak tam samozrejme budou desitky a stovky dalsich tabulek.
-
To RDa:
To jsem nějak nepochopil... V sestavě může být různý počet komponent a dělat pro každou vlastní sloupec se už ukázalo jako blbost.
Asi se nechapeme, nebo ty nechapes co je databaze. Ty potrebujes ukladat 2 druhy informaci: seznam fyzickych veci, at uz sestav nebo komponent ze kterych se to sklada = produkty (Tabulka 1). A pak informaci, kolikrat se ktera vec nachazi v jine veci (Tabulka 2 - sestava), s nejakou referenci, jestli to tam bude obsazeno na vice mistech:
produkty:
1. auto
2. koleso
:
sestava:
1 2 "provozni" 4x
1 2 "nahradni" 1x
:
Kde je tady vlastni sloupec? Jsou to dve primitivni tabulky.
Ty první dva sloupce v tabulce "sestava" odkazují oba do tabulky "produkty"?
-
Jedná se o nízké stovky druhů výrobku. Každý z desítek druhů dílů o desítkovém počtu. Cca 10% dílů jde do více výrobků, klidně do všech. Skladem jsou stovky až tisíce kusů výrobků a vysoké desetitisíce jednotlivých dílů. Denně jde z/do skladu statisíce dílů. Odehrává se to v cca 30 skladových halách.
Excelová tabulka většinu věcí neřeší. Díly si pracovníci berou často sami a skladník tak nemá přehled. Vzniká tak spousta průserů a prostojů.
Hotový systém je neprůchodný. Ani bych ho nedoporučil. Myslím, že úspěch implementace stojí primárně na kázni těch co s tím budou pracovat a na to bych nevsadil ani svůj dělnický plat. Je to pro mé rozšíření vědomostí, likvidaci volného času a možná i zlepšení pracovního prostředí.
P.S.: Úspěšná čtvrtletní inventura rovná se odchylka v jednotkách kamionů...
-
Pokud si lidé berou ze skladu sami, tak struktura databáze je až ten úplně poslední problém (a skladník má buď nervy z oceli, nebo nemá hmotnou odpovědnost).
Prvně bych se zeptal - nakolik je reálné, že se evidencí změní přístup lidí. Mám tím na mysli, co je příčinou, proč nefunguje žádná evidence o pohybu položek. To tam chodí každý pro jednotlivé šroubky, protože nemá na pracovišti skříňku, kam by si to mohl zamknout?
Co se týká položek na skladu, v tomhle okamžiku bych snad ani neřešil z čeho se co skládá. Do skladu přijmete krabici šroubků, matek a podložek a plechů s dírou. Vydáte je a vrátí se smontované pokosníky. V tom okamžiku už nikoho nezajímá, který konkrétní šroubek je kde použit, nebo neřešíte sklad, ale nějaký rodný list výrobku?
-
Tak to v tom mate peknej bordel. Takže, nejprve zavést aspoň čárové kódy,
fasovaci listy, dusledne evidovat převod materiálu do výroby, převod výrobků na sklad, atd. Prostě udělat pořádek. Nechapu jak vám mohl na toto stačit Excel. Hodně štěstí přeju pri tom programování od nuly...
-
co třeba nějak takto:
sklad
------
identifikace
skladová karta
--------------
sklad
identifikace
měrná jednotka
aktuální množství
aktuální cena
díly
---
skladová karta
množství
skladová karta dílu
pohyb
-----
sklad
identifikace
typ pohybu (příjem/výdej)
datum
položka
-------
pohyb
skladová karta
množství
cena
- jednotlivé výrobky a díly jsou v tabulce skladová karta, v případě výrobku obsahuje karta seznam dílů, ze kterých se skládá. Pohyb je záznamem o příjmu a výdeji na skladě, každý pohyb má seznam položek, které byly přijaté, nebo vydané. Pole identifikace v tabulkách může být třeba číslo a název.
-
... vyjde vám z toho, že to nebyly statisíce položek ...
To by ses divil, co nekteri dokazou v excelu zprasit ...
2Ijacek: Skladovych systemu jsou stovky, spousta firem si je pise namiru, protoze zadnej neumi vsechno, ale nektery veci jsou zaklad. A na jednu, dve, pet ... tabulek proste rovnou zapomen. Zapomen i na to, ze budes mit jednu tabulku produktu ... protoze kazdej jeden bude mit 1-N ruznych identifikatoru, paac kazdej dodavatel to dodava pod jinym (a odberatel pod jinym objednava), a ty je musis umet identifikovat pod kazdym. A pokud potrebujes resit jeste expirace, seriovy cisla, sarze, ... tak to pekne bobtna a bobtna.
Samo zalezi co od toho chces. Kdyz neco nepotrebujes, muzes to vynechat, ale mel bys pocitat s tim, ze to potrebovat budes - presne v den, kdy reknes se je to hotovy.
Bezne se resi to, ze ve sklade mas jednotlivy mista (at uz krabice/palety/regaly ....) a sklad vi, kde co lezi, takze ti muze rict, kam pro to mas jit. A pokud vis, jak je ten sklad fyzicky usporadanej, tak ti i muze rict, ze si to mas vzit v prizemi, protoze pro ten jeden kus nepolezes 10m vysoko. Samo se resi rozmery, jak produktu, tak mista, aby ti to mohlo rict, jestli se to tam vejde. Resi se pochopitelne nosnost (regal ve skutecnosti neunese konstatni vahu na kazdy polici, a navic ho musis zatezovat zezdola) atd atd.
A pak taky budes resit pocitam nejaky procesy, prijem, preskladnovani, vydej, inventury ... a zase, to ti databaze pekne naroste, protoze to ze ze skladu vemes 10 sroubku a 10 maticek by jeste nemelo ty veci ze skladu odepsat, protoze si je jeste nikomu nedal, jen si je vzal z tech krabic. Ale uz potrebujes vedet, ze v tech krabicich nejsou. Pripadne chces resit zapujcky = zase potrebujes vedet kde(kdo) to ma ...
Ve finale musis pocitat s tim, ze skladnik je negramotnej idiot, takze cokoli podelat muze, to taky zarucene podela, takze trebas ty mista se zasadne necislujou, ale vzdy musi byt soucasti oznaceni pismeno. Protoze jinak budes mit v poctu presne to cislo toho regalu. Ve vseobecnosti bys vsechny procesy mel navrhnout tak, aby vyzadovaly co mozna nejmin jakyhokoli premejsleni - oni stejne nezvladnou pocitat ani do 10, takze kdyz chces vydat 10, budes tam mit cokoli mezi 5-20.
-
@j: přesně kvůli takovýmto komentářům sem chodím. Tohle se člověk těžko někde jinde dočte. Ještě dneska se pokloním našemu šéfovi skladu.
-
Ty první dva sloupce v tabulce "sestava" odkazují oba do tabulky "produkty"?
Ano presne tak, ale tohle je jen pro ty sestavy. Pak tu evidenci pohybu musi resit dalsima tabulkama pro "co kdy kde kym" bylo odneseno.
-
přesně kvůli takovýmto komentářům sem chodím. Tohle se člověk těžko někde jinde dočte. Ještě dneska se pokloním našemu šéfovi skladu.
Kdysi jsem takovou věc řešil s profesionálem (1mannshow), rostlo to a klubalo se skoro 3 roky. Byly tam sestavy i rozpad materiálu (výroba, řezání, odpad).
Teď přijde rada. Nejdřív si nainstaluj nějaký free systém, vyzkoušej co to dělá a má dělat, dohodni se s nějakým dodavatelem ohledně doplnění částí systému, které neumí. Pak studuj, nebo kup něco hotového. Příjem/výdej se dá splichtit tak, aby to šlapalo. To okolo, a vazby mezi materiály a událostmi, to je už jiná liga. Radím ze zkušenosti, ztratil jsem 10 let života a málem to odneslo zdraví (nakonec jsem utekl mimo obor).
A nezapomeň na toho vedoucího skladu. Už bude takovej fialovej, až do zelena, sedí v koutě a klepe se. Inventura se blíží.
-
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.
-
8) wow! moc pekny popis, to by bolo na clanok
-
To bys mel spis na hodne dlouhej serial, v realu v drtivy vetsine pripadu neni sklad jako takovej soucasti erp, takze se musis prizpusobnit tomu, jak s tim naraba pouzivany ERPcko. A prvni co zjistis je fakt, ze nic neni pravda ... ;D.
Protoze jestli mas predstavu, ze Pepa udela zakazku, tu posle do skladu a skladnik ji vyda, tak presne takhle to NEfunguje.
Protoze Pepa udela zakazku, posle ji do skladu, skladnik vyda to co sklad ma, a pak si zakaznik rozmysli, ze misto sroubu M10 chce M8. A ty maticky, ktery si jeste pred minutou nemel, prave Franta z kotehulek privez, tak mu je tam koukejte dat, at si nestezuje, ze je nedostal ... a ty trubky, co si jich objednal 10x5m, mu dejte 10x 5,5m, protoze v nakupu je to stejny, 5tky nemame, ale 5,5 jo. Pak dorazi Josifek z ulice, a chce svuj plech 100x100mm, tak proc bys mu ho nedal, jenze kdyz mu skladnik ten plech vrazi doruky, tak se mu nelibi, protoze je malo plechovej (pripadne si to rozmysli uz cestou do skladu nebo ...).
Pak tady mas vsemozny "hry" na tema certifikace (CE, ISO a spol), kde mas klidne od stejnyho dodavatele totoznej produkt S a BEZ certifikace, a v tom skladu to (hypoteticky) musis umet oddelit. Prakticky to samozrejme vypada tak, ze dostanes cokoli co zrovna ve sklade je (pokud chces "certifikovanej" strom, tak leda tak, ze si ho dojdes osobne uriznout).
A se vsim timhle (a hromadou dalsich veci) bys mel ve skladu pocitat. A presne proto si to hromada firem dela interne sama (pripadne to pro ne dela nejakej dodavatel na zakazku), protoze zadnej "hotovej" system s necim takovym nepocita ani ve snu.
-
To Karel:
výborný popis, díky moc. Tohle by fakt bylo na článek. Ztratil jsem se tedy na InventoryTransaction u ID transakce a ID řádku transakce. Nevím kam to směřuje či co to dělá, ale zkusím se s tím nějak popasovat zatím bez toho a ono se ukáže.
-
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. Každopádně je to o definování vlastností nutných a vlastností vhodných. Žádný systém není dokonalý. Někdy je třeba jednodušší se částečně přizpůsobit. Nechat si udělat takový systém na zakázku je finančně a časově nesrovnatelně náročnější než hotový systém s rozumnou mírou parametrizace. A při vývoji na zakázku nemáte jistotu, zda po několika letech programování a ladění to bude vůbec fungovat. Pro firmu se skladem popisované velikosti by neměl být problém to financovat.
-
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í.
-
"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ší.
-
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 ... .
-
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í.
-
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..
-
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.