Názory k článku Odoo: otevřený informační systém nabízející ERP, CMS i e-commerce

“základ je k dispozici zdarma s otevřenými zdrojovými kódy a placené řešení včetně pro firmu téměř nezbytné podpory podobně jako u jiných systémů.”

Pokud se spravne koukam na jejich Pricing plan tak zdarma je jedna aplikace v Odoo Online. Pokud chce clovek vsechny aplikace tak je to $25/user/month. Pokud se koukam na jejich community verzi tak nektere moduly jsou k dispozici, nektere nejsou. Mobilni aplikace v community dle prehledu neni. Z clanku jsem mel pocit ze Odoo je neco co muzu nasadit ve firme a pak se pripadne rozhodnout pro placenou podporu, dle jejich stranek to ale tak neni (pokud nezvazuji omezene nasazeni bez mobilnich aplikaci). Na druhou stranu cena je porad zajimava. Dekuji za clanek!

na druhou stranu nejspíš očekáváš, že SW se nepřestane vyvíjet, že budou opravovat bugy a přidávat kompatibilitu a podporu novým technologiím...

Zažil jsem už spousty skvělých aplikací, které umřeli, protože se o ně nikdo nestaral a vývojář z toho neměl dostatečné příjmy.

O prostredky na dalsi vyvoj sw je postarano jak u "licencniho" modelu, tak i u "predplatneho". Pokud si totiz koupis jednorazovou licenci, v cene je obvykle 1 rok podpory. Jestli chces dostavat nove verze, plati se za prodluzovani supportu. Co mam tady prehled z firmy, vetsinou je to 5 az 20% z ceny jednorazove licence...

Pokud ovsem nechces novsi verze softwaru a support nepotrebujes, nemusis krom te jednorazove ceny za licenci nic platit. A to je presne ta moznost svobodne volby, ktera je ti u "predplatneho" uprena...

Mám s tým rovnaký problém a tento model sa mi nepáči.
Tiež si chcem licenciu kúpiť jednorázovo a prípadne si platiť predplatné za možnosť upgrade-u, ak to bude potrebné ako byť rukojemníkom.
Viem že to je "nemoderný" pohľad, ale ako niekto kto roky nakupoval softvér pre korporáciu som videl, ako sa situácia postupne "modernizovala" a firmy už nevedeli ako ťahať zo zákazníkov peniaze.

Vďaka za tipy ohľadom alternatív k Odoo, ktoré sú spomínané nižšie, ako sú InvenTree alebo ale ERPNext.

Nikdo vás nenutí nic kupovat. Odoo můžete stáhnout a provozovat na vlastním serveru.

Ano, zde jsem se nejasně vyjádřil. V případě instalace Community edice ze zdrojových kódů mám k dispozici standardní moduly, kterých je dostatek (účetnictví, nákup, prodej, výdaje, fakturace, inventář, PoS, projekty, služby, výroba, pracovní výkazy, docházka, smlouvy, údržba, jakost, plánování, eLearning, kalendář, diskuze, blogy, eshop, webstránka...) s tím, že později lze přejít na placené řešení, nově tento model:

https://www.odoo.com/pricing-plan#hosting=on_premise

Pokud mi dostupné moduly dostačují (pro malou společnost snad ano, to je velmi individuální), funguji zdarma, případně mohu doinstalovat další aplikace třetích stran, které jsou k dispozici buď volně nebo za úplatu.

Je jasné, že pro firemní využití je placená verze ideální, u nové verze mě zaujala cena, která je velmi konkurenceschopná. Já oceňuji, že mám k dispozici zdrojové kódy pro výše uvedené moduly plus výbornou dokumentaci, reálné využití je samozřejmě o zkušenostech.

Šíře sortimentu ještě nemusí znamenat složitý datový a procesní model. Jasně různé zboží má různé jednotky / balení / pravidla porcování apod. Dál záleží na míře detailu informací o jednotlivých produktech a nakolik se dají automaticky importovat odjinud (od dodavatelů) nebo z předchozího systému, ze kterého se přechází = kolik moc ruční práce je přejít ze starého systému na nový, při té šíři sortimentu.

