ALTUS VARIO a postřehy k němu

Práva a potíže s nimi

V následujícím textu ti, kdo používají informační systém Altus Vario budou souhlasit a pro ty kdo by si tento systém chtěli pořídit je to informace o jednom z problémů tohoto informačního systému.

Ve Variu se práva nastavují pro každého uživatele a to ve třech rovinách:
  1. na úrovni systému jako celku (zda má uživatel práva nastavení a možnost vytváření firem)
  2. na úrovni agend (zda má možnost vytvářet knihy, změnit nastavení agendy apod.)
  3. na úrovni knih (klasická práva čtení, zápisu, výmazu apod.)

A jako další věc - každá firma má svoji databázi, své moduly a v rámci nich agendy a v nich libovolné množství knih. Přidělování práv funguje stylem:

  1. Založit uživatele a přiřadit práva úrovně 1 a 2. To je bezproblémová činnost.
  2. Přiřadit (nebo změnit) uživateli práva pro jednotlivé knihy - tedy na úrovni práv třetí. A tady už nastává zádrhel.

Pokud tedy přiřazujete nebo měníte práva uživatele, přičemž tento uživatel má mít přístup do více modulů a máte mnoho knih, tak se prostě uklikáte (přičemž nemáte možnost vidět přehledně přiřazená práva pro jednotlivé uživatele). Jestli si myslíte, že jsem nepřemýšlel o zprogramování, tak přemýšlel. Ale bohužel firma Altus má pro každý modul definována další dodatečná práva (což by problém nebyl), ale tato dodatečná práva jsou natvrdo zabudována jako konstanty v modulu. Čili nezjistíte jejich hodnotu (Altus ji neuveřejňuje, dalo by se tyto hodnoty zjistit, ale to je práce na několik perných dnů či týdnů) a navíc existuje riziko změny hodnoty těchto konstant při nových verzích. Zkoušel jsem to z druhé strany - protože používáme SQL server, tak jsem zkusil použít role - bohužel však ty nepřebíjejí práva uživatelů VARIA... Také jsem zkoušel vytvořit si vzorové zaměstnance pro různé druhy činností (něco jako role) přímo ve Variu a pomocí kopie uživatelských práv jsem pak zkoušel nastavit práva konkrétnímu uživateli. Tady ovšem dochází k tomu, že přidělení práv není stejné, prostě najednou zjistíte, že v některé knize vzorový uživatel má práva a skutečný uživatel od něj odvozený je nemá!

Další problém vidím v tom, že nejsem schopen si zobrazit práva jednoho uživatele přehledně. To si prostě musíte prohlížet oprávnění jednotlivých knih... A k tomu se přidává to, že pokud odstraníte uživatele (třeba při jeho odchodu ze zaměstnání), tak jeho práva na jednotlivých knihách zůstávají - samozřejmě se uživatel nepřihlásí, ale znepřehledňují se práva a rozhodně to není OK.

Takže: pokud se chystáte, že vaše firma se bude rozrůstat, že budete pracovat s více firmami, že zaměstnanci budou fluktuovat, že bude docházet k častým organizačním přesunům - prostě, že budete často nastavovat  a měnit práva, tak Vario nedoporučuji (pak doporučuji systém, který umí pracovat s databázovými rolemi). Vario se hodí pro pár zaměstnanců, kteří mají v podstatě pořád stejnou funkci a práva se jim nastavují velmi zřídka.

Počty databází

Vario používá pro každou firmu a každý "modul" vlastní databázi. Samozřejmě se dá diskutovat o tom, proč že VARIO používá pro každou firmu svoje datové soubory. Ale jednu zřejmou nevýhodu to má – pokud se vaše společnost skládá z poboček (holding třeba), jenž jsou samostatně sledovány a účtovány, tak je problém, jak například sjednotit data za celou firmu. A také pokud si uvědomíte, že každá firma používá minimálně deset modulů, tak si spočítejte kolik databází vznikne… Jediná věc pro kterou to mohli udělat jsou práva, protože pokud by byla jedna databáze, kde každý záznam je rozlišen podle firmy, pak by se těžko nastavovala práva – ale to by se dalo udělat výběrem záznamů pouze dané firmy.

V této souvislosti si musíte uvědomit, že pro každou firmu musíte zakládat datové soubory  - ať už MDB nebo na SQL serveru. Samotný systém to nedělá, takže je to na vás.

Dokumentace a názvosloví

