Open martin1cerny opened 3 years ago
My aktuálně podporujeme v PCM pouze zaokrouhlování množství - ceny vždy zaoukrouhlujeme na 2 des místa - běžná praxe úč. systémů, ale pro podporu formátu klidně implementujeme možnost zaokrouhlit jednotkovou i celkovou cenu.
Za mě ještě důležitá otázka, jestli se zaokrouhluje, nebo zobrazuje na daný počet des míst. Tj. pokud mám v ORF zadáno 5,33244 počítám s tímto číslem a výsledek zobrazuju zaokrouhlený (takto počítá proconom) nebo zaokrouhlím a pak počítám
Tcena - je to pro jednotkovou cenu položku, nebo pro celkovou cenu položky, nebo je to jen obecná definice ceny? Pokud je to jen obecná definice ceny, potom s totalDigits value="18" souhlasíme, a s xs:fractionDigits value="2" nesouhlasíme, dle dřívějšího návrhu by mělo být 5.
TZaokrouhleni – pokud obecně, ok. Pak ale potřebujeme vydefinovat zaokrouhlení pro typy viz dřívější excel.
K způsobu výpočtu (reakce na dotaz pana Kluha): Je potřeba počítat s počty desetinných míst, které jsou uvedeny v ORF.
Tady je spíše důležitá věc – při průběžné fakturaci (když se položka rozdělí na x fakturačních částí a každá se zaokrouhlí; pak vzniká na konci rozdíl v součtu zaokrouhlených částek oproti původní částce dané v rozpočtu ve smlouvě). K tomu budeme muset najít společné stanovisko.
K způsobu výpočtu (reakce na dotaz pana Klucha): Je potřeba počítat s počty desetinných míst, které jsou uvedeny v ORF.
Počítat zajisté, ale mají se data do ORF zaokrouhlit, nebo se jen v koncových SW zobrazuje zaokrouhlení?
K otázce fakturace - u nás je to tak, že se vždy fakturuje celá JOC položek, která se může zaokrouhlovat vždy stejně a pouze se mění zaokrouhlení množství - vzniká menší možnost numerických chyb. Jsme ale ochotni v rámci memoranda doprogramovat podporu jiného zaokrouhlování cen - jde jen o způsob následného výpočtu - tak abychom se shodovali.
Návrh: Sepsat stručnou metodiku zaokrouhlování jako součást dokumentace.
Dořešit počet desetinných míst https://github.com/KoncepceBIM/ORF/blob/master/ORF.XML/Schema/ORF_v0.1.xsd#L219