Struktura databáze pro sklad

Re:Struktura databáze pro sklad
« Odpověď #30 kdy: 18. 11. 2018, 18:29:20 »
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.
Děkuji za možnost editace příspěvku.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Struktura databáze pro sklad
« Odpověď #31 kdy: 18. 11. 2018, 19:05:11 »
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:

Kód: [Vybrat]
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"?

Ijacek

Re:Struktura databáze pro sklad
« Odpověď #32 kdy: 18. 11. 2018, 22:15:20 »
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ů...

Dr. Heinz Doofenshmirtz

Re:Struktura databáze pro sklad
« Odpověď #33 kdy: 18. 11. 2018, 22:43:00 »
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?

Karlito

Re:Struktura databáze pro sklad
« Odpověď #34 kdy: 18. 11. 2018, 22:59:38 »
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...


cinnamon

Re:Struktura databáze pro sklad
« Odpověď #35 kdy: 19. 11. 2018, 07:29:19 »
co třeba nějak takto:

Kód: [Vybrat]
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.

j

Re:Struktura databáze pro sklad
« Odpověď #36 kdy: 19. 11. 2018, 10:56:09 »
... 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.

Re:Struktura databáze pro sklad
« Odpověď #37 kdy: 19. 11. 2018, 11:26:21 »
@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.

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Struktura databáze pro sklad
« Odpověď #38 kdy: 19. 11. 2018, 11:28:08 »
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.

BBuBBla

Re:Struktura databáze pro sklad
« Odpověď #39 kdy: 19. 11. 2018, 13:09:07 »
 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íží.

Karel

Re:Struktura databáze pro sklad
« Odpověď #40 kdy: 19. 11. 2018, 14:00:03 »
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.

Janci

Re:Struktura databáze pro sklad
« Odpověď #41 kdy: 20. 11. 2018, 08:02:35 »
 8) wow! moc pekny popis, to by bolo na clanok

j

Re:Struktura databáze pro sklad
« Odpověď #42 kdy: 20. 11. 2018, 08:44:53 »
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.

Ijacek

Re:Struktura databáze pro sklad
« Odpověď #43 kdy: 20. 11. 2018, 11:01:16 »
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.

franta PH

Re:Struktura databáze pro sklad
« Odpověď #44 kdy: 20. 11. 2018, 11:05:24 »
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.