Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Struktura rozpočtu, členění položek #3

Open
callidasw opened this issue Jan 27, 2021 · 9 comments
Open

Struktura rozpočtu, členění položek #3

callidasw opened this issue Jan 27, 2021 · 9 comments

Comments

@callidasw
Copy link
Collaborator

Rádi bychom co nejdříve domluvili a zakotvili způsob strukurování rozpočtu na skupiny položek. Zřejmě nejčastěji používaným členěním je hierarchie "STAVBA - OBJEKT - ODDÍL", ale nelze to považovat za dogma.. v praxi se setkáváme s řadou dalších členění, které s pojmy "STAVBA/OBJEKT/ODDÍL" nemají vůbec nic společného. Proto se kloníme k myšlence navrhnout ve formátu ORF strukturování rozpočtu zcela obecně, bez vazby na nějaké konkrétní zažité šablony.

Současná verze schematu deklaruje explicitní elementy "Objekt" a "Dil".. tyto elementy bychom rádi zrušili a nahradili jedním obecným elementem, např. "Skupina" (případně "Uzel, Uroven, Zatrideni") pomocí kterého bude možné definovat libovolné členění rozpočtu, bez fixní vazby na pojmy "STAVBA/OBJEKT/ODDÍL..".

Abychom neztratili možnost jednoznačné interpretace & prezentace dat z dokumentu, bude nutné vybavit elementy "Skupina" informací o tom, co vlastně reprezentují, rozlišením typu skupiny.. aby bylo jasné, že skupina definuje např. právě stavbu, skupinu objektů, objekt, podobjekt, oddíl, pododdíl.. nebo cokoliv jiného. Jako vhodný postup se nám jeví deklarovat u skupin odkaz na definiční záznam typu skupiny. Definiční záznamy typů skupin budou sepsány pod elementem "ORF\Definice" jako podřízené elementy "TypSkupiny".

Pro lepší pochopení konceptu jsme do repozitáře nahráli jednoduchý příklad, soubor "navrh_cleneni_rozpoctu.xml"

@martin1cerny
Copy link
Member

Tuto myšlenku podporuji.

@kluchLProconom
Copy link
Collaborator

My po uvážení - budeme muset změnit drobně logiku tuto myšlenku nakonec taky podporujeme - dá nám daleko větší flexibilitu s návrhem a možnostmi jak nakládat s různými rozpočty

@callidasw
Copy link
Collaborator Author

Děkujeme za reakce.. pokud se na konceptu obecných třídících skupin shodneme, rádi bychom rozpracovali ještě jedno související téma: pokud se bude v rozpočtu vyskytovat třídící skupina určitého typu se stejným kódem vícekrát, pak platí předpoklad, že její význam, název a další vlastnosti ve smyslu definice jsou ve všech výskytech stejné..? Doufáme že ano, v našem systému to tak je.. raději upřesním otázku: pokud bude v rozpočtu více stavebních objektů, je dost pravděpodobné, že budou obsahovat podobné nebo shodné stavební díly (oddíly, kapitoly), například 001 - Zemní práce, 002 - Základy, 003 - Svislé konstrukce. Shodneme se na tom, že význam kódů 001, 002, 003.. reprezentuje ve všech stavebních objektech totéž? Nepřipouští některý ze systémů možnost, že by kód "001" v jednom stavebním objektu znamenal "Zemní práce" a v jiném objektu něco jiného?

Pokud je význam skupin jednoznačný, navrhujeme upravit koncept tak, aby názvy skupin a další vlastnosti ve smyslu definice byly uvedeny pouze jednou, jako detailové elementy v sekci definic, tedy pod elementem "ORF\Definice\TypSkupiny\Skupina". Vizuální orientaci v dokumentu to sice trochu ztíží, na druhé straně to sníží datovou redundanci a zamezí výskytu nejednoznačných interpretací.

Pro lepší pochopení opět přikládáme jednoduchý sample, soubor "navrh_cleneni_rozpoctu2.xml"

@kluchLProconom
Copy link
Collaborator

Za mě nevím, jestli je k tomu důvod a vzdáme se části flexibility. Můžu určitě říct, že na první zamyšlení jsem nenašel případ, kdy by rozpočet obsahoval jinak se jmenující entity, ale každopádně, proč to uživatelům neumožnit? Má to nějakou výhodu? Náš systém určitě umožňuje zmíněnou flexibilitu a nebudeme ji měnit. Znamenalo by to tedy, že kvůli této vlastnosti by byla část našich rozpočtů nevyexportovatelná do ORF.

@callidasw
Copy link
Collaborator Author

Navržená úprava flexibilitu členění rozpočtu nijak neomezí.. jde jen o to, že název a další definiční vlastnosti skupin budou sepsané na jednom místě, jako přehled (soupis) použitých skupin, bez ohledu na to, kde a kolikrát byla skupina v dokumentu použita. Z hlediska datové čistoty je to dobré řešení - zamezí nejednoznačným interpretacím (stejný kód, různé významy) a redundanci ůdajů (opakovaný výpis stejných názvů u skupin, které se v dokumentu vyskytují vícekrát)

@DanielCihelka
Copy link

K návrhům:

  1. Stavba-objekt-část-díl oproti návrhu "Skupin": Částečně rozumíme, že by to dalo větší flexibilitu uživatelům při strukturování rozpočtu, na druhou stranu struktura, která se nyní používá je právě stavba - objekt - část a pak díly - poddíly - položky rozpočtu. Takto je dlouho dobu zažité jako mainstream (bylo před vznikem vyhlášek) a je tak postavená i vyhláška č. 169/2016 Sb. Pokud bychom měli přistoupit na navrhovanému flexibilnějšímu členění, potřebujeme vědět podrobnosti k účelu tohoto členění, podložené příklady i požadavky z praxe (co to členění bude věcně vyjadřovat; v přiloženém příkladu v XML není uvedeno jiné členění). Důvodem je budoucí vzájemná kompatibilita při přenosech dat přes tento formát nejen na úrovni těchto skupin, ale i dalších informací, které jsou na tyto skupiny navázány. Nebo se jedná jen o názvosloví?

  2. Skupina určitého typu se stejným kódem vícekrát: máme podobný postoj jako Proconom. Části objektů mohou mít stejný kód, ale odlišný název, apod.

@callidasw
Copy link
Collaborator Author

Otázku členění rozpočtu pojďme vyřešit co nejdříve, přijde nám to jako základní a zásadní věc.. souhlasíte, abychom to zahrnuli do plánu jednání na středu 3.2.2021..?

@martin1cerny
Copy link
Member

Souhlasím.

@kluchLProconom
Copy link
Collaborator

Také souhlasím

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants