Scénář 1: Zpracování prodejní zakázky 2 - PRODEJ

2.1  Role: Obchodní zástupce - prodej

Obchodní zástupce je první klasickou rolí, se kterou se seznámíte. Obchodní zástupci komunikují se zákazníky, přijímají od nich poptávky, posílají jim nabídky a hlavně s nimi uzavírají prodejní zakázky. Kromě toho se starají o cenovou politiku firmy a kontrolují plnění svých zakázek. K dispozici mají i některé základní marketingové nástroje, možnost uzavírání dlouhodobých smluv atd.

Organizační uspořádání prodeje musí umožnit rozdělení práce mezi jednotlivé obchodní zástupce nebo jejich skupiny, umožnit jim evidovat si o zákaznících vlastní údaje a zároveň tyto údaje v případě potřeby sdílet. Skládá se proto ze tří "popisných charakteristik" - prodejní organizace, cesty odbytu a oboru - které je možné vzájemně libovolně kombinovat. Co tyto charakteristiky znamenají je poměrně volné a záleží na každé firmě, co si pod nimi bude představovat. Jejich kombinací vznikne tzv. oblast odbytu, základní struktura pro klasifikaci zákazníků. Kromě zmíněného rozdělení práce, a z něj plynoucí správy oprávnění, je toto rozčlenění používáno i pro nejrůznější analýzy výkonnosti.

Prodejní organizace je především právní hlavičkou vůči zákazníkům. Je proto hlavním členěním odbytu a velmi často koresponduje s geografickým rozčleněním útvaru prodeje. Je také hlavním prvkem, na který se vážou cenové podmínky. Bývá běžné, že každá prodejní organizace má právo si stanovit svou vlastní cenovou politiku. Cesta odbytu popisuje jednotlivé odbytové kanály firmy - přímý prodej, velkoobchod, Internet. Můžete pomocí ní řídit, co se smí jakým způsobem prodávat a samozřejmě také pružně ovlivňovat cenové podmínky. Tentokrát spíše přes slevy a přirážky. Obor odpovídá řadě výrobků a bývá využíván především pokud má organizace divizionální uspořádání.

V rámci tohoto organizačního uspořádání se pak zakládají jednotlivé kmenové záznamy a vytvářejí prodejní doklady. Každý zákazník může mít  založen svůj kmenový záznam pro několik oblastí odbytu, každému materiálu je v jeho kmenovém záznamu přiřazen jednoznačně jeho obor. Každý vytvářený doklad musí obsahovat identifikaci své oblasti odbytu. Protože by takovéto detailní členění mohlo v praxi někdy svazovat ruce, protože by například nešlo pomocí jednoho dokladu prodávat výrobky z více oborů nebo cest odbytu, je možné používat i tzv. všeobecné cesty odbytu a všeobecné obory, které právě toto umožní.

Prodej samozřejmě musí spolupracovat i s ostatními útvary ve firmě. Vůči finančnímu účetnictví je tato vazba zachycena jednoznačným přiřazením každé prodejní organizace k jednomu účetnímu okruhu (vazbou 1 : N). Každý prodejní doklad povinně obsahuje údaj o cestě odbytu, takže je z něj zřejmé, do kterého účetního okruhu se má zaúčtovat. Vazbu na logistiku představuje především závod, případně sklad a expediční středisko. Vyplňují se v zakázce a určují, odkud chce obchodník odebrat prodávané zboží. Tato indikace je důležitá především pro výrobu (nákup), která se musí postarat, aby toto zboží v daném místě a čase bylo k dispozici a také pro expedici, která zajistí jeho odeslání zákazníkovi. Mapování na personalistiku umožňuje skupina prodeje.

2.2  Vztah mezi organizační strukturou, kmenovými daty a doklady

Stejně jako kmenové záznamy i jednotlivé doklady respektují organizační uspořádání. Zaměstnanec, který je vytváří, vždy musí doplnit příslušné organizační parametry. V praxi se samozřejmě také automaticky zkontrolují jeho oprávnění. Doklad pak obsahuje vedle svých vlastních údajů také odkazy na určitá kmenová data, která musí být definována  ve  vybrané části organizační hierarchie. Kmenová data tak mohou fungovat jako restrikce, protože pokud nejsou pro danou část organizační struktury definována, tak se příslušné operace prostě nemohou provádět. Pokud například není založen určitý kmenový záznam materiálu pro daný závod, tak se v něm materiál nemůže vyrábět ani skladovat.