Obchodní firma typu nákup/prodej/sklad nemusí mít příliš složitý datový a procesní model. Klasické e-shopy mají model navzájem natolik podobný, že mohou fungovat všechny na tomtéž softwaru od jednoho až tří slavných místních dodavatelů, a zavedení nemusí být na rok, jak nás tradičně straší dodavatelé velkých ERP, ale třeba na měsíc včetně před-startovních testů a základního zaškolení na demo datech.
Velký ERP má detailně zpracovanou výrobu a další oborově specifické netriviální věci - čím větší a složitější firma (která pro své potřeby ERP nasazuje), tím složitější model.
Na zavádění velkých ERP je také náročná customizace = přiohýbání společného základu nebo hotového řešení na míru požadavkům zákazníka - který má pocit, ať už oprávněně či nikoli, že je vhodné přiohnout software, namísto přiohnutí procesů ve firmě. Analýza / implementace / testování... (a to jsem to hodně zjednodušil).
Plus třeba lokalizace = nejen překlad uživatelského rozhraní, ale třeba taky přizpůsobení datového a procesního modelu národní legislativě a dalšímu místnímu podhoubí, pokud se jedná o zahraniční SW produkt. Ideální situace je, kdy zahraniční dodavatel má generickou lokalizaci předem hotovou a trvale udržovanou.
Ona i základní parametrizace složitějšího modulu na míru firmě vyžaduje určitý čas a lidskou práci.

Naskladnit a vyskladnit v jediný den by neměl být žádný problém na straně IS nebo zpracování logistických procesů pomocí IS - pokud bych hledal problém, tak v kapacitě a pružnosti lidského faktoru a procesů fyzické logistiky. Když Vám ve tři odpoledne přijde velká dodávka různého zboží (mnoho položek), a má se každá položka vzít do ruky, spočítat, oštítkovat, fyzicky umístit do regálu apod. prostě naskladnit se vším všudy, tak může být oříšek, poslat to týž den rovnou zase dál, pokud u Vás dopravce vyzvedává pravidelně každý den ve čtyři. (Nebo třeba spíš v poledne :-) Pokud Vám zboží chodí každý den (nepracujete např. v týdenních turnusech) tak je efektivní z hlediska rovnoměrného vytížení pracovní síly, expedovat následující den po příjezdu zásilky - a to ještě za předpokladu, že dopravci v rámci dne přivážejí vstup a odvážejí výstup zhruba ve stejnou dobu. Pokud by byl odvoz výstupu ráno a na vstupu doručení večer, tak je to spíš na dva kalendářní dny.
Nějakou část administrativní práce kolem naskladnění můžete mít připravenu předem (na základě avíza o expedici od dodavatele a souvisejících dokumentů) ale velkou část práce prostě "do zásoby neuděláte".
A kompletně automatizovaná/ro­botizovaná logistika, to je jednak vyšší level a dodnes velká výjimka, druhak má taky svoje praktická úskalí, za třetí i robotický sklad má určitou konečnou průchodnost zpracování a nenulové latence.

Pořídit si do firmy software, který je sice open-source, ale přinese si ssebou ohavný dependency hell? "To nevoní dálkama", jak nám říkával Prof. Radek Novák na přednesech z mezinárodní přepravy. Toto prohlašuji jakožto ohavný kutil a freetard - na základě tu a tam zkušeností s Pythonem na Linuxu+Windows a také s prostředím komerčního softwaru. Technické podrobnosti toho pekla pitvat nebudu, jsou hezky v kostce uvedeny v článku...

Moc děkuji za perfetní popis, automatizovanou logistiku bych opravdu rád viděl v praxi, takto na "papíře" vypadá skvěle.

