Itts SRS

iTTS – Software Requirements Specification
Software Requirement Specification (SRS)

Integrated Tea Trade System
Submitted To:
In Association with:
East African Tea Trade Association
Tea Trade Center, Nyerere Avenue
Mombasa, Mombasa County
85174-80100, Kenya
Level - 6, OCAC Tower, Acharya Vihar,

1|P a g e Bhubaneswar - 751013, Odisha,
ESS AfricaIndia
Ltd. & CSM TECHNOLOGIES PVT. LTD.
+91 (0)674 6635 900 | info@csmpl.com | www.csmpl.com

CONTRACT FOR: 35_KE – System Development, Deployment and

Maintenance of the proposed integrated Tea Trade System (ITTS) for
East Africa Tea Trade Association (EATTA)
CONTRACT REFERENCE: PO/20170711
Version 1.0.5
WORK/ ACTION POSITION NAME SIGNATURE
CSM Technologies,
Dhiren Behera
Project Manager
Prepared By
ESS Africa Ltd , CEO Pannaga Patnayak
Reviewed By EATTA - Senior Trade and John Sudi

Information Technology Officer
Recommended By TMEA – Program Manager Erick Sirali
EATTA – Managing Director

Approved By Edward Mudibo
2|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

Revision History
Version Description Author Date

1.0 Draft SRS 1.0 Alex Kamau 20-Sep-2017
1.0.1 Draft SRS 1.0.1 Alex Kamau 20-Sep-2017
Base lining Requirements and Content for
1.0.1 Business Documents, Reports and Rosemary Amondi 27-Sep-2017
Notifications
1.0.2 Draft SRS 1.0.2 Alex Kamau 04-Oct-2017
10-Oct-
1.0.3 Draft SRS 1.0.3 Alex Kamau
17
Requirement Validation and
1.0.4 addition of e-Auction Avinash Mallick 10-May-2018
Functionalities
Addition of Membership
1.0.5 Renewal and Baseline the Avinash Mallick 24-May-2018
Requirement document
1.0.6 Updated SRS based on CR lists Avinash Mallick 24-JAN-2019

Contents
1. Introduction ........................................................................................................................................................8
1.1 Purpose ......................................................................................................................................................8
1.2 Scope..........................................................................................................................................................8
1.2.1 In-Scope Functionality...........................................................................................................................8
1.2.2 Out of scope functionalities ...........................................................................................................10
1.3 Intended audience .................................................................................................................................10
1.4 References ..............................................................................................................................................10
2. Overall Description .........................................................................................................................................10
2.1 Product perspective .............................................................................................................................10
2.2 Product functions..................................................................................................................................12
Membership Module .......................................................................................................................................12
Catalogue Module ...........................................................................................................................................12
eAuction Module .............................................................................................................................................13
Business Module ............................................................................................................................................13
2.3 User classes and characteristics ......................................................................................................14
2.4 Operating environment ........................................................................................................................16
2.5 User environment ..................................................................................................................................16
2.6 User Documentation .............................................................................................................................16
2.7 Design/implementation constraints .................................................................................................16
2.8 Assumptions and dependencies .......................................................................................................17
3. External Interface Requirements ................................................................................................................17
3.1 User interfaces .......................................................................................................................................17
3.2 Hardware interfaces..............................................................................................................................17
3.3 Software interfaces ...............................................................................................................................17
3.4 Communication protocols and interfaces ......................................................................................18
4. System Features .............................................................................................................................................18
4.1 General system features .....................................................................................................................18
4.1.1 Member Registration ........................................................................................................................18
4.1.2 User Registration ..............................................................................................................................21
4.1.3 User Roles ..........................................................................................................................................21
4.1.4 Garden Registration .........................................................................................................................22
4.1.5 Warehouse & Godown Registration.............................................................................................23
4.1.6 Appoint Broker ..................................................................................................................................23
4.1.7 Appoint Warehouse ..........................................................................................................................24
4.1.8 Portal Features ..................................................................................................................................25
4.2 Pre-Auction Features ...........................................................................................................................26
4.2.1 Dispatch Tea ......................................................................................................................................26
4.2.2 Producer Warehouse Tea Receive ...............................................................................................28

4.2.3 Tea Allocations ..................................................................................................................................29

4.2.4 Pre-Auction Catalogue ....................................................................................................................31
4.2.5 Amend Pre-Auction Catalogue ......................................................................................................33
4.2.6 Add valuations and taster’s comments to Pre-Auction Catalogue ......................................34
4.2.7 Valuation Catalogue .........................................................................................................................35
4.2.8 Buyer Valuations ...............................................................................................................................36
4.3 Auction Features ...................................................................................................................................37
4.3.1 Auction Administration ...................................................................................................................40
4.3.2 e-Auction system – Broker floor ...................................................................................................41
4.3.3 e-Auction system – Buyer floor ....................................................................................................42
4.3.4 e-Auction system – Producer View ..............................................................................................44
4.3.5 e-Auction system – Out lots system ............................................................................................45
4.3.6 e-Auction system – Auction Results ...........................................................................................46
4.4 Post-Auction Features .........................................................................................................................47
4.4.1 Sale Confirmation .............................................................................................................................48
4.4.2 Sale Invoice ........................................................................................................................................49
4.4.3 Issue settlement Instructions ........................................................................................................50
4.4.4 Bank Access and Payment Confirmation ...................................................................................51
4.4.5 Tea Release Document ....................................................................................................................52
4.4.6 Delivery Order ....................................................................................................................................53
4.4.7 Loading Instructions ........................................................................................................................54
4.4.8 Release of Tea – Producer Warehouse .......................................................................................55
5. Requirements and Content for Business Documents and notifications ..........................................56
5.1 Business Transaction – Tea Dispatch .............................................................................................56
5.2 Business Transaction – Tea Weight Note .......................................................................................57
5.3 Business Transaction – Pre-Auction Catalogue/Closed Catalogue ........................................58
5.4 Business Transaction – Auction Catalogue/Evaluation Catalogue .........................................59
5.5 Business Transaction – Sale Catalogue .........................................................................................60
5.6 Business Transaction – Sale Invoice ...............................................................................................61
5.7 Business Transaction – Tea Release Document ..........................................................................62
5.8 Business Transaction – Delivery Order ..........................................................................................63
5.9 Business Transaction – Loading Instruction .................................................................................64
5.10 Business Transaction – Release Certificate ..................................................................................65
6. Content Description .......................................................................................................................................66
6.1 Content Description – Tea Dispatch ................................................................................................66
6.2 Content Description – Tea Weight Note ..........................................................................................67
6.3 Content Description – Pre-Auction Catalogue/Closed Catalogue ............................................68
6.4 Content Description – Auction Catalogue/Evaluation Catalogue .............................................69
6.5 Content Description – Sale Catalogue .............................................................................................70

6.6 Content Description – Sale Invoice ..................................................................................................71

6.7 Content Description – Tea Release Document ..............................................................................72
7. Reporting Specifications ..............................................................................................................................74
7.1 Report Description – Producer ..........................................................................................................74
7.2 Report Description – Broker...............................................................................................................75
7.3 Report Description – Buyer ................................................................................................................76
7.4 Report Description – Producer Warehouse ...................................................................................77
7.5 Report Description – Buyer Warehouse ..........................................................................................78
7.6 Report Description – EATTA ..............................................................................................................79
7.7 Report Description – BANK ................................................................................................................80
8. Other Non-functional Requirements ..........................................................................................................80
8.1 General Requirements .........................................................................................................................80
8.2 Interoperability .......................................................................................................................................81
8.3 Security ....................................................................................................................................................82
8.4 Usability ...................................................................................................................................................83
8.5 Performance ...........................................................................................................................................83
8.6 Standards Compliance ........................................................................................................................84
9. Appendix A: Glossary....................................................................................................................................85
10. Appendix A: Analysis Models ................................................................................................................86
10.1 Use Case Diagrams ..............................................................................................................................86
10.1.1 Membership Module ....................................................................................................................86
10.1.2 Catalogue Module .........................................................................................................................87
10.1.3 Auction Module .............................................................................................................................88
10.1.4 Business Module ..........................................................................................................................89
10.2 Data Flow Diagrams..............................................................................................................................90
10.2.1 Pre-Auction ....................................................................................................................................90
10.2.2 Auction ............................................................................................................................................90
10.2.3 Post-Auction ..................................................................................................................................91
11. Change Requests (UAT) ..........................................................................................................................92
11.1 Membership Module .............................................................................................................................92
11.2 Catalogue Module .................................................................................................................................92
11.3 eAuction Module....................................................................................................................................95
11.4 Business Module ...................................................................................................................................98
12. Change Requests (Piloting & Training) ...............................................................................................98
12.1 Membership Module .............................................................................................................................98
12.2 Catalogue Module .................................................................................................................................99
12.3 Auction Module ....................................................................................................................................100
12.4 Business Module .................................................................................................................................101
12.5 MIS ..........................................................................................................................................................103

12.6 Common ................................................................................................................................................104

1. Introduction
1.1 Purpose
The purpose of this SRS document is to provide a detailed overview, description of the
iTTS software product, its features, parameters and goals. This document describes the
project's target audience, its user interface, hardware and software requirements. It
defines how Tea Trade stakeholders, team and audience see the iTTS and its
functionalities. Nonetheless, it helps both designer and developer to assist in software
delivery lifecycle (SDLC) processes.
1.2 Scope
Integrated Tea Trading System (iTTS) will allow data capture of tea from dispatch at the
factory/producer to release of tea after payment of tea has been done from the producer
warehouse. We have categorized the features/functionalities which are covered as part of
the scope and which are not part of the scope of this project as below:
1.2.1 In-Scope Functionality
Based on the requirements gathered, the following functionalities are considered to be

within the scope of the project.
1. Membership management function to enable and control member registration,

definition and management of member’s roles and setting trade rules within
iTTS.
2. Tea dispatch and receipt functions to enable confirmation of teas dispatched

from factory and received at producer warehouse.
3. Tea Weight Note function to enable generation of Tea Weigh Note by

warehouses
4. Tracking and reconciliation of tea inventory movement. This functionality would

enable tracking the movement of the tea from the factory to the warehouse (either in
transit or at the warehouse through a search feature) and the reconciliation of the
inventory would be established based on the tea received and tea sold/issued from the
warehouse as per the report format provided by the EATTA.
5. Tea Offer/ Print Advise function to enable producers to allocate teas for specific
auction session/s.
6. Catalogue preparation and management function to enable and control the

creation, management, access and aggregation of pre-auction catalogue/Closed

Catalogue, auction catalogue/Evaluation Catalogue and post auction catalogue/Sale

Catalogue by brokers.
7. E-Auction function to enable
a) electronic auction of teas by brokers,
b) electronic bidding of teas by buyers,
c) Identification of Out-Lots by the system based on lots which are not sold
during the auction period i.e. without bids from buyers
d) declaration and reporting on Split Lots by system based on EATTA rules and
eAuction Guidelines
e) Acceptance of the highest bid by system.
8. Auction organizer/Admin function to enable
a) the setting and control of e-auction parameters to be used by the iTTS based
on EATTA rule book
b) enable consolidation and publication of all catalogs for auction within

specified timeline
9. Auction Results functionality to enable electronic access to auction results by

stakeholders
10. Invoice functionality to enable tracking of invoices generated by brokers after

the auction
11. Payment function to enable banks to confirm receipt of payment of teas from
buyers
12. Tea Release Order function to enable generation and approval of Tea Release
Order.
13. Reporting function to enable access to reports and statistics based on defined
user roles in the system and the EATTA rule book.
14. Tea Trade business portal to act as a primary source of information for all
stakeholders. It will also help to improve transparency through availability of general
reports for public view as authorized by EATTA.

1.2.2 Out of scope functionalities
1. A Functionality where private buying and selling of teas can take place
2. A functionality to generate export documentation i.e.; KRA, KPA & KEPHIS
1.3 Intended audience

This document is to be read by the development team, the project managers, and
software quality assurance team and documentation writers. This document should be
reviewed by various stakeholders including PIT committee members for better
understanding of the system.
1.4 References
- Business Requirements Document

- EATTA Rule book
- EATTA Rate matrix
- EATTA Penalty & Settlement Matrix
- Standard Used -ISO/IEC/IEEE 29148:2011 - ISO/IEC/IEEE International Standard
2. Overall Description
2.1 Product perspective
The Integrated Tea Trading Platform will possess a suite of business applications with
unique capabilities and standards required to facilitate and streamline all pre-auction,
auction and post auction tea trade transactions including the option of an electronic
auction. The solution shall offer a selection of easy to use, highly available, standardized and
secure B2B trade applications and e-auction capabilities. It will include business applications
for Producers, Brokers, Buyers, Warehouses, Banks, Transporters and Packers to interact
with the system and perform various tea trade functions and transactions. In addition, it will
have the tools for site management, content management, business process definition and
site administration. The solution will be built in a dynamic and scalable manner that
includes all of the unique capabilities and standards required to manage and operate an
effective business to business platform and e-auction system.
10 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

The integrated Tea Trade Platform is intended to achieve the following business
Objectives:
a. Reduce the period between receiving the printing advice and closing date.
b. Reduce the period between Closing date and auction date
c. Reduce the period between Auction date and prompt date
d. Increase average auction speed of lots per minute.
e. Reduce Catalogue preparation time/publishing costs
f. Reduce Average call over time from 2 to 13 hours to real time
g. Reduce time for Invoice preparation and statements
h. Real time availability of data. Currently data is available after 30 minutes from
the closure of auction.
i. Increased transparency through built in audit trail reports and analytics
j. Improved Time to make decisions through intelligent market reporting tools
Table 1 Product Overview

2.2 Product functions
Membership Module
This component will enable and control the registration, definition and management of
members and roles within iTTS. The system will support the pre-registration of member
organizations – (Producers, Buyers, brokers, warehouses, banks, transporters and Packers)
individuals and administrators. Roles and attributes will be defined at the ITTS system level or
organization level. Roles and other grouping (such as subscriptions, geography or organization)
control access to resources and actions. Support for one level of approval for any or all actions
or commands (such as Bid, Buy, and Sell) will be built in.
The module should support a robust governance framework where existing tea trade business
rules relating to membership parameters will be built in to the system and administered.
Catalogue Module
This component will enable and control the creation, management, access and aggregation of
Pre-auction catalogue, Auction Catalogue and Post auction catalogue content by brokers.
The catalogue module will provide a unified view of the teas available for sale and the teas sold
in the Mombasa tea auction Centre. At the core of the system will be an aggregated catalogue
that can provide different views to producers, brokers, buyers, EATTA and banks based on their
current role in the value chain. A robust price index exploration and search feature based on
historical and other parameters to support pricing decisions. Any item in a closed auction
catalogue can be made available for auction by EATTA using this module.
Brokers will view tea allocations available by producers on the e-business module and populate
additional data for the 3 catalogue views through manual entry using a catalogue creation GUI,
or import data from their Systems using predefined Excel Templates or .CSV files. Brokers will
define different views of the catalogue to producers and buyers. i.e Pre-auction/Closing
catalogue, Auction/Evaluation Catalogue and Post Auction/Sale Catalogue. The system will track
the different stages of catalogue publication and will have validation checks i.e the valuation of
Tea at various levels. The Tea Catalogue Builder will have robust features for broker to add or
import tea tasting and valuation information from third party systems information. Buyers will
have a feature where they can view the catalogue and add their internal parameters like tasting
results for purposes of comparison and decision making. Producers will confirm the catalogue
created by broker after which broker will close and publish the auction catalogue to its e-
auction floor. The Auction Organizer -EATTA will then view and avail the auction catalogue for
sale to the broker’s floor.
In addition to standard text and keyword searching, the auction catalogue will support other
filtering mechanisms: tea attribute exploration, historical performance and product
comparison. Product exploration will allow buyers to filter the catalogue by specified tea

