Scénář 1: Zpracování prodejní zakázky 1 - PŘÍPRAVA KMENOVÝCH DAT

Na úvod scénáře několik obecných poznámek. V celém jeho průběhu nevyplňujte čísla vytvářených dokladů. Systém je vyplní za vás podle pravidel interního přiřazení. Systém si také po dobu jednoho přihlášení pamatuje posledně použité hodnoty (čísla dokladů, organizační údaje ...). Pokud zpracování scénáře přerušíte a odhlásíte se, přijdete o tuto výhodu. Nic se sice neděje, ale některé údaje už budete muset doplňovat ručně (podle uvedené tabulky a vašich poznámek), nebo je vyhledávat přes matchkód. Celá řada údajů se vám také doplní automaticky z kmenových dat. Výjimečně se může stát, že některé hodnoty budou oproti popisu chybět a budete je muset (většinou po chybovém hlášení) doplnit ručně.

Zvláštní pozornost věnujte datumům. Celý scénář se v praxi odehrává v průběhu poměrně dlouhého období a tak někdy nemusí být dnešní datum nabídnuté systémem tou nejvhodnější volbou. Na druhou stranu, vytvoření všech dokladů scénáře během jednoho dne je sice zvláštní, ale nemělo by to generovat žádné chyby, takže na možnost "posouvání" datumů nebudete explicitně upozorňováni. S jedinou výjimkou - v systému se totiž dá účtovat jen do otevřeného účetního období (v současně době to je únor a březen 2002, ale nastavení se může změnit). Pro účetní operace proto vždy zvolte nějaké datum z těchto dvou měsíců. Podrobnější informace najdete v jednotlivých krocích. 

1.1  Role a organizační uspořádání

Koncepce rolí je klíčová pro pochopení způsobu práce se systémem SAP R/3. Každý pracovník ve firmě provádí určitou specializovanou činnost a je proto zařazen na určité specifické organizační místo, které je popsáno několika organizačními údaji. Protože je uspořádání každé firmy věcí vysoce individuální, snaží se SAP R/3 k němu přistupovat maximálně pragmaticky a flexibilně. To co si tradičně představujeme pod organizační strukturou, tj. hierarchii útvarů uspořádanou podle míry rozhodovacích pravomocí, odsouvá do modulu personalistiky, ve kterém je možné definovat nejrůznější organizační plány, pracovní místa a na ně přiřazené pracovníky. 

Pro oblast logistiky, kterou se v našem scénáři budeme zabývat především, tak systém potřebuje pouze několik základních charakteristik, které se definují v Customizaci, mají svůj "logistický" důvod, a které je možné na charakteristiky "personalistické" poměrně volně namapovat. Tak například závod je pro logistiku "místo", na kterém probíhá plánování materiálových potřeb (MRP). To, že si pro jeho hladký chod vytvoříme deset různých závodů, ale ještě nemusí znamenat, že budeme muset vytvořit deset útvarů závod s příslušnými řediteli. 

Údaje, které budete zadávat v jednotlivých krocích připraveného scénáře jsou právě tyto "logistické" charakteristiky. Jejich zadáním říkáte sytému, že chcete pracovat s tou a tou "logistickou" částí firmy. V praxi by se slušelo ještě připojit: a mohu s ní pracovat, protože k tomu mám "personalistické" oprávnění. Přes namapování těchto dvou popisných struktur se totiž dá výborně vyřešit správa oprávnění. V praxi se také tam, kde pracovník může pracovat jen s jednou z organizačních jednotek, její zadávání potlačuje. To v našem školním systému bohužel není z důvodů administrativní náročnosti možné. Více informací o "logistických" organizačních úrovních naleznete vždy u příslušných popisů rolí.

Koncepce rolí je také klíčová pro a také pro způsob uspořádání tohoto scénáře. Žádný proces ve firmě totiž nevykonává jediný člověk. Pracovníci si předávají jednotlivé úkoly přesně podle rozsahu svých kompetencí. Obchodník přijímá zakázku, plánovač zabezpečuje hladký chod výroby, nákupčí se stará o plynulé zásobování materiálem. Systém jim musí umožnit efektivní komunikaci a to znamená především zoptimalizovat předávání dokladů. 

