Integrace finančního provozu CRM a účetního systému. Bc. Pavel Mikula

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Integrace finančního provozu CRM a účetního systému Bc. Pavel Mikula

Vedoucí práce: Ing. Jan Žďárek

Studijní program: Elektrotechnika a informatika strukturovaný magisterský Obor: Informatika a výpočetní technika květen 2009

iv

Poděkování Rád bych poděkoval společnosti NetTravel.cz, s.r.o. za možnost zveřejnění tohoto projektu a Ing. Janu Žďárkovi za aktivní přístup a ochotu při vedení mé diplomové práce. v

vi

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Horoměřicích dne 22. 5. 2009

.............................................................

vii

viii

Abstract This diploma thesis describes analysis and realization of integration CRM with accounting system LCS Helios Orange. The main subject of this work is description of the original system; financial functions transfer analysis and realization of this transfer. The connection is based on SQL stored procedures providing enough functionality for entire accounting. User interface of Helios application is also extended to assume role of the main financial management tool. This document provides valuable information for those who search for a realization of Helios accounting system and existing CRM, e-shop or any other application based on SQL.

Abstrakt Práce popisuje návrh a řešení propojení CRM systému s účetním systémem LCS Helios Orange. Cílem je popsat původní systém, analýzu přenosu funkcí souvisejícími s finančním provozem z CRM do účetnictví a realizaci tohoto přenosu. Propojení je realizováno formou SQL procedur, poskytujících veškeré operace potřebné pro správnou funkci CRM, a úpravami prostředí účetního programu tak, aby plně převzal funkci nástroje pro řízení a kontrolu finančního provozu. Tento dokument je určen všem, kteří plánují propojit CRM, e-shop nebo jinou provozní aplikaci s účetním systémem umožňující přístup k SQL nebo chtějí přizpůsobit a rozšířit funkce LCS Helios Orange podle svých potřeb.

ix

x

Obsah Seznam obrázků

xv

Seznam tabulek

xvii

1 Úvod

1

2 Motivace a vymezení cílů 2.1 Vymezení cílů projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2

3 Popis původního systému 3.1 Struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Evidence plateb . . . . . . . . . . . . . . . . . . . . . . . 3.1.1.1 Tabulka Objednavky . . . . . . . . . . . . . . 3.1.1.2 Tabulka Objednavky_Faktury . . . . . . . . . 3.1.1.3 Tabulka Platby . . . . . . . . . . . . . . . . . 3.1.1.4 Tabulka Platby_Davky . . . . . . . . . . . . . 3.1.1.5 Druhy evidovaných plateb . . . . . . . . . . . . 3.1.1.6 Výpočet ZaplatitCK a ZaplatitKlientovi . 3.1.2 Potvrzování plateb . . . . . . . . . . . . . . . . . . . . . 3.1.3 Evidence faktur . . . . . . . . . . . . . . . . . . . . . . . 3.2 Finance v prodejním procesu . . . . . . . . . . . . . . . . . . . 3.2.1 Finance v CRM . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Poukazy . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2.1 Tabulka Poukazy . . . . . . . . . . . . . . . . 3.2.2.2 Tabulka TypyPoukazu . . . . . . . . . . . . . . 3.2.3 Správa plateb – Platby.mdb . . . . . . . . . . . . . . . . 3.2.3.1 Generování platebních příkazů . . . . . . . . . 3.2.3.2 Další funkce související s prodejním procesem . 3.2.4 Fakturace provize – CRM_Finance.mdb . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

3 3 5 6 6 8 9 10 10 12 16 17 19 20 22 23 23 25 27 28

4 Analýza a návrh řešení 4.1 Účetnictví . . . . . . . . . . . . . . . . . . . 4.1.1 Základní pojmy . . . . . . . . . . . . 4.1.2 Systém dokladů . . . . . . . . . . . . 4.1.3 Účtování . . . . . . . . . . . . . . . . 4.2 Definice způsobu účtování . . . . . . . . . . 4.2.1 Použité účty a řady dokladů . . . . . 4.2.2 Účtování akcí CRM . . . . . . . . . . 4.3 LCS Helios Orange . . . . . . . . . . . . . . 4.3.1 Struktura a možnosti přizpůsobení . 4.3.2 Uživatelské sloupce . . . . . . . . . . 4.3.3 Definované přehledy . . . . . . . . . 4.3.4 Úpravy hlavního stromu – soudečky 4.3.5 Externí akce . . . . . . . . . . . . . 4.3.5.1 Stored procedury . . . . . . 4.3.5.2 Definované přehledy . . . . 4.3.5.3 Externí programy . . . . . 4.3.5.4 Pluginy . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

30 30 30 32 32 34 34 36 41 41 42 43 43 43 44 45 45 45

xi

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

4.4

4.3.6 4.3.7 Návrh 4.4.1

4.4.2 4.4.3 4.4.4 4.4.5

4.4.6

4.4.7

4.4.8

4.4.9

4.4.10

Tiskové formuláře . . . . . . . . . . . . . . . . . . . . . . . . Databázové triggery . . . . . . . . . . . . . . . . . . . . . . . implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura propojení . . . . . . . . . . . . . . . . . . . . . . . 4.4.1.1 Zvolená varianta . . . . . . . . . . . . . . . . . . . . 4.4.1.2 Diskuse ostatních možností . . . . . . . . . . . . . . Rozšíření funkcí systému Helios . . . . . . . . . . . . . . . . Obecné procedury . . . . . . . . . . . . . . . . . . . . . . . . Přechod na měnu Euro . . . . . . . . . . . . . . . . . . . . . Funkce CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.5.1 Transakční zpracování . . . . . . . . . . . . . . . . . 4.4.5.2 Čtení informací . . . . . . . . . . . . . . . . . . . . 4.4.5.3 Evidence faktur od CK . . . . . . . . . . . . . . . . 4.4.5.4 Evidence faktur pro zaměstnavatele . . . . . . . . . 4.4.5.5 Změna stavu objednávky . . . . . . . . . . . . . . . 4.4.5.6 Zápis interní faktury klientovi řady 068 . . . . . . . 4.4.5.7 Platby v hotovosti . . . . . . . . . . . . . . . . . . . 4.4.5.8 Správa plateb . . . . . . . . . . . . . . . . . . . . . . 4.4.5.9 Práce s poukazy . . . . . . . . . . . . . . . . . . . . Správa odchozích plateb . . . . . . . . . . . . . . . . . . . . . 4.4.6.1 Zobrazené informace . . . . . . . . . . . . . . . . . . 4.4.6.2 Ovládání a práce s přehledem Platby . . . . . . . . 4.4.6.3 Generování platebních příkazů – dávek . . . . . . . 4.4.6.4 Další funkce přehledu Platby . . . . . . . . . . . . . 4.4.6.5 Kontrola faktur od CK . . . . . . . . . . . . . . . . Systém fakturace provize . . . . . . . . . . . . . . . . . . . . 4.4.7.1 Režimy spouštění . . . . . . . . . . . . . . . . . . . 4.4.7.2 Vystavování faktur – hsp_FakturaceProvize_CZ/SK 4.4.7.3 Dohledání zakázek na fakturách . . . . . . . . . . . 4.4.7.4 Nevyfakturované objednávky . . . . . . . . . . . . . Fakturace poukazů . . . . . . . . . . . . . . . . . . . . . . . . 4.4.8.1 Režimy spouštění . . . . . . . . . . . . . . . . . . . 4.4.8.2 Vystavování faktur – hsp_FakturacePoukazu_CZ/SK 4.4.8.3 Dohledání poukazů na fakturách . . . . . . . . . . . Události řízené externími triggery . . . . . . . . . . . . . . . . 4.4.9.1 Úhrada faktury . . . . . . . . . . . . . . . . . . . . . 4.4.9.2 Zaúčtování pokladního dokladu . . . . . . . . . . . . Zabezpečení externích akcí a definovaných přehledů . . . . .

5 Případové studie 5.1 Typický průběh prodeje zájezdu . . . 5.1.1 Popis situace . . . . . . . . . . 5.1.2 Řešení . . . . . . . . . . . . . . 5.2 Vystavení faktury pro zaměstnavatele 5.2.1 Popis situace . . . . . . . . . . 5.2.2 Řešení . . . . . . . . . . . . . . 5.3 Změna provize po vystavení faktury . 5.3.1 Popis situace . . . . . . . . . . 5.3.2 Řešení . . . . . . . . . . . . . . 6 Realizace projektu

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 46 46 47 47 49 51 54 61 62 62 62 64 65 66 67 70 72 74 74 74 77 79 83 89 90 90 91 94 94 95 95 97 97 99 99 99 99

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

101 101 101 101 109 110 110 112 114 114 115

xii

6.1

6.2

6.3 6.4

Implementace v jazyce SQL . . . . . . . . . . . . . . . . . . . . 6.1.1 Správa zdrojového kódu . . . . . . . . . . . . . . . . . . 6.1.2 Kritické sekce . . . . . . . . . . . . . . . . . . . . . . . . Systém Helios . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Aktualizace . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Obnovení databáze . . . . . . . . . . . . . . . . . . . . . 6.2.3 Externí akce . . . . . . . . . . . . . . . . . . . . . . . . 6.2.4 Definované přehledy . . . . . . . . . . . . . . . . . . . . 6.2.5 Externí triggery . . . . . . . . . . . . . . . . . . . . . . 6.2.6 Pluginy . . . . . . . . . . . . . . . . . . . . . . . . . . . Problémy související s měnou Euro . . . . . . . . . . . . . . . . Problémy s evidencí úhrad . . . . . . . . . . . . . . . . . . . . . 6.4.1 Automatické přiřazení úhrad bankovním výpisům . . . . 6.4.2 Párování úhrad platebních příkazů a bankovních výpisů

7 Fáze projektu a testování 7.1 Režim testování . . . . . . . . . . . . . . . . . . . . 7.2 Fáze projektu . . . . . . . . . . . . . . . . . . . . . 7.2.1 Zkušební import dat do testovací DB . . . . 7.2.2 Analýza a implementace . . . . . . . . . . . 7.2.3 Kontrolní import dat do testovací DB . . . 7.2.4 Sběr dat v CRM do testovací DB . . . . . . . 7.2.5 Import a sběr dat do produkční DB . . . . 7.2.6 Duální běh CRM . . . . . . . . . . . . . . . . 7.2.7 Duální běh Platby.mdb a přehledu Platby v 7.2.8 Zrušení duálního běhu aplikace Platby.mdb 7.2.9 Finální přechod na nový systém . . . . . . 7.2.10 Spuštění verze s podporou měny Euro . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Heliosu . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

115 115 116 117 117 117 117 118 118 119 119 120 120 120

. . . . . . . . . . . .

122 122 122 122 123 124 124 124 125 125 125 125 126

8 Závěr

127

9 Literatura

129

A Seznam použitých zkratek

130

B Obsah přiloženého CD

132

xiii

xiv

Seznam obrázků 3.1 3.2 3.3 3.4 3.5 3.6

Struktura původního systému . . . . . . . . . . . . . . Přehled tabulek pro evidenci financí . . . . . . . . . . Schéma potvrzování plateb . . . . . . . . . . . . . . . Základní schéma pohybu financí v prodejním procesu . Přehled tabulek pro správu poukazů . . . . . . . . . . Ukázka uživatelského rozhraní aplikace Platby.mdb .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 5 14 18 21 25

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Struktura volání stored procedur z CRM . . . . . . . . . . Zápis nové faktury hsp_ZapisFa_CZ/SK . . . . . . . . . Zaúčtování faktury hsp_ZauctovatFa_CZ/SK . . . . . . Zápis faktury klientovi hsp_ZapisFaKli_CZ/SK . . . . . Ukázka uživatelského rozhraní Heliosu, soudeček Platby Generování platebního příkazu hsp_Davka_CZ/SK . . . . Zápis a storno poplatku za SMS hsp_FixRezaFa_CZ . . Fakturace provize hsp_FakturaceProvize_CZ/SK . . . . Tabulky pro správu poukazů nového systému . . . . . . Fakturace provize hsp_FakturacePoukazu_CZ/SK . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

48 58 59 69 75 81 87 93 96 98

xv

xvi

Seznam tabulek 3.1 3.2 3.3

Číselník stavů objednávek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Druhy plateb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Příklad typických hodnot ZaplatitCK a ZaplatitKlientovi . . . . . . . . . .

7 11 13

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8

Ukázka účtování vydané faktury . . . . . . . . . . . . Ukázka účtování přijaté faktury . . . . . . . . . . . . . Ukázka účtování zápočtu faktur . . . . . . . . . . . . . Přehled použitých účtů . . . . . . . . . . . . . . . . . . Přehled použitých sborníků a řad faktur . . . . . . . . Význam hodnot ve sloupci TabHGlob.FazeEuro . . . . Ukázka účtování faktury pro zaměstnavatele řady 0*1 Ukázka účtování poplatku za SMS k faktuře řady 068

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

33 33 34 35 36 61 66 88

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9

Stav účtování zakázky po zápisu faktury klientovi . . . . . . . . . . Stav účtování zakázky po zápisu pokladního dokladu . . . . . . . . Stav účtování zakázky po zápisu faktur od CK řady 023 a provize Stav účtování zakázky po odeslání první platby do CK . . . . . . . Ukázka účtování uhrazené vydané faktury na provizi řady 0*2. . . Stav účtování zakázky po doplatku klienta . . . . . . . . . . . . . . Stav účtování zakázky po odeslání druhé platby do CK . . . . . . Stav účtování zakázky po úhradě faktury pro zaměstnavatele . . . Stav účtování zakázky po vrácení přeplatku klientovi . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

102 103 104 106 107 108 109 111 113

xvii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xviii

KAPITOLA 1. ÚVOD

1

1 Úvod Pracuji pro cestovní agenturu NetTravel.cz, s.r.o. jako programátor a byl mi zadán samostatný projekt na analýzu a realizaci integrace finančního provozu CRM a účetního systému. Ve společnosti se od jejího založení v roce 2003 průběžně vyvíjí vlastní CRM software, který slouží jako jediný nástroj pro prodejce zájezdů. Implementace a funkce systému se průběžně přidávají a upravují podle aktuálních požadavků na prodejní proces, který je upravován s ohledem na rostoucí velikost firmy, organizační strukturu a množství objednávek. První verze CRM byla aplikace v MS Access sdílená mezi uživateli a datovým úložištěm přímo v souboru MDB. Z pohledu financí byly zpočátku evidovány pouze příchozí platby od klientů (formou textových poznámek v historii objednávky) a v roce 2004 bylo provedeno rozšíření CRM s ohledem na rostoucí objem prodeje a nutnost spolehlivější evidence a správy plateb. V souvislosti s tím bylo datové úložiště CRM umístěno na SQL server a vznikly dva nové SW pro správu financí: CRM_Finance.mdb Aplikace MS Access, která zajišťuje hromadou fakturaci provize za zájezdy a evidenci takto vystavených faktur. Platby.mdb Aplikace MS Access, která spravuje stav všech objednávek, generuje hromadné platební příkazy pro úhradu plateb do CK a sleduje celkový stav financí u objednávek. Později byla se založením call-centra a dalším rozvojem společnosti implementovaná nová verze CRM, založena na architektuře klient-server, v prostředí Delphi1 a dále rozvíjena. Aplikace CRM_Finance.mdb i Platby.mdb jsou ovšem pouze průběžně aktualizovány a k zásadní reimplementaci nedošlo ani se založením dceřinné společnosti Lastminute.sk, s.r.o. na Slovensku2 . Udržovaný model tak trpí několika zásadními nedostatky, které jsou komplikací úspěšného chodu společnosti. Mezi hlavní problémy patří například: • omezení počtu uživatelů Platby.mdb na jednoho (a to včetně Slovenska), • nemožnost provozovat aplikace MS Access vzdáleně (mimo lokální síť SQL serveru), • výkonnostní problémy aplikací MS Access s velkým počtem záznamů (desítky tisíc), • neúčtuje se o proběhlých platbách, • fakturace provize probíhá ve 3. aplikaci (CRM_Finance.mdb) bez hlubších kontrol, • chybí zde účetní kontrolní mechanismy. Obě společnosti, NetTravel.cz, s.r.o. i LastMinute.sk, s.r.o., mají zakoupenou licenci na účetní systém LCS Helios Orange3 , který byl využíván pro vedení běžného účetnictví. Tento SW obsahuje, kromě velkého množství základních funkcí, také širokou podporu pro zákaznická rozšíření a umožňuje přidávat nové funkce na úrovni uživatelského rozhraní i SQL. Tato vlastnost byla v době výběru nového účetnictví jedním z hlavních kritérií, aby v budoucnu mohl být realizován tento projekt.

1

Objektově orientované vývojové prostředí společnosti Borland Obě organizace využívají stejné systémy a data mají uložena ve společné databázi. 3 http://www.helios.eu/ 2

2

KAPITOLA 2. MOTIVACE A VYMEZENÍ CÍLŮ

2 Motivace a vymezení cílů Hlavní motivací k realizaci tohoto projektu jsou body uvedené v sekci 1. S rostoucími objemy v hlavní sezóně je již organizačně neúnosné, aby veškeré platby do CK a klientům pro Českou republiku i Slovensko spravoval pouze jeden uživatel aplikace Platby.mdb. Tento SW navíc trpí výkonnostními problémy a veškeré optimalizace se dostaly až na své hranice. Z manažerského pohledu je zásadním problémem skutečnost, že se neúčtuje o žádných transakcích souvisejících s prodejem zájezdů. Tento fakt omezuje možnosti zpětné kontroly pouze na data zadaná do systému a nezabraňuje například situaci, kdy peníze z banky odejdou dvakrát kvůli problémům s odesláním platebního příkazu přes webová rozhraní bank nebo chybou obsluhy.

2.1

Vymezení cílů projektu

Cílem tohoto projektu je provést analýzu stávajícího systému, navrhnout způsob, jakým bude systém napojen na účetnictví a toto propojení realizovat. Úkolem je implementovat všechny funkce původního systému popsané v části 3 tak, aby se pro běžné uživatele (prodejce zájezdů) CRM aplikace nezměnila a nebyl ovlivněn prodejní proces. Současně by měl účetní systém převzít všechny funkce aplikací CRM_Finance.mdb a Platby.mdb. Důležitým bodem je úprava rozhraní Heliosu tak, aby z pohledu uživatele co nejvíce odpovídal aplikaci Platby.mdb, která navíc trpí výkonnostními problémy a prostor pro další optimalizace1 byl již vyčerpán.

1

Databázový dotaz hlavního okna byl přesunut z aplikace MS Access do SQL view, bylo provedeno rozdělení přednastavených filtrů do samostatných dotazů aby došlo ke zjednodušení podmínek WHERE, proběhla optimalizace databázových indexů a další.

KAPITOLA 3. POPIS PŮVODNÍHO SYSTÉMU

3

3 Popis původního systému Jak bylo zmíněno v úvodu, prodejní proces je založen na vlastní implementaci CRM systému ve stejnojmenné aplikaci CRM. Ta zajišťuje všechny funkce potřebné pro prodej zájezdů, komunikaci s klienty, práci s objednávkami a evidenci plateb u objednávek. Pro evidenci plateb je klíčová tabulka Platby popsaná v části 3.1.1. Ta eviduje všechny proběhlé finanční operace u každé objednávky.

3.1

Struktura

Z technického pohledu je CRM komplex aplikací a systémů, které spolupracují na několika úrovních. Samotné CRM, kromě funkcí pro správu objednávek a financí, obsahuje například propojení na telefonní systém call-centra, nástroje pro jednotné elektronické vyplňování cestovních smluv všech CK, systém pro správu emailové komunikace včetně komplexního generování emailů podle přednastavených šablon a další rozšíření pro zvýšení efektivity i úspěšnosti prodeje. Pro účely této diplomové práce se dále budu zabývat pouze částmi systému přímo souvisejícími s prodejním procesem a návazností na finance. Z tohoto pohledu, jak naznačuje obrázek 3.1, jsou základními bloky systému: Server PC na kterém běží veškerá serverová část CRM kromě úložiště emailů, Mailserver fungující pouze jako úložiště příchozích emailů o proběhlých platbách z bank, Banka jako zástupce všech bank v České Republice i na Slovensku, CK jako zástupce všech CK – zde zjednodušeně pouze jako příjemce faktur za provizi. Technickým základem CRM je server s MS SQL 2005, ve kterém jsou založené databáze CRM, Helios_cz_001 a Helios_sk_001. Tyto databáze nejsou na úrovni SQL nijak významně propojeny, kromě procedury na přenos ID objednávek (čísel zakázek1 ) a ručně spouštěného, jednosměrného přenosu faktur na provizi. Na stejném serveru dále běží, jako IIS webová aplikace v prostředí ASP.NET, aplikace označovaná jako DSP2 . DSP představuje serverovou část topologie klient–server a zprostředkovává komunikaci se všemi CRM aplikacemi. DSP neobsahuje téměř žádnou aplikační logiku a implementuje pouze přenos dat s datovou knihovnou použitou při implementaci vlastní CRM aplikace, autorizaci uživatelů a funkce, které nemohou být implementovány na klientovi (zamykání záznamů apod.). CRM nepřistupuje přímo k SQL kvůli zajištění větší bezpečnosti (nepřístupnosti SQL serveru ze vzdálených lokalit), umožnění komprimace přenášených dat a lepšímu oddělení aplikační logiky od datového zdroje. Vlastní CRM aplikace pak komunikují s DSP jak po lokální síti LAN, tak přes internet ze vzdálených lokalit (pobočky v České Republice i na Slovensku, přístupy z domova). V lokální síti je umožněna automatická autorizace na základě spolupráce Active Directory, IIS a NTLM ověřování. Ze vzdálených sítí je pak vyžadováno jméno a heslo, které se používá pro šifrované otevření spojení. Přímo s SQL dále komunikují v síti LAN aplikace založené na technologii MS Access. První z nich je aplikace Platby.mdb, která spravuje veškeré odchozí platby a slouží jako hlavní nástroj pro správu financí souvisejících s prodejem zájezdů. Hlavním úkolem aplikace je, podle předdefinovaných pravidel, nabídnout k úhradě objednávky čekající na úhradu a podle výběru uživatele vygenerovat hromadné platební příkazy. Uživatel poté tyto příkazy ručně odesílá 1

Primární klíč z tabulky CRM.dbo.Objednávky se nazývá „ID“ a je používán jako jediný identifikátor objednávky. V Heliosu je ekvivalentní údaj označován jako „číslo zakázky“ a liší se od hodnoty primárního klíče tabulky Helios_CZ/SK_001.dbo.TabZakazka, který se jmenuje shodně „ID“. 2 Data Service Provider

4


Manuální zpracování « Server - PC » SQL, IIS

CRM Datová komunikace

IIS DSP

LAN, WAN HTTP, TCP/IP

SQL

« Banka » Internetbanking « Mailserver - PC »

Schránka

Služba CRMSync

SQL

Zasílání informací o platbách emailem SMTP

Internetbanking

IMAP

Platby.mdb

SQL DB: CRM

Hromadný platební pĜíkaz

ODBC TCP/IP LAN CRM_Finance.mdb

SQL DB: Helios_cz_001 DB: Helios_sk_001

Faktura na provizi

Export faktur

Obrázek 3.1: Struktura původního systému

« CK »


«table» Platby_Davky -«PK»ID : Integer -UcetNT : String -Vytvorena : Date -Odeslana : Date -Poznamka : String

0..1

0..*

«table» Platby -«PK»ID : Integer -«FK»id_Objednavka : Integer -«FK»id_Davka : Integer -«FK»id_User : Integer -«FK»id_Poukaz : Integer -«FK»id_Faktura : Integer -Team : Integer -Typ : Char -TypPlatby : Char -Vytvorena : Date -Odeslana : Date -Provedena : Date -PlatbaOK : Boolean -UcetNT : String -UcetCK : String -UcetKlient : String -VS : String -Pozn : String -Castka : Double

5

«table» Objednavky -«PK»ID : Integer -«FK»id_Stav -ProvizeHned : Boolean -ProvizeBezDPH : Double -ProvizeSDPH : Double -CenaCelkem : Double -StornoPoplatek : Double -ZaplatitCK : Double -ZaplatitKlientovi : Double -... 0..* 0..1 0..*

1

«table» Objednavky_Faktury -«PK»ID : Integer -«FK»id_Objednavka : Integer -Vytvorena : Date -Vytvoril : Integer -Platit : Boolean -Cislo : Long -Splatnost : Date -Castka : Double -Pozn : String

0..1 0..*

Obrázek 3.2: Přehled tabulek pro evidenci financí přes internetová bankovnictví do bank a v systému potvrzuje odeslání těchto dávek. Funkce Platby.mdb jsou podrobněji rozepsány v sekci 3.2.3. Důležitou úlohu v prodejním procesu hraje potvrzování přijatých plateb na základě údajů z banky. Převážná většina plateb je pravidelně ručně kontrolována přes internet banking jednotlivých bank, což je náročné na lidské zdroje a zřizování přístupů do bank dalším osobám. Proto se do vývoje zařadilo také rozšíření, které tento proces automatizuje (v rozsahu možností jednotlivých bank). Některé banky jsou schopné zasílat informace o proběhlých transakcích emailem. Bohužel to nejsou zdaleka všechny, a zdaleka ne všechny tuto informaci zasílají online v době převodu peněz. I přesto bylo přínosné implementovat službu CRMSync. CRMSync je systémová služba Windows běžící na hlavním serveru, která zajišťuje automatické podpůrné procesy spojené s prodejem v minutových intervalech. V souvislostí s financemi zajišťuje kontrolu schránek pro příjem emailů z bank protokolem IMAP a zpracování těchto emailů pro potvrzování i zápis nových plateb (viz 3.1.2). Druhou aplikací napojenou lokálně přímo na SQL jsou CRM_Finance.mdb. Ty zajišťují generování faktur na provizi podle pravidel rozepsaných v části 3.2.4, evidenci a tisk těchto faktur. Detail faktury obsahuje funkci, která umožňuje jednosměrný přenos faktury do Heliosu aby položky nemusely být opisovány ručně. Problém tohoto spojení je jak v jeho jednosměrnosti (žádné změny provedené v účetnictví nejsou promítnuty zpět do CRM_Finance.mdb), tak v duplicitní evidenci takto vystavených faktur. Kromě faktur na provize slouží aplikace také k vystavování faktur pro zaměstnavatele klientů, kteří touto formou hradí části zájezdů svým zaměstnancům. Tyto faktury mají pouze informativní charakter. 3.1.1

Evidence plateb

Základním místem, ve kterém jsou uloženy informace o objednávkách, je stejnojmenná tabulka Objednavky, jak naznačuje diagram 3.2. Na Objednavky se váží faktury od CK popsané v sekci 3.1.3 a Platby. Tabulka Platby_Davky pak slouží pouze pro sdružování hromadných platebních příkazů, jak je popsáno v části 3.2.3.

6


3.1.1.1

Tabulka Objednavky

V diagramu 3.2 jsou u tabulky Objednavky naznačeny pouze atributy související s financemi, celá tabulka obsahuje několik desítek sloupců. Pro účely sledování financí se kromě jedinečného ID využívají dva stavové sloupce id_Stav a ProvizeHned. Ty mají přímý vliv na způsob, jakým se budou u objednávky počítat klíčové hodnoty ZaplatitCK a ZaplatitKlientovi (viz 3.1.1.6). Tabulka Objednavky obsahuje mj. následující sloupce: ID je jediný jedinečný identifikátor platby, který je používán pro identifikaci objednávky na všech úrovních včetně komunikace s klienty. id_Stav je vzdáleným klíčem do číselníku c_Stavy, možné hodnoty jsou popsané v tabulce 3.1. ProvizeHned slouží pouze jako příznak, jakým způsobem bude uhrazena provize z prodeje zájezdu. Při hodnotě ProvizeHned=1 (true) se do CK hradí celková cena zájezdu snížená o výši ProvizeSDPH, v opačném případě se hradí celková cena a provize je cestovní kanceláří uhrazena až na základě fakturace provize (viz 3.2.4). ProvizeBezDPH vyčísluje provizi bez DPH a slouží pouze pro účely fakturace. ProvizeSDPH vyčísluje provizi s DPH a kromě fakturace slouží i pro výpočet částky k úhradě do CK při ProvizeHned=1. CenaCelkem je celková cena zájezdu, od které se odvíjí výše většiny plateb. StornoPoplatek zastupuje hodnotu CenaCelkem v případě, že došlo ke stornu zájezdu3 a klient je povinen CK uhradit storno poplatek za zrušení smlouvy. ZaplatitCK je vypočítaná hodnota udávající stav financí vzhledem k CK. Kladná hodnota značí, že NetTravel dluží do CK. Záporná naopak, že CK dluží NetTravel. ZaplatitKlientovi je vypočítaná hodnota udávající stav financí vzhledem ke klientovi. Pokud je hodnota kladná, NetTravel dluží klientovi a naopak. Během prodejního procesu prochází objednávka na základě akcí prodejců různými stavy. Aktuální stav objednávky je uložen ve sloupci id_Stav a má zásadní vliv na způsob výpočtu financí. Stavy do 35 jsou z pohledu financí nezajímavé, od stavu 35 se začínají pohybovat platby a ve stavu 100 je objednávka uzavřena jako úspěšně prodaná. Stavy větší než 200 označují stornované objednávky. Obecně může přijít platba v libovolném stavu, protože objednávka se může i ze stornovaného stavu opět obnovit. Podobně od objednávky mohou platby odcházet z různých stavů na základě historie objednávky (vracení přeplatků u prodaných i stornovaných objednávek apod.). Kompletní přehled možných stavů je popsán v tabulce 3.1. 3.1.1.2

Tabulka Objednavky_Faktury

Tabulka Objednavky_Faktury udržuje seznam faktur od CK (viz 3.1.3) pro objednávky, což je jediný druh faktur spravovaný v aplikaci CRM4 . Tyto faktury nemají vliv na výpočet výše závazku vůči CK a udržování jejich správného stavu není tedy pro běh aplikace kritické. Často se při změnách ve fakturách přidávají pouze nové verze faktur a původní jsou z evidenčních důvodů zachovány. Pokud CK výslovně nezašle dobropis, můžou vznikat situace, kdy je ve fakturách uvedeno více než celková cena zájezdu. Tabulka Objednavky_Faktury obsahuje následující sloupce: 3 4

id_Stav=200 nebo 201 Dobropisy se zde zapisují se zápornou částkou


ID 0 1 2 4 5 8 10 12 14 15

Název ?Neznámý K vyřízení Přiděleno skupině Přiděleno prodejci Prodejce vyřizuje Vyprodáno, zašleme alternativy Klient má rezervaci Klient kontaktován Zaslána nabídka/dotaz, čekáme Vyžádání zasláno do CK

17 20 30 35

Rezervace vypršela Smlouva poslána klientovi Smlouva podepsaná Uhrazená záloha

40 70

Uhrazená celá částka Smlouva poslaná do CK

100 110 200

Vyřízeno, klient má cestovní pokyny Vyřízeno, zodpovězen dotaz Zrušeno

201

Zrušeno - Duplicita

202

Zrušeno klientem na webu

Popis Rozpracovaná objednávka před odesláním. Objednávka je k převzetí pro prodejce. Informativní stav. Informativní stav. Informativní stav. Informativní stav. Vytvořena rezervace v CK, informativní stav. Informativní stav. Informativní stav. Speciální případ zájezdu „na vyžádání“. Klient uhradil zálohu, smlouva je v CK a čeká se, zda se podaří zájezd vyžádat. Pokud ano, následuje stav 70, jinak 200. Informativní stav. Informativní stav. Informativní stav. Přišla první platba od klienta, od tohoto stavu se od klienta vyžaduje úhrada celkové ceny zájezdu. Ekvivalentní stavu 35 a je pouze informativní. Cestovní smlouva byla odeslána do CK, od tohoto stavu dlužíme do CK. Uzavřená, prodaná objednávka. Objednávka uzavřena jako neprodaná. Objednávka zrušena z libovolného stavu. Pokud je u objednávky zadán storno poplatek, je nutné ho uhradit. V případě, že u objednávky existuje přeplatek, musí být vrácen klientovi. Objednávka zaslaná jako duplicitní, existuje jiná objednávka stejného klienta v jiném stavu. Klient nedokončil online objednávku na webu a ze stavu 0 ji zrušil před odesláním. Objednávky jsou uloženy, ale nijak se s nimi nepracuje.

Tabulka 3.1: Číselník stavů objednávek

7

8


ID je pouze primární klíč tabulky a nemá vliv na zbytek aplikace. id_Objednavka je povinná vazba na tabulku Objednavky a určuje, ke které objednávce faktura patří. Vytvorena je pouze datum a čas vložení faktury do systému. Vytvoril uvádí odkaz do tabulky Zamestnanci na uživatele, který fakturu zapsal. Platit je příznak výběru konkrétní faktury k úhradě v aplikaci Platby.mdb. Tento způsob označování faktur i objednávek k úhradě způsobuje, že aplikaci Platby.mdb mohl současně obsluhovat pouze jeden uživatel. Cislo je číslo faktury a současně VS, pod kterým se odesílá platba do CK. Hodnota je zpravidla stejná jako číslo rezervace. Splatnost představuje datum splatnosti faktury a má pouze informativní charakter. Castka je cena celkem k úhradě, uvádí se částka s DPH. Pozn je pouze informativní textová poznámka. 3.1.1.3

Tabulka Platby

Tabulka Platby představuje hlavní úložiště informací o stavu financí každé objednávky. V tabulce je uložena každá zájezdová platba, včetně plateb čekajících na potvrzení a stornovaných. Kromě vzdálených klíčů do jiných tabulek systému a sloupce Castka jsou zásadní dvojicí sloupce Typ a TypPlatby, které určují od koho (klient, NetTravel, CK) a komu platba směřovala, ale i o jaký druh platby se jedná (hotovost, převod, fiktivní atd.). Kompletní přehled druhů plateb je uveden v tabulce 3.1.1.5. Tabulka Platby obsahuje následující sloupce: ID je pouze primární klíč tabulky a nemá vliv na zbytek aplikace. id_Objednavka je nepovinná vazba na tabulku Objednavky. Pokud má sloupec hodnotu NULL, jedná se o platbu k poukazu a je vyplněna vazba id_Poukaz na tabulku s poukazy. Při uplatnění poukazu ke konkrétní objednávce se tento sloupec vyplní příslušným ID. id_Davka je vazba na tabulku Platby_Davky a týká se pouze plateb odesílaných ze systému aplikaci Platby.mdb, tedy pouze odchozích plateb převodem na účet. id_User uvádí odkaz do tabulky Zamestnanci na uživatele, který platbu zapsal do systému. id_Poukaz je identifikace poukazu, ke kterému platba přísluší. Platby za běžné poukazy se zapisují nejdříve jako úhrada samotného poukazu a až následně jsou uplatněny ke konkrétní objednávce. Systémové poukazy generují platby k objednávkám při svém uplatnění, jak je popsáno v části 3.2.2. id_Faktura odkazuje u odchozích plateb do tabulky Objednavky_Faktury na fakturu, která byla příslušnou platbou hrazena. Faktury mohou být hrazeny zálohou a později doplatkem, čili k jedné faktuře může obecně existovat více plateb. V případě, že existuje k objednávce více faktur je informace o úhradách důležitá pro správný výběr faktury k úhradě v aplikaci Platby.mdb. Team představuje pouze číslo prodejního teamu, do kterého prodejce patřil v době zápisu platby. Sloupec má pouze informativní charakter a tuto informaci bylo nutné udržovat pro každou platbu zvlášť protože prodejci byli mezi teamy přesouváni i během období, za které se sledovaly výkonnosti jednotlivých teamů.


9

Typ spolu se sloupcem TypPlatby určuje o jakou platbu se jedná a kterým šla směrem (příchozí, odchozí, jiná atd.). První verze systému počítala pouze s příchozími platbami od klientů a odchozími do CK. S postupným rozšiřováním vyplynulo, že sloupec Typ měl být například VARCHAR(2), kde by první písmeno určovalo zdroj a druhé cíl platby5 , aby jednoznačně určoval směr platby. Úlohu druhého znaku (úplného určení směru platby) částečně převzal sloupec TypPlatby, což následně komplikovalo přepočty financí. Úplný přehled možných kombinací hodnot Typ a TypPlatby je uveden v tabulce 3.2. TypPlatby původně sloužil jako informativní doplnění druhu platby (rozlišení celé částky, zálohy nebo doplatku), ale postupem času převzal úlohu identifikace směru platby, jak je popsáno výše. Vytvorena je pouze informace o datu a čase zápisu platby do systému. Odeslana uvádí, kdy byla odchozí platba zadána do banky. Vyplnění této hodnoty u odchozích plateb realizovaných bankovním převodem potvrzuje odeslání platby (podobně jako PlatbaOK u ostatních plateb). Provedena je informace o datu, kdy byla příchozí platba připsána na účet společnosti. Hodnota je vyplňována ručně při potvrzení platby (nastavení PlatbaOK=1) nebo automaticky při automatickém potvrzování plateb (viz 3.1.2). PlatbaOK je zásadní příznak pro většinu plateb, který potvrzuje přijetí platby a její zařazení do výpočtu stavu financí. Pokud má být platba zrušena, tak nedochází k jejímu odstranění ze systému, ale pouze deaktivaci pomocí tohoto příznaku. Výjimku v potvrzování tímto sloupcem tvoří odchozí platby převodem (do CK i klientům), které jsou potvrzovány vyplněním sloupce Odeslana. UcetNT je pouze informativní sloupec s bankovním číslem účtu pro příchozí i odchozí platby převodem. UcetCK udává číslo bankovního účtu CK, na který byla odeslána odchozí platba. UcetKlient udával číslo bankovního účtu Klienta, na který byl vrácen přeplatek odeslaný převodem. VS udává variabilní symbol plateb převodem, příchozích i odchozích. Pozn je pouze informativní textová poznámka k platbě. V některých případech nese informaci o fiktivnosti, nebo bližším určení platby (viz tabulka 3.1.1.5), což měla být původně úloha sloupce TypPlatby. Castka je výše úhrady příslušné platby. Měna platby je dána státem cestovní kanceláře, která je uvedena u objednávky, nebo státem poukazu, jedná-li se platbu za poukaz. 3.1.1.4

Tabulka Platby_Davky

Tabulka Platby_Davky slouží pro sdružování odchozích plateb do hromadných platebních příkazů. Tyto příkazy jsou označovány jako „dávky“ a podle jejich zdrojové banky se generuje formát výstupního souboru, který je dále odesílán do internetového bankovnictví příslušné banky. Tabulka Platby_Davky obsahuje následující sloupce: ID je pouze primární klíč tabulky a slouží pouze pro vazbu na tabulku Platby. 5 Např. Typ= „KN“ by znamenal platbu od klienta do NetTravel, Typ= „NC“ odchozí platbu NetTravel do CK a podobně pro všech 6 kombinací. K tomuto rozšíření ale nedošlo.

10


UcetNT je číslo účtu NetTravel, ze kterého byla dávka odeslána. Tento účet má vliv jak na sloupec UcetNT z tabulky Platby (kam se hodnota opisuje při generování dávky), tak na výsledný formát souboru pro odeslání do internetového bankovnictví. Vytvorena je datum a čas vytvoření dávky. Odeslana je datum a čas, kdy byla dávka odeslána do internetového bankovnictví, a tedy i datum a čas, kdy byly potvrzeny všechny platby v dávce. Poznamka je textová poznámka, která má pouze informativní charakter. Ukládá se sem například informace o tom, kdo a kdy dávku stornoval. 3.1.1.5

Druhy evidovaných plateb

Jak bylo zmíněno v popisu tabulky Platby, systém eviduje více druhů plateb. Platby se rozlišují podle odesílatele, příjemce ale i případného účelu. Toto rozlišení udržuje dvojice sloupců Typ a TypPlatby. Sloupec Typ může obsahovat pouze hodnoty: C – platba klienta přímo do CK, O – platba NetTravel do CK, K – platba klienta do společnosti NetTravel, S – stornovaná platba z odchozí dávky. Hodnota sloupce TypPlatby přitom v některých případech může směr platby otočit. V systému se také rozlišují potvrzené a nepotvrzené platby. Pro účely potvrzování se používají sloupce Odeslana, pro bezhotovostní odchozí platby, a PlatbaOK, pro všechny ostatní. V některých případech se k přesnému určení původu platby používá ještě poznámka, ta již ale nemá vliv na způsob výpočtu stavu financí u objednávky. Kompletní přehled typů plateb je rozepsán v tabulce 3.1.1.5. Speciálními případy plateb jsou storna a virtuální platby. Prvním případem stornovaných jsou platby s příznakem Typ=„S“. Tyto se nikam nezapočítávají a slouží pouze jako evidence stornovaných dávek CK a klientům. Druhým případem byly platby s Typ=„P“ a TypPlatby=„s“. U takto stornovaných plateb se opisuje informace o jejich potvrzení a jsou zapisovány se zápornou částkou, aby v součtech anulovaly původní platbu od klienta. Tento režim sice neumožňuje stornovat všechny typy plateb, ale operace storno platby je v CRM vytvořena pouze jako opravný prostředek při chybně zapsané platbě a jiné typy plateb není nutné stornovat. V důsledku této struktury přibylo do systému postupem času několik druhů virtuálních plateb. Tyto platby nereprezentují žádný fyzický převod peněz, ale pouze evidovaly změny ve stavu financí u objednávky. Za virtuální se obecně považuje většina plateb za poukazy a zadání spropitného. 3.1.1.6

Výpočet ZaplatitCK a ZaplatitKlientovi

Sledování stavu financí u všech objednávek je založeno na výpočtu dvou hodnot – ZaplatitCK a ZaplatitKlientovi. Tyto sloupce v tabulce Objednavky představují součty potvrzených plateb ve vztahu ke klientovi i CK a odvíjí se od nich většina finančních operací. Pokud je hodnota ZaplatitCK větší než nula, znamená to, že NetTravel dluží peníze do CK a obráceně. Podobně, pokud je hodnota ZaplatitKlientovi menší než nula, dluží NetTravelu. Výpočet hodnot se navzájem neovlivňuje, čili stav cash flow je možné určit až na základě obou hodnot. Několik typických situací ilustruje tabulka 3.3.


Typ C C C C O

TypPlatby c z d k o

Potvrzení PlatbaOK PlatbaOK PlatbaOK PlatbaOK Odeslana

O

p

Odeslana

O O

r v

Odeslana PlatbaOK

P P P P P P P P

c z d k m s t u

PlatbaOK PlatbaOK PlatbaOK PlatbaOK PlatbaOK PlatbaOK PlatbaOK PlatbaOK

S S

o p

S

r

Popis Platba klienta přímo do CK – celá částka Platba klienta přímo do CK – záloha Platba klienta přímo do CK – doplatek Vrácení přeplatku z CK přímo klientovi Odchozí platba do CK Virtuální platby jsou označeny poznámkou „Platba poukazem od CK“ Odchozí platba do CK, objednávka má příznak ProvizeHned Vrácení přeplatku klientovi převodem Vrácení přeplatku klientovi, spropitné od klienta je označeno poznámkou „Spropitné, platba neprovedena.“ Platba od klienta – celá částka Platba od klienta – záloha Platba od klienta – doplatek Příchozí platba od CK, vrácení přeplatku Uplatnění marketingového poukazu, fiktivní platba Storno příchozí platby od klienta Příchozí platba kartou Uplatnění poukazu typu infocesta nebo od CK, virtuální platba. Typ poukazu je rozlišen poznámkou. Stornovaná odchozí platba z dávky CK (O, o) Stornovaná odchozí platba z dávky CK, kde byl příznak ProvizeHned (O, p) Stornovaná odchozí platba z dávky klientovi (O, r)

Tabulka 3.2: Druhy plateb

11

12


Určení hodnot ZaplatitCK a ZaplatitKlientovi se provádí na základě následujícího výpočtu. Součet částek z tabulky Platby konkrétního typu zde budu označovat dvojicemi (Typ, TypPlatby) s hodnotami podle tabulky 3.2. Do výpočtu se použijí pouze potvrzené platby. (

CenaKU hrade = StornoP oplatek = OdecetP rovize = P latbyN T doCK P latbyCKdoN T P latbyKlientaCK P latbyCKKlientovi P latbyOdKlienta V racenoKlientovi

= = = = = =

CenaCelkem pro id_Stav ∈ h35, 100i ∪ {15} 0 jinak ( StornoPoplatek pro id_Stav ≥ 200 0 jinak ( ProvizeSDPH pro (ProvizeHned 6= 0) ∧ (id_Stav ∈ h35, 100i) 0 jinak (O, o) + (O, p) (P, k) (C, ¬k) (C, k) (C, ¬k) + (P, ¬k) (O, r) + (O, v)

ZaplatitCK = CenaKU hrade + StornoP oplatek − OdecetP rovize +P latbyCKdoN T − P latbyN T doCK +P latbyCKKlientovi − P latbyKlientaCK ZaplatitKlientovi = −CenaKU hrade − StornoP oplatek P latbyOdKlienta − V racenoKlientovi − P latbyCKKlientovi Z pohledu vztahu mezi NetTravel a CK stojí za zdůraznění, že hodnota ZaplatitCK nijak nezávisí na fakturách vystavených CK. Předpis částky k úhradě je dán cenou zájezdu (případně výší storno poplatku) a stavu objednávky. Faktury od CK se evidují, a platby do CK se v aplikaci Platby.mdb snaží uhradit existující faktury, tato vazba má ale pouze informativní charakter. Speciální úlohu hraje ve výpočtech sloupec StornoPoplatek. Pokud klient zruší podepsanou smlouvu zaslanou do CK, řídí se tato operace smluvními podmínkami každé CK a ve většině případů je doprovázena storno poplatkem. Výše storno poplatku v tomto případě přebírá úlohu ceny zájezdu a představuje výši závazku klienta vůči NetTravel. V některých případech má ale NetTravel dle provizní smlouvy provizi i ze storno poplatku, což v kombinaci s případem ProvizeHned 6= 0 znamená, že závazek NetTravel vůči CK je výše storno poplatku snížená o výši provize ze storno poplatku. Vlastní implementace výpočtu ZaplatitCK a ZaplatitKlientovi je z výkonnostních důvodů prováděna SQL triggerem a do tabulky Objednavky se ukládaly přímo vypočítané hodnoty. Trigger pro přepočet hodnot sleduje jak tabulku Objednavky, kde se hodnoty odvíjí od ceny zájezdu i stavu objednávky, tak tabulku Platby. Uvnitř triggeru se aktuální hodnoty získávají ze dvou zřetězených SQL view, které hodnoty počítají z aktuálních dat. První view předpočítá dílčí hodnoty (cenu k úhradě, platby od klienta, platby do CK atd.) a druhý z nich sečte nové hodnoty ZaplatitCK a ZaplatitKlientovi. Tyto hodnoty jsou následně v triggeru uloženy ke změněné objednávce. Všechny ostatní výpočty se provádí na základě takto uložených hodnot. 3.1.2

Potvrzování plateb

Do výpočtu stavu financí se zahrnují pouze potvrzené platby a kvůli tomu je jejich potvrzování důležitou součástí systému. Potvrzení platby6 deklaruje, že došlo k fyzickému přenosu peněz, 6

Vlastní potvrzení je implementováno příznaky ve sloupcích PlatbaOK a Odeslana (viz 3.2)


CK

Zaplatit Klientovi 0 0

10 000

-10 000

10 000

-5 000

10 000 -10 000

0 10 000

0

10 000

0

15

13

Popis Objednávka, kde se neočekává žádná platba. Toto je případ neprodané, nebo již uzavřené objednávky bez závazků. Čerstvě prodaná, dosud neuhrazená objednávka, nebo objednávka čekající na doplatek od klienta. Klient dluží do NetTravelu a NetTravel dluží tyto peníze do CK. Platba ale nesmí odejít. Klient uhradil zálohu 5 000, která zatím nebyla odeslána do CK. Cash flow u této objednávky je +5 000, což je maximální výše přípustné odchozí platby do CK. Klient uhradil celou částku, která zatím nebyla odeslána do CK. Stornovaný zájezd, nebo zájezd s přeplatkem 10 000. CK dluží NetTravelu, a NetTravel dluží tuto částku klientovi. Stejný případ jako předchozí, ale CK již odeslala peníze do NetTravel. Platba čeká na odeslání klientovi. Například z důvody změny ceny zájezdu došlo k přeplatku s malou částkou, kterou klient nechce vrátit – částka bude započtena jako spropitné od klienta.

Tabulka 3.3: Příklad typických hodnot ZaplatitCK a ZaplatitKlientovi nebo započítání částky virtuálních plateb do prodejního procesu. Správnost tohoto údaje je tedy pro bezchybný chod financí klíčová. Do výpočtů zasahují různé druhy plateb, které se potvrzují různými způsoby. Virtuální platby a platby za poukazy jsou rovnou zapisovány jako potvrzené, protože jsou většinou doprovázeny speciální akcí (uplatněním poukazu), nebo je provádí osoba oprávněná k potvrzování plateb (zápis spropitného) a není je tedy třeba potvrzovat ve dvou krocích. Druhou skupinou jsou odchozí platby do CK i klientům, které se potvrzují ihned po odeslání platebního příkazu do banky přímo v aplikaci Platby.mdb. Další speciální skupinou jsou platby odesílané přímo mezi klientem a CK, jejichž ověření je možné pouze na základě telefonické nebo emailové komunikace. Obdrží-li NetTravel takovéto ověření, obsluha aplikace Platby.mdb potvrzuje zapsanou platbu ručně. Potvrzování zde vyjmenovaných skupin plateb je sice důležité, ale rychlost těchto procesů nemá ve většině případů na prodejní proces zásadní vliv. Poslední skupinou jsou platby od klientů, kde je rychlost potvrzování kritická. Rezervace zájezdů vytvářených v CK jsou zpravidla poskytovány na omezený čas, řádově několik hodin, a CK nejsou kvůli blokování svých kapacit ochotné rezervace prodlužovat. Potvrzení již vytvořené rezervace je možné pouze zasláním cestovní smlouvy, čímž vzniká smluvní vztah a povinnost společnosti NetTravel uhradit cenu zájezdu do CK. Proto prodejce nesmí do CK smlouvu odeslat před přijetím platby od klienta. Přijetím platby se pro účely zaslání smlouvy do CK myslí: • potvrzení platby v systému příznakem PlatbaOK, • převzetí hotovosti do pokladny na pobočce, • ověření na základě potvrzovacího emailu o platbě z banky7 , • ověření platby internetovým bankovnictvím8 , 7

Tuto funkci poskytují pouze některé banky. Vedoucí prodejních teamů mají typicky přístup pro čtení k internetovému bankovnictví některých bank pro účely ověřování plateb. 8

14


Klient

Prodejce

Platby.mdb

Zápis platby [Platba by již mČla být v bance]

Odeslání platby

Požadavek na ruþní ovČĜení Informace prodejci

[Má doklad o platbČ]

Poþká na úkol nebo ovČĜí pozdxji ýekání na platbu

Banka NT PĜijetí platby

Odeslání smlouvy do CK po první platbx

Neznámá platba

Email o platbx

Ruþní dohledání

Zápis potvrzení

Ruþní ovČĜení [Nalezena platby v bance platba]

Informace prodejci

[Jinak] [Platba nalezena]

Služba CRMSync

[Jinak]

[Nalezena objednávka]

Dohledání platby [Nalezena]

[Jinak]

Dohledání objednávky

Zápis platby

[Nenalezena] Ruþní potvrzení platby

Neznámá platba

[Jinak]

[Jinak] Deaktivace potvrzení

[Banka umí poslat mail] Email o platbx

Akce po potvrzení platby

Potvrzení platby Zápis platby

Obrázek 3.3: Schéma potvrzování plateb • nebo potvrzením od CK o přijetí platby klienta přímo na jejich účet. Potvrzení plateb v hotovosti je speciální případ, protože je prováděno až na základě soupisky při složení hotovosti z pokladny na zájezdový účet v bance. Až po této akci je na bankovním účtu dostatek prostředků pro odeslání platby do CK. Smlouvu je v tomto případě ale možné odeslat i když v systému není zapsaná žádná potvrzená platba. Schéma vlastního potvrzování plateb v systému je znázorněno v diagramu 3.3. Klient odešle platbu na účet a informuje o této události prodejce. Ten následně zapíše nepotvrzenou platbu do systému a v závislosti na naléhavosti jejího potvrzení provádí další kroky. Pokud potvrzení nespěchá (doplatky, dlouhé rezervace), může počkat na automatické potvrzení, v opačném případě může urgovat ověření u svého vedoucího teamu nebo potvrzení u obsluhy aplikace Platby.mdb. Obsluha Platby.mdb má přístup do internetových bankovnictví všech bank a má možnost vyhledat libovolnou platbu. U bank, které neumí odesílat emaily o platbách, kontroluje nové platby pravidelně a potvrzení zapisuje ručně. U ostatních dohledává pouze platby na základě požadavku od prodejců. Například Komerční Banka emaily sice odesílá, ale většinu v ranních hodinách za předchozí den. Chování všech bank je z tohoto pohledu následující: Česká Spořitelna – nikdy, ČSOB CZ – průběžně, ČSOB SK – průběžně, Raiffeisenbank – průběžně, Komerční Banka – vklady hotovosti a převody v rámci Komerční Banky průběžně, platby z ostatních bank v 7 hodin ráno,


15

Slovenská Sporiteľňa – nikdy, Tatra Banka – průběžně. Za účelem maximální automatizace prodejního procesu byla aplikace CRMSync rozšířena o část, která zajišťuje automatické zpracování emailů z bank. Aplikace v pravidelných intervalech9 kontroluje složky všech bank na serveru IMAP. Pokud narazí na nový email, pokusí se ověřit jeho pravost a zpracovat některým z přednastavených regulárních výrazů10 . Výsledkem této operace je záznam o potvrzení v tabulce Platby_Potvrzeni, který obsahuje datum, čísla účtů, identifikaci banky, částku a variabilní symbol. Po zapsaní všech nových potvrzení je spouštěna SQL procedura psp_ZapisPlateb, která provádí následující kroky. 1. Spuštění SQL procedury psp_PotvrzeniPlateb, která se pokusí spárovat a potvrdit všechna nevyužitá potvrzení z tabulky Platby_Potvrzeni – jak starší, tak nově zapsaná. Email z banky může dorazit dříve, než prodejce zapíše platbu. V takovém případě se potvrzení zapíše a čeká na vlastní zapsání platby. Jakmile je tato platba zapsána, je v tomto kroku během několika minut i potvrzena. Tento krok se týká plateb, ke kterým není možné dohledat objednávku automaticky, například kvůli chybně zadanému variabilnímu symbolu. 2. Zápis nových plateb k objednávkám nebo poukazům tam, kde je možné jednoznačně dohledat objednávku nebo poukaz. Navíc se ještě kontroluje, zda objednávka očekává platbu (id_Stav ∈ h10, 100i) a zda by platba nebyla zapsána duplicitně. 3. Znovu se spustí SQL procedura psp_PotvrzeniPlateb, která má v této fázi spárovat a potvrdit nově zapsané platby z předchozího kroku. Jak bylo zmíněno výše, úkolem procedury psp_PotvrzeniPlateb je spárovat příslušná potvrzení z tabulky psp_PotvrzeniPlateb s platbami v tabulce Platby. Kromě vlastního potvrzení se provádí i návazné akce, jakými jsou informování prodejců a případná aktivace uhrazených poukazů. Procedura psp_PotvrzeniPlateb provádí následující operace. 1. Ke každému potvrzení dohledá odpovídající jedinečnou platbu, která • má správný typ – je od klienta nebo CK a není v hotovosti, • má stejnou částku, variabilní symbol a banku, • zápis této platby není starší než potvrzení o více než 3 dny, aby nedocházelo k potvrzení starých, neplatných plateb. Přednostně se vybírají již potvrzené platby jako opatření proti duplicitám. Platba může být potvrzena ručně již dříve, ale navíc může přijít ještě dodatečný email, který je v tomto případě pouze přiřazen. Dalším opatřením proti duplicitám je uplatnění pouze prvního ze dvou stejných potvrzení, kde druhé je předáno k ručnímu spárování nebo deaktivaci v aplikaci Platby.mdb. 2. Pro nová potvrzení se vytvoří úkoly informující o nově potvrzených platbách. Úkol je implementován jako záznam v tabulce Ukoly a CRM během svého běhu průběžně úkoly daného prodejce kontroluje. Tímto mechanismem se prodejce dozví i o nově zapsaných a potvrzených platbách, o kterých neměl informaci od klienta. 9 10

V řádu minut Například ČSOB CZ zasílá 4 různé formáty podle druhu transakce

16

KAPITOLA 3. POPIS PŮVODNÍHO SYSTÉMU 3. Nově spárované platby jsou potvrzeny podle párování z bodu 1, je k nim zapsán datum realizace a poznámka o automatickém potvrzení. 4. U plateb za běžné poukazy se ještě zkontroluje, zda je poukaz uhrazen celý a pokud ano, je automaticky aktivován. Aktivace poukazu dále zajistí, že se objednateli poukazu automaticky odešle e-mail s potvrzením aktivace poukazu.

V aplikaci Platby.mdb je sekce, která spravuje automatická potvrzení plateb. V této části je k dispozici filtr pro zobrazení dosud nespárovaných potvrzení z tabulky psp_PotvrzeniPlateb. Tato potvrzení mohou být jak z duplicitních případů, tak ze situací, kdy nemohla být platba přiřazena automaticky kvůli špatnému variabilnímu symbolu apod. Obsluha tak může platby k potvrzením párovat ručně a případné chybějící platby dopisovat. Pro případ skutečně duplicitního potvrzení, nebo platby která nepatří k žádnému zájezdu, existuje možnost potvrzení jako takové deaktivovat. 3.1.3

Evidence faktur

V původním systému se rozlišují tři typy faktur, které různým způsobem zasahují do prodejního procesu. Jsou to • faktury od CK vystavené na cenu zájezdu, • faktury pro zaměstnavatele klientů jako potvrzení o ceně zájezdu, • faktury pro CK na provizi z prodeje zájezdů. Faktury od CK představují jediný typ faktur spravovaný v aplikaci CRM, která ukládá informace o těchto fakturách vystavených na cenu zájezdu. Na fakturách bývá vyčíslena i provize, která je při zadávání faktury zadána k objednávce. Z účetního hlediska představují faktury závazek, který je do CK potřeba uhradit, ale v původním systému mají faktury pouze informativní charakter a částka k úhradě do CK (hodnota ZaplatitCK) se určuje na základě ceny zájezdu, případně výše storno poplatku. Evidence těchto faktur je důležitá, není ale pro správný běh systému kritická. Proto jsou u objednávek často faktury zapsány duplicitně, například v situaci kdy CK zaslala novou, upravenou fakturu. Systém se také z principu výpočtu ZaplatitCK nesnaží zapsané faktury uhradit a pracuje s nimi pouze informativně. Při vlastním generování dávky je možné explicitně vybrat, která z faktur se má uhradit. Částka platby je pak omezena takto vybranou fakturou. Toto je užitečné v případě, kdy se jedná o úhrady zálohy za zájezd. Doplatek je pak uveden na druhé faktuře a hrazen později. Dalším druhem faktur zasahujících do prodejního procesu jsou faktury pro zaměstnavatele klientů, označované také jako faktury pro klienty. Tyto faktury jsou vystavovány a tištěny z aplikace CRM_Finance.mdb, do které mělo přístup pouze několik vybraných zaměstnanců. Mnoho společností, včetně státních organizací, hradí svým zaměstnancům část ceny zájezdu v rámci svých bonusových systémů. Úhrady v takovém případě typicky vypadají tak, že klient sám uhradí celou cenu zájezdu a požádá o vystavení faktury pro svého zaměstnavatele. NetTravel na základě této žádosti vystaví fakturu, označovanou jako „Potvrzení o ceně zájezdu“, na požadovanou částku. Zaměstnavatel na základě této faktury odešle peníze, které se chovají jako běžná příchozí platba ke konkrétní objednávce, a způsobí tak přeplatek. Od klienta je následně vyžádáno číslo bankovního účtu pro vrácení takto vzniklého přeplatku. Vystavení faktury je náročný proces, protože vystavení je možné pouze v aplikaci CRM_Finance.mdb na základě emailové komunikace a není nijak propojené s aplikací CRM.


17

V ideálním případě by faktury pro zaměstnavatele s přednastaveným textem11 mohli vystavovat, tisknout a zasílat rovnou prodejci. Tato funkce by tak zkrátila celý proces vystavení a ušetřila práci uživatelům CRM_Finance.mdb. Poslední typ faktur souvisejících s prodejem zájezdů představuje fakturace provize cestovním kancelářím. Aplikace CRM_Finance.mdb obsahuje nástroj na hromadné generování těchto faktur podle pravidel popsaných v části 3.2.4. Při vzniku nároku na provizi se podle data fakturace vystaví faktura pro CK na výši provize z prodeje zájezdů. Vystavování těchto faktur, sledování jejich úhrad i celková kontrola fakturace provize je v kompetenci finančního oddělení a takto vystavené faktury podléhají účetním procesům.

3.2

Finance v prodejním procesu

Cílem celého prodejního procesu je zrealizovat prodej zájezdu od poskytnutí nabídky klientovi, uzavření cestovní smlouvy a ošetření financí až po doručení pokynů k zájezdu a fakturaci provize cestovní kanceláři. Z pohledu finančních toků je úkolem zajistit tři základní kroky: 1. přijmout platby od klienta, 2. zaslat peníze do CK, 3. vyfakturovat provizi. Realizace těchto kroků v kontextu celého prodejního procesu a situací, které mohou nastat, vedou na složitý proces. Prodejní proces začíná přijetím objednávky do CRM. Ta může vzniknout online na webu, osobní návštěvou klienta na pobočce, případně po telefonické objednávce od klienta. Po obdržení objednávky patří mezi úkoly prodejce ověření dostupnosti zájezdu, vytvoření rezervace a příprava cestovní smlouvy. Cestovní smlouvu pak prodejce zasílá k podpisu klientovi spolu s pokyny k platbě. Klient následně smlouvu podepíše, zašle zpět prodejci a zaplatí zálohu, která bývá typicky ve výši poloviny celkové ceny. Veškeré operace, včetně přijetí platby, se odehrávají pouze mezi klientem a prodejcem pracujícím s aplikací CRM. Po obdržení první platby se do prodeje zapojuje proces ověřování a potvrzování plateb popsaný v části 3.1.2. Po ověření příchozí platby prodejce zasílá podepsanou cestovní smlouvu do CK, čímž vzniká vztah mezi společností NetTravel a cestovní kanceláří. Před zasláním smlouvy do CK je velmi důležité ověřit přijetí platby od klienta. V případě, že by klient platbu neodeslal a účast na zájezdu odřekl, musela by se smlouva v CK zrušit což by dle smluvních podmínek většiny CK bylo doprovázeno storno poplatkem. Tento storno poplatek by tak musel NetTravel uhradit jako ztrátu ze svého a až následně požadovat po klientovi. Od přijetí první platby až do uhrazení celkové ceny zájezdu klientem mohou vznikat příchozí platby v libovolném pořadí a libovolného typu. Občas se stává, že se klient neřídí podle pokynů a peníze zašle přímo do cestovní kanceláře12 a i takovou platbu musí systém ošetřit. Kromě běžných plateb může klient také uplatnit dárkový poukaz, což se chová jako přiřazení již přijaté platby k objednávce. Podrobnosti o systému poukazů jsou popsány v sekci 3.2.2. Jakmile CK obdrží cestovní smlouvu, zkontroluje její údaje a potvrdí rezervaci. Od tohoto okamžiku má klient jistotu, že jeho zájezd nebude prodán nikomu jinému. CK na základě cestovní smlouvy vystaví fakturu na cenu zájezdu a tu zašle zpět společnosti NetTravel. Součástí této faktury je i vyčíslení provize z prodeje zájezdů. Faktura bývá zpravidla rozdělena na dvě 11

Text vystavené faktury, stejně jako údaje na faktuře nemohou být zadávány libovolně. Nejsou výjimkou případy, kdy klienti požadují na fakturu namísto zájezdu uvést kurzy angličtiny, nákup zboží a další nepravdivé údaje. Texty faktur by tak musely být generovány systémově, aby se předešlo případům, kdy klient méně zkušeného prodejce přemluví k zadání nesprávných údajů. 12 Číslo účtu CK bývá uvedeno na cestovní smlouvě.

18


Klient

&HVWRYQ¯NDQFHO£ě

CA: NetTravel

Objednávka Smlouva, výzva k platbx Podepsaná smlouva Platba 1 Podepsaná smlouva Faktura za zájezd Platba 1..N Uplatnxní poukazu 0..N

Platba 1..N Pokyny (po úplné úhradx)

Pokyny k zájezdu

Faktura - provize Vrácení pĜeplatku 0..1

Vrácení pĜeplatku 0..1

Obrázek 3.4: Základní schéma pohybu financí v prodejním procesu

části – zálohovou a doplatkovou. Zálohová část mívá splatnost relativně krátkou, doplatek bývá splatný měsíc před odletem. Výjimkou bývají zájezdy Last Minute s termínem bližším než je měsíc, u kterých nebývá na zálohu a doplatek čas. Aplikace Platby.mdb, tedy odchozí platby do CK, se do procesu zapojují od okamžiku odeslání smlouvy do CK. Od této akce vzniká závazek vůči CK a výpočet hodnoty ZaplatitCK tento dluh zohlední. Jak bylo popsáno ve výpočtu ZaplatitCK, hodnota nijak nezávisí na fakturách od CK. Existují cestovní kanceláře, které faktury nezasílají a systém pak generuje faktury fiktivní. Po obdržení platby od klienta a zaslání smlouvy do CK jsou odesílány peníze do cestovní kanceláře. Platby sice nezávisí na vystavených fakturách, ale snaží se respektovat princip zálohové a doplatkové faktury. To je zajištěno například i tím, že klient jako svou první platbu odesílá pouze zálohu a do CK nemůže být odesláno více, než kolik je přijato od klienta. Po úplné úhradě zájezdu zasílá cestovní kancelář pokyny k zájezdu, které NetTravel pouze předá klientovi a stav objednávky se změní na 100 = „Vyřízeno, klient má cestovní pokyny“. Od tohoto stavu se objednávka považuje za uzavřenou a končí její zpracování z pohledu prodejce. Z pohledu financí je nutné ještě vyfakturovat provizi z prodeje zájezdu (viz 3.2.4) a dořešit případné přeplatky klienta. Pokud vznikne přeplatek klienta v CK, cestovní kancelář vrací peníze agentuře NetTravel a ta následně klientovi. Klient je nejprve vyzván, aby zaslal číslo účtu pro vrácení přeplatku. To je zadáno do CRM k objednávce a následně je na tento účet vrácen přeplatek. Ten může vzniknout například po změnách v cestovní smlouvě, které sníží celkovou cenu zájezdu. Dalším případem může být úhrada vystavené faktury zaměstnavateli popsaná v části 3.1.3.

KAPITOLA 3. POPIS PŮVODNÍHO SYSTÉMU 3.2.1

19

Finance v CRM

Přímo v aplikaci CRM jsou implementovány pouze funkce potřebné pro vlastní prodej zájezdů a operace s ním související. Z pohledu prodejců jsou nejčastěji používanými akcemi zápisy příchozích plateb od klientů, které jsou později ještě potvrzovány některým z postupů popsaných v 3.1.2. Některé další akce, například přesun platby, jsou omezeny uživatelskými právy a mohou je provádět vedoucí prodejních teamů. U objednávky, v závislosti na jejím stavu, je možné provádět následující akce: Zápis platby v hotovosti – zápis platby do tabulky Platby a vytištění příjmového pokladního dokladu. Při zápisu se rozlišují tři varianty (TypPlatby): • celá částka, • záloha, • doplatek. Zápis platby do banky NetTravel – zápis příchozí platby od klienta převodem na účet. Stejně jako u hotovosti se při zápisu rozlišují tři typy: • celá částka, • záloha, • doplatek. Zápis platby do banky CK – zápis platby, kterou klient zaslal přímo do cestovní kanceláře. Toto není standardní způsob úhrady zájezdu, ale někteří klienti zasílají platby přímo na číslo účtu, které najdou na cestovní smlouvě. Opět se zde rozlišují tři základní typy: • celá částka, • záloha, • doplatek. Platba CK klientovi – zápis platby, která představuje vrácení peněž cestovní kanceláří přímo na účet klienta. CK by správně měla peníze zasílat přes NetTravel, ale v některých nestandardních případech vrací peníze přímo na účty klientům. O této skutečnosti informuje cestovní kancelář emailem nebo telefonicky rovnou při odeslání platby, nebo až při odmítnutí požadavku na vrácení přeplatku do NetTravel. Uplatnění poukazu – přiřazení aktivního poukazu a převod plateb ke konkrétní objednávce. V případě, že je uplatněn jiný druh poukazu než běžný, jsou k objednávce zapsány všechny potřebné platby. Ty jsou zapsány rovnou jako potvrzené, aby se uplatnily při výpočtu ZaplatitCK a ZaplatitKlientovi. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, typicky vedoucím prodejních teamů a uživatelům spravujícím poukazy. Zadání účtu klienta – zápis čísla bankovního účtu pro vrácení přeplatku. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, což jsou vedoucí prodeje, finanční oddělení a obsluha aplikace Platby.mdb. Vrácení částky v hotovosti – zápis odchozí platby v hotovosti a vytištění výdajového pokladního dokladu. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, typicky vedoucím prodejních teamů.

20


Storno platby – výběr platby a její stornování tak, aby se nezahrnovala do výpočtu hodnot ZaplatitCK a ZaplatitKlientovi. Způsob, jakým se stornují jednotlivé platby je popsán v části 3.1.1.5. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, typicky vedoucím prodejních teamů. Zadat storno poplatek – zápis částky storno poplatku ke stornované objednávce. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, což je finanční oddělení, osoby zadávající faktury od CK a obsluha aplikace Platby.mdb. Zobrazení historie plateb – náhled do tabulky Platby pro konkrétní objednávku. Kombinace sloupců Typ a TypPlatby je zde nahrazena zjednodušeným slovním popisem, který rozlišuje pouze základní směry plateb. Odchozí platby jsou barevně odlišeny a platby v hotovosti umožňují opětovný tisk příjmového i výdajového dokladu. Přímo v okně s objednávkou je zobrazena i hodnota ZaplatitKlientovi, aby měli prodejci možnost sledovat stav plateb od klienta a chybějící doplatky urgovat. Hodnotu ZaplatitCK prodejci nevidí. Správa faktur od CK – zobrazení, přidávání, úpravy a mazání faktur od CK. Tyto operace jsou dostupné pouze uživatelům s příslušným oprávněním, což je finanční oddělení, osoby zadávající faktury od CK a obsluha aplikace Platby.mdb. Zápis provize – zápis provize z prodeje zájezdů k objednávce. Tato akce je dostupná pouze uživatelům s příslušným oprávněním, což je finanční oddělení a osoby zadávající faktury od CK. Kalkulace – editace cestujících zájezdu a seznamu cen13 pro každého cestujícího. Výsledkem takto vytvořené kalkulace je celková cena zájezdu, ze které vychází výpočet hodnot ZaplatitCK a ZaplatitKlientovi. Správa poukazů – kompletní správa poukazů, vystavování, aktivace a zápis plateb k poukazům. Jednotlivé druhy poukazů a jejich využití je popsáno v části 3.2.2. Zápis celé částky a zálohové platby je možný pouze pokud u objednávky ještě nebyla provedena žádná platba. Tyto dvě varianty plateb pak mění stav objednávky na 35 = „Uhrazená záloha“, případně 40 = „Uhrazená celá částka“. Oba stavy mají stejnou váhu a jejich rozlišení je pouze informativní. Platby doplatků je možné zapsat až po provedení některé z hlavních plateb a stav objednávky nemění. 3.2.2

Poukazy

Přímo v aplikaci CRM existuje nástroj pro jednotnou správu všech typů poukazů. Ty jsou evidovány ve stejnojmenné tabulce Poukazy, která obsahuje u normálních poukazů ještě rozlišení vzhledu podle tabulky TypyPoukazu, jak znázorňuje obrázek 3.5. Součástí nástroje je vyhledávání a přednastavené filtry podle jednotlivých typů a stavů poukazu. Existují čtyři typy poukazů, které se liší svým chováním a použitím, a tři možné stavy poukazu. Poukaz je vždy jednoho z následujících typů: Normální – běžný dárkový poukaz určený pro klienty. Poukaz je hrazen klientem. Marketingový – poukaz vystavený pro propagační účely na náklady NetTravel. Infocesta – speciální typ určený pro úhradu zájezdů typu infocesta. 13

Základní cena, slevy, ceny všech příplatků atd.


«table» Poukazy -ID : Integer -Vytvoren : Date -Aktivovan : Date -Uplatnen : Date -Vytvoril : Integer -Aktivoval : Integer -Uplatnil : Integer -Castka : Double -id_Klient : Integer -id_Objednavka : Integer -Cislo : String -Pozn : String -Typ : Char -Venovani : String -id_CK : Integer -LastUpdate : Date -id_TypPoukazu : Integer -Stat : String

21

0..* 0..1 «table» TypyPoukazu -ID : Integer -Vytvoren : Date -Nazev : String -Nazev_SK : String -Nazev_EN : String -Popis : String -Popis_SK : String -Popis_EN : String -Soubor : String -Typ : Char -Prefix : String -Aktivni : Boolean

Obrázek 3.5: Přehled tabulek pro správu poukazů Od CK – dárkové poukazy vystavené CK, které je možné uplatnit namísto platby do CK. Jako normální poukazy jsou označovány běžné, dárkové poukazy určené pro klienty. Klient si na webu objedná dárkový poukaz na zvolenou částku s možností zadání vlastního věnování. Poukaz si může po dokončení objednávky rovnou stáhnout ve formě PDF, případně si nechat poslat zalaminátovaný originál poštou. Tento typ poukazu musí klient uhradit v plné výši převodem, hotově nebo na základě faktury pro zaměstnavatele popsané v části 3.1.3. Faktura se v tomto případě vystavovala ručně a její úhrada se ke konkrétnímu poukazu opisuje. Aplikace CRMSync automaticky rozpoznává pouze platby k poukazům pod variabilním číslem odpovídajícím číslu poukazu. Aktivace poukazu je prováděna, jakmile dojde k úplné úhradě poukazu. Takto aktivovaný poukaz může klient někomu darovat a následně uplatnit k libovolné objednávce. Při uplatnění se ke všem stávajícím platbám za poukaz vyplní hodnota id_Objednavka a platby za poukaz se tak zahrnou do výpočtů ZaplatitCK a ZaplatitKlientovi konkrétní objednávky. Marketingové poukazy slouží pro evidenci případů, kdy je část zájezdu uhrazena na náklady NetTravel. To se používá například při veletržních slevách, jako výhra v soutěžích vyhlášených NetTravel nebo sleva pro obchodní partnery. Aktivace poukazu není závislá na žádné úhradě a uplatnění poukazu vytváří novou platbu, která se ve výpočtech chová jako příchozí platba od klienta. Poukaz typu infocesta slouží opět jako evidence speciálních případů. Prodejci zaměstnaní na plný úvazek jsou v průběhu sezóny vysílání na zájezdy, které CK pořádají pro své obchodní partnery, tzv. „infocesty“. Během infocesty organizuje program pořádající CK a hlavní náplní jsou prohlídky hotelů a letovisek. Účel je, kromě podpory prodeje, osobní seznámení prodejců s nabízenými kapacitami. Část nákladů na infocesty hradí opět NetTravel. Podobně jako u marketingových poukazů se při uplatnění vytváří virtuální příchozí platba od klienta, kterým je v tomto případě sám prodejce zájezdů. Poukaz typu infocesta je možné uplatnit pouze na typ zájezdu infocesta. Posledním typem poukazů jsou poukazy od CK. Cestovní kanceláře také vystavují své dárkové poukazy, které mohou získat jak klienti a využít je při koupi zájezdu, tak NetTravel jako takový. Typickou příležitostí k získání poukazu je výhra v soutěžích o nejlepší provizní prodejce vyhlašované CK. NetTravel pak může takto získaný poukaz využít pro vlastní zaměstnance,

22


nebo k úhradě zájezdů klientů. Cena poukazu se pak řadí do výnosů. Uplatnění poukazu vytváří vždy fiktivní odchozí platbu do CK, a fiktivní platbu od klienta jako v předchozích případech. Pokud se jedná o poukaz ve vlastnictví NetTravel, je po uplatnění ručně zrušeno potvrzení platby od klienta a poukaz se tak chová pouze jako úhrada do CK. Stav každého poukazu je určen podle vyplnění sloupečků Aktivovan a Uplatnen, ve kterých je uložen datum a čas příslušné operace. Každý poukaz může být v jednom ze tří stavů: Připraven – pouze vytvořený poukaz, který nebyl dosud aktivován (nebyl uhrazen klientem, nebo zatím není určen k uplatnění). Aktivován – poukaz byl uhrazen a je připraven k uplatnění. Uplatněn – poukaz již byl uplatněn ke konkrétní objednávce a není v něm možné provádět žádné změny. 3.2.2.1

Tabulka Poukazy

Tabulka Poukazy obsahuje veškeré informace potřebné pro jednoznačné určení poukazu a jeho parametrů, kromě plateb evidovaných v tabulce Platby. ID – pouze primární klíč tabulky. Vytvoren – datum a čas, kdy byl poukaz vytvořen. Aktivovan – datum a čas, kdy byl poukaz aktivován. Uplatnen – datum a čas, kdy byl poukaz uplatněn. PlatiDo – datum, do kdy je možné poukaz uplatnit. Po tomto datu jsou poukazy automaticky deaktivovány. U normálních poukazů je platnost prodlužována, dokud není poukaz uplatněn, protože je uhrazen klientem a tyto platby nemůžou propadnout. Vytvoril – vzdálený klíč do tabulky Zamestnanci na uživatele, který poukaz vytvořil14 . Aktivoval – vzdálený klíč do tabulky Zamestnanci na uživatele, který poukaz aktivoval. Uplatnil – vzdálený klíč do tabulky Zamestnanci na uživatele, který poukaz uplatnil. Castka – hodnota, na kterou je poukaz vystaven. id_Klient – vzdálený klíč do tabulky Klienti na klienta, který poukaz objednal. id_Objednavka – vzdálený klíč do tabulky Objednavky na objednávku, ke které je poukaz uplatněn. Cislo – číslo poukazu, které slouží pro vyhledání a ověření pravosti. Čísla jsou generována náhodně při vytvoření poukazu a jejich dvoumístné prefixy jsou dané předem podle typu poukazu. Pozn – textová poznámka, ve které jsou uloženy všechny akce prováděné s poukazem. Typ – rozlišení typu poukazu, může nabývat hodnot „n“, „m“, „i“ nebo „c“. Venovani – textové věnování, které chtěl klient uvést na normální poukaz. id_CK – vzdálený klíč do tabulky Cestovky na CK, která vystavila poukaz typu „c“. 14

Poukazy vytvořené online na webu zde mají hodnotu 0 odpovídající uživateli „Systém“.


23

LastUpdate – datum a čas, kdy byla provedena poslední změna v poukazu. id_TypPoukazu – vzdálený klíč do tabulky TypyPoukazu u normálních poukazů. Stat – určuje stát, pro který byl poukaz vytvořen, a tedy měnu poukazu. V současné verzi může sloupec nabývat hodnot „cz“ nebo „sk“. 3.2.2.2

Tabulka TypyPoukazu

Tabulka TypyPoukazu má význam pouze pro normální poukazy, u kterých určuje jejich grafický vzhled. Tento typ poukazů si mohou klienti objednat přímo na webu, kde si také vybírají jednu z připravených grafických variant. Název, popis a další parametry pro online objednávku jsou uloženy právě v této tabulce, která slouží jako číselník a aktualizuje se pouze při přidávání nových vzhledů. Tabulka TypyPoukazu obsahuje následující sloupce: ID – pouze primární klíč tabulky. Vytvoren – datum a čas vytvoření typu poukazu. Nazev – název poukazu pro návštěvníky českého webu. Nazev_SK – to samé pro slovenský web. Nazev_EN – to samé pro evropskou verzi webu. Popis – popis poukazu pro návštěvníky českého webu. Popis_SK – to samé pro slovenský web. Popis_EN – to samé pro evropskou verzi webu. Soubor – prefix názvu souboru bez koncovky, ve kterém je uložen podklad poukazu pro tisk a náhled poukazu. Typ – rozlišení, jaký typ poukazu bude vygenerován. Pro normální poukazy obsahuje vždy hodnotu „n“. Prefix – prefix vygenerovaného čísla poukazu. Pro normální poukazy obsahuje vždy hodnotu „99“. Aktivni – příznak, zda má být tato grafická varianta nabízena klientům k objednání. 3.2.3

Správa plateb – Platby.mdb

Aplikace Platby.mdb vznikla přibližně po roce od spuštění první verze CRM jako reakce na rostoucí objemy prodeje. Nutným důsledkem zvýšení počtu prodejců, prodaných objednávek a tedy i množství odesílaných plateb bylo vytvoření aplikace pro sledování a řízení financí. Touto aplikací byly právě Platby.mdb, které slouží nejen jako manažerský nástroj pro kontrolu plateb u objednávek, ale hlavně jako nástroj pro automatizované generování platebních příkazů. S touto aplikací byla do prodeje začleněna důležitá evidence odchozích plateb, jejich kontrola na základě hodnot ZaplatitCK a ZaplatitKlientovi, a možnost sledování financí i řízení cash flow15 . Stejně jako vlastní CRM se aplikace Platby.mdb dále rozvíjela a s postupem času do ní přibývaly další funkce. 15 Pojem „cash flow“ označuje aktuálně dostupné finanční prostředky za určité období. Pro účely této práce je to označení příchozích plateb, které zatím nebyly odeslány dále a jsou v konkrétním časovém období dostupné.

24


Náhled hlavního okna je na obrázku 3.6. V horní části je lišta se všemi příkazovými tlačítky a ve zbytku okna je výpis objednávek. Tento výpis zobrazuje všechny důležité sloupce pro sledování objednávky a umožňuje běžné filtrování ve stylu aplikací MS Access. U každé objednávky je možné ještě rozkliknout seznam faktur od CK umožňující vybrat konkrétní faktury k úhradě (viz 3.2.3.1). Hlavní funkce aplikace jsou následující: • zobrazení přehledu objednávek, • filtrování tohoto přehledu a označení objednávek (nebo faktur) k úhradě, • generování platebních příkazů (dávek), • export dávek do souborů pro elektronická bankovnictví. V přehledu objednávek jsou zobrazeny sloupce, které jsou významné pro placení zájezdů a sledování celkového stavu objednávek. Tento přehled umožňuje, kromě označování objednávek a faktur, také zobrazování dalších informací. Dvojklik na řádek s objednávkou otevře detail objednávky se všemi ostatními údaji a dvojklik na hodnoty obsahující částky16 zobrazí okno s přehledem všech plateb objednávky. U objednávek, které mají blízký termín a dosud nebyly uhrazeny do CK je navíc hodnota ve sloupci Termin zvýrazněna tučným písmem a obarvena oranžově17 nebo červeně18 . S přehledem objednávek souvisí ještě první sloupec tlačítek na obrázku 3.6. Jsou zde tři přednastavené filtry, které upravují seznam zobrazených objednávek pro efektivnější práci. Tato tlačítka v kombinaci s omezením na CZ/SK objednávky umožňují zobrazit následující výběry: Jen neplacené – Zobrazí objednávky, u kterých je alespoň jedna z hodnot ZaplatitCK nebo ZaplatitKlientovi různá od nuly. Tento filtr je výchozí a zobrazí vše nedořešené. Jen splatné – Zobrazí ty objednávky, které mají ZaplatitCK větší než nula a existuje u nich neuhrazená faktura od CK se splatností v aktuální den. Tento filtr je možné kombinovat s prvním filtrem. Jen k odeslání – zobrazení objednávek, které jsou zařazeny na vytvořené, ale dosud neodeslané dávce. Tento filtr je vhodný pro rychlé dohledání rozpracovaných dávek. Vše – při zrušení všech předchozích tlačítek se zobrazí výpis všech objednávek. Kromě výše jmenovaných, stěžejních, funkcí jsou v aplikaci i další funkce související s prodejem. Jejich zařazení souvisí buď přímo s administrací plateb, nebo se jedná o funkce dostupné pouze uživatelům aplikace Platby.mdb: • zápis plateb od CK do NetTravel i přímo klientům, • zápis spropitného, • administrace tabulky Cestovky, • správa bankovních spojení cestovních kanceláří, • potvrzování příchozích plateb zájezdů i poukazů. 16

CenaCelkem, ZaplatitCK a ZaplatitKlientovi Pokud je termín do pěti dnů. 18 Pokud je termín do tří dnů. 17


25

Obrázek 3.6: Ukázka uživatelského rozhraní aplikace Platby.mdb Poslední součástí aplikace je zobrazování přehledů, které souvisí s tabulkou platby nebo stavem objednávek. Pro kontrolu činnosti prodejních teamů existuje přehled o platbách přijatých v hotovosti do pokladny každého teamu a výpis stornovaných plateb pro každý den. Je zde také celkový přehled závazků vůči cestovním kancelářím, který představuje hlavní ukazatele cash flow v prodejním procesu. 3.2.3.1

Generování platebních příkazů

Jak je popsáno v předchozí části, generování platebních příkazů (dávek) je hlavní úkol aplikace Platby.mdb. Příprava dávky vždy začíná označením objednávek, případně konkrétních faktur, k úhradě. Označení se provádí zaškrtnutím ve sloupci Platit, který je uložen v SQL databázi, a je tedy společný pro všechny uživatele. Tato vlastnost omezuje počet uživatelů, kteří mohou současně vytvářet dávky pouze na jednoho, a to pro české i slovenské zájezdy. Pokud uživatel u označené objednávky nevybere konkrétní faktury k úhradě, snaží se proces generování uhradit všechny neuhrazené v pořadí splatnosti. Pro obecnou úhradu tedy stačí označit pouze celou objednávku a seznam faktur se nemusí rozklikávat. Toto umožňuje hradit zájezdy i u cestovních kanceláří, které nezasílají faktury a v době placení tedy není z čeho vybírat. Dalším krokem po označení všech objednávek a faktur k úhradě je kontrola dávky. Ta prochází stejný proces jako vlastní generování, ale nezapisuje vytvořené platby do databáze. Účelem tohoto kroku je předem upozornit na všechny chyby, které při generování nastanou, a zobrazit celkovou částku dávky. Oprava případných chyb je jednoduší před vygenerováním dávky, než v jejím průběhu, protože se nemusí nedokončená dávka stornovat a generovat znovu. Zobrazení celkové částky slouží pro kontrolu, zda je na bankovním účtu dostatek prostředků pro odeslání hromadného platebního příkazu. Vlastní generování dávky do CK i dávky klientovi se chová podobně, až na výběr čísla účtu a některé kontroly. Vytvoření nové dávky otevře okno s prázdnou dávkou. V tomto okně se nejdříve vybere číslo zdrojového účtu a až poté se spouští generování plateb pro dávku.

26


Při generování musí být známa zdrojová banka, aby mohly být přednostně vybírány ty účty cestovních kanceláří, které jsou ve stejné bance19 . V případě generování dávky do CK může mít cestovní kancelář nastaven příznak, že nezasílá faktury. V tomto případě jsou jako první krok vygenerovány fiktivní faktury na celkovou cenu zájezdu, aby zbytek tvorby dávky mohl běžet jednotně. Generování dávky CK projde všechny označené faktury a pokusí se pro každou vytvořit odchozí platbu. Více faktur u jedné objednávky je odesláno zvlášť, aby bylo možné uvést variabilní symbol podle faktury a evidovat úhrady jednotlivých faktur. Během generování je prováděna řada kontrol, které mají za úkol zajistit správné vygenerování dávky. Během těchto kontrol může dojít ke snížení odesílané částky (v případě, že u objednávky není dostatek prostředků), případně vynechání faktury. Prováděné kontroly jsou následující: • Všechny platby musí mít CK pouze ze státu, v jakém je zdrojová banka dávky, aby na jednom příkazu nebyly různé měny. Platby s nesprávnou měnou jsou vynechány. • Přednostně se vybírá cílové bankovní spojení ze stejné banky. Pokud neexistuje spojení ani do jiné banky, není platba do dávky zařazena, protože není známo, kam se mají peníze zaslat. • U objednávek, které mají nastaveno ProvizeHned 6= 0 se kontroluje, zda je provize zadána. Pokud provize ještě nebyla zadána, rozhoduje o zařazení platby do dávky uživatel. • U vybrané objednávky musí existovat faktura k úhradě, jinak není platba zařazena. Tato situace může nastat v případě výběru objednávky u cestovní kanceláře, která běžně faktury zasílá. částka překročit hodnotu • Od žádné objednávky nesmí odeslaná ( ZaplatitKlientovi pro ZaplatitKlientovi ≤ 0 M axU hrada = ZaplatitCK + 0 jinak bez ohledu na částky na fakturách. Pokud je součet faktur vyšší, je na to uživatel upozorněn a odchozí platby budou sníženy tak, aby se nepřekročil tento limit. • Odeslaná částka musí být kladná. Není možné odeslat peníze k dobropisu, ani platbu sníženou do záporných hodnot. Generování dávky klientům je v porovnání s dávkou do CK výrazně jednodušší. Existuje pouze jedno číslo účtu pro vrácení přeplatků, vždy se vrací celý přeplatek najednou a částka k úhradě je dána přímo hodnotou ZaplatitKlientovi. V případě generování dávky klientům se provádí následující kontroly: • Všechny platby musí mít CK pouze ze státu, v jakém je zdrojová banka dávky, stejně jako u dávky do CK. Ostatní platby jsou vynechány. • Platba klientovi nesmí překročit hodnotu (

ZaplatitCK pro ZaplatitCK ≤ 0 0 jinak což znamená, že není možné přeplatek vrátit pokud jsou peníze v CK, a není tedy z čeho platbu uhradit. M axU hrada = ZaplatitKlientovi +

• Pokud nebylo zadáno číslo účtu pro vrácení přeplatku, je platba zařazena do dávky, uživatel je na tento problém upozorněn a může účet doplnit do již vygenerované dávky. 19

V případě, že má CK účet ve více bankách.


27

Další postup práce s dávkou je společný pro dávku CK i klientům. Uživatel zkontroluje, zda jsou údaje v dávce v pořádku a má možnost některé hodnoty upravit. Tato možnost není z hlediska kontrol vhodná, protože může do dávky zanést chybu, ale některé výjimečné situace by bez toho nebylo možné uhradit. V této fázi může být stornována jak celá dávka, tak zrušeny jednotlivé platby. V případě, že je dávka v pořádku, je odeslána přes elektronická bankovnictví příslušné banky. Přímo v aplikaci Platby.mdb je implementován export dávky do souboru hromadného platebního příkazu konkrétní banky. Tato funkce umožňuje velké dávky rychle zpracovat a odeslat do banky, aniž by se musely všechny hodnoty kopírovat ručně. V současné verzi je možné exportovat následující banky a formáty: Česká Spořitelna – formát ABO, varianta bez jména klienta20 . ČSOB CZ – formát CFD pro SW MultiCash. ČSOB SK – formát SKI pro SW MultiCash. eBanka

21

– formát ABO.

Komerční Banka – formát BEST. Slovenská Sporiteľňa – formát ABO, varianta bez jména klienta. Tatra Banka – formát Gemini. VÚB – formát SKI pro SW MultiCash. Úspěšné odeslání dávky do banky se potvrzuje tlačítkem „Dávka odeslána“, které ke všem platbám v dávce nastaví datum odeslání a tyto platby tak potvrdí. Současně se zavře okno s dávkou, protože touto operací je práce s celou dávkou ukončena. 3.2.3.2

Další funkce související s prodejním procesem

Nedílnou součástí aplikace jsou i funkce, které doplňují systém o ošetření speciálních případů. Implementace těchto funkcí je umístěna v aplikaci Platby.mdb, protože nejsou určeny běžným uživatelům CRM, nebo jsou přístupné pouze uživatelům aplikace Platby.mdb. Pokud se při akci vytváří platby, jsou zapsány rovnou jako potvrzené, aby se nemusely potvrzovat dodatečně. Případná chyba v zadání může být vyřešena zrušením potvrzení. Zápis příchozí platby z CK projde všechny označené objednávky, vybere první z účtů CK a zkontroluje, zda je ZaplatitCK záporné. Pokud ano, je zapsána příchozí platba z CK ve výši −ZaplatitCK. Zápis platby z CK přímo klientovi se chová podobně jako předchozí případ, pouze nejsou vyplněny čísla bankovních účtů. Částka platby se opět řídí hodnotou −ZaplatitCK. Zápis spropitného umožňuje přeplatek klienta prohlásit fiktivní platbou (viz 3.1.1.5) za spropitné a vyrovnat tak hodnotu ZaplatitKlientovi na nulu. Tato hodnota musí být před provedením operace kladná. V případě, že je částka větší než 1000, je uživatel vyzván k ověření, zda se skutečně jedná o spropitné. Před zápisem platby je ještě dotázán na důvod zápisu. 20 21

Elektronické bankovnictví nepřijímalo soubory podle specifikace formátu obsahující poznámku typu AV. eBanka byla později koupena Raiffeisenbank

28


Administrace tabulky Cestovky umožňuje spravovat tuto tabulku, přidávat nové cestovní kanceláře a upravovat jejich kontaktní údaje a nastavení. Správa bankovních spojení CK je podobná administraci cestovních kanceláří a umožňuje zadávat bankovní spojení v návaznosti na tabulku Cestovky. Potvrzování příchozích plateb zájezdů i poukazů je část aplikace popsaná v sekci 3.1.2. V této části existují nástroje pro potvrzování plateb a párování dosud nepřiřazených potvrzení plateb. 3.2.4

Fakturace provize – CRM_Finance.mdb

Účelem aplikace CRM_Finance.mdb je evidence faktur pro zaměstnavatele a faktur na provizi z prodeje zájezdů, jak je popsáno v části 3.1.3. Součástí aplikace je ještě sada finančních přehledů, která ale není významná pro prodejní proces, a nepoužívaná evidence přijatých faktur. Faktury pro zaměstnavatele jsou vystavovány ručně a jejich evidence je umístěna v této aplikaci, protože zde existují vhodné datové struktury a tiskové sestavy faktur. Kvůli tomu není možné faktury vystavovat ani tisknout přímo z CRM, což komplikuje proces jejich vystavení. Hlavní funkcí aplikace CRM_Finance.mdb je automatické generování, evidence a tisk faktur pro CK na provizi z prodeje zájezdů. Tyto faktury se vystavují vždy na konci měsíce a musí pokrýt všechny prodané objednávky, které mají datum fakturace ve zpracovávaném měsíci. Vlastní datum fakturace není jednotné pro všechny objednávky a jeho výpočet se řídí následujícím vztahem: ( Termin pro ProvizeHned = 0 DatumF akturace = ZapisProvize jinak Tato komplikace vychází ze zákona 235/2004 Sb. o dani z přidané hodnoty, který nepočítá s modelem cestovní agentury. Konkrétně s datem uskutečnění zdanitelného plnění (dále DUZP), které podle pravidel v zákoně není možné v případě s ProvizeHned 6= 0 určit. V případě bez provize hned vzniká nárok na provizi s termínem odjezdu, faktura je vystavena cestovní kanceláři bez problému s tímto jednoznačným DUZP a uhrazena běžným způsobem. V případě s provizí hned by podle zákona měla hodnota DUZP odpovídat dni, kdy byly přijaty peníze od klienta, ze kterých byla stržena částka provize a neodeslána do CK. Toto datum ovšem není možné stanovit z několika důvodů: • V době zasílání plateb klientem nemusí být výše provize ještě známá a nemůžeme si jí tedy nechat. Faktury by teoreticky měly být vystavovány v době, kdy není známá částka k fakturaci. • V případě více faktur od CK (zálohové a doplatkové) bývají částky sníženy o výši provize a není známo, jak jsou rozloženy mezi jednotlivé faktury a tedy, ve kterém případě nebyla provize odeslána. • Během prodejního procesu a placení může docházet ke změnám celkové ceny zájezdu i výše provize. V těchto případech by nebylo možné DUZP stanovit jednoznačně, protože ponechání provize by mohlo být rozděleno do několika dní. Z těchto důvodů je v případě ProvizeHned 6= 0 DUZP, a tedy datum fakturace, stanoveno na datum prvního zápisu provize. Toto je první okamžik, kdy je známá částka provize a je tedy možné fakturu vystavit. Samotný proces fakturace probíhá podle následujících kroků. 1. Je vybráno fakturační období. Fakturační období jsou v každém měsíci rozdělena na první a druhou polovinu měsíce. Toto rozdělení plyne ze zákona 563/1991 Sb. o účetnictví, který stanoví, že se faktura musí vystavit do 15 dnů od DUZP.


29

2. Na základě vybraného období se vygeneruje seznam cestovních kanceláří, u kterých existují prodané objednávky k fakturaci. 3. Uživatel z tohoto seznamu vybere všechny CK, kterým chce faktury vystavit. Ve výběru má možnost filtrovat podle státu cestovní kanceláře, ale proces fakturace může při jednom průchodu vystavovat faktury cestovním kancelářím z různých států. 4. Každé vybrané CK se vystaví nová faktura a vygeneruje se její účetní řada a pořadové číslo. Datum vystavení se nastaví na poslední den fakturačního období, datum splatnosti na 15. den následujícího měsíce. 5. Pro každou cestovní kancelář se projdou příslušné objednávky, zpracuje se provize s i bez DPH a zkontroluje se případný výskyt objednávky na stávajících fakturách. Pokud objednávka již existuje na jiné faktuře, rozhoduje o zařazení položky uživatel. Kromě kontroly, možnosti úprav a tisku je možné faktury ještě jednosměrně exportovat do účetního systému Helios. Tato funkce je prvním propojením CRM s účetním systémem a má za úkol ušetřit zbytečné opisování vygenerovaných dat do účetnictví. Faktury se exportují jednotlivě a tento export je pouze jednosměrný a jednorázový. Tzn. že úpravy provedené v Heliosu není možné zpět do CRM_Finance.mdb přenést jinak, než ručním opsáním. Podobně úpravy v CRM_Finance.mdb je možné přenést pouze po odstranění faktury z Heliosu. Další operace s fakturou (účtování, sledování úhrad) probíhají dále bez zásahu systému.

30

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

4 Analýza a návrh řešení Úkolem tohoto projektu je přenést všechny funkce související s financemi z CRM do Heliosu, nebo alespoň zajistit, aby se systém propojil s účetnictvím a o všech transakcích existovaly účetní záznamy. Ideální situací je v tomto případě stav, kdy Helios převezme jak funkčnost aplikací Platby.mdb a CRM_Finance.mdb, tak evidenci všech finančních záznamů jako takovou. Konkrétní rozhodnutí jak bude vlastní propojení vypadat jsou popsána v části 4.4. V každém případě bude nutné vyřešit způsob, jakým budou data uložena do účetního systému. Původní systém pracuje téměř výhradně s tabulkou Platby, ke které má volný přístup a nemá zásadnější omezení na zapisovaná data ani prováděné úpravy. Oproti tomu se účetní systémy řídí mnoha pravidly, která je nutné respektovat. Dalším zásadním okamžikem pro celý systém je datum 1. ledna 2009, kdy Slovenská republika přechází na jednotnou evropskou měnu – Euro.

4.1

Účetnictví

Jak bylo zmíněno výše, pravidla účetnictví se liší od způsobu, jakým pracoval původní systém. Ten byl založen čistě na funkčních požadavcích bez dodržování zásad účetnictví. Úkolem této části práce je popsat základní pojmy a způsob, jakým účetnictví pracuje, aby bylo možné namapovat finanční funkce CRM na nový systém. 4.1.1

Základní pojmy

Účetnictví zahrnuje vlastní sadu pojmů, od kterých se odvíjí celá práce s účetním systémem. Většina těchto označení je z pohledu původního systému nová, některé jsou však jen jiným označením stejné věci. Nenarazil jsem na žádný pojem, který by svým významem kolidoval, což umožňuje používat pro popis systému obě sady. To, oproti využití pouze jedné sady pojmů, umožňuje přesnější popis obou systémů1 . V té části účetnictví, která je využita pro propojení s CRM, se jedná o tyto pojmy: Účetní deník je místo, ve kterém jsou uloženy účetní doklady, tedy všechna zaúčtování. Do deníku se ukládá zaúčtování dokladů ze všech částí účetního systému. Řada dokladu je označení pro rozlišení skupin faktur, tedy zdrojových dokladů pro zaúčtování. Řadou se od sebe odlišují přijaté faktury od vydaných, ale také účel konkrétních dokladů. Speciální využití je u fakturace provize a poukazů, kde se každý rok vytváří nová řada, aby bylo možné z párovacího znaku rovnou určit, v jakém roce byla faktura vystavena. Párovací znak je obecné označení pro číslo, podle kterého se párují různé druhy záznamů. Tento výraz může být: • variabilní symbol na řádku bankovního výpisu, • variabilní symbol na řádku platebního příkazu, • číslo přijaté faktury – číslo uvedené na faktuře (nikoli řada a pořadové číslo pod kterým je faktura zapsána v účetnictví), • číslo vydané faktury – řada a pořadové číslo faktury doplněné zleva nulami. 1 Např. „objednávka“ je v účetnictví označována jako „zakázka“. Dvě různá označení umožní rozlišit, se kterým systémem se při použití konkrétního označení pracuje.


31

Období představuje časový úsek pro účtování nebo označení hospodářského roku. V případě agentury NetTravel se jedná o kalendářní roky. Každý rok tedy odpovídá jednomu období. Toto rozlišení se používá jak pro účetní mechanismy (jako součást identifikace účetních dokladů), tak pro práci s uživatelským rozhraním Heliosu (kde je většina přehledů filtrována právě podle vybraného období). Období stavu je dílčí rozlišení každého období. Zde období stavu představuje konkrétní měsíce. Pro propojení s CRM není období stavu významné, ale musí se vyplňovat u vytvářených dokladů. Tento pojem je důležitý pro jiné části účetnictví, jakou jsou například mzdy. Sborník je rozlišení skupin dokladů v účetním deníku. Podobně jako jsou faktury rozlišeny svou řadou, jsou i doklady v deníku rozlišeny sborníkem. Každá pokladna nebo banka (z bankovních výpisů) má vlastní sborník, ale více řad faktur může být účtováno do jednoho sborníku. To je například u faktur za provizi, kdy jsou řady ze všech roků (062, 072, 082) účtovány do společného sborníku 062. Existují ale i sborníky určené výhradně pro interní doklady, ke kterým neexistuje zdrojový doklad (viz 4.1.2). Sborník je také označován jako „druh účetního dokladu“. Číslo dokladu je obecně pořadové číslo libovolného záznamu (faktury, dokladu v deníku, pokladního dokladu atd.) a slouží jako součást účetní identifikace tohoto záznamu. Číslo řádku je pořadové číslo řádku v rámci konkrétního dokladu. Může se jednat jak o rozlišení řádků účetních dokladů v deníku, tak o pořadová čísla položek faktur, bankovních výpisů, pokladních dokladů a dalších. Účetní doklad představuje skupinu řádků v účetním deníku se stejným obdobím, sborníkem a číslem dokladu. Jednotlivé řádky v rámci dokladu jsou pak rozlišeny pořadovým číslem a liší se v částce, účetních účtech a dalších položkách. Doklad jako celek musí být vždy vyrovnaný (viz 4.1.3). Číslo účtu je virtuální rozlišení účtu, na který je připsána částka zaúčtovaného řádku účetního dokladu. Tato částka může být připsána buď na stranu „má dáti“ nebo „dal“. V souvislosti s bankovními výpisy je číslo účtu označováno také jako „účetní účet“, aby byla zdrůrazněna odlišnost od čísla bankovního účtu. Tvorba čísel účtů vychází z účtové osnovy, jejíž úprava je obsažena především v zákoně č. 563/1991 Sb., o účetnictví, a v prováděcí vyhlášce č. 500/2002 Sb., pro podnikatele. Podle této osnovy jsou první dvě2 číslice závazné a ostatní jsou zvoleny podle potřeb podnikatele. V této aplikaci je většina účtů šestimístných, ale pro účely práce není struktura významná. Popis účtů a účtování konkrétních případů je popsán v části 4.1.3. Má dáti představuje pravou stranu účtu a historicky vychází ze situace, kdy odběratel převzal zboží a dluží (čili „má dáti“) určitou sumu. Na základě toho vzniklo i označení „dal“ pro úhradu. Toto označení je ale rozšířeno na všechny účty takže prakticky je to pouze slovní pojem bez faktické návaznosti. Tato strana účtu bývá také označována jako debetní. Dal je levá strana účtu a vyrovnává stranu „má dáti“. Stejně jako v předchozím případě je to pouze slovní označení. Předkontace udává způsob zaúčtování dokladu. Jedná se o skupinu pravidel, podle kterých se částka dokladu umístí na konkrétní účetní účty. Pokud je předkontace úplná (vytváří vyrovnaný doklad), lze ji využít pro automatické účtování. Každá předkontace má své číslo, které je označováno jako „účetní kód“. Vyplnění tohoto čísla k dokladu definuje způsob, jakým bude doklad zaúčtován. 2

Do konce roku 2002 byly závazné první tři číslice.

32


Číslo zakázky představuje jedinečnou identifikaci zakázky v účetním systému a je uváděno jako vazba všech dokladů ke konkrétní zakázce. Hodnota čísla zakázky je stejná jako ID objednávky, kterou reprezentuje3 . Provozní doklad je libovolný záznam, který je evidován v účetnictví a nesouvisí s CRM. Mezi tyto doklady patří např. faktury za nájem a energie, náklady na marketing, mzdy a další. Zájezdový doklad označuje záznam, který souvisí s propojením Heliosu a CRM. 4.1.2

Systém dokladů

V účetním deníku jsou uloženy tzv. doklady. Každý takový doklad je jednoznačně identifikován trojicí skládající se z období, sborníku a pořadového čísla dokladu. Pravidlem, které musí každý doklad splňovat, je, že doklad musí být vyrovnaný. To znamená, že součet částek všech řádků na straně „má dáti“ musí být stejný jako součet částek všech řádků na straně „dal“. Doklad není v systému Helios uložen jako konkrétní záznam v nějaké tabulce, ale je reprezentován pouze množinou řádků, které mají stejné období, sborník a číslo dokladu. Jednotlivé řádky jsou pak rozlišeny pořadovým číslem v rámci dokladu a obsahují všechny potřebné informace, jako je částka, strana („má dáti“ vs. „dal“), číslo účtu a vazby na další části účetnictví, aby bylo možné určit původ dokladu4 . Způsoby, jakými může doklad vzniknout, jsou obecně dva: 1. Vytvoření interního dokladu. Přímo v deníku se vytvoří řádky dokladu a ručně se vyplní všechny potřebné údaje. Tato operace je vhodná pro interní převody peněz mezi jednotlivými účty, případně pro reprezentování operací, ke kterým není potřeba udržovat žádný zdrojový doklad. Vytváření interních dokladů bude vhodné pro reprezentaci spropitného nebo uplatnění některých druhů poukazů. 2. Zaúčtování zdrojového dokladu. Druhý způsob, jakým může vzniknout doklad v účetním deníku, je zaúčtování zdrojového dokladu. Tímto zdrojovým dokladem může být faktura, pokladní doklad, bankovní výpis, záznam o mzdě, případně další druhy dokladů. Zaúčtování na základě informací na dokladu a vyplněné předkontace připraví nový doklad. V systému Helios má uživatel zpravidla možnost provést ještě úpravy před uložením dokladu do deníku, případně doplnit řádky při neúplně (volně) definované předkontaci. Uložení dokladu do deníku tak obsahuje všechny vazby a cizí klíče potřebné pro určení původu dokladu. Na úrovni databáze je pak cizím klíčem zajištěno, že není možné odstranit zdrojový, zaúčtovaný doklad. 4.1.3

Účtování

Zaúčtováním dokladu nebo události, v případě interního dokladu, je myšleno vytvoření účetního dokladu v deníku. Tento doklad musí obsahovat minimálně dva řádky – jeden pro stranu „má dáti“ a druhý pro „dal“, a musí být vyrovnaný. To znamená, že se součet částek na jedné straně musí rovnat součtu částek na straně druhé. Toto vyplývá z principů účetnictví5 a všechny akce prováděné z CRM budou tento princip muset také respektovat. Dalším pravidlem, které je nutné respektovat, je uzavřenost období. Pokud je některé účetní období uzavřené, nesmí se v příslušných dokladech v deníku provádět žádné změny. Pokud 3

Primární klíč tabulky se zakázkami se také jmenuje ID, to ale nemá pro zbytek systému žádný význam. Mezi tyto vazby patří například číslo zakázky, číslo organizace, cizí klíče do tabulek s fakturami, pokladními doklady, bankovními výpisy a další. Tabulka obsahuje celkem několik desítek sloupců. 5 Dříve se účetnictví označovalo jako „podvojné účetnictví“ a současná „daňová evidence“ byla označována pojmem „jednoduché účetnictví“. 4


33

Vydaná faktura Účet Má dáti Dal Částka Popis 311xxx 11 900 Odběratelé (vydaná faktura) 648xxx 10 000 Ostatní provozní výnosy 343xxx 1 900 Daň z přidané hodnoty Příjem do pokladny za vydanou fakturu Účet Má dáti Dal Částka Popis 211xxx 11 900 Pokladna 311xxx 11 900 Odběratelé (vydaná faktura) Tabulka 4.1: Ukázka účtování vydané faktury Přijatá faktura Účet Má dáti Dal Částka Popis 321xxx 9 520 Dodavatelé (přijatá faktura) 501xxx 8 000 Nákup materiálu 343xxx 1 520 Daň z přidané hodnoty Výdaj z pokladny – úhrada přijaté faktury Účet Má dáti Dal Částka Popis 211xxx 9 520 Pokladna 321xxx 9 520 Dodavatelé (přijatá faktura) Tabulka 4.2: Ukázka účtování přijaté faktury vznikne situace, kdy bude nutné upravit nebo odstranit doklad z uzavřeného období, bude se muset vytvořit nový doklad v aktuálním období tak, aby se v součtu dostal požadovaný výsledek. V případě odstranění dokladu bude mít nový doklad stejnou strukturu jako původní, a to buď se zápornými částkami nebo s prohozenými stranami „má dáti“ a „dal“. Tabulka 4.1 ilustruje účtování vydané faktury a její úhradu v hotovosti. Na účtu 311xxx6 je předepsaná pohledávka vzhledem k odběrateli. Odběratel v tomto případě „má dáti“ částku na faktuře. Aby byl doklad vyrovnaný, na straně „dal“ se položky zaúčtují podle svého druhu, v tomto případě do výnosů a na účet evidující DPH. Úhrada této faktury v hotovosti vytvoří příjmový doklad, který je zaúčtován zde naznačeným způsobem. Na účtu 211xxx se eviduje stav pokladny, oproti 311xxx který vyrovná pohledávku faktury. Pohledávka uložená na účtu 311xxx je tedy vyrovnána. Účtování přijaté faktury, včetně její úhrady, je naznačeno v tabulce 4.2. Opět se eviduje závazek na 321xxx oproti skutečné položce na faktuře a DPH. Úhrada představuje výdajový doklad (rozmístění účtů je prohozené oproti příjmovému), jehož účtování je zobrazeno ve spodní části tabulky. Po těchto dvou operacích by na účtu 211xxx (a tedy fyzicky v pokladně) mělo zůstat částka 2 380. Poslední ukázka (tabulka 4.3) ilustruje případ, kdy jsou výše popsané faktury vzájemně započteny a pouze rozdíl doplacen hotově. 321xxx se zaúčtuje oproti 311xxx, čímž se 321xxx vyrovná na nulu a na účtu 311xxx zůstane závazek ve výši 11900 − 9520 = 2380. Tento závazek 6 Zástupné znaky „xxx“ označují libovolné trojčíslí podle potřeb podnikatele. V ukázkách značí, že sufix účtu není významný (může se lišit pro různé prefixy).

34

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Vzájemný zápočet faktur Účet Má dáti Dal Částka Popis 311xxx 9 520 Odběratelé (vydaná faktura) 321xxx 9 520 Dodavatelé (přijatá faktura) Výdaj z pokladny – úhrada nezapočteného zbytku faktury Účet Má dáti Dal Částka Popis 211xxx 2 380 Pokladna 311xxx 2 380 Odběratelé (vydaná faktura) Tabulka 4.3: Ukázka účtování zápočtu faktur

je pak uhrazen v hotovosti výdajovým pokladním dokladem stejným způsobem jako u první ukázky. Vlastní započtení faktur by se zde realizovalo interním dokladem, protože neexistuje žádný jiný záznam, který by tuto operaci reprezentoval a mohl být zaúčtován. Předčílí účtů v českém i slovenském Heliosu vychází historicky, z dob Československa, ze stejné účetní osnovy a většina účtů má v obou systémech stejné číslo. Analytické účty, evidující částky pro potřeby CRM, jsou vždy nastaveny pro oba systémy shodně.

4.2

Definice způsobu účtování

Jako reprezentace tabulky Platby se pro evidenci stavu financí použije účetní deník, ve kterém se bude vyplňovat číslo zakázky jako vazba na konkrétní objednávku. Různé druhy plateb pak budou rozlišeny účtem, na který budou částky zaúčtovány. Volba konkrétních čísel účtů je v kompetenci účetního oddělení s tou podmínkou, že se použijí stejná čísla v českém i slovenském Heliosu. Účetní oddělení dodává i čísla předkontací, ty se ale budou pro jednotlivé státy lišit. Předkontace jsou číslovány v pořadí vzniku a konkrétní číslo tedy závisí na počtu dříve vytvořených záznamů. Konkrétní hodnoty nejsou pro popis systému významné. Reprezentace původních faktur (od CK, pro zaměstnavatele i na provizi z prodeje zájezdů) bude odpovídat přímo fakturám v Heliosu. Je to nejjednodušší způsob párování a měl by zajistit přítomnost všech potřebných datových sloupců. Tam, kde pro reprezentaci platby nebude stačit interní doklad v deníku, bude rovněž vytvořena interní faktura, u které se budou ukládat potřebné dodatečné údaje. 4.2.1

Použité účty a řady dokladů

V tabulce 4.4 jsou popsány všechna použitá čísla účtů. Některá jsou dána předem (účty pro pokladny, banky, DPH nebo tržby), ostatní jsou vytvořena pouze pro evidenci zájezdového provozu. Pro jednodušší popis zde budu používat dvojice „má dáti“/„dal“oddělené lomítkem. Základ systému tvoří účty 325400, 325100 a 315400. 325400 sleduje částky na vystavených fakturách vzhledem k CK a klientovi. Faktura vystavená klientovi se účtuje 315400/325400. Tím se vytvoří informace o pohledávce od klienta na 315400 oproti závazku 325400. Účelem tohoto závazku je pouze sledovat faktury, které vystaví CK na cenu zájezdu. Takto vystavené faktury se účtují 325400/325100 čímž se závazek převede na účet 325100 – skutečný závazek vůči CK, který je nutné uhradit. 315400 je účet vytvořený pro sledování stavu financí vzhledem ke klientovi a jeho součet přímo odpovídá hodnotě ZaplatitKlientovi. Tato pohledávka vzniká zaúčtováním faktury

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Účet 211xxx 221xxx 311100 315400 315410 325001 325100 325110 325300 325310 325320 325400 343119 513100 518330 518340 548800 602100 648410 648800 800 801

35

Popis Pokladna – „xxx“ zastupuje konkrétní číslo účtu pro každou pokladnu. Bankovní účty – „xxx“ zastupuje konkrétní číslo pro každý bankovní účet. Odběratelé – vystavení faktury na provizi z prodeje zájezdů. Pohledávky – sledování stavu financí u objednávky vzhledem ke klientovi. Součet tohoto účtu odpovídá hodnotě ZaplatitKlientovi. Pohledávky – účtování speciálního případu při rezervaci pomocí SMS u klienta. Závazky – vyrovnání zakázek s ProvizeHned 6= 0 u faktur na provizi z prodeje zájezdů pro CK. Závazky – sledování stavu financí u objednávky vzhledem k CK. Součet tohoto účtu odpovídá hodnotě ZaplatitCK. Závazky – účtování speciálního případu při rezervaci pomocí SMS na straně CK. Závazky – prodané, neuplatněné poukazy. Na tomto účtu se evidují přijaté platby za poukazy a jejich uplatnění ke konkrétní zakázce. Závazky – uplatněné poukazy od CK. Na tomto účtu se eviduje uplatnění poukazů od CK. Závazky – uplatněné marketingové poukazy. Na tomto účtu se eviduje uplatnění marketingových poukazů. Závazky – stav tohoto účtu udává celkovou cenu zájezdu a tedy předpis pro fakturu klientovi ale i očekávané faktury od CK. DPH – prodej s 19% sazbou DPH u faktur na provizi z prodeje zájezdů pro CK. Náklady – účtování nákladů u uplatnění poukazu od CK v případě, kdy je poukaz využit pro zaměstnance na náklady NetTravel. Náklady – účtování nákladů na uplatněné marketingové poukazy. Náklady – účtování nákladů na uplatněné poukazu typu infocesta. Náklady – evidence úhrady části zájezdu (do CK i klientovi) ze spropitného. Tržby – provize z prodeje zájezdů u faktur pro CK. Tržby – účtování tržby za uplatněné poukazy od CK. Tržby – evidence spropitného od klientů i CK. Interní – předpis provize pro kontrolní účely. Interní – předpis provize pro kontrolní účely. Tabulka 4.4: Přehled použitých účtů

pro klienta 315400/325400. Nově se hodnota ZaplatitKlientovi vypočte ze všech řádků účetních dokladů s příslušnou zakázkou podle vztahu: ZaplatitKlientovi =

X i

(

−částkai pro účet = 315400 ∧ strana = „má dáti“ částkai pro účet = 315400 ∧ strana = „dal“

325100 je účet vytvořený pro sledování stavu financí vzhledem ke klientovi a jeho součet přímo odpovídá hodnotě ZaplatitCK. Závazek vzniká s přijatou fakturou od CK účtovanou 325400/325100, což znamená, že v novém systému je částka k úhradě do CK určena na základě vystavených faktur. Hodnota ZaplatitCK se opět vypočte ze všech řádků účetních dokladů s příslušnou zakázkou podle vztahu: ZaplatitCK =

X i

(

−částkai pro účet = 325100 ∧ strana = „má dáti“ částkai pro účet = 325100 ∧ strana = „dal“

Tabulka 4.5 popisuje všechny použité sborníky a řady faktur, které se do nich účtují. Sborníky bez uvedené řady faktur slouží pro zápis interních dokladů. Některé řady faktur (např.

36

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Sborník 023 030 031 032 062 062 068 068 069 076

Řada faktur 023

01* 0*2 0*1 068 0*6

Popis Přijaté faktury od CK Všechny druhy poukazů Přímé platby mezi klienty a CK Spropitné Faktury na provizi z prodeje zájezdů pro CK (pouze SK) Faktury na provizi z prodeje zájezdů pro CK (pouze CZ) Faktury pro zaměstnavatele klientů v roce 200* Faktury klientům reprezentující pohledávku Předpis provize Faktury na dárkové poukazy v roce 200*

Tabulka 4.5: Přehled použitých sborníků a řad faktur 0*2) se mění každý rok aby bylo přímo z označení možné poznat, do kterého roku faktura spadá. Namísto znaku * se pak dosazuje poslední číslice konkrétního roku. 0*2 tedy zastupuje řady faktur 062, 072 a 082. Všechny tyto řady se ale účtují do společného sborníku 062. 4.2.2

Účtování akcí CRM

Ke každé akci z CRM je zde popsán způsob, jakým bude v účetním systému reprezentována. 1. Vystavení faktury klientovi V okamžiku vzniku pohledávky u klienta (id_Stav ≥ 30, tj. „Smlouva podepsaná“) je klientovi vystavena faktura řady 068 účtovaná do sborníku 068. Tato faktura se netiskne ani nezasílá klientovi a slouží pouze pro interní evidenci. Pohledávku by bylo možné realizovat i interním dokladem, v tomto případě je ale potřeba i zdrojový doklad. U faktury se eviduje organizace a její případné bankovní spojení pro vrácení přeplatku klientovi. 315400 / 325400 – Pohledávka od klienta (ZaplatitKlientovi) oproti závazku, který představuje očekávanou výši faktur od CK. 2. Vystavení faktury pro zaměstnavatele Faktura pro zaměstnavatele je vystavena jako běžná vydaná faktura se stejnou řadou 0*1 (viz 4.5) jako v původním systému a na faktuře je jediná položka s vazbou na příslušnou zakázku. Tato faktura se po vystavení neúčtuje, ale čeká v nezaúčtovaném stavu na svou úhradu. V momentě úhrady faktury se faktura zaúčtuje stejným způsobem, jako faktura pro klienta. Na obou účtech byl ale vznikla částka vyšší než cena zájezdu, a proto se faktura 068 pro klienta i její zaúčtování sníží. Tato operace zajistí, že nedojde k navýšení pohledávky u klienta a navíc zvýrazní případný přeplatek na faktuře 068. 315400 / 325400 – Stejné chování jako v případě faktury pro klienta 068. 3. Zápis faktury od CK Faktura od CK se zapisuje pod řadou 023 a účtuje rovněž do sborníku 023. Představuje závazek vůči CK a odvíjí se od ní hodnota ZaplatitCK. Narozdíl od původního systému je zde správná evidence faktur, včetně dobropisů, důležitá a určuje skutečnou výši závazku. Dobropisy se zapisují se zápornou částkou a účtují stejným způsobem jako faktury. 325400 / 325100 – Závazek z účtu 325400 (očekávané faktury od CK) převede na skutečný závazek 325100 vůči CK a současně promítne tuto hodnotu do ZaplatitCK.


37

4. Zápis provize Při zápisu provize do CRM je částka zadána i do účetnictví. Provize se umísťuje na interní doklady sborníku 069 a interní účty. Zápis slouží pouze pro kontrolní účely a nemá zásadní vliv na zbytek systému. 800 / 801 – Pouze evidence na dvou interních účtech bez návaznosti na zbytek systému. 5. Platby mezi klientem a NetTravel hotově Klienti mají možnost složit platbu za zájezd v hotovosti na některé z poboček, nebo si zde vyzvednout případný přeplatek. Platba v hotovosti vytvoří pokladní doklad v pokladně příslušné pobočky a tento doklad zaúčtuje. Doklady jsou účtovány do sborníků konkrétních pokladen, jejichž čísla nejsou pro chod systému významná. Zaúčtování se provádí na základě nastavené předkontace každé pokladny. • Příjmový pokladní doklad 211xxx / 315400 – Účet pokladny oproti vyrovnání hodnoty ZaplatitKlientovi. • Výdajový pokladní doklad 315400 / 211xxx – Obrácený případ než příjmový doklad, peníze jdou opačným směrem. 6. Platby mezi klientem a NetTravel převodem Pří úhradě platby k zájezdu (k faktuře 068 pro klienty nebo 0*1 pro zaměstnavatele) se účtuje pouze bankovní výpis proti hodnotě ZaplatitKlientovi podobně, jako je to u hotovostních plateb. Převody jsou účtovány do sborníků konkrétních bankovních účtů, jejichž čísla nejsou pro chod systému významná. Zaúčtování se provádí na základě nastavené předkontace. • Příchozí platba od klienta 221xxx / 315400 – Konkrétní bankovní účet oproti hodnotě ZaplatitKlientovi. • Vrácení přeplatku klientovi 315400 / 221xxx – Obrácený případ než příchozí platba. 7. Přímá platba mezi klientem a CK V některých nestandardních případech odešle klient platbu přímo do cestovní kanceláře. Ta i v tomto případě musí zaslat fakturu na cenu zájezdu a tato faktura musí být takovou platbou uhrazena. U plateb přímo do CK nejdou peníze přes NetTravel, takže jediný způsob, jakým může být platba reprezentována je vzájemný zápočet faktury klientovi a od CK interní dokladem. Tento doklad je účtován do sborníku 031. • Platba klienta přímo do CK 325100 / 315400 – Závazek vůči CK je započten s pohledávkou u klienta. • Vrácení částky z CK přímo klientovi 325100 / 315400 – Vrácení přeplatků z CK je účtováno stejně, ale částka je uvedena s opačným znaménkem.

38

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 8. Platby mezi NetTravel a CK převodem Odchozí platby z NetTravel do CK hradí závazky faktur od CK řady 023. Tyto platby vyrovnávají hodnotu ZaplatitCK. Převody jsou účtovány do sborníků konkrétních bankovních účtů, jejichž čísla nejsou pro chod systému významná. Zaúčtování se provádí na základě nastavené předkontace. • Odchozí platba do CK 325100 / 221xxx – ZaplatitCK oproti účtu konkrétního bankovního spojení. • Příchozí platba z CK 221xxx / 325100 – Opačný případ než odchozí platba. 9. Uplatnění poukazu Uplatnění každého poukazu se liší podle jeho typu a provádí se do společného sborníku 030 interním dokladem. • Běžný dárkový poukaz 325300 / 315400 – Fond peněž obdržených za dárkové poukazy oproti vyrovnání hodnoty ZaplatitKlientovi. Toto vyrovnání se chová jako platba od klienta ve výši poukazu. • Marketingové poukazy Tyto poukazy jsou hrazeny na náklady společnosti NetTravel a proto se zde navíc vyplňuje nákladové středisko marketing. 518330 / 325320 – Náklady na marketingové poukazy oproti evidenci uplatněných marketingových poukazů. 325320 / 315400 – Evidence uplatněných marketingových poukazů na vyrovnání ZaplatitKlientovi. • Poukazy typu infocesta Podobně, jako v případě marketingových poukazů, jsou i poukazy typu infocesta hrazeny na náklady společnosti NetTravel a proto se u účtování vyplňuje navíc nákladové středisko prodej. 518340 / 315400 – Náklady na poukazy typu infocesta oproti vyrovnání pohledávky u klienta ZaplatitKlientovi. • Poukazy od CK – varianta s úhradou od klienta Uplatnění poukazu od CK ve vlastnictví NetTravel na zájezd, který klient uhradil běžným způsobem. V tomto případě se musí uplatnění zaúčtovat do tržeb protože se jedná o zisk společnosti NetTravel. 325310 / 648410 – Evidence uplatněných poukazů od CK oproti tržbě za uplatněný poukaz. 325100 / 325310 – Vyrovnání hodnoty ZaplatitCK (a tedy platba do CK) oproti uplatněnému poukazu. • Poukazy od CK – varianta bez úhrady od klienta Existují případy, kdy poukaz od CK uplatní sami klienti nebo se poukaz ve vlastnictví NetTravel uplatní na zájezd zaměstnance na náklady společnosti. V takovém případě neexistuje příchozí platba od klienta a při účtování se musí vyrovnat. 325310 / 648410 – Evidence uplatněných poukazů od CK oproti tržbě za uplatněný poukaz.


39

325100 / 325310 – Vyrovnání hodnoty ZaplatitCK (a tedy platba do CK) oproti uplatněnému poukazu. 513100 / 315400 – Náklady na poukaz oproti vyrovnání ZaplatitKlientovi. 10. Spropitné V některých případech nepožadují klienti, cestovní kanceláře nebo NetTravel vrátit drobné přeplatky u zájezdů. Tyto přeplatky se tak prohlásí za spropitné, účetně se evidují a zapisují jako zisk nebo náklad. Kromě případu, kdy si peníze nechává NetTravel může vzniknout situace, kdy je ze spropitného hrazen nedoplatek některé strany. Ze spropitného jsou například hrazeny situace, kdy je chybou prodejce klientovi špatně vyčíslena kalkulace na cestovní smlouvě a dodatečně vznikne nedoplatek. Spropitné se účtuje interními doklady ve sborníku 032. • Od klienta, klient nechce vrátit přeplatek 315400 / 648800 – Z fondu klienta jsou peníze převedeny do evidence tržeb ze spropitného. • Úhrada za klienta ze spropitného 548800 / 315400 – Opačný případ než předchozí, převod na účet klienta je realizován jako náklady ze spropitného. • Od CK, CK nevyžaduje zaslat nedoplatek 325100 / 648800 – Nedoplatek do CK je převeden na stejný účet tržeb jako v případě klienta. • NetTravel nevyžaduje přeplatek z CK 548800 / 325100 – Odpovídající opačná situace, kdy je platba od CK nahrazena na náklady společnosti NetTravel ze spropitného. 11. Řešení speciálního případu rezervace přes SMS Skupina několika cestovních kanceláří prodává své zájezdy pomocí rezervačního systému RezaPortal7 . V tomto případě klienti vytváří rezervace přímo v CK a potvrzují je zasláním SMS v ceně 79 Kč. Tato částka je následně považována za speciální slevu, o kterou se klientovi sníží částka k úhradě. Systém bohužel není nastaven příliš vhodně a výše faktur od CK, a tedy celková cena zájezdu, zahrnuje tuto částku k úhradě. V praxi to vypadá tak, že klient uhradí cenu SMS třetí straně a zbytek ceny zájezdu společnosti NetTravel. Cestovní kancelář vystaví fakturu na celou částku a NetTravel tedy hradí pouze část těchto faktur. Tím v systému zůstává pohledávka u klienta a závazek vůči CK. Aby bylo možné systém odstínit od tohoto problému, jsou prováděny úpravy v zaúčtování faktur od CK i klientům. Částky na účtech 315400 i 325100 jsou sníženy o cenu SMS a ta je připsána na stejný doklad na účet 315410, resp. 325110. Tím se částka oddělí od zájezdového provozu a hodnoty ZaplatitCK a ZaplatitKlientovi se tak vyrovnají. Přebytek těchto účtů je vyrovnáván ručně speciálními fakturami, které ale již nejsou součástí systému. 315400 / – – Na původním zaúčtování faktury pro klienty řady 068 se sníží částka o cenu SMS. 315410 / – – Tato částka se zaúčtuje na stejnou stranu, stejného dokladu, ale pod jiný účet. 7

http://www.rezaportal.com/

40

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ – / 325100 – Podobně se původní částka faktury 023 sníží o cenu SMS. – / 325110 – A rozdíl se opět přidá na stejný doklad pod jiný účet, aby doklad jako takový zůstal vyrovnaný.

12. Faktury na provizi pro CK Společnost NetTravel je provizní prodejce a jako takový fakturuje pořádajícím cestovním kancelářím provizi z prodeje zájezdů. Faktury jsou vystavovány v řadě 0*2 a účtovány do sborníku 062. Samotný proces fakturace je popsán v části 3.2.4. Některé položky faktury mohou být již uhrazeny formou provize hned. Takto označené položky jsou na faktuře uvedeny jako již uhrazené a při samotném účtování faktury je tato skutečnost zohledněna. • Vystavení faktury 311100 / 602100 – Faktura odběrateli oproti tržbám z provize. Na tento účet se účtuje buď základ daně z přidané hodnoty nebo položky s nulovou sazbou DPH. 311100 / 343119 – Opět vystavená faktura oproti účtu DPH 19 %. • Úhrada převodem z CK 221xxx / 311100 – Úhrada faktury (nebo její části bez provize hned) je účtována na konkrétní bankovní spojení oproti faktuře odběrateli. Toto účtování je provedeno až na základě úhrady od CK. • Úhrada formou provize hned 325001 / 311100 – V případě provize hned je příslušná částka zaúčtována hned při vytvoření faktury na zvláštní účet evidující objednávky s provizí hned oproti samotné faktuře. Tím se sníží pohledávka u CK o příslušnou částku. 13. Faktury na poukazy V novém systému se ke každému dárkovému poukazu vystavuje faktura a klienti platby za poukazy zasílají jako úhradu této faktury. Ty se vystavují s řadou 0*6 ale při vystavení se neúčtují. Faktury čekají nezaúčtované na svou platbu, podobně jako v případě řady 0*1 pro zaměstnavatele, a v okamžiku úhrady dojde k jejich zaúčtování do sborníku 076 a tedy i připsání peněž do fondu poukazů. • Vystavení faktury 311100 / 325300 – Vystavení faktury vzhledem k odběrateli oproti závazku, který představuje fond poukazů. • Úhrada hotově 211xxx / 311100 – Úhrada v hotovosti na účet konkrétní pokladny oproti faktuře odběrateli. Na účtu 325300 tedy zůstane fond pro dárkové poukazy ze kterého jsou hrazeny platby klientů ZaplatitKlientovi. • Úhrada převodem 221xxx / 311100 – Úhrada převodem na účet konkrétního bankovního spojení oproti faktuře odběrateli. Na účtu 325300 tedy zůstane fond pro dárkové poukazy ze kterého jsou hrazeny platby klientů ZaplatitKlientovi.


4.3

41

LCS Helios Orange

Aplikace LCS Helios Orange8 je informační systém pro střední a menší firmy. Aplikace je vytvořena v prostředí Delphi a jako datové úložiště využívá MS SQL Server 2005. Společnost NetTravel má k dispozici dvě licence, jednu pro Českou republiku a druhou pro Slovenko. Jedním z hlavních kritérií pro výběr účetního systému byla možnost budoucího rozšíření, které je realizováno tímto projektem. Aplikace Helios podporuje celou řadu rozšíření a přizpůsobení, která jsou popsána v této části dokumentu. Mezi povolené úpravy patří také možnost práce s daty na úrovni externích SQL procedur. Při takových úpravách je ale nutné respektovat strukturu a pravidla používaná systémem, aby nedošlo k poškození nebo vytvoření nekonzistentních dat. 4.3.1

Struktura a možnosti přizpůsobení

V systému Helios existuje několik jmenných konvencí pro názvy objektů v SQL databázi. • Název tabulky nebo SQL view začíná prefixem „Tab“. • Většina procedur začíná prefixem „hp_“, existují ale i jiné řady prefixů. • Systémové triggery začínají prefixem „ht_“. • Uživatelsky definovaný přehled (SQL view) musí začínat prefixem „hvw_“ (viz 4.3.5.2). • Uživatelsky definovaná procedura (SQL stored procedure) musí začínat prefixem „ep_“. • Uživatelsky definovaný trigger musí mít název ve tvaru „et_JmenoTabulky“ (viz 4.3.7). Na úrovni SQL poskytuje systém přístup přímo ke svým tabulkám. Nejčastěji používané tabulky jsou následující. 1. Číselníky: TabObdobi – číselník období, TabObdobiStavu – číselník období stavu, TabZakazka – číselník zakázek, TabCisOrg – číselník organizací, TabBankSpojeni – číselník bankovních spojení organizací, TabPenezniUstavy – číselník peněžních ústavů (bank). 2. Účetní deník: TabDenik – tabulka ukládající řádky účetních dokladů v deníku. 3. Pokladna TabPokladna – hlavička pokladního dokladu. 4. Faktury: TabDokladyZbozi – tabulka se všemi fakturami (přijaté i vydané). Druh faktury se pozná podle hodnoty sloupce DruhPohybuZbo – 13 = faktura vydaná, 18 = faktura přijatá. Faktura sama o sobě může obsahovat 3 jednoduché textové položky bez využití tabulky TabPohybyZbozi. Použití jednoduchých položek se vylučuje s použitím položek z následující tabulky. 8

http://www.helios.eu/

42

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ TabPohybyZbozi – Detailní popis položek faktury. TabUhrady – Úhrady přijatých i vydaných faktur. 5. Bankovní výpisy: TabBankVypisH – hlavička bankovního výpisu, TabBankVypisR – řádek bankovního výpisu obsahující konkrétní údaje o proběhlé platbě. 6. Platební příkazy: TabPlatTuz – hlavička tuzemského platebního příkazu, TabPlatTuzR – řádek tuzemského platebního příkazu obsahující pouze základní údaje, TabPlatTuzRDetail – detail řádku obsahující podrobné informace o platbě a vazby na návazné tabulky. 7. Ostatní TabUzivOzn – Tabulka udržující seznam uživatelsky označených záznamů pro každého uživatele. Pomocí této tabulky a uživatelského sloupce _HeIQ_UzivOzn je možné ukládat označení pro libovolnou tabulku. #TabExtKom – Dočasná tabulka, která je vytvořena před voláním externí stored procedury (viz 4.3.5.1). Do této tabulky je možné ukládat informace pro uživatele, které jsou zobrazeny po ukončení běhu procedury. #TabDenikUcto – Toto je dočasná tabulka, ve které jsou uloženy řádky účetního dokladu během přípravy. Po ukončení úprav je obsah tabulky přenesen do deníku.

4.3.2

Uživatelské sloupce

Systém Helios umožňuje ke každé své tabulce přidat uživatelsky definované sloupce. Ty jsou vždy umístěny ve stejnojmenné tabulce se sufixem „_EXT“9 . Sloupec může být jak samostatným datovým sloupcem, tak sloupcem počítaným. U každého takového sloupce je možné definovat název, datový typ, nadpis pro zobrazování, případně způsob zobrazení a editace. Existuje i několik speciálních možností jak sloupec pojmenovat, aby plnil speciální úkoly. Sloupce s prefixy „_HeIQ_“ mají speciální význam10 a umožňují měnit barvu a styl písma v přehledu, podbarvení řádku, případně ovlivnit vzhled jen konkrétní hodnoty (nikoli celého řádku). Pro učení správného čísla barvy je, kromě přednastavených hodnot 1 až 4, možné využít tlačítko „Přenos barvy do definice“ z formuláře definujícího externí sloupec. Dalším speciálním sloupcem je _HeIQ_UzivOzn. Pokud je definován jako CAST(CASE WHEN EXISTS( SELECT * FROM TabUzivOzn WHERE TabName = ’JmenoTabulky’ AND Uzivatel = SUSER_SNAME() AND IDx = JmenoTabulky.ID ) THEN 1 ELSE 0 END AS BIT) umožňuje klávesou Insert uživatelsky označovat záznamy. Seznam takto označených záznamů je dostupný v tabulce TabUzivOzn pro každou tabulku a každého uživatele. Definice uživatelských sloupců se provádí v Menu / Možnosti / Konfigurace, položka Systémové konstanty. Zde se vybere konkrétní databáze pro úpravy11 a po kliku pravým tlačítkem myši se z kontextového menu zvolí položka Tabulky a pohledy. Ta zobrazí seznam všech dostupných tabulek a opět v kontextovém menu konkrétní tabulky je položka Uživatelské sloupce 9

Například sloupce k tabulce TabZakazka jsou umístěny do tabulky TabZakazka_EXT. Např. _HeIQ_Barva umožňuje změnit barvu písma v řádku. 11 Úpravy je možné provádět pouze v aktuální databázi. 10


43

(Ctrl+Shift+U ), která zobrazí seznam definovaných sloupců označené tabulky. Zde je již možné sloupce upravovat, přidávat nebo odebírat. 4.3.3

Definované přehledy

Další možností přizpůsobení jsou definované přehledy. Definovaný přehled je prakticky SQL view, jehož název musí začínat prefixem „hvw_“, s definovanými parametry pro zobrazení v uživatelském rozhraní. Součástí definice jsou i informace o zobrazení jednotlivých sloupců. Zde je možné definovat šířku, viditelnost sloupce, masku a další parametry jakými je například přístupnost pro tisk nebo součty v přehledech. Vytvořené definované přehledy je možné zobrazovat jako samostatná okna pomocí externích akcí (viz 4.3.5.2) nebo je přidávat do hlavního stromu jako samostatné listy (viz 4.3.4). K přehledům je možné definovat sadu externích akcí, které přehled umožňuje. Nelze ale vytvořit aktivní přehled, který by simuloval funkce systémových přehledů jakými jsou například účtování záznamů, otevírání dalších oken a podobně. Pro zpřístupnění systémových funkcí je nutné otevřít systémový přehled pomocí pluginu, jak je popsáno v části 4.3.5.4. Definice přehledů je přístupná přímo ze stromové struktury systémových přehledů v hlavním okně, konkrétně v části Nástroje přizpůsobení / Definované přehledy. 4.3.4

Úpravy hlavního stromu – soudečky

Jako jedno z možných rozšíření je podporováno i přidávání nových větví do stromu s přehledy v hlavním okně. Definice se provádí v části Nástroje přizpůsobení / Uživatelské soudečky. Soudečky je možné vytvářet pouze jednoúrovňové a při definici se musí uvést číslo přehledu, který má být pod položkou zobrazen. Jako číslo přehledu se uvádí hodnota 100000+číslo, které je vidět v přehledu Nástroje přizpůsobení / Definované přehledy. 4.3.5

Externí akce

Nejdůležitější možností rozšíření, kterou systém poskytuje, jsou externí akce. Ty umožňují do kontextového menu libovolného přehledu umístit vlastní položky a u těchto položek definovat akce, případně posloupnosti akcí. U každé akce se kromě nápovědy a poznámky definují následující parametry: Typ akce udává jednu ze čtyř možných akcí, která bude provedena při spuštění. Je zde výběr z těchto možností: • • • •

procedura, přehled, program, plugin.

Umístění akce udává číslo přehledu, ve kterém je akce dostupná. Pro uživatelsky definované přehledy, podobně jako při úpravách stromu v hlavním okně, se udává číslo 100000+skutečné číslo přehledu. Popis akce je název položky v submenu. Návazná akce je nepovinný odkaz na jinou externí akci, která je spuštěna ihned po skončení aktuální akce. Tato vlastnost umožňuje definovat složitější posloupnosti jednotlivých akcí. Hotkey je klávesová zkratka, která v daném přehledu umožní spustit akci. Je zde možnost využít pouze omezenou skupinu zkratek nabízených systémem. Lze ale předefinovat klávesu enter, tedy výchozí akci při otevření záznamu.

44


Veřejná akce umožňuje vytvořenou akci schovat z menu. Toto je vhodné při využití posloupnosti akcí, kdy není vhodné aby byla posloupnost spouštěna od prostředního kroku. Zobrazit oznámení o ukončení akce je možnost zobrazit zprávu při ukončení procedury nebo externího programu. Název podmenu udává skupinu, ve které bude akce zařazena v kontextovém menu. Před tento název bude v uživatelském rozhraní dosazen znak hvězdičky. Pořadí v podmenu umožňuje řídit pořadí, v jakém budou zobrazeny akce v rámci stejného submenu. Další možnosti nastavení se liší podle jednotlivých typů akcí. Správa externích akcí je přístupná z hlavního okna v přehledu Možnosti přizpůsobení / Externí akce. Zde jsou zobrazeny všechny přístupné akce a jejich editace, přidávání i odstranění. 4.3.5.1

Stored procedury

Externí procedury jsou základním stavebním kamenem všech úprav a zásahů do dat Heliosu. Externí akce typu „procedura“ umožňuje spustit libovolnou12 proceduru na SQL serveru a této proceduře předat předdefinovanou sadu parametrů. Tato sada může obsahovat tři druhy parametrů, které jsou řazeny v tomto pořadí: 1. Konstantní parametry oddělené čárkou, které jsou zadány při definici externí akce do pole „Parametry“. 2. Přednastavené parametry ze druhé záložky, na které bude uživatel dotázán při spuštění akce. Každý parametr má svůj název, typ a přednastavenou hodnotu (kromě upozornění). Typ může nabývat těchto hodnot: Text umožňuje zadat libovolnou textovou hodnotu. Číslo dovoluje zadat desetinnou hodnotu a při spouštění procedury bude uživateli nabídnuta malá kalkulačka jako u všech číselných polí. Datum nabízí zadání konkrétního data, opět s možností zobrazení kalendáře. Volba předává hodnotu typu BIT a zobrazuje uživateli checkbox pro určení hodnot ano/ne. Helios číselník přenáší hodnotu libovolného sloupce z libovolného systémového přehledu. Uživateli je při zadávání nabídnuta možnost přehled otevřít a zvolit řádek pro přenos přímo ze zobrazeného přehledu. Navíc je zde možnost doplnit podmínku WHERE, která může omezit zobrazené řádky podle požadovaných kritérií. Definovaný přehled se chová stejně jako Helios číselník, ale umožňuje vybrat ze seznamu definovaných přehledů. Soubor předává, stejně jako pole text, textovou hodnotu s možností otevření dialogu pro výběr cesty k souboru. Upozornění je pouze textová poznámka, která bude zobrazena uživateli v okně se zadáváním ostatních parametrů. 3. Parametry Helios. Při definici akce je možné určit, že se jako poslední parametr předá ID aktuálně označeného záznamu. Pokud je s pomocí klávesy Shift vybráno více záznamů, je procedura zavolána pro každý záznam a jako poslední parametr je uvedeno vždy konkrétní ID. 12

Jméno procedury musí začínat prefixem „ep_“ nebo názvem externí databáze.


45

Před spuštěním procedury je vytvořena dočasná tabulka #TabExtKom. Do té lze ukládat zprávy o průběhu akce pro uživatele, které budou zobrazeny po ukončení celé akce. Kromě těchto zpráv existuje ještě jedna možnost, jakou je možné proceduru ukončit – vyvoláním chyby číslo 50000. To je uživatelsky definovatelná chyba SQL serveru, která se vyvolává příkazem RAISERROR. Čísla zpráv větší nebo rovny 50000 se považují za uživatelsky definované a zprávy s vyšším číslem než je 50000 využívá Helios pro své vlastní chybové zprávy. Kromě čísla dovoluje RAISERROR definovat vlastní text. Při ukončení procedury tímto způsobem je uživateli zobrazena chybová hláška a obsah tabulky #TabExtKom není zobrazen. 4.3.5.2


Tento druh externí akce umožňuje zobrazení libovolného přehledu v samostatném okně. Lze vybrat jak systémové, tak uživatelsky definované přehledy. Při definici lze zadat dodatečnou podmínku WHERE, která omezí zobrazovaná data. Jako součást této podmínky se lze odkazovat na parametry definované stejně jako u uložených procedur. Pro odkazy na konkrétní hodnoty se používají zástupné symboly HIQParX, kde X je pořadové číslo atributu ze druhé záložky. 4.3.5.3

Externí programy

Spuštění externího programu je další možnost, kterou definice externí akce nabízí. Lze zadat cestu ke spouštěnému programu, pevné parametry a parametry ze druhé záložky. Bohužel nelze předat ID aktuálně označeného záznamu. Předání označeného záznamu lze zařídit předřazenou akcí, která pomocí procedury uloží aktuální ID do databáze a spuštěný program si tuto hodnotu může přečíst. Další komplikací je, že aplikace je spouštěna synchronně a Helios přestane odpovídat až do chvíle ukončení spuštěného programu. Spouštění aplikace v pozadí nelze nastavit. 4.3.5.4

Pluginy

Plugin[2] je poslední typ externí akce a umožňuje provádět další operace s uživatelským rozhraním. Plugin je fyzicky realizován formou dynamické knihovny, která využívá registruje vlastní COM server. Ten je realizován třída implementující interface IHePlugin a jeho jedinou metodu Run. Tato metoda je volána při spuštění externí akce a má jediný parametr typu IHelios 13 , který předává referenci na spuštěný systém. Pomocí této reference je možné provádět operace s rozhraním, jakými jsou otevírání přehledů a práce s nimi, změny filtrů, tisk formulářů označování záznamů a další. 4.3.6

Tiskové formuláře

Systém Helios obsahuje celou řadu tiskových formulářů pro nejrůznější účely. Od jednoduchých přehledů přes různé varianty faktur až po složité výkazy. Součástí systému je i možnost vytvořit kopii stávající tiskové šablony a tu libovolně upravit. Toto je vhodné například v případě, kdy se na fakturu musí přidat hodnota uživatelsky definovaného sloupce nebo je potřeba upravit vzhled faktury. Jako prostředí pro úpravy tiskových sestav je použita aplikace ReportBuilder14 . Ta umožňuje definovat libovolné sestavy a obsahuje i možnost základního skriptování v omezené verzi jazyka Pascal pro ošetření událostí. 13 14

https://forum.helios.eu/orange/doc/cs/Helios_Orange_Interface http://www.digital-metaphors.com/

46


4.3.7

Databázové triggery

Ke každé tabulce v databázi Heliosu je možné vytvořit jeden trigger, který bude zpracovávat události z této tabulky. Jméno triggeru musí být ve tvaru „et_JmenoTabulky“, což omezuje počet triggerů pouze na jeden. Uvnitř triggeru je možné zpracovávat libovolné údaje podle pravidel SQL serveru. K dispozici je přístup k původním i novým hodnotám změněných záznamů i informace o druhu změny. Během provádění operací uvnitř triggeru, a v návazných procedurách, je nutné dávat pozor na práci s dočasnými tabulkami, jakou je například #TabDenikUcto. Účtování jiné faktury během provádění triggeru spuštěného během účtování může způsobit ztrátu původních dat. Další problém, který může nastat při práci s triggerem, je změna hodnoty @@IDENTITY. Trigger, který při spuštěný během vytvoření nového záznamu, uloží jiný záznam do tabulky může změnit tuto hodnotu a narušit tak zbytek procesu přidávání záznamu. Operace přidávání bývá zpravidla rozdělena do několika kroků a změna hodnoty @@IDENTITY může způsobit ztrátu dat.

4.4

Návrh implementace

Samotný návrh implementace vychází z možností a struktury systému Helios. Musí se zde respektovat postupy a pravidla, kterými se řídí vnitřní procesy a manipulace s daty. Dodržování těchto pravidel by mělo zajistit jak správnou evidenci informací, tak konzistentní data pro účetnictví a uživatelské rozhraní Heliosu. Pro zjištění všech potřebných informací pro vývoj je k dispozici několik zdrojů, ze kterých lze čerpat. Samotný Helios implementuje sadu klávesových zkratek, které pomáhají s technickou identifikací záznamů a umožňují tak lepší orientaci v systému z pohledu vývojáře. Počátečním problémem je vždy určit v jaké tabulce jsou uložena data a jaké obsahuje sloupce. Pro zjištění těchto informací jsou k dispozici následující klávesové zkratky: • Alt+B v libovolném přehledu – zobrazí název tabulky a ID označeného záznamu, dále pak možnost zobrazit cizí klíče a informace o datových sloupcích, • Alt+B ve výběru sloupců k zobrazení – po zadání hesla nabídne i skryté systémové sloupce15 , • Ctrl+Q v libovolném přehledu – po zadání hesla zobrazí SQL dotaz, kterým se získávají data z databáze16 , • Stisk klávesy Ctrl během kliknutí na tlačítko „Definice“ v editaci tiskového formuláře omezí načítání dat pro ReportBuilder a zásadním způsobem tak urychlí práci s tímto editorem. Dalším užitečným zdrojem informací je webová stránka[2] určená pro vývojáře. Kromě popisu částí systému a všech informací o technologii Helios Orange Plugin, včetně potřebných knihoven, je zde ke stažení poslední verze dokumentace tabulek v souboru typu MS Help s příponou „chm“. Obsahem tohoto souboru je databázový popis všech tabulek, vazeb mezi nimi, návazných triggerů a další informace. Hlavním přínosem je výpis všech sloupců systému a jejich krátký popis. Součástí tohoto popisu bývají u číselníkových sloupců zdokumentovány významy jednotlivých hodnot17 . 15

Sloupce jako například ID nejsou běžně uživatelům dostupné a nemohou být přidávány do sestav. Pro obnovení normální funkce systému je nutné restartovat Helios. 17 Např. TabDokladyZbozi.DruhPohybuZbo = 13 označuje fakturu vydanou, hodnota 18 fakturu přijatou, TabDenik.Strana = 0 znamená „má dáti“, 1 = „dal“ a další. 16


47

Zmíněné zdroje poskytují dostatek informací pro orientaci v datech a pochopení jejich struktury, neříkají ale nic o procesech, jakými je s daty manipulováno. Pro pochopení práce s daty je jediným spolehlivým zdrojem informací metoda reverzního inženýrství na úrovni SQL transakcí. MS SQL Server a příslušné MS SQL Server Management Studio obsahuje nástroj SQL Server Profiler, který umožňuje sledovat všechny spuštěné příkazy ve vybrané databázi. Vzhledem k množství operací, které server zpracovává, je vhodné před spuštěním nového záznamu nastavit filtr pro název aplikace na hodnotu „Helios%“ a současně filtr na jméno sledovaného uživatele. Toto nastavení omezí sbíraná data na nutné minimum. Po spuštění záznamu se v Heliosu ručně provede sledovaná operace (např. zaúčtování faktury) a záznam se zastaví. Výsledkem jsou všechny dotazy do databáze, které systém provedl během realizace celé akce. Tento záznam obsahuje velké množství vedlejších dotazů, které nesouvisí s prováděnou akcí a pro pochopení procesu by měly být ignorovány. Jsou to typicky zjišťování nastavení uživatelského prostředí, aktuálních informací o systému, kontrola období a dotazy pro naplnění přehledů daty. Z pohledu sledování konkrétní operace jsou zajímavé pouze dotazy obsahující operace INSERT, UPDATE, DELETE nebo EXEC, případně předcházející SELECT pro načtení potřebných hodnot. Použitím této metody lze získat přesný postup, jakým by požadovanou operaci realizoval sám Helios, a tedy i korektní metodu umožňující simulovat akci v externí proceduře tak, aby byla zachována konzistence a význam dat. 4.4.1

Struktura propojení

Od rozhodnutí na jaké úrovni bude stávající CRM propojeno se systémem Helios se odvíjí celý zbytek projektu. K dispozici jsou varianty od jednodušších, při kterých by se implementovaly pouze synchronizační můstky mezi oběma systémy, přes komplikovanější, kdy by byla správa financí zajištěna pouze v účetnictví, až po úplné zrušení CRM a převodu všech aktivit, včetně prodejních, do Heliosu. Při volbě režimu propojení hraje významnou roli jak případné ovlivnění prodejního procesu tak skutečnost, že systém pracuje v České republice i na Slovensku. Technicky jsou česká a slovenská verze Heliosu dvě samostatné aplikace, které pracují v oddělených databázích. Tuto odlišnost od CRM, které pracuje nad společnou databází pro oba státy, je tedy nutné zahrnout do rozhodování a přizpůsobit se jí v novém systému. 4.4.1.1

Zvolená varianta

Jako ideální výsledný stav se jeví varianta, která minimálně ovlivní vlastní aplikaci CRM, ale veškerou evidenci a správu financí přesune do Heliosu. Aktuální verze CRM obsahuje kromě evidence objednávek také mnoho funkcí podporujících vlastní prodej. A to od přizpůsobení akcí prodejnímu procesu, přes automatizovaný systém emailů až po propojení na telefonní ústřednu a automatické vytáčení. Rozsáhlost těchto funkcí a jejich vymezení na konkrétní případ cestovní agentury vylučuje přechod na jiný, obecný systém pro správu objednávek. Oproti tomu je správa financí zatížena historickým vývojem ve společnosti a obsahuje mnoho omezení a nedokonalostí. Proto je stanoveným cílem úplné vyřazení tabulky Platby a všech ostatních tabulek18 simulujících účetní systém. Finanční záznamy objednávek tak budou uloženy v té databázi Heliosu, která odpovídá státu cestovní kanceláře. Hlavní ukazatel zde není stát, ve kterém se objednávka vyřizuje, ale stát cestovní kanceláře, která zájezd pořádá. Například slovenská pobočka může prodat zájezd od české CK, ale cena zájezdu, všechny platby a fakturace probíhá v českých korunách. Proto musí být všude zajištěno, že se rozdělení bude řídit státem CK. 18

Platby, Platby_Davky, Objednavky_Faktury a tabulky pro evidenci vydaných faktur z CRM_Finance.mdb.

48


Prefixem "hsp_" jsou oznaþeny SQL stored procedury v databázi CRM související se systémem Helios

Aplikace CRM

hsp_NazevAkce_CZ hsp_NazevAkce

hsp_NazevAkce_SK

Obrázek 4.1: Struktura volání stored procedur z CRM Všechny operace, které nový systém zajišťuje, jsou realizovány stored procedurami umístěnými v databázi CRM. Výjimku tvoří pouze externí triggery (popsané v části 4.3.7) a definované přehledy (4.3.5.2), které musí být uloženy v SQL databázi konkrétního Heliosu. Aplikace CRM pro realizaci každé akce volá příslušnou stored proceduru, a to včetně operací pro čtení, a nikdy nezasahuje do dat účetního systému přímo. Pro zajištění této vlastnosti existuje pro každou akci vstupní procedura s názvem ve tvaru hsp_NazevAkce19 , jak znázorňuje obrázek 4.1. V každé takové SP se provedou společné operace pro oba státy a dále se zavolá jedna z návazných procedur na základě státu cestovní kanceláře. SQL server neumožňuje měnit databázi, nad kterou běží výpočet, za běhu uložené procedury. Proto se musí na objekty z databáze Heliosu vždy odkazovat úplným názvem obsahujícím i jméno DB20 . Kvůli tomuto omezení nemůže být zdrojový kód pro oba státy společný, ale musí být fyzicky rozdělen. Rozdělení lze realizovat buď podmínkou IF, při které by ve vstupní proceduře byly dva dlouhé bloky kódu lišící se v použité databázi, nebo oddělením do samostatných procedur, jak je to použito v tomto projektu. Zvolená struktura propojení má pro úspěšnou realizaci celého projektu několik výhod: • Z pohledu prodejců a prodejního procesu nedochází téměř k žádným změnám. • Veškerá evidence finančních záznamů je na jednom místě, oproti variantě synchronizačních můstků. • Je vytvořen prostor pro odstranění všech historických nedostatků. • Data jsou uložena přímo v systému Helios a všechny operace prováděné v účetnictví se tak přímo promítají do CRM. • Případné úpravy ve finančních procesech nevyžadují změny ve vlastní CRM aplikaci a redistribuci nové verze všem uživatelům. • Je přesně vymezená vrstva zajišťující pro CRM správu financí. • Oddělení českých a slovenských procedur zpřehledňuje kód a usnadňuje jeho údržbu. Z pohledu CRM je přístup k požadované funkci jednotný bez ohledu na stát. • Použité schéma procedur umožňuje rozšíření systému o další státy, jejichž správa financí nemusí být nutně prováděna v systému Helios. 19 20

Všechny procedury v databázi CRM související se systémem helios mají prefix „hsp_“. Např. Helios_cz_001.dbo.TabJmenoTabulky.


49

Nevýhody zvolené varianty jsou následující: • Každá vstupní procedura předává parametry do výsledné SP, čímž se ke každé akci přidá jedno volaní navíc. • Použití SP u akcí pro čtení není vhodné pro velké objemy dat, protože operace jako je řazení a filtrování21 záznamů musí být realizovány v CRM aplikaci. K dotazům z aplikace CRM nelze přidávat podmínky WHERE ani řazení ORDER BY. Dotazy jsou ale vždy omezeny na konkrétní objednávku, takže by tento problém neměl nastat. • V SQL databázi je uloženo třikrát více stored procedur, než je teoreticky nutné minimum. V rámci celého projektu se počítá jak s úplným odstraněním aplikace Platby.mdb, tak i CRM_Finance.mdb, jejichž úkoly plně převezme účetní systém. Přenos všech funkcí těchto aplikací je popsán v částech 4.4.6 a 4.4.7. 4.4.1.2

Diskuse ostatních možností

Zde jsou popsány další způsoby, jakými mohlo být provedeno propojení CRM a účetního systému. Liší se jak v náročnosti implementace, tak způsobu, jakým by pracovaly s evidencí financí. Při návrhu projektu se počítá se zrušením aplikace CRM_Finance.mdb a neuvažuje se o žádné jiné variantě. Všechny úkoly, které tato aplikace plnila, jsou převeditelné do účetnictví a není potřeba vytvářet duplicitní uživatelské rozhraní založené na technologii MS Access. Navíc všechny operace s fakturami poskytuje systém sám o sobě a proces vystavování faktur je realizovatelný bez zvláštního uživatelského rozhraní. Oproti tomu aplikace Platby.mdb obsahuje mnoho specifických funkcí, které nejsou v účetnictví zahrnuty. Z výkonnostních důvodů je nutné zrušit původní verzi aplikace v MS Access a převést ji na jinou technologii. I zde se počítá s rozšířením systému Helios tak, aby převzal všechny požadované funkce. Je tedy jisté, že datové úložiště bude umístěno v databázi Heliosu, narozdíl od aplikace CRM_Finance.mdb zde ale existují komplikované požadavky na ovládání a funkce samotného uživatelského rozhraní. V úvahu připadá varianta implementovat toto rozhraní přímo do aplikace CRM a zajistit komunikaci pomocí stored procedur. Tento návrh sice přináší široké možnosti pro tvorbu uživatelského rozhraní přesně podle požadavků, naráží však na nevýhodu zvoleného režimu propojení. Konkrétně na nutnost stahovat všechna data do klientské aplikace a filtrování i řazení provádět až v ní. Další nevýhodou je, že nelze provádět interakci s uživatelským prostředím Heliosu a využívat tak jeho zabudovaných funkcí. Nevýhody takového řešení by byly následující: • Nebylo by možné otevřít účetní deník konkrétní zakázky a využít všech zabudovaných funkcí pro editaci záznamů. • Nebylo by možné otevírat přehledy faktur a provádět s nimi všechny operace, které poskytuje systém Helios. • Export dávek platebních příkazů by musel být buď implementován znovu v prostředí CRM, nebo by uživatelé museli mít otevřený současně Helios a dávku vytvářet ve dvou aplikacích, což by z pohledu uživatele znamenalo značnou komplikaci. Z těchto důvodů jsou všechny funkce aplikace Platby.mdb, včetně uživatelského rozhraní, převedeny do uživatelského rozhraní Heliosu. Kombinace definovaného přehledu, externích 21 Filtrováním se myslí dodatečné filtry definované uživatelem nad vrácenou sadou dat, která je již omezena např. pro konkrétní objednávku podmínkou WHERE.

50


akcí a pluginů, popsaná v části 4.3, by měla poskytnout dostatečné množství prostředků pro plnohodnotný přenos všech funkcí původní aplikace. Struktura stávající aplikace CRM a účetního systému Helios nabízela několik dalších možností, jak propojení realizovat. Tyto možnosti zahrnují varianty od synchronizačních můstků až po úplný převod všech stávajících funkcí do modulu CRM v účetnictví. 1. Synchronizační můstky Nejjednodušší variantou je verze synchronizačních můstků. V tomto případě by se plně zachovala původní verze CRM a evidence plateb by nadále probíhala pomocí tabulky Platby. Aplikace Platby.mdb by byla implementována buď jako součást CRM, nebo do prostředí Heliosu. Pro splnění požadavků na propojení s účetním systémem by byla vytvořena sada synchronizačních můstků, které by všechny operace v CRM přenášely do účetnictví. Tento přenos by mohl být prováděn přímo při provedení příslušné akce, nebo hromadně v pravidelných intervalech. Musely by být implementovány jak operace samotné, tak možnost jejich případného zrušení. Současně by se musela vyřešit situace, kdy ke změně dat dojde v účetnictví a nikoli původním systému. Synchronizace by tak musela umět pracovat oběma směry a řešit případné kolizní situace. Při využití této varianty by data byla reprezentována dvojím, duplicitním způsobem, který kromě nejednoznačnosti připouští i nekonzistentní stav obou datových úložišť. Dvojí sada dat navíc přináší problém do rozhodnutí, nad kterými daty založit aplikaci pro správu odchozích plateb (náhradu za Platby.mdb) a fakturaci. Evidence plateb v tabulce Platby přináší několik problémů, které varianta popsaná části 4.4.1.1 umožňuje ošetřit. Hlavním problémem jsou omezené možnosti a složitá práce s různými druhy plateb (viz 3.1.1.5 a 3.1.1.6), kterou nový systém účtování umožňuje ošetřit. Ve zvolené variantě lze například jednoduše reprezentovat odchozí platbu do CK v hotovosti jako obyčejný výdajový pokladní doklad zaúčtovaný 325100 / 211xxx. 2. Aplikační logika v CRM bez využití stored procedur Tato varianta je podobná výsledné, popsané v předchozí části 4.4.1.1. Liší se pouze tím, že by neobsahovala vrstvu řešící finanční funkce ve formě stored procedur, ale veškeré operace, související s účetnictvím a evidencí financí by byly prováděny přímo z CRM. Aplikační logika financí by splynula s aplikační logikou CRM. Oproti výsledné struktuře se zde liší pouze umístění a způsob implementace. CRM by si z databáze Heliosu stahovalo potřebná data, provedlo výpočet a výsledky by byly zapsány opět přímo do příslušné databáze. Výhodou této varianty by byl jednodušší výběr příslušné databáze, než dvojí implementace všech prováděcích procedur naznačená na obrázku 4.1. Na druhou stranu by bylo komplikované načítání potřebných dat pro provedení výpočtu a tedy výrazně větší objem přenášených dat do klientské aplikace. S ohledem na vzdálené pobočky by to znamenalo zvýšení nároků na internetové připojení. Další zásadní nevýhodou by byla nutnost redistribuce nové verze v případě každé úpravy v části související s účetnictvím. Teoreticky by tak mohla vzniknout situace, kdy dva prodejci s různými verzemi aplikace provedli stejnou akci s odlišným výsledkem. 3. Přechod na jinou CRM aplikaci Nejradikálnější variantou je situace, kdy by se stávající CRM aplikace přestala používat a celý prodejní proces by přešel do modulu CRM systému Helios, případně CRM aplikace od třetí společnosti spolupracujícím s účetnictvím.


51

Tato varianta by znamenala úplnou změnu prodejního procesu a všech systémů, které se ve společnosti používají. Stávající verze CRM navíc obsahuje mnoho podpůrných funkcí, napojení na emailovou komunikaci, telefonní ústřednu a jednotné řešení pro Českou republiku i Slovensko. Tyto funkce by v nové verzi chyběly, nebo by jejich implementace byla finančně nákladná. Současně by nový systém vyžadoval náklady na licence a přinesl problémy s instalací aktuálních verzí na všechna prodejní PC. Hlavním důvodem vývoje vlastní CRM aplikace je odlišnost prodejního modelu cestovní agentury od jiných společností. V případě náhrady této klíčové aplikace by nebyla garantována životaschopnost celé společnosti a projekt by mohl způsobit velké finanční ztráty. 4.4.2

Rozšíření funkcí systému Helios

Kromě nových externích akcí a definovaných přehledů jsou v systému Helios provedena další rozšíření, která doplňují funkce uživatelského rozhraní. Mezi zabudovanými funkcemi chybí například možnost přesunu pokladního dokladu do jiné pokladny nebo přesun úhrady k jiné faktuře. 1. Párování bankovních výpisů Po importu nového bankovního výpisu zájezdového účtu22 vznikne v účetnictví mnoho nepřiřazených plateb, které je nutné spárovat s konkrétním číslem zakázky a vyplnit správný účetní účet (315400 při platbě od klienta nebo klientovi a 325100 při platbě mezi NetTravel a CK). Pro tento účel je v přehledu bankovních výpisů vytvořena externí akce Párování výpisů se zakázkami CRM, která spouští stored proceduru hsp_ParovaniUctu_CZ/SK. Ta se pokusí na základě známých informací doplnit číslo zakázky a účetní účet ke každému nespárovanému řádku bankovního výpisu. Celá procedura přiřazuje zakázky na základě různých informací v těchto krocích: (a) Odchozí platby podle platebních příkazů K odchozím platbám se pokusí najít platební příkaz, který tuto platbu realizoval. Dohledávají se příkazy se stejnou částkou, variabilním symbolem a řadou původní faktury 023 nebo 068. Jiné řady se ignorují, aby nedošlo ke spárování s provozním platebním příkazem. (b) Platby s VS odpovídajícím číslu zakázky Druhou skupinou jsou platby s variabilním symbolem stejným jako číslo zakázky. Pod tímto VS mají klienti hradit ceny svých zájezdů a jsou jim pod ním vraceny přeplatky. K vratkám by ale v době importu bankovního výpisu měl existovat platební příkaz a platba by se tedy měla spárovat v předchozím kroku. V některých nestandardních případech pod tímto VS vrací do NetTravel přeplatky i cestovní kanceláře. V takovém případě se vyplňuje příslušné číslo zakázky a účetní účet 325100. Platba od CK se rozlišuje na základě známého čísla účtu bankovního spojení u organizace, která má vyplněnou hodnotu TabCisOrg_EXT._id_CK a je tedy cestovní kanceláří. Mezi známými bankovními spojeními se mohou vyskytovat i bankovní účty samotných klientů, a to v případě, že jim byl v minulosti vrácen přeplatek. (c) Úhrady faktur 0*1 pro zaměstnavatele Poslední párovanou skupinou jsou příchozí platby k fakturám řady 0*1 pro zaměstnavatele. Na základě variabilního symbolu se dohledá konkrétní vydaná faktura, k řádku bankovního výpisu se doplní číslo zakázky podle této faktury a účet 315400. 22

Provozní účet není do párování zahrnut a je rozlišen příznakem TabBankSpojeni.Prednastaveno 6= 0.

52

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Helios by při párování úhrad takovýchto faktur mohl na základě párovacího znaku dohledat zakázku, problém je ale s párovacím znakem faktury, který obsahuje úvodní nulu ale VS ji často vynechává23 a platba se tak nepřiřadí. (d) Doplnění úhrad k zájezdovým fakturám řad 068, 0*1 a 023 Posledním krokem celého procesu je zápis úhrad do tabulky TabUhrady ke konkrétním fakturám. Ke každému nezaúčtovanému, ale spárovanému řádku bankovního výpisu se dohledá faktura řady 068, 0*1 nebo 023 a zapíše se k ní úhrada se správným znaménkem a vazbou na řádek BV. Do této operace se zahrnují pouze jednoznačně nalezené faktury, aby nedošlo k duplicitním nebo sporným zápisům úhrad. Během všech těchto párování se ignorují již zaúčtované řádky a také řádky bez variabilního symbolu24 . Současně je také všude ošetřeno odstranění počátečních nul, protože některé banky předávají VS i s těmito nulami. 2. Rozdělení platby bankovního výpisu V seznamu položek bankovního výpisu je dostupná akce pro rozdělení řádku, která uživatele vyzve k zadání dvou vstupních parametrů: částky a čísla cílové zakázky. Spuštěná procedura hsp_RozdelitBankVypis_CZ/SK vytvoří kopii aktuálního řádku a u této kopie nastaví zadanou částku a číslo zakázky. Následně od původního řádku odečte částku a do poznámky k původní platbě zapíše informaci o rozdělení. Zápis nového řádku a úprava původního záznamu je prováděna v transakci, aby nedošlo k vytvoření nekonzistentních dat. Konkrétně, aby nevzniknul záznam o platbě, která neproběhla a nenavýšila se tak celková částka přijatých plateb. Před provedením změn v databázi musí řádek a vstupní parametry splnit tyto podmínky: • ID vstupního řádku platby musí existovat. • Nelze oddělit vyšší částku, než je původní výše platby. • Nelze rozdělit zaúčtovaný řádek, protože změna pracuje pouze se zdrojovým dokladem a nijak neupravuje údaje zapsané v účetním deníku. • Zadané číslo nové zakázky musí existovat v tabulce TabZakazka, nelze tedy přesunout platbu k objednávce, která zatím nebyla do systému Helios přenesena. Akce rozdělení bankovního výpisu je vytvořena, aby bylo možné společnou platbu více objednávek zaúčtovat ke každé zvlášť. Systém sice umožňuje během účtování každého výpisu upravit způsob, jakým bude zaúčtován. V přípravné fázi účtování lze upravit částku jednoho řádku v deníku a vytvořit nový řádek tak, aby celkový součet dokladu zůstal zachován, a k těmto řádkům lze správně zadat příslušná čísla zakázek. Systém na základě takto rozdělené platby může fungovat a výpočty hodnot ZaplatitCK i ZaplatitKlientovi budou v pořádku. Problém je, že rozúčtování není nijak uloženo u původního dokladu. Pokud by někdo odúčtoval bankovní výpis, bude ručně provedená úprava účtování ztracena. Nové zaúčtování by pak celou částku zaúčtovalo pouze k jedné zakázce. Přeplatek by obsluha aplikace Platby pravděpodobně vrátila objednavateli jedné objednávky, zatímco by u druhé vzniknul nedoplatek. Ke společným úhradám dochází většinou v případě, kdy jeden klient organizuje zájezd pro početnější skupinu cestujících, kteří mají rozdělené objednávky a cestovní smlouvy. Jedna cestovní smlouva odpovídá zpravidla jednomu pokoji a zájezd obsahující více pokojů je tak

23 24

Např. párovací znak 08100001 a VS 8100001. Nevyplněný nebo nulový VS.


53

rozdělen mezi více objednávek. Ty klient může uhradit společnou platbou. Další možností, kdy tato situace může nastat, je úhrada zájezdů více klientů od úvěrové společnosti. V takovém případě může být jednou platbou hrazeno více zájezdů pro klienty, kteří mezi sebou nemají žádné vazby a pozdější dohledávání původu platby by bylo komplikované. 3. Přesun pokladního dokladu mezi pokladnami Helios nemá zabudovanou funkci pro přesun pokladního dokladu mezi pokladnami. Z tohoto důvodu je v přehledu pokladních dokladů přidána akce Přesun pokladního dokladu, která spouští proceduru hsp_PresunPokladny_CZ/SK. Číslo pokladny, do které je platba z CRM zapsána, je určeno konfigurací aplikace CRM na každé pobočce a uživatelé nemají možnost zapisovat platby do cizích pokladen. V některých případech ale může dojít k situaci, kdy platbu pro klienta na jedné pobočce zapisuje prodejce z jiné pobočky, nebo call-centra. Zápis platby v hotovosti může provést i finanční oddělení a platbu je po takové operaci nutno přesunout do správné pokladny. Při spuštění akce je uživatel dotázán na výběr cílové pokladny, do které je vybraná platba přesunuta. Při přesunu musí být splněno několik podmínek, aby nedošlo k vytvoření nekonzistentních dat: • Nelze přesouvat doklady z uzavřeného období. • Nelze přesouvat zaúčtované doklady, protože změnou pokladny by muselo dojít ke změně sborníku, do kterého je doklad zaúčtován. • Cílová pokladna musí existovat a musí mít explicitně nastavenou měnu25 . • Zdrojová měna dokladu a měna cílové pokladny musí být stejné. Samotný přesun dokladu pouze vypočte nové pořadové číslo a k přesouvanému dokladu toto číslo uloží spolu s novou předkontací26 a číslem nové pokladny. Na závěr se musí přepočítat stavy obou zúčastněných pokladen procedurou hp_AktualizacePokladna. 4. Přesun úhrady Další funkcí, o kterou jsou rozšířeny běžné přehledy Heliosu, je akce Přesun úhrady v přehledu úhrad faktury, která spouští stored proceduru hsp_PresunUhrady_CZ/SK. Tato akce se pro označenou úhradu dotáže na číslo cílové faktury a úhradu k ní přesune. Cílová faktura musí být stejného typu (přijatá/vydaná) jako faktura zdrojová kvůli zachování významu znaménka samotné úhrady. Tato akce slouží jako opravný prostředek pro případy, kdy je úhrada z bankovního výpisu (zapsaná ručně i automaticky) přiřazena k nesprávné faktuře. Samotný přesun úhrady musí nejdříve najít závislost, ze které úhrada vznikla. Úhrada může být obecně zapsána: • z pokladního dokladu (tabulkou TabVDokPoklUhr), • z bankovního výpisu (tabulkou TabBankVypisRUhrady), • z platebního příkazu (tabulkou TabPlatTuzRDetail), • ručně bez zdrojového dokladu. 25

Lze vytvořit pokladnu, která nemá explicitně nastavenou měnu. Měna dokladu se pak řídí informací uvedenou přímo u konkrétního dokladu. 26 Se změnou pokladny se mění i číslo předkontace, protože doklad bude zaúčtován do jiného sborníku.

54

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Existuje-li taková závislost, je nejdříve odstraněn příslušný řádek nebo vynulována vazba na úhradu, a až následně je odstraněna samotná úhrada. Pro zápis nové úhrady je použita zabudovaná procedura Heliosu hp_OZGenPlat_Uhrada_Nova_Nebo_Oprava, která na základě vstupních parametrů zapíše jak úhradu, tak její závislosti. Všechny kroky tohoto přesunu jsou obaleny do společné transakce vzhledem k tomu, že ukončením procesu v polovině může dojít ke ztrátě dat nebo vytvoření nekonzistence. 5. Externí sloupce Posledním rozšířením samotných funkcí účetního systému je přidání externích sloupců do tabulek, ve kterých se nevyskytuje vhodná reprezentace potřebných hodnot. Do tabulek jsou přidány tyto externí sloupce: TabBankSpojeni_EXT._CRM je příznak, zda se jedná o aktivní zájezdový účet, který má být zobrazen v CRM. Na základě tohoto příznaku jsou zobrazovány bankovní spojení vlastní organizace27 v číselníku hsp_BankovniSpojeni. TabBankVypisH_EXT._Fiktivni je příznak označující bankovní výpisy založené fiktivně pro účely předběžného potvrzení plateb. Nové řádky jsou přidávány přednostně na již existující výpis. Předběžné potvrzování je popsáno v části 8. TabBankVypisH_EXT._HeIQ_Barva je speciální počítaný sloupec, který na základě vrácené hodnoty umožňuje změnit barvu písma každého řádku. Sloupec je využíván k označení fiktivních bankovních výpisů modrou barvou, aby byly tyto řádky odlišeny od běžných bankovních výpisů. V přehledu Platby jsou modře označeny objednávky obsahující nepotvrzenou platbu, proto je i zde zvolena modrá. TabCisOrg_EXT._id_CK ukládá ID z tabulky Cestovky a vytváří tak vazbu mezi organizací v Heliosu a cestovní kanceláří v CRM. Mezi organizacemi jsou zapsány všechny společnosti i klienti, se kterými má NetTravel účetní vztahy. Proto je potřeba nejen označit cestovní kanceláře jako takové, ale například ve fakturaci spárovat fakturovanou CK s organizací, pro kterou je faktura vystavována. TabPohybyZbozi_EXT._id_Poukaz představuje vazbu na ID poukazu z tabulky Poukazy v databázi CRM. Pro úhradu každého poukazu je v novém systému vystavena faktura řady 0*6, jak je popsáno v 4.2.2, a tento sloupec ke každé položce takové faktury udává vazbu na konkrétní poukaz. Vazba slouží jak pro kontrolu, zda není poukaz fakturován duplicitně, tak pro správné určení poukazů k aktivaci při úhradě faktury. TabPohybyZbozi_EXT._Placeno je sloupec, který u vydaných faktur na provizi řady 0*2, ukládá částku s DPH v případě fakturace s provizí hned. Tato částka, je-li vyplněna, je zobrazena v tiskovém formuláři vydané faktury u každé položky. TabPokladna_EXT._id_DokladyZbozi udržuje u každého pokladního dokladu ID vydané faktury klientovi řady 068. Hodnota se vyplňuje při vytvoření dokladu a používá se při jeho zaúčtování, během kterého se k uvedené faktuře zapisuje úhrada.

4.4.3

Obecné procedury

Vzhledem k rozsáhlosti účetního systému Helios existuje několik postupů, které se opakují u více akcí. Aby si každá akce tyto společné rysy nemusela realizovat sama, jsou pro ně vytvořeny obecné procedury. Ve většině případů se jedná o jednotnou formu vytváření záznamů, případně zjištění parametrů pro výpočet. 27

Za vlastní organizaci se považuje NetTravel.cz s.r.o., nebo Lastminute.sk s.r.o.


55

1. hsp_FVPCastka_CZ/SK Při vystavování faktur 0*2 na provizi z prodeje zájezdů a faktur 0*6 na poukazy se před přidáním položky na fakturu kontroluje, zda není objednávka nebo poukaz již vyfakturován na jiné faktuře. Tuto kontrolu zajišťuje právě tato stored procedura. Podle řady faktury dohledá všechny odpovídající položky ostatních faktur a částku k fakturaci sníží o již vyfakturovanou sumu. Dojde-li ke snížení částky, je o této skutečnosti přidána zpráva pro uživatele do dočasné tabulky #TabExtKom. 2. hsp_FVPIns_CZ/SK Přidání řádku na vydanou fakturu, a tedy vložení řádku do tabulky TabPohybyZbozi, je opět jednotné pro faktury 0*2 i 0*6. Při vkládání se vyplňuje přes 40 sloupců a proto je pro samotnou operaci INSERT vytvořena samostatná procedura. Po vložení záznamu se současně kontroluje hodnota _Placeno a _id_Poukaz a tyto hodnoty se rovnou uloží do tabulky TabPohybyZbozi_EXT. 3. hsp_GetCastka_CZ/SK Tato procedura je jednou z částí systému, která ošetřuje přechod na jednotnou evropskou měnu – Euro. Stored procedura zkontroluje měnu vstupní částky a pokud se liší od hlavní měny, vrátí částku přepočtenou konverzním kurzem, který je uveden v globální konfiguraci účetního systému. 4. hsp_GetCisloOrg_CZ/SK Procedura pro vstupní parametr ID objednávky vrátí číslo organizace, které odpovídá cestovní kanceláři pořádající zájezd. 5. hsp_GetMena_CZ/SK Tato procedura je hlavním zdrojem informací o aktuální fázi přechodu na jednotnou evropskou měnu – Euro. Procedura vrací aktuální hlavní měnu, konverzní kurz Eura a datum přechodu na Euro v závislosti na globální konfiguraci Heliosu uložené v tabulce TabHGlob. 6. hsp_GetMenaObj Pro vstupní parametr ID objednávky vrátí měnu, ve které jsou uvedeny informace na objednávce. Údaje v tabulce Objednavky udržující částku (CenaCelkem, StornoPoplatek, ProvizeSDPH a ProvizeBezDPH) jsou vždy uváděny v hlavní měně, která byla platná v době vytvoření objednávky28 . 7. hsp_GetObdobi_CZ/SK Procedura pro nepovinný vstupní parametr @Datum vrátí ID odpovídajícího období z tabulky TabObdobi. Není-li datum uvedeno, je vráceno ID aktuálního období. V případě, že je výsledné období již uzavřeno, je vrácena chyba, protože není možné zapisovat do uzavřeného období. 8. hsp_GetObdobiStavu_CZ/SK Podobně jako hsp_GetObdobi_CZ/SK pro nepovinný vstupní parametr @Datum vrátí ID odpovídajícího období stavu z tabulky TabObdobiStavu. Není-li datum uvedeno, je vráceno ID aktuálního období stavu. 28

Např. CenaCelkem objednávky objednané 31.12.2008 na Slovensku je uvedena v měně Sk, a to i v případě, že je objednávka prodána v roce 2009, faktury od CK řady 023 jsou zapsány v měně Euro a objednávka je uhrazena také v Eurech, viz 4.4.4.

56

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ V případě, že výsledná hodnota spadá do již uzavřeno období, je vrácena chyba, protože není možné zapisovat do uzavřeného období. 9. hsp_OpravitFa_CZ/SK Procedura umožňuje upravit fakturu v Heliosu a změnit její splatnost, text, částku a číslo dodavatelské faktury. Pokud je faktura již zaúčtovaná, je upraveno také vlastní zaúčtování. Během provádění této operace může nastat situace, při které je doklad zaúčtován v již uzavřeném období. V takovém případě nesmí dojít k úpravě tohoto dokladu, aby nebyly porušeny principy účetnictví. Pokud u faktury existují řádky v účetním deníku spadající do uzavřeného období, je zapisovaná částka snížena o jejich součet a v účetním deníku je vytvořen nový doklad k původní faktuře. Při další úpravě takové faktury existují v deníku již doklady dva, z čehož jeden v uzavřeném období. I zde se jeho hodnota odečte od zapisované částky a dojde k úpravě druhého dokladu tak, aby součet všech dokladů faktury vyšel stejně jako celková částka faktury. Pokud vlivem chyby (nebo ručního zásahu) vznikne u jedné faktury více dokladů, je odeslán email upozorňující na nedokončenou operaci a vrácena chyba.

10. hsp_PridatDoDenikUcto Během procesu účtování je nový doklad připravován v dočasné tabulce #TabDenikUcto. Tato procedura umožňuje přidat během účtování k dokladu nové řádky na základě vstupních parametrů @Castka, @MD a @Dal. Ostatní návazné údaje jako je číslo organizace nebo reference na zdrojový doklad jsou opsány ze stávajících řádků rozpracovaného dokladu. 11. hsp_PrilozitDokument_CZ/SK Přiložení dokumentu vloží cestu k souboru do tabulky TabTabDokumenty a vytvoří vazbu mezi původním dokladem a dokumentem v tabulce TabTabDokumVazba. Tato procedura se používá k přikládání naskenovaných dokumentů k přijatým fakturám. 12. hsp_RenewIdentity Nastaví SQL proměnnou @@IDENTITY na hodnotu danou vstupním parametrem @ID. Toto přiřazení lze realizovat pouze vložením nového řádku do tabulky obsahující sloupec s vlastností IDENTITY. Stored procedura si pro tento účel vytvoří dočasnou tabulku, do které vloží záznam s požadovanou hodnotou @ID a tabulku na konci běhu odstraní. Pokud se v externím triggeru po vložení nového záznamu do některé z tabulek Heliosu přidává záznam do ostatních tabulek, dojde ke změně hodnoty @@IDENTITY. Aplikace Helios pro provedení svých operací tuto hodnotu využívá a může tak dojít k situaci, kdy dostane ID neexistujícího nebo nesprávného záznamu. 13. hsp_SendMail_CZ/SK Procedura přijme jako vstupní parametry předmět a text emailu, který je odeslán na adresu určenou pro rozesílání upozornění a zpráv ze systému. Pro vlastní odeslání se využívá procedura psp_SendMail, která není součástí tohoto projektu, a která pouze vkládá hodnoty do fronty systémových emailů k odeslání. Aplikace CRMSync tuto frontu v pravidelných intervalech kontroluje a zprávy odesílá. 14. hsp_StavDeniku_CZ/SK Vrací stav deníku pro danou objednávku, číslo účetního účtu a stranu ( „má dáti“/„dal“). Součet zohledňuje možný přechod na měnu Euro a vždy vrací hodnotu v aktuální hlavní měně.


57

15. hsp_SyncObj_CZ/SK Stored procedura na základě hodnoty @id_Stav přidá záznam do tabulky TabZakazka, nebo se ho pro stornované objednávky pokusí odstranit. V prvním případě se do tabulky TabZakazka přidává záznam obsahující správné číslo zakázky, jméno klienta a datum objednání u objednávek, které v tabulce zatím nejsou. U stornovaných objednávek se procedura pokusí záznam odstranit. Během transakce odstraňování může dojít k chybě způsobené tím, že je v jiné části systému vyžadována referenční integrita na odstraňovaný záznam. V takovém případě odstranění neproběhne a objednávka nadále zůstává v systému. Pokus o odstranění probíhá pouze z důvodu minimalizace počtu záznamů v tabulce TabZakazka. U mnoha objednávek může dojít k jejich přidání do účetnictví a následnému zrušení bez nutnosti evidovat u takové objednávky stav financí. Záznam je v takovém případě zbytečný a jeho odstraněním se urychluje provádění dotazů nad tabulkou. 16. hsp_ZapisFa_CZ/SK Zápis nové faktury (vydané i přijaté) je poměrně komplikovaný proces. Aby bylo přidávání zajištěno jedinou procedurou, je v jeho průběhu prováděno několik kontrol nebo případných doplnění údajů. Celý proces přidání nové faktury popisuje diagram 4.2. Při nastaveném vstupním parametru @Zauctovat může být zapsaná faktura ihned zaúčtována procedurou hsp_ZauctovatFa_CZ/SK. 17. hsp_ZapisOrg_CZ/SK Zápis organizace nepřidává řádky do tabulky TabCisOrg ihned po volání procedury, ale nejdříve se pokusí dohledat případnou stávající organizaci se stejným názvem, IČ, DIČ a adresou. Není-li stávající organizace nalezena, je přidán nový záznam. V případě, že je při volání nastaven parametr @CisloOrg, není vložena nová organizace ale jsou upraveny informace u stávající, určené vstupním číslem organizace. Po provedení úprav v tabulce TabCisOrg je v případě vyplnění hodnoty DIČ ještě vložen záznam do tabulky TabTabDICOrg, aby bylo možné DIČ vyplňovat na faktury. 18. hsp_ZauctovatDenik_CZ/SK Tato procedura vytváří na základě vstupních parametrů interní doklad v účetním deníku. Vytvoření neprobíhá, narozdíl od účtování faktur a pokladních dokladů, přes tabulku #TabDenikUcto, ale záznamy jsou vkládány přímo do tabulky TabDenik. Vstupní parametry umožňují zaúčtovat na jeden doklad až tři dvojice účtů „má dáti“, „dal“ se stejnou částkou, což je využito při uplatňování poukazů. Po vytvoření záznamů v deníku je rovnou provedena změna fáze dokladu z „Pořízeno“ do stavu „Účtováno“. Tuto změna fáze je možné zakázat nastavením vstupního parametru @JenPorizeno. Vložení všech tří dvojic účtů „má dáti“/„dal“ je obaleno do společné transakce, aby při vkládání nedošlo k vytvoření nevyrovnaného dokladu. 19. hsp_ZauctovatFa_CZ/SK Zaúčtování faktury, podobně jako její vytvoření, obsahuje více kroků. Celý postup je rozkreslen na diagramu 4.3. Po načtení a ověření počátečních informací je vytvořena tabulka #TabDenikUcto, která již může existovat před voláním stored procedury. Pokud tabulka již existuje, je pouze vymazána. Konkrétní podoba tabulky a seznam příslušných sloupců je vytvořen na základě pozorování účtování systému Helios. Dalším krokem je nastavení příznaku realizace procedurou hp_Realizuj_Fak a vlastní příprava dokladu do připravené dočasné tabulky další zabudovanou procedurou Heliosu

58


hsp_ZapisFa_CZ/SK

[Je uvedena zakázka]

Zajistit zakázku hsp_SyncObj_CZ/SK

[Není uvedeno datum poĜízení]

Nastavit aktuální

Naþíst období, období stavu, úþetní kód a mxnu [Úþetní kód neexistuje] [Je uvedena zakázka]

[Je uvedeno þíslo org.] [Jinak]

Naþíst þíslo org. hsp_GetCisloOrg_CZ/SK

Naþíst DIý a ovČĜit þíslo org. [ýíslo org. neexistuje]

Vrátit chybu

Urþit poĜadové þíslo [Akce je spuštČna z aplikace Helios] Uložit Ĝadu a þíslo faktury do #TabExtKom

Uložit fakturu [Faktura má být zaúþtována] Zaúþtovat hsp_ZauctovatFa_CZ/SK

Obrázek 4.2: Zápis nové faktury hsp_ZapisFa_CZ/SK


59

hsp_ZauctovatFa_CZ/SK

[Úþtování faktury na provizi z prodeje zájezdĤ]

Naþíst informace o faktuĜe a ovČĜit pĜedkontaci [Neexistuje Ĝada, pĜedkontace, faktura je na nulovou þástku nebo je období již uzavĜeno]

Vrátit chybu VytvoĜit #TabDenikUcto

Nastavit pĜíznak realizace hp_Realizuj_Fak

PĜíprava dokladu do #TabDenikUcto hp_Uctuj_Kontace_VydaneFaktury

Souþet _Placeno pĜidat do #TabDenikUcto 325001/311100

PĜenést doklad do deníku hp_PrenesDenikUctoDoDeniku [Doklad je ve fázi poĜízeno]

Zmxnit fázi na úþtováno hp_ZmenaRozpracovanostiDeniku

Odstranxní tabulky #TabDenikUcto

Odstranit úvodní nuly párovacího znaku

Obrázek 4.3: Zaúčtování faktury hsp_ZauctovatFa_CZ/SK

60

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ hp_Uctuj_Kontace_VydaneFaktury. Nyní je doklad připraven v #TabDenikUcto a procedura hsp_PridatDoDenikUcto umožňuje přidávat další řádky k dokladu. U faktur na provizi se zde přidává zaúčtování 325001/311100 součtu sloupce _Placeno z položek faktury. Před přenesením dokladu do účetního deníku procedurou hp_PrenesDenikUctoDoDeniku jsou u řádků odstraněny úvodní nuly párovacího znaku. Tato úprava usnadňuje párování dokladů. Po přenosu do deníku je ověřena fáze dokladu29 a případně proveden převod do stavu „Účtováno“ procedurou hp_ZmenaRozpracovanostiDeniku. Posledním krokem je odstranění tabulky #TabDenikUcto, které se provádí pouze pokud byla tabulka procedurou vytvořena. Jinak je obsah, podobně jako na začátku, pouze odstraněn a tabulka zachována.

20. hsp_ZrusOzn_CZ/SK Procedura zruší uživatelské označení záznamů tabulky určené vstupním parametrem @TabName. Toto zrušení se provádí jako odstranění řádků z tabulky TabUzivOzn pro aktuálního uživatele. 21. hsp_ThrowEx Procedura umožňuje společné ošetření sekce CATCH používané pro zjednodušení implementace transakcí. MS SQL Server 2005, narozdíl od předchozích verzí, umožňuje využití TRY/CATCH pro ošetření delšího bloku kódu zpracovávaného uvnitř transakce. Kód uvnitř sekce TRY otevře novou transakci, provede potřebné operace a v případě bezchybného běhu transakci ukončí příkazem COMMIT. Pokud nastane chyba, je řízení předáno sekci CATCH a příkaz COMMIT bude vynechán. V této sekci se pak pomocí ROLLBACK transakce zruší. Ošetření chyby v sekci TRY/CATCH ale způsobí, že chyba není hlášena dále, tedy mimo proceduru a uživateli. V použité verzi jazyka SQL neexistuje objekt reprezentující výjimku a chybu tedy nelze jednoduše propagovat do vyšší úrovně. Tento problém řeší procedura hsp_ThrowEx, která přijme parametr @@PROCID, udávající identifikaci aktuální stored procedury nebo triggeru, načte všechny informace o vyvolané chybě, upraví text chyby a chybu znovu vyvolá s původními hodnotami. Úprava textu kromě chybové hlášky přidá ještě informaci o čísle chyby, řádku a názvu procedury nebo triggeru, ve které chyba nastala. Tu získá na základě vstupního parametru s původní hodnotou systémové proměnné @@PROCID a funkce OBJECT_NAME() vracející název. Pro ošetření transakce a předání chyby dále se tak používá tento kód: BEGIN TRY BEGIN TRANSACTION ... příkazy ... COMMIT END TRY BEGIN CATCH IF @@TRANCOUNT>0 ROLLBACK EXEC hsp_ThrowEx @@PROCID END CATCH 29 Výchozí fáze po zaúčtování dokladu může být jak „Účtováno“, tak „Pořízeno“ v závislosti na nastavení předkontace a řady dokladu zboží.

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ FazeEuro 0 1 2 3

61

Popis Bez konverze hlavní měny, neaplikuje se přechod na Euro. Fáze duálního zobrazování, hlavní měna je zatím nezměněna. Fáze po přechodu na měnu Euro. Databáze byla vygenerována po přechodu na měnu Euro a nelze vytvářet doklady do období před přechodem.

Tabulka 4.6: Význam hodnot ve sloupci TabHGlob.FazeEuro 4.4.4

Přechod na měnu Euro

Hlavní měna Slovenské republiky se ke dni 1.1.2009 mění na jednotnou evropskou měnu Euro. Z tohoto důvodu musí být v systému přechod ošetřen a výpočty musí zohlednit možnost existence jiné měny. Změna se dotýká celého účetnictví a systém Helios s ní počítá ve své datové struktuře. Současně je propojení a práce s finančními údaji navržena tak, aby byl ošetřen i případný přechod České republiky na měnu Euro. Účetnictví a všechny jeho procesy jsou založeny na období, které odpovídá kalendářnímu roku. S přechodem na měnu Euro je původní období uzavřeno, provedeny nevratné změny a přepočty uvnitř databáze a od dne přechodu na novou měnu funguje systém na nové měně. Tento model je poměrně jednoduchý, ale není aplikovatelný na prodej zájezdů, protože všechny objednávky nelze uzavřít ke konkrétnímu dni a od tohoto dne počítat vše v nové měně. Můžou existovat objednávky prodané v roce 2008 s termínem v roce 2009 a platbami v obou obdobích. Současně s tím je kalkulace vypočtena ve slovenských korunách, ale provize je fakturována v Eurech. Podobně jako v Heliosu, kde je implicitní měna30 dána hlavní měnou v době zápisu dokladu, zavádí tento projekt stejné pravidlo i pro tabulku Objednavky v CRM. Všechny objednávky objednané před datem přechodu na Euro jsou evidovány v původní měně a objednávky vytvořené po tomto dni jsou evidovány v Eurech. Měna tedy v tabulce není uvedena explicitně a tímto pravidlem se musí řídit všechny výpočty, včetně reportů mimo tento projekt. Zavedené pravidlo se týká všech sloupců nesoucích finanční údaje, což jsou v případě tabulky Objednavky sloupce CenaCelkem, StornoPoplatek, ProvizeBezDPH a ProvizeSDPH. Platby evidované v účetnictví se řídí pravidly Heliosu, stejně tak všechny vystavené faktury a pokladní doklady. U objednávky tedy mohou existovat dvě faktury stejné řady v různé měně a výpočty musí tuto skutečnost zohlednit. Základním místem, podle kterého se řídí aktuální fáze přechodu na měnu Euro je tabulka TabHGlob a její sloupce DatumPrechoduNaEuro, FazeEuro a DUOkurz. Význam hodnot ve sloupci FazeEuro je uveden v tabulce 4.6. Sloupec DUOkurz uvádí pevně stanovený kurz pro duální zobrazování a kurz, kterým bude původní měna po přechodu přepočítávána na Euro. Pro Slovenskou republiku je kurz stanoven nařízením Rady (ES) č. 694/2008 na hodnotu 30,126031 a je neměnný. Centrální procedurou pro zjištění hlavní měny, konverzního kurzu a data přechodu na měnu Euro je stored procedura hsp_GetMena_CZ/SK, popsaná v části 4.4.5.2. Ta vrací všechny tyto informace pro vybranou databázi. Pokud přechod na měnu Euro neproběhl, je vrácena hlavní měna, konverzní kurz = 1 a datum Eura = NULL. S ohledem na tyto vlastnosti je syntaxe pro přepočet částky do hlavní měny následující: CAST(ROUND(Castka/CASE WHEN Mena<>@Mena THEN @Kurz ELSE 1 END, 2) AS MONEY) Sloupec Castka představuje částku v měně dokladu, která je určena sloupcem Mena. Zao30

Doklady v deníku nemají uvedenou měnu explicitně a platí pro ně hlavní měna podle data pořízení. Konverzní kurz se podle nařízení Rady (ES) č. 1103/97 musí uvádět vždy na šest platných míst, tedy včetně poslední nuly. 31

62


krouhlení je vždy provedeno na dvě desetinná místa. V případě součtu více hodnot se vždy zaokrouhlují jednotlivé položky před vlastním součtem. V definovaných přehledech se namísto datového typu MONEY používá DECIMAL(19, 6), aby byly hodnoty správně zobrazeny32 . 4.4.5

Funkce CRM

Základním stavebním kamenem pro evidenci financí v novém systému z pohledu CRM je sada procedur, které poskytují všechny potřebné funkce pro správné fungování CRM. Struktura propojení, a tedy schéma vrstvy zpracovávající evidenci financí, je popsána v části 4.4.1.1. Zde jsou rozebrány konkrétní procedury a jejich funkce. Samostatnou skupinu tvoří stored procedury určené pro čtení záznamů. Kromě operací pro zápis jsou také operace pro čtení realizovány stored procedurami. A až uvnitř těchto procedur je vybrána správná databáze pro provedení dotazu, jak naznačuje obrázek 4.1. Tento způsob provedení přesněji vymezuje hranice vrstvy, neumožňuje ale řazení a filtrování záznamů na serveru. Zásadní úprava, v porovnání s původním systémem, nastala v evidenci faktur pro zaměstnavatele řady 0*1 a fakturace poukazů. Obě tyto součásti systému jsou nově integrovány přímo v CRM, jak je popsáno v sekcích 4.4.5.4 a 4.4.5.9. Evidence faktur od CK neprošla z pohledu CRM výraznějšími změnami, pouze se nahrazuje tabulka Objednavky_Faktury, jakožto stávající úložiště dat, datovými strukturami přímo v Heliosu. 4.4.5.1

Transakční zpracování

Většina procedur pro splnění svého úkolu neotevírá transakci. V systému se tak mohou vyskytnout rozpracované doklady, jejichž zpracování nedoběhlo do konce. První důvod pro tento postup je výkonnostní. V účetnictví probíhá velké množství operací, z čehož akce související s CRM jsou zpravidla komplexnější, a velké množství transakcí by mohlo způsobit zablokování systému. Dalším důvodem je šance, že v účetnictví zůstane alespoň zdrojový, nezaúčtovaný doklad. V takovém případě lze jednoduše sporné doklady vyhledat, odstranit příčinu problému a zaúčtovat je ručně. V takovém případě se nemusí provádět kontrola všech objednávek, ale stačí cíleně zkontrolovat ty, jejichž zaúčtování se nezdařilo. Transakčnímu zpracování podléhají všechny operace, které mohou způsobit ztrátu nebo nekonzistentní stav dat. Zpravidla se jedná o vícekrokové úpravy dokladů v účetním deníku, které by po sobě mohly zanechat nevyrovnané doklady. 4.4.5.2

Čtení informací

Jak již bylo popsáno výše, všechny operace čtou data pomocí stored procedur, ve kterých se vybírá správná zdrojová databáze na základě ID objednávky. Výběr databáze tak nezávisí na aplikaci CRM, ale na objednávce samotné. Ke každé proceduře v následujícím seznamu existuje vstupní rozcestník bez sufixu _CZ/SK, kromě procedur hsp_HledaniFa a hsp_HledaniZKli, které provádí výpočet přímo. 1. hsp_BankovniUcty_CZ/SK Číselník bankovních účtů obsahující ID, název a číslo účtu. Jsou zobrazeny pouze bankovní spojení vlastní organizace, které mají nastaven příznak TabBankSpojeni_EXT._CRM 6= 0. 2. hsp_Denik_CZ/SK 32 Při použití typu MONEY by se v přehledech za číslem zobrazila měna přednastavená v operačním systému. Typ DECIMAL(19, 6) je používán systémovými přehledy Heliosu.


63

Vrací všechny řádky z účetního deníku obsahující příslušné číslo zakázky, účetního účtu a strany „má dáti“/ „dal“. Kromě ID a čísla dokladu je zobrazena částka, datum, číslo pokladny, bankovního účtu, VS, hlavní měna a vazba na pokladní doklad, aby bylo umožněno jeho případné otevření. Číslo účetního účtu je mezi vstupními parametry, aby měla aplikace CRM možnost rozlišit platby od klienta 315400 a platby mezi NetTravel a CK na účtu 325100. Částka se v případě zaúčtování na opačnou stranu, než určuje vstupní parametr @Strana, vrací se zápornou hodnotou. Částka je vždy zobrazena v hlavní měně, která je do výpisu také zahrnuta. 3. hsp_DenikSumy_CZ/SK Zobrazuje pro konkrétní objednávku hodnoty ZaplatitKlientovi, NaCesteKlientovi a NaCesteCK z definovaného přehledu hvw_PlatbyMain, které jsou vždy vráceny v hlavní měně. 4. hsp_FaCK_CZ/SK Pro ID objednávky vrací seznam všech faktur řady 023. Výpis obsahuje všechny informace potřebné pro správu přijatých faktur a jejich případné úpravy. Kromě sloupce ID a čísla zakázky je to číslo dodavatelské faktury, datum pořízení, splatnosti, částka a měna faktury, poznámka, autor, autor poslední změny a příznak, zda je faktura zaúčtovaná. Částka je vždy uvedena v měně faktury a u jedné objednávky může existovat více různých měn. 5. hsp_FaPoukazu_CZ/SK Tato procedura vrací podobné údaje jako předchozí, navíc ale obsahuje informaci o úhradě a název i číslo organizace, které je faktura vystavena. Hlavním rozdílem je skutečnost, že jsou vráceny konkrétní položky faktury (nikoli faktury samotné), a to pro všechny faktury, na kterých se poukaz vyskytuje. 6. hsp_FaZam_CZ/SK Procedura vrací všechny faktury pro zaměstnavatele řady 0*1 na základě vstupního parametru @id_Objednavka. Seznam sloupců obsahuje všechny informace potřebné k vytištění faktury přímo z aplikace CRM. Proto jsou zde, oproti předchozím výpisům faktur, uvedeny i informace jako je konstantní symbol, bankovní spojení, adresa organizace a další. Speciální význam zde má pořadí sloupců, které je ve stejném pořadí jako parametry procedury hsp_ZapisFaZam. S touto vlastností aplikace CRM počítá a zjednodušuje si tak generování SQL dotazu pro uložení změn na faktuře. 7. hsp_FormaUhrady_CZ/SK Číselník možných forem úhrady faktur vycházející z tabulky TabFormaUhrady. 8. hsp_HledaniFa Toto je první ze dvou procedur, které nepracují pouze jako rozcestník, ale rovnou provádí celý výpočet. Procedura na základě vstupního parametru @Cislo dohledá všechny zájezdové faktury, které mají stejné číslo nebo číslo dodavatelské faktury. Tato funkce rozšiřuje možnosti filtrování seznamu objednávek v hlavním okně CRM a vrací pouze seznam ID příslušných objednávek. 9. hsp_HledaniZKli Druhá z procedur bez rozcestníku vrací také pouze seznam ID objednávek, který je v aplikaci CRM využit pro filtrování objednávek v hlavním okně. Procedura vrací objednávky

64

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ s termínem do jednoho měsíce, u kterých má klient nedoplatek. Tento seznam může být omezen na konkrétního prodejce, prodejní team nebo všechny, které konkrétní prodejce zastupuje.

10. hsp_Org_CZ/SK Tato procedura slouží pro hledání organizací na základě části názvu nebo známého IČ. Do aplikace CRM je vrácen seznam všech informací o nalezených organizacích, aby mohl uživatel posoudit, zda se jedná skutečně o hledanou společnost. Tato funkce slouží pro dohledávání stávajících organizací při vystavení faktury na poukazy a má přednost před založením nové organizace. 11. hsp_PenizeNaCeste_CZ/SK Vrací informace o platebních příkazech, které zatím nebyly potvrzeny bankovním výpisem a jsou tedy považovány za peníze na cestě. Společně s procedurami hsp_Denik_CZ/SK a hsp_DenikSumy_CZ/SK tak tvoří úplný obraz stavu financí u objednávky. 12. hsp_PlatbyHotoveFa Tato procedura je podobným rozcestníkem jako následující hsp_PlatbyHotove_CZ/SK s tím rozdílem, že jako vstupní filtr plateb v hotovosti nepoužívá @id_Objednavka, ale stát Heliosu a ID konkrétní faktury z tabulky TabDokladyZbozi. Přehled slouží pro zobrazení plateb v hotovosti k fakturám za poukazy a umožňuje tisk těchto pokladních dokladů. 13. hsp_PlatbyHotove_CZ/SK Vrací seznam všech plateb pro konkrétní @id_Objednavka nebo ID faktury (při volání z hsp_PlatbyHotoveFa). Vrací všechny sloupce tak, aby bylo přímo z CRM možné vytisknout pokladní doklad. Částka je vždy vrácena v měně dokladu a tato měna je součástí výpisu. Zobrazení částky slovy v příslušném jazyce na tiskové sestavě je úkolem CRM. 4.4.5.3

Evidence faktur od CK

Správa přijatých faktur zůstává i v novém systému nadále v aplikaci CRM. Přesouvá se pouze datové úložiště z tabulky Objednavky_Faktury mezi faktury řady 023 Heliosu, uložené v tabulce TabDokladyZbozi. Spolu s touto změnou se mění také režim správy do formy volání stored procedur. Seznam přijatých faktur pro konkrétní objednávku zajišťuje procedura hsp_FaCK, jak je popsáno výše. Na základě tohoto výpisu je zobrazen seznam faktur objednávky a prováděny úpravy. Přidání nové faktury zajišťuje procedura hsp_ZapisFaCK, která slouží pouze jako rozcestník a předává vstupní parametry obecné SP hsp_ZapisFa_CZ/SK z českého nebo slovenského Heliosu. U každé faktury se zadává pouze částka, číslo, splatnost a případná poznámka. Na konci procedury je vráceno ID nově vytvořené faktury, aby bylo možné s novým řádkem dále pracovat, konkrétně přikládat přílohy. Dobropisy se zapisují stejně jako běžné faktury, liší se pouze záporným znaménkem u částky. Další operace, kterou lze provést s přijatou fakturou je přiložení dokumentu procedurou hsp_PrilozitDokumentFP. Ta pomocí obecné procedury hsp_PrilozitDokument_CZ/SK k záznamu v Heliosu uloží naskenovaný dokument. Každá faktura je zapisována do aktuálního období, částka je uváděna v hlavní měně platné pro den zápisu a je ihned zaúčtovaná do sborníku 023. Zapsané faktury lze později upravovat přímo z aplikace CRM stored procedurou hsp_OpravaFaCK. Ta slouží, podobně jako zápis faktury, pouze jako rozcestník na obecnou proceduru hsp_OpravitFa_CZ/SK. Úpravy je možné provádět


65

i u dokladů zapsaných v uzavřeném období. Ošetření správné změny v zaúčtování faktury vyřeší obecná procedura pro opravy faktur. Zapsané faktury nelze z CRM aplikace odúčtovat, a tedy ani odstranit. Jedná se o zapsaný doklad a jeho případné odstranění je v kompetenci finančního oddělení. Aplikace umožňuje zapsané faktury opravovat a zapisovat případné dobropisy, takže pro funkci odstranění neexistuje důvod. Z preventivních důvodů není nikde v systému implementována operace odúčtování žádného dokladu, ani jeho odstranění. 4.4.5.4

Evidence faktur pro zaměstnavatele

Celá evidence faktur pro zaměstnavatele řady 0*1 je v novém systému přesunuta do aplikace CRM, což umožňuje jejich úplnou správu bez účasti finančního oddělení. V původním systému byla evidence umístěna v aplikaci CRM_Finance.mdb a celý proces vystavení byl velmi komplikovaný (viz 3.1.3). Seznam vystavených faktur objednávky, podobně jako v případě faktur od CK, zajišťuje procedura hsp_FaZam popsaná výše. Narozdíl od předchozího případu obsahuje výpis všechny sloupce potřebné pro správné zobrazení a tisk faktury, který probíhá rovněž přímo z aplikace CRM. Procedura má také jako jediná kladeny požadavky na pořadí vrácených sloupců. To musí odpovídat pořadí vstupních parametrů stored procedury hsp_ZapisFaZam_CZ/SK a CRM, protože CRM této souvislosti využívá pro jednodušší manipulaci se záznamy. Vytváření nových faktur i úpravu stávajících zajišťuje procedura hsp_ZapisFaZam_CZ/SK a jí předřazený rozcestník. Procedura současně obsahuje i parametry pro správu organizace na faktuře. Nové faktury se po zápisu neúčtují a čekají v nezaúčtovaném stavu na svou úhradu. Samotný zápis faktury tedy neprovádí žádné změny v účtování objednávky ani stavu financí. Před zápisem dat do databáze dochází ke kontrolám zabraňujícím vznik nekonzistentních dat. Porušení některé z podmínek vrátí chybu a neprovede žádné změny v databázi. Mezi tyto kontroly patří: • Součet všech částek na fakturách pro zaměstnavatele nesmí být vyšší, než je celková cena zájezdu. • Nelze upravit neexistující fakturu. • Nelze upravit zaúčtovanou fakturu. • Nelze vystavit dobropis ani fakturu na nulovou částku. Jsou-li tyto podmínky splněny, procedura uloží informace o organizaci pomocí hsp_ZapisOrg_CZ/SK a aktualizuje informace na stávající faktuře příkazem UPDATE, nebo zapíše novou fakturu pomocí hsp_ZapisFa_CZ/SK. Jedním ze vstupních parametrů je hodnota @SumaUhrad umožňující vystavit fakturu jako uhrazenou. Při vyplnění tohoto parametru jsou od faktury odstraněny stávající úhrady z tabulky TabUhrady a zapsána nová ve výši odpovídající hodnotě parametru. Při změně faktur je spouštěn externí trigger et_TabDokladyZbozi, který při změně úhrad spouští proceduru hsp_UhradaFa_CZ/SK. V té se kontroluje stav upravovaných faktur a v případě úhrady nezaúčtovaného dokladu řady 0*1 pro zaměstnavatele je tento doklad zaúčtován. V účetním deníku tedy přibude částka faktury na účtech 315400/325400 ve sborníku 068 a dojde k účetnímu navýšení ceny zájezdu. Proto je ihned zavolána stored procedura hsp_ZapisFaKli, která tento rozdíl zohlední a sníží částku faktury 068 i její účtování. Celá operace tak část celkové ceny zájezdu převede z faktury 068 pro klienta na fakturu 0*1 pro zaměstnavatele. Pokud byla faktura 068 již uhrazena klientem v plné výši, dojde snížením její částky k přeplatku. Z pohledu faktur je tento přeplatek evidován jako přebytek úhrad faktury v tabulce TabUhrady a je kontrolován při vystavování platebního příkazu. Účetně sice došlo ke

66

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Stav před zaúčtování faktury 0*1 pro zaměstnavatele Účet Má dáti Dal Částka Popis 315400 10 000 Faktura 068, předpis ZaplatitKlientovi. 325400 10 000 Faktura 068, předpis faktur od CK. 221xxx 10 000 Úhrada celé částky převodem. 315400 10 000 Zaúčtování úhrady 068 na účet ZaplatitKlientovi. Stav po zaúčtování 0*1 a úpravě faktury řady 068 Účet Má dáti Dal Částka Popis 315400 5 000 Snížená faktura 068, předpis ZaplatitKlientovi. 325400 5 000 Snížená faktura 068, předpis faktur od CK. 221xxx 10 000 Nezměněná úhrada celé částky převodem. 315400 10 000 Zaúčtování úhrady na účet ZaplatitKlientovi. 221xxx 5 000 Úhrada faktury 0*1 převodem. 315400 5 000 Zaúčtování úhrady 0*1 na účet ZaplatitKlientovi. 315400 5 000 Faktura 0*1, předpis ZaplatitKlientovi. 325400 5 000 Faktura 0*1, předpis faktur pro CK. Tabulka 4.7: Ukázka účtování faktury pro zaměstnavatele řady 0*1

snížení částky v deníku na účtu 315400, u objednávky ale nadále zůstává zaúčtovaný bankovní výpis, nebo platba v hotovosti zajišťující správnou evidenci vzniklého přeplatku hodnotou ZaplatitKlientovi. Situaci před a po zápisu faktury ilustruje tabulka 4.7. V tabulce je vidět, že po účtování faktury pro zaměstnavatele řady 0*1 a úpravě faktury 068 nedošlo ke změně evidované ceny celkem. Součet účtu 315400 na straně „má dáti“ zůstal v obou případech na hodnotě 10 000. Je zde také vidět součet stejného účtu na straně „dal“ 15 000 odpovídající součtu příchozích plateb od klienta (resp. jeho zaměstnavatele). Porovnáním těchto účtů se vyčíslí hodnota ZaplatitKlientovi, která eviduje přeplatek 5 000. Úhrada faktury 0*1 je uvedena před samotnou fakturou, protože byla zapsaná dříve a až jejím zápisem došlo k zaúčtování faktury 0*1. Na pořadí řádků v účetním deníku pro účely výpočtu nezáleží. Stejně jako u faktur od CK není v CRM implementována funkce pro odstranění faktury. Narozdíl od faktur od CK ale nelze změnit zaúčtovanou fakturu. Ta byla již odeslána, uhrazena a není ji tedy možné upravovat. Případné opravy údajů na zaúčtovaných fakturách musí ručně provést účetní oddělení. 4.4.5.5

Změna stavu objednávky

Každá objednávka prochází během prodejního procesu různými stavy, jejichž seznam je uveden v tabulce 3.1. Každý stav může mít jiný vliv na finance objednávky a proto je nutné, aby bylo účetnictví o těchto změnách informováno. Proto CRM před každou změnou stavu volá proceduru hsp_ZmenaStavu, která provádí následující kroky: 1. Přenos objednávky do tabulky TabZakazka. V dalším kroku je ošetřena přítomnost objednávky v tabulce TabZakazka procedurou hsp_SyncObj_CZ/SK. Ta zajišťuje přenos objednávky vytvářející pohledávku u klienta do Heliosu. Oproti tomu se u stornovaných objednávek pokouší o odstranění záznamu z tabulky TabZakazka, nejsou-li na řádek navázány další údaje. 2. Zápis faktury klientovi řady 068.


67

U objednávek ve stavu tvořícím pohledávku u klienta jsou tyto pohledávky zapsány procedurou hsp_ZapisFaKli, která zapisuje nové faktury řady 068 nebo upravuje stávající. Procedura je volána i u stornovaných objednávek, aby bylo možné vynulovat požadovanou částku, případně jí přepsat na výši storno poplatku. Samotná procedura funguje pouze jako rozcestník. Vypočte aktuální částku pro zápis faktury podle vzorce uvedeného výše a zavolá proceduru hsp_ZapisFaKli_CZ/SK, popsanou v části 4.4.5.6. 3. Uložení předpisu provize do Heliosu. Posledním krokem hsp_ZmenaStavu je zápis provize do účetnictví procedurou hsp_ZapisProv u prodaných a stornovaných objednávek. Procedura je volána i pro stornované objednávky, aby mohla být případně zapsaná provize vynulována, nebo přepsána na provizi ze storno poplatku. Procedura hsp_ZapisProv slouží opět pouze jako rozcestník na hsp_ZapisProv_CZ/SK. Vlastní zápis přepočte částku provize do hlavní měny, zjistí aktuálně zapsanou provizi na účtu 800 (viz. 4.2) procedurou hsp_StavDeniku_CZ/SK a tato dvě čísla porovná. V případě, že došlo ke změně provize a v Heliosu je jiná částka než v CRM, je rozdíl zaúčtován k zakázce na účty 800/801 na nový interní doklad. 4.4.5.6

Zápis interní faktury klientovi řady 068

Vydané faktury řady 068 evidují u každé zakázky celkovou cenu zájezdu a tedy výši pohledávky od klienta. Faktury 068 se účtují jako 315400/325400 (viz 4.2.1), kde na straně „má dáti“ evidují hodnotu ZaplatitKlientovi a na straně „dal“ očekávanou výši faktur od CK. Část z těchto předpisů může být evidována na fakturách řady 0*1, které se účtují stejně a jsou popsány v sekci 4.4.5.4. U jedné objednávky může existovat maximálně jedna faktura řady 068 a libovolné množství faktur pro zaměstnavatele 0*1. Při změnách celkové ceny zájezdu se upravuje pouze faktura 068 tak, aby součet všech těchto faktur udával celkovou cenu zájezdu podle CRM. Pravidlo existence maximálně jedné faktury 068 je zavedeno z několika důvodů: • Minimalizace počtu záznamů v databázi. Dojde-li ke změně ceny zájezdu je dohledána stávající faktura 068, upravena její částka i zaúčtování a nejsou vytvářeny nové záznamy. Reprezentace takové změny jako vytvoření a zaúčtování rozdílové faktury by znamenalo přidání několika nových řádků do databáze. Změna ceny je v prodejním procesu častá operace a tak by se brzy vytvořilo velké množství těchto faktur na malé částky. • Zjednodušení SQL dotazů. V případě, že existuje maximálně jedna faktura řady 068 lze zjednodušit většinu SQL dotazů pracujících s těmito fakturami. Není třeba ošetřovat, že hledaný údaj (např. číslo účtu klienta, viz níže) může být na kterékoli z faktur, případně že se údaje na různých fakturách mohou lišit nebo si protiřečit. Současně s tím lze zjednodušit dotazy používající JOIN, u kterých není nutné přidávat GROUP BY podle čísla zakázky. • Jednoznačná evidence dodatečných údajů – čísla bankovního účtu klienta. Faktury řady 068 jsou svou datovou strukturou vhodným místem pro ukládání dodatečných informací potřebných pro správnou funkci systému. Takovým údajem je například číslo bankovního účtu klienta pro vrácení přeplatku. Bankovní spojení se ukládá pouze k organizaci, kterou lze přiřadit konkrétní faktuře.

68

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Pokud by existovalo více těchto faktur u jedné objednávky, mohla by vzniknout situace, při které se na různých fakturách nachází různé číslo účtu a nebylo by možné jednoznačně určit, na které mají být peníze vráceny. Podobný problém by existoval i u zápisu těchto pomocných informací – nebylo by jednoznačné, na kterou fakturu se mají uložit. Podobný problém by byl s příchozími platbami, u kterých by nebylo jednoznačně stanoveno, ke které faktuře patří. • Transparentnost operací při změně ceny zájezdu. Pokud by byl systém navržen tak, že by umožňoval současnou existenci více faktur 068 a snažil se tyto faktury při změnách ceny upravovat, bylo by komplikované implementovat logiku pro rozdělení částky mezi všechny faktury33 .

Pro zápis faktury slouží procedura hsp_ZapisFaKli, která vypočte zapisovanou částku @Castka a dále funguje pouze jako rozcestník na proceduru hsp_ZapisFaKli_CZ/SK realizující vlastní zápis. Výpočet částky je určen podle vztahu:   

@Castka =

0 pro id_Stav ∈ h0, 29i \ {15} CenaCelkem pro id_Stav ∈ h30, 100i ∪ {15}   StornoPoplatek jinak

Stavy do hodnoty 30 nejsou pro evidenci financí významné, prodejce intenzivně komunikuje s klientem, připravuje cestovní smlouvu a mnoho objednávek je z těchto stavů rovnou stornováno. Často nebývá v CRM uvedena kalkulace a objednávky tak mají uvedenou nulovou cenu. Smlouva nebyla klientem podepsána a nevzniká žádná pohledávka. Od stavu 30, tj. „Smlouva podepsaná“, vzniká pohledávka, kterou je nutné uhradit, a tato pohledávka je ve výši celkové ceny zájezdu. Všechny platby od klienta tedy budou hradit takto vzniklou pohledávku evidovanou na fakturách pro klienta řady 068. Mezi ostatní stavy patří pouze stornované objednávky. U těch existuje pohledávka pouze v případě, že je zadán storno poplatek. Ten u stornovaných zájezdů přebírá úlohu celkové ceny zájezdu a udává tak výši očekávaných plateb od klienta. Speciálním případem je hodnota id_Stav = 15, tj. „Vyžádání zasláno do CK“. Je to mezistav při prodeji zájezdu na vyžádání a v pořadí stavů nastává zpravila až po podepsání smlouvy a úhradě zálohy klientem. U zájezdů na vyžádání musí klient uhradit zálohu, na základě té je odeslána smlouva do CK a cestovní kancelář až poté kontaktuje cílový hotel a vytváří rezervaci. Není tedy zaručeno, že vytvořením rezervace v samotné CK bude volné místo v požadovaném hotelu. Pokud se cestovní kanceláři nepodaří zájezd vyžádat, je cestovní smlouva zrušena bez storno poplatku a peníze vráceny klientovi. V opačném případě je vše potvrzeno a objednávka je dokončena běžným způsobem. Samotný zápis faktury klientovi řady 068 zajišťuje procedura hsp_ZapisFaKli_CZ/SK. Ta se pokusí snížit zapisovanou částku o součet zaúčtovaných faktur 0*1 a dohledat stávající fakturu 068. V případě nalezení takové faktuře dojde pouze k úpravě její částky, jinak je zapsána nová faktura. Celý proces je znázorněn na diagramu 4.4. Aby nedocházelo k duplicitnímu zakládání faktur řady 068, je zde použita systémová procedura sp_GetAppLock, která umožňuje uvnitř otevřené transakce vytvořit kritickou sekci přístupnou pouze této transakci. Exkluzivní přístup je rozlišován podle klíče, který obsahuje ID objednávky. Uvnitř kritické sekce se tak sice mohou vyskytovat různé transakce, musí však pracovat s různými objednávkami. Kromě toho je na začátku procedury dvojí načítání dat, aby bylo vytvářeno pouze nezbytně nutné množství transakcí. V prvním kroku jsou načtena data a je ověřeno, zda došlo ke změně 33 Rozdělení 10 000 mezi tři faktury by v případě rovnoměrného rozdělování znamenalo upravit faktury a jejich účtování na 333,33, 333,33 a 333,34.


69

hsp_ZapisFaKli_CZ/SK Mezi prvním naþtením hodnot a vstupem do kritické sekce mohlo dojít ke zmxnx dat jinou transakcí. Proto se data naþítají znovu.

Naþtení informací o zaúþtování

Naþtení informací o zaúþtování

Odeþtení zaúþtovaných faktur Ĝady 0_1

Odeþtení zaúþtovaných faktur Ĝady 0_1

[ýástka se nezmČnila]

[ýástka se nezmČnila] Potvrzení transakce, uvolnxní kritické sekce

OtevĜení transakce, vstup do kritické sekce pro upravovanou objednávku Naþtení informací o fakturách Ĝady 068 [Existuje více faktur]

Odeslání upozornxní emailem hsp_SendMail_CZ/SK [Existuje více zaúþtovaných faktur]

Nutno opravit ruþnx. PĜebyteþná faktura se musí odúþtovat a odstranit.

[Faktura neexistuje]

Zápis a zaútování nové faktury 068 hsp_ZapisFa_CZ/SK

[Existuje jedna faktura]

Úprava þástky faktury, je-li v hlavní mČnČ

ýástka k zaúþtování je snížena o doklady z uzavĜených obdobích

[Existuje více dokladĤ s úþtem 325400 v otevĜených obdobích]

[Existuje jeden doklad v otevĜeném období] [Neexistuje žádný doklad v otevĜeném období]

Odeslání upozornxní emailem hsp_SendMail_CZ/SK

Zaúþtování nového dokladu hsp_ZauctovatDenik_CZ/SK

Úprava stávajícího dokladu, þástka snížena o úþet 315410

Potvrzení transakce, uvolnxní kritické sekce

Obrázek 4.4: Zápis faktury klientovi hsp_ZapisFaKli_CZ/SK

70


ceny zájezdu a je nutné upravovat faktury. Pokud ano, je spuštěna transakce pro ochranu před případnými chybami a zajištěn vstup do kritické sekce pro konkrétní objednávku. V tomto stavu jsou znovu načteny data z databáze a znovu ověřeno zda došlo ke změně částky. Mezi prvotním načtením dat a vstupem do kritické sekce by mohlo dojít ke změnám v datech, které by mohly ve svém důsledku znamenat i dvojí zápis faktury. Jedná-li se o první zápis faktury, je pouze procedurou hsp_ZapisFa_CZ/SK vytvořena a zaúčtována nová faktura 068 a potvrzena transakce. Pokud v systému faktura 068 pro konkrétní objednávku již existuje, musí být upravena. Samotná úprava se skládá ze dvou kroků a to úpravy částky na faktuře a úpravy zaúčtované částky v deníku. S ohledem na možné uzavření období nebo přechod na měnu Euro mohou nastat tři případy: • Změna faktury z otevřeného období. Toto je nejběžnější a nejjednodušší případ, při kterém byla faktura vystavena v otevřeném období a lze ji upravovat. Procedura pouze upraví částku na faktuře a zaúčtovanou částku na dokladu v účetním deníku. • Změna faktury z uzavřeného období. Pokud se faktura nachází v uzavřeném období, bude i její zaúčtování (nebo jeho část) spadat do tohoto období a nelze provést změnu stávajícího dokladu v deníku. V takovém případě je pouze upravena částka na faktuře34 a nově zapisovaná částka je snížena o doklady zapsané v uzavřených obdobích. Následně se procedura pokusí dohledat doklad k faktuře v otevřeném období. Pokud existuje tak je upraven na zbytkovou částku. Neexistuje-li, je založen nový doklad v aktuálním období procedurou hsp_ZauctovatDenik_CZ/SK s vazbou na původní fakturu. Tato vazba zajistí, že bude faktura zaúčtována na více různých dokladů z různých období. • Změna faktury vystavené před přechodem na měnu Euro. Poslední skupinou jsou případné úpravy faktur, zapsaných před přechodem na Euro, prováděných po přechodu na Euro. V takovém případě nelze provést změnu částky na faktuře, protože systém Helios sleduje databázovým triggerem veškeré úpravy v tabulce TabDokladyZbozi a při pokusu o změnu dat vrátí SQL triggerem chybu. Z tohoto důvodu mohou v systému vzniknout faktury, které mají fyzicky jinou částku, než je součet jejich dokladů v deníku. Pro veškeré výpočty se proto používá částka v deníku, která je vždy správně. Při takovéto změně je pouze upraven, nebo přidán, doklad v aktuálním období tak, jak je to v předchozím případě. Při úpravě stávajícího dokladu v účetním deníku může dojít ke změně dokladu, u kterého byla provedena operace přeúčtování z 315400 na účet 315410 (viz 11). Proto se před vlastní úpravou ověří přítomnost účtu 315410 na dokladu a případná změna účtu 315400 zohlední toto přeúčtování. 4.4.5.7

Platby v hotovosti

Pro zápis plateb realizovaných v hotovosti slouží vstupní procedury hsp_ZapisPlatbyHotove a hsp_ZapisPlatbyHotoveFa. Obě jako první krok vrátí chybu při pokusu o zápis nulové částky a dále pracují pouze jako rozcestník na hsp_ZapisPlatbyHotove_CZ/SK. Procedury umožňují zapsat platbu různými způsoby: 34 Změna částky faktury z uzavřeného období sice není v uživatelském rozhraní povolena, ale neznamená žádné problémy.


71

• hsp_ZapisPlatbyHotove Zapisuje platbu k zakázce a využívá se pro běžné vytvoření pokladního dokladu u libovolné objednávky v CRM. Před voláním procedury hsp_ZapisPlatbyHotove_CZ/SK je ještě ověřeno, že stát pokladny, určený vstupním parametrem @Stat, odpovídá státu objednávky, aby byl zajištěn zápis dokladu ve správné měně. Přes CRM nelze vytvářet pokladní doklady v cizích měnách. • hsp_ZapisPlatbyHotoveFa Zapisuje platbu k vydané faktuře, což je použito pro zápis pokladního dokladu k fakturám 0*6 na poukazy. Procedura přijme vstupním parametrem @fID hodnotu ID z tabulky TabDokladyZbozi konkrétní faktury a zapíše k ní přijatou platbu. Vlastní vytvoření a případné zaúčtování nového pokladního dokladu zajišťuje procedura hsp_ZapisPlatbyHotove_CZ/SK. Vstupními parametry procedury jsou číslo zakázky, ID faktury, částka dokladu, číslo pokladny, poznámka a login autora dokladu. Není zde uveden typ dokladu, který je určen znaménkem vstupní částky – záporná částka znamená výdajový pokladní doklad. Vlastní vytvoření dokladu probíhá v těchto krocích: 1. Načtení úvodních informací. Procedura na základě částky určí typ dokladu jako příjmový nebo výdajový, načte aktuální datum, ověří zda je vyplněno číslo pokladny a zda tato pokladna existuje. Pokud není číslo pokladny platné je vrácena chyba a procedura se ukončí. Spolu s těmito informacemi jsou načtena i ID období a období stavu potřebná pro založení dokladu. 2. Ošetření platby k objednávce. U plateb zapisovaných k objednávce je před vlastním zápisem ověřena přítomnost cílové objednávky mezi zakázkami procedurou hsp_SyncObj_CZ/SK. Po této operaci je ještě zavolána procedura hsp_ZmenaStavu s parametrem @id_Stav=35, tj. „Uhrazena záloha“. Tento krok vynutí přítomnost faktury 068 v Heliosu. Zápis platby může nastat také ve stavu, kdy faktura pro klienta řady 068 ještě nebyla vytvořena a zápis pokladního dokladu by tak nemohl dohledat ID této faktury pro zápis úhrady. 3. Vytvoření textu dokladu. U pokladních dokladů zapisovaných k objednávkám i fakturám je podle vstupních parametrů vytvořen příslušný text. U objednávek je součástí textu jméno klienta a ID objednávky z CRM, u faktur je to číslo hrazené faktury. Není-li při hledání čísla faktury podle ID faktura nalezena, je vrácena chyba a procedura ukončena. 4. Uložení pokladního dokladu. Dále je vypočteno nové pořadové číslo pokladního dokladu v požadované pokladně a aktuálním období a uložen nový pokladní doklad s tímto číslem do tabulky TabPokladna. U dokladů zapisovaných k objednávkám je použito číslo předkontace nastavené u konkrétní pokladny. U dokladů hradících konkrétní faktury bez určení čísla zakázky je použita předkontace definovaná v kódu. Tato předkontace účtuje doklad k faktuře řady 0*6 na poukazy. Není-li parametr @fID, nesoucí ID cílové faktury, vyplněn, je do něj uloženo ID příslušné faktury řady 068. Hodnota parametru @fID je následně uložena do externího sloupce TabPokladna_EXT._id_DokladyZbozi k nově vytvořenému dokladu. Tato hodnota se používá v proceduře hsp_UctovaniPokladny_CZ/SK spouštěné databázovým triggerem při zaúčtování dokladu, viz 4.4.9.2.

72

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 5. Zaúčtování nového dokladu. Má-li zdrojová pokladna vyplněný sborník pro účtování dokladů, je nově vytvořený doklad rovnou zaúčtován. Platí zde omezení, že je účtován pouze první doklad zapsaný k zakázce v jeden den, aby se předešlo duplicitnímu zapisování a účtování dokladů. Zapíše-li prodejce v jeden den dva doklady, je druhý vytvořen pouze jako nezaúčtovaný, aby se předešlo situaci při které je na účtu 315400 (platby od klienta) evidován dvojnásobek skutečné částky. Případné odúčtování prvního dokladu v případě jeho neplatnosti a zaúčtování druhého v opačném případě je již úkolem obsluhy aplikace Helios a provádí se na základě skutečné soupisky pokladny a částky složené z pokladny na bankovní účet společnosti. Zaúčtování každého dokladu probíhá pouze do fáze „Pořízeno“. Tato fáze slouží pro odlišení financí, které jsou fyzicky v pokladně a nejsou k dispozici na bankovním účtu pro úhradu zájezdu do CK. Zakázky obsahující účetní doklady ve fázi „Pořízeno“ jsou v přehledu Platby označeny modrou barvou, aby byla obsluha upozorněna na tuto skutečnost. Peníze jsou ale fyzicky převedeny do společnosti, jsou zaúčtovány na účtu 315400 a platbu za zájezd tedy lze do cestovní kanceláře odeslat. 6. Vrácení ID nového dokladu. Posledním krokem procedury je vrácení ID nově vytvořeného pokladního dokladu. Aplikace CRM si tuto hodnotu uloží, obnoví si seznam pokladních dokladů objednávky procedurou hsp_PlatbyHotove, popsanou v části 4.4.5.2, dohledá podle ID nový doklad a ten zobrazí ve verzi pro tisk.

4.4.5.8

Správa plateb

Zde jsou popsány ostatní funkce CRM pracující s evidencí financí. 1. Zápis platby bankovním převodem. Tato akce je přítomná v CRM pouze z důvodu, aby provedení akce bylo zapsáno v historii objednávky a došlo ke změně stavu objednávky. Při akci se nevolá žádná speciální procedura a je volána pouze hsp_ZmenaStavu. Příchozí platby realizované bezhotovostním převodem jsou v novém systému evidovány na základě bankovních výpisů, které jsou pravidelně párovány k zakázkám a účtovány. Tuto činnost zajišťuje finanční oddělení nebo obsluha přehledu Platby. Zaúčtováním řádku bankovního výpisu na účet 221xxx/315400, nebo 325100/221xxx při příchozí platbě z CK, je evidována příchozí platba k objednávce a zařazena do výpočtu hodnot ZaplatitKlientovi, popř. ZaplatitCK. 2. Zápis platby klienta přímo do CK. Zápis platby klienta přímo na účet cestovní kanceláře je realizován rozcestníkem hsp_ZapisPlatbyKliCK a procedurou hsp_ZapisPlatbyKliCK_CZ/SK. Ta do sborníku 031 zaúčtuje pomocí hsp_ZauctovatDenik_CZ/SK částku převodu jako 325100/315400 a vyrovná tak hodnotu ZaplatitKlientovi oproti ZaplatitCK. Procedura hsp_ZapisPlatbyKliCK může být volána z procedury hsp_ZapisPlatbyCKKli z Heliosu. V tomto případě je částka záporná a je tak zapsána platba cestovní kanceláře zpět klientovi. Zapsaný interní doklad je vytvořen pouze do fáze „Pořízeno“ a v tomto stavu čeká na své potvrzení. Platbu v CK ověřuje telefonicky nebo emailem obsluha přehledu Platby, aby bylo ověřeno, že klient peníze skutečně odeslal. Objednávky obsahující doklad ve fázi


73

„Pořízeno“ jsou v přehledu Platby zvýrazněny modře, stejně jako platby v hotovosti, které zatím nebyly převedeny na bankovní účet. Na konci procedury je ještě dohledána vydaná faktura 068 klientovi a přijatá řady 023 od CK a jsou k nim ručně zapsány příslušné úhrady. 3. Přesun platby. Přesun existující platby je poslední operace manipulující s údaji v deníku a realizuje přeúčtování řádků v deníku od jedné zakázky k jiné. Současně s tím přesouvá návazné úhrady, pokud existují. Operace je realizována procedurami hsp_PresunPlatby a hsp_PresunPlatby_CZ/SK. Celá operace má několik kroků a je prováděna uvnitř transakce, aby během výpočtu nedošlo k vytvoření nekonzistentních dat. Výběr platby k přesunu je určen ID řádku z tabulky TabDenik a ID zdrojové i cílové objednávky. K cílové objednávce se nepřesouvá celý doklad, ale pouze řádky obsahující zdrojové číslo zakázky. Např. u bankovních výpisů jsou na jednom dokladu uvedeny všechny platby. Procedura hsp_PresunPlatby_CZ/SK se skládá z těchto kroků: (a) Načtení počátečních informací. Podle ID zdrojového řádku z tabulky TabDenik je dohledáno číslo dokladu, sborník, ID případného zdrojového pokladního dokladu a řádku bankovního výpisu. Neexistuje-li zdrojový doklad je transakce ukončena a vrácena chyba. Dále je procedurou hsp_SyncObj_CZ/SK zajištěno, že cílová zakázka existuje v databázi Heliosu. (b) Přeúčtování řádku účetního dokladu. V účetním dokladu jsou SQL příkazem UPDATE převedeny všechny řádky dokladu od zdrojové objednávky k cílové a je k nim doplněna poznámka o přesunu platby. (c) Úprava zdrojového pokladního dokladu. Je-li zdrojovým dokladem přesouvaného řádku pokladní doklad, je upraveno číslo zakázky u tohoto zdrojového dokladu a vyplněna nová hodnota TabPokladna_EXT._id_DokladyZbozi podle nově dohledané faktury 068. Následně je dohledáno ID úhrady, která je vytvořena právě tímto zdrojovým dokladem. (d) Úprava řádku bankovního výpisu. Je-li zdrojovým dokladem přesouvaného řádku řádek bankovního výpisu, je upraveno číslo zakázky tohoto řádku podobně, jako v předchozím kroku. Následně je také dohledáno ID případné úhrady k přesunu. (e) Přesun úhrady. Bylo-li v předchozích dvou krocích nalezeno ID úhrady, musí být tato úhrada také přesunuta k cílové objednávce. Nejprve je dohledána cílová faktura řady 068 nebo 0*1 a není-li žádná nalezena je transakce ukončena jako neúspěšná a vrácena chyba. Při nalezení cílové faktury je přesun faktury realizován procedurou hsp_PresunUhrady_CZ/SK, popsané v části 4.4.2. 4. Zápis bankovního účtu klienta. Zadání čísla bankovního účtu klienta je možné z Heliosu, přehledu Platby, a také z CRM. Pro zápis slouží vstupní procedura hsp_ZadatUcetKlienta, která je rozcestníkem na proceduru hsp_ZadatUcetKlienta_CZ/SK, popsanou v části 4.4.6.4.

74 4.4.5.9

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Práce s poukazy

Evidence poukazů v tabulce Poukazy zůstává v novém systému nezměněna, mění se ale způsob jejich placení. Na každý poukaz, včetně objednaných na webu, je vystavena faktura řady 0*6 a klient hradí poukaz pod variabilním symbolem této faktury. Úhradou faktury je spuštěn trigger et_TabDokladyZbozi, který zajistí aktivaci všech poukazů na faktuře a rozeslání informací klientům e-mailem, viz 4.4.9.1. U poukazů objednaných on-line na webu společnosti jsou faktury vystavovány automaticky na základě řádků v tabulce Poukazy_Faktury. Aplikace CRMSync jako jeden ze svých úkolů pravidelně spouští proceduru hsp_FakturacePoukazuAuto, která provede vystavení všech faktur čekajících na vystavení v tabulce Poukazy_Faktury pro Českou republiku i Slovensko. Procedura pro každý stát ověří, zda existují faktury k vystavení a zavolá hsp_FakturacePoukazuAuto_CZ/SK pro jejich vystavení, viz 4.4.8. Každý vystavený poukaz musí znát ID faktury z tabulky Poukazy_Faktury, kterým je fakturován. Ruční vystavení faktury z CRM se tedy provádí jako vložení nového záznamu do této tabulky a zavoláním procedury hsp_FakturacePoukazuAuto. Celý proces je tak shodný s postupem při objednávce z webu. Úhrada takto vystavených faktur se provádí na základě bankovního výpisu hradícího příslušnou fakturu řady 0*6 v Heliosu, nebo v hotovosti procedurou hsp_ZapisPlatbyHotoveFa, popsanou v části 4.4.5.7. Pro uplatnění poukazu k objednávce slouží procedura hsp_UplatnitPoukaz, která podle typu poukazu připraví účty pro jeho zaúčtování a podle státu objednávky zavolá hsp_ZauctovatDenik_CZ/SK pro vytvoření interního dokladu ve sborníku 030 podle připravených účtů. U většiny typů se pak zapisuje ještě úhrada procedurou hsp_ZapisUhradyKli_CZ/SK. Ta pouze dohledá ID faktury řady 068 nebo 0*1 a vytvoří u ní úhradu. Speciálním případem jsou poukazy od CK, u kterých se podle přítomnosti platby od klienta určuje, zda se jedná o poukaz ve vlastnictví NetTravel, nebo ve vlastnictví klienta, a podle toho se upravuje způsob účtování. Pro zajištění kontroly se při uplatnění takového poukazu navíc odesílá email s upozorněním, že byl takový poukaz uplatněn. 4.4.6

Správa odchozích plateb

Součástí tohoto projektu je vytvoření náhrady za aplikaci Platby.mdb tak, aby plně převzala funkce původní aplikace a vyřešila stávající problémy. Systém Helios umožňuje řadu rozšíření, která poskytují dostatek nástrojů, popsaných v části 4.3, aby se přímo do uživatelského rozhraní Heliosu doplnila sekce nahrazující Platby.mdb. Pro realizaci tohoto úkolu je použit definovaný přehled, jeho umístění formou externího soudečku a sada externích akcí pracujících s přehledem. Ukázka uživatelského rozhraní je na obrázku 4.5. Zobrazované informace jsou podobné jako v původní aplikaci Platby.mdb, jak je znázorněno na obrázku 3.6, jsou doplněny o peníze na cestě klientovi nebo CK a fond objednávky. Označování záznamů k úhradě se provádí klávesou Insert, tedy jako uživatelské označení záznamu (viz 4.3.2), a příkazová tlačítka spouštějící externí akce jsou umístěna v kontextovém menu. Nejčastěji používaným příkazům jsou přiřazeny klávesové zkratky. 4.4.6.1

Zobrazené informace

Výchozím bodem pro obsluhu plateb je definovaný přehled (SQL view) hvw_PlatbyMain, který je v uživatelském rozhraní umístěn pod soudeček Platby. Přehled umožňuje zobrazování informací z databáze a obarvování řádků předdefinovanými barvami. Systém Helios umožňuje navíc uživateli upravit pořadí zobrazených sloupců, definovat vlastní filtry a upravit řazení záznamů. Takto upravené sestavy lze uložit pod jménem a rychlým výběrem z panelu nástrojů sestavu


75

Obrázek 4.5: Ukázka uživatelského rozhraní Heliosu, soudeček Platby přepnout. V definovaném přehledu hvw_PlatbyMain jsou částky vždy zobrazeny v aktuální hlavní měně a jsou zde k dispozici tyto sloupce: Ozn – vizualizace uživatelského označení záznamu. Zaškrtnuté řádky byly uživatelem označeny klávesou Insert a budou použity pro generování dávky. ID – zobrazení ID objednávky. Termin – datum odjezdu z CRM. cFaktury – číslo první zapsané faktury do CRM. Hodnota zobrazuje informaci uvedenou v tabulce Objednavky. Klient – příjmení a jméno klienta podle CRM. CenaCelkem – celková cena zájezdu prodaných objednávek podle CRM, nebo výše storno poplatku u stornovaných objednávek. ZaplatitCK – součet účtu 325100, udávající skutečnou hodnotu ZaplatitCK, snížený o peníze na cestě CK. Ty se odečítají, aby zobrazená hodnota z pohledu uživatele vypadala jako vyřízená a neobjevovala se mezi objednávkami čekajícími na odeslání platby. ZaplatitKlientovi – součet účtu 315400 snížený o peníze na cestě klientovi. NaCesteCK – součet úhrad platebních příkazů odeslaných do CK, které zatím nebyly potvrzeny bankovním výpisem. Export platebního příkazu do dávkového souboru pro rozhraní internetového bankovnictví vytvoří úhradu v tabulce TabUhrady u každé faktury, která je přítomna mezi řádky platebního příkazu. Takto vzniklé úhrady mají ve sloupci

76

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ CastkaPoBance uvedenou celou částku až do okamžiku spárování bankovního výpisu. Zápis úhrady z bankovního výpisu tuto částku vynuluje a součtem sloupce CastkaPoBance úhrad zapsaných z platebních příkazů lze získat celkovou výši peněz odeslaných do banky a čekajících na potvrzení bankovním výpisem.

NaCesteKlientovi – součet úhrad platebních příkazů klientům, které zatím nebyly potvrzeny bankovním výpisem. Princip úhrad a práce se sloupcem CastkaPoBance je stejný pro přijaté i vydané faktury. Fond – součet účtů 325100 a 315400 snížený o peníze na cestě klientovi i CK. Hodnota fondu udává aktuální výši cash flow objednávky a tedy maximální realizovatelnou částku odchozí platby. Při generování dávky se tato hodnota používá pro omezení odchozích částky, aby NetTravel neodeslal více peněz, než kolik u objednávky obdržel. CK – název cestovní kanceláře podle CRM. PH – hodnota sloupce ProvizeHned objednávky. UcetKlient – číslo bankovního účtu klienta pro vrácení přeplatku. Bez vyplněného účtu nelze peníze odeslat. cRezervace – rezervační číslo zájezdu z tabulky Objednavky. ProvizeBezDPH – výše provize bez DPH. ProvizeSDPH – výše provize s DPH. id_Stav – ID udávající stav objednávky podle tabulky 3.1. StatCK – hodnota „cz“ nebo „sk“ udávající stát, ze kterého je pořádající cestovní kancelář. Další informace jsou v přehledu Platby zobrazeny odlišnou barvou pozadí řádku, barvou písma nebo jeho stylem. Helios umožňuje pomocí speciálních jmen sloupců, která začínají prefixem „_HeIQ_“, upravovat vzhled jednotlivých sloupců nebo celých řádků, jak je naznačeno u popisu uživatelských sloupců 4.3.2. V přehledu jsou použity tyto sloupce: _HeIQ_Barva definuje barvu písma celého řádku. Kromě výchozí černé barvy jsou použity: • Červená – součet přijatých faktur od CK řady 023 je vyšší, než je předpis celkové částky určený cenou zájezdu nebo storno poplatkem u stornovaných objednávek. Takto označené objednávky by neměly být hrazeny do CK do doby, než u nich budou opraveny faktury, případně zapsány chybějící dobropisy. • Modrá – u objednávky existuje řádek v účetním deníku, který je ve fázi „Pořízeno“. Tato fáze se využívá u automaticky účtovaných pokladních dokladů, které zatím nebyly převedeny na bankovní účet a ověřeny soupiskou (viz 4.4.5.7), neověřených plateb klienta přímo do CK (viz 4.4.5.8), nebo účtování fiktivních bankovních výpisů při předběžném potvrzení platby (viz 8). • Fialová – na vydané faktuře klientovi řady 068 je chybná částka, která v součtu účtu 325400 neodpovídá celkové ceně zájezdu, případně storno poplatku. Pro opravu tohoto stavu by měla být použita funkce „Opravit faktury klientovi (fialové)“ popsaná v části 4.4.6.4. _HeIQ_RB_ určuje barvu pozadí celého řádku. Kromě nuly, označující nezměněné pozadí35 , je v přehledu použita pouze žlutá barva, která označuje objednávky s neuhrazenou fakturou od CK řady 023 a splatností následující den. 35

Výchozí podbarvení řádků v přehledech střídá dva odstíny bílé.


77

_HeIQ_CF_Termin upravuje styl písma ve sloupci Termin na tučné v případě, že zbývá týden do odjezdu a zájezd není plně uhrazen v CK. Týden před odjezdem zasílají zpravidla cestovní kanceláře pokyny k zájezdu, ale pouze v případě, že je zájezd zaplacen. 4.4.6.2

Ovládání a práce s přehledem Platby

Ovládání přehledu vychází ze standardního chování uživatelského rozhraní Heliosu a možností jeho rozšíření. Kromě základního chování a navigace mezi záznamy je zde použita možnost uživatelského označování záznamů a externí akce pro spouštění všech operací. 1. Označování záznamů V nastavení externí akce typu procedura existují tři možnosti, jak získat informace o aktuálně označených záznamech. Na základě těchto informací pak může procedura pracovat se správnými záznamy. Tyto možnosti jsou: • Bez označování Proceduře nejsou žádným způsobem předávány informace o označených záznamech. Procedura provádí operaci, která není závislá na vybraném řádku. Takovou procedurou může být např. zrušení označení všech záznamů, popsanou níže, nebo spuštění akce nesouvisející s aktuálně otevřeným přehledem. • Označené řádky Při výběru této možnosti je jako poslední vstupní parametr přidána hodnota ze sloupce ID aktuálně označeného záznamu. Při využití této volby musí být takto pojmenovaný sloupec součástí přehledu. V případě, že uživatel označí s pomocí kláves Ctrl nebo Shift více záznamů, je procedura spuštěna pro každý takto označený záznam. • Pomocí uživatelského označení záznamů Poslední možností je předávání seznamu označených řádků pomocí uživatelského označování, popsané v části 4.3.2. Vlastní nastavení externí akce je stejné jako u první možnosti a rozdíl je pouze v chování volané externí procedury. Ta si může z tabulky TabUzivOzn zjistit seznam označených řádků, resp. jejich ID, pro aktuálního uživatele a známý název přehledu. Funkce uživatelského označování se do přehledu přidává jako počítaný sloupec se speciálním názvem _HeIQ_UzivOzn. Při jeho přítomnosti mezi sloupci přehledu umožňuje uživatelské rozhraní systému Helios označení libovolného záznamu klávesou Insert. Stejnou klávesou lze označit i více řádků najednou, jsou-li označeny pomocí kláves Ctrl nebo Shift. Zrušení označení se provádí stejně jako označování samotné. 2. Kontextové menu Všechny operace dostupné při práci s přehledem jsou definované jako externí akce. Ty se umísťují do kontextového menu přístupného pravým tlačítkem myši. V první úrovni tohoto menu jsou skupiny uživatelských akcí označeny znakem hvězdičky a jednotlivé akce se umísťují do druhé úrovně pod tyto skupiny. Pro usnadnění práce s přehledem jsou nejčastěji používaným akcím, jakými jsou otevření aplikace CRM nebo kontrola a generování dávek, přiřazeny klávesové zkratky. Rozložení jednotlivých příkazů do skupin je následující: • CRM Platby – příkazy související s placením zájezdů: – Kontrola dávky do CK,

78

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ – – – – – – – – – – –

Kontrola dávky klientům, Dávka CK, Dávka klientům, Platba CK klientovi, Spropitné od klienta, Uhradit ze spropitného klientovi, Spropitné od CK, Uhradit ze spropitného CK, Opravit faktury klientům (fialové), Změna provize hned, Zadat účet klienta.

• Ovládání – ovládání samotného přehledu: – Převzít označení jiného uživatele, – Zrušit označení všech, – Otevřít v CRM. • Účetnictví – funkce související s účtováním a ostatními moduly Heliosu: – – – –

Otevření deníku pro akt. zakázku, Zápis poplatku za SMS – RezaPortal, Storno poplatku za SMS – RezaPortal, Předběžné potvrzení platby výpisem.

3. Ovládání / Převzít označení jiného uživatele Externí akce se dotáže na parametr @Uzivatel, představující login jiného uživatele, a spustí proceduru hsp_PrevzitOzn_CZ/SK. Pro výběr hodnoty je použit typ parametru „Definovaný přehled“36 z přehledu uživatelského označení, u kterého je nastaven filtr na jméno tabulky hvw_PlatbyMain. Dotaz na hodnotu parametru tak nabídne uživateli seznam přihlašovacích jmen všech uživatelů, kteří mají v přehledu Platby uživatelsky označený alespoň jeden záznam. Procedura hsp_PrevzitOzn_CZ/SK odstraní označené záznamy aktuálního uživatele procedurou hsp_ZrusOzn_CZ/SK a na základě hodnoty parametru @Uzivatel zkopíruje řádky z tabulky TabUzivOzn od původního uživatele k novému. Tato funkce umožňuje, aby jeden uživatel připravil objednávky a jiný dávku vytvořil a odeslal do banky. Toto je využíváno např. při práci z domova přes vzdálenou plochu, kdy uživatel ve vzdálené lokalitě nemá přístup k internetovému bankovnictví a nemůže dávku odeslat, nebo v případě příprav dávek pro pobočku na Slovensku. Ta je delegována na zaměstnance pracujícího na Slovensku, který ale z organizačních důvodů nemá přístup k internetovému bankovnictví zájezdových účtů. Pomocí této funkce může dávku připravit, zkontrolovat její generování a vyřešit všechny problémy před vlastním odesláním dávky. Následně informuje českou stranu, která pouze dávku vygeneruje a odešle do banky. 4. Ovládání / Zrušit označení všech Tato akce spouští proceduru hsp_ZrusOzn_CZ/SK, popsanou v části 4.4.3 s parametrem odpovídající přehledu hvw_PlatbyMain. Na konci generování dávky se označení sice ruší 36

Viz 4.3.5.1.


79

automaticky, může ale vzniknout situace, ve které uživatel připravuje dávku a má z dřívějšího používání systému označené některé objednávky navíc. Pro zrušení označení všech objednávek, včetně těch, které nejsou vidět v aktuálně zobrazené sestavě, lze využít tuto funkci. 5. Ovládání / Otevřít v CRM Pro zjednodušení spolupráce Heliosu a CRM z pohledu uživatele je zde externí akce, která umožňuje klávesou Enter, a tedy i dvojklikem na řádek objednávky, otevřít v aplikaci CRM konkrétní objednávku. Externí akce neumožňují předat ID aktuálního záznamu externí aplikaci, narozdíl od stored procedur, a proto je zde tato funkce implementovaná jako dva kroky: (a) Externí akce Otevřít v CRM spouští externí proceduru hsp_OpenObj, které je předáno ID aktuálního záznamu. Ta ID záznamu uloží do sloupce id_Objednavka tabulky Zamestnanci k aktuálnímu zaměstnanci. U této akce je nastavena návazná akce Spuštění CRM. (b) Spuštění CRM je neveřejná akce typu „Program“, která spustí aplikaci CRM s parametrem „/z“. Tento parametr aplikaci oznámí, že si má z tabulky Zamestnanci načíst ID objednávky a tuto objednávku otevřít. Aplikace CRM umožňuje běh pouze jedné instance současně. Proto se při svém otevření pokusí najít již běžící instanci. Je-li nalezena, odešle jí zprávu o aktivaci a nově spuštěný program se ukončí. Stejný princip je použit i v případě spuštění s parametrem „/z“, který v případě nalezení již běžící instance odešle této instanci zprávu o otevření s tímto parametrem a ukončí se. Stávající spuštěné CRM si v tomto případě opět načte hodnotu z tabulky Zamestnanci a objednávku otevře. Helios spouští externí programy synchronně a čeká na jejich ukončení. Proto spuštění nové instance CRM zastaví běh Heliosu do doby, než je aplikace CRM ukončena. Pokud ale CRM běží před spuštěním akce, je formou zprávy předána informace o otevření objednávky, spuštěný program se ukončí a Helios může pokračovat ve své činnosti. 4.4.6.3

Generování platebních příkazů – dávek

Generování platebních příkazů je stěžejní úkol celé aplikace. Během vytváření dávky je prováděna řada kontrol, které zajišťují správný výpočet a oznámení všech problémů souvisejících s objednávkami a jejich fakturami. Během výpočtu musí být zajištěno, že nebude odesláno více, než kolik bylo u konkrétní objednávky přijato. S generováním platebních příkazů souvisí čtyři akce kontextového menu přehledu Platby umístěné ve skupině CRM Platby: • Kontrola dávky do CK, • Kontrola dávky klientům, • Dávka CK, • Dávka klientům. Všechny tyto externí akce spouští jedinou proceduru hsp_Davka_CZ/SK, která zajišťuje všechny potřebné operace. Chování procedury je ovlivněno vstupními parametry, jejichž hodnoty se liší pro jednotlivé akce:

80


@Rada – udává řadu faktur, se kterými bude procedura pracovat a které se bude snažit uhradit. Dávky CK předávají hodnotu 023, dávky klientům 068. Tento vstupní parametr spolu s evidencí závazků klientů na vydaných fakturách řady 068 umožňuje, že generování dávky je, až na znaménka operací, totožné pro odchozí dávky klientům i odchozí dávky do cestovních kanceláří. @Generovat – příznak určující, zda má procedura při svém běhu vytvořit tuzemský platební příkaz a jeho řádky. Kontrola dávky předává hodnotu 0 = false, generování pak 1 = true. @IDBankSpoj – nepovinný parametr, který při generování udává ID bankovního spojení, pro které je platební příkaz vytvořen. U kontroly dávky není hodnota vyplněna. Activity diagram celého procesu generování je naznačen na obrázku 4.6. Jsou zde dva vnořené cykly – jeden pro označené objednávky a druhý pro zaúčtované faktury řady dané parametrem @Rada aktuálně zpracovávané objednávky, které během svého průběhu sledují hodnotu fondu i dalších částek. Během výpočtu jsou v proceduře hsp_Davka_CZ/SK provedeny všechny potřebné kontroly a při nastaveném příznaku @Generovat ukládány řádky platebního příkazu. Výpočet není obalen v žádné transakci, protože při výskytu chyby může vzniknout pouze rozpracovaný platební příkaz. Uživatel může hlavičku příkazu jednoduše odstranit a generování spustit po opravě příčiny chyby znovu. Kromě chyby vstupního parametru @IDBankSpoj jsou všechny chyby a upozornění pro uživatele předávány pomocí tabulky #TabExtKom, jejíž chování je popsané v části 4.3.5.1. Některé operace varují uživatele v případě, že se pracuje s malými částkami. Jako malá se považuje částka menší než 10 Kč, nebo 1 Euro. Tato hodnota je uložena na začátku procedury do proměnné @MalaCastka. Při nastaveném příznaku @Generovat je jako první krok načten kód banky do hodnoty @KodUstavuNt podle hodnoty vstupního parametru @IDBankSpoj. Tím je ověřena správnost zadaného ID bankovního účtu NetTravel. Není-li zadáno platné ID, je vrácena chyba a procedura ukončena. Následně se uloží nový řádek do tabulky TabPlatTuz a vytvoří tak hlavička tuzemského platebního příkazu. Následně se otevře kurzor, který prochází všechna označená ID z tabulky hvw_PlatbyMain aktuálního uživatele. Za koncem cyklu tohoto kurzoru je kurzor uzavřen a při nastaveném příznaku @Generovat je zkontrolováno ID posledního řádku platebního příkazu. Neexistuje-li, znamená to, že na příkaz nebyl přidán žádný řádek a hlavička vytvořená v prvním kroku je odstraněna z databáze. Informace o této operaci je uložena do tabulky #TabExtKom. V případě, že byla dávka vygenerována v pořádku, nebo probíhala pouze kontrola, je do tabulky #TabExtKom vypsána informace o celkové částce celého platebního příkazu. Uvnitř vnějšího cyklu, který prochází všechny označené objednávky, probíhá cyklus přes všechny zaúčtované faktury s řadou odpovídající vstupnímu parametru procedury @Rada. Po otevření kurzoru a před vlastním cyklem je nejdříve zkontrolováno, zda má objednávka alespoň jednu fakturu. Pokud taková faktura neexistuje, je uživateli oznámeno, že objednávka nemá žádnou fakturu k úhradě. V opačném případě je z hvw_PlatbyMain načtena hodnota @Fond a @Zaplatit. Do proměnné @Zaplatit je u faktur řady 023 uložena hodnota ze sloupce ZaplatitCK a u faktur 068 ZaplatitKlientovi. Načtení hodnoty přímo z přehledu hvw_PlatbyMain zajišťuje jak případný přepočet do aktuální hlavní měny37 , tak odečtení peněz na cestě. K dispozici je tedy skutečná částka k odeslání. Tyto hodnoty by bylo možné načítat už ve vnějším kurzoru, načítání ale probíhá až zde, aby se minimalizovala výpočetní náročnost celé operace. 37 Pokud by některá částka v deníku byla ve staré měně před přechodem na Euro, tak je zde vrácena již přepočítaná do hlavní měny.


81

hsp_Davka_CZ/SK Hodnota @Zaplatit odpovídá ZaplatitCK u faktur od CK Ĝady 023 a ZaplatitKlientovi u faktur Ĝady 068 vystavených klientĤm.

[Generovat?]

VytvoĜení tuzemského platebního pĜíkazu

[Jinak] Oznamování událostí probíhá pĜes tabulku #TabExtKom.

OtevĜení kurzoru pro oznaþená ID objednávek

Naþtení dalšího ID objednávky ěada naþítaných faktur je dána vstupním parametrem @Rada

[V seznamu oznaþených není další záznam] [Má data] ZavĜení kurzoru oznaþených objednávek [Jinak]

Oznámení celkové þástky pĜíkazu

OtevĜení kurzoru pro všechny zaúþtované faktury akt. objednávky

[PĜi generování nebyl vytvoĜen žádný Ĝádek]

Naþtení dat faktury [Faktury neexistují]

Odstranxní platebního pĜíkazu, oznámení

[Jinak]

Oznámení, že obj. nemá faktury

ZavĜení kurzoru faktur

Naþtení hodnot @Fond a @Zaplatit objednávky

[Generovat?] [Jinak]

[@Fond<=0 nebo @Zaplatit<=0]

Zrušit oznaþení záznamĤ

Oznámení, že nelze platit

[Jinak] [@Zaplatit > @Fond] [Jinak]

Nastavit @Zaplatit=@Fond

[V seznamu faktur není další záznam] [Má data] Naþíst neuhrazenou þástku faktury @Castka [@Castka > @Fond]

Naþtení dat další faktury

Nastavit @Castka=@Fond

Provedení kontrol, oznámení chyb a varování [Jinak]

[Generovat?]

VytvoĜení Ĝádku a detailu platebního pĜíkazu, zápis úhrady

Od fondu odeþíst právx zpracovanou þástku

Obrázek 4.6: Generování platebního příkazu hsp_Davka_CZ/SK

82


Před vlastním spuštěním vnitřního cyklu jsou hodnoty @Fond a @Zaplatit zkontrolovány. Nulová nebo záporná hodnota některé z těchto proměnných znamená, že není co zaplatit, nebo není z čeho zaplatit. V obou případech je vrácena příslušná zpráva uživateli a kurzor je uzavřen. Poslední kontrolou je ověření, že je ve fondu dostatek financí pro úhradu celé částky @Zaplatit. Pokud je ve fondu méně, je částka @Zaplatit snížena na hodnotu @Fond, aby se odeslalo maximum dostupných prostředků, ale nedošlo k odeslání platby na úkor společnosti. Pro snížení výpočetní náročnosti jsou, stejně jako u vnějšího cyklu, informace o splatnosti a částce k úhradě faktury načítány až dodatečně. Částka faktury, snížená o již odeslané platby38 a peníze na cestě, je uložena do proměnně @Castka. Většina zájezdů je hrazena formou 50% zálohy a doplatku hrazeného měsíc před odletem. Tomu odpovídá i splatnost a požadované datum úhrady přijatých faktur od CK. Faktury jsou pro generování řazeny v pořadí splatnosti a byla-li do dávky zařazena jiná faktura než aktuální a současně má aktuální splatnost déle než za týden, je aktuální faktura z dávky vynechána. To zajistí, že v případě výskytu zatím neuhrazené zálohové faktury, bude uhrazena tato zálohová faktura a doplatková bude z dávky vynechána. Omezení testu na druhé a vyšší pořadí faktury umožní zařadit do generování faktury, které mají pozdější splatnost a neexistují u nich neuhrazené zálohové faktury. Další kontrolou je test na nulovou částku faktury k úhradě. U dříve uhrazených faktur je pouze vypsána zpráva pro uživatele a faktura je z generování vynechána. Vlastní chybová hláška se liší pro uhrazené faktury, u kterých existuje jiná k úhradě, a pro faktury, které jsou sice uhrazené, ale u objednávky je přesto existuje závazek ve výši @Zaplatit. Výpočet @Zaplatit je založen na informacích z účetního deníku a částka @Zaplatit vychází z úhrad faktury zapsaných v tabulce TabUhrady. Nekonzistence těchto dvou údajů může vzniknout ve dvou typických případech. Např. u řádku bankovního výpisu, jehož úhrada je přiřazena k faktuře jiné zakázky, než ke které je zaúčtován samotný řádek. Nebo při generování dávky v situaci, kdy existuje rozpracovaný bankovní výpis, který má pouze přiřazené úhrady, takže peníze již nejsou na cestě a faktura je podle úhrad uhrazena, ale není ještě zaúčtován, takže hodnota @Zaplatit obsahuje tuto částku k úhradě. Kontrola v tomto bodě zajišťuje, že nebudou peníze odeslány vícekrát. Pokud je částka k úhradě faktury @Castka vyšší, než aktuální hodnota @Fond, je částka snížena na hodnotu fondu. To zajistí, že nebude od objednávky odesláno více, než kolik bylo přijato. Pro úhradu se současně použije maximum dostupných prostředků. Uživateli je opět oznámeno, že z faktury bude uhrazena pouze část. Navíc je uživatel upozorněn na situaci, kdy na faktuře zůstane k úhradě méně, než je hodnota @MalaCastka. To může vzniknout např. u celkové ceny 5 015 Kč, zálohové faktuře 2 508 Kč, doplatkové 2 507 Kč a první platbě od klienta ve výši 2 507 Kč. Jako první bude, dle splatnosti, uhrazena zálohová faktura a neuhrazená část bude pouze 1 Kč, což by systém odeslal jako samostatnou platbu při doplatku faktury. Poplatek za odeslání takové platby ale převyšuje odesílanou částku. Podobně je uživatel varován i v případě, že je odesílaná částka menší, než hodnota @MalaCastka. Předposlední kontrolou je ověření, že je faktura nebyla již přeplacena. Tato kontrola slouží hlavně k vygenerování správné zprávy pro uživatele. U faktur, které mají v úhradách více, než částku k úhradě není co odeslat. Podobně u faktur klientům, není-li v úhradách více, není z čeho peníze vracet. Poslední kontrola, před vlastním zařazením částky @Castka aktuální faktury na platební příkaz, je ověření, že u faktury existuje organizace s alespoň jedním bankovním spojením. Kdyby organizace neměla v účetnictví zadané číslo bankovního účtu, nebylo by možné platbu odeslat. Cestovní kanceláře mají zpravidla i několik čísel účtů, ze kterých je možné vybírat (viz dále) a tato kontrola slouží převážně pro generování dávek klientům. Před odesláním dávky klientovi musí být v systému zadán účet klienta, a tedy změněna organizace na faktuře řady 38

Platby potvrzené bankovním výpisem.


83

068. Zadávání účtů a práce s organizací klienta je podrobněji popsána v části 4.4.6.4. Je-li po všech předchozích operacích částka k úhradě, uložená v proměnné @Castka, větší než nula, může být faktura zařazena do dávky. V případě kontroly dávky je pouze vynulován příznak označující první fakturu pro vyřazení případných dalších faktur s pozdější splatností z dávky. Při generování dávky a kladné částce je přidán řádek na platební příkaz. V kódu je jako prevence ještě implementována větev ELSE, která oznamuje chybu ve struktuře procedury. Tato větev by neměla nikdy nastat, ale pro případ vzniku chyby při úpravách kódu je přidána, aby byl problém co nejdříve odhalen. Po provedení všech operací, včetně přidání řádku na platební příkaz, jsou upraveny hodnoty @Fond a @Zaplatit tak, aby odpovídaly stavu po přidání příkazu a mohla být zpracována další faktura. Po zpracování všech faktur a uzavření vnitřního kurzoru je u faktur pro klienty řady 068 ještě zkontrolováno, že byla klientovi vygenerována dávka v plné výši. Případná zpráva uživatele upozorňuje, že ve fondu, nebo v úhradách nejsou správné hodnoty pro to, aby mohla být celá částka vratky odeslána najednou. Vlastní přidání řádku na platební příkaz znamená přidat propojené záznamy do tří tabulek: • TabPlatTuzR– vlastní řádek platebního příkazu, obsahující částku, variabilní symbol, účet příjemce, popis a další údaje. • TabPlatTuzRDetail– tabulka obsahující návaznost na ostatní moduly systému Helios a cizí klíče ostatních tabulek. Vyplňuje se zde ID aktuální faktury, číslo zakázky a ID zapsané úhrady. • TabUhrady– zápis úhrady k aktuální faktuře z modulu platebních příkazů. Tento řádek bude až do doby potvrzení platby bankovním výpisem reprezentovat peníze na cestě. U organizací reprezentujících cestovní kanceláře bývá zpravidla uvedeno více bankovních spojení pro různé banky. Nejrychlejší a nejlevnější převody jsou vždy v rámci stejné banky. Proto se při přidávání řádku do tabulky TabPlatTuzR vybírá přednostně číslo bankovního účtu, které má stejný kód banky jako hodnota @KodUstavuNt načtená na začátku procedury hsp_Davka_CZ/SK. 4.4.6.4

Další funkce přehledu Platby

Kromě generování platebních příkazů jsou v kontextovém menu přehledu Platby dostupné další funkce související s financemi. Většina je převzata z původní aplikace Platby.mdb, ostatní souvisí s přenosem evidence financí do účetního systému. Popsané funkce jsou umístěny ve skupinách menu CRM Platby a Účetnictví. Externí akce přístupné ve skupině Ovládání jsou popsány v části 4.4.6.2. 1. CRM Platby / Platba CK klientovi Externí akce spouští stored proceduru hsp_ZapisPlatbyCKKli. Ta převezme částku, poznámku a ID aktuálně označené objednávky a předá tyto hodnoty proceduře hsp_ZapisPlatbyKliCK, popsané v části 4.4.5.8. Vstupní hodnota @Castka je dále předána se záporným znaménkem, protože přímé platby mezi klientem se liší pouze ve znaménku a účtují se shodně 315400/325100, tedy pohledávka od klienta oproti závazku vůči CK. Vzájemně se zde interním dokladem započtou hodnoty ZaplatitKlientovi a ZaplatitCK. 2. Správa spropitného Pro správu spropitného existují čtyři externí akce, které volají dvě procedury – hsp_ZapisSpropitneKli_CZ/SK ve vztahu ke klientovi a hsp_ZapisSpropitneCK_CZ/SK ve

84

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ vztahu k CK. Obě procedury pracují shodně a liší se pouze v použité částce, číslu účtu a textu chybových zpráv pro uživatele. Zda se jedná o úhradu ze spropitného, nebo si spropitné nechává společnost NetTravel je rozlišeno prvním vstupním parametrem procedur. Na základě jeho hodnoty jsou vybrána čísla účtů a provedeny příslušné kontroly. U úhrady ze spropitného se účtují jako 548800/xxxxxx39 , není-li spropitné odesláno je účtováno jako xxxxxx/648800. Před vytvořením interního dokladu jsou provedeny tyto kontroly: • Při převodu částky do spropitného musí být @Castka větší než nula. Dluží-li klient nebo CK společnosti NetTravel, nelze tuto operaci provést. Pro úhradu ze spropitného jsou určeny jiné akce. • Při úhradě ze spropitného musí být @Castka záporná. Obdobně jako u první kontroly, nedluží-li klient nebo CK, nelze provést úhradu tohoto dluhu ze spropitného. • Zapisovaná nebo hrazená částka nesmí překročit 5 000 Kč nebo 150 Euro na Slovensku. Pro spuštění procedur spravujících spropitné jsou k dispozici tyto externí akce: • CRM Platby / Spropitné od klienta, • CRM Platby / Uhradit ze spropitného klientovi, • CRM Platby / Spropitné od CK, • CRM Platby / Uhradit ze spropitného CK. 3. CRM Platby / Opravit faktury klientům (fialové) Objednávky, u kterých neodpovídá celková cena k úhradě zapsané faktuře 068 jsou v přehledu Platby pro kontrolu označeny fialovou barvou. Pro zajištění opravy tohoto stavu je k dispozici externí akce, která volá proceduru hsp_ZapisFaKli. Ta zajistí správnou úpravu vydané faktury klientovi řady 068 a jejího zaúčtování. Samotná procedura pracuje pouze jako rozcestník na hsp_ZapisFaKli_CZ/SK, která je podrobně popsána v části 4.4.5.6. Chybná hodnota faktury 068 může v systému vzniknout více způsoby. V CRM je k dispozici akce „Změna stavu“, která uživatelům s dostatkem oprávnění umožňuje ručně změnit stav objednávky a porušit tak předepsané pořadí akcí. Zpravidla se změna využívá v nestandardních případech, pro které CRM neposkytuje podporu. Další příčinou může být výskyt chyby v předchozím volání procedury, která tak nedokončí požadované změny při změněné ceně zájezdu. 4. CRM Platby / Změna provize hned Při spuštění akce je uživatel vyzván, aby zaškrtnutím potvrdil, že chce skutečně změnit hodnotu ProvizeHned označeného řádku. Výsledek tohoto zaškrtnutí je spolu s ID objednávky předáno stored proceduře hsp_ZmenaPH. Ta v případě správného zaškrtnutí dohledá aktuálního zaměstnance z tabulky Zamestnanci, změní hodnotu sloupce ProvizeHned v tabulce Objednavky příslušné objednávky a uloží informaci o provedené změně do historie objednávky. 5. CRM Platby / Zadat účet klienta Zadání účtu klienta musí předcházet každému vrácení peněz klientovi převodem. Proto je zadávání účtů přístupné přes CRM i přehled Platby v Heliosu. Procedura má na vstupu

39

Hodnota xxxxxx odpovídá účtu 315400 ve vztahu ke klientovi a 325100 ve vztahu k CK.


85

číslo bankovního účtu, zadávané včetně předčíslí a kódu banky, a ID aktuálního záznamu v přehledu. V prvním kroku je číslo účtu rozděleno na vlastní číslo účtu a kód banky. U krátkých čísel nebo neexistujícího kódu banky je uživateli vrácena příslušná chyba a běh procedury končí. Současně musí pro správné zadání účtu již existovat faktura klientovi řady 068. K této faktuře se zapisuje organizace, ke které je číslo účtu připsáno. Každá faktura řady 068 je založena s organizací „Klient zájezdu“ s číslem organizace 1000. Ve většině případů nevzniká u objednávek přeplatek od klienta a není tedy od začátku potřeba vytvářet každému klientovi vlastní organizaci. V případě zápisu nového čísla bankovního účtu je vytvořena nová organizace odpovídající klientovi konkrétního zájezdu a je k ní přidáno bankovní spojení. Nové organizace odpovídají objednávkám, nikoli klientům. U jednoho fyzického klienta s více objednávkami tedy může existovat více organizací. U různých objednávek může klient požadovat vrácení částky na jiné účty, případně může během času změnit číslo účtu a hodnota zadaná v minulosti již nemusí být platná. Procedura hsp_ZadatUcetKlienta_CZ/SK umožňuje ošetřit jak zadání nového čísla účtu, tak opravu stávajícího. V případě, že je na faktuře jiná organizace než výchozí s číslem 1000, je použita tato a je upraveno pouze její bankovní spojení. Můžou zde nastat tři situace: • Organizace nemá žádné bankovní spojení. Tato situace mohla vzniknout při ručním odstranění původního čísla účtu, nebo výskytem chyby při prvním zápisu. Nové číslo bankovního účtu je přidáno do tabulky TabBankSpojeni ke stávající organizaci. • Organizace má jedno bankovní spojení V tomto případě se číslo účtu na stávajícím spojení přepíše na novou hodnotu a vyplní se čas a autor změny záznamu v tabulce TabBankSpojeni. • Organizace má více bankovních spojení. Tento stav může vzniknout pouze na základě chybného ručního zásahu. Uživateli je vrácena chyba vyzývající k ruční opravě tohoto stavu. U organizace by měl být zadán pouze jeden účet, aby bylo jednoznačně určeno kam budou peníze odeslány. V případě existence více účtů budou peníze odeslány prioritně v rámci stejné banky, z jaké platba odchází. Pořadí zápisu není zohledněno. Pokud je na faktuře uvedena výchozí organizace s číslem 1000, je procedurou hsp_ZapisOrg_CZ/SK vytvořena nová organizace s názvem „Klient zájezdu ID xxx“, kde xxx odpovídá ID objednávky. Tato nová organizace je uložena na fakturu 068 v tabulce TabDokladyZbozi i do jejího zaúčtování v účetním deníku TabDenik. 6. Účetnictví / Otevření deníku pro akt. zakázku Externí akce nespouští stored proceduru, ale funkci OtevritDenikZakazky externího pluginu NtHellPlugin.dll. Tato funkce spouští jedinou funkci z interface IHelios, a to OpenBrowse. Té předá číslo systémového přehledu chronologického deníku pro zakázku a filtr obsahující omezení pouze na aktuálně označenou zakázku. Funkce OpenBrowse otevře libovolný přehled v novém okně a zpřístupní všechny jeho funkce. Se zobrazenými záznamy tak lze přímo z otevřeného přehledu provádět operace úprav, změny stavu a další. Bez využití pluginu by bylo sice možné otevřít definovaný přehled se stejnými informacemi, v tomto přehledu by ale byly k dispozici pouze připravené externí akce.

86

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 7. Správa poplatku za SMS – RezaPortal Poplatek za SMS potvrzující rezervaci je speciální prodejní situace, která se vyskytuje u zájezdů prodaných přes RezaPortal. Princip prodeje těchto zájezdů a příslušné účtování je popsáno v části 11. Z pohledu uživatele jsou pro ošetření této situace v přehledu Platby přístupné dvě externí akce: • Účetnictví / Zápis poplatku za SMS – RezaPortal, • Účetnictví / Storno poplatku za SMS – RezaPortal. Obě tyto akce volají společnou proceduru hsp_FixReza_CZ40 a informaci o zápisu nebo stornu předávají jako první parametr. Procedura obsahuje ve svém těle pouze dvě volání procedury hsp_FixRezaFa_CZ, která provádí vlastní změnu v účtování. První volání probíhá pro přijaté faktury řady 023 a účtování 325100/325110, druhé pro vydané faktury řady 068 a rozúčtování 315410/315400. Struktura procedury je naznačena na diagramu 4.7. Procedura načte počáteční údaje, pokusí se dohledat fakturu odpovídající vstupnímu parametru @Rada a informace o jejím zaúčtování. Před spuštěním úprav v databázi jsou provedeny tři kontroly: • Musí existovat faktura požadované řady. • Při stornu poplatku musí poplatek v databázi existovat. • Při zápisu poplatku nesmí poplatek v databázi existovat. Jako první krok úprav je otevřena transakce. Úpravy provádí změny v účetním deníku a každá změna má vliv alespoň na dva řádky. Všechny úpravy jsou tak obaleny do transakce, aby při případném výskytu chyby nedošlo k vytvoření nekonzistentních dat a nevyrovnaných účetních dokladů. Podle příznaku, zda se má poplatek aktivovat nebo stornovat, nastaveného příslušnou externí akcí, je zvolena jedna ze dvou větví programu: (a) Zápis poplatku za SMS. V případě, že je faktura zaúčtovaná do uzavřeného období nelze provádět žádné změny na stávajícím účetním dokladu v deníku. Proto je rozúčtování provedeno interním dokladem s pomocí procedury hsp_ZauctovatDenik_CZ/SK. Faktura tak bude zaúčtovaná na více účetních dokladech. U faktur v otevřeném období je snížena částka na řádku 315400, případně 325100 u faktur 023 od CK, a přidán nový řádek 315410, popř. 325110, ke stávajícímu dokladu. Účtování faktury řady 068 před a po provedení této úpravy je naznačena v tabulce 4.8. Částka poplatku je z účtu 315400 převedena na účet 315410, aby nebyla zahrnuta do výpočtu hodnoty ZaplatitKlientovi. (b) Storno poplatku za SMS. Pokud je poplatek uložen v uzavřeném období, je zrušen novým interním dokladem v aktuálním období, podobně jako při zápisu. U poplatků zapsaných v otevřeném období je provedena úprava účtování stávajícího dokladu. Před zápisem změn je nejdříve dohledán protiřádek s účtem 315400, případně 325100, od kterého byla při zápisu částka odečtena. Není-li takový řádek nalezen, je uživateli oznámena chyba a transakce ukončena. Tato situace může vzniknout pouze ručním zásahem do účtování a obsluha aplikace by měla účetní doklady opravit ručně. Storno poplatku probíhá jako odstranění řádku s účtem 315410, popř. 325110. Před odstraněním řádku z deníku se musí ještě změnit fáze řádku z „Účtováno“ na

40

Poplatek za SMS se vyskytuje pouze v české verzi.


87

hsp_FixRezaFa_CZ

Naþtení úvodních informací [Nenalezena faktura požadované Ĝady] [Poplatek nenalezen pĜi pokusu o storno]

[Jinak]

[Poplatek již existuje pĜi pokusu o zápis]

[Jinak] [Jinak]

Oznámit pĜíslušnou chybovou zprávu

[Zápis] [Faktura je zaúþtovaná v uzavĜeném období]

Zápis poplatku samostatným interním dokladem hsp_ZauctovatDenik_CZ

Pro úþet 315410 je protiĜádek 315400. Pro úþet 325110 je protiĜádek 325100.

OtevĜení transakce

[Storno]

[Existuje zaúþtování v otevĜeném období]

[Jinak]

Snížení stávající þástky protiĜádku v deníku 315400 nebo 325100

[ProtiĜádek není na stejném dokladu]

PĜidání nového Ĝádku na stávající doklad 315410 nebo 325110

[Poplatek je zaúþtovan v uzavĜeném období]

Storno poplatku samostatným interním dokladem hsp_ZauctovatDenik_CZ [Jinak] Odstranxní Ĝádku poplatku z úþetního deníku 315410 nebo 325110

Oznámení chyby [ProtiĜádek má þástku poplatku] Odstranxní protiĜádku z úþetního deníku 315400 nebo 325100

[Jinak]

Úprava protiĜádku, pĜiþtení þástky poplatku 315400 nebo 325100

Potvrzení transakce

Obrázek 4.7: Zápis a storno poplatku za SMS hsp_FixRezaFa_CZ

88

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Stav před zaúčtování poplatku Účet Má dáti Dal Částka 315400 10 000 325400 10 000 Stav po zaúčtování poplatku Účet Má dáti Dal Částka 315400 9 921 325400 10 000 315410 79

za SMS Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK.

Popis Snížený řádek faktury 068. Nezměněná faktura 068, předpis faktur od CK. Převod poplatku za SMS na příslušný účet.

Tabulka 4.8: Ukázka účtování poplatku za SMS k faktuře řady 068 „Pořízeno“, protože systém Helios umožňuje ve fázi „Účtováno“ odstraňovat pouze celé doklady. Jednotlivé řádky lze odstranit pouze ve fázi „Pořízeno“. U poplatků zapsaných samostatným dokladem bude částka na protiřádku ve výši poplatku, a po odstranění prvního bude jediným řádkem celého dokladu. Proto se protiřádky se stejnou částkou jako je výše vlastního poplatku odstraní. U řádků, které byly při zápisu pouze upraveny dojde k přičtení částky poplatku, aby byl doklad vyrovnán a vrácen do původní podoby. 8. Účetnictví / Předběžné potvrzení platby výpisem Každá příchozí platba připsaná na účet společnosti je účetně zpracována vždy nejdříve až následujícího dne. Bankovní výpisy se stahují vždy za předcházející den a ve většině případů to k bezproblémovému chodu stačí. U některých last minute nabídek je ale potřeba, aby byla platba do CK odeslána ve stejný den. Z tohoto důvodu je k dispozici tato externí akce, která spouští proceduru hsp_ZapisBankVypis_CZ/SK. Uživatel je dotázán pouze na @IDBankSpoj účtu společnosti, na který bude fiktivní bankovní výpis vytvořen a částku platby. Vlastní vytvoření a zaúčtování bankovního výpisu probíhá v následujících krocích: (a) Procedura načte počáteční informace, jakými jsou ID aktuálního období, období stavu, informace o měně a dnešní datum. (b) Pokud pro vybrané bankovní spojení @IDBankSpoj a dnešní datum již výpis existuje, bude řádek přidán na stávající. V opačném případě je přidán nový řádek do tabulky TabBankVypisH, představující hlavičku nového fiktivního výpisu. Spolu s tímto řádkem je do tabulky TabBankVypisH_EXT uložen příznak do sloupce _Fiktivni označující fiktivní výpis. (c) Dále je určeno nové číslo řádku a přidán řádek bankovního výpisu do tabulky TabBankVypisR. U řádku se vyplňuje pouze částka, číslo účetního účtu pro zaúčtování, číslo zakázky a kód účtování udávající, zda se jedná o kreditní nebo debetní položku. (d) Posledním krokem je zaúčtování celého bankovního výpisu. Výpis se účtuje pouze do fáze „Pořízeno“, aby byl odlišen od běžných výpisů a řádek objednávky v přehledu Platby byl zvýrazněn modře41 . Stejně jako v případě účtování faktury nebo pokladního dokladu má proces účtování několik kroků: 41 Modrým písmem jsou označeny objednávky, u kterých existuje doklad ve fázi „Pořízeno“, které znamenají výskyt nepotvrzené platby, viz 4.4.6.1.


89

i. Vytvoření dočasné tabulky #TabDenikUcto pro přípravu účetního dokladu. ii. Pomocí kurzoru jsou zpracovány všechny připravené, nezaúčtované řádky výpisu do dočasné tabulky. Toto účtování realizuje procedura Heliosu hp_BVUcto_UctujRadek. iii. Účtování je dokončeno spuštěním procedury Heliosu hp_BVUcto_UctujSumace, která do dočasné tabulky #TabDenikUcto doplní zbývající řádek pro hlavičku dokladu. iv. Další procedurou Heliosu hp_PrenesDenikUctoDoDeniku je obsah dočasné tabulky přenesen do účetního deníku TabDenik. v. Posledním krokem je odstranění tabulky #TabDenikUcto, vytvořené v prvním kroku. 4.4.6.5

Kontrola faktur od CK

V původním systému vycházela částka ZaplatitCK z celkové ceny zájezdu a správná evidence faktur od CK nebyla pro běh systému kritická. V novém systému se faktury 023 od CK účtují a vytváří předpis částky k úhradě do CK. Proto se jejich správná evidence stává zásadní pro bezchybné fungování finanční části CRM. Objednávky, u kterých součet faktur od CK převyšuje celkovou cenu zájezdu, nebo výši storno poplatku u stornovaných objednávek, jsou v přehledu Platby označeny červeně. Při splnění několika doplňujících podmínek by každá taková objednávka měla být zobrazena v přehledu hvw_KontrolaFaktur, zobrazeného jako soudeček Kontrola faktur. Podmínky pro zobrazení objednávky mezi chybnými jsou následující: • Od prodeje objednávky, tedy odeslání smlouvy do CK, uběhlo alespoň 48 hodin. • Objednávka spadá do státu příslušného Heliosu42 . • Termín odjezdu je po 1.1.2008 a novější. Objednávky s termínem v roce 2007 a starším nejsou do přehledu zahrnuty. • Součet zaúčtovaných faktur řady 023 se liší od předpisu celkové očekávané částky faktur. • Existuje alespoň jedna zaúčtovaná faktura řady 023. Objednávky, u kterých není zatím zapsaná žádná faktura, a předpis se tedy liší od zaúčtované částky, nebudou zobrazeny. Přehled obsahuje ještě speciální ošetření pro CK s ID = 24 a objednávek s provizí hned, kde je pro odečet provize použita částka bez DPH. U všech ostatních cestovních kanceláří se pro odečet provize používá částka s DPH. V přehledu jsou zobrazeny informace z CRM, jakými je ID objednávky, jméno klienta, datum prodeje, stav objednávky, název CK, termín zájezdu, výše zapsané provize, cena celkem a předpis očekávané částky faktur založený na ceně zájezdu nebo storno poplatku. Dále je zobrazen odečet provize u objednávek s provizí hned a očekávaná výše chybějící faktury nebo dobropisu. V přehledu jsou k dispozici dvě externí akce, podobně jako v přehledu Platby: • Ovládání / Otevřít v CRM Externí akce spouští proceduru hsp_OpenObj a, stejně jako akce nastavená v přehledu Platby, má jako návaznou akci spuštění aplikace CRM s parametrem „/z“. 42

Objednávky slovenských CK nebudou zobrazeny v kontrole faktur českého Heliosu

90

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ • Ovládání / Otevření deníku pro akt. zakázku Narozdíl od akce použité v přehledu Platby, kde je otevření zakázky realizováno pluginem, je zde zobrazen přehled hvw_PrehledDeniku s podmínkou nastavenou na hodnotu „CisloZakazky=:ID“. Na základě té systém Helios zajistí, že budou zobrazeny pouze řádky s číslem zakázky stejným, jako je hodnota ID označeného záznamu. Tento způsob otevření zobrazuje informace pouze pro čtení a neumožňuje provádět se zobrazenými záznamy žádné operace.

4.4.7

Systém fakturace provize

Fakturace provize je poslední krok prodejního procesu. Zájezd je již uhrazen v cestovní kanceláři a společnosti NetTravel vzniká nárok na provizi z prodeje zájezdů, s ohledem na hodnotu sloupce ProvizeHned. V původním systému realizovala fakturaci aplikace CRM_Finance.mdb, která je nahrazena funkcemi popsanými v této části dokumentu. Fakturace v aplikaci CRM_Finance.mdb a význam sloupce ProvizeHned je popsán v části 3.2.4. 4.4.7.1

Režimy spouštění

Kromě základní fakturace, která vychází z výběru vstupních parametrů určujících fakturační období a seznam CK k fakturaci, jsou v novém systému přidány funkce pro ruční fakturaci konkrétních objednávek na základě výběru uživatele a ruční dofakturaci objednávek z přehledu nevyfakturovaných, viz 4.4.7.4. Všechny tři režimy jsou spouštěny z externích akcí vytvořených v konkrétních přehledech Heliosu a všechny spouští proceduru hsp_FakturaceProvize_CZ/SK, popsanou v části 4.4.7.2. Ta obsahuje jako svůj první vstupní parametr hodnotu @TabName určující tabulku uživatelského označení, ze které bude fakturace vycházet. Externí akce spouštějící fakturaci mají hodnotu tohoto parametru přednastavenou ve své definici. Jednotlivé režimy spouštění jsou tedy následující: 1. Základní fakturace provize. Tento režim je výchozím způsobem, jakým je provize fakturována a vychází z původní aplikace CRM_Finance.mdb. Procedura hsp_FakturaceProvize_CZ/SK není spouštěna přímo, ale předchází jí výběr vstupních parametrů. Těmi je fakturační období a výběr ze seznamu cestovních kanceláří, které mají ve zvoleném fakturačním období fakturovatelné objednávky. Pro zajištění výběru těchto parametrů je do systému Helios přidána tato sada návazných externích akcí, z nichž pouze první je označená jako veřejná: (a) Fakturace provize CK Tato akce je typu procedura a spouští hsp_ClearFakturace_CZ/SK. Ta pouze uloží hodnotu NULL do sloupce Zamestnanci.id_FakturacnihoObdobi aktuálního uživatele a zruší uživatelské označení pro přehled hvw_ObjFakturace pomocí procedury hsp_ZrusOzn_CZ/SK. (b) Generování období pro fakturaci Toto je také externí akce typu procedura spouštějící hsp_GenObdobiFakturace. Ta ověří, že v tabulce FakturacniObdobi existují všechna potřebná fakturační období a případné chybějící záznamy doplní. Nelze fakturovat provizi za budoucí měsíc, protože ještě nenastal a nemohl vzniknout nárok na provizi. Současně je ale fakturace spouštěna každý měsíc a je nutné zajistit, že tento měsíc bude zařazen mezi fakturovatelné. Každý měsíc je z důvodu rozdělení DUZP rozdělen na první a druhou


91

polovinu, jak je popsáno v části 3.2.4. Posledním krokem procedury je nastavení příznaku Visible = 0 u období starších než půl roku, aby seznam období k fakturaci nebyl příliš dlouhý. (c) Uložení fakturačního období Externí akce spouští jednoduchou proceduru hsp_OpenFO, která pouze hodnotu vstupního parametru @ID uloží do sloupce Zamestnanci.id_FakturacnihoObdobi aktuálního uživatele. Externí akce má jeden vstupní parametr typu „Definovaný přehled“ a vybírá hodnotu sloupce ID z přehledu hvw_FakturacniObdobi. Ten pouze zobrazuje záznamy z tabulky FakturacniObdobi, které mají nastaven příznak Visible. (d) Výběr CK k fakturaci Tato akce je typu „Přehled“ a zobrazuje data z přehledu hvw_ObjFakturace, ve kterém jsou zobrazeny názvy cestovních kanceláří, které mají na základě vybraného fakturačního období objednávky k fakturaci. Kromě názvu CK je k dispozici také sloupec _HeIQ_UzivOzn umožňující uživatelské označení záznamů. Uživatel zde vybere všechny CK, kterým chce vystavit fakturu a seznam jejich ID bude uložen v tabulce TabUzivOzn. Zavřením přehledu hvw_ObjFakturace, bez ohledu na počet označených záznamů, je spuštěna poslední akce, která vystaví faktury. (e) Vystavení faktur na provize Poslední akce v posloupnosti je spuštění procedury hsp_FakturaceProvize_CZ/SK s parametrem @TabName nastaveným na hodnotu „hvw_ObjFakturace“. Výsledkem předchozích akcí je hodnota id_FakturacnihoObdobi, a tedy rozsah období uložený v tabulce FakturacniObdobi, a seznam ID cestovních kanceláří k fakturaci. Na základě těchto údajů procedura vybere seznam objednávek, které budou fakturovány. 2. Fakturace na základě seznamu nevyfakturovaných zakázek. Druhým režimem fakturace je možnost vystavit faktury na objednávky, které jsou zobrazeny v přehledu nevyfakturovaných objednávek (viz 4.4.7.4). Pomocí uživatelského označení je určen seznam objednávek k fakturaci a externí akcí Fakturace provize CK vybraných zakázek je spuštěna procedura hsp_FakturaceProvize_CZ/SK s parametrem @TabName nastaveným na hodnotu „hvw_Nevyfakturovane“. Seznam objednávek k fakturaci je vytvořen na základě označených záznamů aktuálního uživatele. 3. Ruční fakturace konkrétních zakázek. Tato akce je nastavena stejně jako předchozí, ale je umístěna v přehledu zakázek. Uživatelským označením lze vybrat libovolný seznam zakázek a pro ty je pak spuštěna procedura hsp_FakturaceProvize_CZ/SK s parametrem @TabName nastaveným na hodnotu „TabZakazka“. Vlastní fakturace má pak totožný průběh, jako v předchozím případě. 4.4.7.2

Vystavování faktur – hsp_FakturaceProvize_CZ/SK

Vystavení faktur a zápis jejich položek zajišťuje procedura hsp_FakturaceProvize_CZ/SK, která má jediný vstupní parametr @TabName určující zdroj objednávek k fakturaci. Režimy spouštění procedury jsou popsány v části 4.4.7.1 a přípustné hodnoty vstupního parametru jsou: 1. „hvw_ObjFakturace“ Běžná fakturace, při které se hlavní kurzor otevírá pro seznam objednávek na základě hodnoty id_FakturacnihoObdobi z tabulky Zamestnanci aktuálního uživatele, seznamu CK

92

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ uživatelského označení z přehledu hvw_ObjFakturace a všech objednávek, které spadají do vybraného fakturačního období a pořádá je některá z vybraných cestovních kanceláří. Datum faktury a zápisu jejich položek je určeno posledním dnem vybraného fakturačního období. Po přechodu na měnu Euro není možné vystavit faktury spadající do doby před tímto přechodem. 2. „hvw_Nevyfakturovane“ Seznam objednávek k fakturaci vychází z uživatelsky označených zakázek z přehledu hvw_Nevyfakturovane. Datum vystavení faktury je dnešní a není zde tedy žádné omezení související s měnou Euro. 3. „TabZakazka“ Tato hodnota se chová totožně jako předchozí. Výběr objednávek vychází z uživatelského označení v seznamu všech zakázek.

Celý proces vystavení faktur na provize je zobrazen na diagramu 4.8. Po vytvoření kurzoru na základě vstupního parametru jsou připraveny informace, jakými je vygenerování řady faktury, data splatnosti a ID bankovního spojení provozního účtu. Následně je kurzor otevřen a začíná smyčka generující faktury, ve které probíhají tyto kroky: 1. Je zkontrolováno, zda se ID objednávky vyskytuje mezi zakázkami. Pokud objednávka zatím nebyla přenesena do Heliosu, je uživateli oznámena chyba a kurzor pokračuje načtením dalšího záznamu. 2. Pokud se ID CK předchozí objednávky liší od současné, je založena nová faktura. Před vlastním založením se ale nejdříve musí dokončit faktura předchozí, byla-li vytvořena. Dokončení spočítá ve spuštění triggeru Heliosu, který zajistí přepočet kumulativních údajů na faktuře, vytvořením úhrady v případě fakturace s provizí hned a zaúčtování vytvořené faktury. Nejsou-li na faktuře žádné položky, nemůže dojít k jejímu zaúčtování a uživatel je o tomto stavu informován. Pro vytvoření nové faktury se nejprve dohledá číslo organizace odpovídající cestovní kanceláři a následně je spuštěna procedura hsp_ZapisFa_CZ/SK. 3. Dále probíhá příprava položky a načtení informací pro její vytvoření. V případě, že provize není u objednávky vyplněna, je na tento stav uživatel upozorněn a položka je na fakturu zařazena s nulovou částkou. Oprava částky je méně práce, než vytvoření celé položky ručně. Kromě této operace je načten text položky, který obsahuje ID objednávky, jméno klienta, cílovou zemi a číslo faktury řady 023 od CK. Tabulka Objednavky umožňuje zapsat provizi se dvěmi různými sazbami DPH. Jedna objednávka tak může na faktuře vygenerovat dva řádky, každý s jinou sazbou. Pokud je v CRM zadána provize v obou polích se stejnou sazbou, je sloučena pouze do jedné hodnoty, aby nebyla objednávka na faktuře zbytečně dvakrát. 4. Před přidáním položky na fakturu je dohledáno, zda se již objednávka nevyskytuje na jiných fakturách na provizi. Pokud již byla objednávka fakturována, je procedurou hsp_FVPCastka_CZ/SK, popsanou v části 4.4.3, snížena o již vyfakturovanou část. 5. Posledním krokem cyklu je přidání položek na fakturu pomocí další obecné procedury hsp_FVPIns_CZ/SK.


93

hsp_FakturaceProvize_CZ/SK

Naþtení úvodních informací [BČžná fakturace, @TabName=”hvw_ObjFakturace”]

[Jinak] [Fakturace konkrétních zakázek]

Kurzor podle uživatelského oznaþení

Kurzor podle fakturaþního období a seznamu CK

Oznámení chyby

OtevĜení kurzoru

Naþtení dalšího Ĝádku [Není další objednávka]

Oznámení chyby [Objednávka není mezi zakázkami]

[Má data]

Závxreþné úpravy pĜedchozí faktury

[Jinak] Závxreþné úpravy pĜedchozí faktury

[Jiná CK než pĜedchozí] [Jinak]

Závxreþné úpravy pĜedchozí faktury

Dohledání þísla organizace podle CK

Zápis nové faktury hsp_ZapisFa_CZ/SK

[Faktura byla vytvoĜena]

[Objednávka nemá zadanou provizi]

[Jinak] [Jinak]

Upozornxní uživatele

PĜepoþet kumulativních údajĤ faktury [Bylo fakturováno s provizí hned]

Naþtení informací pro Ĝádek faktury

Zápis úhrady

Dohledání zakázky na jiných fakturách [Objednávka je na jiných fakturách] Snížení þástky hsp_FVPCastka_CZ/SK

[Nulová þástka faktury] [Jinak]

[Jinak]

Zaúþtování faktury hsp_ZauctovatFa_CZ/SK

PĜidání ĜádkĤ na fakturu hsp_FVPIns_CZ/SK

Obrázek 4.8: Fakturace provize hsp_FakturaceProvize_CZ/SK

Oznámení nulové þástky

94


Na závěr je opět provedeno dokončení poslední vystavené faktury a zrušeno uživatelské označení na základě vstupního parametru @TabName. Proces vytváření faktur není obalen v žádné transakci, protože případný výskyt chyby lze jednoduše opravit odstraněním rozpracované faktury. Během výpočtu nedochází k dělení dat ani jiné situaci, která by mohla způsobit nekonzistentní stav databáze. 4.4.7.3

Dohledání zakázek na fakturách

V systému Helios obecně nelze hledat na základě informací uložených na položkách faktur. Proto jsou na několika místech dostupné akce Dohledání zakázky na fakturách, které otevírají přehled hvw_VyfakturovaneVsechny. Tato místa jsou: • Přehled hvw_Nevyfakturovane. Akce otevírá přehled hvw_VyfakturovaneVsechny s podmínkou „CisloZakazky=:ID“, která zajistí, že bude filtrováno podle čísla zakázky na základě aktuálně označeného řádku a jeho hodnoty ID. Toto dosazení zajistí systém Helios automaticky podle dvojtečky před názvem sloupce. • Přehled zakázek. Zde se akce chová stejně jako v prvním případě, opět je jako podmínka přehledu nastaveno „CisloZakazky=:CisloZakazky“ zajišťující, že bude dohledána aktuálně označená zakázka. • Přehled vydaných faktur. Z přehledu vydaných faktur se otevírá stejný přehled jako v předchozích dvou případech, zde je ale na hledané číslo zakázky dotázán uživatel na základě definovaného vstupního parametru typu „Helios číselník“. V otevřeném přehledu hvw_VyfakturovaneVsechny jsou zobrazeny řádky faktur, na kterých se vyskytuje hledaná zakázka. Pro otevření zdrojové faktury je k dispozici externí akce Otevření faktury realizovaná pluginem NtHellPlugin. Ta otevře přehled vydaných faktur s podmínkou zobrazující pouze požadovanou fakturu. Tento způsob otevření umožňuje zpřístupnit všechny dostupné systémové akce, které lze provádět z běžného přehledu vydaných faktur. 4.4.7.4

Nevyfakturované objednávky

Jako jeden z přidaných soudečků je uživatelům k dispozici Nevyfakturované obj., který zobrazuje nevyfakturované objednávky. Je zde zobrazen přehled hvw_Nevyfakturovane, který slouží jako opravný nástroj pro případy, kdy vyfakturovaná částka neodpovídá předepsané provizi, včetně situací, kdy nebyla vystavena žádná faktura. Kromě zobrazení informací o předepsané výši provize, datu fakturace a již vyfakturované částce je zde k dispozici externí akce pro dohledání zakázky na fakturách a akce pro vystavení faktur označených zakázek. Přehled zobrazuje všechny zakázky, které • mají zapsanou provizi v jiné výši, než na jakou jsou vystaveny faktury, zaokrouhleno na celé koruny nebo Eura, • neměly být dosud fakturovány nebo měly být fakturovány v minulém měsíci a dříve, • datum fakturace nebo termín jsou alespoň v roce 2007.

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 4.4.8

95

Fakturace poukazů

V novém systému je pro úhradu každého poukazu vystavena faktura řady 0*6 a klient hradí poukaz jako úhradu této faktury pod jejím variabilním symbolem. Tento způsob zjednodušuje evidenci financí i párování plateb a platby za poukazy jsou převedeny na běžné úhrady vydaných faktur. Faktury jsou obecně vytvářeny jako nezaúčtované, aby se jejich částka nepočítala na účet 325300 evidující dostupnou částku uhrazených poukazů. Na základě faktury je pouze vygenerováno číslo faktury, a tedy variabilní symbol pro úhradu. Založenou fakturu je možné vytisknout a v případě požadavku ji odeslat odběrateli, podobně jako v původním systému faktury řady 0*1 vystavené na poukazy. Při úhradě faktury je spuštěn externí trigger et_TabDokladyZbozi popsaný v části 4.4.9.1, který zajistí zaúčtování faktury a aktivaci příslušných poukazů. 4.4.8.1

Režimy spouštění

Vytvoření jedné faktury a přidání položek zajišťuje procedura hsp_FakturacePoukazu_CZ/SK, popsaná v části 4.4.8.2. Ta může být spuštěna ze tří různých částí systému, které ošetřují automatickou fakturaci v případě objednání poukazů online na webu společnosti i ruční vystavení. 1. Ruční vystavení z přehledu Poukazy. Do aplikace Helios je kromě prodejních přehledů přidán i soudeček Poukazy zobrazující definovaný přehled hvw_FakturacePoukazu. V tomto přehledu jsou zobrazeny všechny vystavené poukazy typu „n“, tj. normální dárkové poukazy. Pomocí uživatelského označení lze označit více poukazů, které budou externí akcí Vystavení faktury na vybrané poukazy umístěny na společnou fakturu. Externí akce přímo spouští proceduru hsp_FakturacePoukazu_CZ/SK a ve své definici obsahuje tyto parametry: • Hodnota @TabName je nastavena na „hvw_FakturacePoukazu“. • Číslo organizace @CisloOrg, které je faktura vystavena, je parametr typu „Helios číselník“ a umožňuje uživateli otevřít číselník organizací a číslo organizace zvolit z tohoto přehledu. Pokud organizace neexistuje, má uživatel možnost organizaci přidat. • Číslo vlastního bankovního spojení @IDBankSpoj je také parametr typu „Helios číselník“ a nabízí uživateli zobrazení přehledu s bankovními spojeními vlastní organizace. 2. Automatická fakturace poukazů objednaných online. Dárkové poukazy lze objednat online na webu společnosti a objednávkový formulář obsahuje možnost vystavení faktury konkrétní společnosti. Současně existuje možnost nechat si za poplatek originál poukazu doručit poštou. Ve všech případech je klientovi odeslán email s potvrzením objednávky poukazů a informací, že platební podmínky budou zaslány v dalším emailu. Webová aplikace uloží záznam do tabulky Poukazy_Faktury reprezentující vystavenou fakturu a vygeneruje všechny poukazy do tabulky Poukazy. Nová struktura tabulek pro evidenci poukazů a jejich faktur je na obrázku 4.9. Záznamy z těchto tabulek jsou synchronizovány do databáze CRM a aplikace CRMSync v pravidelných intervalech spouští proceduru hsp_FakturacePoukazuAuto, která pracuje jako vstupní bod pro procedury hsp_FakturacePoukazuAuto_CZ/SK. Web vyplní za každou objednávku poukazů řádek v tabulce Poukazy_Faktury, který reprezentuje požadavek na vystavení faktury. Při objednávce jsou vyplněny všechny sloupce kromě id_Helios a VS.

96


«table» Poukazy -ID : Integer -Vytvoren : Date -Aktivovan : Date -Uplatnen : Date -PlatiDo : Date -Vytvoril : Integer -Aktivoval : Integer -Uplatnil : Integer -Castka : Double -id_Klient : Integer -id_Objednavka : Integer -Cislo : String -Pozn : String -Typ : Char -Venovani : String -id_CK : Integer -LastUpdate : Date -id_TypPoukazu : Integer -Stat : String -id_Faktura : Integer

0..*

0..*

0..1

0..1

«table» TypyPoukazu -ID : Integer -Vytvoren : Date -Nazev : String -Nazev_SK : String -Nazev_EN : String -Popis : String -Popis_SK : String -Popis_EN : String -Soubor : String -Typ : Char -Prefix : String -Aktivni : Boolean

«table» Poukazy_Faktury -ID : Integer -id_Klient : Integer -VS : String -Pocet : Integer -Castka : Double -Poplatek : Double -Celkem : Double -Splatnost : Date -id_Helios : Integer -Stat : String -Nazev : String -ICO : String -DIC : String -DICsk : String -Ulice : String -CP : String -PSC : String -Misto : String -Vytvorena : Date

Obrázek 4.9: Tabulky pro správu poukazů nového systému Procedura hsp_FakturacePoukazuAuto_CZ/SK prochází všechny řádky, které nemají vyplněnou hodnotu id_Helios, což je ID faktury z tabulky TabDokladyZbozi. Pro každý požadavek na vystavení faktury jsou provedeny tyto kroky: (a) Výpočet čísla odběratelské organizace. Pokud klient nechce fakturu zaslat žádné konkrétní organizaci, je použito číslo 1001, tedy obecný klient poukazu podobně, jako se používá obecný klient u faktur řady 068. V opačném případě je procedurou hsp_ZapisOrg_CZ/SK dohledána nebo vytvořena organizace na základě hodnot uložených v tabulce Poukazy_Faktury. (b) Vytvoření faktury. Je spuštěna procedura hsp_FakturacePoukazu_CZ/SK s parametrem @TabName nastaveným na hodnotu „hvFakturacePoukazuAuto“, číslem organizace z prvního kroku, bankovním spojením společnosti NetTravel a ID řádku Poukazy_Faktury. (c) Potvrzení vystavené faktury. Do zdrojového řádku v tabulce Poukazy_Faktury jsou doplněny hodnoty id_Helios a VS podle nové faktury. (d) Odeslání platebních podmínek klientovi. Od tohoto kroku je znám variabilní symbol pro platbu a klientovi je odeslán email s platebními podmínkami. Odeslání zajišťuje procedura psp_SendSysMail, která uloží požadavek na odeslání. Vlastní odeslání pak zajistí aplikace CRMSync ve spolupráci se systémem psaní emailů pro CRM. (e) Odeslání upozornění při žádosti o zaslání faktury. V případě, že chtěl klient na poukazy vystavit fakturu, je odeslán email účetnímu oddělení, které fakturu vytiskne a odešle cílové organizaci. 3. Ruční vystavení z CRM. Poslední možnost, jak vystavit fakturu na poukazy, slouží pro ruční vystavení poukazu z CRM. Aplikace CRM pro vystavení faktury vloží řádek do tabulky Poukazy_Faktury


97

a sama zavolá proceduru hsp_FakturacePoukazuAuto. Tím simuluje stejný proces, jaký probíhá při objednávce poukazu online a zbytek vystavení faktury probíhá stejně, jako v předchozím případě. 4.4.8.2

Vystavování faktur – hsp_FakturacePoukazu_CZ/SK

Vystavení jedné faktury na poukazy a přidání všech fakturovaných poukazů do položek této faktury zajišťuje procedura hsp_FakturacePoukazu_CZ/SK, jejíž struktura je naznačena na obrázku 4.10. Procedura může být spuštěna buď v automatickém nebo ručním režimu, které se liší ve výběru fakturovaných poukazů, viz 4.4.8.1. Vstupní parametry procedury jsou: 1. @TabName udává zdroj fakturace a určuje, které poukazy budou fakturovány. Parametr může nabývat dvou hodnot: (a) „hvw_FakturacePoukazu“ – ruční fakturace, při které jsou na fakturu přidány všechny poukazy podle uživatelského označení v přehledu hvw_FakturacePoukazu. (b) „hvFakturacePoukazuAuto“ – automatická fakturace. Mezi položky faktury budou přidány všechny poukazy, které mají hodnotu Poukazy.id_Faktura stejnou, jako je hodnota posledního vstupního parametru @id_Faktura. Při tomto režimu může být na fakturu přidán ještě řádek s poplatkem za zaslání originálu dárkového poukazu poštou. Částka poplatku je načtena z tabulky Poukazy_Faktury příslušné faktury s ID odpovídající hodnotě @id_Faktura do proměnné @Poplatek. 2. @CisloOrg udává číslo organizace, které bude faktura vystavena. 3. @IDBankSpoj je ID bankovního spojení organizace NetTravel a udává číslo bankovního účtu, na který má být úhrada faktury odeslána. 4. @id_Faktura je nepovinný vstupní parametr, který je vyplněn pouze v případě automatické fakturace. Udává ID z tabulky Poukazy_Faktury aktuálně zpracovávaného řádku. Procedura na základě hodnoty vstupního parametru @TabName otevře kurzor pro požadovanou sadu poukazů, který v cyklu na vytvořenou fakturu přidá položky odpovídající všem poukazům. Faktura je vytvořena spuštěním procedury hsp_ZapisFa_CZ/SK při prvním průchodu, aby nebyly vytvářeny prázdné faktury v případě, že kurzor nemá k dispozici žádná data. Uvnitř smyčky se podle hodnoty externího sloupce TabPohybyZbozi_EXT._id_Poukaz dohledá, zda se již poukaz nevyskytuje na jiných fakturách. Pokud ano, je částka aktuálního řádku snížena pomocí procedury hsp_FVPCastka_CZ/SK. Vlastní přidání řádku na fakturu pak zajišťuje další obecná procedura hsp_FVPIns_CZ/SK. Pokud byla faktura vytvořena, jsou po uzavření kurzoru provedeny ještě závěrečné úpravy faktury. Mezi ty patří přidání řádku s poplatkem, pokud je částka @Poplatek větši než nula. Dále jsou přepočteny kumulativní informace faktury spuštěním triggeru Heliosu, který tento přepočet zajistí. Posledním krokem je zrušení uživatelského označení procedurou hsp_ZrusOzn_CZ/SK. Procedura vrací ID vytvořené faktury jako svou návratovou hodnotu, aby bylo při automatické fakturaci v proceduře hsp_FakturacePoukazuAuto_CZ/SK možné s fakturou dále pracovat. 4.4.8.3

Dohledání poukazů na fakturách

Podobně, jako hledání zakázek na položkách vydaných faktur na provizi z prodeje zájezdů lze hledat i faktury, na kterých se vyskytuje poukaz. Hledání je realizováno jako externí akce Dohledání poukazu na fakturách typu „Přehled“ v přehledu hvw_FakturacePoukazu. Akce otevírá

98


hsp_FakturaceProvize_CZ/SK @Poplatek je þástka poplatku za zaslání originálu poukazu poštou, hodnota je uložena v tabulce Poukazy_Faktury.

Naþtení úvodních informací [Ruþní fakturace, @TabName=”hvw_FakturaceProvize”]

[Jinak] [Automatická fakturace]

Kurzor podle poukazĤ faktury z Poukazy_Faktury, naþtení @Poplatek

Kurzor podle uživatelského oznaþení

Oznámení chyby

OtevĜení kurzoru

Naþtení dalšího Ĝádku [Není další poukaz]

UzavĜení kurzoru

[Má data] [Faktura nebyla vytvoĜena]

[První poukaz] [Jinak] Zápis nové faktury hsp_ZapisFa_CZ/SK

[Jinak] [@Poplatek > 0]

Dohledání poukazu na jiných fakturách

PĜidání poplatku na fakturu hsp_FVPIns_CZ/SK

[Poukaz je na jiných fakturách] Snížení þástky hsp_FVPCastka_CZ/SK

[Jinak]

PĜidání ĜádkĤ na fakturu hsp_FVPIns_CZ/SK

PĜepoþet kumulativních údajĤ faktury

Zrušení oznaþení hsp_ZrusOzn_CZ/SK

Obrázek 4.10: Fakturace provize hsp_FakturacePoukazu_CZ/SK


99

definovaný přehled hvw_VyfakturovanePoukazy s podmínku WHERE nastavenou na „id_Poukaz=:ID“. Ta, stejně jako u zakázek, zajistí, že se zobrazí pouze ty řádky, které mají ve sloupci _id_Poukaz stejnou hodnotu, jako je ve sloupci ID aktuálně vybraného řádku z přehledu hvw_FakturacePoukazu. Přehled hvw_VyfakturovanePoukazy zobrazuje pouze číslo a základní informace o faktuře a, narozdíl od dohledávání zakázek, neumožňuje provádění dalších operací se zobrazenou fakturou. 4.4.9

Události řízené externími triggery

Dalším rozšířením Heliosu, které je v novém systému použito, jsou externí triggery, jejichž princip je popsán v části 4.3.7. Propojení CRM a účetního systému využívá externí trigger na tabulkách TabPokladna a TabDokladyZbozi. Aby bylo v databázi Heliosu minimum externího kódu, je v každém triggeru pouze kurzor iterující přes upravené řádky, který volá příslušnou stored proceduru umístěnou v databázi CRM. 4.4.9.1

Úhrada faktury

K tabulce TabDokladyZbozi je přidán externí trigger et_TabDokladyZbozi. Ten prochází všechna ID upravených faktur a spouští proceduru hsp_UhradaFa_CZ/SK, která načte informace o aktuální faktuře a na základě její řady zajišťuje požadované operace. U faktur řady 0*1 pro zaměstnavatele43 se kontroluje, zda byla faktura uhrazena v plné výši a zda ještě nebyla zaúčtována. Pokud jsou obě podmínky splněny je provedeno zaúčtování faktury procedurou hsp_ZauctovatFa_CZ/SK a následně úprava faktury řady 068 u stejné objednávky procedurou hsp_ZapisFaKli. Při úhradě faktury na poukazy řady 0*6 jsou aktivovány všechny poukazy, na které byla tato faktura vystavena. Pokud faktura nebyla dosud zaúčtována tak je rovnou provedeno i účtování procedurou hsp_ZauctovatFa_CZ/SK. Na konci výpočtu je vždy spuštěna procedura hsp_RenewIdentity, která obnoví hodnotu systémové proměnně @@IDENTITY, viz 4.4.3. 4.4.9.2

Zaúčtování pokladního dokladu

Tabulka TabPokladna má u sebe externí trigger et_TabPokladna, který pro zaúčtované pokladní doklady s vyplněnou hodnotou externího sloupce TabPokladna_EXT._id_DokladyZbozi spouští proceduru hsp_UctovaniPokladny_CZ/SK. Ta pro zaúčtované doklady, u kterých dosud není zapsaná žádná úhrada faktury, zapíše úhradu pomocí procedury Heliosu hp_OZGenPlat_Uhrada_Nova_Nebo_Oprava. Po zápisu úhrady je ještě do tabulky TabVDokPoklUhr přidána vazba mezi úhradou a zdrojovým pokladním dokladem. Při případném odstranění dokladu bude na základě tohoto propojení automaticky odstraněna i vytvořená úhrada. Na konci procedury je rovněž spuštěna hsp_RenewIdentity, která zajistí obnovení hodnoty systémové proměnné @@IDENTITY. 4.4.10

Zabezpečení externích akcí a definovaných přehledů

Přístup do aplikace Helios je povolen na základě integrovaného ověřování systému Windows a definice uživatelských práv v konfiguraci systému. Zde lze uživatele přidávat mezi uživatele SQL serveru a povolit jim tak přístup k databázovým objektům. Systém Helios řeší přístupová práva na základě vlastní vrstvy a databázově povoluje přístup ke všem objektům. V definici práv uživatelů lze konfigurovat přístup k jednotlivým přehledům pro každého uživatele zvlášť, 43

Faktury pro zaměstnavatele a význam jejich zaúčtování je popsán v části 4.4.5.4.

100


případně pro různé role. Jeden uživatel pak může mít přiřazenu pouze jednu roli, což je zásadní omezení. Vzhledem k častým změnám v organizační struktuře společnosti a velkými rozdíly mezi uspořádáním během hlavní sezóny a mimo ni jsou jednotlivým uživatelům práva často pouze přidávána a nikoli odebírána. Současně nejsou příliš využívány role, protože konkrétní zaměstnanci potřebují často přístup do sekcí nad rámec své základní role. Externí akce a definované přehledy Heliosu sice umožňují definici uživatelských práv, ale pouze ve stejném smyslu, jako jsou nastavována práva na ostatní části systému. Kromě toho, aplikace CRM nevyžaduje přímý přístup uživatelů k SQL databázi a uživatelé tak nemají zpravidla do databáze přístup. Bez zřízeného přístupu nemůžou spouštět stored procedury ani otevírat definované přehledy, které používají tabulky z databáze CRM. Z těchto důvodů je zabezpečení externích akcí vyřešeno formou uživatelských skupin v Active Directory domény systému Windows. Zde jsou definovány skupiny zabezpečení, kterým je současně povolen přístup do databáze CRM a podle svého účelu mají na úrovni SQL serveru povolena práva pro čtení nezbytných tabulek a spouštění konkrétních stored procedur. Režim skupin Active Directory umožňuje, aby jeden uživatel byl členem více uživatelských skupin současně, což rozšiřuje možnosti nastavení systému. Pro účely propojení aplikace CRM a Heliosu jsou zřízeny tyto uživatelské skupiny: HeliosFakturace – skupina, která garantuje přístup k externím akcím souvisejícím s fakturací poukazů a provize z prodeje zájezdů. Uživatelé bez členství v této skupině nemají přístup k souvisejícím stored procedurám. HeliosPlatby – skupina, která garantuje přístup k placení zájezdů, generování dávek a souvisejícím operacím v přehledu Platby. HeliosUsers – obecná skupina, která povoluje čtení tabulek a spouštění obecných procedur, případně dalších rozšíření funkcí Heliosu. V případě definovaných přehledů není využito žádné dodatečné zabezpečení. Přehledy neobsahují citlivé informace, které by bylo nutné tajit a zpravidla využívají tabulky z databáze CRM. Proto uživatelé Heliosu, kteří nejsou alespoň členy skupiny HeliosUsers nemají k přehledům přístup. Kromě přístupu do databáze CRM je nutné přidat také uživatele, pod kterým se připojuje k databázi aplikace DSP mezi uživatele systému Helios a přidat ho do české i slovenské databáze. Jinak by nebylo možné provádět žádné operace pracující s objekty v databázích Heliosu z aplikace CRM.

KAPITOLA 5. PŘÍPADOVÉ STUDIE

101

5 Případové studie V této části jsou rozebrány typické situace, které nastávají při běhu nového systému. Narozdíl od předcházejícího popisu jednotlivých funkcí jsou zde operace a jejich návaznosti popsány v kontextu celé aplikace. Případové studie poskytují širší pohled na celý průběh prodejního procesu podle nového systému a je zde naznačena spolupráce konkrétních částí projektu.

5.1

Typický průběh prodeje zájezdu

Hlavní funkcí nového systému, kterou je nutné zachovat, je schopnost evidovat finance u všech objednávek a umožnit tak prodej zájezdů. V této části je popsán typický průběh prodeje zájezdu, včetně všech provedených plateb. Ty zahrnují jak správu příchozích plateb od klienta, tak úhradu ceny zájezdu do cestovní kanceláře. 5.1.1

Popis situace

Do aplikace CRM byla přijata nová objednávka, která mohla být vytvořena online na webu společnosti, nebo zadána ručně prodejcem, a bylo jí přiděleno ID 321420. U této objednávky proběhlo vyjasnění detailů zájezdu s klientem, rezervace zájezdu v cestovní kanceláři a úhrada zájezdu klientem. Pro úhradu zálohy ve výši 50 % celkové ceny využil klient možnost složit peníze v hotovosti na některé z poboček. Doplatek zaslal bankovním převodem měsíc před odjezdem na účet společnosti NetTravel. Případná žádost klienta o vystavení faktury pro zaměstnavatele je popsána v případové studii v části 5.2. Na základě podepsané smlouvy zaslala cestovní kancelář společnosti NetTravel fakturu, na které je uvedena celková cena zájezdu. Polovina ceny zájezdu je splatná týden od přijetí faktury, doplatek měsíc před odjezdem. Celková cena zájezdu je 30 000 Kč, z čehož je 2 100 Kč provize. Cestovní kancelář není plátcem DPH a zájezdy této CK jsou s provizí hned1 . Čili faktura od CK je vystavena na částku 27 900 Kč. Společnost NetTravel cestovní kanceláři pořádající zájezd vystavila fakturu na provizi z prodeje zájezdů. Tato faktura zohledňuje provizi hned a byla vystavena při pravidelné měsíční fakturaci provizí všech CK. Případnou změnu provize po vystavení faktury řeší studie 5.3. 5.1.2

Řešení

Zde jsou popsány jednotlivé kroky prodejního procesu odpovídající situaci rozepsané výše. 1. Přijetí objednávky do systému. Prvním krokem prodeje každého zájezdu je přijetí objednávky do CRM. Ta může vzniknout online na webu společnosti, kde si klient vybere konkrétní termín zájezdu a vyplní objednávkový formulář, nebo ručním vytvořením záznamu prodejcem. Ten se využívá při telefonických objednávkách, osobních návštěvách na pobočce nebo v případě, že je jedna objednávka klienta stornována, ale klient má zájem o alternativní nabídku. Informace o založení objednávky nemá na prodejní proces ani evidenci financí žádný vliv. Může se pouze lišit způsob, jakým prodejce komunikuje s klientem. Objednávce z této případové studie bylo přiděleno ID 321420, což bude později také číslo zakázky v databázi Heliosu. 2. Provedení rezervace a vytvoření cestovní smlouvy. V této fázi prodejce intenzivně komunikuje s klientem a jsou vyřešeny podrobnosti prodeje zájezdu. Je vytvořena rezervace konkrétního zájezdu v cestovní kanceláři a prodejce 1

Význam pojmu „provize hned“ je vysvětlen v části 3.2.4.

102


Sborník 068 068

Účet Má dáti Dal 315400 325400

Částka 30 000 30 000

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK.

Tabulka 5.1: Stav účtování zakázky po zápisu faktury klientovi v systému na vytváření cestovních smluv připraví pro klienta smlouvu k podpisu. Cestovní smlouva je zasílána emailem, případně rovnou vytištěna pro klienty, kteří přišli cestovní smlouvu podepsat osobně na pobočku. Při vytváření smlouvy je vyplněna kalkulace pro jednotlivé cestující a vypočtena celková cena zájezdu. Ta je v tomto případě 30 000 Kč a je uložena do sloupce CenaCelkem objednávky ID 321420. Objednávka prochází různými stavy, které ale nemají žádný vliv na evidenci financí. Aplikace CRM po každé akci spouští proceduru hsp_ZmenaStavu (viz 4.4.5.5), která pouze kontroluje, že na zakázku nejsou kladeny žádné požadavky a neprovádí žádné operace. 3. Podpis smlouvy klientem, vystavení faktury řady 068. Akce podepsání smlouvy klientem v CRM změní stav objednávky na 30, tj. „Smlouva podepsaná“, a spustí proceduru hsp_ZmenaStavu. Od tohoto okamžiku vzniká pohledávka a klient je povinen uhradit celkovou cenu zájezdu společnosti NetTravel. Procedura hsp_ZmenaStavu pomocí hsp_SyncObj_CZ/SK (viz 4.4.3) vytvoří záznam v tabulce TabZakazka a vyplní do sloupce CisloZakazky hodnotu 321420. Tím je objednávka přenesena do Heliosu a lze její číslo uvádět jako cizí klíč do ostatních tabulek. Dalším krokem procedury hsp_SyncObj_CZ/SK je spuštění hsp_ZapisFaKli popsané v části 4.4.5.6. Ta do proměnné @Castka načte celkovou cenu zájezdu 30 000 Kč. S touto částkou je následně spuštěna hsp_ZapisFaKli_CZ/SK. Zápis faktury pro klienta vytvoří vydanou fakturu řady 068 na částku 30 000 Kč, jako organizaci použije obecnou organizaci s číslem 1000 „Klient zájezdu“ a tuto fakturu zaúčtuje do účetního deníku. Přehled deníku pro zakázku 321420 je v tabulce 5.1. Zatím je zde pouze zaúčtování faktury 068, které na účtu 315400 vytváří předpis hodnoty ZaplatitKlientovi a na 325400 předpis očekávaných faktur od CK. Hodnota ZaplatitKlientovi je nyní −30 000 Kč a klient tyto peníze dluží společnosti NetTravel. 4. Úhrada zálohy v hotovosti. Při zápisu platby v hotovosti je prodejce v aplikaci CRM dotázán pouze na zadání částky 15 000 Kč a poznámky, která je součástí každé akce. Číslo pokladny je uloženo v konfiguračním souboru, který se liší pro každou pobočku a ostatní údaje pro vytvoření pokladního dokladu jsou načteny automaticky. Vytvoření pokladního dokladu zajišťuje procedura hsp_ZapisPlatbyHotove, která pouze zkontroluje, zda není zapisována nulová částka a zda je stát pobočky stejný, jako stát objednávky, aby nebyla zapsána platba ve špatné měně. Jinak procedura pracuje pouze jako rozcestník na hsp_ZapisPlatbyHotove_CZ/SK, popsané v části 4.4.5.7. Návratovou hodnotou z procedury na vytvoření dokladu je jeho ID. CRM si po zápisu obnoví seznam pokladních dokladů procedurou hsp_PlatbyHotove (viz 4.4.5.2) a podle vráceného ID dohledá nově zapsanou platbu. Na základě informací z nalezeného řádku je přímo v CRM zobrazen příjmový pokladní doklad, který prodejce klientovi vytiskne. Spuštěná procedura hsp_ZapisPlatbyHotove_CZ/SK zapsanou platbu také zaúčtuje do fáze „Pořízeno“. Objednávky s účetními doklady ve fázi „Pořízeno“ jsou v přehledu Platby


Sborník 068 068 yyy yyy

Účet Má dáti Dal 315400 325400 211xxx 315400

Částka 30 000 30 000 15 000 15 000

103

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou.

Tabulka 5.2: Stav účtování zakázky po zápisu pokladního dokladu zvýrazněny modrým písmem, aby byl uživatel upozorněn na výskyt nepotvrzené platby. Platby v hotovosti se potvrzují, tj. převádí do fáze „Účtováno“, v okamžiku složení hotovosti z pokladny na bankovní účet společnosti na základě soupisky pokladny. Zaúčtování dokladu, kromě změn v účetním deníku, spustí trigger et_TabPokladna popsaný v části 4.4.9.2, který k faktuře 068 zapíše úhradu do tabulky TabUhrady s částkou 15 000 Kč a vazbou na pokladní doklad. V případě zápisu druhé platby ve stejný den by k zaúčtování nedošlo, protože by se pravděpodobně jednalo o opravu dokladu a tedy duplicitní zápis platby (viz 4.4.5.7). Odúčtování prvního a zaúčtování druhého dokladu by následně zajistila obsluha přehledu Platby při potvrzování plateb na základě soupisky. Zaúčtování přijaté platby se provádí na účty 211xxx/3154002 a platba tak vyrovnává hodnotu ZaplatitKlientovi. Stav účetního deníku pro zakázku 321420 po zápisu platby v hotovosti je znázorněn v tabulce 5.2. Hodnoty zobrazené v přehledu Platby u objednávky jsou nyní: ZaplatitKlientovi −15 000 ZaplatitCK 0 Fond 15 000 Hodnota ZaplatitKlientovi je záporná a po úhradě poloviny ceny zájezdu se závazek klienta snížil z celkové ceny zájezdu −30 000 Kč na očekávaný doplatek −15 000 Kč. V účtování se zatím nevyskytuje účet 325100 a v ZaplatitCK je proto nula. Tato hodnota se změní po zápisu přijaté faktury od CK řady 023. K objednávce celkem přišlo 15 000 Kč a nebyla odeslána žádná platba a proto je hodnota fondu 15 000 Kč, tj. maximální částka odchozí platby. 5. Zaslání smlouvy do CK. Akce zaslání smlouvy do CK spuštěná v CRM nemá zásadní vliv na finance evidované u objednávky. Akce je důležitá pro samotný prodejní proces, protože je do cestovní kanceláře odeslán email s podepsanou cestovní smlouvou a stav objednávky se změní na 70, tj. „Smlouva poslaná do CK“. Od tohoto stavu se objednávka považuje za prodanou a započítává se do prodejních reportů. Odesláním smlouvy do CK se potvrzuje rezervace zájezdu a společnost NetTravel je povinna zájezd do cestovní kanceláře uhradit. A to i v případě, že klient zájezd nezaplatí. Storno smlouvy se řídí smluvními podmínkami každé CK a může obsahovat storno poplatek. Proto v prodejním procesu musí být vždy nejdříve přijata platba a až následně odeslána smlouva do CK. Kdyby klient neuhradil doplatek zájezdu, bude storno poplatek uhrazen z již přijaté zálohy. 2

„xxx“ zastupuje číslo účtu pro konkrétní pokladnu. Význam jednotlivých účtů je popsán v tabulce 4.4.

104


Sborník 068 068 yyy yyy 023 023 023 023 069 069

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801

Částka 30 000 30 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu.

Tabulka 5.3: Stav účtování zakázky po zápisu faktur od CK řady 023 a provize 6. Zápis přijaté faktury od CK řady 023. Cestovní kancelář na základě podepsané cestovní smlouvy vystaví fakturu společnosti NetTravel na konkrétní zájezd. V případě cestovní kanceláře pořádající zájezd 321420 si nechává společnost NetTravel provizi hned, a proto obdrží fakturu na částku 27 900 Kč. Tato částka je na faktuře rozdělena na dvě splatnosti – částka 13 950 Kč je splatná do jednoho týdne, doplatek ve výši 50 % je splatný měsíc před odletem. Na faktuře je rovněž vyčíslena provize z prodeje zájezdu na částku 2 100 Kč. Fakturu společnost NetTravel obdrží zpravidla ve formátu PDF, případně jiné elektronické podobě. Asistent finančního nebo prodejního oddělení, zodpovědný za zápis faktur od CK, přijatou fakturu zapíše k objednávce ID 321420 jako dvě samostatné faktury, každou s příslušným datem splatnosti a stejným číslem faktury i částkou. Zápis je realizován procedurou hsp_ZapisFaCK (viz 4.4.5.3), která vytvoří přijatou fakturu 023 a zaúčtuje. Během zápisu asistent přiloží dokument v elektronické podobě do příloh objednávky, při čemž je spuštěna procedura hsp_PrilozitDokumentFP zapisující soubor také mezi dokumenty do účetního systému ke konkrétní faktuře. Po zápisu faktur asistent zapíše také částku provize 2 100 Kč ke konkrétní objednávce. Při změně provize spouští aplikace CRM proceduru hsp_ZmenaStavu i v případě, že ke změně stavu nedošlo. V proceduře je jako jeden z kroků spuštěna procedura hsp_ZapisProv (4.4.5.5), která zajistí zápis provize do účetnictví. Stav účetního deníku pro zakázku 321420 po zápisu obou faktur a předpisu provize je zobrazen v tabulce 5.3 a hodnoty zobrazené v přehledu Platby u objednávky jsou nyní: ZaplatitKlientovi −15 000 ZaplatitCK 27 900 Fond 15 000 Zapsané faktury se účtují jako 325400/325100 a mají vliv pouze na hodnotu ZaplatitCK, která nyní udává předpis pro částku k odeslání do cestovní kanceláře. Ve fondu je stále 15 000 Kč a nesmí být odesláno více, než je tato částka. Na účet 325400 již nebude nic zapisováno a zůstane pro zakázku nevyrovnaný. Rozdílová částka je výše provize 2 100 Kč, ale tento případ se vyskytuje pouze u objednávek fakturovaných s provizí hned. U ostatních je účet 325400 vyrovnán. Účetní oddělení na konci roku


105

tento účet vyrovná jediným dokladem 325001/325400 pro všechny zakázky fakturované s provizí hned. Na účet 325001 se na vydaných fakturách účtuje provize hned namísto jejich úhrady, viz rozpis účtování v části 4.2.2. Zaúčtování provize hned u vydané faktury na provizi z prodeje zájezdu je realizován uvnitř procedury hsp_ZauctovatFa_CZ/SK popsané v části 4.4.3. 7. Úhrada zálohy do CK. Podle hodnot ZaplatitCK a Fond již nic nebrání tomu, aby byla odeslána platba do CK. Obsluha přehledu Platby označí klávesou Insert řádek se zakázku 321420 spolu s dalšími objednávkami, které chce uhradit do cestovních kanceláří. Spustí externí akci CRM Platby / Kontrola dávky do CK, která odkazuje na proceduru hsp_Davka_CZ/SK (viz 4.4.6.3) s parametrem @Generovat nastaveným na hodnotu 0 = false. Tím je spuštěna kontrola dávky ještě před vytvořením platebního příkazu, aby bylo možné odstranit případné problémy. Kontrola dávky v případě zakázky 321420 vybere k úhradě pouze první fakturu řady 023 v pořadí splatnosti a tu se pokusí uhradit. Vzhledem k tomu, že první faktura nebyla zatím uhrazena, tak druhá nebude zařazena do dávky a bude odesláno pouze 13 950 Kč. Uživatel je na tuto situaci upozorněn příslušnou zprávou pomocí tabulky #TabExtKom. Kontrola dávky v tomto případě nenarazí na žádné problémy, protože: • Hodnota ZaplatitCK obsahuje kladnou částku k úhradě do CK. • Byla nalezena dosud neuhrazená faktura 023 k úhradě. • Ve fondu objednávky je dostatek prostředků k odeslání platby. • Faktura 023 má organizaci s vyplněným bankovním spojením. Jako další krok zvolí obsluha aplikace platby externí akci CRM Platby / Dávka CK, která rovněž spustí proceduru hsp_Davka_CZ/SK, ale s parametrem @Generovat přednastaveným na hodnotu 1 = true. Současně musí uživatel vybrat bankovní spojení, ze kterého bude dávka odeslána. Průběh generování je téměř stejný jako v případě kontroly, při průchodu je navíc vytvořen platební příkaz v tabulce TabPlatTuz a jeho položky. Při vytváření řádku platebního příkazu je k hrazené faktuře 023 zapsána úhrada do tabulky TabUhrady, která představuje peníze na cestě a čeká na své potvrzení bankovním výpisem. Po vygenerování dávky exportuje uživatel Heliosu platební příkaz do souboru a odešle prostřednictvím elektronického bankovnictví do banky. Export dávkového souboru zajišťují funkce v aplikaci Helios pro všechny banky. Vytvoření platebního příkazu, zápis úhrad, export dávkového souboru a jeho odeslání do banky neprovádí žádné změny v účetním deníku a odeslaná platba se bude vyskytovat na bankovním výpisu až druhý den. Aby nedocházelo k tomu, že obsluha přehledu Platby odešle stejnou platbu vícekrát za sebou, je do výpočtu v přehledu hvw_PlatbyMain, zobrazeného v soudečku Platby, zahrnuta hodnota NaCesteCK, resp. NaCesteKlientovi. Hodnota se vypočte na základě úhrady faktury zapsané z platebního příkazu, která zatím nebyla potvrzena bankovním výpisem. NaCesteCK se v přehledu odečítá od hodnoty ZaplatitCK i Fond, protože byla již odeslána do cestovní kanceláře i odčerpána z fondu objednávky. Stavy zobrazených hodnot v přehledu Platby jsou po odeslání platby následující: ZaplatitKlientovi −15 000 ZaplatitCK 13 950 Fond 1 050 NaCesteCK 13 950

106


Sborník 068 068 yyy yyy 023 023 023 023 069 069 zzz zzz

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801 325100 221xxx

Částka 30 000 30 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100 13 950 13 950

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání ocekávané cástky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby.

Tabulka 5.4: Stav účtování zakázky po odeslání první platby do CK Tento stav zůstane u objednávky 321420 až do zpracování bankovního výpisu následující den. Na tomto výpisu je řádek odpovídající variabilním symbolem a částku uhrazené faktuře 023. Z bankovního výpisu je zapsána úhrada do tabulky TabUhrady, která potvrdí úhradu vytvořenou z platebního příkazu a vynuluje tak peníze na cestě, a řádek výpisu je zaúčtován 325100/221xxx. Stav účetního deníku pro zakázku 321420 po zpracování bankovního výpisu je v tabulce 5.4. Dojde také ke změně hodnot v přehledu Platby takto: ZaplatitKlientovi −15 000 ZaplatitCK 13 950 Fond 1 050 NaCesteCK 0 Zápisem úhrady z bankovního výpisu je vynulováno NaCesteCK a částky ZaplatitCK a Fond již nejsou vypočteny s pomocí NaCesteCK, ale na základě nového zaúčtování zakázky. 8. Fakturace provize. U objednávky ID 321420 probíhá fakturace formou provize hned a datum fakturace DUZP je tedy datum zápisu provize. Provize jako taková již byla do systému zapsána a objednávka je zařazena do nejbližšího vystavování faktur podle postupu rozepsaného v části 4.4.7, které probíhá vždy na konci měsíce. Objednávka může být v případě provize hned fakturována dříve, než byla celá uhrazena do CK a tedy dříve, než je termín odjezdu. V případě, že by do odjezdu došlo ke změně provize, případně ke stornu zájezdu, bude objednávka zobrazena v přehledu Nevyfakturované obj., ze kterého lze fakturaci spustit dodatečně (viz 4.4.7.1) a případný rozdíl tak dorovnat. Na jedné vydané faktuře na provizi z prodeje zájezdů se mohou vyskytovat objednávky jak s provizí hned, tak bez ní. V případě 321420 se jedná o případ s provizí hned a proto bude u položky vyplněn sloupec TabPohybyZbozi_EXT._Placeno na celkovou částku. Na faktuře bude hodnota tohoto sloupce zobrazena jako již uhrazená, CK nebude platbu za tuto objednávku odesílat ale pouze provede její účetní zpracování. Při zaúčtování faktury procedurou hsp_ZauctovatFa_CZ/SK jsou na účetní doklad přidány ještě řádky pro


Sborník 062 062 062 062 062 062 zzz zzz

Účet Má dáti Dal 602100 602100 602100 311100 325001 311100 221xxx 311100

Částka 2 100 1 000 3 300 6 400 3 100 3 100 3 300 3 300

107

Popis Provize zakázky ID 321420 s provizí hned. Provize zakázky ID 321500 s provizí hned. Provize zakázky ID 321105 bez provize hned. Faktura 092, hlavička dokladu – součet položek. Převod provize hned na jiný účet. Převod provize hned z účtu hlavičky. Bankovní účet - přijatá platba. Vyrovnání účtu hlavičky – úhrada faktury.

Tabulka 5.5: Ukázka účtování uhrazené vydané faktury na provizi řady 0*2. 325001/311100, které převádějí součet všech provizí hned na účet 325001. Očekávaná platba za fakturu na účtu 311100 je tedy účetně snížena. Úhrada faktury, tj. její části bez provize hned, se pak na řádku bankovního výpisu účtuje jako 221xxx/311100. Tím se vyrovná účet faktury 311100 a v nevyrovnaném stavu zůstává pouze částka provize hned na účtu 325001. Ta je na konci roku vyrovnána ručně jediným dokladem účtovaným 325400/325001, jak je popsáno výše. Ukázka zaúčtované a uhrazené faktury řady 092 (obecně 0*2) je v tabulce 5.5 a pro ilustraci obsahuje několik dalších objednávek. K účtování zakázky přibude pouze řádek s účtem 602100, který nemá žádný vliv na výpočet stavu financí u objednávky. 9. Úhrada doplatku bankovním převodem. Přibližně měsíc před odletem upozorní prodejce klienta emailem na splatnost doplatku jeho zájezdu a ten platbu odešle bankovním převodem. Následující den po přijetí platby na účet společnosti je platba na importovaném bankovním výpisu. Obsluha aplikace Helios používá pro automatické párování externí akci (viz 4.4.2), která spouští proceduru hsp_ParovaniUctu_CZ/SK. Ta se pokusí dohledat k platbám jejich zakázky a vybrat jeden z účtů 315400 a 325100 pro zaúčtování. V případě popisované platby je vyplněno číslo zakázky 321420 a účet 315400, protože variabilní symbol a částka odpovídá platbě od klienta. Kromě účtování jsou platbám na bankovním výpisu přiřazeny také úhrady. Platba od klienta vytvoří úhradu s částkou 15 000 Kč u faktury řady 068. Ta má nyní v úhradách celkem 30 000 Kč, protože první úhrada byla zapsána z pokladního dokladu. Stav účtování zakázky po zpracování bankovního výpisu s platbou od klienta je zobrazen v tabulce 5.6. Aktuální hodnoty zobrazené v přehledu Platby jsou: ZaplatitKlientovi 0 ZaplatitCK 13 950 Fond 16 050 Platba zaúčtovaná jako 221xxx/315400 vyrovnala hodnotu ZaplatitKlientovi a klient již nedluží žádné peníze. Tato částka byla převedena do fondu objednávky a může být odeslána do CK. Ve fondu je současně částka provize hned, protože tu si společnost NetTravel nechává a neodesílá ji do cestovní kanceláře. 10. Úhrada doplatku do CK.

108


Sborník 068 068 yyy yyy 023 023 023 023 069 069 zzz zzz 062 zza zza

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801 325100 221xxx 602100 221xxx 315400

Částka 30 000 30 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100 13 950 13 950 2 100 15 000 15 000

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Položka faktury 092, vyfakturovaná provize. Bankovní účet - přijatá platba. Vyrovnání ZaplatitKlientovi bank. výpisem.

Tabulka 5.6: Stav účtování zakázky po doplatku klienta Z pohledu financí zbývá pouze odeslat doplatek do cestovní kanceláře. Jeho úhrada probíhá stejně, jako v prvním případě. Jediný rozdíl je, že při výběru konkrétní faktury řady 023 k úhradě je první faktura již plně uhrazena a nyní bude úhrada provedena u druhé. Stejný postup probíhá také z pohledu peněz na cestě. Ihned po odeslání je vytvořena úhrada z platebního příkazu, která reprezentuje peníze na cestě. Až do potvrzení platby bankovním výpisem bude stav financí u objednávky následující: ZaplatitKlientovi 0 ZaplatitCK 0 Fond 2 100 NaCesteCK 13 950 Hodnota peněz na cestě je odečtena jak od ZaplatitCK, tak od Fond, protože peníze již fyzicky odešly a platba nesmí být do CK odeslána vícekrát. Po zaúčtování bankovního výpisu bude zakázka z pohledu financí již uzavřena, jak je naznačeno v tabulce 5.7, a stav financí se změní na: ZaplatitKlientovi 0 ZaplatitCK 0 Fond 2 100 NaCesteCK 0 V případě, že by klient odeslal peníze přímo do cestovní kanceláře, namísto společnosti NetTravel, proběhl by zápis platby přímo do CK realizovaný procedurou hsp_ZapisPlatbyKliCK (viz 4.4.5.8). Ten by částku zaúčtoval jako 325100/315400 interním dokladem a vzájemně tak započetl fakturu 068 klientovi a 023 od CK. Do CK by tím ale odešla platba 15 000 Kč, která by zahrnovala část provize. Ta by způsobila, že by měl sloupec ZaplatitCK hodnotu 1 050 Kč a CK by tuto platbu musela odeslat zpět společnosti NetTravel.


Sborník 068 068 yyy yyy 023 023 023 023 069 069 zzz zzz 062 zza zza zzb zzb

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801 315100 221xxx 602100 221xxx 315400 325100 221xxx

Částka 30 000 30 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100 13 950 13 950 2 100 15 000 15 000 13 950 13 950

109

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Položka faktury 092, vyfakturovaná provize. Bankovní účet - přijatá platba. Vyrovnání ZaplatitKlientovi bank. výpisem. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby.

Tabulka 5.7: Stav účtování zakázky po odeslání druhé platby do CK 11. Zaslání cestovních pokynů. Objednávka 321420 je plně uhrazena v cestovní kanceláři a nic nebrání tomu, aby klient odcestoval. Týden před odjezdem zašle CK společnosti NetTravel, případně klientovi, cestovní pokyny a tím prodejní proces končí. Prodejce pouze u objednávky provede změnu stavu, čímž se objednávka považuje za uzavřenou. Tato změna stavu spustí proceduru hsp_ZmenaStavu, která prakticky pouze zkontroluje zapsanou provizi a zapsanou fakturu klientovi a neprovede žádné změny. V případě, že by některá z hodnot ZaplatitCK nebo ZaplatitKlientovi nebyla nulová, bude objednávka zobrazena v přehledu Platby k dořešení. V případě změny celkové ceny zájezdu během prodejního procesu je rovněž spuštěna procedura hsp_ZmenaStavu, která zajistí, že bude upravena faktura 068 klientovi procedurou hsp_ZapisFaKli (viz 4.4.5.6). Ta upraví účtování 315400/325400 a změní tím jak předpis ZaplatitKlientovi, tak částku očekávaných faktur od CK řady 023 evidovanou na účtu 325400. Ke změně ceny dochází nejčastěji v důsledku změny objednaných služeb, případně změn v počtu cestujících osob.

5.2

Vystavení faktury pro zaměstnavatele

Některé společnosti, včetně státních organizací, hradí v rámci svých systémů benefitů část nákladů na dovolenou. Zpravidla to bývá do výše 50 % z celkové ceny. V takovém případě klient požádá o vystavení faktury na zájezd pro svého zaměstnavatele. Prodejce na základě této žádosti vystaví fakturu řady 0*1 a odešle ji klientovi. Bez ohledu na tuto fakturu musí být zájezd uhrazen dle své splatnosti. Proto ve většině případů celkovou cenu uhradí nejprve klient a až později dorazí platba od jeho zaměstnavatele. Následně je vzniklý přeplatek vrácen zpět klientovi.

110 5.2.1

KAPITOLA 5. PŘÍPADOVÉ STUDIE Popis situace

Prodej zájezdu a jeho úhrady probíhají stejným způsobem, jako u předcházející studie 5.1. Během přípravy cestovní smlouvy se klient dotáže prodejce, zda je možné jeho zaměstnavateli vystavit před odjezdem fakturu a vzniklý přeplatek vrátit na účet klienta. Domluví se spolu, že prodejce fakturu vystaví před odjezdem, protože interní pravidla společnosti, pro kterou klient pracuje, umožňují platit zájezdy až ke dni jejich realizace. Prodejce vystaví fakturu dle dohody a odešle ji klientovi. Ten ji před nástupem na dovolenou předá zaměstnavateli, který fakturu později uhradí. Přeplatek zájezdu je vrácen převodem na bankovní účet klienta. 5.2.2

Řešení

Aplikace CRM a její propojení na účetní systém obsahují pro realizaci tohoto požadavku sadu funkcí, které umožňují jeho jednoduché zpracování. Celý proces obsahuje několik kroků, které nejsou závislé na stavu objednávky. Na základě vzniklé situace se předpokládá, že faktura bude vystavena kdykoliv před stavem objednávky 100, tj. „Vyřízeno, klient má c. pokyny“, a uhrazena nejdříve v den odjezdu. 1. Vystavení faktury řady 091 pro zaměstnavatele. Během prodejního procesu může prodejce vystavit fakturu klientovi prostřednictvím aplikace CRM, která spustí proceduru hsp_ZapisFaZam (viz 4.4.5.4). Tím se u zakázky 321420 vytvoří nová, nezaúčtovaná faktura řady 091 (obecně 0*1). Návratová hodnota procedury je ID nové faktury, podobně jako u zápisu pokladního dokladu. Aplikace CRM si po vytvoření dokladu obnoví seznam faktur pro zaměstnavatele procedurou hsp_FaZam a podle vráceného ID dohledá nový řádek. Pro tento řádek rovnou zobrazí fakturu, kterou lze vytisknout na tiskárně nebo do souboru PDF. Až do zaúčtování faktury má prodejce možnost fakturu upravovat a opět vytisknout. Pro úpravu slouží rovněž hsp_ZapisFaZam. Procedura má vstupní parametry ve stejném pořadí, jako jsou vrácené sloupce z hsp_FaZam. Faktura není po zápisu účtována a čeká v systému na svou úhradu. Vytvoření faktury tedy nezasahuje do stavu financí objednávky ani žádných výpočtů. Může se stát, že zaměstnavatel nakonec fakturu neuhradí a ta by komplikovala evidenci financí u objednávky. 2. Úhrada faktury řady 091 zaměstnavatelem. Řádek s přijatou platbou bankovního výpisu se účtuje stejně, jako v případě přijaté platby od klienta. Podle variabilního symbolu je automaticky dohledána konkrétní faktura řady 091 a je k ní zapsána úhrada do tabulky TabUhrady. Zápis úhrady způsobí spuštění externího triggeru et_TabDokladyZbozi (viz 4.4.9.1), který spustí proceduru hsp_UhradaFa_CZ/SK. V této proceduře je, v případě úhrady v plné výši, procedurou hsp_ZauctovatFa_CZ/SK faktura zaúčtována. Za předpokladu, že byla od klienta přijata i druhá platba a objednávka je tedy plně uhrazena, je nyní v systému faktura řady 068 na 30 000 Kč a faktura řady 091 na 15 000 Kč, obě uhrazeny v plné výši. Současně jejich součet účtu 315400 udává závazek klienta ve výši 45 000 Kč. Proto se ihned po zaúčtování faktury řady 091 v proceduře hsp_UhradaFa_CZ/SK spouští hsp_ZapisFaKli (viz 4.4.5.6), která upraví částku faktury řady 068. Procedura zapisující fakturu klientovi zjistí, že existuje faktura řady 0*1 a sníží částku faktury 068 i její účtování na 15 000 Kč. Tím se předpis k úhradě klientovi sníží v součtu obou faktur (068 i 091) na 30 000 Kč. Částka faktury 068 byla sice snížena na 15 000 Kč, ale v úhradách je stále původních 30 000 Kč zapsaných z pokladního dokladu a bankovního


Sborník 068 068 yyy yyy 023 023 023 023 069 069 zzz zzz 062 zza zza zzb zzb 068 068 zza zza

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801 325100 221xxx 602100 221xxx 315400 325100 221xxx 315400 325400 221xxx 315400

Částka 15 000 15 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100 13 950 13 950 2 100 15 000 15 000 13 950 13 950 15 000 15 000 15 000 15 000

111

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Položka faktury 092, vyfakturovaná provize. Bankovní účet - přijatá platba. Vyrovnání ZaplatitKlientovi bank. výpisem. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Faktura 091, předpis ZaplatitKlientovi. Faktura 091, předpis faktur od CK. Bankovní účet - úhrada faktury řady 091. Vyrovnání ZaplatitKlientovi bank. výpisem.

Tabulka 5.8: Stav účtování zakázky po úhradě faktury pro zaměstnavatele výpisu dle předchozí studie. Současně zaúčtovaný řádek bankovního výpisu hradící fakturu 091 způsobuje, že je na účtu 315400 přeplatek ve výši 15 000 Kč. Stav deníku, po všech změnách souvisejících s úhradou faktury od zaměstnavatele, je u zakázky 321420 zobrazen v tabulce 5.8. Ostatní hodnoty zobrazené v přehledu Platby jsou3 : ZaplatitKlientovi 15 000 ZaplatitCK 0 Fond 17 100 3. Zadání čísla bankovního spojení klienta. U objednávky je v současném stavu evidován přeplatek od klienta ve výši 15 000 Kč. Ten si může klient vyzvednout v hotovosti na některé z poboček společnosti, nebo požádat o vrácení přeplatku převodem. Tato studie počítá s druhou variantou, u které prodejce vyzve klienta emailem, aby zaslal číslo svého bankovního účtu pro vrácení přeplatku. Číslo účtu je zadáno buď prostřednictvím CRM nebo externí akci v přehledu Platby Heliosu. V obou případech je spuštěna procedura hsp_ZadatUcetKlienta, resp. hsp_ZadatUcetKlienta_CZ/SK popsaná v části 4.4.6.4. Ta změní organizaci na faktuře řady 068 z obecné „Klient zájezdu“ na nově vytvořenou „Klient zájezdu ID 321420“ a u této organizace vytvoří jedno bankovní spojení odpovídající číslu účtu klienta. 3

Částky předpokládají, že zájezd byl již uhrazen do CK.

112


4. Vrácení přeplatku klientovi. Podobně jako při úhradě do CK je již vše připraveno na vrácení peněz klientovi. Obsluha přehledu Platby může použít akce CRM Platby / Kontrola dávky klientům a Dávka klientům pro přípravu platebního příkazu. Podobně jako u plateb do CK lze na jeden příkaz zařadit více objednávek. Externí akce spouští proceduru hsp_Davka_CZ/SK (viz 4.4.6.3), která bude u platby klientovi pracovat pouze s fakturami řady 068. Kontrola dávky nenarazí na žádné problémy, protože jsou splněny všechny požadavky na generování platebního příkazu: • • • •

Hodnota ZaplatitKlientovi obsahuje kladnou částku k odeslání. Byla nalezena faktura řady 068, která má v úhradách evidovaný přeplatek4 . Ve fondu objednávky je dostatek prostředků k odeslání platby. Faktura 068 má organizaci s vyplněným bankovním spojením klienta.

Podobně jako v případě platby do CK je vygenerován platební příkaz pro internetové bankovnictví, který uživatel odešle do banky. S platebním příkazem je vytvořena úhrada faktury 068, která reprezentuje peníze na cestě klientovi. Ta se v přehledu Platby odečítá od částky ZaplatitKlientovi i Fond, protože platba již byla odeslána. Úhrada čeká ve formě peněz na cestě až do potvrzení platby bankovním výpisem. Stav financí objednávky ihned po odeslání platby je: ZaplatitKlientovi 0 ZaplatitCK 0 Fond 2 100 NaCesteKlientovi 15 000 Konečný stav účetního deníku po zaúčtování platby z bankovního výpisu je v tabulce 5.9. Zapsaná úhrada je systémem Helios spárována s úhradou reprezentující peníze na cestě klientovi a ty jsou tak vynulovány. Částka ZaplatitKlientovi i Fond tak vychází pouze z účetního deníku a stav financí je: ZaplatitKlientovi 0 ZaplatitCK 0 Fond 2 100 NaCesteKlientovi 0 Zakázka je tak opět vyrovnaná stejným způsobem, jako v případě bez faktury zaměstnavateli 091.

5.3

Změna provize po vystavení faktury

V některých případech se může stát, že dojde ke změně provize po její fakturaci. Tento případ může nastat z několika důvodů, mezi které patří například chybně vypočtená provize ze strany CK, změna ceny zájezdu (a tedy i provize určené jako procento z celkové ceny) nebo storno objednávky. Při stornu může být provize vynulována, nebo snížena podle provizní smlouvy na provizi ze storno poplatku. Ke změnám dochází zejména u objednávek fakturovaných s provizí hned, u kterých je faktura vystavena ještě před úplným uzavřením zájezdu. Případná změna v objednaných službách nebo cestujících osobách může mít vliv na výši provize. V každém případě je tento stav nutné podchytit a na případný rozdíl vystavit fakturu či dobropis. 4 Částka faktury byla upravena na 15 000 Kč, ale v úhradách je celkem 30 000 Kč – za platbu v hotovosti a úhrady převodem od klienta.


Sborník 068 068 yyy yyy 023 023 023 023 069 069 zzz zzz 062 zza zza zzb zzb 068 068 zza zza zzb zzb

Účet Má dáti Dal 315400 325400 211xxx 315400 325400 325100 325400 325100 800 801 325100 221xxx 602100 221xxx 315400 325100 221xxx 315400 325400 221xxx 315400 315400 221xxx

Částka 15 000 15 000 15 000 15 000 13 950 13 950 13 950 13 950 2 100 2 100 13 950 13 950 2 100 15 000 15 000 13 950 13 950 15 000 15 000 15 000 15 000 15 000 15 000

113

Popis Faktura 068, předpis ZaplatitKlientovi. Faktura 068, předpis faktur od CK. Pokladní doklad. Vyrovnání ZaplatitKlientovi pokladnou. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Faktura 023, vyrovnání očekávané částky. Faktura 023, předpis ZaplatitCK. Předpis provize. Předpis provize, vyrovnání dokladu. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Položka faktury 092, vyfakturovaná provize. Bankovní účet - přijatá platba. Vyrovnání ZaplatitKlientovi bank. výpisem. Vyrovnání ZaplatitCK bankovním převodem. Bankovní účet - odeslání platby. Faktura 091, předpis ZaplatitKlientovi. Faktura 091, předpis faktur od CK. Bankovní účet - úhrada faktury řady 091. Vyrovnání ZaplatitKlientovi bank. výpisem. Vyrovnání ZaplatitKlientovi bank. výpisem. Bankovní účet - odeslání platby.

Tabulka 5.9: Stav účtování zakázky po vrácení přeplatku klientovi

114 5.3.1

KAPITOLA 5. PŘÍPADOVÉ STUDIE Popis situace

Po vystavení faktury na provizi z prodeje zájezdu objednávky ID 321420, popsané v části 5.1, došlo k odhalení chyby ve vyčíslené provizi. Správná částka provize je 2 200 Kč, oproti původně fakturovaným 2 100 Kč. 5.3.2

Řešení

1. Oprava provize v CRM. Cestovní kancelář informuje společnost NetTravel o nové provizi a asistent zodpovědný za zápis faktur od CK opraví částku provize v CRM. Tato úprava spustí proceduru hsp_ZmenaStavu (viz 4.4.5.5), která jako svůj poslední krok provede úpravu zapsané provize pomocí hsp_ZapisProv. Upravená částka provize způsobí, že je objednávka zobrazena v přehledu nevyfakturovaných objednávek hvw_Nevyfakturovane (viz 4.4.7.4), zobrazeném pod soudečkem Nevyfakturované obj.. Zde je zobrazen řádek pro objednávku 321420 s provizí 2 200 Kč a již vyfakturovanou částkou 2 100 Kč. K fakturaci tedy zbývá 100 Kč. 2. Fakturace rozdílové částky. Uživatel systému Helios zodpovědný za fakturaci zájezdů si v přehledu Nevyfakturované obj. může klávesou Insert uživatelským označením vybrat konkrétní zakázky k fakturaci a vystavit na ně fakturu externí akci Fakturace provize CK vybraných zakázek. Ta spouští proceduru hsp_FakturaceProvize_CZ/SK s parametrem @TabName=„hvw_Nevyfakturovane“. Proces fakturace je popsán v části 4.4.7. V případě zakázky 321420 dojde ke spuštění obecné procedury hsp_FVPCastka_CZ/SK, která zajistí snížení částky k fakturaci o již vyfakturovanou část. Na položce faktury bude tedy pouze 100 Kč.

KAPITOLA 6. REALIZACE PROJEKTU

115

6 Realizace projektu Implementace projektu vychází ze zvolené struktury propojení (viz 4.4.1.1) a rozšíření, která umožňuje systém Helios. Některé problémy a komplikace nebylo možné předpovědět a objevily se až během realizace. V této části práce jsou popsány situace, které se vyskytly v pozdějších fázích projektu.

6.1

Implementace v jazyce SQL

Vzhledem ke zvolené struktuře propojení, založené na stored procedurách, je většina kódu celého propojení implementována v jazyce SQL. Ten s sebou přináší režim transakčního zpracování a pouze omezené možnosti řízení programu, přesto ale poskytuje dostatek nástrojů pro realizaci celého projektu. Komplexnější operace pracující s daty jsou v Heliosu také implementovány formou stored procedur na SQL serveru, což umožňuje transparentní pohled na metody, jakými s daty pracuje účetní systém. Celý projekt je vypracován jako zakázkové řešení pro jednu konkrétní společnost a nepočítá se s další distribucí a nasazením v jiných prostředích. Proto je kód závislý na struktuře databáze CRM, není psán obecně a ani neposkytuje žádné možnosti konfigurace. Např. řady faktur nebo čísla předkontací jsou specifické pro společnost NetTravel a jejich čísla byla zvolena účetním oddělením. Tam, kde to je možné se nastavení přebírá z tabulek Heliosu1 , aby se omezily nutné zásahy do aplikace. 6.1.1

Správa zdrojového kódu

Většina procedur existuje pro českou i slovenskou verzi Heliosu a liší se v použité databázi a nastavení konstant. Obě verze je nutné udržovat aktuální při jakékoliv změně. Jako postup pro správu kódu se osvědčila příprava první verze a následný převod do slovenské tímto postupem: 1. Náhrada textu „_cz_“ za „_sk_“ pro hromadnou změnu databáze z Helios_cz_001 na Helios_sk_001. 2. Náhrada textu „_CZ“ za „_SK“ pro hromadnou změnu spouštěných procedur z tohoto projektu. 3. Kontrola všech výskytů příkazu EXEC, zda odkazují na správné místo. 4. Porovnání všech konstant nové verze s původní procedurou. Typicky se liší tyto hodnoty: • Nastavení masky pro řadu 01*, která se liší od české 0*2. • Nastavení předkontací uvedených v kódu. • Hodnota prvního parametru procedury hsp_FVPIns_CZ/SK, který udává ID zboží skladu, a tedy typ položky faktury. • Jazyková verze textu pokladního dokladu nebo vystavované faktury. Pro zjednodušení správy je v kódu typicky vytvořena proměnná, jejíž hodnota se inicializuje na začátku procedury. Tento postup zjednodušuje následné dohledávání rozdílů mezi českou a slovenskou verzí. Správě verzí zdrojového kódu ani zálohám není potřeba věnovat pozornost. Celý kód, případně nastavení aplikace Helios, je uložen v databázi, která se pravidelně zálohuje. Součástí zálohy jsou tak i všechny části aplikace vytvořené v rámci tohoto projektu. Případnou obnovou zálohy tak lze získat úplný stav aplikace k vybranému dni. 1

Např. čísla předkontací pro účtování pokladních dokladů.

116 6.1.2

KAPITOLA 6. REALIZACE PROJEKTU Kritické sekce

Pro každou objednávku může být vystavena maximálně jedna vydaná faktura klientovi řady 068 a na základě tohoto pravidla jsou vytvořeny SQL dotazy ve všech částech systému. Zápis faktury klientovi zajišťuje procedura hsp_ZapisFaKli_CZ/SK, popsaná v části 4.4.5.6. Aby nedošlo k vytvoření více faktur, je v proceduře použita kritická sekce. Implementace kritické sekce je zajištěna systémovou procedurou sp_GetAppLock [3], která zajišťuje blokování duplicitního volání. Jako klíč pro vstup do sekce použit řetězec „hsp_ZapisFaKli_XXX“, kde XXX představuje ID objednávky. Prakticky se tak může v kritické sekci vyskytovat více transakcí současně, musí ale běžet pro různé objednávky. To zajišťuje jak dostatečnou propustnost procedury hsp_ZapisFaKli_CZ/SK pro celý systém, tak omezení vícenásobného vstupu pro jednu objednávku. Vstup do kritické sekce je v kódu ošetřen takto: SET @LockKey=’hsp_ZapisFaKli_’+CAST(@id_Objednavka AS VARCHAR) EXEC @LockRet=sp_GetAppLock @LockKey, ’Exclusive’, ’Transaction’, 10000 IF @LockRet<0 BEGIN ––0=OK, 1=Pockal a OK COMMIT RAISERROR 50000 ’hsp_ZapisFaKli_CZ: Chyba při zamykání ID’ RETURN END 1. Příprava klíče pro vstup do kritické sekce. Do proměnné @LockKey se uloží společný řetězec a ID objednávky. Klíč obsahuje i část názvu procedury, aby bylo v jiné části systému možné vytvořit další kritickou sekci omezenou podle ID objednávky. Pokud by bylo klíčem pouze ID, nebylo by možné vytvářet více nezávislých kritických sekcí. Klíč je uložen do proměnné, protože v parametrech příkazu EXEC lze uvést pouze název proměnné, nebo literál. 2. Vstup do kritické sekce procedurou systémovou sp_GetAppLock. Procedura je spuštěna s připraveným klíčem a v režimu „Exclusive“. Ten zajišťuje, že nikdo jiný nemůže do sekce s tímto klíčem vstoupit. Parametr „Transaction“ nastavuje, že zámek je vytvořen na úrovni transakce. Podmínkou tedy je uzamčení uvnitř otevřené transakce. Uvolnění zámku se v tomto případě nemusí provádět explicitním voláním procedury sp_ReleaseAppLock, ale stačí pouze ukončení transakce příkazem COMMIT, nebo ROLLBACK. Posledním vstupním parametrem je hodnota „10000“, která určuje timeout. Po tuto dobu se procedura pokusí počkat na uvolnění zámku v případě, že ho má jiná transakce. Číslo se udává v milisekundách, nastavená hodnota tedy odpovídá času 10 sekund. 3. Ověření návratové hodnoty. Návratová hodnota z volání je uložena do proměnné @LockRet. Záporná čísla signalizují chybu, nula nebo jedna označuje úspěšné otevření zámku. Číslo jedna uvádí, že byl vstup povolen až po čekání na uvolnění od jiné transakce. Nula znamená okamžité otevření kritické sekce bez čekání. Konkrétně v proceduře hsp_ZapisFaKli_CZ/SK nebyly před pokusem o vstup do sekce změněna žádná data, a proto je v případě výskytu chyby transakce ukončena příkazem COMMIT. Následně je vyvolána chyba a procedura ukončena.


6.2

117

Systém Helios

Analýza i realizace celého projektu vychází z možností rozšíření, které poskytuje systém Helios (viz 4.3). Zde jsou popsány komplikace, které vznikly při jejich použití. 6.2.1

Aktualizace

Součástí aplikace Helios a její licence jsou automatické aktualizace. Ty jsou vydávány přibližně v týdenních intervalech a umožňují aktualizovat celý systém. Součástí je aktualizace vlastní aplikace a jejích knihoven, tiskových formulářů i dalších funkcí systému, ale také struktury databáze. V důsledku aktualizace může dojít ke změně uložených procedur, tabulek i chování triggerů. Taková úprava by mohla mít vliv na funkci propojení s CRM. Vzhledem k počtu potenciálních rozšíření, která mají všechny společnosti využívající účetní systém Helios, je nepravděpodobné, že by došlo k zásadní změně struktury databáze, odebrání procedury, tabulky nebo sloupce. Případné přidání procedur, tabulek nebo sloupců do databáze nemá na tento projekt vliv. Jedinou výjimku tvoří změna předepsané struktury tabulky #TabDenikUcto. Ta je vytvářena při účtování v několika procedurách a v případě přidání sloupce je nutné tento nový sloupec přidat i do kódu. Procedura Heliosu hp_PrenesDenikUctoDoDeniku, přenášející data z dočasné tabulky do TabDenik, při nesprávném počtu sloupců způsobí chybu a doklad není zaúčtován. V případě změny struktury #TabDenikUcto je nutné provést opravu v těchto procedurách: • hsp_ZapisBankVypis_CZ/SK, • hsp_ZapisPlatbyHotove_CZ/SK, • hsp_ZauctovatFa_CZ/SK. 6.2.2

Obnovení databáze

Licence společnosti NetTravel na aplikaci Helios umožňuje použití jedné hlavní databáze a druhé jako záložní pro testovací účely, případně náhledu na data ze zálohy. Pro spuštění starší verze stačí obnovit zálohu databáze Helios_cz_001 do databáze pojmenované Helios_cz_002. V souvislosti s propojením CRM a účetního systému se na tuto obnovenou zálohu vztahují dvě omezení: 1. Externí triggery. Před prvním spuštěním Heliosu je nutné odstranit externí triggery et_TabDokladyZbozi a et_TabPokladna (viz 4.4.9). Ty by reagovaly na události v záložní databázi, ale příslušné operace by prováděly nad daty z ostré verze. Obnovená záloha je považována za testovací databázi a případné spuštění triggeru by mohlo způsobit změny dat ve špatné databázi. 2. Externí akce. Podobně jako triggery se v obnovené záloze nesmí používat externí akce. Ty spouští procedury z databáze CRM, které pracují s daty v produkční verzi databáze. 6.2.3

Externí akce

Nastavení externích akcí poskytuje dostatek prostředků pro realizaci všech požadovaných úkolů. Komplikace se vyskytla v nastavení externí akce pro přesun úhrady. Ta má jako vstupní parametr ID cílové faktury z tabulky TabDokladyZbozi, ke které má být úhrada přesunuta. Mezi

118


systémovými přehledy neexistuje žádný, který by zobrazoval přijaté i vydané faktury současně. Toto omezení je vyřešeno použitím dvou vstupních parametrů udávajích ID faktury. Jeden vybírá ID z přijatých, a druhý z vydaných faktur. Uvnitř procedury hsp_PresunUhrady_CZ/SK (viz 4.4.2) je pak ověřeno, že uživatel vyplnil pouze jednu z těchto hodnot. V opačném případě je vrácena chyba. Druhá situace, která vznikla při vytváření externích akcí, byla nutnost vytvořit externí akci typu „Přehled“, která by ale nebyla veřejná. To se týká akce zobrazení přehledu s výběrem fakturačního období a seznam CK k fakturaci (viz 4.4.7). Systém Helios neumožňuje v uživatelském rozhraní nastavit externí akci typu „Přehled“ jako neveřejnou. Lze to však zařídit ručním zásahem do tabulky TabExtKom, ve které jsou externí akce uloženy. U příslušných akcí je nastavena hodnota sloupce Verejna na nulu a akce se v uživatelském rozhraní nezobrazují. 6.2.4


Při vytváření definovaných přehledů se v systému vyskytla dvě omezení. Prvním byla nutnost používat datový typ DECIMAL(19, 6) namísto MONEY, a případné sloupce typu MONEY přetypovat. Zobrazení sloupce MONEY v přehledech způsobuje, že je za částku přidána ještě měna. Tato měna je ale přebrána z lokálního nastavení PC a ve slovenské verzi Heliosu se částky zobrazovaly s „Kč“. Druhým omezením je, že nelze použít sloupec s vlastnosti IDENTITY jako primární klíč přehledu, ze kterého je hodnota tohoto sloupce přenášena jako parametr do jiné externí akce. Definovaný přehled hvw_FakturacniObdobi, sloužící pro výběr období k fakturaci, zobrazuje řádky z tabulky FakturacniObdobi. Sloupec ID z této tabulky má vlastnost IDENTITY a je přenášen jako parametr externí akce spouštějící fakturaci. Proto se musí v definovaném přehledu přetypovat na sloupec typu integer, aby byla odstíněna vlastnost IDENTITY. 6.2.5

Externí triggery

Použití externích triggerů se chová odlišně, než samostatně spouštěné procedury. Kód je spouštěn uprostřed některé z operací Heliosu a platí zde další omezení. Při práci s triggerem je nutné ověřit, že nedojde ke koliznímu použití dočasné tabulky. Z pohledu tohoto projektu se jedná hlavně o tabulku #TabDenikUcto, která se používá při účtování dokladů. Prvním krokem účtování je vždy buď vytvoření nové, nebo odstranění všech řádků stávající tabulky. Pokud by proces Heliosu spoléhal na přítomnost dat v tabulce a uvnitř triggeru byla tato tabulka smazána, došlo by k vytvoření nekonzistentního stavu aplikace. Druhým omezením při práci s triggerem je problém se změněnou hodnotou systémové proměnné @@IDENTITY. Přidání nového řádku do libovolné tabulky s vlastností IDENTITY způsobí změnu této proměnné. Akce spouštěná z uživatelského rozhraní Heliosu tak může dostat nesprávnou hodnotu ID nově vytvořeného záznamu a systém Helios zobrazí chybovou zprávu „Nepodařilo se znovu načíst založený záznam“. Proto se na konci každého triggeru musí spouštět procedura hsp_RenewIdentity, která pomocí dočasné tabulky hodnotu systémové proměnné obnoví. Procedura má jeden vstupní parametr @ID a obsahuje tento kód: IF @@IDENTITY<>@ID BEGIN IF OBJECT_ID(’tempdb..#hsp_RenewIdentity’) IS NULL CREATE TABLE #hsp_RenewIdentity(ID INT IDENTITY(1, 1) PRIMARY KEY) ELSE TRUNCATE TABLE #hsp_RenewIdentity SET IDENTITY_INSERT #hsp_RenewIdentity ON INSERT INTO #hsp_RenewIdentity(ID) VALUES (@ID) SET IDENTITY_INSERT #hsp_RenewIdentity OFF DROP TABLE #hsp_RenewIdentity END


119

Došlo-li ke změně hodnoty @@IDENTITY, je vytvořena dočasná tabulka #hsp_RenewIdentity s jediným sloupcem ID, který má nastavenou vlastnost IDENTITY. Pokud tabulka již existuje, jsou pouze odstraněny její řádky. Poté je u tabulky povolena operace IDENTITY_INSERT, která umožňuje do sloupce ID hodnotu vložit, namísto implicitního přiřazení systémem. Příkazem INSERT je vložena původní hodnota, a tím je obnovena i systémová proměnná @@IDENTITY. 6.2.6

Pluginy

Při spuštění externí akce využívající plugin je systémem Helios volaný plugin zaregistrován mezi knihovny systému. Soubor DLL pluginu musí být umístěn v adresáři, ze kterého je Helios spouštěn a první spuštění na každém PC musí provést uživatel s právy administrátora, aby mohla být knihovna zaregistrována do systému.

6.3

Problémy související s měnou Euro

Běh účetního systému a jeho propojení na aplikaci CRM není závislý na měně, která se používá v daném státě. Problémy přináší až změna hlavní měny zavádějící nutnost ošetřit případný výskyt částek v původní měně. Po přechodu na měnu Euro je do systému Helios přidána řada omezení, která se vztahují na záznamy vytvořené před přechodem na novou měnu. Tohoto projektu se týkají pouze dvě omezení, která mají vliv na faktury uložené v tabulce TabDokladyZbozi. Po přechodu na Euro platí pro tuto tabulku mj. tato dvě omezení: 1. Nelze vytvářet doklady ve starém období. Naprostá většina faktur vystavovaných v souvislosti s prodejem zájezdů (řady 068, 023, 0*1, 0*6) se vystavuje vždy k aktuálnímu datu a tedy do aktuálního období. Omezení se tak na tyto faktury nevztahuje a problém vzniká pouze u faktur na provizi z prodeje zájezdů řady 0*2, resp. 01* na Slovensku. Faktury za prosinec se obecně vystavují až v lednu a nastavuje se u nich prosincové datum. Proto musí být tyto faktury vystaveny ještě v prosinci, nebo na začátku ledna, ještě před přechodem systému na novou měnu. Později už nelze faktury do starého období přidávat. 2. Nelze upravovat stávající doklady ve starém období. Trigger ht_DokModify systému Helios kontroluje u tabulky TabDokladyZbozi všechny změny provedené u faktur založených před převodem systému na novou měnu. Při pokusu o libovolnou úpravu faktury vyvolá chybu a znemožní tak provedení operace. Z tohoto důvodu nelze po přechodu na Euro zadávat čísla účtů klientům, jejichž faktura řady 068 byla vystavena ve starém období. Systém Helios nedovolí provést změnu organizace z obecného klienta na konkrétní organizaci podle ID objednávky. Tento problém lze obejít pouze dočasným zakázáním příslušného triggeru, které ovšem nelze provést ve stored proceduře. Proto je jediným řešením zaslat číslo účtu administrátorovi systému, který připraveným skriptem trigger zakáže, zapíše potřebné změny a činnost triggeru obnoví. Práce s triggerem představuje změnu chování databáze a musí být oddělena příkazem GO, který nelze použít uvnitř procedury. Šablona skriptu vypadá následovně: DISABLE TRIGGER ht_DokModify ON TabDokladyZbozi GO ... zápis čísla účtu klienta ... ENABLE TRIGGER ht_DokModify ON TabDokladyZbozi GO

120

6.4


Problémy s evidencí úhrad

Nejslabším článkem propojení CRM a účetního systému jsou úhrady faktur, uložené pro přijaté i vydané faktury v tabulce TabUhrady. Účetnictví obecně vychází téměř výhradně pouze ze stavu účetního deníku a evidence úhrad je pouze vedlejší funkce. Současně je jejich evidence a párování v režii účetního systému, bez možnosti hlubších zásahů. Rozšíření systému Helios realizované tímto projektem využívá úhrady faktur během kontrol při generování dávek a jako evidenci peněz na cestě (viz 4.4.6.3). 6.4.1

Automatické přiřazení úhrad bankovním výpisům

Prvním problémem, který se vyskytl při realizaci projektu, byla chyba v automatickém párování úhrad bankovních výpisů. U přijatých faktur jsou úhrady realizované odchozími platbami zapisovány s kladným znaménkem, stejně jako úhrady příchozích plateb k vydaným fakturám. Vrácení peněz, tedy platby opačným směrem, jsou pak zapisovány jako záporné. Při párování řádků bankovních výpisů na konkrétní faktury se systém choval odlišně při použití ručního a automatického přiřazení faktur. Odlišné chování se vyskytovalo v případě plateb opačným směrem, tj. v případě, že CK vrátila přeplatek společnosti NetTravel, nebo společnost NetTravel odeslala přeplatek klientovi. V obou těchto případech měla být úhrada zapsána se záporným znaménkem. 1. V případě ručního dohledání faktury byla úhrada zapsána správně se záporným znaménkem. 2. Při využití zabudované funkce automatického přiřazení faktur dohledal systém Helios k řádku bankovního výpisu příslušnou fakturu. Ve výše zmíněném případě ale úhradu zapsal vždy s kladným znaménkem. Tím se chybně navýšil součet úhrad faktury. Chybně zapsaná úhrada u přijaté faktury od CK nebyla pro systém významnou překážkou. Faktura byla již uhrazena v CK (jinak by nevzniknul přeplatek) a uměle vytvořený přeplatek proto nevadil. Pouze znemožňoval případné odeslání platby do CK v případě, že by se zvýšila částka faktury. Zásadní problémem byl chybný zápis úhrad u faktur řady 068. V případě vrácení přeplatku klientovi byla vytvořena úhrada z platebního příkazu při generování dávky. Ta byla procedurou hsp_Davka_CZ/SK zapsána se záporným znaménkem a reprezentovala peníze na cestě. V okamžiku chybného přiřazení úhrad příslušnému bankovnímu výpisu ale došlo zápisu úhrady s kladným znaménkem. Úhrada z bankovního výpisu se tak nespárovala s platebním příkazem a nedošlo k vynulování peněz na cestě. Z tohoto důvodu bylo nutné platební příkazy po zpracování bankovních výpisů odstraňovat. Tato chyba byla společností LCS International a.s. již opravena a v současné verzi Heliosu se nevyskytuje. 6.4.2

Párování úhrad platebních příkazů a bankovních výpisů

Druhým problémem, který se vyskytuje při běhu systému, je párování úhrad z platebních příkazů (tedy peněz na cestě) a úhrad z bankovních výpisů (potvrzení peněz na cestě). Toto párování zajišťuje trigger Heliosu ht_UhradyModify, který při změně v tabulce TabUhrady prochází záznamy konkrétní faktury a páruje řádky se stejnými hodnotami. Tento proces ale neobsahuje dostatečné množství kontrol a připouští chybné párování. Problém vzniká u vzorové situace, kdy společnost NetTravel odesílá do CK platby za přijatou fakturu řady 023 formou zálohy a doplatku. Obě tyto platby mají stejný VS i částku, liší se pouze dnem odeslání. Před odesláním doplatku dojde k odstranění prvního platebního příkazu. Všechny úhrady tak probíhají v těchto krocích:


121

1. Odeslání platby do CK vytvoří úhradu č. 1 z platebního příkazu, která reprezentuje peníze na cestě. 2. Následující den je zpracován bankovní výpis, který vytvoří odpovídající úhradu u stejné faktury. Zapsaná úhrada č. 2 je triggerem ht_UhradyModify spárována s úhradou č. 1, což způsobí korektní vynulování peněz na cestě. 3. Pozdější odstranění platebního příkazu odstraní také úhradu č. 1. Tato operace nemá žádný vliv na evidenci financí, pro evidenci úhrad faktury je významná pouze úhrada č. 2. 4. Odeslání doplatku do CK vytvoří úhradu č. 3 z platebního příkazu, která opět reprezentuje peníze na cestě. Při zápisu ale došlo ke změně v tabulce TabUhrady a je spuštěn trigger ht_UhradyModify. Nová úhrada má stejnou částku i další údaje jako první platba a dojde k chybnému spárování úhrady č. 3 a úhrady č. 2, protože trigger nekontroluje při svém běhu datum zápisu. U objednávky tak nejsou evidovány žádné peníze na cestě. Tento scénář způsobí, že čerstvě odeslaná platba není zahrnuta do peněz na cestě. Není proto odečtena ani z fondu objednávky, ani z hodnoty ZaplatitCK a objednávka vypadá jako připravená k úhradě. Ve stejný den tak může obsluha přehledu Platby platbu odeslat podruhé. Tento problém bude odhalen následující den, kdy budou na bankovním výpisu platby dvě a přeplatek bude evidován v hodnotě ZaplatitCK. Požadavek na opravu této situace byl odeslán společnosti LCS, která přislíbila jeho vyřešení v některé z příštích aktualizací systému Helios.

122

KAPITOLA 7. FÁZE PROJEKTU A TESTOVÁNÍ

7 Fáze projektu a testování Přenos evidence financí z CRM do účetního systému je složitá operace, která musí být provedena za chodu tak, aby nebyl ovlivněn ani pozastaven prodejní proces. Z toho důvodu nelze projekt připravit, otestovat několika testy podle případových studií a spustit v den D. Realizace celého projektu, testování a průběh spouštění musí být prováděn postupně tak, aby mohly být na živém provozu otestovány dílčí funkce systému, ověřena funkčnost navrženého řešení a proces neměl zásadní vliv na prodejce zájezdů. Před finálním přechodem na nový systém musí běžet původní i nová evidence financí v duálním režimu, který bude umožňovat v případě výskytu problému pozastavení projektu a nepřerušený chod prodeje podle původního systému. Z těchto důvodů je celý projekt rozdělen na dílčí fáze, které se navzájem překrývají. S ohledem na nutnost komplexního ověření funkčnosti celého projektu a odhalení chyb před finálním spuštěním nejsou jednotlivé fáze prováděny souběžně v českém i slovenském Heliosu současně. Nejdříve je vždy připravena plná verze pracující s českou databází. Na té jsou odladěny všechny problémy a její slovenský klon je vytvořen až po ověření funkčnosti.

7.1

Režim testování

Testování funkcí projektu neobsahuje žádné jednotkové, akceptační ani další průmyslově využívané testy. Ty nejsou použity s ohledem na strukturu celého projektu a omezené zdroje pro jeho vývoj. Během jednotlivých fází projektu a vývoje jsou průběžně testovány dílčí funkce systému. Před spuštěním duálního provozu jsou hlavním zdrojem testování všechny operace prováděné v ostré verzi CRM. Bez vědomosti prodejců je spuštěna verze CRM, která provádí sběr dat do testovací databáze a každá operace provedená v původním systému se tak přenese i do nového. Tato fáze byla důležitá z několika důvodů: • Odhalení implementačních problémů v samotné CRM aplikaci. • Otestování dílčích funkcí nového systému. • Simulace reálného běhu systému. • Možnost porovnání hodnot ZaplatitCK a ZaplatitKlientovi s původním systémem. Poslední jmenovaný bod umožňuje odhalení všech potenciálních problémů a jejich včasné ošetření. Každá prováděná operace má vliv na ZaplatitCK nebo ZaplatitKlientovi a porovnáním těchto sloupců mezi původním a novým systémem lze jednoduše objevit nesrovnalosti. Musí se pouze vzít v úvahu skutečnost, že platby jsou v Heliosu zapisovány až následující den po jejich realizaci při párování bankovních výpisů. Současně jsou při té příležitosti odhaleny všechny chyby ve stávajícím zaúčtování bankovních výpisů. Vyrovnáním hodnot každé objednávky je zajištěno, že jsou všechny platby přiřazeny příslušným objednávkám a je správně vybrán jeden z účtů 315400 a 325100 pro účtování.

7.2

Fáze projektu

Jak je popsáno výše, celý proces spouštění je prováděn za provozu a nesmí výrazně ovlivnit prodejní proces. Proto je projekt rozdělen do jednotlivých fází, které umožňují průběžné testování a ověřování funkčnosti navržených řešení. 7.2.1

Zkušební import dat do testovací DB

Úvodní fází projektu je zkušební import základních dat do účetnictví. Zatím neexistuje žádná z propojovacích procedur a pro import dat jsou vytvořeny samostatné skripty. Do testovací data-


123

báze Heliosu je přenesena většina dat z roku 2006 pro Českou republiku. Vzhledem k pracnosti importu a testovacím účelům nejsou přeneseny všechny druhy dokladů, ale pouze základní: • faktury klientům řady 068, • faktury od CK řady 023, • uplatnění poukazů, • platby klienta přímo do CK. Platby v hotovosti byly do účetnictví kvůli evidenci pokladen zapisovány průběžně ručně a není nutné je importovat. Rovněž nejsou importovány platby realizované převodem, protože ty jsou přítomné na bankovních výpisech zájezdových účtů. Součástí importu je pouze kontrola a případné přeúčtování chybně přiřazených účtů 315400 a 325100, rozlišujících platby klientů a cestovních kanceláří. Tento import slouží pouze pro ověření stěžejní části účtování a odhalení případných chyb na reálných datech. Neobsahuje přenos spropitného, zápis provize, ošetření poplatku za RezaPortal (viz 11) ani rozlišení faktur pro zaměstnavatele. Dalším účelem importu je průzkum databázové struktury Heliosu a příprava skriptů pro zápis faktur, účtování a další obecné operace. 7.2.2

Analýza a implementace

Na základě poznatků ze zkušebního importu, předpisu účtování od účetního oddělení a konzultace se společností LCS International a.s.[1] je připravena analýza a následná implementace celého projektu. Během této fáze jsou připraveny všechny stored procedury pro českou verzi Heliosu a příslušné rozcestníky. Ty, až do otestování české verze v reálném provozu, neobsahují odkazy na slovenské verze procedur. Implementace je napojena na testovací databází Helios_cz_002, do které jsou zapisovány výsledky dílčích testů nově vytvořených procedur. Průběh implementace je rozdělen na jednotlivé části podle prostředí, ve kterém jsou vytvářeny a lze je rozdělit do těchto oblastí: 1. Implementace SQL stored procedur. Základ aplikace tvoří stored procedury, které jsou spouštěny z aplikace CRM i externích akcí Heliosu. Externí akce spouštěné z uživatelských soudečků jsou zpravidla implementovány až po vytvoření přehledu, ze kterého jsou spouštěny. Procedury zpravidla odkazují na aktuální řádek přehledu, a proto musí při tvorbě procedury přehled již existovat. 2. Implementace pluginu NtHellPlugin. Implementace tohoto pluginu spočívá ve vytvoření COM knihovny a představuje samostatnou část vývoje (viz 4.3.5.4). Vytvoření musí předcházet nastavení externí akce, která funkce pluginu využívá. 3. Rozšíření funkcí Heliosu: Další samostatnou skupinou jsou změny prováděné v uživatelském rozhraní systému Helios, které vychází z možností rozšíření popsaných v části 4.3. Při realizaci tohoto projektu byly provedeny tyto operace: • vytvoření externích sloupců, • příprava definovaných přehledů, • vytvoření uživatelských soudečků,

124

KAPITOLA 7. FÁZE PROJEKTU A TESTOVÁNÍ • nastavení externích akcí.

4. Úprava aplikace CRM pro spolupráci s novým systémem Poslední částí je úprava samotné aplikace CRM. Ta má tři fáze, které se liší rozsahem implementace a režimem, ve kterém CRM pracuje. Popis jednotlivých fází je uveden níže, veřejně spuštěné verze CRM jsou tyto: • sběr dat do produkční databáze, • duální běh CRM, • finální přechod na nový systém. 7.2.3

Kontrolní import dat do testovací DB

Další fází je odstranění původní testovací databáze, její náhrada aktuální produkční verzí a nový import všech dat z roku 2007 podle evidence financí CRM. Ten slouží jako základ pro otestování sběru dat první veřejnou verzí aplikace CRM, pracující s propojením na účetní systém. Tento import přenáší úplný obraz financí za celý rok a lze na něm zkontrolovat všechna přípustná účtování a ověřit tak životaschopnost celého projektu. Současně slouží jako zkouška importu všech dat před jejich přenesením do ostré verze. Přenesení všech údajů umožňuje zkontrolovat stávající účtování všech pokladních dokladů a bankovních výpisů zájezdových účtů. Bankovní výpisy se před zahájením projektu účtovaly pouze na jeden účet a nebyly tak rozlišeny platby klientů a cestovních kanceláří. Součástí importu je také hromadné přeúčtování záznamů, které lze spárovat s platbami uloženými v tabulce Platby. Případné úpravy v zaúčtování dokladů musí být provedeny znovu po importu dat do produkční verze databáze. 7.2.4

Sběr dat v CRM do testovací DB

Následující fází je spuštění první verze CRM, která spolupracuje s propojením na účetní systém. V této verzi aplikace jsou implementovány pouze funkce pro zápis, které pro každou úpravu financí v původním systému spouští příslušnou proceduru a data tak zapisují i do nového systému. CRM neobsahuje žádné prvky uživatelského rozhraní využívající data z Heliosu a slouží pouze pro otestování sběru dat do účetnictví. Prodejci o této verzi nejsou informováni a není změněno ani chování aplikace. V případě výskytu kritické chyby lze spustit předchozí verzi aplikace CRM a prodejní proces může pokračovat bez přerušení. V tomto režimu je hlavním zdrojem finančních informací stále původní systém a zápis dat do databáze Heliosu slouží pouze pro vytvoření konzistentního obrazu financí. Ten slouží pro otestování celého propojení a ověření správnosti účtování všech záznamů. Sběr provozních dat současně umožňuje otestovat propojení z hlediska výkonu a propustnosti. 7.2.5

Import a sběr dat do produkční DB

V listopadu roku 2007 jsou zopakovány předchozí dvě fáze pro ostrou verzi databáze. Prakticky to představuje nový import všech dat na základě stávajících informací v databázi CRM a úpravu všech procedur, ve kterých je nahrazena odkazovaná databáze Helios_cz_002 na produkční Helios_cz_001. Tento přechod lze udělat na serveru bez nutnosti zveřejnění nové verze aplikace CRM. Ta běží nadále v nezměněné podobě a stejném režimu jako doposud. Realizací této fáze jsou zahájeny opravy stávajících bankovních výpisů, které nejsou svým účtováním rozděleny na platby klientů a cestovních kanceláří. Přenos všech informací z databáze CRM a běh aktuální verze CRM aplikace udržuje v Heliosu aktuální obraz financí. Ten lze na


125

základě porovnání klíčových hodnot ZaplatitCK a ZaplatitKlientovi s původním systémem zkontrolovat a opravit všechny nesrovnalosti jak v účtování stávajících dokladů, tak případný výskyt problému v novém systému. V lednu roku 2008 je po provedení všech oprav a otestování spuštěné části propojení provedena stejná operace pro slovenskou část systému. Jsou vytvořeny příslušné kopie stored procedur, upraveny rozcestníky, aby tyto kopie byly spouštěny, a proveden import dat z roku 2007. Opoždění této části projektu způsobilo pozdní zakoupení a dodání rozšiřující licence na slovenskou verzi Heliosu umožňující práci více uživatelů a doplňující chybějící moduly potřebné pro rozšíření uživatelského rozhraní. 7.2.6

Duální běh CRM

Na konci ledna 2008 byla zveřejněna nová verze CRM, která obsahovala duální režim. Ten, kromě funkcí pro zápis, implementoval i všechny funkce pro čtení. Primárním zdrojem informací je nový systém a v CRM jsou k dispozici všechny nástroje, pro úplnou správu financí v novém systému. Ty nově zahrnují zobrazení historie plateb podle účetního deníku, práci s fakturami pro zaměstnavatele i tisk pokladních dokladů na základě informací v Heliosu. Duální běh stále zapisuje všechny operace i do tabulek původního systému a v případě výskytu kritické chyby tak umožňuje přechod zpět na předchozí verzi. Tato fáze slouží jako zkušební období pro ostrý provoz celého systému a nepředpokládá návrat k původnímu. 7.2.7

Duální běh Platby.mdb a přehledu Platby v Heliosu

Po spuštění duálního režimu CRM bylo zahájeno testování a duální běh přehledu Platby v Heliosu, který nahrazuje stávající aplikaci Platby.mdb. Zpočátku jsou dávky generovány v obou systémech pro stejné skupiny objednávek a porovnáván jejich výsledek. Později generování dávky v Heliosu vytváří kopii vytvořeného platebního příkazu v tabulce Platby_Davky a Platby. Tyto kopie umožňují, stejně jako duální běh CRM, přechod zpět na původní systém s úplnou evidencí odeslaných plateb. 7.2.8

Zrušení duálního běhu aplikace Platby.mdb

V květnu 2008 byl ukončen duální režim a zakázáno generování dávek pro český systém v aplikaci Platby.mdb. Toto je první krok k odstavení původního systému a představuje první operaci, kterou nelze rychle vrátit zpět a přejít tak na původní systém. Každá nová dávka vygenerovaná v české části systému by se musela obnovit na základě informací na bankovním výpisu. Po tomto finálním spuštění české verze plateb je spuštěno testování slovenské části v duálním režimu, který je ukončen spolu s finálním přechodem na nový systém. 7.2.9

Finální přechod na nový systém

Poslední fází přechodu na evidenci financí v účetním systému Helios je zveřejnění nové verze CRM bez podpory původního systému, provedené v červenci 2008. Tento přechod byl proveden uprostřed hlavní sezóny a nezpůsobil žádné narušení prodejního procesu. Vzhledem k provázanosti aplikace CRM na původní systém a stávající struktuře databáze CRM nemůže být odstavení původního systému provedeno jednorázově. Spuštěná verze CRM sice nepočítá se strukturou původního systému, ta ale ještě zůstává v databázi obsahující sloupce, přehledy a triggery používané výhradně původním systémem. Z tohoto důvodu je odstranění těchto prvků z databáze provedeno v poslední části úprav provedených až po spuštění odpovídající verze CRM.

126 7.2.10

KAPITOLA 7. FÁZE PROJEKTU A TESTOVÁNÍ Spuštění verze s podporou měny Euro

Jediný širší zásah do struktury nového systému po jeho spuštění představuje přechod na měnu Euro na Slovensku. Tyto úpravy byly prováděny až po převodu účetnictví na novou měnu, aby mohly být zohledněny všechny změny realizované ve struktuře a chování Heliosu. Pro ten představuje změna hlavní měny složitý proces, při kterém je provedeno uzavření období a dokladů ve většině modulů. Kromě doplnění obecných procedur pracujících s měnou Euro bylo upraveno chování všech procedur a přehledů tak, aby zohledňovaly možný výskyt dokladů v jiné měně.

KAPITOLA 8. ZÁVĚR

127

8 Závěr Účelem mé diplomové práce bylo analyzovat evidenci financí ve stávající aplikaci CRM a na jejím základě navrhnout a implementovat přenos všech souvisejících funkcí do účetního systému Helios. Současně měl projekt zajistit automatizaci všech účetních procesů souvisejících s prodejem zájezdů. Realizované propojení aplikace CRM a účetnictví přenáší veškeré funkce související s evidencí financí do účetnictví, zavádí pravidla pro účtování všech operací a realizuje jejich automatizaci. Jediným úložištěm stavu financí je v novém systému databáze Heliosu, což umožňuje úplné odstavení původní evidence. Propojení obou systémů je implementováno v jazyce SQL formou stored procedur, které zajišťují všechny operace pro čtení i zápis. Mezi automatizované operace patří např. vystavování faktur klientům, pokladních dokladů, účtování všech druhů dokladů nebo správa a fakturace dárkových poukazů. Práce rovněž přenáší hromadné vystavování a tisk faktur na provizi z prodeje zájezdů z aplikace CRM_Finance.mdb do prostředí účetního systému. Správa financí v účetním systému založená na účtování všech operací zavádí do aplikace řadu kontrolních mechanismů, které vychází ze základních principů účetnictví. Dále je důraz kladen na kontrolu odchozích plateb při generování platebních příkazů, aby nedocházelo k chybnému odesílání plateb. S tím souvisí také varovné obarvování řádků v přehledu Platby a kontrola faktur od CK zajišťující, že předpis částky k odeslání cestovním kancelářím nebude převyšovat cenu zájezdu. Zásadní reimplementací prošla aplikace Platby.mdb, která realizovala generování odchozích plateb a příslušných platebních příkazů. Její funkce byly kompletně přeneseny do uživatelského rozhraní aplikace Helios a pro zajištění tohoto úkolu byla využita téměř všechna zákaznická rozšíření, která systém Helios umožňuje. V novém systému bylo odstraněno omezení maximálního počtu uživatelů aplikace Platby.mdb a také výkonnostní problémy původní aplikace, založené na technologii MS Access, s velkým počtem záznamů. Integrace finančního provozu CRM do účetního systému splňuje všechny požadavky ze zadání a poskytuje úplnou finanční podporu prodeje zájezdů. Finální spuštění bylo provedeno v průběhu hlavní sezóny v červenci 2008 a odstavení původního systému se obešlo bez narušení prodejního procesu. Během hlavní sezóny spravoval systém obrat společnosti v řádu milionů korun denně a stabilně běží již rok. Součástí mé diplomové práce je jak vysvětlení funkcí původního systému, tak analýza jejich nové realizace, popis možných rozšíření účetního systému Helios a řešení situací, které se vyskytly v průběhu celého projektu. Navržený systém není vzhledem ke specifické struktuře cestovní agentury univerzálně přenosný na jiné společnosti, ale jeho části a základní principy lze využít při implementaci jiných projektů spolupracujících s účetním systémem Helios.

128

KAPITOLA 8. ZÁVĚR

KAPITOLA 9. LITERATURA

129

9 Literatura [1] LCS International, a.s., Jana Křapková, senior konzultant Helios Orange: konzultace dne 9.5.2007. [2] Technické informace o systému Helios http://extra.lcs.cz/helios/zajimavosti/ [3] MSDN: sp_getapplock (Transact-SQL) http://msdn.microsoft.com/en-us/library/ms189823.aspx [4] Informace o měně Euro a související legislativě na Slovensku http://www.euromena.sk/

130

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

A Seznam použitých zkratek ASP.NET Prostředí založené na platformě .NET Framework pro vývoj webových aplikací BV Bankovní výpis DB Data Base, databáze CA Cestovní agentura CK Cestovní kanceláře COM Common Object Model CRM Customer Relationship Management CZ Označení českých částí systému DIČ Daňové Identifikační Číslo DLL Dynamic Linked Library, přípona souborů DPH Daň z Přidané Hodnoty DSP Data Service Provider, webová aplikace zajišťující datovou komunikaci CRM DUZP Datum uskutečnění zdanitelného plnění ERP Enterprise Resource Planning, informační systém EU Evropsá Unie IČ Identifikační Číslo (dříve označované jako IČO) ID IDentification, jednoznačný číselný identifikátor IIS Internet Information Service, webový server systému Windows IMAP Internet Message Access Protocol MDB Microsoft DataBase, přípona souborů aplikace MS Access MS Microsoft NT NetTravel – zadavatel projektu NTLM NT LAN Manager, síťový autorizační protokol MS Windows PDF Portable Document Format, přípona souborů dokumentů v elektronické podobě ODBC Open Database Communication, komunikační protokol mezi aplikacemi MS Access a SQL databází PC Personal Computer, počítač SK Označení slovenských částí systému SMS Krátká textová zpráva SP Stored Procedure, uložena procedura v SQL databázi

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK SW SoftWare SQL Structured Query Language VS Variabilní symbol

131

132

PŘÍLOHA B. OBSAH PŘILOŽENÉHO CD

B Obsah přiloženého CD Index.html - Úvodní stránka. ReadMe.txt - Popis adresářů, poznámky k instalaci. SRC/ - Zdrojové kódy aplikace a export rozšíření systému Helios. Text/ - Tento dokument včetně zdrojových kódů.

Integrace finančního provozu CRM a účetního systému. Bc. Pavel Mikula

Recommend Documents