attributes or parameters. Product comparison will allow buyers to compare different teas
offered in the catalog.
eAuction Module
This component will enable auction activity management and facilitate electronic auction of
teas. It will also support managing parameters used by the auction organizer EATTA. It will
contain an auction floor set up feature for each broker and an administration feature for EATTA
to organize the auction activities. The main objective of the e-auction module will be to
facilitate price discovery, enable matching between buyers and sellers and increase speed and
efficiency of the auction.
It will have a feature for creation and management of auction floors for each broker. Each
broker will have an auction floor where all settings and parameters will be managed. The
current rotation in relation to brokers will be maintained. Each auction floor will have all
gardens for sale, price and attributes with options for online bidding, time to complete the bid,
no of buyers biding.
The system will support the current rotation of brokers and ascending order auction model with
an option for broker to set reserve price. It will have the option and parameters to receive
online bids from buyers and accept Bid by brokers. It will reconcile all auction sales data
including out lots and sale price. It will support reporting and historical analysis of all auction
activity. The System will also follow the eAuction guideline and EATTA rule.
Business Module
This component will control the initiation and flow of all tea trade business transactions
including tea offers/allocations, dispatch advice, receiving, catalog, sale order, delivery order,
invoice, payment confirmation, TRD and reporting data through the platform. Using a
notification feature all defined tea trade transaction documents and forms moving through the
defined approval flow will be converted into appropriate e-business messaging formats and
placed in the recipient’s inbox as a notification.
This module will support dynamic distinct access functionalities for all trading partners
including producers, buyers, brokers, warehouses and banks depending on their role. All
transactions and activities from the other modules (such as auctions and catalog) will be logged
and made available through the reporting tools.
The entire offer, dispatch, catalog, auction, order, fulfillment and payment process will be
tracked through this module. This module will also control creation and listing of gardens, tea
tasting results, and all associated attributes. It should allow for seamless integration with third
party applications including banks through a robust integration framework architecture. It
should be scalable, highly secure, and built on robust open architectures and global standards.
It should contain rich features for workflows, designing and generating reports, business
intelligence and data analytics.

2.3 User classes and characteristics
The following are the kinds of users of the iTTS system.
1. Administrators:
Administrators are the ones who adds or administers the parameters for each
stakeholder’s use of the system as defined below:
Super Admin – Has access and rights to the whole iTTS system. Super
Admin assign roles that define and limit which tasks other administrators
can perform.
Auction Admin – will administer and configure the Auction Module for
the Brokers and Buyers to use
Producer Admin – will administer the producer use of the system as well
as register producer users of the system
Warehouse Admin – will administer the warehouse use of the system as

well as register warehouse users who will carry out business transactions
at the warehouse
Buyer Admin – will administer buyer use of the system. The admin will
create buyer users and assign them roles with regard to various
transactions within the use of the system
Bank Admin – will manage the bank use of the system including managing
users
2. Producer User: This user will enter transactional data such as Tea dispatch, generate
Tea dispatch note among other tasks assigned by the Producer Admin.
3. Broker User: This user will do most transactions in the system such as receiving tea
allocations, creating catalogues, adding valuations to catalogues among other tasks as
assigned by the broker admin
4. Warehouse User: The warehouse user will receive tea from producer, generate Tea
Arrival Note and Weight Note among other tasks as assigned by the warehouse admin
5. Buyer User: The buyer user will enter taster’s comments, enter offline bids, bid for teas,
enter loading instructions among other task as assigned by the buyer admin
6. Bank User: The bank user will be assigned roles within the system by the Bank admin to
perform various tasks


2.4 Operating environment
Operating environment for the iTTS system would be as follows and would be finalized
during the approval of the infrastructure assessment report.
▪ Relational Database Management Systems
▪ 3-tier Architecture
▪ Operating system: Windows or Linux (as per clients’ preference)
▪ platform: Java/PHP
Though the iTTS system would be developed on open source platform, however, the end-users
would access the application on their preferred operating environment/browsers.
2.5 User environment

- Desktop or Laptop computers
- Smart Phones as well as Tablets running on Windows, iOS and Android.
- Dedicated Internet connectivity
- Power supply
2.6 User Documentation
The following documentation will be delivered along with the software:

- User Manual
- Online help
- Tutorials (YouTube videos)
2.7 Design/implementation constraints
There are few constraints that the system should follow. They are:
All the inputs should be checked for validation and messages should be given for the
improper data. The invalid data are to be ignored and error messages should be given in
case of mismatch of formats.
Details provided by the users during sign up should be stored in database.
While adding the data to the system, mandatory fields must be checked for validation
whether the user has filled appropriate data in these mandatory fields. If not, proper
error message should be displayed or else the data is to be stored in database for later
retrieval.

2.8 Assumptions and dependencies
A number of factors that may affect the requirements specified in the SRS include:
- EATTA Rule Book changes with accordance to requirements

- The system will be a web-based system and requires internet
connection for all stake holders
- Existing stakeholder’s systems will run concurrently
- Identification of the champion users for each of the user category
- Collection of the test data for the execution of the User Acceptance Test
- Availability of the Champion Users for the Train the Trainer (ToT)
sessions and various project related activities during the life cycle of the
project.
- Training/Conference Room facilities within and outside EATTA
- Provision of recommended hardware and infrastructure to host the
application during test environment and live production environment
- Dedicated Single Point of Contact from TMEA/EATTA for consultation
and approval for various milestone and related certifications thereof.
3. External Interface Requirements
3.1 User interfaces
iTTS users will be required to have a computer that has an operation system and a web
browser. iTTS will be support all major web browsers that will make it convenient for the user
to access the system with ease. The browsers to be supported include Internet Explorer, Mozilla
Firefox, Google Chrome and Opera among others.
3.2 Hardware interfaces

The following servers may be deployed for iTTS:
- Database Server
- Transaction Server
However, the final hardware specifications would be provided after the completion of Infrastructure Assessment
Report.
3.3 Software interfaces
Sl. no Category Description

1 OS Required Windows Server 2012 / Red Hat Linux 7.3
2 Application Java Spring Boot Framework, JPA, Spring Security,
Framework Thymeleaf

3 Database Server MySQL

4 Web Server Tomcat 8
5 Web Browsers Internet Explorer(IE 11 and above), Firefox & Chrome
3.4 Communication protocols and interfaces
The iTTS shall use the HTTPS protocol for the communication over the internet and for the
intranet communication will be through TCP/IP protocol suite
4. System Features
The system features are categorized into 5 categories
 General system features

 Pre-Auction features
 Auction features
 Post-Auction features
 Reporting and Business Document Exchange Specifications
4.1 General system features
The General System features consists of the Membership Module which involves the
process of Registration of various stakeholders like Producers, Brokers, Buyers,
Warehouses, Banks, Packers and Transporters entities. It also consists of the creation of
Admins for each entities of stakeholders. These Admins will look into every aspect of
registration of the respective entities’ users, updating of profile. There are also certain
settings which Admin(Producer) will do in their account like “Tagging of Brokers” , “Tagging
of Warehouses”, “Tagging of Transporters”.
4.1.1 Member Registration
4.1.1.1 Description and Process Flow

The following will be the process for Membership Registration
a) Exiting Users:
All existing users’ data will be migrated into the iTTS system. Following which system
generated credentials will be provided to them. All existing users will get certain
days’ time period to ensure their profile is updated by uploading mandatory
certificates.
Following which EATTA super admin will lock their profile account and update the
status to “Working”. For those, who have not updated their profile, the status will
remain as “Non-Working”.

Prerequisite:
1. Existing Data of all stakeholders needed to create profile of them and
provide user credentials.
2. Structure of existing data
3. Time Period for all stakeholders to update profile.
b) New Users:
On the transparency portal, any new entity who wants to be a part of Tea Auction
process can be a part by registering themselves on the Portal. Upon registration,
they will receive a temporary credential using which they can update their profile
and submit all necessary documentations. An Acknowledgement number of that
application will need to be submitted along with Physical documents of the
certificates at EATTA. Upon submission, the application will be forwarded to EATTA
membership user, who will do the initial verification. Upon confirmation from the
Membership user, a request will be send to the registered user to make the
payment online. Upon successful receipt of the payment, the application will be
send to Board member user to approve the request. Upon approval system will
update the status as “Working”.
Prerequisite:
1. Listing of Mandatory documents for registration.
2. Online integration with Banks through online payment aggregator.
c) Renewal of Users:
EATTA will keep a track of all users Effective and Expiry date. EATTA will thus update
the Renewal Costs breakdown and then submit a renewal payment due date.
System will also allow EATTA to give the user a grace period for payments (in days).
If the user do not pay within the given grace period, system will update the status of
the user as “Non-Working member” and block the user from any activity in the
system.
If the user pays within the given period then EATTA user to verify the payment and
update the status of user as “Working member”. EATTA user also to update the new
Effective and Expiry dates for the user.
4.1.1.2 Functional Requirements
Feature Requirements: Member Registration (FR-MR)
Feature ID Feature Name Feature Description

FR-MR-1 Register member The system shall enable registration of Member
categories Categories
i. Producer
ii. Broker
iii. Buyer
iv. Producer Warehouse

v. Broker Warehouse
vi. EATTA (Super Admin / Auction Admin /
Membership Admin User)
vii. BANK
viii. Transporter
ix. Packers
FR-MR-2 Register members The system shall allow registration for becoming
EATTA members
FR-MR-3 Codification Currently there is manual codification based on
Stakeholders names
System will allocate a unique code / identity through
which each Stakeholder's trade information /
transactions can be identified.
FR-MR-4 Update members The system shall allow members to update their
profile profile
FR-MR-5 Upload The system shall enable users to upload various
certifications certifications
FR-MR-6 Generation of The system shall be able to generate a new
Acknowledgement acknowledgement number for all new applications.
Number
FR-MR-7 Update Status The system shall allow EATTA membership user to
update status of each members based on their
application status
FR-MR-8 Verification and The system shall allow EATTA membership user to
demand payment verify the details of each new user and demand the
of fees payment of applicable fees. If note meeting criteria
then EATTA membership user will reject the
application.
FR-MR-9 Subscription Rate The System shall have the latest Rate sheet to pre-
Sheet calculate
FR-MR-10 Forward of The system shall allow EATTA membership user to
applications check payment status and forward application for
approval to the EATTA board user
FR-MR-11 Approval EATTA board user will Approve the application after
board approval.
FR-MR-12 Existing User Entry System will allow EATTA user to add information of
existing user to create their credential
FR-MR-13 Pending Payment System shall allow EATTA user to request for pending
dues payment dues and giving the grace period to pay.
FR-MR-14 Update user status System shall allow EATTA admin user to update a
/ Block unblock status of an entity. This screen can be used to suspend
user / block any user with comments.
FR-MR-15 Bank information System shall allow entity users to update bank details
update and upload bank information details. This will be
verified by EATTA admin and approved. Upon

approval, system will update the bank details in its

system.
4.1.1.3 Notifications
1. Once all the stakeholders’ information are updated in system, system will send SMS
/ email / system based notification on user credential to the registered
mobile/email address / dashboard respectively.
2. There will be a reminder on updating of profile 3 days prior to the deadline.
3. Upon updating of status by the super admin, notification will be send to concerned
stakeholders.
4. System will keep a check on expiry dates of license dates and remind the
stakeholders on renew of licenses.
4.1.2 User Registration
Upon successful registration of Stakeholders’ Entity, each Entity will get a link to register its
own users in the system. The Entity will act as an administrator for its users.
Feature Requirements: User Registration (FR-UR)

FR-UR-1 Register users The system shall allow registration of users by the
respective stakeholders’ entity
FR-UR-2 Assign Roles The system shall allow stakeholders’ entity to assign
Roles and links to their respective users.
Upon successful registration of user, user will be notified on the credentials

1.
through SMS/ email.
4.1.3 User Roles
The Entity will act as an administrator for its users whereby it will assign the various roles
and links to the user to perform the daily activities.

Feature Requirements: User Roles (FR-USR)

FR-USR-1 Create user roles The system shall allow Entity admin user to
create and define roles
FR-USR-2 Assign user roles The system shall allow Entity admin user to
assign roles
1. Upon successful registration of user, user will be notified on the credentials

through SMS/ email.
4.1.4 Garden Registration
Producers’ Entity Admin can register gardens also known as marks. They can also update
or delete them in case they are not used in the system. Upon registration of new
gardens, they need to update the production start date of the Garden.
Feature Requirements: Garden Registration (FR-GR)

FR-GR-1 Add/Remove The system shall enable producer add/remove
garden/mark tea garden/mark
FR-GR-2 Update garden/mark The system shall allow producer update tea
details garden/mark profile
1. Upon addition of new gardens, EATTA admin user will be notified on the garden
and its estimated production date.
2. A Notification will also be sent to the associated Broker for that Producer.

4.1.5 Warehouse & Godown Registration
Warehouses’ Entity Admin can register Warehouse locations and also the godowns for
each warehouse. They can also update or delete them incase they are not used in the
system. These Warehouse listing will be available to Producer to appoint while dispatch
of teas. Subsequently when warehouse receives the Tea, they can update in system ,
which godown it is allocated to. The information on Warehouse-Godown will be
available across catalogues and also on post auction activities like Invoices, TRD,
Delivery note as well as on Loading instructions.
Feature Requirements: Warehouse Registration (FR-WR)

The system shall enable Warehouse Admin to
FR-WR-1 Add/Remove add/remove
Warehouse/godown Warehouse/godown
Update
FR-WR-2 Warehouse/godown The system shall allow Warehouse Admin update
details Warehouse/godown profile
1. Upon addition of new Warehouse or godown, Warehouse Admin as well as

Producer associated with that warehouse will be notified.
4.1.6 Appoint Broker
Producers Entity Admin will appoint brokers with which to sell teas through the auction.
They can also enable or disable them

Feature Requirements: Appoint Broker (FR-AB)

The system shall enable producer entity admin to
FR-AB-1 Select broker(s) appoint broker
The system shall allow the producer entity
FR-AB-2 Enable/disable admin to
broker(s) enable/disable their brokers
1. A Notification will also be sent to the associated Broker for that Producer and
the users of that Entity producer.
4.1.7 Appoint Warehouse
Producers and buyers will appoint producer warehouses and buyer warehouses respectively to
store and handle their teas. They will also enable or disable them.
Feature Requirements: Appoint Warehouse (FR-AW)