Každá transakce, která tvoří rozhraní mezi dvěma rolemi, proto má mimo jiné také robustní funkce pro vyhledávání dokladů z předchozích kroků daného procesu. A protože je každý krok specifický je i toto vyhledávání specifické, tj. pokaždé jiné. Popisovat je by bylo extrémně náročné a tak se pro veškeré reference dokladů předpokládá znalost jejich čísel. V praxi se čísla dokladů používají v podstatě jen tehdy, když dojde k nějakým problémům a je třeba se odkázat na konkrétní doklad.

1.2  Kmenová data

Kmenová data jsou páteří každého dobrého informačního systému. Představují relativně stálé údaje, které stojí v pozadí za každou prováděnou operací a představují pro ni informační podporu. Za nezbytné minimum se dá považovat uchovávání informací o materiálech a obchodních partnerech, v praxi se ale ukládá mnohem větší množství údajů, například o cenových podmínkách, přepravních dispozicích atd. Dá se říci, že čím více času a prostředků se věnuje na údržbu kmenových dat, tím lépe a hladčeji pak probíhají vlastní konkrétní obchodní operace.

V SAP R/3 každý kmenový záznam obsahuje řádově desítky polí a soustřeďuje do sebe veškeré údaje, které potřebují jednotlivá oddělení společnosti. Jeho struktura proto musí kopírovat „organizační strukturu“ firmy, protože například dvě různé organizační jednotky (např. závody) si mohou chtít evidovat dvě různé sady údajů (např. parametry pro ocenění). Je proto rozložen do několika „tabulek“, z nichž každá obsahuje údaje specifické pro ten který organizační útvar. Globální data jsou uchovávána v tabulce na úrovni klienta, data vztahující se k celé společnosti v několika tabulkách na úrovni účetních okruhů atd. Struktura kmenového záznamu je proto jen částečně hierarchická. Pro to, aby se daný materiál, zákazník atd. mohl v dané části organizační struktury používat, musí mít definovány příslušné záložky. 

Kmenový záznam se většinou vytváří postupně. Prvnímu založení se říká založení (create) a vzniká při něm číslo kmenového záznamu. Je to spíš jeho kód, protože může obsahovat libovolné "běžné"  znaky. Systém jej doplní buď automaticky interně, nebo jej může zvolit uživatel ručně. V tomto případě si většinou firma nadefinuje určité pojmenovávací mnemotechnické konvence. Každé další doplnění je už jen rozšíření (extend) kmenového záznamu. Doplňuje k záznamu další, napoprvé nezaložené dílčí tabulky. Výhodou je snížení počtu záznamů v nepoužívaných dílčích tabulkách, které by měly pouze implicitní hodnoty, nevýhodou pak trochu práce navíc. Nové kmenové záznamy  je možné zakládat s referencí na již hotové záznamy. Do nového záznamu se zkopírují všechny hodnoty ze zadaných organizačních úrovní, které dávají smysl (nebudou se například kopírovat adresy nebo stavy zásob).

Většinu údajů v záznamu lze v průběhu času měnit. Výjimkou jsou některé základní řídící údaje, jako je účtová skupina u obchodního partnera, nebo druh materiálu u materiálu, jejichž změna není možná, nebo podléhá přísným pravidlům. Všechny změny se uchovávají. Staré hodnoty se nemažou, ale umisťují do speciálních souborů (change documents) mimo kmenový záznam. Ten pak obsahuje jen aktuální údaje, ale jeho „platné znění“ k libovolnému okamžiku je možné kdykoliv zrekonstruovat. Neuchovávají je jen některé objemné položky (např. vysvětlující texty) a odvozené údaje (např. úrovně skladových zásob).

