Oprávnění: Úvod do organizační struktury

Každý uživatel v systému pracuje na nějaké pracovní pozici, v nějaké funkci, a to určuje funkční

omezení jeho oprávnění. Funkční omezení se zaměřuje na to, jestli uživatel pracuje například

v personalistice, skladu, výrobě nebo například ostraze objektů, a podle toho autorizuje (omezuje)

aplikace, které uživatel pro svou práci používá. Zároveň každý uživatel v systému patří k nějaké

právní entitě, k nějakému týmu, do nějaké geografické lokace nebo na konkrétní pracoviště. Podle

této své organizační příslušnosti potřebuje být uživatel oprávněn k práci s daty, za kterou jeho

organizační jednotka zodpovídá. Tento uživatel by ale naopak neměl mít přístup k datům, za které

zodpovídá jiná organizační jednotka. Když to velmi zjednodušíme, určuje pracovní pozice s jakými

nástroji uživatel pracuje, zatímco organizační příslušnost určuje, s jakými daty uživatel pracuje.

Vezměme si jako příklad roli "Skladník". Naše organizace provozuje 4 sklady a je požadavkem vedení, aby si různé geografické lokace navzájem nemanipulovaly skladem. Proto vytvoříme čtyři kopie role skladník, pro každou lokalitu zvlášť.

Jak organizační struktura v oprávněních funguje? Vysvětlíme si alespoň několik základních pojmů.

Funkční (technická) a organizační oprávnění

Oprávnění se strukturují pomocí autorizačních objektů („authorization objects“) a autorizačních polí

(„authorization fields“). Většina autorizačních polí jsou funkční nebo je můžeme také nazvat

technické. Jejich hodnoty jsou pro konkrétní aplikaci jednoznačně definovány jejím účelem. Proto

mohou být tyto hodnoty připravené již v SU24 popisu aplikací (čtěte „Co a proč je SU24 popis

aplikace“). Pokud je aplikace například určena pouze k náhledu, budou téměř všechna pole ACTVT

mít hodnotu 03 (případně také 08).

Příklady technických oprávnění:

• Transakce SE11 přistupuje k databázové tabulce AGR_1251, kontroluje proto oprávnění pro tabulku A (objekt S_TABU_NAM, TABLE=AGR_1251)

• Transakce XD03 zobrazuje data zákazníka, kontroluje proto oprávnění pro aktivitu zobrazení (objekt F_KNA1_GEN, ACTVT=03)

Organizační oprávnění fungují trošku jinak. Jednak je nemůžeme specifikovat v transakci SU24,

protože každá role musí mít svoje vlastní nastavení organizační struktury. V datech role jsou

technická oprávnění (v tabulce AGR_1251) fyzicky oddělena od organizačních oprávnění (tabulka

AGR_1252). A konečně se dostáváme k tomu, co jsme popsali již v příkladu nahoře, že například role

„Skladník“ by měla fungovat vždycky stejně z hlediska nástrojů (aplikace pro skladníky budou vždy a

všude stejné), ale skladníci v jednom areálu společnosti a v jiném areálu společnosti si navzájem

nemohou přistupovat k datům nebo je dokonce měnit.

Příklady organizačních oprávnění:

• Transakce ME23N potřebuje číst data závodu (“Plant”), kontroluje proto oprávnění pro přístup k závodu (objekt M_BANF_WRK, WERKS=$WERKS)

• Transakce XD03 zobrazuje data zákazníka, kontroluje proto oprávnění pro příslušný účetní okruh („Company code“) (objekt F_KNA1_BUK, BUKRS=$BUKRS)

Přehled organizačních polí najdeme v transakci SUPO. Zde máme možnost i nějaká existující

technická pomalu změnit na organizační. Protože to znamená velmi výrazný zásah do způsobu, jak

připravujeme oprávnění, taková změna by měla být velmi pečlivě promyšlená předtím, než se do ní

pustíte.