Ano, pekla se závislostmi se u Odoo zbavit nelze, stačí se podívat na soubor requirements.txt. Tady vidím ideální řešení pro běžnou společnost variantu "vše v jednom" s tím, že si s dodavatelem nasmlouvám komplexní podporu (a popřemýšlím o Cloud řešení, které však osobně zvláště u ERP řešení nerad vidím), otázkou je jako vždy cena (podpora české legislativy je zajištěna, v úvahu však musím též brát současný počet partnerů Odoo, kterých v ČR není mnoho:

https://www.odoo.com/partners/country/czech-republic-55

).

Mimochodem zažil jsem situaci nasazení SAP - Oracle databáze byla nainstalována na oficiálně nepodporovaném Centos serveru (aneb ušetřeme každý haléř), který díky "dobrým vztahům" dodavateli nevadil.

> automatizovanou logistiku bych opravdu rád viděl v praxi,
> takto na "papíře" vypadá skvěle.
>
To jsme dva.

Obecně o vysokou míru robotizace skladů usilují firmy jako Amazon. A bez lidí se přesto neobejdou.

Člověk by řekl, že třeba v automotive odvětví v tom taky budou napřed, když mají všude JIT a mezi prvními před mnoha lety měli třeba EDI - ale co si pamatuju když jsem se asi před 10 lety náhodně vyskytl u dokončení nové skladové haly v jedné tuzemské automobilce, tak tam stále jezdily uličkami mezi regály vysokozdvižné vozíky šoférované lidmi, které dodala nějaká agentura. A projektový šéf firmy, která tam dodávala na klíč integraci toho skladu (od vysokozdvižných vozíků po software který přijímal požadavky od ERP automobilky a dával pokyny šoférům ještěrek) se jednou rozčiloval, že si automobilka představuje, že má sklad latenci vyřízení požadavku "teď hned" a random access - a že to je přeci pitomost, že on potřebuje dostávat požadavky předem frontované, aby si mohl interně přeskupovat jejich pořadí kvůli optimalizaci tras vozíků, aby se nejezdilo pro každou pitomost zvlášť, jinak jde do kopru průchodnost. = úplně základní věci. A bez lidí to nešlo :-)

Teď nedávno jsem slyšel ohledně jednoho velkého slavného dodavatele elektrovýzbroje pro spalovací motory apod., že si staví sklad, kde se zboží skutečně nedotkne lidská ruka.

A někdy loni nebo předloni jsme dvakrát koupili pár nějakých rozvaděčů zn. Rittal od jednoho součástkového velkodistributora (tuším rakouského, nechci jmenovat) - tzn. nikoli od místního zastoupení výrobce, protože ten distributor měl požadované zboží skladem a nabízel kratší dodací lhůtu. No a v obou případech jsme ty rozvaděče obratem reklamovali, protože dorazily potlučené k nepoužití... a když jsme se distributora ptali, jak je to možné, tak jejich obchodník tvrdil, že s tím nedokážou nic dělat, protože takhle se zbožím zachází jejich úžasný nový plně robotizovaný sklad. Že tam není, koho kázeňsky řešit, protože tam na zboží nesáhne lidská ruka.

To bych chtěl někdy vidět. Jako beru EDI, že si faktury apod. posílají navzájem elektronicky ERPčka. Ale jak robot vykládá přijaté zboží z kamionu nebo kontejneru, a ještě by měl nějak inteligentně genericky kontrolovat, zda to dorazilo zhruba v pořádku, hmm...

Ve zpětném ohlédnutí detailní a zábavné intro do skladové logistiky přednášel na VŠE prof. Pernica. (Já ho zažil v minulém století.) Měl na to tuším hezky zpracovaná skripta a fůru slajdů na přednáškách.