Organizační údaje se doplňují jak do hlavičky dokladu, kde jsou většinou povinné a zadávají se ručně, tak do jednotlivých položek, kam je zpravidla načte systém z kmenových dat a často povinný charakter nemají. Typickým zdrojem takových hodnot může být kmenový záznam materiálu, ve kterém může být uložen například preferovaný závod, nebo expediční středisko. Totéž se může objevit i v kmenovém záznamu odběratele. Důvodem je to, že zatímco hlavička identifikuje část organizační struktury, ke které se vztahuje aktuálně prováděná operace, položky často obsahují i údaje o tom, co se bude dít v příštích krocích. U zmíněné zakázky se expediční středisko vztahuje až k okamžiku vyskladňování materiálu, objevit se může už ale i v poptávce.

Kmenová data fungují ale především jako zásobárna implicitních údajů, které systém do dokladu automaticky načítá. Povelem k tomu je mu stisknutí klávesy nebo tlačítka Enter, které má v SAP R/3 mnohem větší dopad než v jiných systémech. Po jeho stisknutí se totiž spustí algoritmus, který v závislosti na tom, odkud byl vyvolán, natáhne do dokladu implicitní hodnoty z relevantních kmenových záznamů (ale také třeba z předchozích dokladů, na které byla provedena reference), doklad zkontroluje a zobrazí případná chybová hlášení. Údaje z kmenových záznamů v naprosté většině případů fungují opravdu jen jako implicitní hodnoty, takže se v dokladu dají ručně přepsat.

2.3  Způsob práce s doklady

Existuje určitý nepsaný "standard", jak v systému pracovat s doklady tak, aby se minimalizoval počet zobrazených chybových hlášení. Nejprve vyplňte vstupní obrazovku. Na ní můžete vyplnit organizační údaje, které se vážou na hlavičku dokladu. Po stisku Enteru se doplní do dokladu a už vám nedovolí vybírat kmenová data z jiné organizační části. Ve vlastním dokladu pak vyplňte povinné údaje z hlavičky a opět stiskněte Enter. Do hlavičky dokladu se natáhne všechny implicitní hodnoty, které systém dokázal najít s tím, že pokud najde pro určité pole více variant, ze kterých si "nedokáže" vybrat, zeptá se na vaši volbu ve speciálním okně. Pokud jste nevyplnili některé povinné pole a neexistuje pro ně implicitní hodnota, objeví se vám chybové hlášení a systém vás donutí pole doplnit. Nakonec zadejte povinné údaje do jedné nebo více položek a stiskněte Enter potřetí. Opět se provede načtení implicitních hodnot a kontrola povinných polí s případnými okny pro výběr z více hodnot a chybovými hlášeními. Tentokrát se doplnili z kmenových dat a z údajů v hlavičce hodnoty do zadaných položek.

Pokud se od tohoto postupu odchýlíte, v podstatě se nic neděje. Riskujete ale, že vás systém pomocí chybových hlášení donutí zadat hodnoty v "jeho" pořadí a navíc, a to je horší, nemusí správně natáhnout do dokladu všechna data, se kterými scénář počítá. Pokud například na vstupní obrazovce nevyplníte organizační údaje, systém se na ně zeptá při prvním stisku Enteru uvnitř dokladu a ve speciálním okně nabídne už pouze ty hodnoty, které odpovídají zadaným kmenovým datům. Vše je v tomto případě v pořádku. Jiná situace nastane, pokud už jste zpracovali položky a uvědomíte si, že implicitní hodnoty, které se do nich natáhly z hlavičky jsou špatně například proto, že jste zapomněli opravit údaj, který si tam systém sám doplnil při druhém stisku Enteru. Speciálně často se to stává u datumů. V tomto případě nestačí opravit údaj v hlavičce a stisknout Enter, protože tato nová hodnota už se do položek nedoplní. Údaj musíte opravit přímo v položkách, v jejich detailním zobrazení.

Transakce VA11- založení poptávky

2.4  Cenové podmínky 

Stanovení cen je v SAP R/3 hodně komplexní úlohou. Především je třeba zdůraznit, že ceny v nákupu a prodeji fungují sice podle stejných principů, práce s nimi je ale přece jen trochu odlišná. V prodeji se totiž počítá s aktivním přístupem tvorbě cen a tak je položen důraz na jejich centralizaci do jediného místa. V nákupu se naopak ceny spíše přebírají od dodavatelů a tak se upřednostňuje pružnost při jejich "přepisování" do systému. Cenové podmínky doplněné do dokladů zde například mohou automaticky zaktualizovat kmenová data, tzv. infozáznam dodavatele. V prodeji to nejde, infozáznam zákazník-materiál neobsahuje údaje o cenách, ale mimo jiné například číslo materiálu používané zákazníkem.

