- phases-= 1-3 - users, sku aliases, portals

7/27/2019 - Phases-= 1-3 - Users, Sku Aliases, Portals

1/12

PURCHASING AND INVENTORY MODULE

FUNCTIONAL SPECIFICATION

1 | P a g e

Purchasing & Inventory

Functional Specification

Phase 1-3: Users, Portals, and

SKU Management/Aliasing


2/12



2 | P a g e

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


3/12



3 | P a g e

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 handheld 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.

LicenseThis 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 bestpractices. 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).


4/12



4 | P a g e

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 andrecommendations, 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


5/12


6/12



6 | P a g e

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.


7/12



7 | P a g e

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 SKUis 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


8/12



8 | P a g e

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. Theproductstable (not shown in Figure 1 below, as were not concerned with it at themoment).

2. The skus_mastertable, which holds the single unique SKU that is attached to each and everyproduct. 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. Theportals 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


9/12



9 | P a g e

Figure 3

General FunctionalityThe 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 theportals table when it is selected for edit-in-place.


10/12



10 | P a g e

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 thequeue.

- User can click on Import SKUs to upload a CSV file containing a column of SKUs to be aliasedfor 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 thequeue 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 uploadnew 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 eachportal 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 portaland walk through each SKU in the queue table one by one, allowing the user to alias the SKU by


11/12



11 | P a g e

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 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 thewizard and restarts the process, it would start with any previously skipped records atthat 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 recordas follows:

Create the entry in the skus_aliases table that connects this sku with the portaland 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


12/12



12 | P a g e

Figure 5

Figure 6

- phases-= 1-3 - users, sku aliases, portals

Documents