Ano, o Amazonu jsem četl už před cca pěti lety, že se snaží minimalizovat počty zaměstnanců snad ve své polské pobočce. To jsem očekával i od dalších výrobců či distributorů, je však pravda, že živnostničím již přes deset let a informací o této problematice se ke mě dostane jen málo. Juknul jsem se na pár firem, které znám a jsem příjemně překvapen, Mall nasadlil SW robota pro stornování objednávek a ještě zajímavější model využívá Škodovka ve Vrchlabí, zde se mi moc líbí kooperace klasických zaměstnanců s robotickou automatizovanou stanicí.

VŠE jsem jako středoškolák nezažil (pouze cca před rokem na školení), takže ke slajdům přístup nemám, na druhou stranu jsem rád, že mám vyštudovanou ekonomku, protože vést si celou agendu sám není vůbec od věci.

He, he, u těch rozvaděčů Rittal jsem se krásně zasmál, budeme muset roboty pomocí AI naučit odpovědnosti, i když zatím nevím jak je trestat - vyndat baterii nebo za trest pověsit za vytaženou šňůru ze zásuvky jim zřejmě příliš vadit nebude.

Proto buďme rádi za to, co máme a jak žijeme, také jsem jako ajťák, který nyní provozuje vyjížďky a tábory na koních, míval choutky nějak to uzdění a sedlání zautomatizovat, časem jsem se uklidnil a kromě občasného výrazu typu "tohle sedlo s tou kobylou není kompatibilní" jsem zase pokorně přepnul na manuální ovládání.

"budeme muset roboty pomocí AI naučit odpovědnosti"
Ani ne. Ono je to pouzito jenom jako vymluva.

Pro méně náročné, kteří nemají v plánu hned zakládat řetězec fastfoodů, kolotočů a infolinku v Indii a support na Novém Zélandu, ale spíš nějaký jednodušší interní systém pro skladování / plánování / prodej / nákup - koukněte se na InvenTree. Umí to správu skladových zásob, BOMy, plánování, sledování vývoje cen, odhady cen, prodeje/nákupy atd. Zdarma, open-source a má to poměrně aktiní vývoj. Akorát teda aplikace do mobilu je za jednorázový poplatek.

Nicméně bych měl dodat, že osobně to (zatím) nepoužívám na žádné komerční použití, takže věci jako faktury z toho generovat neumím, nehodlám a nevím, jestli je to umí. Ovšem vzhledem k otevřenému API a podpoře pluginů by to neměl být problém ani kdyby to neumělo...

Moc děkuji za typ, na InvenTree se určitě podívám. Nakonec proč pro menší interní systém nevyužít kombinaci Python/Django.

Já jsem před lety od Odoo utekl. Myslím že poslední verzi jsem provozoval 10. Pak v nové komunitní verzi zmizely některé vlastnosti do placené verze a bylo to.
Zakotvil jsem u ErpNext, používám na výrobu, sklady a psaní faktur.

ErpNext vypadá opravdu pěkně, překvapuje mě, že v Pythonu je k dispozici tolik řešení.

Ano, téměř každá nová verze Odoo přináší nový obchodní model. Je otázkou, zda by Community verze s podporou ideálně interních vývojářů byla schopna naplnit potřeby menší nebo střední společnosti, zatím vím pouze o dvou českých firmách, které tento systém nasadily (obě v placené verzi).

ERPNext vyvíjejí indové. Ale vůbec to není špatné, jen se to musí rozšířit o VAT number a IČO u zákazníků a o datum splatnosti.
Teď jsem si do skladu dodělával uživatelské proměnné pro lokaci součástek v pořadačích.

https://axelor.com/agpl-license/ ale neměl jsem čas to detailně sledovat, protože spíš hledám OpenSource na schvalování nákupních objednávek a workflow faktur ideálně s vytežením QR platby či jiných údajů

Za me ruce pryc, hrozny bastl. Trpel jsem s tim dva roky nez se nam podarilo vse zmigrovat jinam. Na prvni pohled vypada dokumentace dobre, ale jakmile potrebuje clovek udelat neco slozitejsiho, muze se zanorit do zdrojaku plnych historickych mnamek. UI je hrozne neintuitivni. A komunita prevazne indicka, takze je to neco jako kdyz hledate reseni problemu s windows: nejaci lidi co do toho vubec nevidi davaji random odpovedi.