V prodeji jsou cenové podmínky ukládány do speciálních kmenových záznamů stejného jména. Pro každý z nich je třeba vybrat druh podmínky a její rozsah. Druh podmínky determinuje podobu hodnot, které může podmínka obsahovat. V Customizaci je jich nadefinováno asi sto a dají se dodefinovat další. Zhruba je lze roztřídit do 4 skupin. Ceny definují základní ceny materiálu, přirážky/slevy, přepravné a daně pak nejrůznější přičítané a odečítané položky, které se berou v úvahu při kalkulaci výsledné ceny. Zadat se mohou nejrůznějším způsobem od absolutních hodnot, přes procenta až po jejich vázání na odebraný objem daného zboží nebo celkovou částku zakázky.

Rozsah podmínky určuje pro koho podmínka platí. Vedle časové platnosti od - do se podmínky mohou vázat na materiál,skupinu materiálů,  zákazníka, prodejní organizaci, cestu odbytu nebo na jejich libovolnou kombinaci. Podrobnější (pozor ne výhodnější!) podmínka má samozřejmě přednost. To umožňuje flexibilní řízení cen. Je možné mít různé ceny v různých prodejních organizacích, preferovat určité zákazníky nebo cesty odbytu, řídit sezónní slevy pro určité materiály a podmiňovat je nejrůznějšími dalšími okolnostmi a to na různé úrovni jemnosti. Posledním prvkem při stanovení ceny jsou tzv. kalkulační schémata. Nastavují se v Customizaci a přiřazují jednotlivým zákazníkům a prodejním dokladům. Určují, které podmínky a v jakém pořadí se budou brát v úvahu při výpočtu ceny. 

Při založení libovolného prodejního dokladu se podle zadaného zákazníka a materiálů nejprve natáhnou do položek všechny relevantní podmínky platné k zadanému datumu ceny. Stanoví se cena jednotlivých položek, získané hodnoty se sečtou a přenesou do hlavičky. Zde se případně aplikují další nalezené podmínky, které se vážou na zákazníka nebo doklad jako celek. Podmínky v položkách i hlavičce pak můžete ručně modifikovat, případně přidávat další. Systém dokonce umí rozpočítat hlavičkové podmínky do položek v určitém poměru. Takto zadané podmínky se ale nebudou zpětně doplňovat do kmenových dat.

Transakce VK31- založení cenové podmínky

2.5  Reference mezi doklady

Důvody pro reference jsou tři. Reference umožňují překopírování všech smysluplných hodnot do vytvářeného dokladu a tím eliminují nutnost zadávat je ručně. Takto se například mohou vytvářet nové prodejní zakázky podle údajů ze zakázek starších. Převzít je možné například pracně doplněné individuální cenové podmínky nebo vložené dokumenty. Systémovější ale bývá v takových případech aktualizovat kmenová data. Druhým důvodem je možnost slučování jednotlivých položek v následných dokladech. Zákazník například celý měsíc objednává zboží, ale fakturu chce dostávat jen jednou měsíčně. Slučovat lze jen takové položky, které mají shodné určité klíčové parametry.

Třetím důvodem je vlastní reference mezi doklady v rámci procesu jejich zpracování. Při založení následného dokladu se kromě zkopírování hodnot zaktualizuje i status dokladu předchozího. Odpovědný pracovník tak má přehled o tom, jak daleko pokročilo zpracování procesu, který inicializoval. Aktualizace statusů probíhá na úrovni položek a kromě reference nabídky na poptávku vždy bere v úvahu množství uvedené v dané položce. Následný doklad tak může položku z dokladu předešlého "referovat" plně, částečně nebo vůbec. Názvy jednotlivých stavů se liší doklad od dokladu, ale princip zůstává všude stejný. Je tak možné například zjistit, která zakázka byla vytvořena podle které nabídky, zda vyčerpala celé nabízené množství nebo byla jenom dílčí a jestli byla při jejím vytváření využita nějaká rámcová smlouva.

Celý řetěz provázaných dokladů lze zobrazit z kteréhokoliv z nich tlačítkem Tok dokladů. Speciální obrazovka vám ukáže seznam všech dokladů, které jsou mezi sebou propojeny a jejich statusy. Aktuální doklad je nejvíce vlevo, všechny doklady, které na něj navazují jsou o jednu tečku odsazeny. Odsazení tak indikuje možná omezení při změnách dokladu. Vzhledem k tomu, že určitá rozhodnutí už mají jistou právní závaznost, například odeslání faktury odběrateli, nejdou některé údaje z dokladů po určitých událostech měnit a to buď vůbec nebo jen omezeně. Snad není třeba připomínat, že tok dokladů se vždy váže na jednotlivé položky.