Další důležitou částí funkcionality je možnost plánování změn. Plánované hodnoty se opět uchovávají mimo kmenový záznam a jsou viditelné pouze pomocí speciálních transakcí. Uživatelé tak mohou například postupně kompletovat hodnoty nového záznamu , nebo se vzájemně informovat o chystaných změnách. Z plánovaných změn se stanou změny aktuální provedením tzv. aktivace. Pomocí kmenových záznamů je také možné provádět blokování určitých operací, tj. znemožnění jejich provedení, pokud se v nich objeví odkaz na daný kmenový záznam. Nejčastěji se blokuje placení dodavatelům, protože nám například dluží peníze v jiné oblasti podnikání, ale lze takto zabránit i odeslání objednávky, nákupu určitého materiálu nebo fakturaci. Smazání záznamu probíhá ve dvou krocích. Po označení k vymazání se fyzické odstranění provede prostřednictvím archivační procedury.

Systém dále poskytuje celou řadu dalších možností, jako je např. hromadná správa záznamů, ale zároveň zůstává natolik flexibilní, aby se dal přizpůsobit individuálním požadavkům každého zákazníka. V praxi totiž až 50% implicitních polí zákazník nevyužije a naopak potřebuje evidovat údaje, které v kmenových záznamech chybí. V Customizaci jde proto dodefinovat další pole, tabulky a vazby a provést celou řadu dalších nastavení. Při práci s kmenových záznamem materiálu SAP R/3 v současné době preferuje  tzv. views – záložky, které například uživatelé operačního systému Windows dobře znají. Seskupuje do nich jednotlivá pole podle jednotlivých oddělení a umožňuje intuitivní navigaci mezi nimi. 

1.3  Kmenový záznam materiálu

Materiál je v SAP R/3 hodně univerzální pojem. Spadá pod něj cokoliv, co je nakupováváno, vyráběno, skladováno, prodáváno nebo z nějakých důvodů evidováno. Alternativně se někdy používá možná vhodnější termín artikl. Je natolik univerzální, že je potřebný ve všech částech organizační struktury firmy a tak se jeho záložky vážou v podstatě na všechny organizační prvky, od závodu, přes nákupní organizaci až po oblast odbytu a účetní okruh. Každé view obsahuje kód a popis materiálu, základní měrnou jednotku a tlačítko pro informační údaje (kdo view založil, měnil, mazal, …). Další údaje už jsou většinou specifické a váží se ke konkrétní organizační jednotce, která bývá zobrazena hned pod obecnými údaji a je nutné ji vybrat při spuštění transakce nebo nejpozději při v stupu na view. 

Při zakládání kmenového záznamu materiálu musíme zvolit jeho druh. Ten determinuje chování systému v jednotlivých transakcích, omezuje možnost zakládání určitých záložek a výběr jednotlivých polí. Mezi hlavní druhy patří: suroviny (ROH) - jsou  externě nakupovány, skladovány a nelze je prodávat tradičním způsobem; hotové výrobky (FERT) - jsou vyráběny, prodávány, nakupovat je lze jen pokud je to v jejich kmenovém záznamu povoleno;  služby (DIEN) - nemohou být skladovány, mají specifický způsob účtování; obchodní zboží (HAWA) - nemůže být vyráběno, od hotových výrobků se liší také čísly účtů při  jeho vyskladnění/příjmu na sklad. Připraveny jsou i speciální druhy materiálu, např. konfigurovaný materiál (KMAT), polotovar (HALB) a další.

1.4  Role: Správce kmenových dat

Některým velkým firmám se vyplatí vyčlenit si pro správu základních kmenových dat specialistu, který pak kmenová data upravuje podle požadavků z jednotlivých oddělení. Alternativně si mohou jednotlivá kmenová data udržovat sami uživatelé, kterých se týkají. Pak je ale potřebné přesně rozdělit příslušné kompetence a například také domluvit konvence pro přiřazování čísel kmenových záznamů, pokud je systém negeneruje interně.

Správce kmenových dat musí mít samozřejmě detailní přehled o celé "logistické" organizační struktuře společnosti. Protože by se nám ale její popis překrýval s ostatními rolemi, tak se zde zmíníme jenom o její "účetní" části, protože pro účetnictví nebyla zpracována samostatná role. Zde je základním prvkem účetní okruh. Představuje účetní jednotku, za kterou se sestavuje účetní závěrka. Každý doklad, který zachycuje operaci mající dopad do účetnictví, musí také obsahovat údaj o tom, do kterého účetního okruhu patří. Tento údaj však většinou není nutné zadávat ručně, protože se dá dovodit z ostatních organizačních údajů. Ty jsou totiž jednoznačně přiřazovány (vazbou 1 : N) pod účetní okruh.  