Dokumentace, a to jak pro uživatele, tak pro vývojáře je na mizerné úrovni. Ač jsou nabízeny funkce a procedury z VARIO.MDA k použití, tak nějak jsem nikde nezjistil co funkce a procedury vlastně nabízejí (typ a význam parametrů spolu s vysvětlením funkce - a to ať přímo v popisu funkce knihovny nebo ve zvlášť dokumentaci). Musíte si to prostě ozkoušet - v dokumentaci na jejich webu je pouze pár nejpoužívanějších funkcí vysvětleno.

Firma ALTUS používá názvy objektového modelu MS ACESS, tak jak byly navrženy firmou Microsoft, mnohdy v jiném významu. Např. modul je používán v klasickém významu modulu programového kódu, ale také ve významu samostatné aplikace systému VARIO. Proč tedy nenazvat aplikaci podsystémem systému VARIO - tak to bývá obvyklé.

Klíče a relace

Překvapilo mě, že firma Altus používá pro primary (a tím i foreign) klíče textové položky (např. firma = 30 znaků). Musí to nutně zpomalovat práci JETu nebo SQL serveru, nehledě na problémy při přejmenování hodnoty primárního klíče. Tuto chybu jsem udělal jednou a přidělala mi spoustu problémů. Navíc to zkomplikuje pozdější možnost replikací. Vždycky používám automatické počitadlo, a to i pro hodnoty číselníků... Proč nepoužili u aplikace Adresář tabulku FIRMA:ADRESA ve vztahu 1:N? Nyní mají napevno ve struktuře tabulky firem několik adres (Adresa, Adresa2, Sídlo, Zboží doručit, Obchodní rejstřík). Tím nejen, že porušují pravidla normalizace databází, tím komplikují variabilitu systému. Každý by si mohl nadefinovat číselník adres a vyplňovat jen adresy, které používá.

Pro vývojáře - ošetření chyb

Vytváříte-li doplňky pro Vario, tak počítejte s problémy při odlaďování. Samotnému mi chvíli trvalo než jsem zjistil, že doplněk nedělá to co má, ač se tváří, jako že vše je v pořádku (objevovaly se například chyby v modulu, aniž by byl doplněk vyvolán).  A další čas mi trvalo než jsem přišel na to proč: i když striktně používáte zachycování chyb ve svých procedurách, tak zachytávání chyb přebírá Vario - to by samozřejmě nebylo nic špatného - ale bohužel oni používají (zřejmě všude) příkaz RESUME NEXT, čímž se dále pokračuje v programu, aniž byste cokoli zaregistrovali...

Ještě jsem neměl možnost zjistit, zda je to standardní chování v MS Access, že zachytávání chyb doplňku přebírá vlastní aplikace. Až to zjistím, tak doplním tento článek.

Ukládání vypočítávaných hodnot do tabulky

Do tabulky dokladů se ukládají i vypočítávané položky! Ve všech publikacích i návodech je to věc silně nedoporučovasná. Jen Bůh a firma Altus ví co je k tomu vedlo...

Účetní sestavy a zaokrouhlování

Narazili jsme nedávno na problém zaokrouhlování v účetních sestavách (výsledovky, rozvahy, výkazy zisků a ztrát) a zjistili jsme, že číslo, které má být 228 je na jedné sestavě 227 a na druhé 228. Dobrá napsal jsem na Altus a čekal jsem na odpověď. Normálně bych předpokládal, že se za chybu omluví (což o to chyby děláme všichni) a pošlou opravu. Prdíčky naší babičky! Napsali nám, že chyba vzniká tím, že na jedné ze sestav se již bere údaj ze zaokrouhlených údajů a na druhé z originálních a že si máme na druhé sestavě ručně přičíst 1 a bude to v pohodě, že to společnosti tak normálně dělají. Účetní z toho byli na odpis - myslel jsem, že jim budu muset dávat umělé dýchání! Takže takovéto účetnictví může být jen na dvě věci (doplňte si sami).

Licencování

Nevím zdali je to smlouvou nebo je to u firmy Altus standardní  postup: že se platí aktualizační poplatek je u každého softwaru normální - máte možnosti stahování oprav a levnějšího nákupu upgradů. Ovšem pokud neplatíte, nemáte nárok na uvedené, ale programy běží dál. Ne tak u Altusu - licence jsou vystaveny na rok a musíme platit aktualizační (nemalé) poplatky. Teprve na základě plateb nám prodlouží licenci. Dobrý co?

Tomáš Havetta : Programátoři

>http://blog.vyvojar.cz/havetta/archive/2007/01/29/program-to-i.aspx

O jakémpak systému nám to pan Havetta asi tak mluví ve druhé části svého článku? Hádejte - můžete třikrát. To podstatné shrnul do pár vět.

Posted by Igor Pechanec Wednesday, March 11, 2009 6:01:00 PM Categories: Postřehy, názory
Igor Pechanec © 2016-2017, all rights reserved