The system shall enable producer entity admin
FR-AW-1 Select producer appoint
warehouse producer warehouse
The system shall allow producer entity admin
FR-AW-2 Enable/disable enable/disable
Producer warehouse producer warehouse
The system shall enable buyer entity admin
FR-AW-3 Select buyer appoint buyer
warehouse warehouse
The system shall allow buyer entity admin
FR-AW-4 Enable/disable buyer enable/disable
warehouse buyer warehouse
1. Upon updating by the producer entity admin, a notification will be send to the
Producer warehouse.
2. Upon updating by the buyer entity admin, a notification will be send to the buyer
warehouse.

4.1.8 Portal Features
The system shall allow members access general information concerning the Trade
The system shall allow members access industry bulletins
The system shall allow members to communicate through chat groups (enabling support
team to send messages to stakeholders)
The system shall allow members receive notifications from the Trade.
Feature Requirements: Portal Features (FR-PF)

The system shall allow Super Admin to Create /
FR-PF-1 Primary Links View and update Primary Links
FR-PF-2 Secondary Links View and update Secondary Links / Sub Links
View and update Content in a template based
FR-PF-3 Template based pages page
FR-PF-4 Video Links embed View and update video links (ex: youtube)
The system shall allow Super Admin to upload /
FR-PF-5 PDF Upload Delete PDF files
Publish Unpublish The system shall allow Super Admin to set publish
FR-PF-6 content dates / remove the content by unpublishing
Target Stakeholders The system shall allow Super Admin to send target
FR-PF-7 Notification based notifications to various stakeholders
1. Based on the target based notifications set by Super Admin, system will send notifications to all identified
stakeholders.

4.2 Pre-Auction Features
The Pre-Auction features consists of the Catalogue Module as well as business module which
starts from the Producers dispatching Tea to Warehouse , followed by Producers appointing
broker to catalogue the tea. The broker involves tea- tasters to identify and catalogue the teas
and derive the final price of the Tea. Brokers also send samples of Tea to Buyers. Once Brokers
have settled the price of Tea with Producers, they prepare a final catalogue and submit to
EATTA for eAuction.
4.2.1 Dispatch Tea
Tea dispatch is done by the producer. It involves choosing the warehouse where Tea will
be dispatched and by entering details of tea being dispatched to that producer
warehouse. The following properties are currently entered:
Property Name Property Description

The factory or producer where the tea
Garden has been produced and packaged
Uniquely identifies the batch of tea
Invoice packed at the producer
Grade Grade type of Tea e.g. BP, PF1, F1, PD, DUST1
Packages Number of bags per Invoice / batch
Packaging Type Type of packaging e.g. bags
Net Weight Net Weight of the invoices/batch
Tare Weight Tare weight of each invoice
Gross Weight Total weight of each invoice including the tare weight
Pallet weight Captures Pallet weight (in kgs)
Packaging Date Date when the invoice/batch was packed
Dispatch Date Date when the dispatch to warehouse is made
Dispatch # Uniquely identifies the dispatch information
Kgs Per Package Number of kgs per package e.g. kgs per bag
This is the Base price margin/Least price margin(per KG)
updated by Producer. This is an indicative price for broker to set
Base Sale Price the tea valuation.
Destination – warehouse where the tea will be delivered to on
Warehouse dispatch which is usually a producer warehouse
Remarks Remarks contain any free form text for the Dispatch Summary.
Transporter Info –
Name Name of the Transporter
Address Address of the Transporter
Lorry # Lorry Number of the Transporter

Driver Name Driver Name of the Lorry
Driver ID Nos Driver ID number of the Lorry
TurnBoy Name Turnboy Name of the Lorry
TurnBoy ID Nos Turnboy ID Number of the Lorry
Factory Supervisor
Name Name of Supervisor of the factory
Factory Manager Name Name of Factory Manager of the factory
4.2.1.2 Prerequisite
1. Dispatch Tea format should be standardize across Producers.

2. Excel Format to upload Dispatch information from various producers to be standardize.
Feature Requirements: Tea Dispatch Note (FR-TD)

The system shall enable the producer user to
FR-TD-1 Create New Dispatch enter information of teas ready for dispatch
FR-TD-2 Tea Dispatch Note generate Tea Dispatch Note
FR-TD-3 Modify Tea Dispatch modify a dispatch note of that day.
View/Track/Reconcile The system shall allow the user to track and
FR-TD-4 dispatched Teas reconcile as well as view all dispatched teas
The system shall provide EJB based API services to
be called by Producer system to import
information of teas for dispatch.
Import dispatch Another option of updating the information

FR-TD-5 information through standard excel upload format
1. Upon generation of Tea Dispatch Note, notifications will be send to Producer admin,
Producer user, Warehouse Admin, Transporter Admin and truck driver.

4.2.2 Producer Warehouse Tea Receive
Producer warehouse receive tea dispatched from various producer factories. Once
received, the tea invoices are weighed and the details entered into the system.
The Warehouse men will allocate the particular godown for the arrived stock. Tea arrival
advice is generated and is made available to the producer factory. Tea details from the
Tea Dispatch are displayed on the receiving form and the following new properties are
entered:
Property Name Property Description

Date Received The date when the tea is received
Warehouse-godown
info The Warehouse and godown information will be listed
Packages (Warehouse) Number of bags per Invoice / batch
Net Weight
(Warehouse) Net Weight of the invoices/batch
Gross Weight
(Warehouse) Total weight of each invoice including the tare weight
Kgs Per Package
(Warehouse) Number of kgs per package i.e. kgs per bag
Remarks (Warehouse) Remarks contain any free form text for the Dispatch Summary.
This will show the difference in figures of Gross weight of that
Gain/Loss invoice.
Type This will show whether this Invoice is Reprint / New
1. Warehouse receipt / Tea weight Note format should be standardize across Warehouses.
2. Warrant description to be standardized.
Feature Requirements: Producer Warehouse Tea Receive (FR-PWTR)

Create New Tea The system shall enable the warehouse to enter
FR-PWTR-1 Receive details of teas received
Tea Receipt The system shall allow the warehouse confirm
FR-PWTR-2 Confirmation receipt of teas by generating Tea Arrival Advice
The system shall enable the warehouse to
Tea weight note generate the Tea Weight Note and is made
FR-PWTR-3 generation available to the broker

The system shall allow the warehouse user to

View/Track/Reconcile track and reconcile as well as view all received
FR-PWTR-4 Received Teas teas
be called by Producer warehouse system to
import information of teas receipt.
Import producer
Warehouse Tea Another option of updating the information
FR-PWTR-5 Receive information through standard excel upload format
1. Upon generation of Tea Dispatch Note, notifications will be send to Producer admin,
Producer user, Warehouse Admin, Transporter Admin and Broker.
4.2.3 Tea Allocations
Producers select and offer tea, for auction, to brokers in order for the broker to include
the tea in the pre-auction catalogue. This process of Tea Allocation can only happen when
the tea is already in the producer warehouse and the Tea weight note is generated
through the system. The following properties are required for the tea allocation:
Property Name Description Comment

Uniquely identifies the batch of tea
Invoice packed at the producer From Producer Tea Dispatch
Grade type of Tea e.g. BP, PF1, F1,
Grade PD, DUST1 From Producer Tea Dispatch
From Producer Warehouse Tea
Packages Number of bags per Invoice / batch Receive
Packaging Type Type of packaging e.g. bags Receive
Number of kgs per package e.g. kgs From Producer Warehouse Tea
Kgs Per Package per bag Receive
Net Weight Net Weight of the invoices/batch Receive
Total weight of each invoice From Producer Warehouse Tea
Gross Weight including the tare weight Receive
Date when the invoice/batch was
Packaging Date packed From Producer Tea Dispatch
Date when the tea allocation to
Allocation Date broker is made New property
Auction sale number represents the New property (selected from
Sale Number auction number the tea is Auction sale list)

offered/allocated for sale as defined

by the auction organizer
Broker company offered the tea for
sale at the auction. Broker includes New property (selected from
Broker the tea on the auction Catalogue registered brokers)
The type of auction where the tea
Auction Sale invoices are offered. i.e Primary or New property (Selected from
Type Secondary auctions Sale Types)
Remarks contain any free form text
Remarks for the Dispatch Summary. New property
1. Tea allocations can only be enabled after tea weight note is generated by the producer
warehouse.
Feature Requirements: Tea Allocations (FR-TA)

The system shall enable producers to select
FR-TA-1 Allocate Teas teas for allocations to brokers
The System will generate a unique Tea
Allocation Number to identify individual
FR-TA-2 Tea Allocation Number producers’ allocations to Broker.
The system shall enable the producer
Update/Recall Tea update/recall tea allocations from brokers
FR-TA-3 Allocations before the set time
View/Track/ Reconcile The system shall allow the producer track and
FR-TA-4 Tea Allocations reconcile tea allocations
The system shall provide EJB based API services
to be called by Producer system to import
information of teas receipt.
Another option of updating the information

FR-TA-5 Import Tea Allocations through standard excel upload format
1. Upon generation of Tea Allocation Number, notifications will be send to Producer

admin, Producer user and Broker.

4.2.4 Pre-Auction Catalogue
Broker creates Pre-Auction Catalogue, otherwise known as closed catalogue, based on tea
allocations from the producers. All teas that have been offered to a particular auction sale
are given lot numbers. These lot numbers can be reorder based on Broker choice. Once
the Pre-Auction Catalogue is closed, no more allocations (new/modification) can be done.
The following properties are required for Pre-Auction Catalogue:
Property Name Description Comment

Auction sale number uniquely identifies
Sale Number an auction as defined by the auction organizer New property
Sale Date This is the date when the auction happens New property
Warehouse- From Producer Warehouse
godown Warehouse – godown where the tea is stored godown Tea Receive
Uniquely identifies the lot at the auction sale. Each
tea invoice is allocated a lot number for a given
Lot auction. New property
From Producer Tea
Grade Grade type of Tea e.g. BP, PF1, F1, PD, DUST1 Dispatch
Uniquely identifies the batch of tea packed at the From Producer Tea
Invoice producer Dispatch
From Producer
Packages Number of bags per Invoice / batch Warehouse Tea Receive
From Producer
Packaging Type Type of packaging e.g. bags Warehouse Tea Receive
From Producer
Kgs Per Package Number of kgs per package e.g. kgs per bag Warehouse Tea Receive
From Producer
Net Weight Net Weight of the invoices/batch Warehouse Tea Receive
Comment contains any free form text for the lot in New property
Comment the catalogue
All the formats should be standardized.

Feature Requirements: Pre-Auction Catalogue (FR-PAC)

Generate Pre-Auction The system shall enable the broker to generate Pre-
FR-PAC-1
Catalogue Auction catalogue based on allocated teas
Update/Edit Pre- The system shall allow broker to edit/update Pre-

FR-PAC-2
Auction Catalogue catalogue before closing/publishing
Reorder Pre-Auction The system shall allow broker to reorder the lots in
FR-PAC-3
Catalogue the pre-auction catalogue
Close/Publish Pre- The system shall enable the broker to

FR-PAC-4
Auction Catalogue close/publish Pre-Auction catalogue
Search/View Closed Pre- The system shall allow member users to
FR-PAC-5
Auction Catalogue search/view closing catalogues
The system shall enable broker to log and search
tea samples. For Logging the samples, broker will
FR-PAC-6 Log Tea samples have to choose Invoice and select the list of buyers,
it is send to. System can track samples based on
brokers, invoice, Buyers.
The system shall enable brokers to mark certain

Marking out lots for out-lots as “Sold Privately”. This will remove the
FR-PAC-7
private sales Out lot from future tracking under Auction or Post
auction process.

be called by Broker system to import information
Import Pre-Auction of teas receipt.
FR-PAC-8
Catalogue
through standard excel upload format
1. Upon generation of Pre-Auction catalogue, notifications will be send to Producer admin,

Producer user, EATTA admin and Buyers.

4.2.5 Amend Pre-Auction Catalogue
The broker will carry out any necessary amendments to the closed catalogue. This
includes withdrawing and recalling lots to the catalogue.
Not Applicable
Feature Requirements: Amend Pre-Auction Catalogue (FR-APC)
Update Pre-Auction The system shall enable the broker to amend

FR-APC-1 Catalogue details of the Pre-Auction catalogue
Withdraw lot from Pre- The system shall enable the broker to withdraw a
FR-APC-2 Auction Catalogue lot from the Pre-Auction catalogue
Re-publish Pre- Auction The system shall allow the broker approve and
FR-APC-3 Catalogue re-publish amended catalogue
1. Upon updating of Pre-Auction catalogue, notifications will be send to Producer admin,

Producer user, EATTA admin and Buyers.

4.2.6 Add valuations and taster’s comments to Pre-Auction Catalogue
Broker adds valuations to lots in a catalogue. The prices from the preceding auction are a
major determinant of the value of each and every lot in the pre-auction catalogue. Broker
also adds taster’s comments, in the taster comment field, on lots in the catalogue.
Not Applicable
Feature Requirements: Add valuations and taster’s comments to Pre-Auction Catalogue

(FR-AVP)
Add valuations to pre- The system shall allow the broker to add
FR-AVP-1 auction catalogue valuations to the Pre-Auction catalogue
The system shall allow the broker to enter

taster’s comments on lots in the Pre-Auction
Enter taster’s Catalogue. The taster’s comment is solely for the
FR-AVP-2 comments Broker.
System will provide an option to Broker to enable
/ disable taster’s comments and valuation to
producer.
Enable / Disable
valuation and taster’s
comment visibility to
FR-AVP-3 Producer
be called by Broker system to import information
of teas receipt.
Import valuations and Another option of updating the information
FR_AVP-4 taster’s comments through standard excel upload format
1. Upon updating of valuation, notifications will be send to Producer admin, Producer user
if the setting to notify will be enabled by Broker.

4.2.7 Valuation Catalogue
The broker user shall submit the sale valuation catalogue. Once the valuations and taster’s
comments have been entered, the pre-auction catalogue becomes the valuation
catalogue. Once submitted, the Auction Admin publishes the sale valuation catalogues
and becomes available to members of trade for viewing and comparison purposes. The
taster’s comments are not displayed to anyone except the broker.
1. Valuation catalogue format should be standardize across Producers
Feature Requirements: Valuation Catalogue (FR-VC)
Submit valuation The system shall enable the broker submit

FR-VC-1 Catalogue valuation catalogue
Publish valuation The system shall allow the Auction Admin to
FR-VC-2 catalogues publish valuation catalogues
Search and view
valuation The system shall enable member users to
FR-VC-3 Catalogues search/view valuation catalogues
Compare valuation The system shall enable member users compare
FR-VC-4 Catalogues valuation catalogues
1. Upon submission of Valuation catalogue, notifications will be send to EATTA Admin.

2. Once Valuation catalogue is published by EATTA admin, notifications will be send to
Producer admin, Producer user, EATTA admin and Buyers.

4.2.8 Buyer Valuations
Buyers shall have an opportunity to enter their own offline valuations on lots in the
published Sale valuation Catalogues. These valuations should only be visible to
themselves. This will guide them when bidding for the teas at the auction. Buyers shall
also enter taster’s comments on various lots tasted. Buyers shall select and create a
gallery of teas of interest and this will be displayed on a separate window highlighted to
them when bidding.
1. Taster’s comments should be standardize for all Buyer’s
Feature Requirements: Buyer Valuations (FR-BV)

