MASARYKOVA UNIVERZITA
FAKULTA INFORMATIKY
}w !"#$%&'()+,-./012345<yA|
Mobilná aplikácia pre
CRM-ERP systém OpenERP
DIPLOMOVÁ PRÁCA
Miroslav Sliacky
Brno, 2013
Prehlásenie
Prehlasujem, že táto diplomová práca je mojím pôvodným autor- ským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pra- mene a literatúru, ktoré som pri vypracovaní používal alebo z nich ˇcerpal, v práci riadne citujem s uvedením úplného odkazu na prí- slušný zdroj.
Miroslav Sliacky
Vedúci práce: doc. RNDr. Vlastislav Dohnal, Ph.D.
Pod’akovanie
Chcel by som pod’akovat’ svojej rodine a priatel’ke ktorí ma podpo- rujú v štúdiu. ˇDakujem vedúcemu tejto práce doc. RNDr. Vlastisla- vovi Dohnalovi, Ph.D. za odborné vedenie a cenné rady. ˇDakujem aj firme Cloud Technologies s.r.o a jej zamestnacom.
Zhrnutie
Táto práca sa zaoberá návrhom a následnou implementáciou mo- bilného klienta pre open source CRM-ERP systém OpenERP na plat- forme Android. Vytvorená aplikácia poskytuje užívatel’om OpenERP mobilný prístup k systému a správe produktov, zákazníkov a ich ob- jednávok.
Kl’úˇcové slová
Customer Relationship Management, Enterprise Resource Planning, CRM-ERP, OpenERP, OpenERP klient, Android, Java, OpenSource
Obsah
1 Úvod . . . 1
2 Základné pojmy . . . 3
2.1 CRM . . . 3
2.2 ERP systém . . . 4
2.3 Open source . . . 5
2.4 XML . . . 6
3 CRM-ERP systémy . . . 7
3.1 Komerˇcné riešenia . . . 7
3.1.1 SAP ERP . . . 7
3.1.2 Microsoft Dynamics . . . 8
3.1.3 Oracle E-Business Suite . . . 8
3.1.4 NetSuite ERP . . . 9
3.2 Open source riešenia . . . 9
3.2.1 xTouple ERP . . . 9
3.2.2 Compiere . . . 10
3.2.3 Openbravo . . . 10
3.2.4 Tryton . . . 11
4 OpenERP. . . 12
4.1 Architektúra . . . 13
4.1.1 Databázový server . . . 13
4.1.2 Aplikaˇcný server . . . 13
4.1.3 Web server . . . 14
4.2 Analýza systému . . . 14
5 XML-RPC . . . 15
5.1 RPC . . . 15
5.2 XML-RPC a Java. . . 16
6 Android . . . 17
6.1 Charakteristika . . . 17
6.2 História . . . 17
6.3 Verzie a ich zastúpenie . . . 18
6.4 Architektúra . . . 19
6.4.1 Linux kernel . . . 19
6.4.2 Knižnice . . . 21
6.4.3 Android Java a Dalvik . . . 21
6.4.4 Aplikaˇcný framework . . . 22
6.4.5 Aplikácie . . . 22
6.5 Vývoj aplikácií . . . 22
7 Analýza a návrh. . . 25
7.1 OpenERP 6.1 . . . 25
7.1.1 Zákazníci . . . 26
7.1.2 Produkty . . . 27
7.1.3 Predaje . . . 29
7.2 Android OpenERP Client . . . 30
7.2.1 Prihlásenie . . . 31
7.2.2 Zákazníci . . . 32
7.2.3 Produkty . . . 34
7.2.4 Predaje . . . 35
7.2.5 Vyhl’adávanie . . . 37
7.3 Diagramy prípadov užitia a tried . . . 37
8 Implementácia . . . 40
8.1 Použité knižnice . . . 40
8.1.1 Android-xmlrpc . . . 40
8.1.2 Android-openerp . . . 41
8.1.3 ZXing . . . 42
8.2 Implementaˇcné detaily aplikácie . . . 42
8.2.1 AsyncTask . . . 43
8.2.2 Zobrazenie dát . . . 44
8.2.3 Rotácia zariadenia . . . 44
8.2.4 Lokalizácia . . . 46
8.2.5 Aktivity a fragmenty . . . 47
9 Záver . . . 48
A Príloha – CD . . . 50
1 Úvod
Pre úspech v konkurenˇcnom boji vynakladajú firmy nemalé úsilie.
Snažia sa tak získat’ výhodu oproti ostatným spoloˇcnostiam na trhu.
K najdôležitejším aspektom, ktorým sa firmy venujú patria podni- kové procesy a komunikácia so zákazníkmi.
Bez ohl’adu na to, ˇci sa jedná o výrobu, nákup, predaj, logistiku, úˇctovníctvo alebo iné ˇcinnosti, je dôležité, aby procesy vo všetkých oblastiach boli správne a efektívne plánované a riadené. K tomuto úˇcelu sa využívajú ERP systémy (Enterprise Resource Planning), kto- ré mnohé z týchto ˇcinností automatizujú a starajú sa tak o jedno- duchost’ a efektívost’ procesov. CRM systémy (Customer Relations- hip Management) slúžia firmám pre riadenie komunikácie so zákaz- níkmi.
Používanie CRM-ERP systémov dávalo firmám výhodu v boji s konkurenciou. Dnes už sa však stali prakticky nevyhnutnou súˇcas- t’ou väˇcšiny podnikov a je potrebné d’alší náskok hl’adat’ inde. Ne- ustávajúci rast popularity zaznamenávajú mobilné technológie. Vy- užívanie smartfónov a tabletov neustále rastie a je preto prirodzené zamerat’ sa na túto oblast’ a pokúsit’ sa využit’ prepojenie CRM-ERP systémov s mobilnými platformami.
V spolupráci s Cloud Technologies s.r.o. sme sa preto rozhodli vytvorit’ aplikáciu pre operaˇcný systém Android, ktorá bude slú- žit’ ako klient pre open source CRM-ERP systém OpenERP. Komuni- kácia medzi jednotlivými komponentami bude prebiehat’ pomocou protokolu XML-RPC.
Aplikáciu budú využívat’ predovšetkým obchodníci bežne pra- cujúci s OpenERP, ktorým umožní mat’ kedykol’vek k dispozícii sprá- vu produktov, zákazníkov a ich objednávok. Napríklad pri stretnu- tiach s novými potenciálnymi zákazníkmi budú schopní okamžite ich pridat’ do systému a následne im môžu hned’ vytvorit’ novú ob- jednávku. Aplikácia tak prinesie väˇcšiu flexibilitu pre obchodníkov a odstráni nutnost’ mat’ prístup k poˇcítaˇcu pri vytváraní nových ob- jednávok.
Obsah práce je rozdelený do jedenástich kapitol. Prvá kapitola je venovaná úvodnému oboznámeniu sa s témou práce. V druhej ka- pitole sa oboznámime so základnými pojmami ako napríklad CRM,
1. ÚVOD
ERP a open source. Nasledujúce dve kapitoly sú venované defino- vaniu CRM-ERP systémov a popisu konkrétnych riešení, ktoré sú rozdelené podl’a otvorenosti kódu. Podrobne sa práca venuje hlavne systému, nad ktorým je aplikácia vyvíjaná, OpenERP. Na komuni- káciu s ním sa používa protokol XML-RPC, ktorému je taktiež ve- novaná samostatná kapitola. ˇDalšie kapitoly sa venujú samotnému vývoju aplikácie. Najskôr je predstavený operaˇcný systém Android a všetky použité technológie. Nasleduje analýza, návrh a popis im- plementácie aplikácie. V poslednej kapitole sú zhrnuté výsledky prá- ce.
2 Základné pojmy
Pre lepšiu orientáciu v problematike CRM-ERP systémov a vývoja mobilných open source aplikácií, ktoré s týmito systémami spolupra- cujú, si na úvod definujeme niekol’ko základných pojmov s ktorými sa môžeme v práci stretnút’.
2.1 CRM
Skratka CRM pochádza z anglického slovného spojeniaCustomer Re- lationship Management – riadenie vzt’ahov so zákazníkmi. Toto spo- jenie vzniklo v polovici devät’desiatych rokov a do širšieho povedo- mia sa dostalo koncom desat’roˇcia [9]. Je však zložité nájst’ jednotnú a jednoduchú definíciu, pretože CRM sa neustále, rýchlo vyvíja a pre rôzne firmy má rozdielny význam. Pre porovnanie si uvedieme nie- kol’ko definícií CRM:
• Integruje l’udí, procesy a technológie s ciel’om maximalizovat’
vzt’ahy so všetkými zákazníkmi. CRM je komplexný prístup, ktorý umož ˇnuje bezproblémovú koordináciu medzi všetkými, na zákazníka orientovanými, funkciami. CRM ˇcoraz viac vy- užíva internet (2003). [8]
• Infraštruktúra, ktorá umož ˇnuje vymedzenie a zvyšovanie hod- noty pre zákazníka a poskytuje správne prostriedky, ktorými cenných zákazníkov motivuje aby zostali lojálni – samozrejme, aby znovu nakupovali (2004). [4]
• Taký dynamický proces riadenia vzt’ahu medzi spoloˇcnost’ou a zákazníkom, že zákazníci chcú nad’alej pokraˇcovat’ vo vzá- jomne výhodných obchodných transakciách a naopak sú odrá- dzaní od transakcií, ktoré sú pre spoloˇcnost’ stratové. [1]
Ako je možné vidiet’ CRM má za ciel’ nastavit’ firemné procesy sme- rom k zákazníkom a budovat’ s nimi dlhodobý a vzájomne pros- pešný vzt’ah. Úspešne implementované CRM ponúka množstvo vý- hod, ako sú napríklad lepšie informácie pre predaj a marketing, zvý- šená produktivita alebo kvalitnejší zákaznícky servis [9].
2. ZÁKLADNÉ POJMY
Aby však bola implementácia CRM úspešná, je dôležité, aby fir- ma pri nasadzovaní upravila všetky aspekty podl’a vlastných po- trieb. Neexistuje jedno univerzálne riešenie, ktoré by sa dalo nasadit’
v každej spoloˇcnosti.
2.2 ERP systém
Z anglického Enterprise Resource Planning (plánovanie podnikových zdrojov) pochádza pomenovanie ERP systém, napriek tomu, že o plá- novanie sa tieto systémy primárne nestarajú. Ich hlavnou funkciou je prepojenie všetkých oddelení v spoloˇcnosti do jediného informaˇc- ného systému tak, aby plnil špecifické potreby jednotlivých odde- lení.
Je nároˇcné vybudovat’ jeden program vyhovujúci potrebám za- mestnancov v oddelení l’udských zdrojov a zárove ˇn zamestnancov v sklade. Bežne majú každé z týchto oddelení vlastný systém, opti- malizovaný presne pre ich potreby a spôsob práce. ERP systém však práve tieto jednotlivé systémy spája do samostatného celku, do jed- ného integrovaného informaˇcného systému, ktorý pracuje nad jedi- nou spoloˇcnou databázou. Napomáha tak jednoduchému zdiel’aniu informácií a lepšej komunikácii medzi rôznymi oddeleniami [20].
Rovnako ako pri CRM aj ERP systémy sú vysoko špecifické a pre každú firmu je potrebné navrhnút’ a implementovat’ systém na mie- ru. Nie je možné jednoducho nainštalovat’ systém, ktorý funguje ús- pešne v inej spoloˇcnosti. Ak sa však podarí úspešne systém zaviest’, môže byt’ pre firmu vel’kým prínosom v mnohých oblastiach [20]:
• Zjednotenie finanˇcných informácií– Pri kontrole financií a sta- vu firmy majú vedúci pracovníci všetky informácie na jednom mieste. Nemusia riešit’ nekonzistentnosti, ktoré môžu vznik- nút’ používaním viacerých systémov.
• Zjednotenie informácií o objednávkach zákazníkov – ERP systém sa stáva miestom, kde prebieha celý životný cyklus ob- jednávky, od prijatia až po vyexpedovanie a fakturáciu. Je preto jednoduchšie sledovat’ objednávky a koordinovat’ výrobu.
• Štandardizovanie a urýchlenie výrobných procesov– Výrobné spoloˇcnosti, hlavne tie s viacerými výrobnými miestami, ˇcasto
2. ZÁKLADNÉ POJMY
vyrábajú produkty rôznymi procesmi s použitím rôznych in- formaˇcných systémov. ERP automatizuje niektoré kroky výrob- ného procesu. Ich štandardizácia, používanie jedného systému, tak môže šetrit’ ˇcas, zvyšit’ produktivitu a znižit’ poˇcet potreb- ných zamestnancov.
• Štandardizovanie informácií o l’udských zdrojoch – Najmä vo vel’kých podnikoch s viacerými obchodnými jednotkami, môže byt’ zložité sledovat’ pracovnú dobu zamestnancov a ko- munikovat’ s nimi o výhodách a službách. ERP môže tento ne- dostatok napravit’.
2.3 Open source
Pri vývoji softvéru na ˇn autorovi vznikajú zo zákona exkluzívne prá- va. Medzi ne patria napríklad právo na kopírovanie, distribúciu a vy- tváranie odvodeného softvéru. Autor sa môže rozhodnút’ niektoré z týchto práv preniest’ na ostatných prostredníctvom licenˇcnej zmlu- vy. Väˇcšina komerˇcných zmlúv sa snaží ˇco najviac obmedzit’ použí- vanie softvéru.
Open source licencie dávajú užívatel’om naopak omnoho viac práv. Najpopulárnejšia open source licencia GNU General Public Li- cense napríklad poskytuje právo kopírovat’ licencovaný softvér, vy- tvárat’ z neho odvodené produkty a distribuovat’ originálnu verziu ako aj jej deriváty [14].
Medzi d’alšie obl’úbené a ˇcasto používané licencie patria naprí- klad:
• GNU Library alebo ”Lesser” General Public License (LGPL)
• Apache License 2.0
• The MIT License
• BSD 2-Clause License – ”Simplified” alebo ”FreeBSD”
• GNU Affero General Public License 3.0 – GNU AGPL-3.0 Pod licenciou GNU AGPL-3.0 bude uvol’nený aj zdrojový kód našej aplikácie, podobne ako je šírené aj OpenERP.
2. ZÁKLADNÉ POJMY
Viac informácií je možné nájst’ na internetových stránkach Open Source Initiative.
2.4 XML
Extensible Markup Language– rozšíritel’ný znaˇckovací jazyk – je štan- dard, ktorý bol schválený konzorciom W3C (World Wide Web Con- sortium). Definuje všeobecnú syntax pre oznaˇcenie dát pomocou jed- noduchých, pre l’udí ˇcitatel’ných znaˇciek. Poskytuje tým štandardný formát dát, ktorý je natol’ko flexibilný, že môže byt’ upravený pre domény tak rozdielne, ako sú internetové stránky, vektorová grafika, volanie vzdialených procedúr a mnoho d’alších [10].
Príklad XML kódu použitého v OpenERP:
1 <?xml version="1.0"?>
2 <openerp>
3 <data>
4 <record id="view_servers_form"model="ir.ui.view">
5 <field name="name">x_server.form</field>
6 <field name="model">x_server</field>
7 <field name="type">form</field>
8 <field name="arch"type="xml">
9 <form string="Servers">
10 <group>
11 <field name="url"/>
12 <field name="ip"/>
13 <field name="server"/>
14 <field name="note"/>
15 </group>
16 <notebook>
17 <page string="Partners">
18 <field name="partners"
19 widget="one2many_list"/>
20 </page>
21 </notebook>
22 </form>
23 </field>
24 </record>
25 </data>
26 </openerp>
3 CRM-ERP systémy
V predchádzajúcej kapitole sme sa oboznámili s významom CRM a ERP systémov a zistili sme aké výhody prinášajú. Pre väˇcšie a stred- né podniky je prakticky nevyhnutné implementovat’ niektoré z na trhu dostupných riešení.
Je však dôležité, aby vybraný systém dokonale sp´l ˇnal všetky po- žiadavky kladené danou firmou. Musí preto byt’ priamo vytvorený na zákazku alebo dostatoˇcne upravený. Aby CRM-ERP systémy mo- hli byt’ jednoducho upravované a splnit’ tak všetky nároky, ktoré sú na ne kladené, sú väˇcšinou vytvárané modulárne. Zavedenie vo firme je následne jednoduchšie. Pri každej implementácii sa použijú a upravia len potrebné moduly.
CRM-ERP systémy môžeme rozdelit’ do dvoch kategórií podl’a otvorenosti ich zdrojového kódu. Komerˇcné riešenia s uzavretým zdrojovým kódom a open source riešenia, ktoré sú vydávané pod rôznymi open source licenciami.
V nasledujúcej ˇcasti si predstavíme niekol’ko zástupcov z obi- dvoch skupín a pozrieme sa aj na to, ˇci ponúkajú svojim zákazníkom aj prístup pomocou mobilných klientov.
3.1 Komerˇcné riešenia
3.1.1 SAP ERP
SAP ERP je systém vyvinutý nemeckou medzinárodnou spoloˇcnos- t’ou SAP AG –Systems, Applications, and Products in Data Processing, založenou v roku 1972. V minulosti sa oznaˇcoval ako SAP R/3. Dnes však SAP ponúka množstvo produktov a modulov, ktorých centrál- nym komponentom je práve SAP ERP [11].
SAP ponúka aj širokú škálu mobilných aplikácií pre smartfóny aj tablety na všetkých platformách – iOS, Android, Blackberry a Win- dows. Nie však v rovnakej miere. Najviac aplikácií ponúka pre iOS – takmer 160, na druhom mieste je Android s poloviˇcným poˇctom a najmenej aplikácií poskytuje pre Blackberry a Windows – do 25.
Domovská stránka:http://www.sap.com
3. CRM-ERPSYSTÉMY
3.1.2 Microsoft Dynamics
Ked’ sa Microsoft rozhodol vstúpit’ na trh s ERP riešeniami v roku 2000, zaˇcal tým, že odkúpil popredné firmy v tomto odbore v Spoje- ných štátoch amerických a v Európe. Získal tak štyri ERP riešenia:
• Microsoft Dynamics GP – Great Plains
• Microsoft Dynamics SL – Solomon
• Microsoft Dynamics AX – Axapta
• Microsoft Dynamics NAV – Navision
Ich výhodou je výška investícií, ktoré Microsoft venuje na výskum a vývoj svojich produktov, integrácia s ostatnými produktami, ako napríklad Microsoft Office a v neposlednom rade aj množstvo infor- mácií, ktoré Microsoft o svojich produktoch poskytuje, vrátane dlho- dobých plánov [12].
Mobilných klientov pre Microsoft Dynamics CRM poskytuje nie- kol’ko spoloˇcností a to na všetkých významných platformách. Patrí medzi ne BFI Mobile GmbH & Co. KG ale napríklad aj slovenská firma Resco spol. s.r.o. [BFI, Resco]
Domovská stránka:www.microsoft.com/dynamics 3.1.3 Oracle E-Business Suite
Oracle ponúka svojim zákazníkom vlastné riešenie s názvom Oracle E-Business Suite. Jedná sa o balík niekol’kých aplikácií rozdelených do rôznych kategórií ako napríklad:
• CRM
• správa služieb
• správa financií
• pokroˇcilé verejné obstarávanie a iné
Oracle ponúka v oblasti mobilných klientov iba niekol’ko apliká- cií pre iPhone a iPad. Sú to napríklad Oracle Business Approvals for
3. CRM-ERPSYSTÉMY
Managers,Oracle Mobile Sales Assistantalebo Oracle Mobile Sales Fore- cast.
Domovská stránka:http://www.oracle.com/us/products/
applications/ebusiness
3.1.4 NetSuite ERP
NetSuite je jedným z popredných poskytovatel’ov cloud ERP riešení (SaaS – softvér ako služba). Cloudové riešenia šetria náklady spoloˇc- ností spojené so zavedením a udržovaním infraštruktúry potrebnej na prevádzku.
NetSuite ERP je postavené modulárne a je jednoducho upravi- tel’né potrebám jednotlivých zákazníkov. Všetky úpravy sú následne zachovávané aj pri automatických prechodoch na novšie verzie sys- tému.
NetSuite ponúka zo spomínaných systémov najmenej ˇco sa týka mobilných klientov pre svoje CRM-ERP systémy. Dve z riešení sú primárne zamerané na Blackberry a starší Windows Mobile –Mobile Edge,Explore Mobile. Tretí –SuiteDroid– je vyvýjaný pre OS Android.
Domovská stránka:http://www.netsuite.com/
3.2 Open source riešenia
3.2.1 xTouple ERP
Spoloˇcnost’ xTouple ponúka svoje open source riešenie v štyroch edí- ciách:
• PostBooks
• Standard
• Manufacturing
• Enterprise
Ako už samotné názvy napovedajú, poˇcet funkcií obsiahnutých v sys- téme postupne stúpa a s nimi aj zameranie na vel’kost’ firmy.
xTouple neponúka mobilného klienta v pravom slova zmysle. Ich riešenie sa nazýva xTouple Mobile Web. Ide o aplikáciu založenú na
3. CRM-ERPSYSTÉMY
HTML5, napísanú v JavaScripte. Dá sa preto spustit’ v prehliadaˇci v každom smartfóne, tablete ˇci stolnom poˇcítaˇci.
Domovská stránka:https://www.xtuple.com/
3.2.2 Compiere
Compiere pôvodne zaˇcínal ako open source projekt poskytovaný pod licenciou GNU GPL. Na Sourceforge patril medzi top 10 produktov medzi rokmi 2002 až 2006. Následne, po príchode investora sa roz- hodli autori svoj produkt ponúkat’ komerˇcne a vznikli tak dve verzie ich systému [16]:
• Community edition – Open source verzia, podporovaná a spra- vovaná komunitou.
• Enterprise edition – Komerˇcná verzia systému s priamou pod- porou výrobcu.
Pre Compiere je jediným dostupným mobilným klientom Com- piere Mobile vyvíjaný firmou Astidian Systems. Funkˇcne ide skôr o prehliadaˇc, ˇcím sa má zabezpeˇcit’ použitel’nost’ na rôznych platfor- mách. GUI je ladené do štýlu iOS, aby bolo jeho používanie prívetivé pre užívatel’ov [19].
Domovská stránka:http://www.compiere.com/products/
3.2.3 Openbravo
Openbravo bol prvýkrát vydaný v roku 2006. Je navrhnutý tak, aby v ˇco najväˇcšej miere podporoval možnosti úprav systému a nezame- riava sa preto na špecifický druh priemyslu. Pristupuje sa k nemu cez internetový prehliadaˇc. Spoloˇcnostiam so vzdialenými poboˇc- kami a pracovníkmi, ktorí musia cestovat’ tak ponúka jednoduché riešenie [6].
Openbravo má k dispozícii niekol’ko aplikácií. Jednu z nich môžu využívat’ zamestnanci na samotnom mieste predaja, napríklad v re- štauráciách. ˇDalšia –Openbravo Analytics– ponúka analýzu dát z in- štancie Openbravo priamo v smartfóne.
Domovská stránka:http://www.openbravo.com/
3. CRM-ERPSYSTÉMY
3.2.4 Tryton
Tryton je systém, ktorého vývoj sa zaˇcal koncom roku 2008 ako ko- munitná verzia systému OpenERP. Napísaný je v jazyku Python a po- užíva databázu PostgreSQL. Skladá sa z troch komponent:
• Klient
• Server
• Moduly
Tryton je dostupný pod licenciou GPLv3 a to pre Linux, Windows a Mac OS X.
Tryton Android, ako je z názvu zrejmé je klient pre Tryton ERP na platforme Android. Je to všeobecný klient a mal by byt’ kompatibilný so všetkými modulmi. Umož ˇnuje prístup k úˇctovníctvu, faktúram, výrobe, skladu atd’.
Domovská stránka:http://www.tryton.org/
4 OpenERP
V predchádzajúcej kapitole sme sa oboznámili s rôznymi CRM-ERP systémami, ktoré sme rozdelili do dvoch skupín podl’a otvorenosti ich kódu. Do skupiny open source riešení patrí aj OpenERP, ktoré je publikované pod licenciou AGPL. OpenERP S.A. ponúka svoj pro- dukt v troch variantách:
• OpenERP Enterprise– Verzia pre podniky pripravená priamo na produkˇcné nasadenie a použitie. Ide však o spoplatnenú verziu. V cene je zahrnutá plná podpora zo strany OpenERP, neobmedzené migrácie na nové verzie systému, záruka na o- pravy chýb a bezpeˇcnostné upozornenia. Zárove ˇn je poskyt- nutá možnost’ pre zákazníkov vytvárat’ si vlastné, súkromné moduly rozšírením licencie na AGPL + Private Use. Firmy tak môžu používat’ open source softvér a zárove ˇn si strážit’ svoje citlivé dáta.
• OpenERP Community– Plná verzia systému so všetkými jeho súˇcast’ami, ale nie je zahrnutá akákol’vek priama podpora zo strany OpenERP, ani migrácie na novšie verzie a nie je možné ani používat’ súkromné moduly. To znamená, že všetky novo vytvorené moduly musia byt’ zverejnené aj so zdrojovými kód- mi komunite. S touto verziou OpenERP pracujeme aj my.
• OpenERP Online – Online verzia ponúka zákazníkom clou- dovú alternatívu voˇci ostatným produktom. Taktiež ako pri ver- zii enterprise ide o spoplatnenú verziu, avšak lacnejšiu. Systém je v tomto prípade umiestnený na serveroch OpenERP a je nimi preto aj spravovaný. V cene sú taktiež zahrnuté zálohy a migrá- cie, nie je však možné používat’ súkromné moduly ani moduly vytvorené komunitou, iba oficiálne.
Vývoj OpenERP zaˇcal v roku 2005, pôvodne pod názvom Tiny ERP. V roku 2008 pri verzii 4.2.X bol následne premenovaný tento systém na dnešné OpenERP a dostupný je už vo verzii 7.0. Napriek tomu, že vývoj našej aplikácie prebiehal ešte pre staršiu verziu 6.1, úpravy potrebné pre fungovanie s najnovšou verziou by v prípade potreby nemali byt’ zásadné. [15]
4. OPENERP
4.1 Architektúra
Systém OpenERP sa skladá z troch komponent –databázový server, aplikaˇcný serveraweb server(v tomto kontexte chápaný ako klient pre aplikaˇcný server) [15].
4.1.1 Databázový server
Databázový server tvorí dátovú vrstvu architektúry OpenERP. Ako relaˇcný a objektový databázový systém je používaný PostgreSQL. Je to vol’ne šíritel’ný, vysoko výkonný open source systém, ktorý je do- stupný pre všetky operaˇcné systémy od Unix/Linux cez Windows až po Mac OS X, Solaris, SunOS a BSD.
Na databázovom serveri sú ukladané databázy jednotlivých in- štancií OpenERP, v ktorých sú ukladané dáta spolu s väˇcšinou nasta- vení. Napriek tomu, že SQL dotazy môžu byt’ vykonávané priamo z OpenERP modulov, väˇcšina prístupov do relaˇcných databáz je vy- konávaných cez objektovo-relaˇcné mapovanie (ORM [13]).
ORM je charakteristickým prvkom systému. Dátové modely sú zadefinované v jazyku Python a OpenERP vytvára tabul’ky v samot- nej databáze. Jej výhody ako sú napríklad relaˇcná integrita, obme- dzenia unikátnosti, efektívne dotazy a iné sa tak spájajú s flexibilitou Pythonu.
4.1.2 Aplikaˇcný server
O všetku vnútornú logiku systému a o to, aby fungoval optimálne sa stará aplikaˇcný server, tvoriaci logickú vrstvu architektúry. Je na- vrhnutý a napísaný ako jadro, ku ktorému môžu byt’ následne do- inštalované d’alšie moduly a vytvorí sa tak špecifická konfigurácia OpenERP. Jadro i moduly sú písané v Pythone.
Na aplikaˇcnom serveri môžu byt’ vytvorené špecifické biznis ap- likácie a obsahuje taktiež kompletný vývojový framework, poskytu- júci rozsah funkcií pre ich vytváranie – ORM, MVC, rozšíritel’né dá- tové modely a pohl’ady a iné.
4. OPENERP 4.1.3 Web server
Web server je samostatná aplikácia s názvomOpen Object client-web, ktorá umož ˇnuje užívatel’om pripojit’ sa k OpenERP pomocou štan- dardného prehliadaˇca. Na komunikáciu s aplikaˇcným serverom vy- užíva protokol NET-RPC. Spolu s GTK klientom je súˇcast’ou prezen- taˇcnej vrstvy architektúry OpenERP.
Je možné všimnút’ si v pomenovaní istú nekonzistentnost’. Jedná sa teda o server alebo klienta? Pre vysvetlenie je potrebné uviest’, že sa na tento komponent môžeme pozerat’ z dvoch uhlov pohl’adu. Pre internetový prehliadaˇc sa javí ako web server, ale naopak z pohl’adu aplikaˇcného servera sa správa ako klient. Záleží teda na kontexte.
4.2 Analýza systému
Z pohl’adu vývoja klienta pre OpenERP je pre nás najdôležitejší ap- likaˇcný server, s ktorým bude aplikácia priamo spolupracovat’. Pre komunikáciu medzi klientmi a serverom sa využíva niektorý z pro- tokolov XML-RPC, NET-RPC alebo JSON-RPC. Posledný menovaný bol pridaný až vo verzii 6.1. My budeme využívat’ prvý z nich – XML-RPC, ktorý si popíšeme bližšie v nasledujúcej kapitole.
Jedným z hlavných rysov OpenERP je jeho modulárnost’, vd’aka ktorej sa dá jednoducho prispôsobit’ potrebám takmer každej spo- loˇcnosti. Pre našu aplikáciu sme sa rozhodli pracovat’ s ˇco najzáklad- nejšou verziou s ˇco najmenším poˇctom modulov, aby bola jednodu- cho nasaditel’ná do väˇcšiny inštancií. Je možné ju preto spustit’ aj nad ˇcistou, novou inštanciou, ale v takom prípade bude dostupná len správa zákazníkov. Pre plnú funkˇcnost’ aplikácie – správa uží- vatel’ov, produktov a objednávok – je potrebné mat’ nainštalovaný modul riadenia predaja (Sales Management).
5 XML-RPC
Webová služba je sadou nástrojov umož ˇnujúcou vývoj aplikácií nad existujúcou webovou infraštruktúrou. Tieto aplikácie využívajú in- ternet ako akúsi transportnú vrstvu, ale neponúkajú priame l’udské rozhranie cez prehliadaˇc.
XML-RPC patrí medzi najjednoduchšie, ale zárove ˇn najspol’ahli- vejšie riešenia webových služieb a zjednodušuje volania procedúr na vzdialených poˇcítaˇcoch. Využíva infraštruktúru, ktorá bola pôvodne vytvorená pre komunikáciu medzi l’udmi, na komunikáciu medzi poˇcítaˇcovými programami. XML poskytuje slovník pre popis vzdia- lených volaní procedúr – RPC (Remote Procedure Call), ktoré sú ná- sledne prenesené medzi poˇcítaˇcmi pomocou HTTP (HyperText Trans- fer Protocol). [18]
5.1 RPC
Volanie vzdialených procedúr je podstatne staršia technológia ako internet. Samotný koncept je v podstate tak starý ako siete, napriek tomu sa Sun Microsystems považuje za tvorcu všeobecného formál- neho mechanismu na volanie procedúr a návrat výsledkov pomocou sietí.
Napriek tomu, že RPC pri svojom fungovaní produkuje naviac isté režijné náklady, s knižnicami na obidvoch stranách pripojenia vytvára a spracováva správy a zárove ˇn môže vzniknút’ aj oneskore- nie spôsobené siet’ou, poskytuje možnost’ ako distribuovane spraco- vávat’ a zdiel’at’ informácie. Jeho koncepcia ul’ahˇcuje prácu progra- mátorom, pretože sa vd’aka RPC nemusia podrobne zaoberat’ štruk- túrou siete, siet’ovými protokolmi ani inými implementaˇcnými de- tailami. Aj programy napísané pre rôzne platformy tak môžu spolu komunikovat’ ak majú spoloˇcnú siet’.
RPC tak dáva vývojárom možnost’ vytvárat’ rozhrania, ktoré mô- žu byt’ volané po sieti, ˇci už ide o jednoduché rozhrania o vel’kosti rádovo jednotiek funkcií alebo komplexné API. [18]
5. XML-RPC
5.2 XML-RPC a Java
Java má vlastný mechanizmus pre vzdialenú komunikáciu a koor- dináciu objektov – RMI (Remote Method Invocation), ktorý je na do- statoˇcne pokroˇcilej úrovni oproti konkurencii. XML-RPC má napriek tomu niekol’ko výhod [18]:
• Odl’ahˇcenost’, jednoduchost’ – odosiela iba parametre miesto celých objektov.
• Jednoduchá konektivita s l’ubovol’ným systémom, ktorý pod- poruje XML-RPC – nemusí sa obmedzovat’ iba na Java systémy využívajúce RMI ani na komplexných CORBA sprostredkova- tel’ov komunikácie.
• XML-RPC využíva len malú ˇcast’ HTTP – Java aplikácie sa tak môžu vyhnút’ nadbytoˇcnej réžii spracovania plného protokolu HTTP a fungovat’ efektívnejšie.
6 Android
V tejto kapitole si predstavíme operaˇcný systém Android. Obozná- mime sa s jeho históriou, ale hlavne sa na ˇn pozrieme z pohl’adu vý- voja mobilných aplikácií.
6.1 Charakteristika
Android je komplexná open source platforma navrhnutá pre mo- bilné zariadenia. Vlastní hoOpen Handset Alliance(OHA), nezisková skupina zložená z kl’úˇcových mobilných operátorov, výrobcov hard- véru, vývojárov a d’alších spoloˇcností, ako napríklad Google, HTC, Intel, Dell, Motorola, LG Electronics, Samsung Electronics, Nvidia atd’. Úlohou tejto širokej aliancie je urýchlit’ vývoj a inovácie v mobil- ných technológiách a ponúknut’ zákazníkom bohatší a lacnejší „záži- tok” z mobilných technológií. Je však stále ešte relatívne mladá a nie- ktorí ˇclenovia sa ešte len uˇcia navzájom spolupracovat’. Momentálne na Androide najviac pracuje samotný Google [7] [5].
6.2 História
Kl’úˇcové momenty v histórii systému Android [7]:
• V roku 2005 Google kúpil Android, Inc. Verejnost’ sa domnieva, že príde na trh s vlastným smartfónom „gPhone”
• Následne, po dlhšej odmlke, až v roku 2007 vznikáOpen Hand- set Alliancea Android oficiálne otvára svoj zdrojový kód a stáva sa open source platformou.
• V roku 2008 je vydaný Android SDK 1.0.Tesne na to prichádza na trh telefón G1 od HTC.
• Nasledujúci rok sa zvyšuje poˇcet zariadení založených na An- droide – je ich viac ako 20. Vychádzajú nové verzie operaˇcného systému: Cupcake (1.5), Donut(1.6) a Eclair (2.0 a 2.1).
6. ANDROID
• Android je za Blackberry druhou najlepšie sa predávajúcou plat- formou pre smartfóny v roku 2010. Vychádza Froyo (Android 2.2) a využíva ho viac ako 60 zariadení.
• V tom istom roku zaˇcal Google vydávat’ sériu zariadení Nexus – vlajkové lode vyrábané jeho partnermi, ktoré majú prezento- vat’ najnovšie vlastnosti systému.
• Aktuálna verzia operaˇcného systému je 4.2.x Jelly Bean
6.3 Verzie a ich zastúpenie
Ako každý softvér aj Android je neustále vyvíjaný a vylepšovaný, pribúda nová funkcionalita a prejavuje sa to na ˇcísle verzie systému.
Prehl’ad všetkých verzií ukazuje nasledujúca tabul’ka 6.1.
Verzia API level Kódové meno Distribúcia
Android 1.0 1 <0.1%
Android 1.1 2 <0.1%
Android 1.5 3 Cupcake <0.1%
Android 1.6 4 Donut 0.1%
Android 2.0 5 Eclair <0.1%
Android 2.01 6 Eclair <0.1%
Android 2.1 7 Eclair 1.7%
Android 2.2 8 Froyo 3.7%
Android 2.3 9 Gingerbread 0.1%
Android 2.3.3 10 Gingerbread 38.4%
Android 3.0 11 Honeycomb <0.1%
Android 3.1 12 Honeycomb <0.1%
Android 3.2 13 Honeycomb 0.1%
Android 4.0 14 Ice Cream Sandwich <0.1%
Android 4.0.3 15 Ice Cream Sandwich 27.5%
Android 4.1 16 Jelly Bean 26.1%
Android 4.2 17 Jelly Bean 2.3%
Tabul’ka 6.1: Verzie OS Android a ich zastúpenie k 1. 5. 2013 [7][2].
6. ANDROID
Obr. 6.1: Relatívne zastúpenie verzií systému Android k 1. 5. 2013 [2].
Dáta k prehl’adu verzií operaˇcného systému Android boli získané z prístupov do Google Play Store poˇcas dvojtýžd ˇnového obdobia, konˇciaceho 1. 5. 2013.
6.4 Architektúra
V tejto podkapitole sa pozrieme podrobne na operaˇcný systém An- droid, konkrétne na jeho architektúru. Jej porozumenie nám pomôže pri programovaní pochopit’ ˇco všetko dokáže.
Skladá sa zo štyroch vrstiev (vid’. 6.2) [7]:
• Linuxové jadro (Linux kernel)
• Knižnice (Libraries, Android runtime)
• Aplikaˇcný framework (Aplication framework)
• Aplikácie (Applications) 6.4.1 Linux kernel
Android je vystavaný nad jadrom operaˇcného systému Linux. Ide o kvalitný systém, ktorý je jedným z hlavných zástupcov open source.
Medzi hlavné dôvody pre jeho výber patrí jeho portabilita, bezpeˇc- nost’ a iné funkcie. [7]
6. ANDROID
Obr. 6.2: Vrstvy OS Android [2].
• Portabilita– Linux je prenosná platforma, ktorá sa dá pomerne jednoducho skompilovat’ na rôznych druhoch zariadení. Tento stupe ˇn abstrakcie hardvéru prináša aj pre Android. Nie je preto potrebné obávat’ sa o hardvér na ktorom pobeží.
• Bezpeˇcnost’– Linux je zárove ˇn vel’mi bezpeˇcný systém, testo- vaný drsnými podmienkami poˇcas desat’roˇcí. Android sa vý- razne spolieha na jeho bezpeˇcnost’ tým, že všetky aplikácie be- žia ako oddelené Linuxové procesy s oprávneniami nastave- nými práve Linuxom, ktorý beží pod ním.
6. ANDROID
• Funkcie– Súˇcast’ou Linuxu je aj množstvo d’alších užitoˇcných funkcií, ktoré Android využíva. Patria sem napríklad podpora správy pamäte, správa napájania, správa sietí a iné.
6.4.2 Knižnice
Sú to C/C++ knižnice prevažne z open source komunity, ktoré po- skytujú potrebné služby aplikaˇcnej vrstve. Okrem iných sú to naprí- klad [7]:
• Webkit – Rýchly engine na zobrazovanie webu, používaný Sa- fari, Chrome a inými prehliadaˇcmi.
• SQLite – Plnohodnotná SQL databáza.
• Apache Harmony – open source implementácia Javy
• OpenGL – Knižnica pre 3D grafiku
• OpenSSL – Open source implementácia protokolu SSL
• Bionic – Prepísaná verzia štandardnej knižnice C z licenˇcných a technologických dôvodov.
6.4.3 Android Java a Dalvik
V Jave je zdrojový kód kompilovaný na Java bitový kód, ktorý sa následne vykonáva v Java VM. Java VM však nie je vol’ne dostupný, preto Dan Bornstein a jeho tím v Google vyvinuli virtuálny stroj, špe- ciálne navrhnutý pre Android – Dalvik. Aby ten vedel príkazy spra- covat’, musí byt’ Java bitový kód skompilovaný do Dalvik bitového kódu.
Android Java nie je súborom tried štandardnej Javy. Najbližšie má k Java SE. Hlavný rozdiel je v tom, že knižnice užívatel’ského ro- zhrania (AWT a Swing) boli nahradené knižnicami špecifickými pre Android. Naviac pridáva aj d’alšie funkcie, no zachováva väˇcšinu tých pôvodných.
6. ANDROID
6.4.4 Aplikaˇcný framework
Aplikaˇcný framework je funkˇcne bohaté prostredie, ktoré poskytuje služby vývojárom pri vykonávaní ich práce. Je to najlepšie zdokume- tovaná ˇcast’ systému, pretože dáva programátorom nástroje pre vý- voj kvalitných, kreatívnych aplikácií. Patrí medzi ne množstvo Java knižníc špeciálne vytvorených pre Android, ale aj služieb a mana- žérov sprostredkujúcich využívanie schopností telefónu – Wifi, sen- zory, lokáciu zariadenia a iné.
6.4.5 Aplikácie
Poslednou vrstvou je vrstva samotných aplikácií, medzi ktoré patrí aj náš klient pre OpenERP. Sú to práve aplikácie, ktoré si mnohí uží- vatelia najviac cenia na Androide.
Aplikáciu tvorí jeden balík – APK súbor, ktorý sa skladá z troch hlavných ˇcastí:
• Dalvik spustitel’ný súbor – Zdrojový kód skompilovaný pre Dalvik VM, na základe ktorého aplikácia beží.
• Zdroje– Sem patrí všetko, ˇco nie je kód. Aplikácie môžu obsa- hovat’ okrem kódu aj obrázky, videá, XML súbory popisujúce rozvrhnutie obrazoviek aplikácie, jazykové balíky a pod.
• Natívne knižnice– V niektorých prípadoch môžu aplikácie ob- sahovat’ aj natívny kód ako napríklad C/C++ knižnice, ktoré môžu byt’ zabalené spolu v APK súbore.
6.5 Vývoj aplikácií
Ako sme si ukázali v podkapitole 6.3, na trhu sú dostupné zariade- nia s rôznymi verziami systému Android. Túto skutoˇcnost’ musia zohl’adnit’ aj vývojári pri návrhu a implementácii svojich aplikácií výberom minimálnej a ciel’ovej verzie.
Ciel’ová verzia urˇcuje typ systému Android, na ktorom sa apliká- cia plánuje používat’. Minimálna väˇcšinou korešponduje s ciel’ovou
6. ANDROID
verziou, ale ak sa aplikácia nespolieha na najnovšie API alebo do- káže pracovat’ aj so staršími, tak môže byt’ nastavená nižšia verzia ako je ciel’ová [7].
V našej aplikácii sme sa rozhodli pre minimálnu verziu API 11 – Android 3.0 Honeycomb. Obsahuje množstvo noviniek, ktoré sme využili aj pri implementácii a niektoré z nich si popíšeme.
Podpora viacjadrových architektúr procesorov
Android 3.0 je prvou verziou systému, ktorá bol navrhnutá aby fun- govala na jedno aj viacjadrových architektúrach procesorov. Bolo po- trebné vykonat’ pre to množstvo zmien vo virtuálnom stroji Dalvik, knižnici Bionic a inde. Z týchto úprav profitujú všetky aplikácie, vrá- tane jednovláknových. Ak jednovláknovú aplikáciu spustíme na za- riadení s viacerými jadrami, systém automaticky zariadi, aby na dru- hom jadre bol spustený napr.garbage collectora zrýchli tak ˇciastoˇcne beh aplikácie [3].
Aktivity a fragmenty
Aktivitou sa obyˇcajne nazýva jedna obrazovka, ktorú v danom ˇcase vidí užívatel’ na zariadení. Aplikácia sa skladá z niekol’kých akti- vít, medzi ktorými sa užívatel’ môže pohybovat’ [7]. Od API verzie 11 (Obr. 6.1) ponúka Android naviac fragmenty. Ide o akési „pod- aktivity”, ktoré musia byt’ umiestnené v aktivitách. Môžu však byt’
použité modulárne na viacerých miestach v aplikácii.
Ich využitie nájdeme napríklad v aplikáciách, ktoré podporujú aj zobrazenie na tabletoch. Kedže tablety majú väˇcšiu obrazovku, ap- likácie, ktoré na ˇnom bežia môžu ˇcasto zobrazovat’ viac fragmentov naraz. Naopak ak je tá istá aplikácia spustená na menšom smartfóne, je možné to detekovat’ a zobrazit’ každý fragment v samostatnej ak- tivite.
Action Bar
Novinkou je tiež takzvanýAction Bar– ovládacia lišta v hornej ˇcasti obrazovky. V aplikácii môže byt’ využitý pre rýchly prístup užívate- l’ov ku kontextovému menu (nahrádza tým tlaˇcítko Menu na starších
6. ANDROID
zariadeniach), rôznym nástrojom, navigácii a d’alším ovládacím prv- kom. Vývojári tak sprostredkúvajú viacero funkcií na jednom mieste a zjednocujú tak ich používanie naprieˇc aplikáciou [3].
Spätná kompatibilita
Z pohl’adu vývoja aplikácií je dôležité aby staršie aplikácie bez prob- lémov fungovali na nových zariadeniach. Android 3.0 napriek množ- stvu noviniek, ktoré boli zavedené, je plne spätne kompatibilný s ap- likáciami vyvinutými pre staršie verzie systému [3].
7 Analýza a návrh
V tejto kapitole sa budeme venovat’ analýze systému OpenERP. Obo- známime sa s jeho webovým rozhraním a zameriame sa na to, akým spôsobom je používaný obchodníkom pri vykonávaní svojej práce.
Zo získaných poznatkov následne zanalyzujeme akú funkciona- litu by mala naša aplikácia ponúknut’ a v akej forme tak, aby ostala intuitívna pre užívatel’ov štandardného webového klienta.
Výstupom tejto analýzy a návrhu budú diagramy prípadov užitia a tried, nachádzajúce sa v závereˇcnej ˇcasti kapitoly.
7.1 OpenERP 6.1
Obrazovka, ktorá sa zobrazí užívatel’ovi po prihlásení do systému sa dá každému osobitne nastavit’. Implicitne sa však zobrazí ponuka dostupných ˇcastí systému – Predaj, Sklad, Úˇctovníctvo, Nastavenia a d’alšie (vid’. 7.1). K presunu do inej ˇcasti systému môžu byt’ využité vel’ké ikony v strede obrazovky, menšie ikony, ktoré sa nachádzajú nad nimi v navigaˇcnom paneli alebo užívatel’ské skratky nad pane- lom.
Obr. 7.1: Úvodná obrazovka OpenERP [17]
7. ANALÝZA A NÁVRH
7.1.1 Zákazníci
Pri zobrazovaní záznamov v OpenERP sa využívajú prevažne dva druhy pohl’adov – tzv. stromový (Obr. 7.2) a formulár (Obr. 7.3).
Stromový pohl’ad zobrazuje všetky záznamy v prehl’adnej tabul’- ke. V našom prípade je to tabul’ka so zákazníkmi, ktorej st´lpce zo- brazujú najdôležitejšie údaje – meno, telefón, e-mail, mesto, krajinu a priradeného obchodníka.
Obr. 7.2: OpenERP – Zákazníci [17]
Formulár naopak zobrazuje bližšie informácie o jednom konkrét- nom zázname – zákazníkovi. V tomto pohl’ade už nájdeme v poliach všetky o ˇnom dostupné informácie. Modrým podfarbením sú ozna- ˇcené tie, ktoré sú povinné. Tento formulár sa používa pri vytváraní nových zákazníkov, ale aj pri zobrazovaní a úprave tých existujúcich.
Pre užívatel’a je teda dôležitý prehl’adný zoznam zákazníkov s naj- dôležitejšími údajmi. A následne po výbere konkrétneho zákazníka zobrazenie jeho bližších, podrobnejších informácií. Pri pridávaní no- vého zákazníka do systému užívatel’ jednoducho vyplní všetky po- vinné a l’ubovol’né nepovinné polia a klikne na tlaˇcítko Uložit’, ktoré je umiestnené v l’avom hornom rohu (Obr. 7.3).
7. ANALÝZA A NÁVRH
Obr. 7.3: OpenERP – Zákazníci, editovací formulár [17]
7.1.2 Produkty
Dalšou ˇcast’ou systému, s ktorou prichádza obchodník do styku priˇ svojej práci, je správa produktov. V st´lpcoch tabul’ky všetkých pro- duktov sú zobrazené: referencia (odkaz), názov, merná jednotka, typ výrobku, množstvo na sklade, dostupné množstvo, verejná cena, vý- robná cena a stav produktu (Obr. 7.4).
Pri upravovaní parametrov produktu alebo pri vytváraní nového, je štandardne využitý editovací formulár (Obr. 7.5). Je možné si všim- nút’, že povinných polí je pri produktoch viac. Pre užívatel’a to však nie je nijak zásadná komplikácia, pretože okrem mena majú všetky polia nastavené implicitné hodnoty.
Obchodník túto ˇcast’ systému využíva väˇcšinou v prípadoch kedy potrebuje do OpenERP pridat’ nový produkt alebo upravit’ para- metre niektorého z už existujúcich. Pri vytváraní objednávok pristu- puje k produktom nepriamo cez previazané pole vo formulári objed- návky.
7. ANALÝZA A NÁVRH
Obr. 7.4: OpenERP – Produkty [17]
Obr. 7.5: OpenERP – Produkty, editovací formulár [17]
7. ANALÝZA A NÁVRH
7.1.3 Predaje
Predaje sú pre obchodníka najdôležitejšou ˇcast’ou systému. Tu si vy- tvára, spravuje predajné objednávky a sleduje ich životný cyklus od návrhu až po úspešné dokonˇcenie alebo zrušenie. Stav objednávky je zobrazený aj pri stromovom pohl’ade zárove ˇn s d’alšími základnými informáciami ako sú kód ojednávky, dátum, zákazník, zodpovedný obchodník, suma bez dane, celková suma a informácie o tom ˇci je ob- jednávka vyfaktúrovaná a objednané produkty pripravené k odberu (Obr. 7.6).
Pri vytváraní novej predajnej objednávky sa obchodníkovi zo- brazí obdobný formulár ako v predchádzajúcich prípadoch (Obr. 7.7).
Niektoré z polí sú predvyplnené implicitnými alebo vygenerovanými hodnotami. Je potrebné doplnit’ zákazníka a samotné riadky objed- návky. Zákazník sa vyberá pomocou pol’a previazaného s doménou zákazníkov. Táto väzba užívatel’ovi poskytuje funkcie automatické- ho doplnenia, vyhl’adania alebo vytvorenia zákazníka.
Obr. 7.6: OpenERP – Predaje [17]
Riadky objednávky sa pridávajú tlaˇcítkom vytvorit’ (Obr. 7.7).
V okne, ktoré sa následne zobrazí, sa podobne ako zákazník vybe-
7. ANALÝZA A NÁVRH
rie tentokrát produkt a zvyšné údaje, ako napríklad cena, sa doplnia automaticky (je však možné ich ešte upravovat’). Zadá sa už len po- žadované množstvo. Hotovú objednávku je následne možné potvr- dit’ – zmení sa tým jej stav.
Obr. 7.7: OpenERP – Predaje, editovací formulár [17]
Zákazníkov a produkty je možné kedykol’vek upravovat’. U ob- jednávok je to trochu zložitejšie. Upravovat’ je možné len tie pre- dajné objednávky, ktoré sú v stave Návrh (Draft). V prípade, že je nutné upravit’ schválenú objednávku, musí sa najprv zrušit’ a ná- sledne previest’ spät’ naNávrh.
7.2 Android OpenERP Client
Ako je možné vidiet’ na snímkach z webového rozhrania, OpenERP je komplexný a pomerne zložitý CRM-ERP systém. Pre jeho pohodlné a prehl’adné používanie obchodníkom aj na mobilných zariadeniach je preto potrebné, aby bol poˇcet informácií zredukovaný na tie naj- dôležitejšie údaje danej ˇcasti systému.
Podobne ako v prehliadaˇci, ani v našej aplikácii sa dáta nebudú lokálne ukladat’ a všetky operácie budú vykonávané online, priamo na serveri prostredníctvom XML-RPC protokolu.
7. ANALÝZA A NÁVRH
7.2.1 Prihlásenie
Po spustení aplikácie, rovnako ako vo webovom rozhraní, sa uží- vatel’ najprv prihlási (Obr. 7.8). Okrem štandardných údajov ako sú užívatel’ské meno a heslo, vyplní informácie o pripojení – URL ad- resu servera, na ktorom beží OpenERP a názov databázy, do ktorej sa pripája.
Neustále vypl ˇnovanie všetkých údajov pri každom prihlásení by bolo užívatel’sky výrazne neprívetivé. Preto aplikácia ponúkne mož- nost’ ich zapamätania.
Obr. 7.8: Klient – Uvítacia obrazovka, prihlásenie
Po prihlásení do systému sa užívatel’ovi naskytne podobný po- hl’ad ako pri využití webového klienta. Hlavné menu zobrazí ikony zodpovedajúce dostupným ˇcastiam systému – Predaje, Zákazníci, Produkty (Obr. 7.9).
7. ANALÝZA A NÁVRH
Obr. 7.9: Klient – Hlavné menu
7.2.2 Zákazníci
Zoznam zákazníkov, ktorý sa zobrazí v tabul’ke pri vstupe do tejto ˇcasti systému bude slúžit’ ako obdoba stromového pohl’adu vo we- bovom klientovi (Obr. 7.10). Pre jednoduchost’ a prehl’adnost’ bude potrebné zmenšit’ poˇcet vypísaných údajov. Zobrazené budú nako- niec meno zákazníka a jeho kontakty – telefón a e-mail, aby boli pri používaní jednoducho dostupné. Z webového klienta budú prevzaté aj umiestnenia tlaˇcítok pre vytvorenie nového zákazníka vl’avo hore a úpravu zákazníka vl’avo pri každom zázname.
Rovnako štandardne má fungovat’ aj zobrazenie detailu zákaz- níka kliknutím na jeho riadok v tabul’ke. V tomto zobrazení bude dostupných viac informácií, nie však všetky, aby bola zachovaná pre- hl’adnost’.
Pri úprave údajov a vytváraní zákazníka bude použité rovnaké rozloženie ako pri zobrazení jeho detailov, polia však budú editova-
7. ANALÝZA A NÁVRH
Obr. 7.10: Klient – Zákazníci
Obr. 7.11: Klient – Úprava zákazníka a kontaktu
7. ANALÝZA A NÁVRH
tel’né (Obr. 7.11). Pribudne len tlaˇcítko na pridanie nového kontaktu, po stlaˇcení ktorého sa zobrazí zadávací formulár. Pre editáciu exis- tujúceho kontaktu na zobrazenom kontakte užívatel’ dlhšie podrží prst. V tomto prípade sa zobrazí rovnaký formulár, ale s predvypl- nenými údajmi.
7.2.3 Produkty
Sekcia produktov bude z pohl’adu používania podobná predchádza- júcej ˇcasti. V úvodnej tabul’ke sa zobrazí meno produktu, dostupné množstvo a jeho cena – informácie najpotrebnejšie pre obchodníka pri svojej práci (Obr. 7.12).
Pri zobrazení konkrétneho produktu potom pribudnú d’alšie úda- je ako množstvo na sklade, základná merná jednotka alebo kód Ean13.
Obr. 7.12: Klient – Produkty
Úprava existujúceho a vytváranie nového produktu bude prebie- hat’ na obrazovke podobnej zobrazeniu jeho detailu (Obr. 7.13). Na- viac tam bude pridané tlaˇcítko, pomocou ktorého sa spustí aplikácia
7. ANALÝZA A NÁVRH
Obr. 7.13: Klient – Úprava produktu
pre naskenovanie Ean kódu. Naopak, vynechané budú polia s množ- stvom dostupného produktu, pretože sa nedajú upravit’ priamo.
7.2.4 Predaje
Poslednou ˇcast’ou aplikácie, s ktorou budú užívatelia pracovat’ je sekcia predaja. V zozname predajných objednávok budú zobrazené základné údaje – ˇcíslo objednávky, zákazník, dátum a celková suma (Obr. 7.14). Pri tomto zobrazení bude môct’ užívatel’ jednoducho roz- líšit’ rôzne stavy objednávok podl’a sfarbenia ich ˇcísla.
Vytváranie objednávok má kopírovat’ správanie webového kli- enta. Bude staˇcit’ preto zadat’ partnera a pridat’ riadky objednávky, ktoré bude možné pridat’ dvoma spôsobmi. Bud’ výberom zo zo- znamu (Obr. 7.15), alebo naskenovaním ˇciarového kódu produktu.
7. ANALÝZA A NÁVRH
Obr. 7.14: Klient – Predajné objednávky
Obr. 7.15: Klient – Úprava objednávky a pridávanie produktov
7. ANALÝZA A NÁVRH
7.2.5 Vyhl’adávanie
Môžeme si všimnút’, že pri každom stromovom pohl’ade vo webo- vom rozhraní je aj ˇcast’ pre vyhl’adávanie v danom zobrazení. Je to dôležitá a ˇcasto využívaná ˇcast’ systému, preto by táto funkcionalita nemala chýbat’ v našej aplikácii. V hornej ˇcasti zobrazení produktov, zákazníkov a predajných objednávok sa bude nachádzat’ zadávacie pole s tlaˇcítkom pre vyhl’adanie. Po jeho stlaˇcení sa v tabul’ke ná- sledne zobrazia zodpovedajúce výsledky (Obr. 7.16).
Obr. 7.16: Klient – Vyhl’adanie produktov
7.3 Diagramy prípadov užitia a tried
Z analýzy využívania systému OpenERP obchodníkom sme vytvo- riliUse Casediagram – digram prípadov užitia (Obr. 7.17). Názorne nám zobrazuje komunikáciu užívatel’a, obchodníka so systémom.
7. ANALÝZA A NÁVRH
Poˇcas následného návrhu našej aplikácie vznikli diagramy tried, rozdelené podl’a jednotlivých ˇcastí aplikácie – produkty (Obr. 7.18), zákazníci (Obr. 7.19) a predaje (Obr. 7.20). Zobrazujú budúcu štruk- túru systému a vzt’ahy medzi jednotlivými triedami.
Obr. 7.17: Diagram prípadov užitia
Obr. 7.18: Diagram tried – produkty
7. ANALÝZA A NÁVRH
Obr. 7.19: Diagram tried – zákazníci
Obr. 7.20: Diagram tried – predaje
8 Implementácia
Naša aplikácia bola implementovaná inkrementálne po jednotlivých ˇcastiach – zákazníci, produkty a predaje. Diagramy tried k jednotli- vým ˇcastiam je možné nájst’ v predchádzajúcej kapitole – Obr. 7.19, 7.18 a 7.20.
Poˇcas vývoja bola testovaná na virtuálnych zariadeniach, ktoré poskytuje emulátor vývojového prostredia Android SDK [7] ale aj na fyzických, konkrétne na HTC Desire X a Sony Ericsson Xperia Neo MT15i.
8.1 Použité knižnice
Pri implementácii našej aplikácie boli použité aj tri externé knižnice.
Dve z nich zabezpeˇcujú komunikáciu s OpenERP serverom pomo- cou protokolu XML-RPC a tretia slúži na sprostredkovanie aplikácie na skenovanie kódov Ean13.
8.1.1 Android-xmlrpc
Komponent, ktorý zabezpeˇcuje komunikáciu s OpenERP serverom cez protokol XML-RPC je jednoduchá, ale kompletná knižnica pre platformu Android – android-xmlrpc.1
Jej použitie je pomerne jednoduché. Najskôr si nainicializujeme klienta a následne na ˇnom zavoláme metóducalls parametrami, ktoré obsahujú názov procedúry a jej parametre.
1 XMLRPCClient client =newXMLRPCClient("http://your.url.com");
2
3 int intResult = (Integer) client . call ("testFunction1", 1, 3) ;
4 booleanboolResult = (Boolean) client . call ("testFunction2", param1, 4, 10) ;
5 String strResult = (String) client . call ("testFunction3", " test string ") ;
1. Knižnica android-xmlrpc je dostupná na stránke http://code.google.
com/p/android-xmlrpc/
8. IMPLEMENTÁCIA
8.1.2 Android-openerp
Android-xmlrpc využíva knižnica android-openerp v triede Open- ErpConnect, ktorá slúži ako konektor k OpenERP serveru pre zaria- denia Android.2 Je dostupná ako open source pod licenciou GNU GPL.
Niektoré z funkcií, ktoré poskytuje android-openerp:
• Prihlásenie – Zabezpeˇcuje ho funkciaconnect. Pri jej zavolaní sa vytvorí spojenie, ktoré sa následne používa poˇcas behu ap- likácie.
1 OpenErpConnect.connect(
2 mServer,
3 mPort,
4 mDatabase,
5 mUserName,
6 mPassword );
• Vyhl’adávanie – Pre zobrazenie prvkov systému, napr. produk- tov, je potrebné najprv ich vyhl’adat’. Funkcia search nájde zoznam ID zodpovedajúcich záznamov.
1 connection.search(
2 mModel,
3 mCount,
4 mOffset,
5 mLimit,
6 mOrder,
7 mReverseOrder,
8 mConditions );
• Cítanie – Po získaní zoznamu ID záznamov môžeme zavolat’ˇ funkciu read pre naˇcítanie hodnôt ich polí (názov produktu a pod.).
1 connection.read(
2 mModel,
3 mIds,
4 mFields );
2. https://github.com/zikzakmedia/android-openerp
8. IMPLEMENTÁCIA
• Všeobecné volanie – Používa sa ak je potrebné zavolat’ metódu v systéme, ktorú nepokrýva žiadna z ponúkaných funkcií.
1 connection.call (
2 mModel,
3 mMethod,
4 mParams);
8.1.3 ZXing
ZXing (Zebra Crossing) je open source knižnica napísaná v Jave, ktorá slúži na spracovanie ˇciarových kódov v rôznych formátoch (1D aj 2D). Jej úˇcelom je za využitia vstavanej kamery zariadenia naskeno- vat’ kód a následne ho dekódovat’ bez nutnosti komunikácie so ser- verom. Medzi podporované formáty patria napríklad EAN-8, EAN- 13, UPC-A, UPC-B, QR Code, Code 39 a d’alšie.3
V našej aplikácii využívame komponentuandroid-integration, kto- rá slúži na prepojenie s aplikáciou na ˇcítanie kódov Barcode Scanner vyvinutou taktiež tímom ZXing.
8.2 Implementaˇcné detaily aplikácie
Zdrojový kód aplikácie je rozdelený do niekol’kých balíkov podl’a funkcionality.
• Tri balíky, ktoré obsahujú externé knižnice, popísané v pred- chádzajúcej ˇcasti:
com.google.zxing.integration.android org.xmlrpc.android
cz.cloudtech.openerpclient.connection
• Dalšie tri balíky obsahujú triedy rozdelené podl’a jednotlivýchˇ modulov:
cz.cloudtech.openerpclient.customers cz.cloudtech.openerpclient.products cz.cloudtech.openerpclient.sales
3. Kompletný zoznam podporovaných kódov a viac informácii o ZXing je možné nájst’ nahttp://code.google.com/p/zxing/
8. IMPLEMENTÁCIA
• Balík obsahujúci triedy zodpovedné za úvodnú a prihlasovaciu obrazovku:
cz.cloudtech.openerpclient
• V poslednom balíku sú umiestnené triedy, ktoré zabezpeˇcujú komunikáciu so serverom. Ich funkciu si bližšie popíšeme v na- sledujúcej ˇcasti.
cz.cloudtech.openerpclient.async
8.2.1 AsyncTask
Komunikácia so serverom býva ˇcasto ˇcasovo nároˇcná. Ak by prebie- hala na hlavnom vlákne aplikácie, na ktorom beží aj správa grafic- kého rozhrania, malo by to za následok mrznutie aplikácie. Android má proti nereagujúcim aplikáciám ochranu a po urˇcitom ˇcase zobrazí varovný dialóg.
Aby sme sa takémuto správaniu vyhli, využívame v našej apliká- cii trieduAsyncTask. ˇCasovo nároˇcné operácie sme implementovali v jej metódedoInBackground(). Pre následné spustenie vykoná- vania v samostatnom vlákne treba vytvorit’ inštanciu triedy, ktorá rozširujeAsyncTaska zavolat’ na nej metóduexecute().
1 AsyncTask aTask =newAsyncCustomerSearchRead(
2 params).execute();
Poˇcas jej behu je potrebné aby sme nejakým spôsobom oznámili užívatel’ovi, že aplikácia nezamrzla a stále pracuje. Využívame na to funkcionalitu, ktorú nám poskytujeActionBar– neurˇcitý indikátor priebehu (Indeterminate Progress Bar).
1 requestWindowFeature(Window.FEATURE_INDETERMINATE_PROGRESS);
2 setProgressBarIndeterminateVisibility(true) ;
Ked’doInBackground()ukonˇcí svoje vykonávanie, tak sa spus- tí metóda onPostExecute(), v ktorej môže prebiehat’ následné spracovanie výsledkov a môže pracovat’ aj s užívatel’ským rozhra- ním. Na tomto mieste taktiež vypneme indikátor priebehu nastave- ním viditel’nosti nafalse.
8. IMPLEMENTÁCIA
8.2.2 Zobrazenie dát
Dáta získané zo servera pomocou asynchrónnych volaní následne potrebujeme zobrazit’ užívatel’ovi. V rôznych ˇcastiach systému ich zobrazujeme pomocou rozliˇcných tried API.
Pri zobrazení detailov záznamu používame jednoduché textové polia –TextView. V prípadoch, kedy potrebujeme záznam upravo- vat’ používame editovatel’né polia –EditText, zaškrtávacie políˇcka –CheckBoxa rolovacie ponuky –Spinner. Pri zobrazovaní kontak- tov zákazníka využívame viacstránkové zobrazenie –ViewFlipper, ktorého reakcie na gestá sú definované v metódeonFling()v triede CustomerDetail. Pomocou nich sa medzi záznamami užívatel’ po- hybuje.
8.2.3 Rotácia zariadenia
Pri otáˇcaní mobilného zariadenia zo zvislej do vodorovnej polohy alebo naopak sa mení rozloženie obrazovky. Môže nastat’ situácia, že niektoré prvky zobrazenia nie sú v obidvoch rozvrhnutiach rovnako dobre dostupné. Preto Android ponúka možnost’ ako mat’ pre každú z pozícií vlastné rozloženie.
Obr. 8.1: Zákazníci – Pôvodné rozloženie
8. IMPLEMENTÁCIA
Obr. 8.2: Zákazníci – Upravené rozloženie
Bežne sa XML súbory definujúce rozloženie jednotlivých obrazo- viek ukladajú do adresára res/layout/. Ak však chceme aby sa pre zobrazenie vo vodorovnej polohe použil iný súbor umiestnime ho do adresárares/layout-land/s rovnakým názvom. Výsledok si môžeme porovnat’ na obrázkoch 8.1 a 8.2.
Problémy s rotáciou
Pri implementácii sa nám vyskytli aj isté problémy s rotáciou zaria- denia. Konkrétne išlo napríklad o prípad, ked’ sa pri zobrazení dia- lógu pre výber produktu do objednávky zariadenie otoˇcilo a apli- kácia následne havarovala. Bolo to spôsobené tým, že sme sa triede DialogFragment snažili predat’ parametre pret’ažením konštruk- tora. Android však pri rotácii DialogFragment zniˇcí a znovu ob- noví. Volá pri tom bezparametrový konštruktor a k predaným para- metrom sa už nemá ako dostat’.
Riešením bolo zmenit’ spôsob vytvárania dialógu. Bežne sa vy- tvára v metódeonCreateDialogtriedy rozširujúcejDialogFrag- ment. V aplikácii sa následne po inicializácii zobrazí pomocou me- tódyshow(). Pre zobrazenie dilógu bez predávania parametrov ten- to spôsob funguje správne.
8. IMPLEMENTÁCIA
1 NoProductFoundDialog productNotFound =new NoProductFoundDialog();
2 productNotFound.show(getFragmentManager(),"no_product_found");
Ak však chceme využit’ aj parametre musíme tento postup upravit’
pridaním statickej metódy newInstance(), ktorá dialóg nainicia- lizuje, parametre uloží do statickej premennej a vráti. Na vrátenom dialógu už môžeme zavolat’ metódu show() ako v predchádzajú- com prípade.
1 private static Object[] mParams;
2 public static SalesOrderProductDialog newInstance(Object[] params) {
3 SalesOrderProductDialog d =newSalesOrderProductDialog();
4 mParams = params;
5
6 return d;
7 }
1 SalesOrderProductDialog productDialog = SalesOrderProductDialog.newInstance();
2 productDialog.show(getFragmentManager(),"find_product");
8.2.4 Lokalizácia
Lokalizácia je vyriešená obdobným spôsobom ako rozloženia akti- vít. Aplikácii je poskytnutý implicitný súbor s textovými ret’azcami umiestnený v adresárires/values/strings.xml. Tento súbor je použitý ak je vyžadovaný jazyk, ktorý aplikácia nepodporuje. Sú- bory pre d’alšie jazyky sú uložené v prieˇcinkoch oznaˇcených daným kódom jazyka ako napríkladres/values-en/strings.xml, ale- bores/values-cs/strings.xmla d’alšie.
V súboroch strings.xml sa nachádzajú záznamy v tvare<string name=”id”>Retazec</string>. V kóde sa potom na miestach, kde by sa bežne použil textový ret’azec, použije odkazR.string.id.
Použitý jazyk sa vyberá na základe nastavenia telefónu.
8. IMPLEMENTÁCIA
8.2.5 Aktivity a fragmenty
Naša aplikácia nebola primárne navrhovaná pre podporu tabletov, napriek tomu ˇcast’ systému, ktorá je venovaná zákazníkom využíva túto technológiu. Výsledok je možné vidiet’ na nasledujúcom ob- rázku (8.3), kde je oproti smartfónu naraz zobrazený zoznam zákaz- níkov aj detail jedného z nich.
Obr. 8.3: Zákazníci – Zobrazenie na tablete
9 Záver
Ciel’om tejto diplomovej práce bolo navrhnút’ a implementovat’ mo- bilného klienta pre CRM-ERP systém OpenERP na mobilné zariade- nia s operaˇcným systémom Android. Výsledná aplikácia má poskyt- nút’ obchodníkom, ktorí pracujú so systémom OpenERP možnost’
využívat’ jeho funkcie aj v teréne, mimo svojej kancelárie.
Po analýze a návrhu sa nám úspešne podarilo aplikáciu imple- mentovat’ a je pripravená na testovaciu prevádzku v reálnych pod- mienkach a na následné nasadenie do ostrej prevádzky. Môže tak plnit’ úˇcel, pre ktorý bola navrhnutá.
Ako každý program aj naša aplikácia má potenciál pre d’alší vý- voj a je potrebné, aby ho v budúcnosti využila. Jednou z možností kam smerovat’ napredovanie našej aplikácie je jej optimalizácia pre využitie na tabletoch. Tie zaznamenávajú výrazný nárast v ich po- užívaní, preto by bolo vhodné zamerat’ sa na túto oblast’. V prvom rade by bolo treba navrhnút’ nové rozloženia obrazoviek, ktoré by boli primerane prispôsobené vel’kým obrazovkám tabletov. Využili by sa k tomu fragmenty vo výraznejšej miere ako v aktuálnej verzii.
Dalej bude potrebné upravit’ aj ostatné grafické prvky ako sú ikony,ˇ dotykové ovládacie prvky a aj samotný text. Ich vel’kosti musia byt’
adekvátne upravené aby zodpovedali vel’kostiam obrazoviek table- tov.
OpenERP, ako väˇcšina CRM a ERP systémov, má tú vlastnost’, že je modulárny. Každá firma má tieto systémy upravené podl’a vlast- ných potrieb. Preto je dôležité aby aj naša aplikácia bola pri použití konkrétnym klientom vhodne upravená, prípadne doplnená o d’al- šie moduly, ak to bude potrebné. Z pohl’adu vývoja aplikácie to zna- mená, že sa budú musiet’ zobrazované polia – napr. v detaile pro- duktu – upravit’ podl’a požiadaviek zákazníka. Iné informácie o pro- duktoch si žiada výrobná firma a iné napríklad špediˇcná. V prípade, že zákazník bude používat’ v OpenERP d’alší modul a bude chciet’, aby bol taktiež dostupný aj cez nášho klienta, bude potrebné ho do- programovat’. Všetky ˇcasti našej aplikácie sú samostatné a nezávislé, preto nebude problém obdobne ho pridat’.
Poˇcas implementácie sa taktiež vyskytlo niekol’ko menších kom- plikácií. Väˇcšinu z nich sa však podarilo úspešne vyriešit’. Najˇcas-
9. ZÁVER
tejšie spôsobovala problémy rotácia zariadenia. Jedným z použitých riešení je napríklad doˇcasné uzamknutie rotácie poˇcas behu „kritic- kých” metód.
Coskoro sa naša aplikácia zaˇcne používat’ v reálnom prostredíˇ obchodnej firmy a bude sa tak moct’ d’alej vyvíjat’ a zlepšovat’.
A Príloha – CD
- Text práce
- Zdrojové kódy aplikácie
- Inštalaˇcný .apk balík s aplikáciou
Literatúra
[1] Bryan Bergeron. Essentials of CRM : A Business Guide to Cus- tomer Relationship Management. John Wiley & Sons, Inc., 2002.
[2] Android Developers. Dashboard. online,
2013 [cit. 20 Mája 2013]. Dostupné na adrese:
http://developer.android.com/about/dashboards/index.html.
[3] Android Developers. Honeycomb. online,
2013 [cit. 20 Mája 2013]. Dostupné na adrese:
http://developer.android.com/about/versions/android- 3.0-highlights.html.
[4] Jill Dyché. The CRM Hanbook: A Business Guide to Customer Relationship Management. Addison-Wesley, 2004.
[5] Ben Elgin. Google buys android for its mobile ar- senal. online, 2005 [cit. 20 Mája 2013]. Dostupné na adrese: http://www.businessweek.com/stories/2005-08- 16/google-buys-android-for-its-mobile-arsenal.
[6] Gruman Galen. Is open source the answer to erp?CIO, 20(9):24, 2007.
[7] Marko Gargenta. Learning Android. O’Reilly Media, Inc., 2011.
[8] Barton J. Goldenberg. CRM Automation. Prentice Hall PTR, 2003.
[9] Barton J. Goldenberg. CRM in Real Time. CyberAge Books, 2008.
[10] Eliotte Rusty Harold and W. Scott Means. XML in a Nutshell, Third Edition. O’Reilly Media, Inc., 2004.
[11] Peter Jones and John Burger. Configuring SAP ERP Financials and Controlling. Wiley Publishing, 2009.