2.6  Rozvrhování expedice

Už na úrovni zakázky je třeba se zákazníkem dohodnout, jaké množství zboží a v jakých termínech od nás požaduje. SAP R/3 navíc umožňuje specifikovat pro každou položku dokladu její rozvržení v čase, tj. určit tzv. dílčí dodávky. Rozvrhování se proto provádí až na úrovni rozvržení a ne položky. Zároveň vlastní dodání zboží zákazníkovi vyžaduje celou řadu dílčích činností s určitými časovými nároky, a tak je třeba určit celou řadu datumů, které představují nejpozdější termíny, kdy se musí s danou aktivitou začít. Zatím budeme předpokládat, že zákazník objednává s dostatečným časovým předstihem a že objednávané zboží je v dostatečném množství na skladě. Budeme se tedy zatím věnovat pouze první fázi rozvrhování. Ta se nazývá zpětné rozvrhování, protože se postupuje od požadovaného data dodání do minulosti a testuje se, zda jsme schopni zákazníkův požadavek splnit.

Nejdůležitějším termínem je proto požadované datum dodání zboží. Od něj odečteme dobu trvání přepravy zboží a získáme datum výdeje materiálu, který představuje okamžik, kdy se firma zbavuje právní odpovědnosti za odesílané zboží, protože zboží fyzicky opouští expediční středisko a zároveň se účtuje o jeho výdeji. Odečtením času potřebného na nakládku získáme nejpozdější datum zahájení nakládky. Do přistavených dopravních prostředku se začíná nakládat zboží, které musí být v tomto okamžiku fyzicky připraveno k odběru. Musí být vhodně zabaleno a přesunuto na místo nakládky. Odečtením časových nároků těchto operací získáme datum přistavení materiálu, které je nejpozdějším termínem, kdy se výrobky musí objevit na skladě z výroby nebo nákupu. Pokud už k dnešnímu dni (datum založení dokladu) výrobky na skladě jsou a datum přistavení materiálu vyjde v budoucnosti, je vše v pořádku a všechny stanovené datumy je možné potvrdit. V dokladu se evidují oba dva datumy, tj. ten požadovaný zákazníkem a ten námi potvrzený. V tomto případě se nebudou lišit.

Transakce VA21- založení nabídky

2.7  Kontrola disponibility (rozvrhování expedice 2)

Kontrola disponibility nejprve provede zpětné rozvržení expedice popsané výše. Pokud se zjistí, že firma není schopná splnit požadavky zákazníka, tj. dodat celé požadované množství v požadovaném termínu,  je třeba provést nějakou korekci tak, aby nebylo nutné zakázku odmítnout. Tentokrát se musí vyjít z možností firmy a rozvrhovat dopředně. Začne se stanovením nejbližšího možného datumu přistavení materiálu, tj. termínu, do kterého je firma schopna požadované množství zboží vyrobit nebo nakoupit, a přičítáním všech zmíněných intervalů se dostaneme až k nejbližšímu možnému datumu dodání zboží zákazníkovi. 

Této fázi rozvrhování se proto říká dopředné rozvrhování. Posunout je možné buď dodávku jako celek, nebo jen její část. Něco se dodá okamžitě z volné zásoby na skladě a zbytek se odešle později. S touto variantou však musí zákazník souhlasit, protože obvykle znamená vyšší přepravní náklady. V jeho kmenovém záznamu, případně v infozáznamu zákazník-materiál navíc musí být realizace částečných dodávek povolena. V dokladu se pak opět uchovávají oba datumy, které se tentokrát budou lišit. Jak původně požadovaný, tak firmou potvrzený. Pokud dojde k realizaci dílčích dodávek, objeví se všechny potřebné informace v detailech rozvržení.

Kontrola disponibility je poměrně složitý algoritmus. Musí totiž brát v úvahu celou řadu informací, nestačí prostě kouknout na sklad, kolik je tam aktuálně zboží. Především se musí rozlišovat volná a zakázkami rezervovaná zásoba (předpokládané úbytky), aby si zboží nepřebíraly navzájem. Pak je třeba zohlednit délky výrobních a nákupních cyklů (předpokládané přírůstky) a také parametry vlastní dispozice (pojistná zásoba, doba obnovy atd.). Proto je v Customizaci možné nastavit, zda a jakým způsobem se bude bude kontrola disponibility pro daný materiál (a závod) provádět. Zda to bude automaticky při každém vytváření nebo  změně zakázky, na vyžádání uživatele nebo vůbec. 

Transakce VA01- založení prodejní zakázky