Enter buyer The system shall enable the buyer to enter
FR-BV-1 valuations valuations on lots of interest
Enter buyer taster’s The system shall allow the buyer to enter
FR-BV-2 comments taster’s comments on lots
The system shall enable the buyer select and
Create gallery of create a gallery of favorite teas from the
FR-BV-3 favorite teas Catalogue
Upon updating of Valuation by Buyer, system will notify the Buyer admin.

4.3 Auction Features
The Auction features consists of the Auction Module which starts from EATTA admin creating
the auction floor.
The Methods of Auction will be Sequence Based (for within compound auction) and Timing
based (for outside compound auction).
Sequence Based Auction:

A Sequence based Auction is one whereby Auction Admin chooses the sequence or order of
Broker based on existing rotation policy.
On the day of the auction, the Broker will login to system and click on “START AUCTION”.
System will check for his sequence number and then will start the auction.
The system will display the list of lots for auction starting with 1st lot in the broker’s catalogue.
The time duration for each lot will be 30 seconds (configurable). Buyers can bid during this 30
seconds time period. When a Buyer (say X) bids, the booking period is set at 10 Seconds
(configurable). if no bidder bids within that 10 seconds then Buyer (X) wins.
Similarly if a bidder (Y) had bid, then system gives another 10 seconds to all buyers. Similarly
the auction continues. After Lot 1 is over, auction moves to Lot 2.
In cases, where no bidder are showing interest to bid, then Broker can reduce the base price for
that lot within the stipulated 30 seconds to attract buyers else as soon as 30 seconds is elapsed,
system will update the lot as an OUT lot.
Timing Based Auction:

A timing based Auction is one whereby Auction Admin chooses the start time of the Auction as
well as sequence of the brokers.
System will then derive the slots of auctions for the broker’s based on a formula as listed
below:
Ex: Auction admin sets the Auction to start at 7:30 AM with Broker A followed by Broker B
(rotation) and system will derive the timing as such.
Broker Lots Count Time needed Auction Start time Auction End Time
Broker A 100 100*30secs = 7:30 8:40
3000 Secs = 50
Mins + Grace
Period 20 mins
(20 mins / 100
lots)
Broker B 150 150*30Secs = 8:45 10:30
4500 secs = 75
mins + Grace

Period 30 mins
(20 mins / 100
lots)
Broker C 75 75*30Secs = 10:35 11:28
2250 secs = 38
mins + Grace
Period 15 mins
(20 mins / 100
lots)
After this on the time as mentioned in the above setting system will auto start auction for the
respective buyer (A) catalogue.
The system will display the list of lots for auction starting with 1st lot in the broker’s catalogue.
The time duration for each lot will be 30 seconds (configurable). Buyers can bid during this 30
seconds time period. When a Buyer (say X) bids, the booking period is set at 10 Seconds
(configurable). If no bidder bids within that 10 seconds then Buyer (X) wins.
Similarly if a bidder (Y) had bid, then system gives another 10 seconds to all buyers. Similarly
the auction continues. After Lot 1 is over, auction moves to Lot 2.
In cases, where no bidder are showing interest to bid, then Broker can reduce the base price for
that lot within the stipulated 30 seconds to attract buyers else as soon as 30 seconds is elapsed,
system will update the lot as an OUT lot.
If there is a scenario whereby there are few lots left to be auctioned and the time period fixed
has elapsed then all the said lots will move to a consolidated Lots (Pending Lots) section.
The Pending Lots section will start only after all Brokers sequence has finished. The process of
auctions of all Pending Lots will work as explained above.
Split Lot
As per the EATTA rule 34, For CTC Main Grades, the minimum quantity of packages for a lot will
be 40, and for Secondary Grades, the minimum quantity of packages for a lot will be 20.There
will be no division of lots consisting of for 40 packages, however, lots of 60 packages can be
divided between two Buyers and lots of 80 packages or more, among three Buyers.
During eAuction, the system will work in the following manner:

For Lot of 60 packages,
1. If there is a buyer (X) who bids, say 2.5 $ and if no one else bids then Buyer (X) wins the
entire 60 packages.
2. If another buyer (Y) also bids the same price, 2.5 $ then system will give Buyer(X) 40 and
buyer (Y) 20.
3. If another buyer (Z) also bids the same price, 2.5 $ then system will give Buyer(X) 20 and
buyer (Y) 20 and buyer (Z) 20.

4. System will not allow any other bidder to quote 2.5 $. They may bid more than 2.5 $.
For Lot of 80 packages,

5. If there is a buyer (X) who bids, say 2.5 $ and if no one else bids then Buyer (X) wins the
entire 80 packages.
6. If another buyer (Y) also bids the same price, 2.5 $ then system will give Buyer(X) 60 and
buyer (Y) 20.
7. If another buyer (Z) also bids the same price, 2.5 $ then system will give Buyer(X) 40 and
buyer (Y) 20 and buyer (Z) 20.
8. If another buyer (A) also bids the same price, 2.5 $ then system will give Buyer(X) 20 and
buyer (Y) 20 and buyer (Z) 20 and buyer (A) 20.
9. System will not allow any other bidder to quote 2.5 $. They may bid more than 2.5 $.
Single Sign-on
1. In order to protect from unwanted spikes during the peak period of auction, system will
allow only a single session of a user credential to work.
2. If the User (Buyer A) has already logged in and is again trying to login, then system will
warn him that there is already an active session of that user.
3. System will then ask him whether he wants to Kill the other session or logout himself.
4. If the user (Buyer A) Kills the other session, then the previous logged in user (Buyer A)
will be logged out and the current user will continue to work.
5. If the user (Buyer A) logs out then there will be no effect on the active session of
previous logged in user (Buyer A).
6. This feature will not be limited to only Buyer but to EATTA Admin, Producer Admin,
Producer User, Broker Admin and Broker User as well during the auction days.
7. The login will also be restricted to OTP based login.
Configurable Settings:
1. Settings in system to start an auction as Sequence based / timing based.
2. Settings in system to display X number of lots to buyers.
3. Settings in system to change each Lot time limit for that day’s auction. Default is 30
seconds.
4. Settings in system to change booking period after a buyer bid. Default is 5 seconds.
5. Settings in system to change grace period. Default is 20 mins per 100 lot or 0.2mins/lot.
6. Settings in system to change GAPS between 2 catalogue auctions. Default is 5 mins.
7. Settings in system to maintain anonymity of Buyer. Default is set as “Not Visible”.
8. Settings in system to set increment / decrement values (+10 cents, +20 cents etc).
9. Settings in system to show 1 lot / multiple lots for auction at certain time.
10. Settings in system to allow multiple buyer users from one entity.

4.3.1 Auction Administration
Auction Admin (AA) will create auctions and allocate them sale numbers and dates. Buyer
bidding floors shall also be created by the Auction Admin as well as broker auction floors
based on rotation and auction rules. AA will also set auction configurations such as the
auction type, auction session time, lot time, booking period, grace period, Gaps between
Auction catalogue, Increment and decrement list of values, buyer anonymity/known
options.
1. List of configurable Settings to be finalized.
Feature Requirements: Auction Administration (FR-AA)

The system shall enable the Auction Admin to
FR-AA-1 Create Auction details create Sale No and Sale Date information
Create Buyer bidding The system shall enable the Auction Admin to
FR-AA-2 floor set/create buyer bidding floors
Create Broker bidding set/create broker auction floors based on
FR-AA-3 floor rotation and auction rules
The system shall allow the Auction Admin to set
auction type: 1. Sequence Based Auction
FR-AA-4 Set Auction Type 2. Timing based auction
The system shall allow the Auction Admin to set
Display lots per The count of lots to be displayed in a catalogue
FR-AA-5 catalogue to all buyers.
The system shall enable the Auction Admin set
Each lots time limit for that day’s auction.
FR-AA-6 Set Lot time out Default is 30 seconds
change booking period after a buyer bid. Default
FR-AA-7 Set booking period is 5 seconds
change grace period. Default is 20 mins per 100
FR-AA-8 Set Grace Period lot or 0.2mins/lot
Set buyer anonymity The system shall enable the Auction Admin to
FR-AA-9 or known set buyers anonymous or known


Set Gaps between change GAPS between 2 catalogue auctions.
FR-AA-10 auctions Default is 5 mins
Set Increment / set increment / decrement values (+10 cents,
FR-AA-11 Decrement Values +20 cents etc).
In order to protect multiple log-in using single
Single Session per User user, system would allow only single session per
FR-AA-12 System user.
Not Applicable.
4.3.2 e-Auction system – Broker floor
Broker shall start the auction based on rotation and auction rules. Broker shall view and
monitor the bidding process, adjust ask price either downwards or upwards. Broker can lower
price to attract more buyers if no buyer is showing any interest for a Lot. Lots without any bids
will automatically become out lots when the Lot time is elapsed.
Not Applicable
Feature Requirements: Broker Floor (FR-BF)

FR-BF-1 Start the Auction The system shall enable the broker to log into
auction floor and START the auction (Sequence
based auction)
FR-BF-2 View bidding process The system shall allow the broker to view
bidding progress
FR-BF-3 Adjust ask price The system shall allow the broker to adjust ask
price upwards or downwards
The System shall trigger Single Sign on
FR-BF-4 Single Sign on Functionality during auction process

Not Applicable
4.3.3 e-Auction system – Buyer floor
The buyer will log into the bidding floor, view the lots for sale and place bids. The buyer shall
adjust the bid upward when he/she is outbid. When bidding, the buyer shall an indicator to
display favorite lots. The buyer shall get his share of split lots based on the system logic
provided above.
The Buyer dashboard will be segregated to sections.

1. Live Auction details
2. Favorite Auction List
3. Buyer’s Current auction details
a. Total Lots won
b. Total Qty Won
c. Total Money Spent
d. Breakdown by Grade
4. Auction history
The buyers will have 2 to 3 user logins for Auction users. This is based on EATTA setting for each
buyer. Based on this the Buyer Entity admin must create the allowed number of users.
Once users are created, system shall allow Admin to segregate Lots for upcoming auctions for
these users. These can be segregated by Grade, by Brokers, or by lots. Based on this, on the day
of auction, the users will see the “Live Auction details” based on the Lots which is assigned to
them. If no setting is set by Buyer Admin, then the first user will only see all list of auctions and
no other will see the list.
1. eAuction guideline need to be released as an EATTA rule.

Feature Requirements: Buyer Floor (FR-BYF)

FR-BYF-1 Log in to buyer The system shall enable the buyer to log in to
their bidding floor, view the teas for sale and
bidding floor asking price
FR-BYF-2 Enter bids The system shall allow the buyer to enter their
bid for teas per lot
FR-BYF-3 Adjust bids The system shall allow the buyer to adjust their
bid price upwards
FR-BYF-5 Display highest bid The system shall allow the buyer to view highest
bid for each lot
Highlight buyer’sThe system shall highlight buyer’s favorite tea

FR-BYF-6 favorite tea lotslots
The buyer shall get his share of split lots based on
FR-BYF-7 Split lots the system logic provided above
FR-BYF-8 Single Sign on Functionality during auction process
Buyer Admin Create The system shall allow buyer admin to create
FR-BYF-9 multiple users multiple buyer users.
The system shall allow Buyer admin to assign lots
to each buyer user based on Grade / Broker /
FR-BYF-10 Assign Lots Lots
The system shall show unique dashboard to
FR-BYF-11 Buyer Dashboard separate buyer users.
Not Applicable

4.3.4 e-Auction system – Producer View
Producers shall log in and view the auction as it happens. They shall view results of their tea
immediately after the auction sessions are over.
Not Applicable
Feature Requirements: Producer View (FR-BYF)

FR-PV-1 Producer Log in and The system shall allow the producer to log in
view auction and view auction as it happens
FR-PV-2 Display producer lots The system shall display the producer lots
results results after the auction sessions
FR-PV-2 Single Sign on Functionality during auction process
Not Applicable

4.3.5 e-Auction system – Out lots system
When there is no interest shown in a lot during the auction, then upon expiry of the lot time,
system will automatically set the lot to be an Out lot. These out lots can be bought to Re-
Auction on the following day. The process of auction will still remain the same.
1. EATTA must clarify on the Out lot flow.
Feature Requirements: Out lots system (FR-OS)

The system will automatically set a lot to be an
out lot if no interest in bids is submitted within
FR-OS-1 Out lots the lot time period.
The system shall allow the producer and trade to
FR-OS-2 View Out lots view out lots
The system shall allow the broker to auction out
FR-OS-3 Auction Out lots lots
Add Out lots to a The system shall allow the broker to add out lots
FR-OS-4 catalogue to a catalog
Mark Outlots as Private The system shall allow the broker to set outlots
FR-OS-5 Sale as privately sold.
Not Applicable

4.3.6 e-Auction system – Auction Results
When the auction is over, members of trade will log in and view auction results. Auction history
and statistics will also be available to members. Search criteria based on auction parameters
will enable the members search and view auction history in different views. Each Auctioned
Lots audit trail report will also be available for view by the Trade.
Not Applicable
Feature Requirements: Auction Results (FR-AR)

FR-AR-1 View Auction Results The system shall enable trade, buyers and
producers to log in and view auction results
FR-AR-2 View Auction History The system shall allow trade to log in and view
and statistics auction history and statistics per
broker/buyer/garden Mark/producer
View Auctioned lots The system shall allow trade to log in and
FR-AR-3 Audit Trail view the auctioned lots audit trail report.
1. Once the Auction is over for the day, notifications will go to trade to login and view
auction details.

4.4 Post-Auction Features
The Post-Auction features consists of the business module which starts from the Brokers /
Producers/ Buyers / Warehouse / Admin / Bank downloading the result from the auction. The
system will provide options for downloading these reports:
1. Sale Catalogue
2. Total Out lots
3. Out Lots per Producer
4. Out Lots per Producer per mark
5. Total Sale Confirmation
6. Sale confirmation per Producer
7. Sale Confirmation per producer per mark
The brokers will also be able to generate Sale invoice from the system by choosing the lot won
by the buyer. These invoices will be available to be viewed by the Bank and respective buyers.
The invoices will be
1. Broker-Buyer Specific invoice report
2. Buyer Specific consolidated invoice report
Payment:
Once, the Buyer makes the payment through online payment gateway and can check for
payment confirmation, once payment is confirmed, a notification will go to respective brokers
of that Buyer to check the online status of the payment of the invoice. Once the status of
invoice shows as settled (meaning the money is distributed between brokers and producers), system
shall allow Broker to generate the TRD document which is based on invoice.
Alternate Solution (Payment):

Once, the Buyer makes the payment to the bank. Bank will need to update status of payment
for each invoice. Once the status of invoice shows as settled (meaning the money is distributed
between brokers and producers), system shall allow Broker to generate the TRD document which is
based on invoice.
Once TRD is generated, Broker can generate the Dispatch Order. This dispatch order will be
available for buyer’s to generate the Loading Instructions. A Loading Instruction can consist of
Multiple Delivery order from the same warehouse-godown. or 1 Dispatch order can generate 1
loading instruction. This loading instruction will be needed to release tea from Producer’s
Warehouse to Buyer’s Warehouse. The Producer warehouse will generate a Tea Release
Certificate which will be the end of Tea Post Auction Process.
Pre-Requisite
1. Bank to make online payment gateway live.
2. Bank to facilitate APIs for Confirmation of Online payment (thorough Transaction
number)
3. Bank to facilitate Settlement APIs to confirm payment done to brokers and producers
based on Invoice.

