PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Purchasing & Inventory Functional Specification Phase 1-3: Users, Portals, and SKU Management/Aliasing

1|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Contents
Project Overview........................................................................................................................................... 3 License........................................................................................................................................................... 3 General Look & Feel and Overall Functionality Requirements ..................................................................... 3 Database ....................................................................................................................................................... 4 Phase 1: Users & Logging In .......................................................................................................................... 5 Overview ................................................................................................................................................... 5 Database Structure ................................................................................................................................... 5 Functionality ............................................................................................................................................. 5 Phase 2: Portal Master .................................................................................................................................. 6 Overview ................................................................................................................................................... 6 Phase 3: SKU Management with Aliases and Importer ................................................................................ 7 Overview ................................................................................................................................................... 7 Database Structure ................................................................................................................................... 8 General Functionality ................................................................................................................................ 9 SKU Importing and Alias Wizard/Dialog.............................................................................................. 10

2|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Project Overview
This project involves creating a cross platform Inventory and Purchasing system using the Qt framework that interfaces with a variety of web platforms (ecommerce carts, Amazon, eBay, +more) via calls to web services. The project also contains a Point of Sale module, and extends to mobile devices such as hand held scanners and/or tablet/phone devices. Phase 1-3 of this project is building the basic foundation of the application (general look and feel, core dependencies, etc.), as well as building the first pieces of real functionality, which are managing users, portals, and SKUs with a SKU matching/aliasing interface.

License
This project is proprietary and closed source, therefore all work done is on a work-for-hire basis and we own all work produced. Care must be taken by the developers to make sure all components, code, imagery, or any other element used during the creation of this application is either a unique creation by the developer that falls under the work-for-hire agreement and becomes our property, or is licensed under terms that allow for free and unrestricted use in commercial applications. No GPL or similarly licensed code should be used within this application. If there are any questions at all regarding this, do not hesitate to ask for clarification.

General Look & Feel and Overall Functionality Requirements

This application will use the Qt framework and should implement a standard but modern GUI look and feel. Layout of the menu, content, and general GUI elements will follow all modern software best practices. Utilization of industry standard components such as data tables, drag and drop functionality, and standard reporting controls is required wherever possible. We do want the application to be very attractive, so keep visual appeal in mind. We want to use stylish controls, attractive colors, etc. The screen shots contained in this specification or for general overview only and not intended to be matched exactly for look and feel. We want the most attractive, most user friendly design of the app possible so please enhance the examples we gave to make that happen. We would like a very attractive Dashboard screen for this app moving forward. This is not crucial for the beginning phases, but will come up shortly as we move forward. The first phases of the application will consist solely of the desktop app running on modern Windows machines with the database server running on a centralized server, however moving forward as the application grows in functionality, it will be implemented on Linux and possibly Mac machines for the standard Purchasing and Inventory portions; the POS (Point of Sale) interface will be running on several machines, and portions of the code will be ported to run on embedded Linux devices and/or mobile platforms (iOS and/or Android). 3|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION This application will generally operate in full-screen mode on desktops, certainly for the short term and most likely long term also. Therefore we want to optimize the interface accordingly in order to maximize usability. This is not nearly as important during these first phases, as the data is not very involved and interfaces generally small, however moving forward the complexity of the interfaces will increase as amount of data we are displaying, sorting, and filtering increases. The application must use database record locking, as this will be a multi-user application, with many users potentially attempting to modify the same record or sets of records. PERFORMANCE and USABILITY are crucial with this application. Those items should be top of mind at all times while designing database structure, as well as designing and implementing code. Caching should be implemented wherever possible, as well as pagination of larger datasets to reduce initial load time. Intuitive progress dialogs should be displayed and used at all times, notifying the user of current processing status with a display of the current task and remaining time left (as accurate as possible). We would like to use edit-in-place for records wherever it makes sense to do so. The use of shortcut keys, tabbed navigation, etc. is important so make sure this is addressed at all times during development. The program will require logging in (see Phase 1 below), so on initial startup the system should authenticate the user and keep that users permissions in session while the app is running.

Database
The actual database backend is currently up for discussion. We encourage your suggestions and recommendations, but are currently leaning toward either MySql or PostgreSQL, most likely MySql as the majority of ecommerce carts we are working with are based in MySql as well, so ideally wed like to keep consistency. There are many tables and overall data design structures in our own existing cart platform for objects such as products, orders, customer, etc. that we can replicate design wise to this application so again, consistency will make things a bit easier. Nearly all tables contain the following columns and must be updated accordingly on all data creation and edits: poster: the user_id of who CREATED the record created_at: the timestamp of when the record was CREATED editor: the user_id of who last EDITED the record edited_at: the timestamp of when the record was last EDITED