Ještě před Delphi frčela FoxBase/FoxPro a její potomek Visual FoxPro leckde jede i dnes:-)

Ano, s Foxkou jsem si také užil své, u nás na českolipsku dodnes frčí programy postavené na starém dobrém PC Fandu, které po vyřešení komunikace s moderními USB tiskárnami slouží naprosto spolehlivě.

A ruku na srdce, mě jako malému živnostníkovi by podobné řešení dostačovalo také. Používám Libre Office, ale stejně dobře by mi stačila kombinace GTK aplikací Abiword/Gnumeric nebo na TQT postavených KWord/KSpread z mého oblíbeného prostředí Trinity desktop.

Ale co naplat, mám rád novinky, takže Arch Linux, Odoo a v poslední době stále více pokukuji po Rustu, člověk se holt v dnešní době nemá šanci nudit ani vteřinku.

PC-Fand, ach srdce mi poskočilo, kdeže jsou ty doby rozverného mládí :)
A nemyslím to ironicky.

Dovolil si někdo Rustem vpáčit do vrstev, kde je "Javovo"? Namátkou jsem zkoušel hledat něco většího, třeba zrovna ERP, ale v Rustu nic, co by překročilo sotva skelet.

Myslím, že Rust se zaměřuje na jiný typ SW, s Javou si IMHO do zelí moc nelezou (aspoň zatím).

A je ta ambice vůbec realistická?

Open-source ERP systém – pozor není váš, když si jej stáhnete. Řada lidí se domnívá, že když budou mít systém s otevřeným kódem, tak kód vlastní a zbaví se závislosti na dodavateli softwaru.

Rozšířování open-source ERP je však velmi omezené z následujících důvodů:

• Složitost – ERP systemy jsou královskou třídou v programování software. Dodavatelé disponují dlouholetým know-how a velkým náskokem, který dosud nemohla open-source komunita přinést. Tyto open-source dále zaostávají ve funkčnosti.

• Náklady na přizpůsobení – mají-li být open-source řešení ve firmě funkční a přinášet efektivitu, musí být často podstatně přizpůsobena. Při zapojení externí softwarové firmy vznikají dodatečné náklady. Při použití interního IT dochází k velke spotřebě času a interním střetům zájmů.

• Nejsou sponzoři – nedostatek solventních sponzorů

Shrnutí:

Zdrojový kód mít je fajn, ale zajistí mi to spolehlivý běh a takové řešení, které opravdu bude dobře sloužit? Závislosti na dodavateli se nezbavím, ale vytvořím si ji tak či tak.

Podívejte se také zda má nový informační system API a hlavně jak je toto API zdokumentované. Vyznáte se v této dokumentaci, tak abyste mohli například rychle napojit externí software či službu?

Podívejte se na také trendy zejména low-code řešení. Kvalitní low-code (či částečně i no-code) mají top tvůrci ERP softwaru. Low-code umožňuje udělat řadu zakázkových úprav rychleji. I tady je ale často doporučován specializovaný dodavatel.

Pokud uvidíte, že má systém má kvalitně zdokumentované API a ideálně webhooks, je to možná dobrá volba, pokud budete potřebovat cosi napojit (a to pravděpodobně jednou přijde).

Moc děkuji za vynikající příspěvek, ano, zcela s ním souhlasím. Osobně jsem nesmírně vděčný všem lidem, kteří svojí práci a čas dávají k dispozici zdarma. A je zde krásně vidět posun od malých aplikací přes rozsáhlé kancelářské balíky až po dnešní oteřená, přesto nesmírně komplexní ERP řešení a nesmím zapomenout na operační systémy. Proto mě Odoo a podobné aplikace tak zaujaly a možnost si takový systém doma nainstalovat a otestovat je něco, co jsem dříve nemohl.