4. Committee to finalize whether the option to check invoice status to be only with broker
or can be given to Buyer as well.
5. Committee to finalize whether TRD / Delivery Order be generated by Buyer themselves
or need Broker to release.
4.4.1 Sale Confirmation
Sale confirmation is basically producer’s lots results in the auction showing the buyer and the
price at which the lots were sold. After auction ends, system will show this report whereby
Producer can check all his lots sold or out lot details. This can be segregated Mark/ Garden
Wise. A producer can view other Producers sold and out lot details
Not Applicable
Feature Requirements: Sale Confirmation (FR-SC)

FR-SC-1 View Sale The system shall enable the producer/buyer
confirmation view sale confirmation automatically as
Generated by the system after eAuction ends.
1. Once the Auction is over for the day, notifications will go to trade to login and view
auction details.

4.4.2 Sale Invoice
Brokers will generate sale invoices from the system by choosing the lot won by the buyer and
submit to buyers to enable them arrange for payment of tea bought in the auction. The invoices
are lot wise. (See 4.6 Requirement Specifications for Business Documents and Notifications BT-
1.6 – Sale Invoice)
Not Applicable
Feature Requirements: Sale Invoice (FR-SI)

FR-SI-1 Generate Sale Invoice The system shall enable the broker to generate
an invoice based on lot (1 Lot = 1 Invoice)
FR-SI-2 View Sale Invoice The system shall allow the buyer to view and get
Invoice. The Buyer can get the consolidated sale
invoice report too.
FR-SI-3 Download Sale The system shall allow the bank to login and get
invoice list the entire invoice data for payment settlement
Get Payment status of The system shall allow Brokers/Producers/Buyers
FR-SI-4 each invoice to get the status update of each invoice.
1. Once the Broker has generated the invoices, notifications will go to respective
Producers, Broker Admin, respective Buyers and Bank to login and view invoices details.

4.4.3 Issue settlement Instructions
The producer will set and issue settlement instructions per Sale Invoice through the system and
thereafter the bank will respond to that through payment settlement. Producer can always
check status of payment through each Sale Invoice Payment status.
1. All producers must have bank account.
Feature Requirements: Settlement Instructions (FR-SEI)

FR-SEI-1 Issue payment The system shall enable the producer to set
payment parameters/fees and instructions per
instructions Sale invoice
View Payment The system shall allow Brokers / bank and
FR-SEI-2 Instructions respective Producer to view Payment Instruction.
Download Payment The System shall allow bank user to download
FR-SEI-3 Instruction the payment instruction of each invoice.
Get Payment status of The system shall allow Brokers/Producers/Buyers
FR-SEI-4 each invoice to get the status update of each invoice.
1. Once the producers has set the payment instructions per Sale Invoice , notifications will
go to respective Broker Admin and Bank to login and view details.

4.4.4 Bank Access and Payment Confirmation
Banks shall log into the iTTS system and access settlement instructions from the producers.
Banks shall also access invoices and post-sale catalogue. After buyers have made payments to
the Sale Collection Account online, banks will transfer payments as per the settlement
instructions and update payment confirmations per Sale Invoice.
Not Applicable
Feature Requirements: Bank Access and Payment Confirmation (FR-BAPC)

FR-BAPC-1 Access settlement The system shall allow the bank to log in and get
instructions settlement instructions
FR-BAPC-2 Access Sale Catalogue The system shall enable the bank to access the
sale catalogue
The system shall allow the bank to get Sale
FR-BAPC-3 Access sale invoices invoices
FR-BAPC-4 Confirm Settlement of The system shall enable the bank to confirm
tea payment of teas per Sale Invoice
The system shall allow the producer, Buyer and
FR-BAPC-5 View payment broker
to view/get payment confirmation based on each
confirmation Sale Invoice
be called by Bank system to update payment
FR-BAPC-6 Interface with bank information.
system
through standard excel upload format
Not Applicable

4.4.5 Tea Release Document
Once payment has been confirmed, broker shall generate Tea Release Document (TRD). The TRD
shall be authenticated and made available to the buyer. TRD will be invoice specific. (See 4.6
Requirement Specifications for Business Documents and Notifications BT-1.7 – Tea Release
Document)
1. TRD will generate for those invoice whose payment status shows confirmed.
Feature Requirements: Tea Release Document (FR-TRD)

The system shall enable the broker to generate
Tea Release Document (TRD) based on payment
FR-TRD-1 Generate TRD confirmation
The system shall authenticate the TRD and make
it available to the buyer i.e TRD will generate for
FR-TRD-2 Authenticate TRD those invoice whose payment status shows confirmed
The system shall allow Buyer to view and
FR-TRD-3 View TRD download the TRD.
1. Once the Broker generates the TRD, Notification will be send to the Buyer admin and
Buyer user.

4.4.6 Delivery Order
Once TRD is generated, broker shall generate DO against that TRD. The DO shall be Invoice specific
and made available to the buyer. (See 4.6 Requirement Specifications for Business Documents and
Notifications BT-1.7 – Delivery Order)
2. DO will generate for those invoice whose TRD is generated.
Feature Requirements: Delivery Order (FR-DO)

The system shall enable the broker to generate
Delivery Order (DO) based on Tea Release
Document (TRD)
FR-DO-1 Generate DO
The system shall authenticate the DO and make
it available to the buyer i.e DO will generate for
those invoice whose TRD is generated.
FR-DO-2 Authenticate DO
The system shall allow Buyer to view and
FR-DO-3 View DO download the DO.
2. Once the Broker generates the DO, Notification will be send to the Buyer admin and
Buyer user.

4.4.7 Loading Instructions
Buyer will generate loading instructions by selecting from list of DO and send to the producer
warehouses. Loading instructions shall be accompanied by a copy of TRD and DO. 1 Loading
instruction can be generated from 1 DO or 1 Loading Instruction can be generated from
multiple DO provided all the DO have same warehouse-godown.
Not Applicable
Feature Requirements: Loading Instructions (FR-LI)
The system shall allow the buyer to generate

Loading instructions to warehouse on handling
of teas bought. 1 Loading instruction can be
generated from 1 DO or 1 Loading Instruction can
Generate Loading be generated from multiple DO provided all the
FR-LI-1 Instructions DO have same warehouse-godown.
The Loading instruction generated by Buyer User

FR-LI-2 Double Verification will be send to Buyer Admin for approval.
The system shall enable the

View TRD,DO, Loading TRD, DO and Loading Instruction available to
Instruction by buyers, the producer
FR-LI-3 Producer Warehouse warehouse for release of teas
be called by Buyer system to update Loading
Instruction.
Import loading
instructions from Another option of updating the information
FR-LI-4 buyer system through standard excel upload format
3. Once the Loading instruction is generated, Notification will be send to the Buyer admin
and Buyer user and producer warehouse.

4.4.8 Release of Tea – Producer Warehouse
Upon receiving loading instructions, TRD and Delivery Order producer

warehouse shall release tea as instructed by the buyer.
In cases, where Producer warehouse and Buyer Warehouse are the same entity
then the producer warehouse will do a Book transfer. In this case, no weighment
of Tea is done and the information from the loading instruction is passed from
Producer warehouse to buyer warehouse.
Release Certificate will be given to the buyer. This is the end of Tea Post Auction
Process.
1. Warrant description to be standardized.
Feature Requirements: Release of Tea – Producer Warehouse (FR-RTPW)

FR-RTPW-1
The system shall allow Producer Warehouse

admin to enter the loading instruction number
and allow for release. Upon allow, the loading
instruction information will be visible to Producer
Permission of Release Warehouse user.
FR-RTPW-2 Producer warehouse The system shall enable the producer
release teas warehouse to confirm, release and dispatch teas
against buyer loading instructions and TRD by
updating outgoing weight and Other details.
The system shall allow the producer warehouse
Track all incoming and to report and track all incoming and outgoing
FR-RTPW-3 outgoing teas Teas
System shall allow Book Transfer only if Produce
warehouse and Buyer warehouse are same. in
this the entire information of that Loading
instruction will be transferred from Producer
FR-RTPW-4 Book Transfer warehouse to buyer warehouse.
System shall allow Producer warehouse to
generate a release certificate to the Buyer
FR-RTPW-5 Release Certificate warehouse

1. Once the Release of Tea is done by the Producer Warehouse, Notification will be send to
the Buyer admin and Buyer user and producer admin and Producer warehouse.
5. Requirements and Content for Business Documents and

notifications
5.1 Business Transaction – Tea Dispatch
Form Business Transaction

Form Id BT-1.0- Tea-Dispatch
Identifier Barcode
Provides a list of teas sent to warehouse by the producer and requests the
Description warehouse to confirm receipt, where the warehouse is expected to weigh
the teas and confirm the weight and quantity delivered.
EATTA Rule(s) Pre-sale regulations 13 and 14
Pattern Send / Confirm
Business activities and
associated authorized Product-Dispatch
roles
1. All T-Paks must be marked
Constraints 2. The weight on The Factory Dispatch Note should not exceed The total net
weight.
Requesting Partner
Producer/Vendor
Type
Requesting Activity
Product Dispatch
Role
Requesting Activity
Factory Dispatch Note
Document
Responding Partner
Warehouse
Type
Responding Activity
Warehouse Tea Receipt
Role
Responding Activity Tea Arrival Advice
Document(s) Warehouse Tally Sheet

5.2 Business Transaction – Tea Weight Note
Form Business Transaction

Form Id BT-1.2 - Tea Weight Note
Identifier Barcode
This indicates the individual pallet tea weight, including
any excess/short weight. Tea Weight Note is the basis of
Description
the catalogued weight and does not exceed the weight
indicated on the packaging.
EATTA Rule(s) Pre-Sale Regulations 15,16
Pattern Notification
associated authorized
roles Pre-auction cataloguing
Constraints
Must be made available by a week before sale
Requesting Partner
Type Producer Warehouse
Requesting Activity
Tea Warranty
Role
Requesting Activity
Tea Weight Note
Document
Responding Partner
Broker
Type
Responding Activity
Product Catalogue
Role
Responding Activity
Pre-Auction Catalogue
Document(s)

5.3 Business Transaction – Pre-Auction Catalogue/Closed Catalogue
Form Id BT-1.3 - Pre-Auction Catalogue/Closed Catalogue

Identifier
Description Provides the accepted list of offered teas for sale. Teas
offered for sale are allocated auction sale number and lot
number. Pre-Auction catalogue or closed catalogue does
not have valuation.
EATTA Rule(s) Pre-sale regulations 18
associated authorized
Roles Product-Catalogue
Constraints
- Pre-Auction catalogue shall close on Thursday at
1700h East African Time
- Closed catalogue should be available to members
by Friday noon
Requesting Partner Type Broker
Requesting Activity Role Generate Pre-Auction Catalogue
Requesting Activity
Document Pre-Auction Catalogue
Responding Partner Type Members
Responding Activity Role Auction preparation, Buyer-Tea Tasting, Broker-add
Valuation
Responding Activity NONE

5.4 Business Transaction – Auction Catalogue/Evaluation Catalogue
Form Id BT-1.4 – Auction Catalogue

Identifier
Description This provides the catalogue to be used at the auction. It is
basically Auction catalogue with valuation.
EATTA Rule (s) Pre-Sale Regulations 27
Business activities and Present-Auction Catalogue
associated authorized Members
roles
Auction catalogue should be available to members
Constraints including
the secretariat the Friday prior to the auction, by 1200h
noon.

Requesting Activity Role Broker
Requesting Activity Invoice
Document
Responding Partner Members
Type
Responding Activity Role Buyer – Prepare for auction, enter internal valuations
Auction Admin- upload all broker sale catalogues
Document/Notification

5.5 Business Transaction – Sale Catalogue
Form Id BT-1.5 – Sale Catalogue

Identifier
Description This provides the sale catalogue with buyer indicated and
the value at which the tea lots were sold at the auction.
EATTA Rule (s) Post-Sale Regulations 43
Business activities and Present – Post-Sale Catalogue
associated authorized Broker
roles
Constraints The Post-Sale catalogue should be available to members
by 1000hrs the following day of the sale

Requesting Activity Sale Catalogue
Document
Responding Partner Members
Type
Responding Activity Role Buyer – Prepare to make payment


5.6 Business Transaction – Sale Invoice
Form Id BT-1.6 – Sale Invoice

Identifier Barcode
Description This is the brokers’s invoice to the buyer for teas whose
bids have been accepted by broker
Business activities and Present-Invoice
associated authorized Warehouse
roles
Constraints
The invoice shall reflect the sale and Tea Weight Note
details

Requesting Activity Invoice
Document
Responding Partner Buyer
Type
Responding Activity Role Payor – Make payment to Payee/Producer
Payee Bank- Receive Payment /Confirm Payment
Responding Activity
Document/Notification Payment confirmation

5.7 Business Transaction – Tea Release Document
Form Id BT-1.7 – Tea Release Document (TRD)

Identifier Barcode
Description This document is generated by the broker after payment
confirmation has been received. It authorizes the buyer
to make arrangements and collect tea, he/she has bought
and paid for, from the producer warehouses.
Business activities and Present-TRD
associated authorized Broker
roles
Constraints TRD is generated only after payment confirmation from
the bank

Requesting Activity
Document Tea Release Document
Responding Partner Buyer
Type
Responding Activity Role Buyer – Prepare Delivery Order
Responding Activity Delivery order

5.8 Business Transaction – Delivery Order
Form Id BT-1.8- Tea-Delivery Order

Identifier Barcode
Once TRD is generated, broker shall generate DO. The DO shall be Invoice
Description specific and made available to the buyer
EATTA Rule(s) Pre-sale regulations 50 and 52

associated authorized Present Broker-Delivery Order
roles
Constraints 1. All DOs will be invoice specific

Requesting Partner
Broker
Type
Requesting Activity
Broker
Role
Requesting Activity
Delivery Note
Document
Responding Partner
Buyer
Type
Responding Activity
Buyer – Prepare Loading Sheet
Role
Responding Activity
Document(s)

5.9 Business Transaction – Loading Instruction
Form Id BT-1.9- Tea-Loading Instruction

Identifier Barcode
Buyer will generate loading instructions and send to the producer
Description warehouses. Loading instructions shall be accompanied by a copy of TRD
and DO.
EATTA Rule(s)
associated authorized Present Buyer- Loading Instruction
roles
1 Loading instruction can be generated from 1 DO or 1 Loading Instruction
can be generated from multiple DO provided all the DO have same
Constraints
warehouse-godown.
Requesting Partner
Buyer
Type
Requesting Activity
Buyer – Receive Tea
Role
Requesting Activity
Loading Instruction
Document
Responding Partner
Producer Warehouse
Type
Responding Activity
Producer Warehouse – Prepare Release certificate
Role
Responding Activity
Document(s)

5.10 Business Transaction – Release Certificate
Form Id BT-2.0- Release Certificate

