Brandlink Business-to-Business E-commerce web Solution. Master of Science Thesis MUHAMMAD ALI NASIR JANJUA MUHAMMAD ARIF

Transcription

1 Brandlink Business-to-Business E-commerce web Solution Master of Science Thesis MUHAMMAD ALI NASIR JANJUA MUHAMMAD ARIF Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering Göteborg, Sweden, June 2013 I

2 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Brandlink Business to Business E-commerce web Solution Master of Science Thesis Host organization: Speedment AB Kilsgatan 10 Post Code Göteborg, Sweden Tel: Supervisor: Per-Åke Minborg Chief Technical Officer (CTO), Speedment AB Göteborg Sweden ( Telephone minborg@speedment.com Examiner: Graham Kemp Chalmers University of Technology University of Gothenburg Department of Computer Science and Engineering SE Göteborg Sweden Telephone +46-(0) kemp@chalmers.se Muhammad Ali Nasir Janjua Muhammad Arif Muhammad Ali Nasir Janjua, June Muhammad Arif, June Department of Computer Science and Engineering Göteborg, Sweden June 2013 II

3 ABSTRACT Today, business is moving rapidly towards web technologies due to their portability, efficiency and multi-platform compatibility. Web technologies are impacting the way of businesses and their management. It is very difficult to manage many business relationships manually or even using some desktop application because there are multiple and distributed users. Using web based systems it s easy to manage distant users and speed-up business transactions. This project has produced a web based system which aims to make the business transactions speedy, easy to execute, and reliable. This report presents the importance of web based systems in modern world and provides the mechanism that how business-to-business e-commerce solutions work. Specifically the report discusses the Brandlink Business to Business e-commerce solution which is kind of a complete management system facilitating manufacturers/brands and sellers/retailers to do business transactions between them through a web based e-commerce system. It also addresses the important development phases, resulting outcomes, and technical description of different sections of the Brandlink B2B solution (supplier/brand, store/retailer, and admin). A formalized specification of the requirements is developed keeping the documentation simple and clear. Testing of solution is performed at the component level and bugs appeared during testing are listed in this report. The end product is a complete web based B2B ecommerce system able to be deployed in real environment. The solution reduces the transaction processing time & cost, improves efficiency, and provides reliability compared to manual business transactions. III

4 A CKNOWLEDGEMENTS This work is done with Speedment AB at Gothenburg, Sweden. We are very grateful to Carina Dreifeldt Chief Executive Officer (CEO), Speedment for giving us this opportunity to work on this project. Our very special gratitude goes to our supervisor Per-Åke Minborg Chief Technical Officer (CTO), Speedment who has always guided and supported us many times during our work. We are lucky enough that he has never hesitated in helping us in our practical work as well as in planning and management tasks. He has been guiding, helping and encouraging us throughout the time. Whenever failures in work depressed us, we always found him to share with. We are also grateful to our examiner Graham Kemp Associate Professor, Chalmers University of Technology who has always helped us with the smile throughout our work despite of his very busy work schedule. IV

5 TABLE OF CONTENTS Abstract... III Acknowledgements... IV 1. chapter 1: Introduction & Objectives Introduction to Brandlink Introduction to Speedment Problem Introduction of the Project Objectives chapter 2: Tools & Technologies Introduction Web Application Architecture Tier Tier Tier Supporting Software Tools chapter 3: Requirement Gathering and Analysis Introduction Brandlink B2B E-commerce Solution requirements chapter 4: Supplier Section Development Introduction Theme/GUI Shopping Cart Product Product and category permissions Private Catalog Product Search Summary chapter 5: Store/ Retailer Section Development Introduction Theme/GUI View Related Suppliers Advertisements Catalog Product Details Orders History page Marketing Information V

6 5.9. Summary chapter 6: Brandlink Administrator Section Development Introduction Theme/GUI Home Page Orders Page Statistics Reports Advertisements Page Relationships Page Section Summary Deployment Introduction Hardware architecture Installation of server applications Summary Results and Future work Introduction Results Future Work Critical analysis Introduction Implementation framework The good decision Major problems Learning References Appendix A: SRS & Analysis Appendix B: Supplier Development Appendix C: Admin Development Appendix D: Deployment D.3 Application deployment VI

7 LIST OF FIGURES 1. Figure 1.1: Brand link B2B ecommerce system Figure 2.1: Web application Figure 2.2: Three tier web architecture Figure 2.3: Drupal Architecture Figure 3.1: Supplier Pages Figure 3.2: Store Pages Figure 3.3: Admin Pages Figure 4.1: Supplier section theme layout Figure 4.2: Drupal list of blocks Figure 4.3: Admin J-Query quick tabs user interface Figure 4.4: View of supplier home page Figure 4.5: Links below products catalog Figure 4.6: Add product classes Figure 4.7: JavaScript calculating seller commission Figure 4.8: Attributes & options for products Figure 4.9: Product discounts Figure 4.10: Product publishing Figure 4.11: Permissions with categories and sub-categories Figure 4.12: Product catalog categories and sub-categories Figure 4.13: Complete supplier section Figure 5.1: Store side theme Figure 5.2: Relationships block Figure 5.3: Products page Figure 5.4: Store s order history Figure 5.5: Complete store side Figure 6.1: Admin section layout Figure 6.2: JQuery tabs to organize content Figure 6.3: Drupal menus Figure 6.4: Drupal Views Figure 6.5: List of suppliers Figure 6.6: List of stores Figure 6.7: Orders page VII

8 32. Figure 6.8: Drupal view for statistic reports Figure 6.9: Statistics report Figure 6.10: Relationships content type Figure 6.11: Mass ing user interface Figure 6.12: Admin Section Figure 8.1: Hardware architecture VIII

9 1. C HAPTER 1: INTRODUCTION & OBJECTIVES 1.1. Introduction to Brandlink Brandlink AB is a third party who provides e-commerce services (Electronic commerce, commonly known as e-commerce, consists of the buying and selling products or services over electronic systems such as the internet and other computer networks). Brandlink AB needed a web-based e-commerce system to automate the manual business between different Suppliers/Brands and Stores/Retailers. The features required in the project were to make every-day business activities between Suppliers/Brands and Stores/Retailers easy and reliable using automated computer systems. Administration section of the system was required with the capability of creating new Supplier or Store accounts and maintaining the system. As users are distant so it was a basic requirement to have a single system that can support all the remote users having different platform (Windows, Linux, MacOs, etc.) based client computers and make business-related transactions very easy. To develop the system Brandlink AB contacted Speedment AB Introduction to Speedment Speedment AB is an IT specialist who solves problems (related to different domains) by providing desktop and web based computer applications. Speedment deals with following five major areas [1]. Web Application Development. Database Acceleration and web hosting. Web development in Drupal content management. Mobile application development. IT Consulting. 1

10 1.3. Problem There are two types of business entities that are involved in this problem statement: Suppliers/Manufacturers & Stores/Retailers. Suppliers manufacture one or more types of products that are associated with unique brand names, for example shoes, garments, etc. Stores are the shops in the market that sell one or more types of brands. One Supplier can have business relationships with many Stores to sell products and Stores purchases different brands from different Suppliers. To get the latest information about some product, a store either gets some printed media or visits Supplier s website. An order is placed via , phone call, or by meeting Supplier. A supplier uses some spreadsheets or applications to keep a record of products, orders, and business relationships with Stores. A business relationship is just a group of different agreements and parameters, for example: A supplier offers different discount rates to each store. Brandlink AB analyzed that there was a problem for Stores to access each Supplier s catalog by either visiting websites or by using printed media. Both, Suppliers & Stores were keeping record separately for each business relationship. The most difficult task that they were doing was to maintain many to many business relationships. After analysis, Brandlink AB decided to provide such an e-commerce solution that will allow Suppliers & Stores to connect with each other using a single platform. Stores should be able to select a list of products from Supplier s catalog and to place an order. The system will keep the record of each business activity Introduction of the Project The project aims to provide a complete web-based e-commerce solution and an administration section. The E-commerce systems are categorized into two main categories. B2B (Business-to-Business). B2C (Business-to-Consumer). Business-to-business (B2B) describes commerce transactions between businesses, such as between a manufacturer and a wholesaler, or between a wholesaler and a retailer [2]. The term business-to-business was originally coined to describe the electronic communications between businesses or enterprises in order to distinguish it from the communications between businesses and consumers (B2C) [2]. The main difference between these two types of e-commerce systems is that B2B includes multiple sellers and buyers while B2C has one seller and many buyers. In Brandlink project, Suppliers and Stores are two types of business. There can be multiple sellers (Suppliers) and multiple buyers (Stores). Each Supplier can be a brand that manufactures different kind of products and each Store buys different brands to sell in retail. This shows that Business-to-Business (B2B) e-commerce solution is more suitable for Brandlink which led us to build a B2B ecommerce system for Brandlink. 2

11 Brandlink Business-to-Business E-commerce solution will provide a complete management system that allows suppliers and stores to do business transactions through a web interface. Each supplier will have a personal catalog (consisting of categories, sub categories and products added by supplier) and rights to administer its catalog. To access the catalog of a particular supplier and to make an order, stores will need a relationship with a supplier. The relationship between a supplier and a store will ensure that store has access to the right supplier, i.e. a store selling shoes should not see the supplier manufacturing electronic devices. Brandlink administration will be a super user of the system and will have rights to add new users (suppliers and stores) and manage the relationships between suppliers and stores Objectives Objective of business to business e-commerce system to facilitate suppliers and stores with a system with interactive web based user interface that can help to perform the business transactions over internet and keep a record of all activates. Figure 1.2 shows an abstract view of the system and how different users will be interacting with different functionalities to complete their business objectives through a totally automated system. Creat Manages View Vie Creates &Maintains Generates Vie Figure 1.2: Brand link B2B e-commerce system 3

12 Figure 1.2: Description System Administrator (Brandlink) System administrator with super user rights (as indicated by wide arrow) will be able to Add, edit, and delete supplier and store accounts. Manage the relationships between suppliers and stores. View and Search Orders. Access Statistics reports. Create image and video advertisements shown on store side. Send to selected users. Suppliers/Brands Users with supplier role will have rights to do following transactions. Create and maintain their catalog. Add new products. Change the product permission settings. Manage discounts applied to categories or products. Track and fulfill their order. Monitor their sales reports. Add marketing information for their stores. Change own account information. Stores/Customers Stores will have rights to do following transactions. View their related supplier accounts. Navigate the supplier s catalog. Create their cart and place orders. View their previous orders. View and download marketing information provided by supplier. View scrolling advertisements created by admin and play videos directly. Change own account information. 4

13 2. CHAPTER 2 : TOOLS & TECHNOLOGIES 2.1. Introduction Software tools and technologies are applications and some standards that help to build some modern application and provide a way to solve some problem. As web application development is a part of this thesis project, it is important to understand about web technology. A web application is an application that executes on a web server [3]. A User interacts by sending the web request over network (the internet) by using some web browser. The Web server receives the request and generates a response by executing a web application. The response is sent it back to the client (user) in a Hyper Text Markup Language (HTML) format that is that is rendered by the web browser. All requests and responses are sent using Hyper Text Transfer Protocol (HTTP). Figure 2.1: Web application, adapted from [3] These are some benefits of using web applications, Distributed application and users from different locations can access it at the same time. Cross platform compatibility. Users having different operating systems (Windows, Linux, Mac, etc.) can use it. 5

14 It requires a thin client. Only a web browser is required to run the web based application Web Application Architecture Web applications are usually divided into different logical components that can be placed on one or multiple machines distributed over a network [4]. Distribution of components over hardware depends on work load on each component. Each logical component is called a Tier. Request Tier1: Web Browser Request Response Tier2: Web Server Response Tier3: Database Server Write Database Read Figure 2.2: Three tier web architecture 2.3. Tier1 Tier1 is also called presentation layer. This layer is implemented as client machine. A web browser is used to render the graphical user interface that allows the user to interact with a web application. Different web browsers are used on the client side like Internet Explorer, 6

15 Mozilla Firefox, Safari, etc. Scripting languages are used to render the user interface in a web browser. HTML, JavaScript, and CSS are used in this project as a client side scripting languages HTML Hyper Text Markup Language (HTML) is written in the form of elements consisting of tags, enclosed in angle brackets (like <html>), within the web page content [5]. An HTML File is either written by author of the website or can be generated dynamically by a web server and sent to a client after the web browser s request. Web browser interprets the script and composes into visual content (pages) CSS Web browsers can also refer to Cascading Style Sheet (CSS) to define the appearance and layout of text and other material [6]. CSS defines the presentation of a web page or complete website. It can be written as a separate document or with HTML, called embedded CSS. Benefit of using CSS is to increase the presentation power of HTML and to isolate the layout from content JavaScript JavaScript is also a client side scripting language that defines the behavior of HTML pages. For example: navigation, data validation before submit, and calculations on a client side. It can be written in a different file or can be embedded in the webpage Tier2 Tier2 is called the application layer that consists of a web server. A web server is an application that executes some web application [7]. It listens to HTTP requests from clients and replies after receiving content from hosted web application. There are different types of web server applications like Apache HTTP, Apache Tomcat, IIS, and Oracle Web Tier. Each web server supports one or more types of scripting languages and databases Apache HTTP server Apache is the most popular open source web server software that can be installed on almost all operating systems, including Linux, UNIX, and Windows. These are some benefits of using Apache. It is supported by multiple operating systems. It is a freely available & open-source application. Easy to install and configure. Supports PHP scripting language. 7

16 PHP PHP is a scripting language that executes on a web server to generate dynamic content like HTML, CSS, and JavaScript. It is an Object Oriented language [8]. One can either embed it in HTML code (using <?php and?> tags) or can write separate documents. There are a lot of content management systems, modules, and scripts which are freely available that are written in PHP and can be a starting point to build a complex web application. Due to this benefit, PHP language is used in this project for web application development Drupal Drupal is an open-source content management system that is written in PHP. It is powered by its community all over the world [9]. It is fully compatible with all web servers that support PHP and database. It has a variety of modules and themes freely available over internet. All the modules and themes are customizable. Drupal provides a web-based User Interface that is used to configure, customize, and manage the website content. Figure 2.3 describes the architecture of Drupal Content Management System (CMS). Core is a bundle of basic functionalities that makes Drupal a Content Management System. It can be easily customized by adding modules (features written by the Drupal community), themes (different styles for graphical user interface), and translation files. Drupal modules interact with Drupal by using hooks. Hooks are interfaces that activate on some event. Core themes Core modules Custom themes Custom modules Translation and configuration files Drupal Core files Figure 2.3: Drupal Architecture Drupal requires a database server to store different records. During Drupal installation, it creates a database structure in selected database that is used to store site s dynamic content and configurations. Variety of database servers can be used with Drupal. MySQL is the most commonly used database server with PHP and Drupal. It is very time consuming to implement such a complex e-commerce business to business application from scratch. There are a lot of content management systems that are freely 8

17 available. Drupal was selected for development in this project because of its following features, Customizable & Scalable. Most stable content management system. Written in PHP, works on many platforms like Apache, IIS. Open source. Active community. Modules & themes are freely available. Provides interfaces (hooks) to implement & attach a new functionality. Drupal has released version 7.0, but it doesn t have enough modules and support to build this complex system. Drupal 6 is the most stable version & has enough material to support this project. So we decided to use it CentOS CentOS is Linux based operating system that is mostly used for web servers [10]. It is an open-source, free, and the most stable version of Linux. CentOS 5.4 version is used for this project Tier3 The third tier is a data storage layer. It is just a database management system. A web application stores all records on this layer. MySQL Server is used in this project because it is very stable and compatible with Drupal MySQL MySQL is a relational database management system (DBMS) [11]. It is most popular (for web applications), free, and compatible with Apache web server. It uses Structured Query Language (SQL) to manipulate databases. MySQL Server 5.0 is used to store application s content & configurations Supporting Software Tools Different tools are used for this project development, Adobe Dreamweaver Adobe Dreamweaver CS 4 is an editor for scripting languages like HTML, CSS, and JavaScript. It visualizes scripts in the easy and readable format. 9

18 Adobe Photoshop Adobe Photoshop CS 5 is graphics designing software. It is used to create themes (layout of graphical user interface), icons and graphics for web applications Firebug Firebug is a debugging tool that helps a developer to debug problems related to HTML, CSS, and JavaScript. It is an Add-On that works with Firefox web browser. It is also available for other browsers like Google Chrome & Internet Explorer PuTTY PuTTY 0.60 is a free and open-source application that is used to establish SSH connections with remote machines (computers). It is also available in the portable format that can be used directly without installation [12]. 10

19 3. CHAPTER 3 : REQUIREMENT GATHERING AND ANALYSIS 3.1. Introduction In this chapter focus will be to define the Software Requirement Specification (SRS) document, discuss the purpose of SRS document, specify tangible benefits of the end product, and describe the different sections of the solution. The requirements gathered, analyzed and finalized for the Brandlink B2B e-commerce project are listed in the user manual (Appendix A). To finalize requirements reading of a document made by Brandlink client and researching & navigating different existing ecommerce systems helped a lot Brandlink B2B E-commerce Solution requirements As there are three major sections of the Project, Supplier, Store, and Admin section so the requirement gathering process splits into these three sections. The Supplier user accounts are companies that manufacture brands like garments, shoes, cell phones, etc. The suppliers manufacture and transport their products to different stores to approach potential customers. The Brandlink B2B e-commerce solution aims to facilitate suppliers to do their transactions with stores. Figure 3.1 shows different pages and functions on those pages for supplier users. A complete description of supplier section requirements is listed in table 1 in Appendix A. 11

20 Figure 3.1: Supplier Pages 12

21 The Store user accounts are retailers who sell different brands to customers. Figure 3.2 shows different pages and functions on those pages on the store side. A complete description of store side requirements is listed in table 2 in Appendix A. Figure 3.2: Store Pages 13

22 The Admin is a super user in Brandlink B2B system. Admin can create new store and supplier user accounts. It can also create relationships between them. The admin will be able to view the different statistical reports, send bulk s to all or specific users, and create advertisements. Figure 3.3 shows different pages and functions on those pages on admin part of the site. A complete description of admin part requirements is listed in table 3 in Appendix A. Figure 3.3: Admin Pages 14

23 4. CHAPTER 4 : SUPPLIER SECTION DEVELOPMENT 4.1. Introduction Supplier section is a graphical user interface that lets the supplier (role) to create and organize content related to their business. Supplier users are redirected to this interface after login where they can perform following operations, Create/Edit profile, which contains logo, and page that will appear to stores. Create and edit categories & products. Apply permissions and publication conditions. Create discount packages for categories and products. Upload and edit marketing information files (images, video clips) related to their products. Can generate sale and order reports (statistics). Development of supplier's section consists of two main parts. Theme (the graphical user interface) and Functionality. Shopping cart is the main feature in these sections. Shopping cart is a set of functions that allows online customers to select different products, accumulate a list, calculates all the values, charges, and taxes and let the customer checkout. Development of the shopping cart is further divided into different parts. Product, categories & sub-categories, and discounts. There are some other important features that are developed, like private catalog, product & category permissions, and discounts. Private catalog and product permission are very important features that allow suppliers to build personal product catalog and apply different permissions on categories and sub-categories Theme/GUI This section describes the front-end part of supplier s section. This section consists of three main graphical sections: header, left content, and right content. In order to create new sections in Drupal theme (defines layout for graphical user interface), one should register those blocks in theme information file and define an HTML element DIV in the specific part of theme where space is required. Figure 4.1 describes how the supplier interface is divided into three parts for content management. 15

24 Figure 4.1: Supplier section theme layout To start with the theme in Drupal, any basic theme can be modified to achieve the desired layout. For this section, Brandlink theme is used as a starting point because it looks similar to required layout and takes less effort to modify. Login and navigational blocks were removed from the base theme in page.tpl.php file to make it much simple. To display supplier s banner image in header section, there should be some block registered in Drupal. New block called header region was introduced in theme information file, and its position was set in template file. Line 2 and 6 in figure 4.2 shows how to register a section and define its position in web-page. Figure 4.2: Drupal list of blocks (Admin-è Site Building-è Blocks) A Drupal block can render any piece of a script. Either it is written directly or generated by Drupal View. Drupal view is a graphical user interface to generate content blocks. A Drupal view was created that fetches supplier logo from its profile. Here is Drupal generated code for Drupal View. Line 6 filters out only logo type content and related to current logged in user. 16

25 As it is showing in figure 4.1, content section consists of two parts. Each content section is a floating panel. Panels are used to manage the content and to make the GUI interactive. Drupal doesn t have any built-in function to generate tabbed panels like desktop applications. JQuery Quick Tabs [13] is a module that can be installed to achieve this functionality. To place tabs, JQuery Tabs [13] module is used. It creates tabs and in each tab, one can put block or page. Figure 4.3: Admin J-Query quick tabs user interface Left content contains supplier s product catalog and other information like statistics. Two tabs are created that contains each content category. Left content block is designed using the same method as header part by registering block in information file and theme file. Product is the most important content in this section. Supplier can add hundreds of products. There must be some searching interface to search desired product by id or name. To display search box, new block was placed using the Drupal information and theme file. Some Cascading Style Sheet script was written to position the search block on the top of main content. Line 2 and 6 shows the registration of search block in Drupal theme and information file. 17

26 Figure 4.4: View of supplier home page To make the user interface simple, some hyper-links were placed to perform operations related to products and different parameters like discounts, publishing, etc. As these links are important for all suppliers so template file is best to design and display the shared functionality. The following piece of code can be written in file page.tpl.php to achieve dynamic links for each supplier. The code was written in page.tpl.php file to generate a list of links. From line 5 onward, the code shows how to generate different links for current logged in user. 18

27 Figure 4.5: Links below products catalog 4.3. Shopping Cart In e-commerce, a shopping cart is used to assist people making purchases online. This feature works exactly as a real cart in a shop to collect items. It gathers all the products that a customer wants to buy with their accurate quantities. Upon checkout, the application typically calculates a total of the order, including shipping and handling (i.e. postage and packing) charges and the associated taxes, as possible [14]. There are different modules for shopping cart that are freely available on the Internet. Ubertcart [15] is a bundle of modules that can be used with Drupal to achieve the basic functionality for shopping cart. Here is a list of some important modules related to this project, Product Catalog Cart Store Attribute Discounts Ubertcart is a generic module for e-commerce systems. The following limitations were discovered after studying the implementation of this Ubertcart It supports only one supplier that can have many stores (one to many relationship). All products (relevant and irrelevant) appear to all the stores. Catalog is built to support one supplier. There is no discount on the product s category level. Ubertcart is easy to customize and extend because it is written in PHP. The following features were decided to implement in the existing module Multiple suppliers. Private Catalog of products with categories and sub-categories. Product and catalog access permissions. 19

28 4.4. Product Product is the main content type in this system. Each supplier creates and manages hundreds of products for stores. For this project, a product can have the following list of fields, Article number. Article name. Color code. Style. Size. Pictures (front & back). Cost. Retail price. Seller Commission. Information. Discount information. Each product created by Ubertcart is a Drupal node. Each type of content in Drupal is called node. Drupal provides a built-in module called Content Construction Kit (CCK) [16]. CCK provides an interface that allows some user to attach custom fields (text fields, select boxes, etc.) to any content type. However, it doesn t attach fields directly with Product. It means supplier needs to attach for each product. A simple solution for this problem is to create a class of product content type called Article. New product class can be created using following path Administer è Store Administration è Products è Manage Classes. Figure 4.6: Add product classes 20

29 CCK module can only attach simple text fields with Article. An Article can t be described in a simple text form. It requires some other fields add pictures, attachments, and other attributes. So some helping modules were used with CCK to attach content fields Product Pictures One product can have two image attachments that appear on the store side. CCK module requires some module that provides some image attachment functionality. ImageField [17] and FileField [18] modules can be installed to enable image field attachment. ImageField provides different parameters like maximum number of images, resizing of images, etc. Settings to image field can be accessed using following drupal path (Admin è Content Management è Article è Manage Fields è Field_Image_Cache) Seller Commission The seller commission field is already available so that a supplier can record the desired amount. The problem is that a seller has to calculate and record their commission for each product. Simple solution to this problem is a script implemented in JavaScript that listens to different events and calculates the seller commission automatically when cost or price fields are filled by some user. Line 3, 8, 14 and 20 are functions that listen to different events. For example the function blur() written on line 3 checks if the field edit-list-price is changed, calculate the sell price and fill into the edit-sell-price text field. Figure 4.7 shows the output of this script in text fields. 21

30 Figure 4.7: JavaScript calculating seller commission This script was written in Drupal block and permission was set so that it can only execute for add product page Product attributes In the real world, products are differentiated by their properties e.g. size, weight, etc. These properties are called product attributes. In any kind of business, these products have different identification numbers (article numbers) because of these attributes, but all these products belong to same class. In an e-commerce system, all these attributes are virtual, so all products look same. It is important to group all those products that belong to same class and let the user to choose attributes. Ubertcart provides a module called uc_attribute (Product Attributes) to define and attach different attributes to product. After adding this, the administrator can define different attributes for suppliers. Initially, sizes attribute was defined and added options (Small, Medium, Large, etc.). Attributes enable a supplier to configure the extra cost, price, and different article number Discounts Figure 4.8: Attributes & options for products There can be different kind of discounts with following conditions, Time based discount (activates during the specified time span). Quantity based (having some condition like overall shopping items exceeded X number of items). 22

31 Fixed number of discounts that defines some discount to expire after a defined number of selling of some product or whole category. Shopping subtotal based (if total shopping exceeds some amount). Discount coupons for to embed in advertisements. Discount on product categories and sub-categories. Discounts can be enabled by using module uc_discounts (Discounts) [19] that is in the optional list of Ubertcar package. By allowing permissions, it allows a supplier to define discounts on products and categories having different conditions. Figure 4.9: Product discounts Product Publishing Product publishing/un-publishing can be a very useful feature in the e-commerce system. It allows a supplier to set publishing and un-publishing dates so that some product appears at the right time (i.e. like some products only appears in some seasons). There is a module called Scheduler [20] that enables any content type in Drupal to publish and un-publish on specific dates. It requires enabled Date module to function properly. Date is built-in Drupal module that displays simple text fields to fill-up dates. Some graphical calendar instead of text field is a better solution. JQueryUI module [21] can be installed that enables Drupal to display more interactive user interfaces. As it can be viewed in figure 4.1.0, supplier can select and edit publishing and un-publishing dates while create or editing products. Figure 4.10: Product publishing 23

32 4.5. Product and category permissions One supplier can have hundreds of products organized in tens of categories and subcategories. All products and categories are not relevant to all stores. It is important to have some permissions system so that a supplier can set permissions for the different kind of stores. There is a question in this concept, how some supplier would know about the type of store to set permissions? The solution is to define some relationship system among suppliers, so each store can only view the relevant suppliers in its list. For further filtrations, a relationship type can be defined while creating a relationship. For this project, relationships can be divided into four classes called A, B, C, and D. These are just alphabetic labels that define the class of relationship. Implementation of relationships can be read from section 6.7. Same as relationship labels, four classes of permission labels (A, B, C, and D) are defined. A product or category can be tagged with one of these four classes so that system can filter content for a supplier by using by using relationship-permission matrix shown in table 4.1. These four labels for relationships and permissions were initially defined for this project that can be renamed and extended in the future. A store having a relationship type A can access products and categories tagged with label A. B type of relationship can only access the content having permission tags B, C, or D. C relationship can only access C or D labeled products and class D can access all the products and categories having any permission tag. Permission types Relationship types A B C D A Yes No No No B Yes Yes No No C Yes Yes Yes No D Yes Yes Yes Yes Table 4.1: Shows how relationship and permission tags show/hide products and categories to store users A simple permission tag can be defined with a product using the CCK module. This field will not be visible to stores. A supplier can choose the permission type for some product while creating a new product. This information should be invisible for stores because it is just for system. Tagging a category and sub-category is not directly possible because a category is not a content type; it is a Taxonomy [22]. CCK module is unable to add any extra fields. A module called Taxonomy Permissions was implemented that performs the following actions, When this module is installed, it appends a new column called permission in database table term_data (i.e. Taxonomy module table use to store category information). Hide extra field called details and show select box to select permissions. When some category is edited, it recursively modified permission in sub-categories. 24

33 Implementation details of this module can be read in Appendix B. Taxonomy was modified to view permissions with hierarchy of categories and sub-categories. Figure 4.11: Permissions with categories and sub-categories Catalog module was modified so that only permitted stores can access the content. Modification details can be read in Appendix B Private Catalog Product catalog consists of categories and sub-categories that are arranged in a hierarchical form to organize products. Catalog module is built-in Ubertcart package that generates Taxonomy [15] categories. This module generates a shared catalog for all users. It means there can be only one supplier and many store like other e-commerce websites. After understanding the functionality of Catalog module, a customized module can be developing to achieve a private catalog for each supplier user. Catalog module generates an empty shared container and then it calls Taxonomy library functions to generate a hierarchy of categories and sub-categories. The Private Catalog module was developed to achieve a private catalog for each supplier. Implementation details can be read in Appendix C. This module generates a new catalog when an account is created for supplier user. The module captures different events in the Drupal system and performs following actions, When a new user is being registered, if the user supplier, create a new catalog and insert a root category called Start. When the supplier is logged in, switch the right catalog that belongs to the user. When some store accesses some supplier s catalog, switch the appropriate catalog for it. 25

34 Figure 4.12: Product catalog contains categories and sub-categories Catalog is just a container for Taxonomy categories. To add categories, it requires having private Taxonomy categories. By default in Drupal, Taxonomy is shared for all users. To achieve private taxonomy functionality, a module called Private Taxonomy [23]. It generates a private taxonomy for each user Product Search Search functionality is common for supplier and store side. It is used to search articles (products) by name and article number. Drupal has built-in search functionality, but it searches all content types. Product is the only content type that is relevant to supplier user, so it is very important to filter only products. To achieve filtered search functionality, a special searching module can be used that searches only products. This module is called Product Search [24]. This module can t directly be used in this project for the following reasons, This module only searches only Product type content while Article class is used in this project. Details for this class can be read in section There is no check for permissions (product filtrations) that is implemented in section 4.5. It also hides un-published products from suppliers. So, this module was modified to fit in this project. Details about modification and can be found in Appendix D. 26

35 4.8. Summary The result of all discussion and implementation in this chapter is a complete supplier section having all features described in section 4.1. Figure shows the complete user interface for supplier section. Figure 4.13: Complete supplier section The most difficult task was to understand Drupal core and to make logic for many to many relationships among suppliers and stores. It took a lot of effort and research to implement complex permissions system and private catalogs for suppliers. 27

36 5. CHAPTER 5 : STORE/ RETAILER SECTION DEVELOPMENT 5.1. Introduction This chapter describes the development details of Store section of Brandlink B2B e- commerce solution. Store side of the system contains interfaces, logic and queries for store user. Store users are redirected to store interface after login where they can perform following operations, Create/Edit the profile which contains logo, and page that will appear to stores. View related supplier profiles, and their catalogs. Navigate through the catalog and can search products in catalog. Can place an order to a particular supplier. View and download marketing information files uploaded by suppliers. View the order history report. View the advertisements uploaded by Brandlink admin Theme/GUI Figure 5.1 shows the theme layout on store side. Figure5.1: Store side theme The store side theme is divided into four main content areas that are, 28

37 Header section Header contains the Brandlink logo, store logo, user profile link, and logout link. As the header is same as it is on the supplier and admin section so the implementation detail can be found under supplier section Left sidebar It contains a list of selected suppliers and the related shopping cart. Content area This area presents the content like products, search block, marketing information, etc. Right sidebar Right sidebar is actually introduced only for the store section. The purpose of this area is to show advertisements to stores View Related Suppliers Left side bar is used to render a list of supplier s logos that links to supplier s profiles. As the store user sells only specific brands or products, they should not see all supplier accounts in the Brandlink system. Stores have a relation with suppliers that allows to shop from those suppliers. Left side bar of the store s home page contains a list of logos of related suppliers. Following query creates a view which populates related suppliers of current store user. Relationships that are used in the query are described in Admin Section under 6.7. In the content area a drop down menu is created, which links to the Store s Orders page and the Store s home page content. If the store has not created any home page, the link will be add home page else the link will be edit home page. Figure 5.2 shows the code used to add this menu. 29

38 Figure 5.2: Relationships block 5.4. Advertisements Right sidebar of store section shows scrolling image/video advertisements. The slideshow of images & videos is created by using following Drupal modules. i. Content Construction Kit ( CCK ) In Drupal, CCK module helps to create content types and add fields i.e. image upload field. For advertisements, a content type is created which contains image and video upload fields. The admin can create content of this type, and store can only view the advertisement content. ii. Views View is a Drupal built-in module that is used to generate views of different content types. Views is used with two other modules called Views Slideshow and Views Slideshow ddblock to generate rolling advertisements. iii. Views Slideshow Slideshow can be used to create a slideshow of any content type that can be display in a View [25]. Slideshow functionality provides a graphical user interface to modify different parameters of slideshow. For example animation speeds. iv. Slideshow Ddblock This module accepts a dynamic list of images, videos and text type content and presents them in a form of a slideshow on a web page. Content changing frequency and other settings can be easily changed by its easy configuration. The module helped us to include videos in our slideshow. 30

39 v. Lightbox2 It provides a functionality to display images in a popup-window that appears without re-loading the web page. Lightbox2 can display images and videos [26] Catalog By clicking on some supplier logo, the store navigates to Supplier page and accesses the supplier s catalog. Store can navigate through different categories and products of the supplier. Relationship type between Supplier and Store will define which products store can view and order. As described in section 4.5, the product added by supplier also falls into one of the four types (A, B, C, and D). If the store has A type relationship with a supplier then store will be able to navigate products of all types A to D. And if the relationship is of B type then store will be able to navigate products of type B to D. Similarly with C type relationship store can navigate products of C to D and if the relationship is of type D then only products of type D are accessible to the store. This is also described in table in supplier section Products Page In the content area, a grid containing products of particular category is placed. Here product s image, size, price, choose an option add to cart, etc. are shown. Choose option button links to product detail page, and add to cart button will add product to cart. Clicking on add to cart doesn t refresh the page and cart updates through Ajax. For this functionality Ajax Driven Cart module is used which updates cart without refreshing page using JavaScript [27]. Figure 5.3 describes the product detail page. 31

40 Figure 5.3: Products page Search Products At the top of the content area search box will be shown. The purpose of the search box is to make it easy for store to locate desired products. All categories of the supplier will come in a drop down box. A store will be able to select a category and type product name or article number and click go. The result page will show all products in selected search criteria. For searching, a module called Product Search was modified. Details can be read from section Shopping Cart Store will be able to add products to the cart. On supplier page, there is a block on the left side containing cart overview and links. Links on the block are view-cart and checkout. Here detailed view of the shopping cart appears. User has more control on the cart and can remove or change quantity of selected items in cart. Clicking on update cart button will make desired changes in cart. Checkout button links to checkout first step Supplier Information The suppliers can add their logos, offers, important guidelines, interests, and future plans in the form of images and text Product Details This page shows all details about a selected product. Here again add to cart button will be shown but with enhanced functions. Users are able to select size (s, m, l, xl etc.) and can also enter quantity (number of items to purchase). The cart again updates through Ajax. A product s front and back side images will also appear here Orders History page This page shows history of orders made by current store in a grid. Figure 5.4 shows the history of sample transactions in tabular form. 32