Hotové řešení sklad

[Hyp]

Dobrý den,
chtěl bych se zeptat, zda o nějakém hotovém řešení skladové evidence, úplně jednoduchém systému založeném na php a mysql, které by se dalo implementovat. Jediný požadavek mám, aby to evidovalo expirace a aby to nabízelo zboží s nejkratší expirací. Procházej jsem github pro nějaké nakopnutí, ale nic kloudné jsme nenašel.

Pokud ne, zkusil bych to udělat, byť nejsem profík, ale nevím, jak nejjednodušeji udělat  u zboží např :
Nákup např. 1 basa piva (obsahuje např 24ks) a prodej po kusech či basách, jak to nejlépe přepočítávat, zda udělat dvě karty, případně umožnit vydávat jednotlivě a komplet. (Možná by bylo dobré udělat do budoucna i nějaké komplety/sety jednolivých položek a vydávat to jako jednu, ale asi to je teď zbytečné.

 a zda je nutné aktuální stav zásoby do nějaké pomocné tabulky, případně zda to dělat přepočtem všech příjmů a výdajů ( v současnosti jsou 2 sklady -uvažujeme  o 5ti, karet a je 5000 ( z toho aktivních 2000) a cca 10000 položek příjmů a výdajů.

V současnosti to dělám tak, že naskladňuji basu jako 24ks buď na sklad 1 či 2 a pak i kusy vydávám ( a u nějterých položek mám 2 skladové karty), stav zásoby mám jako pole ve skladové kartě a  k tomu mám položky jako dotaz výdej k dispozici na skladě 1 a výdej k dispozici na skladě 2, ale určitě by to mělo jt nějak zjednodušit.

Budu rád za počáteční nakopnutí :-)

[Reklama]

[vlna]

Něco umí Odoo https://www.odoo.com/page/editions

[PitB]

Nevím, jestli bych se do toho pouštěl, pokud neznáš aspoň trochu účetní postupy. Není problém udělat evidenci zásob, to je primitivní, tak jak píšeš - součty podle pohybů a v zásadě to je.
Problém nastává u oceňování zásob. Firma musí umět ocenit každou položku na skladě, při každém prodeji nebo expedici musíš umět přesně říct, kolik daná položka stála. Oceňovací metody průměrnou cenou, FIFO, podle sériových čísel,... Do toho zvládnout umět ocenit vratky, dobropisy,... Je to přímo navázáno na účtování nákladů, tím pádem zisk a tím pádem odvod daní, takže to není žádná legrace.
Dělal jsem teď jedno řešení, shodou okolností právě MySQL + PHP, máme to hotové, ale jen díky tomu že já jsem trochu dev a trochu finance a hodně Dynamics Nav a měl jsem k sobě PHPčkáře.

[Zdeno Sekerák]

Tak zrovna sklad je dobra alchymie. Priklad s jogurtama.
Na sklade mas 10 jogurtu za 12.-
Dokoupis dalsich 5 za 10.-

Kolik stoji jogurt ted? Oba jsou stejny druh malinový s dobou trvanlivosti do konce mesice. Udelas LIFO, FIFO pri prodeji? A co kdyz nekdo koupi jogurtu 12? Za kolik jich prodas? Prumer ceny?
No a to jeste do toho takova komplikace ze nejake vyhodis protoze jsou prosle, nebo protoze se cestou poškodili. Kam daš ty? Nekdo to bere s DPH nekde bez.

Jinak obycejne skladove hospodarstvi gratis rekneme do 100 polozek ti da skoro kazdy. Namatkou tady https://www.instaluj.cz/ucetni-programy#

[Miroslav Šilhavý]

Souhlas s pány kolegy.
Nejprv musíte vědět, jestli firma účtuje sklady metodou A nebo metodou B.
Poté musíte vědět, jestli ocenění skladů je váženou nákupní cenou (= vážený průměr), nebo FIFO.
Pokud evidujete šarže nebo evidenční čísla kvůli exspiraci, nabízí se FIFO.
Při vratce do skladu se musí sklad zpět přecenit - a to musíte opět vědět, jakou cenou se ocení navracená položka.

Pak tu jsou i velmi praktické operace, které musíte v praxi řešit. Např. mít možnost expedovat zboží, které ještě nemá všechny náležitosti shromážděné. Přijede zásilka zboží (nebo zboží z vratky) a končí mu exspirace. Musíte ho rychle poslat dál. Máte k dispozici spediční doklady (dodací list), ale nemáte ještě účetní doklady (fakturu) kvůli ocenění. V takovém případě potřebujete umět dělat zbožní pohyby v nezávislém cyklu od účetních pohybů, ale zároveň neztratit o tom přehled.

Musíte umět evidovat reklamace (a další vyřazené zboží), protože ho máte zpět ve skladu (účetně máte i jeho hodnotu ve skladu, dokud nedojde k přecenění - to dělá účtárna na základě podkladů), ale zároveň není disponibilní. Nemůžete ho poslat dál. Přestože není v hlavním skladu, FIFO fronta nákupních cen se touto operací nesmí porušit, takže systém s nimi počítat musí.

Atomová věda to není, pracné to je. Každopádně potřebujete nejdřív znát, jak to funguje, poté se doptat na (nejen na tyto) důležité otázky. Dat a jejich zpracování je pak hromada a lze na tom využít sílu SQL. I v poměrně malém skladu už na těchto operacích zjistíte, jak moc práce budete mít s MySQL oproti tomu, kdybyste zvolil některou z "dospělých" databází. V praxi se z opensource nejčastěji volí PostgreSQL, z proprietárních pak MS SQL (neb lze začít na Express edition a pak poměrně "levně" přejít na Standard (levně v porovnání s Oracle)).

Když se do toho pustíte bez těchto znalostí, budete to přepisovat desetkrát od nuly, protože postupně zjistíte (řeknou Vám), na co všechno jste nepomyslel.

Zaujalo mě: aby to nabízelo zboží s nejkratší expirací. To mi přijde mimo skladovou realitu. Skladník nemůže hledat správné sériové číslo podle systému. Dělává se to tak, že skladníci musejí mít srovnané zboží podle exspirace a naopak jsou to oni, kteří dávají systému informaci o tom, jakou šarži / evidenční číslo vyskladnili. Je to mnohonásobně rychlejší, a funguje to docela dobře, pokud se ve skladu drží aspoň základní pořádek.

O hotovém otevřeném řešení nevím. Muselo by být české (kvůli českým účetním standardům), spíš pochybuji, že něco takového je volně k dispozici. Třeba můžete být první.

[Reklama]

[Miroslav Šilhavý]

PS: v praxi jsem nejčastěji viděl, že firma si koupila nějaké jednoduché hotové řešení na Windows tak, aby data byla uložena v MS SQL. Do MS SQL pak lze jednoduše přistupovat i z Linuxu a nad daty si udělat např. výstupy. Pokud je potřeba provádět i vstupy, tak ty je nebezpečné zapisovat přímo do SQL (protože cizí strukturu dat nikdy neznáte dokonale). V takovém případě se vybírá i podle toho, aby daný systém měl nějaké API nebo třeba XML import dat pro opačný směr.

[Michal Šiman]

Máme vlastní vývoj, jak už tu někdo přede mnou zmínil, není to opravdu sranda. Expirace, ceny, různí dodavatelé, FIFO atd. a to nejsme prodejí firma, jsme výrobní, takže k tomu ještě BOM, pak převody materiálu na hotové výrobky. Celé nám to jede v PHP, MySQL, ještě to umí hromadu věcí navíc, vlastně je to celé ERP, ale vychází to hlavně ze skladu. Vývoj 12 let. Napasované přesně pro naše konkrétní potřeby. Já nejsem ten vývojář, jsem jen admin. Rozhodně podobná věc nejde udělat univerzálně. A rozhodně pokud ji chceš používat v ČR tak to musí být určené (ohnuté) na české zákony a předpisy. Také neznám nic hotového. A to co máme u nás by ti k ničemu nebylo. Spíš jsem chtěl říct ... vlastní vývoj a nebo na to zapomeň rovnou ...

[Petr Blahos]

Souhlasím se všema ostatníma. Ta funkcionalita se staršně nabaluje, ale hlavně jsou tam zákony.

Takový FlexiBee basic stoji 295 měsíčně na uživatele (disclaimer: sám jsem flexibee nikdy neviděl,
ale sklad prý má a ten základ tam musí mít taky, a pokud vím, tak je dost otevřený).

[Hyp]

Ahoj všem, díky moc za info.
CO se týče účetních problémů, podklady pak importuju do účetního systému přes xml, výsledky stavu zásob jsou stejné, jenom vzniká rozdíl při postupu naskladňování. Co se týče reklamací, vyřazení prošlého zboží, vše mi funguje.
Ještě mě napadlo, jestli by něco nebylo součástí nějakého obchodu k CMS (joomle,m wordpresuu), přáípadně to přesunout takto. Chtěl bych mít data v myslq, abych k nim mohl přistupovat
Fakt se nechvi smířit s tím, že by se nic podobného neřešilo..........
Díky moc. Hyp

[Miroslav Šilhavý]

CO se týče účetních problémů, podklady pak importuju do účetního systému přes xml, výsledky stavu zásob jsou stejné, jenom vzniká rozdíl při postupu naskladňování.

Jak můžete importovat do účetního programu a jak může účetní program oceňovat sklad, když s oceněním nepracujete? Takto můžete maximálně importovat počet kusů, nic víc.

[Ondrej Nemecek]

IMHO pokud chcete mít hotové řešení a přistupovat k datům, koukněte na ten FlexiBee. Neznám z praxe, ale co jsem na něj koukal tak je opravdu navržený pro dobrou integraci, má API, dokumentaci a běží na otevřených technologiích.

[Hyp]

CO se týče účetních problémů, podklady pak importuju do účetního systému přes xml, výsledky stavu zásob jsou stejné, jenom vzniká rozdíl při postupu naskladňování.

Jak můžete importovat do účetního programu a jak může účetní program oceňovat sklad, když s oceněním nepracujete? Takto můžete maximálně importovat počet kusů, nic víc.

Hodnora skladu se počítá nákupních cen a množství zásob, což Pohoda bez problémů počítá i přepočítá zpětně. Já sám si počítám průměrnou nákupní cenu, kdy jediný rozdíl mi vzniká tím, že např. pokud já prodám poslední kus a ten den naskladním nové / nebo naskladním nové a prodám poslední kus, tak vznikají rozdíly mé a pohody, což, dle mého, jsou oba postupy v pořádku a hlavně rozdíly jsou naprosto zanedbatelné.

[Miroslav Šilhavý]

Hodnora skladu se počítá nákupních cen a množství zásob, což Pohoda bez problémů počítá i přepočítá zpětně. Já sám si počítám průměrnou nákupní cenu, kdy jediný rozdíl mi vzniká tím, že např. pokud já prodám poslední kus a ten den naskladním nové / nebo naskladním nové a prodám poslední kus, tak vznikají rozdíly mé a pohody, což, dle mého, jsou oba postupy v pořádku a hlavně rozdíly jsou naprosto zanedbatelné.

Vážené nákupní ceny jsou možná metoda, protože vedou stále k přesnému výsledku. Horší to ale je, když řešíte vratky (musíte znát nákupní cenu toho, co se vrací). Druhou chybou, kterou v Pohodě uděláte jsou reklamace a exspirované zboží. Pokud je nevyřídíte ze skladu okamžitě, rozjede se to už od reality. Pokud pan kolega napojuje externí systém, nelze očekávat, že účtárna tyto operace provede okamžitě.

Popisovaný problém s Pohodou se řeší v údržbě databáze, tam je operace přepočtu vážených nákupních cen.

[Hyp]

Děkuji za info.
Co se týče rozdílů, tak si myslím, že metodika se dá ošetřit vnitřní směrnicí, neboť kdy se vyřadí prošlé zboží a kdy se zaúčtuje není možné brát absurdně. Např. něco se likviduje na svoje náklady dodavatel, něco musí být zlikvidováno odborně a zaneseno do systému odpadů. Reklamace se někdy uzná/někdy ne Je zde spousty variant a případů, ale myslím si, že není nutné vše řešit on-line, je třeba dodržovat stálé postupy a v případě změn udělat doklady pro průkaznost.

Co se týče údržby databáze
ta si myslím zahrnuje přepočet cen, ale dle mého názoru není nutná, pouze provádí údržbu databáze, neboť tam je accesssovská. Samozřejmě se to doporučuje, aby se odstranily chybné relace, ale nutné to není. Také pohoda umožňuje funkci výdej do mínusu či nikoli, takže i zde jsou rozdíly, to bych ale neřešil. Pohoda si myslím, že to přepočítává (při importu xml) dle dnů, ale nejsem si jist.

Jinak děkuji za informace, jen bych se zeptal :
-jak a zda dělat ty různé typy množství-zatím mám kartu zboží vždy na nejmenší prodávané množství, ale spoustu dodavatelů nabízí elektronické dodací listy pro načtení, což by asi usnadnilo práci, ale tím, že nesedí popis zboží, tak to naskladňujeme ručně přes čárové kódy, ale asi pokud by bylo řešení na přepočet /balení/blistr/karton u každé položky, asi by to nějak šlo načíst, že by se změnilo množství
-jak nejlépe řešit to porovnábání expirací : v současnosti mám dotaz na dotazu v accessu, což je asi nevhodné, ale vůbec nevím, jak to upravit/zjednosušit
SELECT [Expirace-prijemky].IdKarty, [Expirace-prijemky].Expirace, [Expirace-prijemky]!SumOfMnozstvi+Nz([Expirace-vydejky]!SuofVydano,0) AS K_Dispozici, [Expirace-prijemky].Sklad
FROM [Expirace-prijemky] LEFT JOIN [Expirace-vydejky] ON ([Expirace-prijemky].Expirace = [Expirace-vydejky].Expirace) AND ([Expirace-prijemky].IdKarty = [Expirace-vydejky].IdKarty) AND ([Expirace-prijemky].Sklad = [Expirace-vydejky].Sklad)
GROUP BY [Expirace-prijemky].IdKarty, [Expirace-prijemky].Expirace, [Expirace-prijemky]!SumOfMnozstvi+Nz([Expirace-vydejky]!SuofVydano,0), [Expirace-prijemky].Sklad
HAVING ((([Expirace-prijemky]![SumOfMnozstvi]+Nz([Expirace-vydejky]![SuofVydano],0))<>0))
ORDER BY [Expirace-prijemky].Expirace;

[Miroslav Šilhavý]

...

Achich, hodně témat .

Interní směrnicí můžete upravit pravidla ve firmě, ale stále musejí zůstat splňovat Zákon o účetnictví a Český účetní standard (i ostatní předpisy). Zboží, pokud se Vám vrátilo (je Vaše), musí být k rozhodnému okamžiku naskladněno a za správnou cenu (nákupní cenu). Toto pravidlo obejít nelze, protože pak nesplníte požadavek na souvstažnost a potažmo s tím padá průkaznost účetní operace. Proto se to řešívá odděleným kolečkem kusových pohybů od účetních pohybů. Skladový systém eviduje kusy ve skladovém oběhu, ale chybí mu účetní pohyby. Na to se bohužel nedá rezignovat.

(S názorem, že zákon zle obejít interní směrnicí se setkávám, ale NELZE).

Přepočet VNC je důležitý, právě kvůli záporným stavům musíte používat funkci na přepočet a následně v údržbě databáze používat i přepočet cen. Pokud to děláte dobře, projde to bez problémů. V praxi se v Pohodě striktně zakazují pohyby do mínusu, právě kvůli obrovskému riziku rozpadu ocenění. Povolují se jen na chvíli při zvláštních operacích, které musí dělat opravdu znalá osoba. Zde moc doporučuji mínusové stavy úplně vypnout, je to cesta do pekel, věřte mi. Konkrétně Pohoda používá pro ukládání MDB nebo i MS SQL a provádí při údržbě spoustu operací. Přepočet VNC je jedna z nich.

Různé jednotky se řeší přes tabulku jednotek. Stanovují se pak převody do základní jednotky. Např. může být základní jednotkou gram (nějaké suroviny) a odvozenou jednotkou miligram, kilogram, balení či paleta. Skladové sestavy se pak tisknou v základní jednotce (je nemyslitelné sestavy ladit ručně na různé jednotky). Je potřeba si pohlídat rozlišení jednotek, aby nedocházelo k rozdílům.

Dotaz máte principiálně správně, musí se groupovat podle šarže (exspirace), jen nějak nechápu proč je to tabulka expirace-prijemky, z příjemek se to určitě brát nemá. Co byste na takovém dotazu chtěl zjednodušit?

Kód: [Vybrat]

SELECT
  id_zbozi,
  datum_exspirace,
  volne_kusy
FROM
  stav_skladu
  INNER JOIN exspirace -- může být podle situace LEFT JOIN
GROUP BY
  id_zbozi, datum_exspirace