Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta
Elektronický obchod Bakalářská práce
Vedoucí práce: Ing. Hana Netrefová
Bohumil Přecechtěl
Brno 2004
Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně s použitím literatury, kterou uvádím v seznamu.
V Brně dne 21. května 2004
....................................................
Děkuji paní Ing. Haně Netrefové za odborné vedení, cenné rady a metodickou pomoc při tvorbě této bakalářské práce.
4
Abstract Přecechtěl, B. Electronic shop. Bachelor thesis. Brno, 2004. This text is oriented to current trends of electronic shop aplications development. It is aimed to understanding main e-shop types, positives and negatives. The example of correct e-shop structure is presented.
Abstrakt Přecechtěl, B. Elektronický obchod. Bakalářská práce. Brno, 2004. Práce se zabývá současnými tendy ve vývoji elektronického obchodu. Zamýšlí se nad klady a zápory a navrhuje správnou strukturu systému elektronického obchodu.
5
OBSAH
Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 7 7
2 Současný stav 2.1 Obyčejný elektronický obchod . . . . . . . . . . . . . . . . . . . . . . 2.2 Modulární elektronický obchod . . . . . . . . . . . . . . . . . . . . .
9 9 9
3 Problematika elektronických obchodů
11
4 Co je třeba ke zřízení elektronického obchodu
13
5 Typy elektronických obchodů 5.1 Manuální editace . . . . . . 5.2 Editace přes program . . . . 5.3 Předgenerované stránky . . 5.4 Přímé spojení . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
14 14 14 15 15
6 Náležitosti a struktura elektronického obchodu 6.1 Různé vlastnosti zboží . . . . . . . . . . . . . . 6.2 Slevy . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Zpracování objednávky . . . . . . . . . . . . . . 6.4 Rychlost . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Technologická základna . . . . . . . . . . 6.4.2 Složitost aplikace a kvalita řešení . . . . 6.5 Platby, doprava, splátkový prodej . . . . . . . . 6.6 Elektronické platby . . . . . . . . . . . . . . . . 6.7 Zajímavý vzhled . . . . . . . . . . . . . . . . . 6.7.1 Manuální úprava stránek . . . . . . . . . 6.7.2 Volba barevného schématu . . . . . . . . 6.7.3 Šablony . . . . . . . . . . . . . . . . . . 6.8 Jazyky a měny . . . . . . . . . . . . . . . . . . 6.9 Podpora prodeje . . . . . . . . . . . . . . . . . 6.10 Statistika . . . . . . . . . . . . . . . . . . . . . 6.11 Propojení s partnery . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
17 17 17 18 18 18 18 19 19 19 20 20 20 20 20 21 21
7 Právní stránka věci 7.1 Správa dat . . . . . . . . . . . 7.2 Informační povinnost . . . . . 7.3 Ochrana dat dle § 13 . . . . . 7.4 Oznamovací povinnost dle § 16 7.5 Shrnutí . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
22 22 22 24 24 24
. . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . .
. . . . .
. . . . .
6
OBSAH
8 Shrnutí technologií používaných pro elektronické obchody 8.1 Databázový systém . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Strana serveru . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Programy CGI . . . . . . . . . . . . . . . . . . . . . 8.2.2 Dynamické HTML . . . . . . . . . . . . . . . . . . . 8.3 Programovací jazyky na straně serveru . . . . . . . . . . . . 8.3.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Strana klienta . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.2 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.3 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.4 Kaskádové styly . . . . . . . . . . . . . . . . . . . . . 8.4.5 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . 9 Doporučení při vývoji elektronického obchodu 9.1 Volba hostingového serveru a datové základny . 9.2 Vzhled aplikace . . . . . . . . . . . . . . . . . . 9.3 Návrh a realizace systému . . . . . . . . . . . . 9.4 Vyhledávání . . . . . . . . . . . . . . . . . . . . 9.5 Katalog . . . . . . . . . . . . . . . . . . . . . . 9.6 Nákupní košík . . . . . . . . . . . . . . . . . . . 9.7 Administrace . . . . . . . . . . . . . . . . . . . 9.8 Testování . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . . . . . . . .
25 25 26 27 27 27 28 28 28 28 29 29 30 30 30
. . . . . . . .
32 32 32 33 34 34 34 35 35
10 Závěr
36
11 Literatura
37
1
ÚVOD A CÍL PRÁCE
1
7
Úvod a cíl práce
1.1
Úvod do problematiky
V dnešní době, kdy se Internet rozmáhá obrovskou rychlostí, se objevuje stále více elektronických obchodů, tzv. „e-shopůÿ. Každý je svým způsobem jiný, ale všechny mají jedno společné. Snaží se nalákat zákazníka a přinutit jej, aby nakupoval právě tady. Tyto obchody tvoří většinou tvoří programátoři a grafici podle požadavků zadávajícího obchodníka. Je pochopitelné, že pro zdárné dokončení aplikace musí celý tým spolupracovat a navzájem se usměrňovat v návrzích, aby mohl vzniknout kvalitní elektronický obchod, který bude lákat zákazníky k nakupování, nejen pomocí pěkného designu, ale i správnou funkčností. V praxi však dochází k rozporu mezi nápady obchodníka, neznalého možností programovacího jazyka, a programátora. Proto by měl schopný programátor umět vysvětlit pomocí laických výrazů obchodníkovi co lze či nelze provést. Sledujeme-li literaturu, kterou lze v současnosti koupit a která se týká problematiky elektronických obchodů, zjistíme, že taková literatura v podstatě neexistuje. Problematika je rozprostřena do několika publikací zabývajících se nakupováním na Internetu, které však spíše slouží běžným uživatelům. Pro designéra by mělo být samozřejmostí alespoň zběžně rozumět tvorbě webovských stránek (Špaček, 2003) a pro programátora, kromě použitého programovacího jazyka, ovládat standard HTML1 (Dellwig, 2003) a CSS2 (Staníček, 2003). Na Internetu lze najít mnoho elektronických obchodů, ale troufám si říct, že jen málo z nich je opravdu kvalitních. Mnohdy se setkávám s nedostatky po právní i bezpečnostní stránce, což dělá obchod méně důvěryhodný. Z těchto důvodů se v České republice vyskytují obavy z nakupování v elektronických obchodech. Přesto se je ale vyplatí provozovat, protože zákazník v něm sice nakoupí jen zřídka, ale má možnost si výrobek „osahatÿ a poté si jej osobně zakoupit přímo u firmy. Doufám, že se vstupem do Evropské unie se přístup lidí zlepší a že časem vymizí neustálá obava o ztrátu soukromí při registracích v e-shopech.
1.2
Cíl práce
V současnosti sice na trhu existuje několik publikací, které popisují elektronický obchod, ale žádná z nich neobsahuje kompletní přehled. Většinou se jen specializují na způsoby platby, manipulaci s osobními údaji nebo popisují známé elektronické obchody. Problémem také je, že tyto publikace nevycházejí z praktických zkušeností a opomíjejí lidský faktor. Autorům elektronických obchodů se tak nedostává literatury, která by shrnula nezbytné základní prvky. Cílem tohoto textu je shrnout problematiku elektronických obchodů, popsat jejich náležitosti a funkce. Účelem není zmínit všechny prvky, které elektronický 1 2
HyperText Markup Language Cascading Style Sheets
1.2
Cíl práce
8
obchod obsahuje, protože jejich množství záleží jen na potřebách a možnostech autorů, ale zdůraznit ty nejčastější. Pokusím se nastínit nejzákladnější pravidla, jež je nutné dodržovat a tím odstranit nejčastější chyby, jichž se dopouštějí autoři těchto aplikací. Dále vysvětlím, co vlastně Internetový obchod je, co je potřeba k jeho zařízení, jak by měl vypadat, co by měl obsahovat a upozorním na chyby a nedostatky v řešení. Vzhledem k tomu, že pro chod aplikace je důležité správně zvolit programovací jazyk a datovou základnu, rozhodl jsem se také vyjmenovat základní typy, které nabízí běžný hostingový server a doporučit vhodnou možnost ze své vlastní zkušenosti.
2
SOUČASNÝ STAV
2
9
Současný stav
V současné době lze na Internetu rozlišit dva nejzákladnější typy elektronických obchodů. Rozhodl jsem se popsat jejich vlastnosti a zaměřit se na výčet kladů a záporů, abych objasnil jejich rozdílné využití.
2.1
Obyčejný elektronický obchod
Tento obchod se na Internetu vyskytuje nejčastěji. Je tvořen pro každého zákazníka zvlášť, protože obsahuje jedinečné požadavky. Pro celý tým, který tuto aplikaci vytváří, je nutné se dopředu dohodnout s obchodníkem na všech kritériích, které bude od aplikace očekávat. Poté lze navrhrnout optimální datovou základnu, použitý programovací jazyk nebo administrační nástroj. Po zhotovení obchodník získá celou aplikaci, kterou umístí na server, na kterém hostuje. Klady: • řešení na míru, • obchodník získá celou aplikaci, • unikátní design i funkce, • osobité provedení, • vyhledávání podle nestandardních kritérií. Zápory: • vyšší cena, • náklady za hosting, • v ceně není zahrnuta programová aktualizace, • zastarání aplikace.
2.2
Modulární elektronický obchod
Vzhledem k vysokým nákladům na předešlý typ vznikl druh elektronického obchodu, který obchodníkovi nabízí levnou a plně funkční variantu. Tato varianta je umístěna na serveru a obchodník si kupuje jen právo ji využívat. Navíc tým programátorů neustále aplikaci upravuje a přidává různá vylepšení. Obchodník tak ušetří náklady za hosting a získá plně funkční aplikaci, kterou může vzhledově upravit pomocí šablon a funkčně pomocí povolení jednotlivých prvků. Pro programátory je tvorba aplikace velmi obtížná, protože musí počítat s širokou škálou požadavků. Výsledkem je množství elektronických prodejen, které různě vypadají, podobně fungují, a které obsluhuje jeden script. Klady: • žádné náklady za hosting, • programová aktualizace, • šablony.
2.2
Modulární elektronický obchod
10
Zápory: • obchodník získá jen právo užívat aplikaci, • doménová adresa obchodu je odvozena od doménového jména poskytovatele aplikace, • nelze uskutečnit některé nadstandardní požadavky.
3
PROBLEMATIKA ELEKTRONICKÝCH OBCHODŮ
3
11
Problematika elektronických obchodů
Elektronický obchod zahrnuje produkci, reklamu, prodej a distribuci produktů prostřednictvím telekomunikačních sítí. Není to fenomén, který by přicházel až v současné době, protože je do něj možno zahrnout i starší technologie jako telefon, fax a televizi, dále relativně jednoduché aplikace jako elektronické platby a systémy elektronických finančních převodů či elektronickou výměnu dat (Electronic Data Interchange). Až v souvislosti s použitím Internetu se však používá v poněkud užším smyslu vzhledem k zcela nových možnostem. Patří sem zejména interaktivní komunikace na různě strukturovaných kanálech (zahrnujících např. různé počty příjemců sdělení), která není omezena časem či místem, probíhá v multimediálním prostředí (zvuk, obraz a text). Vše je také doprovázeno velmi nízkými náklady (případně náklady, které hradí koncový uživatel – negativním projevem toho je však hromadné rozesílání nevyžádané reklamní pošty, tzv. spamming, který se stává vážným praktickým problémem). Internet rozšířil možnosti elektronické výměny dokumentů (EDI), protože umožnil participaci subjektů, které jsou mimo speciálně vyčleněné sítě. Snižuje se cena za obchodní transakci, to přispívá ke snižování nákladů na vstup na nový trh a tak prospívá zejména malým a středním podnikům. Obecná dostupnost účastníků Internetu usnadňuje reklamu a soutěž jak v domácím, tak i mezinárodním měřítku, což zvyšuje možnost výběru, kvalitu a snižuje cenu. Tam, kde je produkt digitalizovatelný (zejména software, cestovní služby, zábava a finance), dochází k vymizení nákladů na dopravu a zejména malé společnosti či společnosti z chudších zemí mají větší možnosti volby místa produkce nezávisle na umístění svých zákazníků. Praktické zkušenosti s obchody na Internetu v České republice ukazují srovnatelnou dynamiku, jaká je udávána z rozvinutějšího světa tj. 30% meziměsíční nárůst, což odpovídá předpokladu 200% nárůstu během jednoho roku, který je pravděpodobně sám limitován rychlostí připojení na síť. Průměrné nákupy činí 150–500 Kč3 , jejich hodnota postupně roste a prodávají se tak již např. i televize či videa v ceně přes 10 000 Kč (přes 60 nakupujících během prvních pěti měsíců provozu s obratem přes 300 000 Kč). V oblasti elektronické reklamy lze vypozorovat u menších firem, které umístění elektronické reklamy nabízejí, růst celkového obratu z 2–3 milionů Kč v roce 1997 na předpokládaných 11–14 milionů korun v roce 2004. V červnu 1997 byl uveden do zkušebního provozu standard pro platby přes elektronické sítě SET (Secure Electronic Transactions), který vyvinuly dvě hlavní společnosti vydávající kreditní karty a několik firem z oblasti informačních technologií a telekomunikací, kdy předávání čísel platebních karet probíhá dokonce bez toho, aby je v otevřeném tvaru mohl vidět prodejce. Spolu se zaváděním digitálních podpisů, metod ověřování autenticity zpráv a obecnou dostupností šifrovacích metod a kryptografických protokolů se tak vytváří bezpečné a verifikaceschopné prostředí pro elektronické transakce. 3
údaj ze společnosti FreeGSM Team s. r. o.
3
PROBLEMATIKA ELEKTRONICKÝCH OBCHODŮ
12
Česká republika je jednou ze čtyř zemí, kde probíhá pilotní implementace systému SET. To by mělo v budoucnu kompenzovat problémy, které jsou u nás s platbami platebními kartami bez fyzického podpisu zákazníka (tj. přes telefon nebo Internet). Konzultační firma Datamonitor odhaduje současnou velikost trhu zabezpečujícího infrastrukturu používání veřejných klíčů a jejich certifikací na 60 milionů dolarů, zatím převážně v USA a Kanadě. Od roku 1997 došlo k nárůstu na zhruba 750 milionů dolarů jak v Evropě, tak i v USA a v globálním měřítku se jednalo o objem 1,9 miliardy dolarů. Toto souvisí jednak s celkovým rozvojem elektronického obchodu a jednak s tím, že roste zájem o prostředí zabezpečující soukromí a nastolující důvěru. Komise UNCITRAL Spojených národů vypracovala a v roce 1996 schválila Vzorový zákon o elektronickém obchodu, který by zemím bez legislativy v této oblasti měl napomoci při používání elektronických transakcí a alternativních možností ke komunikaci a ukládání informací v jiné formě než na papíru. Členským státům OSN bylo doporučeno tento Vzorový zákon vzít v potaz při tvorbě nových zákonů nebo revizi stávajících, a zajistit tak nejen změnu svých právních norem tímto směrem, ale též harmonizaci mezinárodních hospodářských vztahů s ohledem na využívání nových technologií. Zákon o elektronickém obchodu má sousední Německo. Spojené státy vyvíjejí velkou mezinárodní iniciativu na obecné přijímání takových norem a získaly již souhlas či podporu ekonomicky nejvýznamnějších zemí světa (Zlatuška, 1998). V České republice v této oblasti chybí prakticky jakékoli použitelné právní zázemí, což se týká zejména: • elektronických dokumentů (objednávky, faktury, platební příkazy, smlouvy), které by měly být postaveny na roveň papírovým, • uzavírání závazkových vztahů prostřednictvím Internetu a jiných telekomunikačních služeb (zakotvení duality pro vznik, určitost, platnost a dokazatelnost závazkových vztahů uzavřených přes Internet a řešení problémů teritoriality), • daňových aspektů při obchodování pomocí Internetu (DPH a srážkové daně, místo poskytnutí služby, celní předpisy, průkaznost z hlediska účetních a daňových předpisů), • bezpečnosti obchodování prostřednictvím Internetu (certifikace zabezpečujících zařízení v privátním sektoru, zákon o digitálním podpisu a ceritifkačních autoritách veřejných klíčů). Využití Internetu pro elektronický obchod je tak u nás stále omezeno především na reklamu a zprostředkování katalogů než na vlastní provádění transakcí.
4
CO JE TŘEBA KE ZŘÍZENÍ ELEKTRONICKÉHO OBCHODU
4
13
Co je třeba ke zřízení elektronického obchodu
Nejdůležitější věcí, která je potřeba pro zřízení elektronického obchodu je odhodlání investovat svůj čas a prostředky do vývoje nového elektronického oddělení firmy. Na variantu, že obchodník „nasypeÿ na Internet přehled svého zboží a bude za čas v prodeji úspěšný, se spoléhat nedá. Už nyní je na Internetu vzrůstající množství elektrotechnicky zaměřených e-obchodů, takže se začíná formovat konkurence dodavatelů i na Internetu. Přičemž vůbec nemusí být přímá úměra mezi velikostí kamenného obchodu a jeho elektronického bratříčka. Pořizovací cena e-obchodu se pohybuje v desítkách tisíc, přičemž netvrdím, že čím dražší, tím lepší, ale když je levný nestojí za nic. Je přímo nutné takovému obchodu vyhradit pracovníka, nebo pracovníky, podle velikosti a složitosti. Spoléhat se na to, že e-obchod povede správce sítě, který rozumí systémům, programování, databázím, grafice atd. není nejšťastnější. Obvykle má své práce dost a navíc není obchodník. E-obchod musí být souhra grafika, programátora, zásobovače a obchodníka. Prakticky je nutné, aby každý ve firmě zastával svou funkci ještě elektronicky v e-obchodu. Např. obchodník v terénu nabídne a vysvětlí také variantu e-obchodu, skladník vychystá objednané zboží, fakturantka vystaví doklad apod. Další důležitou investicí je reklama na eobchod. Každý e-obchod, pokud má být úspěšný, si určitě zaslouží a také vynutí hodně propagace. Samozřejmě každá skupina má většinou odlišnou cílovou skupinu zákazníků a od toho se odvíjí typ serverů vhodných na propagaci. V dnešní době se také můžeme na různých stránkách setkat s reklamními proužky – bannery, které lze zobrazovat za peníze nebo jako výměnnou reklamu4 .
4
http://www.billboard.cz
5
TYPY ELEKTRONICKÝCH OBCHODŮ
5
14
Typy elektronických obchodů
Webové stránky elektronické prodejny by měly být umístěny na výkonném serveru připojeném linkou s dobrou propustností. V mnoha případech proto není vhodné, aby byl tento server součástí vaší firemní počítačové sítě. Tím ale vzniká problém, jak data v prodejně, umístěné na serveru, aktualizovat daty, které máte ve skladě ve vnitřní počítačové síti. Proto rozlišujeme několik typů elektronických obchodů, které jsem rozdělil podle způsobu editace položek zboží.
5.1
Manuální editace
Mezi nejjednodušší patří manuální editace zboží z administrátorských stránek prodejny, tj. přímo na Internetu, nebo nahráním textového, případně databázového souboru se zbožím na server přes FTP a spuštěním aktualizace serverové databáze. Tento způsob je nejrozšířenější, protože pro programátora představuje nejmenší práci. Stačí udělat jednoduchou administrační aplikaci. Klady: • snadná obsluha, • programová jednoduchost. Zápory: • časová náročnost připojení k Internetu (v případě úprav na Internetu), • náročná manuální úprava katalogu, • nelze vytvářet složitější struktury nebo závislosti mezi položkami katalogu, • obtížně realizovatelná správa zákazníků a objednávek (z tohoto důvodu často chybí), • vhodné pro prodejny s maximálně několika desítkami až stovkou položek v katalogu.
5.2
Editace přes program
Pokročilejší systémy nabízejí k aktualizaci zboží program pro osobní počítač, ve kterém je obsah ceníku upravován offline a dávkově ho odesíláte přímo z prostředí programu. Tyto systémy jsou často propojeny s ekonomickými programy, pak je možné aktualizovat internetovou prodejnu přímo z prostředí softwaru pro skladové hospodářství. Tyto systémy jsou z pochopitelných důvodů dražší, ale na druhou stranu šetří peníze za připojení k Internetu. Klady: • pohodlná úprava katalogu, • automatizovaná aktualizace, • díky pohodlnější správě katalogu je možné vytvářet i složitější závislosti mezi výrobky, například sestavy s volitelnými parametry, skupiny výrobků apod.,
5.3
Předgenerované stránky
15
• možná správa objednávek a zákazníků stejně lehce, jako katalogu. Zápory: • aktualizace není okamžitá, • vhodné pro prodejny se stovkami až tisíci položek.
5.3
Předgenerované stránky
Existují i takové aplikace, které na internetovém serveru nemají žádnou databázi zboží, webové stránky se vygenerují ještě na počítači u obchodníka a pak se jako statické HTML stránky nahrají na internetový server. Taková internetová prodejna je pak velmi rychlá, ale aktualizace tisíce položek může být časově velmi náročná. U nás se takové aplikace vyskytují jen zřídka. Častěji se vyskytuje jednoduchá stránka se zbožím, kterou si většinou vytvářejí sami obchodníci, protože nechtějí utrácet za složitější aplikace nebo mají v katalogu jen pár položek. Klady: • rychlost prodejny, • není potřeba připlácet za hosting s podporou databáze nebo scriptovacího jazyka. Zápory: • při každé změně nutnost nahrávat celý katalog na server, • bez databáze a aktivních stránek na serveru vzniká mnoho dalších omezení, např. nemožnost prohledávání katalogu, registrace zákazníků . . . • vhodné pro prodejny s maximálně několika desítkami až stovkou položek.
5.4
Přímé spojení
Přímé propojení elektronické prodejny se skladovým hospodářstvím zajišťuje okamžitou aktualizaci, ale stojí spoustu peněz. Rozhodnete-li se provozovat vlastní internetový server v rámci vaší firemní sítě, existuje možnost vytvořit internetovou prodejnu jako součást skladového hospodářství založenou na stejné databázi zboží. V tomto případě problém aktualizace katalogu neexistuje, všechny změny ve skladech jsou ihned viditelné i v internetové prodejně. Obvykle se jedná o samostatný modul ekonomického systému, který se platí zvlášť, nebo je nutné si jeho zhotovení objednat na zakázku. Klady: • přímé propojení objednávek z internetové prodejny s ostatní evidencí objednávek, • okamžitá aktualizace, • snadná přizpůsobivost internetové prodejny individuálním potřebám, • přehledná navigace a vyhledávání.
5.4
Přímé spojení
Zápory: • riziko napadení firemní sítě z Internetu, • vysoké náklady na připojení, • vysoké náklady na pořízení prodejny.
16
6
NÁLEŽITOSTI A STRUKTURA ELEKTRONICKÉHO OBCHODU
6
17
Náležitosti a struktura elektronického obchodu
Nejčastěji bývá v elektronických prodejnách zboží rozdělené do kategorií a podkategorií, většina aplikací se tomuto schématu přizpůsobuje a umožňuje jejich snadné a přehledné procházení. V některých případech však takový přístup nepostačuje, a proto je dobré, když aplikace nabízí více alternativních způsobů. Některé druhy zboží je vhodné začlenit do více kategorií nebo stejné zboží členit podle různých kritérií. Zdaleka ne všechny aplikace jsou na takovou potřebu připraveny. Každý obchodník má svou vlastní představu o tom, jak by se měl zákazník v jeho prodejně orientovat, je proto dobré, aby aplikace nabídla více než jeden standardní způsob navigace, nebo možnost vytvořit vlastní. Při vyhledávání bývá zapotřebí umožnit nalézt zboží nejen podle názvu, popisu a ceny, ale i podle dalších parametrů, které výrobky mohou mít. Přitom u každého obchodníka se bude jednat o parametry jiné, takže je velmi obtížné nalézt již hotovou aplikaci, která by vyhověla všem požadavkům. Ve své praxi jsem se setkal s případem, kdy chtěl obchodník s vínem nabídnout možnost vyhledávat vína, která se hodí k určitým druhům jídel, nebo vyhledávání počítačových sestav podle různého výkonu. V prodejně videokazet je zase užitečné nabídnout možnost vyhledávat podle obsazení filmu. Dobrý obchodník takové nápady samozřejmě má, ale pro programátora aplikace se jedná o velmi speciální případy, které se dají velmi těžko zahrnout do celé aplikace. Je pak důležité znát svoje možnosti a zkušenosti v tvorbě podobných aplikací, aby bylo možno vyhovět i v takových individuálních požadavcích.
6.1
Různé vlastnosti zboží
Označení novinky, výprodeje, akce, výše slevy – to vše má vliv na prodejnost zboží. Každá prodejna by je měla umožnit nastavit. (Z praxe vím, že je nejčastěji žádáno zobrazení výrobků se sníženou cenou na úvodní stránce obchodu.) Mezi základní vlastnosti patří kromě zobrazení cen i označení výrobce, popis, obrázek, případně rozšiřující popis a zvětšený obrázek, dále doba dodání, případně množství na skladě. Dobrý obchod nabízí škálu možností pro zadání a zobrazení dalších vlastností, což má ovšem pochopitelný vliv na složitost a konečnou cenu aplikace. V některých případech je požadována možnost nechat na zákazníkovi, aby si zvolil hodnotu některých parametrů výrobků. U textilu je to často velikost a barva, u výpočetní techniky různé příslušenství nebo tvorba počítačových sestav apod. Mezi univerzálními řešeními se jedná spíše o výjimečnou vlastnost, proto je vhodné vytvářet elektronické obchody „na míruÿ.
6.2
Slevy
V obchodní praxi existuje mnoho různých systémů slev, v rámci jedné prodejny se často několik slev vzájemně kombinuje. Obchodník by měl zvážit, zda bude moci ve
6.3
Zpracování objednávky
18
své prodejně realizovat alespoň větší část z těch, které aktivně používá. Nejrozšířenější je přidělení slevy přímo na konkrétní výrobek, dále se často používá přidělení osobní slevy jednotlivým zákazníkům. V dealerském prodeji doporučuji členit své dealery do dealerských skupin, kdy každá skupina má své vlastní ceníkové ceny. Všechny tyto možnosti by měla být schopna aplikace pro vaši internetovou prodejnu realizovat. Vyskytují se i případy, kdy se uvedené možnosti vzájemně kombinují, např. přidělení slevy celé kategorii výrobků pro určitou skupinu zákazníků, jako jsou například stálí zákazníci. Nezastupitelnou roli v systému slev zaujímají množstevní slevy, které se přidělují zákazníkovi za podmínky překročení stanovené hranice výše jeho objednávky. V praxi se na přidělování slev kladou různé podmínky, často až protichůdné, ne každá aplikace jim je schopna vyhovět.
6.3
Zpracování objednávky
Doručením objednávky obchodníkovi její zpracování často nekončí, ale teprve začíná. V dobré internetové prodejně má zákazník obvykle možnost zjistit, v jakém stavu se jeho objednávka nachází. Pokud již byla objednávka vyřízena, dozví se kdy bude zboží doručeno, případně expediční kód, pod kterým si může zjišťovat stav zásilky u doručovací služby. Velkou výhodou je přímé propojení s vaším ekonomickým systémem, ve kterém si pak můžete objednávku zpracovávat standardním způsobem. Tyto možnosti však vyžadují registraci zákazníka v elektronickém obchodě na jedné straně a schopný tým starající se o objednávky na straně druhé.
6.4
Rychlost
Rychlost internetové prodejny patří mezi její nejdůležitější parametry. Kvůli dlouhé odezvě je množné zákazníka navždy ztratit. Faktory zpomalující chod aplikace sou nastíněny ve dvou základních bodech. 6.4.1
Technologická základna
Prodejnu s vysokou návštěvností nelze vybudovat na jednoduché databázi, proto doporučuji využití transakčního SQL serveru. Při tvorbě aplikace doporučuji MySQL, který podporuje většina hostingových serverů, protože jeho šíření a použití je zdarma. Ovšem ani výkonný SQL server nezajišťuje automaticky vysoký výkon aplikace, vyladit její výkon vyžaduje obvykle práci zkušeného odborníka na SQL databáze, který navrhne strukturu a propojení jednotlivých tabulek. 6.4.2
Složitost aplikace a kvalita řešení
Často jsem ve své praxi docházel k rozporu – buď pracuje nějaká funkce správně nebo rychle. Ano, je v tom jistá nadsázka, ale i kus pravdy. Zjistit, která funkce prodejnu brzdí, a jak ji zrychlit, vyžaduje mravenčí práci. Proto nelze počítat s tím,
6.5
Platby, doprava, splátkový prodej
19
že lze udělat rychlou prodejnu s mnoha funkcemi za pár tisícovek. Kvalita řešení však nesmí opomenout i základní věci, jako je například zadávání velikostí obrázků v HTML kódu, což výrazně urychlí zobrazení stránek na straně klienta.
6.5
Platby, doprava, splátkový prodej
Nejlepší je možnost nastavení vlastních druhů dopravy a způsobu výpočtu poštovného a balného. Pro některé druhy dopravy se poštovné stanoví pevnou sazbou, pro jiné podle hmotnosti zásilky. Tato problematika patří mezi nejsložitější. Někdy je zapotřebí, aby se pro některé výrobky poštovné nepočítalo, balné by mělo záviset na počtu balíků a počet balíků by se měl odvíjet od celkového počtu výrobků a jejich hmotnosti. Mnohé aplikace se omezí tím, že umožňují nastavit poštovné a balné pro celou objednávku a s možností dělit objednávku do více balíků nepočítají. Na některé druhy plateb také občas potřebujete povolit slevu nebo naopak přirážku. V případě splátkového prodeje je zapotřebí zobrazit výpočet splátek. Samotný splátkový prodej je přes Internet obtížně realizovatelný, vzhledem k nutnosti uzavřít písemnou smlouvu se zákazníkem. U aplikací na zakázku by mělo být samozřejmostí vše, co si obchodník dokáže vymyslet.
6.6
Elektronické platby
V poslední době se objevují stále nové způsoby online příjmu plateb. Ať už se jedná o internetbanking, mikroplatby, nové platební nástroje nebo o specializované platební portály, které umožňují jednotný přístup k více druhům platebních nástrojů. Každý z těchto způsobů přináší určité výhody, každý má také své nevýhody. Je proto vhodné obeznámit se s tím, co přinese konkrétní platební nástroj právě vaší prodejně, a čím za to budete muset zaplatit. Zabudovat do internetové prodejny alespoň většinu z existujících platebních nástrojů je poměrně náročný technický úkol. Každý z nich vyžaduje jiný způsob komunikace mezi prodejnou, zákazníkem a stranou vyřizující platbu (provozovatelem platebního nástroje). Platí úměra, že čím je jednodušší technické řešení, tím je nižší úroveň zabezpečení platby. Čím vyšší úroveň zabezpečení, tím obtížnější je technické řešení a zároveň vyšší požadavky na zákazníka i obchodníka. Univerzální platební portály (MUZO) se pokoušejí tuto obtížnost a různorodost vyřešit za obchodníka (nebo tvůrce internetové prodejny) tím, že umožňují přístup ke všem platebním metodám jednotným způsobem. Obvykle však za to požadují poplatky. Výhodou je ale to, že na sebe přebírají zodpovědnost za dokončení transakce.
6.7
Zajímavý vzhled
Vzhled elektronického obchodu je velmi důležitý, protože jako první působí na potencionální zákazníky. Proto je dnes skoro samozřejmostí, že design aplikace navrhuje grafické studio, která spolupracuje s programátorem. V praxi jsem se ale setkal tím,
6.8
Jazyky a měny
20
že grafik navrhne vzhled, který je obtížné převést do HTML, proto je pro programátora nutné, aby grafika v tomto ohledu „usměrnilÿ. Aplikace by měla být po grafické stránce měnitelná, což se řeší různými způsoby, existují však zhruba tři úrovně: 6.7.1
Manuální úprava stránek
Manuální úprava stránek je nejčastější u aplikací typu nákupní košík nebo u zakázkových řešení. Obvykle vyžaduje velmi dobrou znalost aplikace, protože se zasahuje přímo do ní a její funkčnost tak může být ovlivněna. Proto tyto úpravy (u zakázkových řešení) nejčastěji provádí přímo dodavatel. 6.7.2
Volba barevného schématu
Volba barevného schématu, vlastních obrázků a doplnění vlastních HTML stránek parametrizací5 . Možnosti úpravy vzhledu jsou limitované, výhodou je to, že je zvládne i nezkušený pracovník. 6.7.3
Šablony
Jsou-li podporovány, je možné vzhled libovolně měnit jejich úpravou. Vzhledem k tomu, že šablony nejsou s aplikací přímo svázány, jejich modifikace méně ohrožuje funkčnost a mohou je provádět i odborníci mimo dodavatele software, případně po zaškolení i pracovníci obchodníka.
6.8
Jazyky a měny
Se vstupem naší země do Evropské unie se stává aktuálním prodej ve více měnách a jazycích. Možnost zobrazení cen v různých měnách (s přepočtem podle kurzu) nebo volba jazyka zákazníkem – to jsou vlastnosti, se kterými u jednoduchého nákupního košíku nelze počítat. Proto je jejich řešení obsaženo ve složitějších aplikacích.
6.9
Podpora prodeje
Pod tímto názvem se skrývají různé funkce, které pomáhají zákazníkům orientovat se ve zboží, například automatickým generováním přehledu nejprodávanějšího zboží, ať už v celé prodejně nebo v právě vybrané kategorii, vytváření seznamu zboží, které se nejvíce prodává spolu s vybraným výrobkem apod. Dále je možné do této skupiny zahrnout dotazy zákazníků k jednotlivým výrobkům, hodnocení výrobků, . . . Všechny tyto funkce poskytují zákazníkům doplňkové informace potřebné k jeho rozhodnutí o koupi produktu. Takové funkce jsou běžné pouze u vyšší třídy univerzálních řešení nebo u prodejny na zakázku, v některých případech pouze za příplatek. 5
povolení nebo zakázání zobrazení různých prvků na stránkách
6.10
Statistika
6.10
21
Statistika
Obchodník, který se své prodejně věnuje, potřebuje znát nejen průběžnou návštěvnost a prodej, ale i odezvu zákazníků na své marketingové akce, sledovat jejich chování v prodejně apod. Přitom podrobné statistiky patří k tomu nejnáročnějšímu, co tvorba prodejny obnáší. Vyžadují použití transakčního SQL a určitým způsobem také zpomalují rychlost aplikace. U méně pokročilých řešení proto nejsou podporovány.
6.11
Propojení s partnery
Na Internetu se často zvyšuje návštěvnost stránek pomocí partnerských webů, které si na své stránky umístí odkaz na vaše. V případě prodejny má smysl takové partnery zaujmout poskytnutím provize z každé objednávky, kterou návštěvníci přicházející z jejich stránek u vás dokončí a zaplatí. To vyžaduje, kromě dohody s partnerem, aby se u každé objednávky registrovalo, od kterého partnera zákazník přišel.
7
PRÁVNÍ STRÁNKA VĚCI
7 7.1
22
Právní stránka věci Správa dat
Paragraf 5 zákona (101/2000 Sb., 2000) o správě dat určuje povinnosti správce. Mezi ty nejdůležitější patří: 1. Shromažďovat osobní údaje odpovídající pouze stanovenému účelu a v rozsahu nezbytném pro naplnění stanového účelu (§ 5, odst. 1, písm. d). 2. Uchovávat osobní údaje pouze po dobu, která je nezbytná k účelu jejich zpracování. Po uplynutí této doby mohou být osobní údaje uchovávány pouze pro účely statistické, vědecké a pro účely archivnictví. Při použití pro tyto účely je třeba dbát práva na ochranu před neoprávněným zasahováním do soukromého a osobního života subjektu údajů (§ 5, odst. 1, písm. e) 3. Zpracovávat osobní údaje pouze v souladu s účelem, k němuž byly shromážděny, pokud zvláštní zákon nestanoví jinak. Zpracovávat k jinému účelu lze osobní údaj, jen pokud k tomu dal subjekt údajů souhlas (§ 5, odst. 1, písm. f) 4. Shromažďovat osobní údaje pouze otevřeně; je vyloučeno shromažďovat údaje pod záminkou jiného účelu nebo jiné činnosti, pokud zvláštní zákon nestanoví jinak (§ 5, odst. 1, písm. g) 5. Nesdružovat osobní údaje, které byly získány k rozdílným účelům, pokud zvláštní zákon nestanoví jinak (§ 5, odst. 1, písm. h) Pokud správce nepoužije data jednorázově (k vyřízení objednávky) a uloží je do databáze, musí zákazníka požádat o souhlas. „Ze souhlasu musí být patrné, v jakém rozsahu je poskytován, komu a k jakému účelu, na jaké období a kdo jej poskytuje. Souhlas může být kdykoliv odvolán, pokud se subjekt údajů se správcem výslovně nedohodne jinak. Tento souhlas musí správce prokázat po dobu zpracování osobních údajů, k jejichž zpracování byl dán souhlasÿ (citace § 5 odst. 5). Problémem není stav, kdy e-shop předá osobní data dalšímu subjektu (např. distribuční firmě), která se tak stane zpracovatelem údajů. Pro zpracovatele platí stejné povinnosti jako pro správce, ale navíc nesmí získané informace poskytnout další osobě. „Správce je před zahájením zpracování osobních údajů povinen subjekt údajů řádně a včas písemně informovat o tom, v jakém rozsahu a pro jaký účel budou osobní údaje zpracovávány, kdo a jakým způsobem bude osobní údaje zpracovávat a komu mohou být osobní údaje zpřístupněny či komu jsou určeny, nejsou-li subjektu údajů tyto informace již známy.ÿ Tyto a další informační povinnosti, které jsou zákonem nařízeny (poučení o právu přístupu k informacím, důsledky odmítnutí apod.) může management e-shopu splnit zveřejněním prohlášení během aktu registrace.
7.2
Informační povinnost
Od 1. ledna 2000 vstoupil v účinnost zákon 367/2000 Sb., který vkládá do Občanského zákoníku 64/1964 Sb. mimo jiné i směrnici evropského parlamentu a rady
7.2
Informační povinnost
23
97/7/ES o ochraně spotřebitele v případě smluv uzavřených na dálku. Tato směrnice, která je v zemích EU hlavním nástrojem ochrany spotřebitelů na internetu, získala podobné postavení i u nás. Vztahuje se tedy jen na sektor B2C6 , kdy podnikatel prodává koncovému spotřebiteli. Jejím přínosem je zakotvení informační povinnosti prodávajících a možnosti vrácení zboží spotřebitelem. Podle § 53, odst. 4 musí elektronický obchod sdělit s dostatečným předstihem před uzavřením smlouvy spotřebiteli kromě dalších i tyto informace: • Základní identifikační údaje provozovatele obchodu, kterými jsou obchodní jméno, adresa a identifikační číslo. A ačkoli to zákon výslovně neukládá, je vhodné pro zvýšení důvěry spotřebitelů zveřejnit i operativní kontaktní údaje (telefon a e-mail). • Název a hlavní charakteristiky zboží nebo služeb; tyto údaje zveřejňuje každý obchodník, který chce prodat, zcela automaticky. • Cenu zboží nebo služby včetně všech poplatků, tzn. včetně DPH, ostatních daní, poplatků za podlimitní objednávku apod. • Vyčíslení nákladů na dodání. Ideální je uvedení přesné částky za přepravné, v některých případech to však není technicky možné; pak se hodí např. zveřejnit ceník přepravného podle váhy nebo např. odkaz na internetové stránky České pošty (musí však být uvedeno, jaká služba České pošty bude použita, protože částky u obyčejného, profi a EMS balíku se významně liší). • Způsob platby, dodání zboží nebo plnění služby, což jsou běžně zveřejňované přehledy možných způsobů úhrady a metod dodání (v ČR stále vede dobírka České pošty, která je vlastně obojí v jednom). • Náklady na použití komunikačních prostředků na dálku, což se vztahuje spíše na objednávky uzavírané prostřednictvím telefonů se zvláštním tarifem (0609, 0900 apod.). • Dobu, po kterou zůstává nabídka nebo cena v platnosti, aby se spotřebitel v okamžiku objednávky nesetkal například s tím, že aktuální cena je vyšší. • O právu na odstoupení. Spotřebiteli by měla být podle tohoto ustanovení poskytnuta jednoduchá informace, že má právo od smlouvy odstoupit ve lhůtě 14 dnů od dodání zboží. Další informační povinnosti ukládá obchodníkovi Občanský zákoník v § 53, odst. 5. Níže uvedené údaje musí být spotřebiteli poskytnuty písemně po uzavření smlouvy, nejpozději však před jejím plněním (dodáním zboží): • Opět základní identifikační údaje provozovatele obchodu popsané výše. • Informace o podmínkách a postupech pro uplatnění práva odstoupit od smlouvy, mezi kterými by kromě konstatování faktu, že je možno odstoupit, měly být i konkretizovány podmínky (jaká lhůta je u kterého zboží, protože dodavatel ji může prodloužit) a mělo by být popsáno, jakým způsobem odstoupit (které osobě zboží zaslat apod.). 6
Business To Customer
7.3
Ochrana dat dle § 13
24
• Informace o službách po prodeji a zárukách; zaznívá tu požadavek na písemné uvedení záruky, a proto nestačí běžná praxe, že není-li uvedeno nic, tak automaticky platí dvouletá záruka podle Občanského zákoníku. • Posledním požadavkem je uvedení podmínek pro zrušení smlouvy, je-li uzavřena na dobu delší, než jeden rok nebo dobu neurčitou. Někteří obchodníci možná stojí před dilematem, zda upozorňovat spotřebitele na možnost vrácení zboží či neupozorňovat. Počet spotřebitelů, který si je vědom tohoto svého práva, je stále ještě relativně nízký, takže by se mohlo zdát výhodné to nezveřejnit. Objevil se i názor, který prezentoval i jeden prominent elektronického obchodování na českém internetu, že zákon dává prodávajícímu na vybranou, zda chce informace zveřejňovat a mít lhůtu na odstoupení jen 14 dní nebo nechce a připustí ji tříměsíční. S touto myšlenkou bych si dovolil polemizovat, protože zákon jednoznačně ukládá informace zveřejňovat (Pavlík, 2002).
7.3
Ochrana dat dle § 13
„Správce a zpracovatel jsou povinni přijmout taková opatření, aby nemohlo dojít k neoprávněnému nebo nahodilému přístupu k osobním údajům, k jejich změně, zničení či ztrátě, neoprávněným přenosům, k jejich jinému neoprávněnému zpracování, jakož i k jinému zneužití osobních údajů. Tato povinnost platí i po ukončení zpracování osobních údajů.ÿ
7.4
Oznamovací povinnost dle § 16
Opět cituji zákon 101/2000 Sb.: „Ten, kdo hodlá zpracovávat osobní údaje, je povinen tuto skutečnost oznámit Úřadu před započetím zpracovávání osobních údajů. Oznámení je povinen učinit i správce, jestliže hodlá změnit zpracování osobních údajů. Oznámení musí být učiněno písemně.ÿ
7.5
Shrnutí
Pokud e-shop od svých zákazníků vyžaduje při registraci vyplnění osobních údajů (stačí kombinace jméno + příjmení + poštovní adresa), musí se řídit při manipulaci s takovými daty Zákonem o ochraně osobních údajů. Nutnou podmínkou je oznámení Úřadu pro ochranu osobních údajů, který nad ním nadále vykonává kontrolní činnost a může mu za nesplnění litery zákona uložit dokonce až desetimiliónovou pokutu.
8
SHRNUTÍ TECHNOLOGIÍ POUŽÍVANÝCH PRO ELEKTRONICKÉ OBCHODY
8
25
Shrnutí technologií používaných pro elektronické obchody
8.1
Databázový systém
Databázových systémů existuje velké množství od různých výrobců a pod různými licencemi. Mezi nejznámější patří například: Oracle, MySQL, mSQL, dBASE, Sybase, PostgreSQL, . . . Obecně lze rozlišit databázové systémy na relační RDBMS7 a objektově orientované ODMBS8 . V relačních databázích jsou data uložena v sadě tabulek. Každá tabulka obsahuje jeden nebo více sloupců, které popisují atributy dat a každý řádek v tabulce je instancí dat. Relační databáze se již používají mnoho let v oblasti akademické i obchodní a jsou to ověřené a stabilní systémy. Objektově orientované databázové systémy jsou současným trendem. Jsou velmi flexibilní a podřizují se skoro přirozeně struktuře většiny dat. V těchto databázích jsou data reprezentována objektem s vlastnostmi a metodami, které na ně lze aplikovat. Ve vývoji ODBMS jsou velkým příslibem zapouzdření a modularita, které objektově orientované programování programátorovi poskytuje. I když by ODBMS měl být lepší v reprezentaci dat a jejich relacích, bude zde ještě hodně práce při zvyšování výkonu. Vyhledávací algoritmy v systémech RDBMS jsou zralejší a robustnější. V současnosti jsou velmi rozšířené databázové systémy mající charakteristiky RDBMS i ODBMS. Takovéto databázové systémy se někdy nazývají Rozšířené relační databáze (Extended Relational Databases, ERDBMS), ale obvykle jsou označovány jako Objektově relační databáze (Object Relational Databases, ORDBMS). Tyto databázové systémy mají některé vlastnosti a možnosti ODBMS, ale struktura dat a přístup k těmto datům je pomocí relačního přístupu. Příkladem tohoto druhu databáze je PostgreSQL. Protože je třeba vybudovat systém s minimálními náklady, je vhodné vybírat pouze mezi databázovými systémy s licencí typu open source. Možná by bylo dobré si trochu přiblížit co vůbec termín Open source software znamená. Open source software nevyvíjí žádná společnost. Místo toho schopní programátoři, kteří mají zájem a určité množství volného času, se zkontaktují prostřednictvím Internetu a vyměňují si názory. Někteří napíší program a uloží ho na místo, odkud si ho může stáhnout kdokoliv. Jiní programátoři se připojí a provedou změny. Jakmile je program dostatečně funkční, ohlásí programátoři dostupnost programu ostatním uživatelům Internetu. Uživatelé najdou chyby a chybějící funkce a ohlásí je zpět programátorům, kteří obratem program vylepší. Možná to zní jako neproveditelný proces, ale ve skutečnosti to skrývá několik výhod: • Není vyžadována struktura společnosti, proto nejsou žádné režijní výdaje ani ekonomická omezení. 7 8
Relational Database Management Systems Object Oriented Database Management Systems
8.1
Databázový systém
26
• Vývoj programu není omezen schopnostmi pouze najatých programátorů, ale odráží schopnosti a zkušenost velké komunity internetových programátorů. • Je usnadněna odezva uživatelů a je umožněno testování programu velkým počtem uživatelů v krátkém časovém období • Vylepšení programu lze rychle distribuovat uživatelům. Jsou to tedy databázové systémy, které jsou k dispozici bezplatně i pro obchodní využití. Z těchto systémů jsou k dispozici a dostatečně rozšířené pouze dva databázové systémy a to MySQL a PostgreSQL. 8.1.1
PostgreSQL
Předchůdcem objektově relačního databázového systému Postgres byl systém Intres9 , vyvinutý na kalifornské univerzitě v Berkeley (1977–1985). Zdrojový kód sytému Intres byl později rozšířen o relační technologie společnosti Intres, která vytvořila jeden z prvních komerčně úspěšných relačních databázových systémů. V Berkeley rovněž působil Michela Stonebraker, který vedl tým zabývající se vývojem objektově relačního databázového serveru s názvem Postgres. První demoverze tohoto systému byla představena v roce 1987 a první verze byla uvolněna uživatelům v červnu 1989. Druhá verze v červnu 1990 a třetí v roce 1991. Počet externích uživatelů se během roku 1993 zdvojnásobil a tato komunita již byla schopna zajistit vývoj a podporu systému sama. Projekt Postgres byl v Berkeley oficiálně ukončen verzí 4.2. Během této doby byl Postgres používán pro mnoho implementací v oblasti výzkumu i výroby. Například pro systémy pro analýzu finančních dat, geografické informační systémy, lékařské IS, ale také třeba pro vyhledávání drah asteroidů. Postgres byl také využíván pro výuku na mnoha univerzitách. Zdrojový kód systému Postgres byl také firmou Illustra information Technologies převeden do komerční podoby – tato je v současné době známá jako Informix a vlastněná společnosti IBM. V roce 1994 Andrew Yu a Jolly Chen nahradili dotazovací jazyk PostQUEL dotazovacím jazykem SQL a byly provedeny další změny. Databáze byly přejmenována na Postgres95 a celkově byla o 30–50 % rychlejší než původní verze 4.2. V roce 1996 byl tento systém přejmenován na PostgreSQL a číslování se vrátilo k Postgresu, tedy první verze byla PostgreSQL verze 6.0. Bylo provedeno několik dalších vylepšení. V současnosti je nejnovější verzí PostreSQL Verze 7.4 a je jedním z nejlépe funkčních databázových systémů a mezi systémy typu open source nemá konkurenci vůbec. PostgreSQL je dostupný pro více jak 34 různých platforem typu UNIX a s verzí 7.4 byla přidána i podpora pro platformu MS Windows. V současné době je databázový systém součástí standardní distribuce většiny operačních systémů třídy Linux. Je k dispozici nativní rozhraní pro ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, Python a Ruby. Odpovídá specifikaci ANSI SQL a je zajištěna kompatibilita pro přechod ze starší RDBMS (Momjian, 1998). 9
Interactive Graphics and Retrieval System
8.2
Strana serveru
8.1.2
27
MySQL
MySQL je v současné době asi nejrozšířenějším databázovým systémem v oblasti internetového využití. Patří mezi relační DBMS. Je to malý, kompaktní, jednoduše použitelný databázový server, ideální pro malé a střední aplikace. Jedná se o implementaci klient-server, která se skládá z daemonu serveru mysqld a mnoha různých klientských programů. Je dostupný pro platformy UNIX, Windows NT a Windows 95/98. MySQL má ale také jednu obrovskou nevýhodu, a to právě ve své jednoduchosti. Neumožňuje některé ze základních prvků databází – cizí klíče, pohledy, podvýběry . . .
8.2
Strana serveru
Tyto prostředky jsou nejdůležitější pro vývoj mého systému. Úkolem je tvorba dynamických stránek a jejich následné předávání koncovým uživatelům ve vhodné podobě. Dynamické stránky se generují na základě dotazů koncových uživatelů a dat získaných z databázového systému, případně dat zaslaných uživatelem ke zpracování. Fyzicky je tato vrstva tvořena tzv. „webovým serveremÿ, což je speciální aplikace komunikující s koncovým uživatelem pomocí protokolu HTTP, případně HTTPS. Tato aplikace má implementovány některé možnosti – programovací jazyky – které dynamicky generují požadované stránky. Nejrozšířenějším webovým serverem je Apache, který také většinou zajišťuje funkčnost běžných hostingových serverů. Alternativy pro implementaci jsou: • programy CGI, • dynamické stránky HTML generované této vrstvě, • programovací jazyky na straně serveru. 8.2.1
Programy CGI
Programy CGI10 jsou funkční programy napsané v některém programovacím jazyce – v současnosti Perl, jazyk C, Java, Python. Tyto programy mohou přistupovat k databázovému systému pomocí příslušného rozhraní API, které je k dispozici pro většinu databází. Toto funguje následujícím způsobem: při požadavku na příslušnou stránku je na serveru spuštěn příslušný program, tomu je vytvořen proces s určitými oprávněními. Toto může být velký bezpečnostní problém v případě nevhodného nastavení zabezpečení serveru nebo při chybě v programu. Také pokud prohledáváte servery nabízející hosting na sítí Internet, tak možnost CGI skriptů je často nabízena až za příplatek. 10
Common Gateway Interface
8.3
Programovací jazyky na straně serveru
8.2.2
28
Dynamické HTML
Dynamické stránky HTML, vytvářené ve této vrstvě, používají pro přístup k databázi funkce databázového rozhraní API jazyka Java a ovladače JDBC, které jsou k dispozici pro většinu databází.
8.3
Programovací jazyky na straně serveru
Programovací jazyky na straně serveru – jmenujme PHP a ASP. Tyto jazyky poskytují API pro přístup prakticky ke všem relačním databázím. ASP je proprietární systém firmy Microsoft a je dostupný pouze pro webový server firmy Microsoft a ten běží samozřejmě pouze na strojích s platformou Microsoft Windows. 8.3.1
PHP
PHP je skriptovací jazyk na straně serveru, jeho výhodami jsou jednoduchost, rychlost a přirozený způsob práce s databázemi. Tento jazyk je určen pro činnost v oblasti webu a může být přímo součástí webového serveru a tím zvýšit jeho propustnost. Skriptovací jádro jazyka PHP (v současné době jádro Zend) je velice dobře optimalizované na rychlost odezvy. Skripty v jazyce PHP jsou nejen velice rychlé, ale i jednoduché v syntaxi a robustní. Syntaxe vychází z jazyka C. Samozřejmě je možné vytvářet vlastní funkce, ale třeba i používat objektově orientované programování (plně objektové chování je podporováno až od verze 5). Vlastní funkce můžete uspořádat do modulu. Dle názoru mnoha lidí je programování v PHP jednoduché a programy jsou dobře čitelné, na rozdíl od jiných jazyků, jako třeba Perl. Neposlední výhodou jazyka PHP je, že je šířen pod Open Source licencí. A je třeba podotknout, že kombinace Linux, Apache a PHP je vynikající vývojové prostředí z hlediska stability a z hlediska ceny nemá konkurenci vůbec. PHP má schopnost nativně (bez prostředníka) se připojit na mnoho databází. Pokud se použije Open Database Connectivity Standard (ODBC), lze se připojit ke kterékoliv databázi, která podporuje ODBC, včetně produktů Microsoftu a dalších. Vzhledem k tomu, že PHP bylo již od počátku navrhováno pro web, obsahuje mnoho funkcí, které jsou určeny k plnění úkolů svázaných s webem. Vzhledem k tomu, že je tento jazyk podporován většinou hostingových serverů, tak mu dávám přednost a vytvářím aplikace právě v něm. Na druhou stranu proti tomuto jazyku hovoří například to, že se na severech nechová vždy stejně, což je způsobeno rozdílným nastavením a verzemi.
8.4
Strana klienta
Technické nároky na klientskou stranu musí být naprosto minimální, aby bylo umožněno korektní zobrazení ve většině prohlížečů.
8.4
Strana klienta
8.4.1
29
HTML
Pro prezentaci dat na internetu se používají jazyky odvozené od SGML11 , což je způsob definování jednotlivých jazyků vyvinutých podle obecných principů SGML. SGML je tedy jen popis, jak má jaký jazyk vypadat. Všechny tyto jazyky jsou značkovací, to znamená, že veškerá data jsou uložena jako strukturovaný dokument. Tedy k vlastním datům v podobě znaků, která popisují co tyto vlastní data znamenají a jak mají vypadat. Je několik jazyků z rodiny SGML, pro tyto potřeby jsou to následující: HTML, XML, XHTML. HTML je z těchto jazyků nejstarší a jako jediný dodržuje (pokud je v přesné formě) standard SGML. Přesnou formou se rozumí, že jde o přesné definice organizace World Wide Web Konsorcium a ne o definice, které si některá společnost nadefinovala pro potřeby své a svého prohlížeče. Značky jazyka HTML (a tedy dokument napsaný v tomto jazyce) pouze označují, jak mají být data formátována, neobsahují žádné údaje, o jaká data se jedná. Jeho důležité základní principy jsou: • Je to vždy pouze textový formát. Pokud se na stránkách vyskytují binární data, jako jsou obrázky nebo animace, je na ně odkázáno, tj. tato data nejsou umístěna do souboru se základním popisem stránky. • Příkazy tohoto jazyka jsou spolu se svými parametry uzavírány do špičatých závorek. Jakmile se v souboru HTML objeví výrazy uzavřené do těchto závorek, jedná se o příkaz, který nějakým způsobem definuje formátování elementů na stránce. Vždy hned za první otevírající závorkou je jméno příkazu, dále jsou pak jeho parametry. • Příkazy jsou buď párové nebo nepárové. Párový příkaz slouží k formátování elementu. Jeho první díl je před formátovaným elementem a druhý těsně za tím, čímž je vymezena oblast, na kterou se formátování aplikuje. Nepárový příkaz se vztahuje na celý dokument (např. na jeho pozadí) nebo na element, který už je sám o sobě přesně vymezený (např. obrázek). 8.4.2
XML
XML je naopak jen podmnožinou SGML – jde o jakési odlehčení. Principem XML je, že můžeme nadefinovat vlastní strukturu dat. Způsob formátování a zobrazení je nutné zajistit jiným způsobem (typicky pomocí kaskádových stylů). Dokumenty HTML a XML jsou si na první pohled velmi podobné. XML se v současnosti stává univerzálním formátem i pro přenos dat mezi jednotlivými systémy od různých výrobců. Proč je tento jazyk ještě stále málo rozšířený i přes jeho výhody? Protože každá prezentovaná stránka XML se ve skutečnosti skládá ze 3 souborů – v jednom jsou definovány jednotlivé elementy, tedy struktura dat. V dalším souboru jsou uložena vlastní data (samozřejmě musí přesně odpovídat již definované struktuře) a ve třetím souboru je pomocí kaskádových stylů určeno, jak tato data budou při prezentaci vypadat. 11
Standard Generalized Markup Language
8.4
Strana klienta
8.4.3
30
XHTML
XHTML je syntézou jazyků HTML a XML a v podstatě jde o „přidání inteligenceÿ do jazyka HTML. S tímto souvisí zpřísnění syntaktických pravidel a možnost definice vlastních elementů. XHTML je jakýmsi přechodem a využívá se minimálně. V této práci je použit jazyk HTML, protože pro potřeby tohoto systému stačí pouze jazyk, který zajistí dobrou prezentaci výstupních dat a toto HTML zajistí dobře. Vyhledávání jednotlivých položek v souboru, v čemž je dobré XML, nebude potřeba, protože veškeré tyto činnosti budou probíhat na úrovni databázového systému a skriptovacích jazyků na straně serveru. 8.4.4
Kaskádové styly
V prvotním webdesignu se nikdo příliš vzhledem stránek nezabýval. Důvodem byly pochopitelně nízké přenosové rychlosti a akademické prostředí, kde se web zrodil. Jak ale rychlosti rostly a internet se stával komerčnějším, na vzhled stránky se kladly větší nároky, někdy i na úkor samotného obsahu. V té době existoval jediný jazyk, HTML, který se staral jak o obsah, tak i o vzhled stránky. Po čase ale začalo být zřejmé, že obsah by měl být od vzhledu oddělen, což v konečné fázi zapříčinilo vznik jazyka popisujícího vzhled HTML elementů. Tímto jazykem je CSS. Tato technologie slouží k definování formátování textu. V porovnání s elementy HTML nabízí podstatně širší možnosti tohoto formátování. Kaskádové styly je možno používat několika způsoby – buďto jenom obohatit možnosti formátování textu jazyka HTML nebo jimi formátování textu v HTML nahradit úplně. Norma CSS byla vydána roku 1996. Za tu dobu již všechny důležité prohlížeče zvládly drtivou většinu možností prvních kaskádových stylů. Autory stránek je CSS podporováno a dnes se již jedná o nepostradatelnou součást webu. Po necelých dvou letech vydalo W3C novou verzi této normy, známou jako CSS2. Přestože již od této doby uplynulo mnoho let, situace není nijak růžová. Prohlížeče často nezvládají „nověÿ přidané vlastnosti, často ani ty, které by byly velmi dobře použitelné. A navíc bývají informace o CSS2 zkreslené a neúplné. Tu a tam se na světlo světa dostane nějaká zmínka o konkrétní vlastnosti, ale obecně platí, že mnozí webmasteři o této normě příliš nevědí. 8.4.5
JavaScript
JavaScript je jednoduchý programovací jazyk, který je možno zapisovat přímo do HTML stránky. Pochází z vývojářské dílny firmy Netscape, ale dnes ho podporuje i Internet Explorer a další prohlížeče. Příčinou vzniku JavaScriptu byl požadavek na zvýšení uživatelského komfortu pro uživatele stránek. JavaScript můžeme použít například při vstupní kontrole dat vkládaných do formulářů ještě předtím, než jsou vyplněné údaje odeslány na server. Kontrolu údajů nemusí provádět server a výsledkem je rychlejší odezva pro uživatele. JavaScript ve svých prvních verzích navíc umožnil i vytváření interaktivnějšího uživatelského rozhraní stránek. Stránka
8.4
Strana klienta
31
mohla reagovat na různé události vyvolané uživatelem a například doplňovat pole do formulářů nebo vyvolat otevření nového okna prohlížeče. Tyto možnosti pak dále rozšířil nový koncept dynamického HTML.
9
DOPORUČENÍ PŘI VÝVOJI ELEKTRONICKÉHO OBCHODU
9
32
Doporučení při vývoji elektronického obchodu
Vzhledem k nedostatkům, které lze najít ve většině elektronických obchodů, považuji za nutné doporučit základní prvky ve vývoji e-shopu. Poznatky vyplývají z mé vlastní zkušenosti s touto problematikou. Již delší dobu se totiž zabývám vývojem internetových aplikací, mezi které patří právě elektronické obchody. Zastávám tak funkci programátora, který je jednou ze tří, resp. čtyř12 nejdůležitějších částí ve vývoji a správné funkčnosti e-obchodu. Avšak úspěšnost, jak už jsem výše nastínil, v elektronickém podnikání není dána jen správným programovým kódem, ale i například vhodnou grafikou a rychlou odezvou na došlou objednávku. Vzhledem ke svým zkušenostem jsem se rozhodl svůj návrh rozdělit do několika částí.
9.1
Volba hostingového serveru a datové základny
Většina obchodníků, kteří za mnou přicházejí s žádostí o vytvoření elektronického obchodu, si platí základní hosting. Proto je důležité prodiskutovat s nimi požadavky na aplikaci a následně jim doporučit rozšíření hostingových služeb. Já osobně nejraději programuji v PHP, protože je tento jazyk nejen jednoduchý, ale také je podporován (za příplatek) na většině hostingových serverů. Problémem ale občas bývá různá konfigurace tohoto jazyka, z čehož plyne nutnost komunikace se správci hostingového serveru. Další nezbytnost základního elektronického obchodu je databáze, která umožňuje jednoduché vkládání a rychlé vyhledávaní. Já osobně doporučuji MySQL, protože jej stejně jako PHP podporuje skoro každý hostingový server. Jak už jsem zmínil v předchozí kapitole, MySQL nepodporuje cizí klíče, proto je nutné dávat si pozor na mazání záznamů z tabulek pokud jsou tyto záznamy navzájem programově propojeny. Naštěstí se na vývoji tohoto relačně databázového systému neustále pracuje, a tak doufám, že se časem dočkáme podobných funkcí jako nám například nabízí Oracle.
9.2
Vzhled aplikace
Grafické zpracování elektronického obchodu je první, čeho si zákazník všimne a na co obvykle klade velký důraz. Je to něco podobného, jako kdyby zákazník v reálném světě volil mezi nákupem v nově postaveném, naleštěném obchodu a obchodem starým, kde již dávno nad vchodem vybledl název prodejny. Úvodní stránka by měla být nejlepší z celého webu, už jenom z toho důvodu, že ji návštěvník uvidí první a utvoří si hned názor. Proto je dobré zadat grafický návrh zkušenému grafikovi. Od něj se však neočekává jen to, jak bude aplikace vypadat, ale i rozmístění ovládacích prvků. V praxi jsem se často setkal s rozporem názorů grafika, programátora a obchodníka, které jsou dány různými stupni a zkušenostmi s ovládáním Internetu. 12
programátor, grafik, obchodník a skladník
9.3
Návrh a realizace systému
33
Nejvhodnější je, když se menu nachází nahoře (pokud je málo položek), nebo na boku. Já osobně preferuji boční menu, protože umožňuje rozšiřitelný počet položek bez použití JavaScriptu, který mají někteří uživatelé ve svých prohlížečích vypnutý. Programátor by měl grafikův návrh zpracovat s pomocí HTML a CSS2. Já doporučuji pozicování elementů pomocí kaskádových stylů, čímž se dosáhne toho, že půjde lehce změnit design pouze změnou v kaskádovém stylu. Je ale nutné dát si pozor na korektní zobrazení ve známých prohlížečích.
9.3
Návrh a realizace systému
Je vhodné, aby si programátor než začne programovat nejprve systém navrhnul. Struktura systému záleží na typu elektronického obchodu a také na datech ukládaných do tabulek. Většinou se používá rozdělení zboží do kategorií, případně podkategorií. Takovéto rozdělení ulehčuje zákazníkovi orientaci. Doporučuji vytvořit nejméně dvě tabulky. V jedné mít názvy sekcí, resp. podsekcí označenou jako kategorie a v druhé výrobky. Spojením obou tabulek lze vybírat výrobky patřící do různých sekcí, jak je to známé snad ze všech elektronických obchodů. Příklad na vytvoření tabulky kategorií v MySQL: CREATE TABLE kategorie ( id int(4) NOT NULL auto_increment, nazev_sekce varchar(50) NOT NULL default ’’, podsekce int(4) NOT NULL default ’0’, PRIMARY KEY (id) ); Příklad na vytvoření tabulky zboží v MySQL: CREATE TABLE zbozi ( id int(4) NOT NULL auto_increment, sekce int(3) NOT NULL default ’0’, nazev varchar(100) NOT NULL default ’’, cena float NOT NULL default ’0’, popis mediumtext, PRIMARY KEY (id) ); Příklad spojení tabulek s vybráním zboží patřícího do sekce 3: SELECT nazev, cena FROM kategorie, zbozi WHERE kategorie.id=zbozi.sekce AND kategorie.id=3 Další možnosti závisí na požadavcích zadavatele projektu. Pochopitelně lze přidat i tabulku v které budou uchovávány záznamy o registrovaných zákaznících.
9.4
Vyhledávání
34
Příklad na vytvoření tabulky registrovaných zákazníků v MySQL: CREATE TABLE reg_zakaznik ( id int(5) NOT NULL auto_increment, login varchar(15) NOT NULL default ’’, heslo varchar(15) NOT NULL default ’’, email varchar(50) NOT NULL default ’’, jmeno varchar(15) NOT NULL default ’’, prijmeni varchar(20) NOT NULL default ’’, ulice varchar(40) NOT NULL default ’’, mesto varchar(25) NOT NULL default ’’, psc varchar(10) NOT NULL default ’’, PRIMARY KEY (id), KEY login (login), KEY heslo (heslo) ); Tyto jednoduché tři tabulky nám stačí na vytvoření základního obchodu s možností registrace. Zákazníci se však obávají o svá data, takže se neradi registrují. Obzvláště neradi poskytují své telefonní číslo. Z tohoto důvodu bývá vhodné nabídnout zákazníkovi možnost nakoupit v obchodě i bez registrace.
9.4
Vyhledávání
Pokud je v obchodě více výrobků, zákazník ztrácí přehled, a proto je vhodné umožnit mu jednotlivé zboží vyhledat zadáním časti nebo celého slova. Vyhledávání je dobré seřadit podle abecedy, ceny nebo seskupit podle sekcí, v kterých se nalezené slovo nachází. Tady bych se chtěl pozastavit nad jedním problémem, který se objevuje v českých e-shopech. Tím problémem je nemožnost zadávání slov bez diakritiky. Mně osobně to vadí zejména proto, že standardně používám anglické rozložení kláves na klávesnici.
9.5
Katalog
Důležitou součástí elektronického obchodu by měl být katalog zboží nebo ceník. Zákazník tak získá možnost zjistit ceny nabízeného zboží, aniž by musel procházet celou strukturou obchodu. Vzhledem k tomu, že se ceny mohou neustále měnit, doporučuji ceníky generovat podle cen z databáze. Zákazník tak získá nejaktuálnější ceny a informace o nabízeném zboží. Vhodnou formou ceníku je například výstup do PDF.
9.6
Nákupní košík
Nákupní košík je součástí skoro všech elektronických obchodů. Zákazník do něj vkládá nabízené zboží. Na stránce by proto mělo být viditelně zobrazeno, kolik
9.7
Administrace
35
položek košík obsahuje a jaká je celková suma nákupu. Z tohoto důvodu je potřeba informace aktualizovat při každé změně v košíku, ať už jde o změnu množství nebo o přidání dalšího zboží. Obchody k tomu používají JavaScript, rámy nebo obnovují celou stránku při každé změně. JavaScript není vhodný, protože nefunguje, pokud si jej uživatel zakáže v prohlížeči. Rámy dnes už nejsou moderní a obnovovat celou stránku není praktické, zvláště pokud obsahuje větší množství grafických prvků. Já používám tzv. <IFRAME> což je párový tag HTML, který zobrazí plovoucí rám vložený do libovolné stránky. V dokumentu se zobrazí jako obdélník s načtenou další stránkou. Tuto stránku lze obnovovat jako obyčejný rám. Výhodou je, že jej lze umístit kamkoliv, a když v něm zobrazujeme stránku, na které je jen počet položek a celková cena, aktualizace trvá jen okamžik.
9.7
Administrace
Lze říct, že se každý elektronický obchod programuje dvakrát, protože k němu patří i program pro adminstraci. Vzhledem k tomu, že lidé, kteří budou elektronický obchod naplňovat daty, nejsou programátoři, je nutné vytvořit aplikaci pro úpravu obchodu. Tato aplikace musí zahrnovat bezpečné přihlašování, aby data nemohla měnit nepovolaná osoba. Další součástí je pochopitelně možnost přidávat, mazat a měnit kategorie a zboží. Já jsem se většinou setkal s požadavkem aktualizovat ceny zboží pomocí souboru. Doporučuji proto formát CSV, v kterém lze uložit tabulky dělané v Excelu. Tento formát je textový a obsahuje jednotlivé položky oddělené středníkem. Jeho výhoda spočívá v jeho jednoduchosti, protože jej lze rozdělit do pole právě pomocí středníků a následně je procházet a položku po položce aktualizovat v tabulce.
9.8
Testování
Před spuštěním hotové aplikace doporučuji nechat ji otestovat několika lidmi. Tím se odhalí většina chyb. Já osobně nechávám testovat aplikaci v průběhu programování obchodníkem, který si tím ověří její funkčnost a ovládání. Výhodné je to i proto, že obchodníka napadne i několik připomínek, které by nebylo jednoduché do aplikace zavést po jejím dokončení. Po úspěšném otestování už jen stačí zpřístupnit aplikaci na serveru.
10
10
ZÁVĚR
36
Závěr
Práce se zabývá shrnutím náležitostí elektronického obchodu a technologií použitých pro jeho realizaci. Jejím cílem je uspořádat, kromě výše jmenovaných náležitostí, i nezbytné právní skutečnosti pro provozování elektronického obchodu. Hlavní částí práce je však problematika elektronického obchodu, která je zde shrnuta jak ze stránky programátora, tak ze strany obchodníka. Dává tak oběma stranám na výběr z několika typů a způsobů provedení. Výčet ovšem není konečný, protože vždy záleží na fantazii obou stran a na zvoleném programovacím jazyce. Pouhých 16 % občanů Evropské unie někdy nakoupilo zboží on-line, v přistupujících zemích, mezi které patří i Česká republika, je toto číslo ještě významně nižší. Jedním z hlavních důvodů, proč spotřebitelé nevyužívají výhod, které jim Internet nabízí, jako pohodlný výběr z široké nabídky bez ohledu na pracovní dobu, a váhají s nákupem, jsou obavy z různých rizik elektronického nakupování. Je proto pravděpodobné, že pokud se budou autoři e-shopů řídit tímto textem, dojde k zvýšení důvěry lidí k elektronickým obchodům, protože se tyto obchody velmi přiblíží kamenným obchodům. V současné době tomu brání většinou obava lidí o osobní data, čímž dochází k nechuti se v obchodech registrovat a následně tak přicházejí například o slevy. Ovšem ani splnění všech náležitostí nevede automaticky k úspěchu. Důležitá je také rychlost zpracování objednávky a způsob vyřizování reklamací, pro které by měl být zvlášť přidělený pracovník schopný pracovat s Internetem. Práce vychází z mých vlastních zkušeností s touto problematikou. Samotný dokument je přípravou pro diplomovou práci, ve které bude uvedeno a popsáno i konkrétní provedení elektronického obchodu v programovacím jazyce PHP a s využitím MySQL, vzhledem k faktu, že je oboje podporováno na běžných hostingových serverech.
11
11
LITERATURA
37
Literatura
Dellwig, I. HTML4 – Příručka tvůrce webu. Praha: Grada publishing, 2003. 272 s. ISBN 80-247-0297-5. Haggard, M. Příručka tonoucího webmastera. Praha: Computer Press, 2003. 173 s. ISBN 80-7226-139-8. Kosek, J. PHP tvorba interaktivních internetových aplikací – podrobný průvodce. Brno: Grada publishing, 2003. 492 s. ISBN 80-7169-373-1. Momjian, B. PostgreSQL – praktický průvodce. Brno: Computer Press, 2003. 402 s. ISBN: 80-7226-954-2. Pavlík, K. Informační povinnost elektronických obchodů. http://www.interval.cz/clanek.asp?article=1029 (cit. 19. 3. 2002). Pavlík, K. Do nákupů na internetu s důvěrou. http://www.spotrebitele.cz/cizina/eu/donakupunainternetusduverou.html (cit. 30. 3. 2004). Staníček, P. Kompletní průvodce CSS (kaskádové styly). Praha: Computer Press, 2003. 178 s. ISBN 80-7226-872-4. Špaček, B. Nakupování na Internetu. Praha: Computer Press, 2003. 95 s. ISBN 80722-612-8. 101/2000 Sb. Úplné znění zákona o ochraně osobních údajů. http://www.uoou.cz/101_2000.php3 (cit. 4. 4. 2000). Zlatuška, J. Srovnání vybraných charakteristik přechodu k informační společnosti v České republice a ve světě (2). Brno: Zpravodaj ÚVT MU, 1998. roč. 9, č. 2, s. 1–9. ISSN 1212-0901.