Identifier Barcode
Producer warehouse will release tea when they receive TRD, DO and
Description Loading Instruction.
Along with this they will send Release certificate
EATTA Rule(s)
associated authorized Present Warehouse- Release Certificate
roles
It will contain the warrant which will transfer from Producer Warehouse to
Constraints Buyer.
Requesting Partner
Producer Warehouse
Type
Requesting Activity
Producer Warehouse – Release Tea
Role
Requesting Activity
Document
Responding Partner
Buyer
Type
Responding Activity
Role
Responding Activity
Document(s)

6. Content Description
6.1 Content Description – Tea Dispatch
Form Id: BT-1.0- Tea-Dispatch

Element/Component Occurs Data Field Semantic Description
Name Type Width
Garden 0..1 Text TBD The factory or producer where
the tea has been produced and
packaged
Invoice 0..1 Number TBD Uniquely identifies the batch of
tea packed at the producer
Grade 0..1 Text TBD Grade type of Tea e.g. BP, PF1,
F1, PD, DUST1
Packages 0..1 Number TBD Number of bags per Invoice /
batch
Packaging Type 0..1 Text TBD Type of packaging e.g. bags
Net Weight 0..1 Number TBD Net Weight of the invoices/batch
Gross Weight 0..1 Number TBD Total weight of each invoice
including the tare weight
Packaging Date 0..1 Date TBD Date when the invoice/batch was
packed
Dispatch Date 0..1 Date TBD Date when the dispatch to
warehouse is made
Kgs Per Package 0..1 Number TBD Number of kgs per package e.g.
kgs per bag
Warehouse 0..1 Text TBD Destination – warehouse where
the tea will be delivered to on
dispatch which is usually a
producer warehouse.
Remarks 0..1 Text TBD Remarks contain any free form
text for the Dispatch Summary.

6.2 Content Description – Tea Weight Note
Form: Content Description

Form Id: BT-1.2- Tea Weight Note
Name Type Width
Warranty Number 0..1 Number TBD
Weight Note Date 0..1 Date TBD This is the date when the Tea
Weight Note is created
Garden 0..1 Text TBD The factory or producer where
the tea has been produced and
packaged
F1, PD, DUST1
batch
Gross Weight 0..1 Number TBD Total weight of each invoice
including the tare weight
Warehouse-godown 0..1 Text TBD Destination – warehouse-godown
where
the tea is delivered to on
dispatch which is usually a
producer warehouse and its
godown
Broker 0..1 Text TBD Broker company issued with the
Tea Weight Note

6.3 Content Description – Pre-Auction Catalogue/Closed Catalogue

Form Id: BT-1.3- Pre-Auction Catalogue/Closed Catalogue
Name Type Width
Sale Number 0..1 Number TBD Auction sale number uniquely
identifies an auction as defined
Sale Date 0..1 Date TBD This is the date when the auction
happens
Warehouse & godown where the
Warehouse-godown 0..1 Text TBD tea is
stored
Lot 0..1 Number TBD Uniquely identifies the lot at the
auction sale. Each tea invoice is
allocated a lot number for a given
auction.
F1, PD, DUST1
batch
kgs per bag
Comment 0..1 Text TBD Comment contains any free form
text for the lot in the catalogue.

6.4 Content Description – Auction Catalogue/Evaluation Catalogue

Form Id: BT-1.4 – Sale Catalogue
Name Type Width
happens
stored
auction.
F1, PD, DUST1
batch
Kgs PerPackage 0..1 Number TBD Number of kgs per package e.g.
kgs per bag
Value 0..1 Number TBD Value of the tea lot.

6.5 Content Description – Sale Catalogue

Form BT-1.5 – Post-Sale Catalogue
Id:
Name Type Width
happens
stored
auction.
F1, PD, DUST1
batch
kgs per bag
Value 0..1 Number TBD Value of the tea lot.
Sale Price 0..1 Number TBD Price at which the lot is sold
Buyer 0..1 Text TBD Buyer who won the bid or has
bought the tea
Sale Packages 0..1 Number TBD Number of packages bought.
Packages in a lot can be shared
among buyers

6.6 Content Description – Sale Invoice

Form BT-1.6 – Sale Invoice
Id:
Name Type Width
happens
Prompt Date 0..1 Date TBD Date when the buyer is supposed
to have made payment of tea
purchased and as per the sale
invoice
Invoice Date 0..1 Date TBD Date when the Sale Invoice is
created
Invoice Number 0..1 Number TBD The unique identifier of the Sale
Invoice
Uniquely identifies the lot at the
Lot 0..1 Number TBD auction.
Mark 0..1 Text TBD Represents the
factory/producer/garden where
the tea came from.
stored
F1, PD, DUST1
kgs per bag
bought the tea
Brokerage Fee 0..1 Number TBD Fee charge by the broker per lot
sale
Total Amount 0..1 Number TBD Total Amount contains the total

price for the entire invoice.
6.7 Content Description – Tea Release Document

Form BT-1.7 – Tea Release Document (TRD)
Id:
Name Type Width
TRD Number 0..1 Number TBD Uniquely identifies the TRD
TRD Date 0..1 Date TBD Date when the TRD is created
Invoice Number 0..1 Number TBD The unique identifier of the Sale
Invoice
happens
Warrant Number 0..1 Number TBD Represents the number of the
warranty document that
describes the details of the tea at
the warehouse
auction.
Mark 0..1 Text TBD Represents the
factory/producer/garden where
the tea came from.
Warehouse- Warehouse & godown where the
godown 0..1 Text TBD tea is
stored
F1, PD, DUST1
kgs per bag
bought the tea

BrokerageFee 0..1 Number TBD Fee charge by the broker per lot
sale
Total Amount 0..1 Number TBD Total Amount contains the total
price for the entire invoice.

7. Reporting Specifications
The system shall allow the Trade to log in and access relevant reports and statistics.
7.1 Report Description – Producer
Form: Report Description

Stakeholder: Producer
Report Report
Id: Name Objective Description Report Design Notes
ProdRPT- User to select start
01 List of Teas Enables tracking of teas Displays list of teas date, end date,
grouped by
dispatched on a given destination
dispatched period dispatched from the warehouse
to various warehouses factory on a
specified time
length
ProdRPT- Provides the producer
02 Tea stock at with the Displays list of teas
Warehouse stock balance of tea that have not been
dispatched to the
warehouse offered for sale
ProdRPT- List of Tea Enables tracking of teas User to select start
03 sold sold Displays list of teas date, end date
over a given period of
time sold on a specified
time length
ProdRPT- List of Enables tracking of teas
04 unpaid that Displays list of teas
have been bought but
Teas not paid that have been
bought by buyers
but have yet to be
paid for

7.2 Report Description – Broker

Stakeholder: Broker
Report
Report Id: Name Objective Description Report Design Notes
Enables tracking of Displays list of teas User to select start date,
BrokRPT-01 List of Tea teas that end date
allocated to broker have been allocated
Allocations over a to and All/factory
specified period time broker over a given
period
List of Tea Enables tracking of Displays list of teas User to select start date,
BrokRPT-02 sold teas sold end date
sold over a given
period of on a specified time
time length
List of Enables tracking of Displays list of teas
BrokRPT-03 unpaid teas that
that have been have been bought
Teas bought but by
buyers but have yet
not paid to
be paid for
List of Out Enables the broker to List of Teas that
BrokRPT-04 lots track have User to select Sale Number
out lots on a given been declared out
auction lots
on a given auction
sale

7.3 Report Description – Buyer

Stakeholder: Buyer
Report Report Design

Report Id: Name Objective Description Notes
Enables tracking of User to select start
BuyerRPT-01 List of Tea teas Displays list of teas date, end date
bought over a given
bought period of bought on a
time specified time length
List of Enables tracking of
BuyerRPT-02 unpaid teas that Displays list of teas
have been bought but
Teas not paid that have been
bought but have yet
to be paid for
Enables the buyer
BuyerRPT-03 Producer track teas Displays list of teas
warehouse that have been
List bought and that have been
paid for but not
of Tea collected at bought and paid for
available the producer
for warehouse but not collected at
collection the producer
warehouse

7.4 Report Description – Producer Warehouse

Stakeholder: Producer Warehouse
Report Id: Report Name Objective Description Report Design Notes

PdwseRPT- Enables the User to select start date,
01 List of received warehouse to Displays list of teas end date
track teas
Tea received from received from and All/factory
producers over a
given period producers over a
of time specified period of
time
PdwseRPT- Enables tracking User to select start date,
02 List of Tea of teas Displays list of teas end date
allocated to
Allocations broker over a that have been and All/factory
specified period
time allocated to broker
over a given period
PdwseRPT- Enables tracking
03 Warehouse of all teas in Displays list of teas in Grouped by factory
the producer
Stock warehouse the warehouse
PdwseRPT- Enables tracking User to select start date,
04 List of of teas Displays list of teas end date
dispatched over a
dispatched Tea given period that have been and All/destination
of time dispatched from the
producer warehouse

7.5 Report Description – Buyer Warehouse

Stakeholder: Buyer Warehouse
Report
ByrwseRPT- List of Enables the User to select start date,
01 received warehouse to Displays list of teas end
track teas received
Tea from received from date and All / producer
producer warehouse
over a producer warehouse warehouse
given period of time over a specified period
of time
ByrwseRPT- Enables tracking of all
02 Warehouse teas in Displays list of teas in Grouped by buyer
Stock the buyer warehouse the buyer warehouse
ByrwseRPT- Enables tracking of User to select start date,
03 List of teas Displays list of teas end
dispatched dispatched over a
Tea given period that have been date and All/destination
of time dispatched from the
producer warehouse

7.6 Report Description – EATTA

Stakeholder: EATTA
Report Id: Report Name Objective Description Report Design Notes

EATTARPT- Enables tracking of User to select start date,
01 List of Tea Sold teas sold in Displays list of teas end
the auction over a
specified that have been sold date
period time through the auction
over a given period
EATTARPT- Provides input to User to select start date,
02 List of statistics on Displays list of teas end
tea produced
dispatched tea countrywide that have been date
dispatched to
warehouses over a
given period of time
EATTARPT- Provides input to User to select start date,
03 List of shipped statistics on Displays list of teas end
tea exported tea that have been date and All/destination
shipped to various
destinations over a
given period of time

7.7 Report Description – BANK

Stakeholder: BANK
Report
Enables the bank to Displays list of User to select Sale
BankRPT-01 List of sale track invoices number
invoice details for and their details
invoices payment based
transfer purposes on a auction sale
8. Other Non-functional Requirements

8.1 General Requirements
ID Requirements
NFR-G-001 The System will allow the user to review and update information if
there are correctable errors
NFR-G-002 The System will contain a "help" function on each screen as
needed to provide users with instructions on how to perform
functions, descriptions of data elements and/or other
information
NFR-G-003 The System may provide access to "rules/regulations
documentation" via the System for look up and reference in
the relevant context of the screen/process.
NFR-G-004 The System will maintain a record (e.g. audit trail) of all changes
made to data in the System - system initiated changes or user
initiated changes. This should be readily searchable by user ID,
system ID or beneficiary ID. This must include but is not limited to:
i. The user ID of the person who made the change or system ID if
the change was system generated
ii. The date and time of the change
iii. The information that was changed
iv. The data before and after it was changed
v. The data source if the change was system generated

8.2 Interoperability
ID Requirements
NFR-I-001 iTTS will provide support for integrating with applications with
SOA and event-driven architectures in a manner that supports
the following implementation strategies: ' Web Services: Web
Services Interoperability (WS-I) Organization-compliant
implementation of basic Web services standards, including
SOAP, WSDL and Universal Description, Discovery and
Integration (UDDI), as well as higher-level Web services
standards, such as WS-Security. ‘Representational State
Transfer (REST): Support for XML-based messages, processing
and HTTP, and XHTML.
NFR-I-002 The iTTS System will seamlessly work with the technology and
programs that act as glue, transforming among protocols,
connecting to databases and linking pre-SOA Application
Programming Interfaces (APIs) to the SOA backplane.
NFR-I-003 The iTTS System will have the capability to work with security
policy manager for Web services that allows for centrally
defined security policies that govern Web services operations
(such as access policy, logging policy, and load balancing)

8.3 Security
ID Requirements
NFR-S-001 The iTTS System will allow for controlled access to beneficiary
records. Users will be able to view beneficiary data within the
System at the State-defined levels of access based on user
security privileges.
NFR-S-002 The System will maintain a level of security that is
commensurate with the risk and magnitude of the harm that
could result from the loss, misuse, disclosure, or modification
of information.
The system will provide for the highest level of digital

encryptions and/or e-signature capabilities
NFR-S-003 The System will provide protection to maintain the integrity of
data during concurrent access.
NFR-S-004 The System will enforce a limit of (configurable) consecutive
invalid access attempts by a user. The System will protect
against further, possibly malicious, user authentication
attempts using an appropriate mechanism (e.g. locks the
account/node until released by an administrator, locks the
account/node for a configurable time period, or delays the next
login prompt according to a configurable delay algorithm).
NFR-S-005 The System will provide the capability to prevent database
administrators from seeing the data in databases they
maintain.
NFR-S-006 The System will provide the ability to create and maintain a
directory of external providers to facilitate communication and
information exchange.
NFR-S-007 The System will provide more-advanced session management
abilities such as prevention of duplicate logins, remote logout
and location-specific session timeouts.
NFR-S-008 The System will provide the capability to monitor events on the
information system, detect attacks, and provide identification of
unauthorized use of the system

8.4 Usability
ID Requirements
NFR-U-001 The System will speak the users' language, with words, phrases
and concepts familiar to the user, rather than system-oriented
terms.
NFR-U-002 The System's User Interface will be simple, consistent, and use
familiar terminology.
NFR-U-003 The System's navigation will be familiar and consistent, and all
user actions will be predictable and reversible.
NFR-U-004 The users will be able to easily navigate to a variety of
functions available to them without having to move
sequentially through excessive menus and screens.
NFR-U-005 The System will follow standardized conventions. Users should
not have to wonder whether different words, situations, or
actions mean the same thing.
8.5 Performance
ID Requirements
NFR-P-001 The system shall accommodate 400 users during the Auction
sessions, with estimated average session duration of 50
minutes.
Responses to queries shall take no longer than 5 seconds to
load onto the screen after the user submits the query.
The system shall display confirmation messages to users
within 4 seconds after the user submits information to the
system.
NFR-P-002
iTTS should scale correctly and load balance to support high
traffic loads

8.6 Standards Compliance
ID Requirements
NFR-SC-001 The system shall support latest open messaging standards. The standard
should have been published and the current standard specification
document available either freely or at a nominal charge at the time of
implementation. There should be no constraints on the re-use of the
standard.
Standards may Include but limited to, ISO/ UN/CEFACT-ebXML , GS1

XML and Universal Financial Industry Schema – UNIFI/SWIFT (ISO 20022)
ISO 9362 Business Identifier Code BIC, to identify parties, and the ISO
10383 Market Identifier Code (MIC), The standards should support
messaging Guidelines, stylesheets, archiving and sample
client/document formats.
At a minimum should have core message components for e-mandates,

e-auction/e-ordering, e-invoicing, e-catalogue, e-notification.