4|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Phase 1: Users & Logging In

Overview
Phase 1 of the project involves creating the basic user tables and forms for storing and administering our users. This will be extremely basic for now we are not implementing the full roles or permissions systems just yet, simply getting the basic user structure in place to build on moving forward.

Database Structure
Please refer to Figure 1 below. This will be a very simple single table to start with simply the users table for storing our user information including basic name, email, and password. This will expand as we move forward however we will keep it very simple to start.

Functionality
The program will require logging in, so on initial startup the system should authenticate the user with a basic login dialog using their username (email address) and password, and keep that users permissions in session while the app is running. The interface for this is very straight forward. The GUI for the screen itself should utilize a left hand data table listing all users in the system (use dummy data for now to code/test with), with the ability to filter by using a Status dropdown (showing the values Active, Locked, and Inactive) that defaults to Active as well as a continuous filter single text box that will look at each applicable field in the table (varchar) and do a simple on-the-fly filter of the data on each keypress within the field. For instance if I have 5 users in the database, one of which is named Fred Franklin and another named Fred Fredericks, as I start typing the letters Fred, I should immediately see my list of users updating to narrow down the matches. If the next characters I type are a space and then Fr: Fr, then I should still see both of those users. As I type either e or a next, I should then only be left with the one corresponding user that matches my filter. When the application user clicks on one of the users in the left table, the form for editing that user should appear in the right portion of the application. I should be able to edit all fields as either text or a dropdown (e.g. for Status), with the exception of the password field, which should be a double entry field with the actual content hidden with *s and requiring standard double entry of the password with verification on save to make sure they match. Passwords should be encrypted when stored at the database level; type of encryption is up for discussion. There should be intuitively placed buttons for Create New User. Existing users will not be deleted, only made inactive.

5|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Phase 2: Portal Master

Overview
Portals are the publishing platforms that we will be interfacing with from our application. We will be pushing and pulling product and order information to and from these portals. These are such well known places as Amazon, eBay, Yahoo Shopping, along with well known shopping carts such as Magento, and others. The POS (Point of Sale) interface is also considered a portal as well and will be addressed at a later time in the development process. As we move forward we will be adding many additional portals to the application as we code interfaces for them. For now, the Portal management screen should follow the same layout as the User management screen with the basic list of portals in the left column; clicking on one will show the form to edit in the right body area (in a Tabbed layout). It is very simple currently as we just need the basic record created in order to perform the SKU aliasing defined below in Phase 3 so we only need the Portal name on the General Information tab, and the SKU constraint information (naming conventions/rules for SKUs in each portal) on its tab. See Figure 1-2 below for GUI, and Figure 4 below for database design. The constraints for SKUs vary on each platform, but we basically have the following: minimum size, maximum size, and allowable characters. For instance, Amazon defines their SKU constraints as: A 150 character string of arbitrary structure which cannot be null, that can contain the characters a-z, A-Z,
0-9, underscores, periods, and dashes

At a minimum we need three fields for defining these constraints - but we are open to ideas regarding the allowable characters interface. We could use freeform comma separated lists (however commas are allowed in SKUs on many platforms), we could use a dialog box showing characters with checkboxes to select allowable, etc. The master SKU does not currently have any constraints applied, however moving forward that may change.

6|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Figure 1

Figure 2

Phase 3: SKU Management with Aliases and Importer

Overview
Every item (or product) of inventory will have a master SKU that it is connected with. The master SKU is contained in a dedicated table; each product will reference the id of the master SKU in the product table. When a single product is published to different portals (e.g. Amazon, Yahoo Shopping, ecommerce site 1, ecommerce site 2, etc.), the SKU for that product might need to be different for a variety of reasons such as: legacy data, requirements/constraints on some platforms for size or characters allowed in a 7|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION SKU, forced SKUs (such as Amazon), etc. In order to accommodate for this, our system must allow aliasing of SKUs, which allow a single product to be published and managed on various platforms using a variety of potential SKUs. We are calling these aliases and each alias SKU is tied to both a master SKU as well as the portal where it is used. A portal can simply use the default master SKU, but may also define an alias that it uses (or several to accommodate SKU changes and such). The same alias can also be used in multiple portals; however the list of master SKUs will be unique, and the list of alias SKUs PER PORTAL will be unique. Each portal will also define a list of constraints for its SKUs (see above), and each portal will have a default SKU that it uses, which is the MASTER SKU if not otherwise specified.