Na druhou stranu takové nadšení nelze převést do firemního prostředí, je jasné, že zkušenosti výrobců letitých řešení jsou nenahraditelné. Jak píšete, náklady na přizpůsobení jsou velmi důležité, osobně jsem se nesetkal s nasazením ERP, které by nebylo nutno přizpůsobit (a nelze nepřehlédnout odpor mnohých uživatelů přizpůsobit se novému řešení).

Nemám dostatečné programátorské zkušenosti, abych mohl podrobně zkoumat API, rozumím, určitě vyvstane potřeba propojení např. s bankou či s dalším interním systémem (vlastní zkušenost, při zavádění SAP R/3 již manažeři nepovolili dokoupení modul výroby a nahradit stávající, takže IT oddělení muselo řešit propojení dvou aplikací). Proto bych velmi rád slyšel o reálném nasazení Odoo nebo jiného otevřeného ERP ideálně v menší firmě "na zelené louce" pouze s využitím kapacit interních vývojářů (obávám se však, že si velmi, velmi dlouho počkám).

Low-code a no-code se dnes velmi skloňuje, osobně jsem se s těmito platformami setkal na informačním webu školitelů Czechitas, jsem moc zvědav, kam se posunou. I Odoo nabízí LowCode Platform, určitě budu sledovat.

Mě na jakémkoliv, tedy i OpenSource ERP řešení příjde jako podstatný a téměř hlavní problém, že se uživatelé nejsou ochotni přizpůsobit tomu kterému sw. a výsledkem je nekonečný kolotoč očekávání, úprav a frustrace.
U mě Odoo i ERPNext slouží hlavně k přípravě výroby elektronických zařízení, nákupu součástek, dodání k zákazníkovi a vyfakturování.
Neřeším účetní finesy, protože účetní dostane balík vydaných faktur a navstupuje si je sama. Export by šel udělat, ale nestála o něj.
U obou sw. jsem se přizpůsobil stylu jak to dělají oni, jen si to rozšířil o drobné reálie ČR.
Ale nasazovat to ve větší firmě bych se to neodvážil.

No máít něco, co mi vystavý periodicky fakturu tak cca 100 klientům bytového družstva a zaúčtuje platbnu z bnanky v ABO by se mi líbilo... Nějaké video na Youtube nechcete udělat?

Dal by se na to použít https://docs.erpnext.com/docs/v13/user/manual/en/accounts/subscription ?
Jen ten ABO konektor by se musel udělat.

Video nejsem schopen udělat, teď navíc chcípam s Covid :(

Co se týká nasazování Odoo ve větší firmě - asi to nebude tak tragické, vzhledem k tomu, že to používá například Toyota (minimálně ve Francii).
Nicméně jak bylo zmíněno výše, nasazování ERP do firmy je záležitostí přizpůsobení tohoto ERP pro potřeby firmy. Takže jde spíše o to jestli na daném trhu máte někoho kdo je toho schopen nebo toho jste schopni vy a máte na to dostatek sil. To si musí posoudit každý sám.

Zdravím, systém Odoo, dříve OpenErp jsem už několikrát nasazoval nebo upravoval v Anglii. Takže v čechách nikoli. Ale dokážu si představit, že to bude podobný. Nakonec jsem se rozhodl odoo "opusit" a napsat systém nový, v jazyku Idris2. Zatím šitý na míru pro ecommerce, se zaměřením na integraci s existujícím sw. I tak to trvalo dlouho a ještě na tom pracuju. Co mi vadilo? Když pominu chyby které se najdou až při běhu, je to spíš "filozofie vše v jednom". Což je lákavý slib na který zákazník slyší, protože to opravdu pomůže zefektivnit operace ve firmě, ale v praxi to znamená nahradit specializovaný software, například účetnictví nebo eshop moduly v erp. Od doby kdy jsem začal (rok 2009), odoo udělalo velký posun vpřed. Ale být dobrý v tolika doménách je opravdu těžký i pro velký hráče. Například Netsuite nabízí vlastní ecommerce platformu. Stejně jako odoo. A v praxi? Na stránkách shopify najdete case study o tom, že netsuite modul pro ecommerce nebyl dost rychlý a zákazník přešel k shopify. Další problematická záležitost je samotný vývoj modulů. Kdo ovládá javascrip, html ale i třeba účetnictví zárověn. Ano, je třeba tým lidí ale nároky jsou i tak velké. A není lehké testovat něco izolovaně a pak integrovat. Ale to je můj názor. ... Nicméně potřeba integrace a mít celkový přehled o dění ve firmě zůstavá. Ale aplikace typu "vše v jednom" je jen jedna z možných cest. Ta druhá je založena na skutečnosti, že ERP je "stavový stroj", který hlídá stav rozsáhlého množství zdrojů: v základu zboží a peněz. Ale to by bylo na samostatný článek. Snad jindy.

Tak ten článek z konce příspěvku by mne moc zajímal.

Pekny clanok :) pokial by ste chceli viac info / spytat sa ludi na skusenosti s implementaciou odporucam CZ/SK komunitnu skupinu na FB - https://www.facebook.com/groups/odooczsk