9. Appendix A: Glossary
iTTS Integrated Tea Trade System
SRS Software Requirements Specification
ERD Entity Relationship Diagram
EATTA East Africa Tea Trade Association
B2B (Business-to-Business), also known as e-biz, is the
exchange of products, services or information (e-
commerce) between businesses, rather than between
businesses and consumers
HTTP HyperText Transfer Protocol. HTTP is the underlying
protocol used by the World Wide Web and this protocol
defines how messages are formatted and transmitted,
and what actions Web servers and browsers should take
in response to various commands.
Members East Africa Tea Trade Association members
ISO International Organization for Standardization
UN/CEFACT United Nations Centre for Trade Facilitation and
Electronic Business
ebXML E-Business Extensible Markup Language
ISO/IEC/IEEE 29148:2011 A standard which contains provisions for the processes

and products related to the engineering of requirements
for systems and software products and services
throughout the life cycle
SAP SAP is an acronym for Systems, Applications and Products
ERP Enterprise Resource Planning
AA Auction Admin
TRD Tea Release Document
Rainforest Alliance The Rainforest Alliance is a non-governmental
organization working to conserve biodiversity and ensure
sustainable livelihoods by transforming land-use
practices, business practices and consumer behavior

10. Appendix A: Analysis Models

10.1 Use Case Diagrams
10.1.1 Membership Module

10.1.2 Catalogue Module

10.1.3 Auction Module

10.1.4 Business Module

10.2 Data Flow Diagrams
10.2.1 Pre-Auction
10.2.2 Auction

10.2.3 Post-Auction

11. Change Requests (UAT)

11.1 Membership Module
1. Proposer and seconder for document upload -
There is need to re-look at the requirements of the Board Members; should have a proposer and
seconder where a standard document for the proposer and seconder can be provided through a
documentation upload into the system.
Development Team: optional documents for upload can be given called “Letter of Endorsement -
Proposer” & “Letter of Endorsement – Seconded”.
11.2 Catalogue Module

1. Allocate the teas to broker - The system should allow the producers allocate the teas to the broker
when they are on transit. The below screens show how allocate the teas to the broker changes
2. Broker to assign themselves -
1. The system should allow the broker to assign themselves teas on behalf of the producer. Some
members also recommended that Warehouse to allocate teas on behalf of the producer.
PIT (31st Oct): The committee noted that there is no deviation to the current system as the producer
assigns teas to the broker. The committee recommended that the producers who would want to do
the allocations themselves be allowed to do so. For those producers who are not in a position to do
so, the broker will do the allocations on their behalf. The broker will only allocate teas to themselves
for a producer in which they have a contract.
PIT (15th Nov): The proposal was agreed upon by the members in the forum
3. Allocate two brokers -
The system should allow the producers allocate two brokers for the same teas and same mark but
having different invoice numbers
4. Allow for editing to avoid rigidity -
1. The system should allow for editing to avoid rigidity especially in scenarios where the teas arrive
underweight.
Development Team: System shall allow Warehouseman to update the actual received weight which
will go for Auction from a particular dispatch.
PIT(31st Oct): This was agreed upon by the committee.
5. Producer swaps teas - The system should consider scenarios whereby the producer swaps teas i.e.
swapping invoice B with invoice A.
Project Team: This needs to be decided in PIT meeting. Currently as agreed, Producers will give
invoice information of those teas which are bound for auction and warehousemen to update the
quantity against those invoices.
PIT (31st Oct): It was noted that sometimes errors occurs or /teas are swapped due to factors such as
teas having stains. The committee recommended that any swapping of teas be done before the

auction catalogue is published. Any editing of information where more than one party is involved, a
notification should be sent in such a case.
6. Capturing the warrant number -
1. The system to allow capturing the warrant number in the catalogue. The warrant number will be
used to address cases where the broker publishes the auction catalogue without the teas having been
received in the warehouse. The period in which the teas in the catalogue should be removed from the
system if the warrant number is not indicated will be agreed upon and documented as a rule.
Development Team: PIT to confirm us whether warrant number to be updated by warehousemen

when they receive Tea or when will this warrant number come into picture?
PIT (31st Oct): The committee was informed that this was raised by buyers to prevent teas which are
not in the auction from being sold during auction days. It was pointed out that there is a current rule
that outlines when the tea should be in the warehouse before sale.
The committee noted that there is need for clear cut off with which teas whose warrant numbers
have not be updated on the system should automatically be removed from the catalogue. The
committee recommended that the status quo remains and to wait for the system to be fully
implemented after which the members will decide on the cut off period.
PIT (15th Nov): The members recommended that the system sticks to the current rule when it comes
to inputting the warrant numbers. Teas that have not been updated as per the current rule should
not appear in the system during sale. This warrant number should be updated when tea is received in
the warehouse.
7. Tea arrival status -
1. Need for a requirement to know the tea arrival status. Goods conditions should be clearly indicated
and also goods status whether arrived/transit should be shown to Brokers/Buyers
8. Tasting comments
Tasting comments space to be a text box.
9. Weight note generation -
Weight note should be (is) generated much later at the warehouse
Development Team: PIT to confirm to us where to use Warrant number and Weight Note.
PIT (31st Oct): The committee recommended that the warehouse weight note is what should be
considered by the system as it contains the accurate weight of the teas
10. Only map to Warehouse
Only map to Warehouse and not the Go-down
11. Roles between Brokers
There should be division of roles between Brokers, Warehouse, and Producers to feed their
information.
Development Team: In the current system, role of Producer is “Dispatch Tea & Allocate Tea” role of
Warehouse is “Receive Tea”

Role of Broker is “View Allocated Teas and Create Closing Catalogue and Evaluation Catalogue”
12. System Generated Dispatch Number
Dispatch number should be a system generated
Development Team: As agreed with Producers, the dispatch Format will no more have dispatch
number.
13. Gross Weight on Tea Allocation
There should be Warehouse confirmation update, Gross Weight on Tea Allocation.
Development Team: Noted, the weight which will be shown in Auction is the received weight
submitted by warehouse.
14. Invoice Date removal - Invoice Date is not needed and should be removed from the template.
15. Destination of teas mapped to the warehouse
Destination of teas should only be mapped to the warehouse and not the Godown, Warehouse will
confirm the Warehouse-Godown
16. Total tare weight

Total tare weight should be updated by Warehouse
17. Net weight /Package
Net weight /Package to be updated by Warehouse.
18. Catalogue preparation by the Broker

Transits teas should be allowed to be published during catalogue preparation by the Broker
Development Team: DONE. It will be allowed in publishing closing catalogue but not in auction
catalogue
PIT(31st Oct): The system will allow for publishing of closing catalogue while teas are not in the
warehouse but not in auction catalogue. There needs to be clear deadlines
PIT(15th Nov): The members agreed that the system sticks to the current rule
19. Mapping of warehouse
Mapping of warehouse; Warehouse being able to decide and choose where to take the teas. Allow
producers to only assign teas to warehouse and not go-down
20. Disclaimer to be removed Warehouse wants the disclaimer to be removed.
21. Issues of re-prints of Teas
Issues of re-prints of teas/options at the warehouse level needs to be checked on and how the ITTS
will handle them.
Development Team: Those Teas which are OUTLOTS from auctions will be shown to producers to
allocate to brokers.
PIT (31st Oct): The committee recommended the below;

a) Decision on how the out lots will work be discussed in the upcoming members forum b) Out lots
should be open to all bidders and let the highest bidder win c) Have a widow in which out lots are
sold.
er and
after the
ise after
window closes. The overall recommendation was to keep the market for outlots open up to Friday at
11.00am.The window will however close each day at 5.00pm to allow the broker take the bids.
11.3 eAuction Module

1. Buyers notified Have the buyers notified once the broker changes the valuation price.
Development Team: As agreed, PRESET pricing by Buyers will not come into effect whenever
there is a change in the valuation price in the auction catalogue.
PIT(31st Oct): This was agreed upon by the committee
2. Text box on the bidding
1. Have a text box on the bidding interface where the Buyer can key prices other than only
having pre-defined ranges.
3. Allow withdrawal of lots
1. The system to allow withdrawal of lots as is the case in the current manual system.
Development Team: PIT and TMEA to take a call. eAuction guideline to suggest. PIT (31st Oct):
The committee recommended the need for a clear defined process for withdrawing lots. It was
recommended the need to have timestamp in which one can withdraw a lot. There should be
however clearly defined measurers on number of lots one can withdraw for each particular sale.
withdrawn lots should appear at the bottom after the last lot
PIT(15th Nov):
r each catalogue was
set to 3.
4. Split Lots The members were presented with the proposed working of the split lots (attached).
for the secondary. It was noted that 40 packages perform better than the larger packages. This is
o
away with splitting of lots. This might however result to the producer losing few cents for larger
packages. The overall recommendation of the members is to have both functionality i.e. splitting
of lots and no splitting of lots and review the matter after rollout.

5. Auto-bid In cases of preset prices, the present price should not work if the prices drop. A section
of the buyers also felt that the auto-bid should be done away with.
Development Team: PIT and TMEA to take a call on this.
PIT (31st Oct): The committee advised Avinash (CSM) to do a paper with all the possible scenarios
of how the preset feature could work and present it to the committee.
PIT (15th Nov): There was concern that the auto bid will not capture the current dynamism of the
market.
Since the buyer cannot input a price below the valuation of the broker, this will pose a challenge
as the valuation of the broker is always on the higher side and most teas do not sell at the base
price.
It was also clarified that the auto bid will work on first come first serve basis and any bid will be
nullified if the broker changes the valuation price. During the bidding process, the broker can
filter through lots and change the valuation price for the upcoming lots.
The outcome of the forum was that the auto bid will be tested during validating and the
members will decide whether to switch on or off.
6. Buyer Live Auction – in the “Previous Lot Winner” section, the whole list of winners are showing.
Color-code the lots so that Buyer is able to identify which lots they have won
7. Broker Live Auction – When Buyer is withdrawing the Lots, message is displayed to the Broker,
the color of the Message should be in RED / Orange rather than in Green as it is a withdrawn
message.
8. Once a buyer withdraws from a Lot, the Lot is coming for ReAuction, at the end of the auction.
Restrict the withdrawing Buyer from participating in that Lot’s ReAuction.
9. Buyer Live Auction – create a new tab “My Winning Lots” to show only those lots to the Buyer
which he has won
10. Offer Price - If highest offer price is given by buyers then don’t allow lower offer prices to be
given by Buyers for that Lot. Example – if the Lot 1101 carries a base price of 2 $, if Buyer X offers
1.8$ then don’t allow any other Buyer to offer lesser than 1.8 $. Buyer Y can offer 1.9 $.
Subsequently, if Broker reduces the price to 1.9 $, then automatically Buyer Y will lead the
auction at 1.9$.
11. When buyer's bid is more than $10 put an alert "Are you Sure to bid X $" if yes then allow to bid
else don’t allow. Once Current Price is beyond 10$, “Warn user - Y/N” option should show to
buyers. Buyers will use this option to see warning or not while bidding more than 10 $.
12. When broker reduce the price of upcoming lots then broadcast notification should go to all
buyers. This notification time should be 10s. The Notification should show below Bidding Section.
13. Upcoming lot number should be displayed above Lot information for both Buyer and Broker.
14. Option to switch on / off Buyers segregation based on Grade, Broker.
15. Option for Auction admin to restart auction of a specific broker and a specific Lot in cases of
breakdown.

16. Broker Live Auction - Option for Broker to reduce price other than what is listed (ENTRY FIELD),
Option for Broker to increase price.
17. buyer widthdraw of a lot should notify to all buyers
18. Split lot

Split Lot Booking period will be double of Non Split Lots.
if Buyer 1 has taken 40/ 20 Lots then show other buyers interest for remaining Packs.
Buyer 1 to decide whether to split or take entire lot.
widthdraw cases notify to the specific buyer those who have bid in same price.
Option to give to the other buyer, whether he wants reauction / take full packages.
19. Rather than showing Total Qty, Total Amt Spend, Avg price per Grade,Total Qty per Grade,Total
Price,Total Qty show in buyer live auction
20. In buyer catalogue create an option to create a new field called as group (1 lot = multiple group)
. Example - Group can be Pak, UAE, SUDAN etc
21. Highest offer price by buyers should display where broker will choose to accept that offer and
that buyer will lead the auction at the offered price.
22. OUTLOT
Give an option to broker in the outlot where broker can increase the base price / Reduce the
base price.
Producer Can widthdraw lots from outlots for Private Sale.
option to broker to accept or reject the offered price by buyer(Highest), if Accept then that buyer
will win that Lot and if reject then that lot will still be in outlot.
Notification to buyer when other buyer bids more than his price in outlot.
23. Option to Buyer withdraw should be extended to Auction wise, currently system has settings
Catalogue wise.
24. In both Broker and Buyer, Lot information will be changed to following details
a. Lot Number
b. Grade
c. Packages
d. Mark
e. Previous Sale Graph (Based on Grade n mark)
f. Current Sale Graph (Based on Grade n mark)
25. All Entry textboxes in Buyer and Broker Live Auction screen will be entered in US CENTS format.
System will auto calculate to dollar format and update the backend system.
26. Rename "Current Price" to "Current Bid". Rename "Current Offer" to "Other Bids"
27. Buyer Upcoming Lots - Show Buyer Comments , evaluation Price & Preset Price
28. Broker Upcoming Lots to show in Broker Live Auction.

Upcoming Lots should show Broker Tasting remarks, Comments and evaluation Price.
29. Buyer who has lead the preset will see an Option to switch off Preset for that Lot.
and enter bidding in manual mode

30. Outlot winner will be first come first basis. Option to be built whether it is "First come First" or
"Bid wise Winner".
11.4 Business Module

1. Buyer Payment reference – Currently the Payment reference number created is sequential which can be a
security issue. Hence it is advised that it should be a dynamic alphanumeric number generated (ALL
CAPS). EX: HGDU8W9, JSH4UY9
2. TRD Generate – Give an option to choose multiple Lots whose statuses are paid to generate TRD.
Currently use is manually clicking all the LOTS.
3. DO Generate – Currently Broker has to click “Generate DO” button against each TRD separately. System
should allow user to choose all the TRD, give the Security and DO number and at the end should click
“Generate DO” button only once. System should self-generate all the DO based on the selections.
4. Sale invoice to use the new format with withholding tax.
5. Notification to send to both buyers and brokers whenever the payment is success for an invoice.
6. Once buyer is creating Bank Payment Reference Number, he can still update the lots for that reference
number unless and until he has made payments to bank and it is updated as successfully paid by bank.
7. Rather than creating Sale invoice in iTTS, option to be built to upload Sale Invoice Numbers and Lot
information which will automatically create sale invoice in iTTS.
12. Change Requests (Piloting & Training)

12.1 Membership Module
1. Option to users to enter multiple email IDs.
2. Admin of a Stakeholder should see Login Information of his and his users
3. Payment by Offline mode - Add a dropdown for Payment Mode and a text field for Payment Reference
Number.
4. Rename the Status "Application Forwarded" to "Forwarded for Board Approval".
5. For new member application process, use complete(Tick) / Incomplete(Cross) instead of 100. And have
the next button at the top as well
6. Business Code for 2 companies can be same across User Type - Buyers, Producer, Warehouse, Broker,
Packers
7. Change PIN CODE to Postal Code
8. Upload Documents should be country specific
9. Create a username column in Login. For all users allow them to change username in the Change Profile
page. Username must be unique for entire application. During login, user will enter username and
password.
10. Business Information section, Bank name to be non-mandatory