Database Structure
The beginning database structure for this is relatively simple. This functionality is based on 4 core tables shown below: 1. The products table (not shown in Figure 1 below, as were not concerned with it at the moment). 2. The skus_master table, which holds the single unique SKU that is attached to each and every product. This is a one-to-one relationship with the product, as each product will have one and only one unique MASTER SKU, however they can have unlimited alias SKUs. 3. The portals table, which defines the various platforms in which we can publish our products. Examples include Retail Store, Amazon, www.EcommerceSite1.com, www.EcommerceSite2.com, eBay, etc. 4. The skus_aliases table, which

8|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Figure 3

General Functionality
The SKU alias interface will be a screen in the app for viewing, editing, creating and deleting existing SKUs/aliases one at a time, as well as offering an importing interface for walking through an imported list of SKUs and rapidly importing and aliasing them to the master SKUs. Moving forward, the SKU aliases will be used consistently everywhere while processing and fulfilling orders, creating purchase orders, running reports, etc. For Phase 2, we just need the core structure in place with the initial functionality defined here working. We are open to recommendations regarding interface design; however we are leaning toward a tree widget in the left column (see Figure 4 below) with filtering similar to the Users data table defined above. When a SKU is selected from the left list, it opens a form in the right body portion of the application to view further information and for editing. This is a good case also for edit-in-place for the SKUs and Portals. The SKUs will be free text, and should do validation on the attempted save of the edit per above constraints regarding unique values and general size and allowed characters (defined above in Phase 2 Portals section). The portal field should turn into a dropdown that loads values from the portals table when it is selected for edit-in-place. 9|Page

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Figure 4

SKU Importing and Alias Wizard/Dialog Overview The SKU importer generally works as follows (we are not married to the current example design layout, this is just to express our thoughts thus far your recommendations on the most intuitive interface are encouraged). See Figure 5 and Figure 6 below: Main screen shows the current portal list and if there are any SKUs awaiting import in the queue. User can click on Import SKUs to upload a CSV file containing a column of SKUs to be aliased for a selected portal. The dialog design for this is not included in this spec but should be very simple select the CSV to import, and the portal in which to alias. The application validates the SKUs on import, checking immediately for SKUs already in the queue table, already aliased for the selected portal in the aliases table, or which are already the MASTER SKU, which are then skipped (but noted to the user). All other SKUs are then saved into a temporary staging table (not shown in diagrams the table should be a simple two column table with the portal_id and the SKU to import) to walk through the import process. This step should end with a message to the users stating how many SKUs were skipped because they were already aliased, and how many were queued for further processing. A user may upload new SKUs to alias at anytime, and new ones should simply be added to the queue table for the matching process. The alias wizard can be launched anytime by clicking the Run Queue button next to each portal that has SKUs waiting in the queue table, which will launch the wizard dialog (Figure 6). The wizard dialog will start by grabbing the lowest record id in the queue table for this portal and walk through each SKU in the queue table one by one, allowing the user to alias the SKU by 10 | P a g e

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION selecting from some system generated matches (based on query formulas we will supply), or by allowing the user to perform a continuous search. If the clicks in the <search> field and starts tying, the system should first automatically select the radio button for this option. The system should then do a continuous search looking for any and all matches to what the user is typing. Ideally the system should prioritize the matches by listing the master SKUs that BEGIN with the users input first, and then showing other matches that hit within the SKU. For instance, if were matching on the alias SKU: F5261_ATACS_FG_03M and I click in the search field and begin typing: 5261 my suggested search results that show should appear something like this: 52612345 52612346 A5261_ATACS_AL_03M(L:591) F5261_ATACS_FG_03M(L:671) G5261_ATACS_FG_03M(L:973) show the beginning of word matches first, then others below. I should then be allowed to select whatever master SKU I want to alias. My button options are: o Cancel: stop the process where it is and just close the dialog. The user can always pick the process back up at anytime. o Skip: this just skips the current record and moves to the next one. If the users closes the wizard and restarts the process, it would start with any previously skipped records at that point since were starting with the lowest ID first and moving forward. o Add Alias and Continue: if the user selects this button, we will then process this record as follows: Create the entry in the skus_aliases table that connects this sku with the portal and the master sku, as well as sets the default flag. Remove that record from the queue table Move on to the next record waiting in the queue table

11 | P a g e

PURCHASING AND INVENTORY MODULE FUNCTIONAL SPECIFICATION

Figure 5

Figure 6

12 | P a g e