Transakce MM01 - založení kmenového záznamu materiálu

1.5  Doklady

Doklady jsou protipólem kmenových dat. Představují záznamy o jednotlivých provedených operacích a proto se právě na kmenová data odkazují. Všechny doklady mají podobnou strukturu. Tvoří ji:

• hlavička se  základními informacemi o prováděné operaci, které jsou pro všechny položky stejné. U prodejní zakázky mezi ně patří například údaje o obchodním partnerovi,

• několik položek, které tvoří jeho jádro a obsahují všechny podstatné údaje. Ve zmíněné zakázce jde o materiály si zákazník objednává, jejich množství, datum dodání a cena. Některé doklady používají ještě jemnější rozčlenění položek, například právě prodejní zakázka umožňuje ke každé položce dodefinovat množstevní rozvržení dodávek v čase. 

Každá položka je relativně samostatná. Do dokladů, vlastně s trochou nadsázky seznamů položek, je seskupena s jinými položkami jen kvůli snadnému zpracování. Údaje v hlavičce platí pro položku pouze tehdy, pokud v ní není uvedeno jinak. Tak například není nutné vyplňovat vícekrát společné organizační údaje, nebo je možné si při vstupu do transakce přednastavit implicitní hodnoty pro položky. Pokud tedy v SAP R/3 uvažujeme o dokladech, měli bychom uvažovat vlastně o jejich jednotlivých položkách. Toto uspořádání také umožňuje flexibilní zakládání dokladů s referencí, tj. rychlé převzetí  jednotlivých položek, a to i z více jiných dokladů do dokladu právě vytvářeného. 

Pro práci s dokladem systém SAP R/3, stejně jako u kmenových dat, používá záložky - jednu sadu pro údaje hlavičky, druhou sadu pro detaily jednotlivých položek. Většina transakcí vám na základní obrazovce nabídne nějakou jejich podmnožinu s tím, že k úplné sadě záložek se dostanete buď přes aplikační menu nebo pomocí tlačítek umístěných přímo v obrazovce. Ty vás přepnou buď obecně na celou sadu záložek (viz tlačítka Detaily pro položku, Detaily pro hlavičku) nebo přímo do konkrétní záložky (viz tlačítka Rozvržení nebo Podmínky). Novější transakce pak mají na základní obrazovce záložky všechny a umožňují jejich de/aktivaci (viz tlačítka Skrytí dat/Detailní data). Protože by byla práce s detaily položek zdlouhavá je mezi tyto dvě sady záložek umístěn ještě přehled položek. Obsahuje v jednoduché tabulce stejné údaje jako detaily položek. Je méně přehledný, ale rychle se do něj dají doplnit potřebné údaje.  

Transakce MB1C - naskladnění materiálu

1.6  Kmenový záznam obchodního partnera - dodavatele a odběratele

Obchodní partneři jsou jakékoliv fyzické nebo právnické osoby, o nichž je třeba evidovat v informačním systému nějaké údaje. Rozdělují se do 4 hlavních skupin podle toho, v kterém modulu se s nimi pracuje: dodavatelé v nákupu, zákazníci v prodeji, vlastní zaměstnanci v personalistice a ostatní osoby všude. Každá skupina má svou vlastní strukturu kmenového záznamu a své vlastní transakce, které ji zpřístupňují. Pokud partner spadá do více kategorií (typicky zákazník může být i dodavatelem), je nutné pro něj vytvořit oba kmenové záznamy a až následně je propojit odkazem. Speciálním kmenovým záznamem je záznam tzv. jednorázového partnera, který se v systému uchovává pouze jeden a v operacích zastupuje partnery, pro které se nevyplatí uchovávat speciální kmenový záznam. Systém u něj eviduje menší počet údajů.