11. Rename Effective Date & Expiry Date to "Contract Start Date" , "Contract End Date" in Broker and
Warehouse Mapping
12. Don’t allow admin to create user with same mobile and same email. If the said new users are not logging
into application for X days block them.
13. Mail OTP based login whenever System detects the IP is not in the last 3 different allowable Ips
14. Allow maximum of 10 users to be created by ADMIN. Also each user must have unique email and Mobile
number, don’t allow duplicate. Keep a setting screen for Admin to set how many from a company can
users be created
15. Create a new roles called Associate (Gov) n Associate (Oth). Give separate access to both types of
Associates
12.2 Catalogue Module

1. One Producer user will be created and added to multiple Marks.
2. In the Producer dispatch details, delete option should be there. user can delete as long as the invoice is
not in Closing catalogue.
3. In the warehouse receive, add Goods condition as "Shortage".
4. In the dispatch list, show the dispatch reference number.
5. Weight Note field in the Warehouse upload to be renamed to Weight Note Number
6. Close date/time of the catalog changes by the broker need to be implemented only in production server
as per Rulebook
7. Warehouse code to rename to warehouse location
8. Dispatch Details view screen - Show Auction Nos, Auction Date and Broker Name. Rename Dispatch to
Allocation
9. In the dispatch & Receive & Broker allocation, Invoice number could repeat . Hence Map these Invoices
with Year to make them unique
10. In Broker Catalogue, Lot number can be duplicate, Implement SaleNo - Lot to make it unique
11. Closing , Auction and Sale catalogue must contain all the fields as in existing Catalogue, put all fields first
and then all rest fields
Include Auction No, date, warehouse, warehouse code, and entry number in the catalogue
12. Invoice Number must accept a. Example : 1392/18.19/19 when typing
13. Odd package numbers - how the systems will deal

Producers will always send in packages 20,40,60,80,100.
Warehouseman will update packages received (it could be odd ones like 73). Reason also to be given by
warehouse (free text)
Brokers - during Closing & Auction Catalogue will say how this odd package will act as 20/40/60/80/100.
During Auction, system will act as mentioned by Broker.

eAuction guideline to suggest how the actual packages will be split - last buyer will take the odds
14. Broker Screen: Catalogue ModuIe Lot Creation

Show: Grade, Pkg, Pkg Type, Net Wt
15. The Entry Number: optional keyed at producer(Non Kenyans), warn warehouse men if not keyed in when
receiving tea of NON KENYANs, aIso warn when broker is publishing cIosing and auction catalogue when
containing NON Kenyan Tea
16. Pallet Height: Regular/Irregular, Done at warehouse receiving from producer
17. Buyer catalogue upload screen - User should be able to download Auction catalogue and give additional
options like Remarks, Taster comments, Preset Price , Fav and upload it
12.3 Auction Module

1. UX Change in Producer Auctions screens, Admin Auction Screens all screens
2. No user should be able to use multiple logins to an auction system. System should block the user.
In case, accidently logged out, system should allow user to login in another machine only if no activity
found in the first Machine
3. When a Buyer has added Favourite lots, how does it come in Buyers Tab - Fav Lots as well as how it is
highlighted when he is bidding
4. in the manual Split, when there is a POP UP , don’t close the POP UP if more requests are there, if No
more Lots can be split
5. Producer Live Auction, The message to Broker to Sell, Hold, Withdraw should be for Outlots and not for
Auction Lots
6. withdrawn Lots coming back to the Live-Auction, should indicate withdrawn by who-Buyers Name
7. Show Summary in Buyer Live Auction - Statistic page
8. Options to Brokers to change price of Outlots as auction continues.

Buyers should be able to give lower bids as Offer for Outlots. Only for Lower Bids, broker will have option
to accept/ reject the offer price.System should show the highest offer price among buyers always. If some
buyer has bid more than or equal to the Price set by broker then System will make that buyer the winner
of that lot
9. Buyer catalogue, any change in Preset price / tea remarks / comments must immediately reflect auctions
page for Buyers.
10. Live Auction Window: Current Lot details to include Invoice Number, Certification,Net Weight.
Show Buyer Broker Name on the TOP
11. Preset Logic: Buyers can preset less than base price. When that lot comes for auction if the highest preset
price is less than base price then it will come as offer price to broker. Once broker accepts buyer wiII Iead
the auction.Preset On Price doesn't affect when broker is reducing or increasing price
12. Buyer Withdraw:

Non SpIit Cases - Buyer X Bids 2.2$ BuyerY bids 2.42$ after winning, If buyer Y withdraws then Buyer X to
win the Iot at 2.2$, Notification to Buyer X that he has won the Iot as Buyer Y has withdrawn
SpIit Cases - Buyer X won 80, Buyer Y won 20, if Buyer Y withdraws, give buyer X 100.Notification to Buyer
X that he has won the Iot as Buyer Y has withdrawn
Buyer X won 80, Buyer Y won 20, if Buyer X withdraws then reauction
13. New Button for buyer to show refusal of accepting split lots - NO SPLIT BUTTON, on Click, under Current
Price, it should show that Not Interested for Split
14. In Buyer live auction, add a button call to BID UP, On click it should bid 2 cents higher than current price.
Also in the entry text for Bidding, allow values > 2 cents of the current price
15. In the upcoming lots for Broker, remove broker name. Add new tabs , OUTLOTS & PAST LOTS. Delete lots
prompt "Do you want to Withdraw".
In the auction, upcoming lots, give option to broker to change price.
In the buyer upcoming Lots, show additional data along with Auto preset price data also show and allow
to edit
16. The name of the Company Code(Buyer/Broker) to show/display live auction, Broker Company Code to
display in Live auction
17. Buyers Upcoming Screen as well as Lot description should contain Invoice, Certification & Nett Qty, Preset
Value, Remarks, Tasting Comments. Remove producer name
18. When a broker changes the Base Price, reset the auction to allow other buyers to bid
19. In the Buyer Group Report, add QTY, Price. Pick from Live Auction. The report link to be given to Buyer
User
20. Auction admin can change Broker Sequence in middle of auction and it should work
21. Rename the Tab, Broker Reduce Price to Broker Change Price. Also the column name should be changed
22. In the Withdraw option for Buyer, Rename "Withdraw Tea" to "Withdraw Lot".
23. During Auction, Broker should be able to see all outlots, also should be able to see messages by Producer
for the outlots.
Broker should be able to Adjust price for the outlots during his ongoing sale also on a separate screen.
Once broker clicks on Publish, only then the system will show the outlots to the buyer else wont show
24. in the broker screen, put the Increase section on top and reduce section on bottom
25. In Broker Live Auction, when user clicks on PAUSE, Show alert but on clicking do not show message
paused successfully. Also do not clear Current Price by the buyers.
12.4 Business Module

1. When bank is updating settlement / payment status, they should update the bank reference codes as well
2. Private sale naming to Producer Withdrawals. This option which is currently given to Producer should also
be there for Broker, This should be a setting in Manage Auction. Whether Broker can withdraw outlots

3. Options to Brokers to Withdraw of Tea which have already been paid by Buyers. The screen should
include Reason of Withdraw , Credit Note / Debit Note number. These Numbers should be keyed in and
Document to be uploaded
4. Out-lots that come to the auction for the second time the weights have to be updated due to the
withdrawal.
Fields for Brokers to update Original Wt , Current Wt, Original Packs, Current Packs
Ex: Original Wt: 6000 Current Wt: 5992, Original Packs: 60 Current Packs: 57
During auction it will act as 60 , if Buyer X takes 40 and Buyer Y takes 20 then after that lot it should show
like this
Buyer X - 40 packs, 4000 wt ( 6000/60 * 40 = 4000)
Buyer Y - 17 packs, 1992 wt (the odd wt 5992 - 4000 = 1992)
5. Payment Ref. Number: must contain SaIe invoice number and producer inv. Number
6. Generation of Barcode on DO's, TRD's and LI's

Security Number, DO's, TRD's and LI's: Self Generated
Common Security number Across TRD, DO and LI
Loading Instructions Report:
Add Driver & Truck Info
add: producer Invoice and Sale Invoice
7. In the Tea Release, Warehouseman can release partial teas based on the Packs released, add new column
called Release Date. Generate TRC certificate only after he has taken all lots.
8. All Approvals will be 2 process - Verifier and Approver. These will not be admin but users of the system.
Mail OTP based authentication for Verifier and Approver.
Give option to view all pending for verification or approval in a list. Option to choose multiple and
approve/verify. Also Reason field on why it is being rejected to be stored
9. Payment reference printable in pdf with the receiving bank details. It should clearly define all breakdown,
SP, Nett Qty, Amount, Withholding , Commission, Late Fees, an account number of the bank they intend
to make payment, bank name as well.
Late fees should be calculated to only 60 days. Late fee calculation is Compound based not Simple
interest.
10. Daily email on Total cases pending for approval/ settlement should be sent to Bank Approvee authority.
"Payment Reference","Pending Since".
11. API logs to be maintained for all calls, screen for EATTA to view only cancelled / declined / failed
transactions . Filter option to be there in the screen
12. Bank payment reference number and settlement reference number to include the following and should
be less than 16 characters:
1. XX - Year
2. YY - Salenumber
3. ZZZZ - Bank Business Code
4. 9 characters random generated alpha numeric data
13. Screen for EATTA to determine the base rate for calculating of penalties for Banks like the bank Prevailing
Rate. It should contain Effective and exoiry date.
14. In the Loading Instruction, do not allow users to choose Teas which are in different Warehouse.
Also 1 Loading Instruction can have multiple Truck information

15. If TRC is not generated, then Buyer can edit loading instruction data on the transporter details only.
16. Excel uploads must be revised to ensure all fields are captured.
post auction excel uploads must contain Sale number
12.5 MIS
1. In All Reports, Add Country . Also show by Producers, By Brokers, By Buyer, By Warehouse , By Auction.
From Date - To Date in all reports. YTD, MTD also
2. IN the ADHOC Report, allow user to choose multiple Marks rather than one to compare.Add option to
filter by Grade also
3. Withdraw Report - By Broker, By Buyer, By Auction.. Rename "Destined Tea Report" to "Tea in Transit
Report"
4. A new Screen called GLOSSARY to be added.
5. New Report - Country wise Average price over auction Grade wise, Mark wise Avg Price
6. New Report - Upcoming Auction - Grade wise Qty.
7. New Report - Warehouse wise Average Volume over auction Grade Wise
8. Dynamic Reports - which can capture any set of Data for a given user.
Auto filteration option to choose any marks , producer and compare with Market Trend / Competitor.
Also include EBB Reports
9. Buyer Catalogue Group Report - Synced with Live Auction, and should Capture: Packages, Lots, Net
Weight and Summary.
10. "Private Sale" changes to "Producer Withdrawn Lot".
11. Add: Auction No and Date, Warehouse Code on the Catalogues - Closing , Auction , Sale
Remove tasters comment
12. In the dashboard show analytics reports for Producers, Brokers
13. in the paid unpaid report, add late payment details
14. Tea Over View Report - restrict to per buyer reports, especially sections on payments
15. Buyer to see Winning Lots Summary/Totals of Packages/Net Weight/ Amount Spent and Broker
Commission Drill down report Catalogue-wise during an auction change-over.
16. Post Sales Report:

In catalogue add the columns = manufacturing date, certifications number, check with current post sale
catalogue
filter by marks to be available

17. New Report - Allocation , Catalogued, Sold, Outlot, Withdrawn, Reauctioned
18. Reports - Late payment report
19. Report - Bank reconsillation report
20. Screen for Banks to download / View all Payment References generated for their banks only,
Search based on Auction Date, Auction No & Buyer
12.6 Common
1. A Help screen where all modules and sub modules links will be given to Youtube
2. Use tooltip feature on specific area to give more information or explanation
3. In the home page, Auction statistics to show Average Price, Total Volumes Sold, Total Volume Outlot -
Country wise
4. All pages to have search options to filter out records. Also "select all" checkbox options to be there
5. IN the Home page, change the Login options to just one as it is all redirected to same page
6. Use of icons should be self-explanatory, distinct, and consistent - especially for the main menus
7. 200 records upload limit to be increased for Production environment. Add in Configuration
8. Approval of Admin processes by a second approver is required. This can be made a uniform across.
9. In the business, Auction module for all approvals it should not be only admin, it can be any user assigned
by admin

Itts SRS

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Itts SRS

Uploaded by

Copyright:

Available Formats

iTTS – Software Requirements Specification

Software Requirement Specification (SRS)

Level - 6, OCAC Tower, Acharya Vihar,

+91 (0)674 6635 900 | info@csmpl.com | www.csmpl.com

CONTRACT FOR: 35_KE – System Development, Deployment and

CONTRACT REFERENCE: PO/20170711

WORK/ ACTION POSITION NAME SIGNATURE

ESS Africa Ltd , CEO Pannaga Patnayak

Reviewed By EATTA - Senior Trade and John Sudi

Recommended By TMEA – Program Manager Erick Sirali

EATTA – Managing Director

2|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

Version Description Author Date

3|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

4|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

4.2.3 Tea Allocations ..................................................................................................................................29

5|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

6.6 Content Description – Sale Invoice ..................................................................................................71

6|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

12.6 Common ................................................................................................................................................104

7|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

1.2.1 In-Scope Functionality

Based on the requirements gathered, the following functionalities are considered to be

1. Membership management function to enable and control member registration,

2. Tea dispatch and receipt functions to enable confirmation of teas dispatched

3. Tea Weight Note function to enable generation of Tea Weigh Note by

4. Tracking and reconciliation of tea inventory movement. This functionality would

6. Catalogue preparation and management function to enable and control the

8|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

Catalogue, auction catalogue/Evaluation Catalogue and post auction catalogue/Sale

7. E-Auction function to enable

a) electronic auction of teas by brokers,

b) electronic bidding of teas by buyers,

e) Acceptance of the highest bid by system.

8. Auction organizer/Admin function to enable

b) enable consolidation and publication of all catalogs for auction within

9. Auction Results functionality to enable electronic access to auction results by

10. Invoice functionality to enable tracking of invoices generated by brokers after

9|P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

1.2.2 Out of scope functionalities

2. A functionality to generate export documentation i.e.; KRA, KPA & KEPHIS

1.3 Intended audience

- Business Requirements Document

2.1 Product perspective

10 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

Table 1 Product Overview

11 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

2.2 Product functions

12 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

13 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

2.3 User classes and characteristics

The following are the kinds of users of the iTTS system.

Warehouse Admin – will administer the warehouse use of the system as

14 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

15 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.

2.4 Operating environment

2.5 User environment

2.6 User Documentation

The following documentation will be delivered along with the software:

2.7 Design/implementation constraints

Details provided by the users during sign up should be stored in database.

16 | P a g e ESS Africa Ltd. & CSM TECHNOLOGIES PVT. LTD.