Tedy, že bych se amatérsky zeptal, tak Odoo je zahraniční produkt. Nejde mi o jazykovou lokalizaci, ale a bohužel o tu lokalizaci účetní, mzdovou daňovou ostatně i celkově obchodně právní - a v tomto se to naše prostředí diametrálně liší, a navíc poměrně rychle, díky legislativním změnám rychle mění. Jen že bych připomněl - a vlastně to ještě není ani oficiálně zrušeno, měli jsme tu něco jako EET, a v tom bylo i našim odborníkům a analytikům často nejasné jak určité případy řešit - a to hlavně třeba v online prodejích. Tohle asi autoři Odoo řešit nebudou.
Čili mi z toho vychází, že ty základní ekonomické moduly Odoo, stejně budou nepoužitelné a budou se muset nahradit našimi (které už, krom toho jednoduchého účetnictví) zdarma nebudou - ale o to tak nejde. Čili mi z toho vychází že Odoo pro naše podmínky je jen ta manažerská nadstavba, která z těchto připojených modulů bude tahat agregovaná data a zobrazovat v nějakých grafech?

Ano, data pro účetnictví je potřeba dostat do nějakého českého účetnictví.
Na druhou stranu, plánování výroby, nákupy do skladů, vystavování faktur, servis zařízení a další věci co umí Odoo není vůbec k zahození.

Odoo jako framework
Mohl by někdo ze zkušenějších prozradit, jak hodně se liší či je omezená Community verze v15 a v16 z pohledu vlastního subsystému? A jestli nemá nějaká omezení vlastního vývojového prostředí oproti verzím 8/9?
Používám Odoo jen jako základnu pro psaní vlastních modulů, nepoužívám žádné jejich hotové, takže přidávání a ubírání jejich modulů mě vcelku netrápí.
Teď jedu Odoo 8 a rád bych upgradoval na nějakou výrazně novější verzi (hlavně kvůli Pythonu 3).
Díky.

zajimalo by me jako vyvojare, jak napr. realizuji vytisk faktury. Tato, vlastne takova standardni procedura vypovida dost o tom, jak je takovy framework navrzen. Nenalezl jsem nikde na netu nejake video, kde by to ukazovali.

Ve starších verzích se faktura (resp. všeobecně výstupní data do tisku - PDF report) definovala v xml, v nových nevím. Ale dá se s tím poměrně dobře pracovat, včetně definice vlastního papíru, hlaviček, agregované součty přímo ve formuláři, atd.
Videonávod na PDF report např. zde:
https://www.youtube.com/watch?v=pIevsbkoq-E