Dodavatelé jsou ti obchodní partneři, kteří nám dodávají zboží nebo služby, nebo na těchto dodávkách alespoň nějakým způsobem participují. Dostávají zaplaceno za odebrané zboží, odesílají faktury atd. Vedle externích dodavatelů je možné vytvářet záznamy i pro dodavatele interní (distribuční centra). Kmenové záznamy dodavatelů potřebuje útvar prodeje a finančního účetnictví a tak tento záznam respektuje organizační uspořádání v těchto oblastech. Skládá ze dvou oddělených částí pro nákup (členění podle nákupní organizace) a finanční účetnictví (podle účetního okruhu) a všeobecných údajů. Vedle transakcí pro jeho centrální správu existují i speciální transakce s omezeným přístupem k datům daného útvaru. Kmenový záznam tak dokonce může být založen i jen v jednom z nich, ale v praxi se to nedoporučuje. Je také možné dodefinovat ještě podrobnější členění záznamu, například podle jednotlivých závodů nebo dílčího sortimentu dodavatele.

Pro každého dodavatele je při zakládání kmenového záznamu třeba zvolit parametr účtová skupina. To je  hodně nešťastně přeložený výraz „account group“, protože s účetnictvím nemá v podstatě nic společného. Určuje strukturu záznamu (řazení obrazovek, výběr datových polí, povinné hodnoty), způsob jeho číslování (interně systémem / externě uživatelem) a množinu rolí, do kterých může daný partner vstupovat. Právě podle „nejsilnější“ povolené role jsou pojmenovány některé předdefinované účtové skupiny (0001 dodavatel, 0006 objednací adresa a další). Vlastní kmenový záznam pak obsahuje řadu polí, z nichž jsou povinné pouze pole měna a účet hlavní knihy.

Mezi standardní role patří: dodavatel materiálu  („může“ úplně všechno),  příjemce objednávky (tomuto partnerovi je odesílána objednávka), výstavce faktury (od něj je očekávána faktura a na jeho účet se účtuje) nebo odlišný příjemce platby. V kmenovém záznamu jednoho partnera (zejména toho s účetní skupinou dodavatel) je pak možné uvést odkaz na partnera jiného. V transakcích se pak bude preferovat tato speciálnější role a pokud je k ní přiřazeno více partnerů, systém je automaticky nabídne k výběru (objednané zboží je tak možné například zaplatit někomu úplně jinému, samozřejmě pokud si to dodavatel takto přeje). Role tak umožňují alespoň trochu popsat organizační strukturu velkých partnerů.

Odběratelé (zákazníci) jsou ti obchodní partneři, kterým dodáváme zboží nebo služby, nebo na těchto dodávkách alespoň nějak participují. Opět mohou být i interní (anglicky „sites“). Zvláštním postavení má záznam tzv. spotřebitele. Existuje v systému pouze jeden a obsahuje pouze obecná data, protože pro drobné zákazníky není třeba evidovat jejich individuální údaje. Účtové skupiny a role fungují podobně jako dodavatele. Mezi hlavní role patří zadavatel zakázky („nejsilnější role“), příjemce materiálu (dostane dodávku), příjemce faktury a plátce. Na rozdíl od nákupu je zde však možné vytvářet pomocí speciálních transakcí tzv. hierarchie zákazníků, které modelují organizační uspořádání daného partnera a umožňují například mnohem propracovanější řízení cen. O vlastní data se tentokrát dělí s útvarem finančního účetnictví útvar prodeje. Všeobecné údaje (adresa, bankovní spojení ale i třeba centrální místa vykládky) doplňují informace vázané na zvolený finanční okruh (účty, platební podmínky, pojištění ..) a oblast odbytu  (ceny, expediční údaje, role).

Kmenové záznamy zaměstnanců vede modul personalistika (pouze pokud není implementována, je možné je zakládat i prostřednictvím modul prodej). Mezi ostatní partnery patří například kontaktní osoby (v oblasti prodeje se údaje o nich ukládají do kmenového záznamu zákazníka, v nákupu mají svůj kmenový záznam).