:) ShopDesk: Technical Requirements Document(Fabric)
- Noreen Ayesha
ShopDesk: Technical Requirements Document
Version History | ||
Version no. | Date | Updates |
v1.1 | May 6, 2021 | Initial Version |
v1.2 | May 15, 2021 | Sequence & Architecture Diagram |
v1.3 | May 23, 2021 | Non-functional requirements |
v1.4 | May 30. 2021 | Sequence Flow and System Design Diagrams |
Technical Scope of Work
ShopDesk is a POS application that has been white-labeled for Fabric. We are focusing on integration with Fabric components so we can handle inventory, transaction & reporting seamlessly as part of the Fabric ecosystem.
Non-Functional Requirements
Security
Audit Trails and Logs.
Performance
Should be able to support a high volume of user applications
Scalability
Highly scalable architecture
User Personas
Super Admin
Admin
Manager
Cashier
Registrar
Accounts
Auditor
Shop Manager
Tech Stack
Frontend: React
Backend: PHP (CodeIgnitor)
Database: MySQL
Hosting: AWS
Integrations: NodeJS Adaptor
Technical Requirements - TBD
Problem Statement
The Point of Sale system allows businesses to better manage their sales records. Every business at some point requires a point of sale system even if it is the simplest one. The POS allows you to have a fully robust cloud-based POS system that allows you to take the business to its next level. A POS acts as a fully synchronized omnichannel medium which allows you to connect with any third-party system to make sure that everything is automatically managed. It includes the features of classic POS such as cash registers and as well as the latest features of product cataloging with public APIs that allow you to connect with any software. The POS allows you to have one unified solution for retail shops as well as online channels.
Solution
Point of Sale commonly referred to as POS is a co-pilot app that provides the functionality of finalizing a transaction. In the narrowest sense, it means that the terminal that sits beside the cash register to process credit and debit cards, and any gift cards you accept at your business.
Existing Modules
POS has a total of 12 modules. The following table will help understand the business logic of everything that the POS currently has to offer.
Module | Business Logic & Purpose |
Dashboard | The dashboard is an index page, it allows you to view all the Graphs and summaries of your Daily sales, The sales History, a brief explanation of profits, and the total count of sales |
Categories | This Tab is specifically for the kind of product you want to add to the POS system, for example, the product has a set category under which it falls, it could be Shoes for a pair of shoes or Slippers, Stitched or Unstitched for a set of clothes or cloth. etc. |
Suppliers | This Tab allows you to Add new Suppliers or view the suppliers already added to the POS from who the raw material for your business is secured and purchased. Information such as their Name, Email, Phone number, and Tax id can be added to the suppliers' profile. |
Taxes | Tax Tab allows you to add the tax percentage that is to be levied on different products. An example is that on Food products the tax could be 10% and on Clothes the Tax could be 12%. This is manually managed. |
Products | You can add products to your POS system in this Tab (Manually and by Bulk). The products SKU, Category, Tax Category, Description, Picture, Purchase price, Sale price, and variants can all be selected in the Products tab. As this is a stand-alone product it allows the creation of a product catalog. Moreover, this can also be connected with PIMs. |
Customers | The Customers Tab is to view the customer profile or add a new customer profile in the POS system. You can add info such as Name, Phone number, email, Gender, and customer code. This can help you send promotional adverts to the right targeted audience and also maintain the credit history of each customer if the business is involved in credit sales. |
Couriers | Different Couriers can be added in case of an order that needs to be delivered. (Locally and Globally) depending on the business's outreach. This is mostly used when a business is selling online and delivering from physical stores. |
Register | The main component of the POS system that allows you to Make, Park, and execute transactions |
Sell (under register tab) | Under This Tab, you can select the product being sold, add the customer profile, select tax, select quantity of product, discount, Invoice notes and select whether the transaction will be completed under cash or credit |
Sales History (under register tab) | You can view all the sales carried out in a specific date range under this tab and even their final or pending status. A report in a CSV file for that specific date range can also be exported here. |
Stock Control | This tab is all to do about the stock management of your business. |
Purchase orders (Under stock control tab) | This is to Monitor all the Purchase orders of your business location, You can place a new purchase order, monitor/edit old ones. The due date, order date, and status is also visible here |
Inventory transfers (Under stock control tab) | In case of multiple locations of your Business. The inventory transfers tab can help you transfer stock from one location to another very easily. |
Stock adjustment (Under stock control tab) | Sometimes if the stock delivered is damaged or the wrong product has been delivered, the stock adjustment tab can help you fix it. This is mainly used for audit purposes to make sure that the physical inventory on hand matches with the system |
E-Commerce | This Tab is relevant to the Online orders placed for your business. |
Orders (Under E-commerce tab) | To manage and execute the invoice of the online orders received |
Inventory sync (Under E-commerce tab) | This is to sync up the inventory showing on your e-commerce portal (such as app or website) with the actual stock available in store. It allows you to sync the inventory with the relevant sales channel. |
Reports | Different reports can be fetched under this Tab for any given date range. The reports can be exported to CSV format for your ease and comfort |
Sales Summary (Under Reports tab) | This Tab allows you to look at all the sales & Refunds that have taken place between a given date range |
Inventory dump (Under Reports tab) | This tab allows you to see the real-time inventory figures in the POS of any particular location. |
Product History (Under Reports tab) | This tab can help you view and manage the different products added earlier to the POS system. |
Omni sales summary (Under Reports tab) | This is a report generated for all the orders that came through the online channel and were successfully executed by the warehouse/delivery team. |
Category wise (Under Reports tab) | Here you can view a report of the sales that have taken place according to the category of a certain product. such as total sales of shoes or clothes or even jewelry separately. This report can also be exported in a CSV format |
Setup | Settings page |
Outlets (Under Setup tab) | This Tab allows you to add different business locations if you have an admin account for your business |
Users (Under Setup tab) | For those different locations or the same location, under here you can add different users to give your employees access to view the sales, returns, and all the activity they executed in the POS. |
Receipt Template (Under Setup tab) | The receipt template, designed according to your Business's needs. Each location can have a unique receipt for its location. |
Functional Requirements
Item | Use Case | Implementation Details |
1 | Inventory | Centralized location to manage/track all inventory from all 10 stores & warehouse
|
2 | Transactions | Ability to make transactions/returns in stores and have inventory updated automatically. |
3 | Reporting | Real-time, automated, per location reporting for each store location
|
4 | PIM Integration | Allow kitting/bundling through POS - Cannot manage inventory accurately without this |
5 | OMS Integration | Conduct accurate inventory counts as quickly as possible so we can walk away with variance reports immediately (that can be acted on the same day). (POS will send the inventory count adjustments to fabric OMS ) |
6 | WMS Integration | Integration with WMS to get the updated inventory figures against each location and also to send the stock adjustments and variance reports. |
7 | Offers Integration | Integration with Fabric Offers to validate coupons and promotions. |
Non-Functional Requirements
Item | Use Case | Implementation Details |
1 | Audit Logs |
|
2 | Transaction Logs |
|
3 | Performance |
|
4 | Scalability |
|
Process Flows
Inventory
The inventory of all locations as the functional requirement states is to be centrally managed. The single source of truth in the case of the inventory will be WMS. POS will be using the inventory either from WMS/OMS to update the inventory in its locations.
Few important aspects that have been finalized are below
Transfer of Inventory
The transfer of inventory in between stores needs to happen in POS. An option of centralized stock transfer requests where the super admin approves of the transfer requests and allocates the store. Locations are to be handled in POS that will be in sync with OMS locations (store ids to be used for the sync). Any transfer within the store once approved by the super admin will reflect in OMS. So all updated inventory will be sent to OMS in real-time.
POS will only be sending the delta (the only SKUs being changed will be sent). We will incorporate a timer system that will kick in on the first transfer request and after an hour or 30 mins, it will send the adjusted accumulated quantities to the OMS/WMS.
Receiving / Placing POs
Receiving & Placing POs to be done in the POS will also require barcode scanning on receiving for double confirmation. PO’s are to be dealt with at the POS level only. Any Purchase order placed above a certain cap will go to super admin for approval.
Input and Manage POs with the ability to trackability to Open To Buy
The ability to control the stock transfers/purchase orders more centrally. A cap is to be placed against each buyer. If the amount exceeds that particular amount which is set then it will move to the super admin for approval.Ensure tied back into financial reporting (system of checks and balances)
POS will be sending back information to Fabric OMS and Fabric OMS will send it to the financial reporting system. However, all stock audit adjustments will be sent to WMS too.
Reporting
POS is to give location-wise figures of the following points along with a date range for its end users.
Sales
Sales recorded at each store. Cash/Credit Sales both to be shown.Gross Profit Margin
The assumption is that the cost of the product is added against each variant. If the variants are coming from PIM. Then the cost is being sent from PIM to the POS.Sell-Through
The sales to inventory ratio are also to be shown. This will work on avg inventory basis. We will capture snapshots of the inventory every hour. Take an average of the inventory for the day by combining the different snapshots. This will give us accurate sales through inventory.Units Per Transaction
This will include the unit-wise sales. The average units per transaction as well.Avg Ticket Size
Average order valueCategory Level
Category-wise sales are to be shown on the main dashboard page.Inventory / Catalog
Value and count of inventory at each location to be made available.
PIM Integration
POS is going to be in sync with the fabric PIM. All relevant product details will be fetched in the POS using PIM API. The products are expected to come from Fabric PIM. POS will be handling bundled products same as Fabric PIM to maintain uniformity throughout. Product integration to be created with a proper audit trail. The mechanism of updating existing products and creating new ones will be scheduler-based.
OMS Integration
POS will be in sync with the fabric OMS as well. All relevant locations with their inventories/orders will be connected. POS will be using OMS API to maintain the integration.
Items to be sent to OMS
All sales will be registered in OMS.
After closing sales, orders will be created with “fulfilled” Status in the OMS.
Ability to create web orders for delivery. The ability to send the address.
WMS Integration
TBD
Fabric Offers Integration
TBD.
System Design and Architecture
APIs
https://documenter.getpostman.com/view/14200526/TzeXjmvq
Sequence Flow
For the integration with the fabric’s identity POS will be using a hybrid b/w it’s and fabric’s identity. Upon every request Authorizer Middleware will check if the requested token’s owner user already exists in the POS user base it will just let the request go if not then Authorizer Middleware will check for the required access and create a user in the POS user base and propagate the request internally
WMS 2 Way Inventory Sync
TBA
ERD
Monitoring health checks
An application health check is crucial for measuring the health of the application.
Steps to implement health check:
Identify all the external APIs used by the application.
Like 3rd party endpoint, MySQL clustercreate an API /health-check
this API will initiate a simple connection of all the external URLs needed for the proper function of the application.
/health-check status code 200 indicates the application is healthy
A periodic call will be automated to this /health-check API. eg: once every 5 mins
Use Case:
If somehow the database instance or application entirely goes down. The monitoring tool will be able to quickly identify which service has become unavailable and for how much time.
We can have a status page as shown below to ensure the visibility of our application.
Branching & Deployment Strategy
Lint pre-commit checks should be ensured.
There would be 3 major branches.
Develop: is the branch where developers are committing their code on daily basis and it is the developers’ responsibility to keep this branch stable.
Staging: is the branch where QA is done. This branch is attached to a replica of production with the same build and deployment strategy so smooth rollouts can be tested and ensured.
Production is the live environment.
CI pipelines are to be run before branches can be merged.
No code can be merged into production until the corresponding ticket is marked as QA verified.
Testing & QA Strategy
We will have the following environments for the QA strategy.
Dev
Stage
Internal Production
Sandbox/UAT
Production
Dev
All the development work will be pushed to the dev environment and developers will ensure the stability of this environment.
Stage
Once the developer has tested their code in dev env then they will raise a PR against stage env. The QA will ensure the stability of this env and run his QA test cases.
Internal Production
Internal Production will be the last env where smoke testing will be performed against all feature releases. The PM and Dev Lead will ensure the stability of this env. Once this env has been tested PR will be raised against the master branch.
Sandbox
Sandbox will be the UAT env for the clients and deployment to this env can only be performed using the master branch. Internal QA needs to perform smoke testing on this env and external clients can perform the UAT activities.
Production
Production will be the live environment for POS. Smoke testing is required after every release to ensure the stability of this environment.
Back of the envelope estimates
TBA