About TL

DIGIT-Trade License (TL) enables local government bodies to regulate trading establishments. It also serves to protect the interest of the public at large against possible health hazard and inconvenience that can be caused by any business operations. With DIGIT-TL traders can obtain the trade certificate in a simplified manner and ensure compliance with rules and safety guidelines issued by the government. The module offers the citizens and governance bodies a convenient and transparent means of processing trade licenses.

The Trade License application makes the process of obtaining a Trade License easy, smooth, and transparent. The module, hence, removes the need for manual processing and streamlines the key trade license management functions to provide a better user experience.

Key Features

DIGIT Trade License module enables citizens to -

1. Apply for a new trade license or renew an existing trade license.

2. Upload all the relevant documents required for the license.

3. Make payment for the Trade License (New/Renewal) fee using the online payment gateway.

4. Receive notifications and alerts by emails or SMS for new application status updates and pending renewals.

5. Download Trade License, Payment & Acknowledgement Receipts online.

DIGIT Trade License module enables employees to -

1. Create flexible role-based workflows.

2. Configure license fees calculation logic.

3. View custom dashboards for module statistics.

4. Filter search results using advanced configurable search parameters.

Section Overview

This section contains all docs and information required to understand the TL module, its key features, functional scope, and configuration details. Click on the links below to learn more about deploying, configuring, customizing, and using the TL module.

• Functional Specifications

• TL Roadmap

• TL User Manual

• Product Brochure

• TL Workflows

• Master Data Configuration Templates

• TL Service Configuration

• Implementation Handbook

• Demo Script

Contact Us

Reach out to us through any of the below-mentioned contact channels for any assistance or additional information on TL module deployment.

Details coming soon..

Details coming soon..

Introduction

The DIGIT-Trade License application makes the process of obtaining a Trade License easy, smooth, and transparent. The module, hence, removes the need for manual processing and streamlines the key trade license management functions to provide a better user experience.

Module Features

DIGIT Trade License module enables citizens to -

1. Apply for a new trade license or renew an existing trade license.

2. Upload all the relevant documents required for the license.

3. Make payment for the Trade License (New/Renewal) fee using the online payment gateway.

4. Receive notifications and alerts by emails or SMS for new application status updates and pending renewals.

5. Download Trade License, Payment & Acknowledgement Receipts online.

DIGIT Trade License module enables employees to -

1. Create flexible role-based workflows.

2. Configure license fees calculation logic.

3. View custom dashboards for module statistics.

4. Filter search results using advanced configurable search parameters.

Module Ontology

State Level

1. Trade Category

2. Trade Type

3. Trade Sub Type

4. Trade License Documents Attachment

5. Structure Type

6. Structure Subtype

ULB Level

1. Trade License Fee

Module Reports

1. Receipt Register

2. Application Status

3. Cancelled Receipt Register

4. ULBwise Collection Report

5. ULBwise Application Status

For traders to do business in India, ease in redundant procedures and regulatory processes is of paramount importance. DIGIT-Trade License increases procedural efficiency, improves access to license information, and provides transparency thus enabling the business to flourish and function with ease.

All content on this page by is licensed under a .

Introduction

Trade Type can be further sub-classified into Trade Sub Type depending on the trade ontology existing in the ULBs or States. Hence, Hotels can be further classified into Dhabas in North India or Udupis in South India.

Once the are defined, the next task is to -

• Define Trade Sub Types

• Map Trade Types to corresponding Trade Sub Types

Data Table

The table above contains sample data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.

3. Select the relevant Trade Type Code from the Trade Type master data. This will map the listed Trade Sub Type to the selected Trade Type.

4. Enter a unique value for Trade Sub Type Code.

5. Enter the English name for Trade Sub Type Name (English).

6. Enter the local name for the Trade Sub Type Name (Local Language).

Checklist

The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

Once the are defined, the next task is to -

• Define Trade Types

• Map Trade Category to listed Trade Types

The Trade Type can be defined as the next (2nd) level classification of Trade. There can be multiple trade types and the list may vary from one State/ULB to another.

Data Table

The table above contains sample Trade Type data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.

3. Select the relevant Trade Category Code from the available drop-down list of Trade Category. This will map the listed Trade Type to the corresponding Trade Category.

4. Enter a unique Trade Type Code to identify the type of trade.

5. Enter a Trade Type Name (In English).

6. Enter the Trade Type Name (In Local Language).

Checklist

The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Introduction

The Trade Category List can be defined as the primary or the 1st level classification “head” for trade(s) defined at a ULB/State Level.

Data Table

The table above contains sample Trade Category data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document to learn more about the template sheet, data type, size, and definitions.

3. Enter a unique Trade Category Code for each trade head.

4. Enter the Trade Category Name. Some trade categories are already defined in the master. Add new categories as required.

5. Enter the Trade Category Name (Local Language).

Checklist

The checklist contains a set of activities to be performed once the data is filled into a template to ensure data entry requirements are met. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Configuration Data Templateconfiguration-data-template-trade-master-2-.xlsx - 17KB

Sample Data Templatesample-configuration-data-template-trade-master-filled-2-.xlsx - 19KB

Introduction

The Trade License product provides a digital interface, allowing citizens to apply for the Trade License and subsequently make the trade license fee payment online.

The Trade License product enables:

• Ease of doing business — Traders can apply for new licenses, renewals, amendments, and supplemental licenses

• Regulatory Tracking — Administrators can track and manage regulatory processes

• Shorter Timelines — It streamlines and automates business licensing processes and helps a business to be set up quickly

• Data-driven decision making — The application collates valuable information on the economic activity and employment opportunities in a ULB

Functional Scope

The list below summarizes the key features supported by the TL module -

1. Registration, Login and Creation of User Profile

2. Applying for a Trade License

3. Trade License Issue

4. Modifications to a Trade License

5. Renewal of Trade License

6. Payments and Fee

7. Dashboards and Reports

8. General Features

Registration, Login and Creation of User Profile

Applying for a Trade License

User can apply for a new TL from the system. User can select the type of license to apply. The user enters trade details, owner details and documents after which application can be reviewed and submitted. Similarly, a counter employee can also apply for TL on behalf of the citizen. The system has a workflow integration which enables stage-wise approval before Approval for issuing the Trade License.

Trade License Issue

The system has the facility to assign the application to the respective Inspector for survey and verification. After the application is submitted, it goes to the document verifier. The next step after document verification is field inspection. After the field inspector’s approval, the TL is approved by the approver.

Modifications to a Trade License

The system has the facility to edit/update the Application based on the Inspection report against the application.

Renewal of a Trade License

The system has the facility to provide a hassle-free renewal process for citizen and employee ease, leading to increased revenues, by reducing unlicensed trades. The system allows sending of SMS and Email notifications and reminders based on the renewal cycle.

Payment and Fee

Dashboards and Reports

General Features

System specification in compliance with the Ease of Doing Business (EODB) BRAP 2019

List of Features- Trade License

Overview

This service is used to issue a license to the user after verification. The service is designed in such a way that it can be used to serve different type of licenses. Currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass. The service is integrated with workflow where we can define the steps for approval of the application. Once the application is approved the license is generated.

Pre-requisites

Before you proceed with the documentation, make sure the following pre-requisites are met -

• Java 8

• Kafka server is up and running

• egov-persister service is running and has tl-services persister config path added in it

• PSQL server is running and database is created

Key Functionalities

• Used for license generations in trade licenses, stakeholder registration and issue lockdown pass

• Define roles to applicants on successful application to access Building Plan Approval services at the time of stakeholder registration

• Generate application number and license number

• Support workflows

• Provide notification on various status changes for an application

Interaction Diagram

Deployment Details

1. Add MDMS configs required for Trade License and BPA stakeholder registration and restart MDMS service

2. Deploy the latest version of tl-services service

3. Add tl-service persister yaml path in persister configuration and restart persister service

4. Add Role-Action mapping for API’s

5. Create businessService (workflow configuration) according to trade license and stakeholder registration

6. Add tl-service indexer yaml path in indexer service configuration and restart indexer service

Configuration Details

Following application properties in the Trade License service are configurable.

Integration

Integration Scope

The trade-license service is currently used to issue trade licenses, perform stakeholder registration and issue lockdown pass.

Integration Benefits

• Provide backend support for the different license registration process.

• Mseva and SMS notifications on application status changes.

• The elastic search index for creating visualizations and Dashboards.

• Bpa Stakeholder registration provides new roles to the user to access the Building Plan Approval system.

• Supports workflow which is configurable

Steps to Integration

1. To integrate, host of tl-services service should be overwritten in the helm chart.

2. {servicename}/_create/ _create should be added as the create endpoint for creating any license in the system

3. {servicename}/_search/ _search should be added as the search endpoint. This method handles all requests to search existing records depending on different search criteria

4. {servicename}/_update/ _update should be added as the update endpoint. This method is used to update fields in existing records or to update the status of the application based on workflow.

Reference Docs

Doc Links

API List

In all below endpoints if the service name is BPAREG it is treated as a stakeholder registration application and if it is TL or if it is absent then the application is treated as trade license application.

Stakeholder registration APIs:- https://www.getpostman.com/collections/d18b79ccfb69ee8bb526

Trade-License APIs:- https://www.getpostman.com/collections/99f98723c45f97024831

Overview

Trade License Calculator service is used to calculate the Trade license fees / renewal fees based on the defined billing slabs. This service enables the TL admins to create billing slab with different combination of license type, trade type, structure type and accessory type. The service is designed in such a way that it can be used to serve different type of licenses.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

• Java 8

• Kafka server is up and running

• egov-persister service is running and has tl-calculation-persister & tl-billing-slab-persister config path added in it

• PSQL server is running and a database is created to store TL Application data

• Following services should be up and running:

  • egov-perister

  • egov-mdms

  • tl-services

  • billing-service

Key Functionalities

• TL Admin an Employee of ULB with TL_Admin role can create, update billing slab(s)

• ULB Employee with TL_CREATOR and TL_ADMIN can search billing slab(s)

• TL service internally calls tl-calculator to generate demand.

Deployment Details

1. Deploy the latest version of tl-service and tl-calculator

2. Add tl-calculation-persister.yml & tl-billing-slab-persister.yml file in config folder in git and add that path in persister . (The file path is to be added in environment yaml file in param called persist-yml-path )

Configuration Details

MDMS Configuration

MDMS for Penalty Calculation

{
  "tenantId": "pb",
  "moduleName": "TradeLicense",
  "Penalty": [
    {
      "rate": 10,
      "minAmount": 0.0,
      "flatAmount": 0.0,
      "fromFY": "2018-19",
      "startingDay": "1/09/2018"
    },
    {
      "rate": 10,
      "minAmount": 0.0,
      "flatAmount": 0.0,
      "fromFY": "2015-16",
      "startingDay": "1/04/2016"

    }
  ]
}   

MDMS file for Rebate Calculation

{
  "tenantId": "pb",
  "moduleName": "TradeLicense",
  "Rebate": [
    {
      "rate": 10,
      "maxAmount": null,
      "flatAmount": 0.0,
      "fromFY": "2018-19",
      "endingDay": "31/03"

    },
    {
      "rate": 10,
      "maxAmount": null,
      "flatAmount": 0.0,
      "fromFY": "2019-20",
      "endingDay": "31/03"
    }
  ]  
}

Actions & Role Action Mapping

Actions

[
  {
    "id": {{PLACEHOLDER1}},
    "name": "TL BillingSlab Create",
    "url": "/tl-calculator/billingslab/_create",
    "displayName": "TL BillingSlab Create",
    "orderNumber": 1,
    "parentModule": "",
    "enabled": false,
    "serviceCode": "",
    "code": "null",
    "path": ""
  },
  {
    "id": {{PLACEHOLDER2}},
    "name": "TL BillingSlab Update",
    "url": "/tl-calculator/billingslab/_update",
    "displayName": "TL BillingSlab Update",
    "orderNumber": 1,
    "parentModule": "",
    "enabled": false,
    "serviceCode": "",
    "code": "null",
    "path": ""
  },
  {
    "id": {{PLACEHOLDER3}},
    "name": "TL BillingSlab Search",
    "url": "/tl-calculator/billingslab/_search",
    "displayName": "TL BillingSlab Search",
    "orderNumber": 1,
    "parentModule": "",
    "enabled": false,
    "serviceCode": "",
    "code": "null",
    "path": ""
  },
  {
    "id": {{PLACEHOLDER4}},
    "name": "TL Calculation",
    "url": "/tl-calculator/v1/_calculate",
    "displayName": "TL Calculation",
    "orderNumber": 1,
    "parentModule": "",
    "enabled": false,
    "serviceCode": "",
    "code": "null",
    "path": ""
  }
]

Role Action Mapping

[
  {
    "rolecode": "TL_ADMIN",
    "actionid": "{{PLACEHOLDER1}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "TL_ADMIN",
    "actionid": "{{PLACEHOLDER2}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "TL_CREATOR",
    "actionid": "{{PLACEHOLDER3}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "TL_CEMP",
    "actionid": "{{PLACEHOLDER3}}",
    "actioncode": "",
    "tenantId": "pb"
  },
  {
    "rolecode": "TL_CEMP",
    "actionid": "{{PLACEHOLDER4}}",
    "actioncode": "",
    "tenantId": "pb"
  }
]

Integration Details

Integration Scope

tl-calculator will be integrated with tl-services. tl-services internally invoke the tl-calculator service to calculate and generate demand for the charges.

Integration Benefits

Tl calculator application is used to calculate the Trade license Fees based on the different billing slabs in the DB that's why the calculation and demand generation logic will be separated out from TL services. So in future, if calculation logic needs to modify then changes can be carried out for each implementation without modifying the TL services.

Steps to Integration

1. TL application to call /tl-calculator/v1/_calculate to calculate and generate the demand for the TL application

2. ULB Employee can create billing slab calling /tl-calculator/billingslab/_create

3. ULB Employee can update billing slab calling /tl-calculator/billingslab/_update

4. ULB Employee can search billing slab calling /tl-calculator/billingslab/_search

Interaction Diagram

TBD

Reference Docs

Doc Links

API List

(Note: All the API’s are in the same postman collection therefore the same link is added in each row)

__

__

Introduction

Along with the rates, the Trade License application process does require certain documents as an attachment of proof. The proof can be defined by a set of documents ranging from

• Identification Proof (Drivers License/ Voter Card/ Adhaar/ Pan etc.)

• Trade Premises Proof (Lease Agreement, Electricity Bills, etc).

• Misc Documents (Affidavit, Self- Declaration, etc).

The Number and the Documents required could vary across the State, ULB(s), and might be dependent on Trade Subtypes, all of which are totally configurable on DIGIT.

Data Table

The table above contains sample data.

Procedure

How to fill data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

3. In case of any doubt, please reach out to the person who has shared this template with you to discuss and clear your doubts.

4. Identify the “Trade Sub Types” that exists at a ULB/ State level.

5. Collect the above information and feed it below the “Trade Sub Type Name” column accordingly. The Description of Trade Sub Type Name must be provided as per the language specified in the respective column.

6. Add the “Trade Sub Type Code” respectively against the identified trade type(s).

7. Fill in the *Document 1 & *Document 2 columns respectively.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

Configuration Data Templateconfiguration-data-template-trade-master-4- (1).xlsx - 23KB

Sample Datasample-configuration-data-template-trade-master-filled-4-.xlsx - 24KB

Introduction

Structure sub type is the second level of classification of the premises where the trade has to be established and conducted. This is mostly used as management information in the trade detail.

Data Table

The table above contains sample data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document for more details on data type, size, and definitions.

3. Contact the person who shared this template with you to discuss and clear your doubts.

4. Enter the relevant structure sub types with its proper mapping with structure type.

5. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per specifications. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

A separate entity-specific checklist is not needed for this entity data template.

Attachments

Configuration Data Templateconfiguration-data-template-structure-subtype_v1-1-.xlsx - 10KB

Sample Datasample-configuraion-data-structure-type-and-subtype-2-.xlsx - 9KB

Executive Summary

Overview of the Product

The computerized and automatic Trade License system offered by eGov, facilitates citizens who seek to apply for a Trade License within any Urban Local Body with a transparent, speedy, hassle-free and user-friendly procedure. Trade License (TL) is one of the components of a smart city that ensures a check on all the trade practices and increases the ease of conducting business within the state. Keeping in mind the benefits associated with the product offered, the proposed system is about to be implemented in 500+ ULBs across the country in 15 states. (For details on product features refer to Section-2)

Implementation Methodology for TL

For the offered product, the implementation process can be divided into seven major distinctive stages. Each stage has a predefined entry and exit criteria, roles & responsibilities to assure objective monitoring and decision making for the overall success of the engagement. The whole implementation lifecycle is typical of 38-42 weeks for the State, keeping in mind the entry and exit criteria defined at the beginning and end of each stage are met on time recommended.

Exhibit 1: Phases of Implementation.

Stage Zero is that of program setup and onboarding which is a pre-requisite for the initiative to kick-off and requires setup of the governance model, implementation Team and decision regarding other significant elements of the initiative like funding and procurement process. Stage One requires scoping of the initiative and decisions on the priorities for implementation by the State Implementation Team. In stage two, the State Team will work upon identifying and finding solutions to the significant gaps in the product offered with respect to the need of the State. Configuration and customization of the product offered is the primary objective of stage four. This involves working on various aspects of State-specific needs and incorporating them into the product offered. In stage five, post doing UAT and including all the necessary feedback on the product, the roll-out of the product is done at the State level (Go Live) from a couple of ULBs to pan State coverage in batches. Finally, in stage 6 sustenance and ongoing improvements are worked upon while the product is already functioning in the State. (For details on implementation plan refer to Section-3)

Critical Success Factors for implementation

Implementation of Trade License (TL) requires meticulous planning and close coordination between various stakeholders at the center and State level. The success of the initiative is dependent upon many factors like strong Program governance, availability of the trained resource, financial planning, targeted Implementation Team onboarding, focus on last-mile capacity building and ensuring necessary support to Urban center. Achievement of all these factors will provide the most effective and efficient roll-out and adoption of the Trade License System in the State.

Product-Overview

The purpose of this document is to give an overview of the Trade License System (TLS). The Trade License product provides a digital interface, allowing citizens to apply for the Trade License and subsequently make the payment online.

The Trade License product enables:

• Ease of doing business — Traders can apply for new licenses, renewals, amendments, and supplemental licenses

• Regulatory Tracking — Administrators can track and manage regulatory processes

• Shorter Timelines — It streamlines and automates business licensing processes and helps a business to be set up quickly

• Data-driven decision making — The application collates valuable information on the economic activity and employment opportunities in a ULB

The TL product features can be broadly classified as the following modules:

1. Registration, Login and Creation of User Profile

2. Applying for a Trade License

3. Trade License Issue

4. Modifications to a Trade License

5. Renewal of Trade License

6. Payments and Fee

7. Dashboards and Reports

8. General Features

Trade License (TL) Implementation Methodology

This section provides an overview of the methodology for State-wide implementation of TL. The Implementation of TL is distributed across seven distinct stages. Each stage has a predefined entry & exit criteria and roles & responsibilities. This is to ensure objective monitoring and decision making for the overall success of the program. Details of each stage are defined in this section.

Note: This document is specific for States that have more than 30 ULBs

TL implementation program is expected to be completed approximately between 38- 42 weeks with the resource deployment by the State and System Integrator (SI) Team (as defined below). However, it is critical that activities and exit criteria set for each stage are achieved to adhere to this timeline.

Seven Stages of Implementation for Trade License

Stage 0 - Program Setup/Onboarding

This is a set of initial critical activities undertaken on receiving a letter of Enrolment or MOU from the State. Successful completion of these activities assures that the program is started with crucial personnel, System Integrator (SI) Teams, and funds.

*Details of TL cell is mentioned in section 4 of the handbook

System Integrator (SI) Sign-up:

• System Integrator and state will agree on program scope, program timelines, and budgeting & resourcing.

Stage 1 - Program Kick-Off

This stage envisages the in-person interaction of crucial State officials and implementation System Integrator (SI) Teams to kick-start the program. This stage may require multiple interactions/meetings with different interest groups. The principal objective of these interactions is to identify scope and planning strategies for phasing/ rollout, create an active collaboration & Governance approach and agree on a high-level timeline for the engagement.

*Exploration is required to understand the Inter and Intra Departmental Jurisdictions of Local Governments with respect to Trade License.

#Details of TL cell is mentioned in section 4 of the handbook

Stage 2 - Solution Design

During the Solution design stage, key State officials and members, who are subject matter experts, are expected to share State acts and policies and help interpret the same for the System Integrator (SI) Team. This stage baselines the State-specific product features in the Product Configuration report.

Stage 3 - Configuration & Customization

This stage consists of a series of developments in accordance with the detailed project plan to ensure smooth functioning of the customised product. Master Data Collection & Environment Setup will be achieved in this phase. Further monitoring and maintenance strategies are put in place.

Stage 4 - UAT & Go Live

During this stage, demonstration of the product followed by a hands-on session is conducted for the ULB officials. Necessary training of ULB officials and resources required for UAT is conducted and identified respectively. The establishment of the State support Team and required processes are initiated in this stage.

Stage 5 – Rollout

On successful Go-Live in the Pilot ULBs, and further fine tuning to stabilize the product, the solution will be rolled out to the rest of the ULBs in phases. Guidance and support from the State Team will be required to create the rollout plans and assure the necessary infrastructure for training and deployment is available at each ULB.

Stage 6 – Sustenance and Ongoing Improvement

The final stage consists of strategies to ensure the sustenance of the product in the State. Systems are put in place to ensure the continuous tracking of data and provisions are made to improve the product if new data suggests.

Roles and Responsibilities - TL Cell, eGov Team & System Integrator (SI)Team

This section outlines the activities involved in each stage of the implementation along with responsibility and accountability of critical stakeholders - State, eGov Team and System Integrator Team onboard.

TL Cell: TL Cell is the government-appointed body chaired by the Principal Secretary/Secretary, Urban Development Department with members from Urban Development Department etc.

Resource requirements for the TL cell required to be formed by the State

eGOv Team: eGov Team is the technical partner of the project which will provide all necessary support to the State concerning the implementation, Program Designing etc.

System Integrator (SI)Team: SI Team will be responsible for consulting, program management and the implementation of products in the ULBs in close collaboration with the TL cell, technical partner (eGov) and various other stakeholders.

Overall Program Assumptions

Glossary

Vision:

Defining the time frame to go live, the time frame to scale it pan state, the value proposition of the programme for the state and year-on-year financial targets and adoption targets

Project Plan:

A detailed plan of Program schedule/timelines, implementation phases, team structure and ongoing support and maintenance required.

System Integrator:

The Entity/Company which collates all the subsystem required for the project and integrates them to achieve the program objective

Program Charter:

Outline of implementation plan agreement with priority applications and broad timelines, program governance model, program success metrics and capacity building.

Acceptance Letter/MOU:

Formal Acceptance/Sign Off of the Client State with a clear mandate of the Program

Program Success Metrics:

Defining the parameters (which are measurable) prior to the program, on which the success of the program is to be measured on the completion of the program

Project steering committee:

The key body within the governance structure which is responsible for the business issues associated with the project that are essential in ensuring the delivery of the project outputs and the attainment of project outcomes.

Project governance:

Set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programmes and portfolios.

Scoping:

List of activities measured against time taken to complete them in accordance with the project goals

Baseline data:

Set of information that serves as a foundation to compare other data acquired afterwards

Project Kick off meeting:

Meeting with the project team and the client of the project. This meeting would follow definition of the base elements for the project and other project planning activities

Fitment Study:

GAP Study of the Existing/Required Field Process Vs Product

Data migration:

Existing Records of the functional activities need to be moved into the Database of the newly released Application

Data collection:

Required data for the roll-out of the applications, which needs to be collected from the existing functional process

Data validation approach:

This approach enables the sanctity of the Data with built-in validation by Design

Data synchronization:

The process of establishing consistency among data from a source to a target data storage and vice versa and the continuous harmonization of the data over time.

Pilot Implementation:

Any new process is tested out as pilot in one or two instances before pan implementation

Pilot ULB:

The ULB's Selected for the pilot implementation are called pilot ULB’s.

Roll out:

On successful clearance of the Pilot, the Process/Application/Services are implemented across all Offices/ULB's

Deployment:

Deployment defines the complete package of Software components set up in a particular environment

Customization:

Details of changes to be made in the Product to comply with the needed field process

Configuration:

Defining existing content such as Options and Variables based on the requirements on the ground

Product walkthrough:

Explaining the users step-by-step through a set of actions that they need to take to achieve a specific outcome

Edit Trade License

This feature allows the user to edit the application already created under their mobile number. After verifying employee can send the application back to the citizen with remarks of any changes that are needed to be done, which can be edited by the user using this flow.

Edit Application

On the Application details page, on the employee side, if the application is marked with “Send Back to Citizen”, the edit option will appear dynamically at the end of the application details page, which the user can navigate through my applications.

After this, On clicking the button, the user can edit the trade license details by going through the create flow again. First, it will land on the Summary page, where for each section “change” button is there. Clicking on the Change button, the user will be redirected to the particular content, the only exception here will be the values will be pre-populated from the License object received from Trade License Search API, on completing the flow, Update API will be called and License application will get successfully updated.

Technical Implementation Details

Edit Trade License main index can be found in the link given below:

here the main code consists of the function which results in transforming the License object received in Search API to the object structure which is suitable for citizen Apply flow (owner details, units, accessories etc), as the user needs to go through Apply flow again with pre-populated details and update the value of any accordingly. it also consists of the routing for the pages in the Apply flow.

getTradeEditDetails() function is being used so that the License object which is received from the Trade Search API, is converted to the Apply flow relevant structure so that the values can be pre-populated for the user convenience, on completing the flow, the application is updated. The link for the same can be found below:

Similarly, for owners the method which is used to form the new request param array is gettradeownerarray

It is similar to Accessories and Units - the only difference is in UI. Users can’t select multiple owners and only add one owner, it needs to either add more than one owner or select a single owner as ownership category and proceed. After the successful update the application next action will be “Pending for document verification” as there is an update in the data.

On completing the flow, the same object structure which was being used earlier in the flow gets changed into the request body structure for the update API: /tl-services/v1/_update, for this, the method which gets used is declared inside the Utils folder. Method name: convertToResubmitTrade and it can be found in the below link:

MDMS

MDMS data that is being used here is the same as the Apply flow only, as the flow structure used for edit trade is the same as the Apply for Trade License. Please refer to the link for detailed MDMS information.

Localization

For Edit Trade also, the Localization keys are being added in the ‘rainmaker-tl’ locale module. To change, update or adding of any new localization key will be done in the same locale module only.

Renewal Flow

This feature allows the user to renew any trade license applications, which either has been expired or had to be renewed for current financial year (Approved and Paid), it also had integration with the payment component, in order to complete the flow all together for renewal.

Renewal can be two types:

• DIRECT RENEWAL

• EDIT RENEWAL

Renewal List

Once the user click on Renew Trade License button at the home page, it will redirect to the renewal list page which will display all the application eligible for the renewal corresponding to the mobile number on which the user has logged in. It will show the Trade name, License Number, Owner Name and status whether active or expired.

Once the user click on Renew Button, it will redirect the user on the summary page just like in edit Trade license, with all the values pre-populated from the search API. Info card will be declared so that user will understand how to proceed with either direct renewal or edit renewal.

Direct Renewal

If the user just want to renew the same application without updating any data, it will cross-verify all the values in the summary page and then click on submit button directly at the end of the page, this will lead the application with the next status as pending for payment and user can go through payment flow from the acknowledgement screen also, by clicking on the Make Payment button.

Edit Renewal

If the user before renewal need to update the application, they can do so by clicking on the change button on the summary screen, this will tell that the flow has been changed from direct to edit renewal, and user will need to follow the same apply flow in order to complete the edit part of it. the values from the application will be pre-populated in the respective screens, to get the details about the edit flow,one can refer this link. .

Once the user click on submit button it will change the current action of the application to pending for document verification as the data has been updated.

Technical Implementation Details

Renewal Trade main index can be found in the below given link:

in this we are calling the trade license search API, In order to get all the application, through which the sorting is happened to classify which application are eligible for renewal for the current financial year.

the hook which has been used for the API is:

The data from here then are sorted into application which doesn’t have any open renewal application for current financial year or which has a status of approved or expired. the significant method to get the renewal list of application is mentioned below:

From here the Trade License List Component has been called which displays the list of the renewal application.

Once the user has completed the flow as required or clicked the submit button directly, the method convertToEditTrade is being called, which re arranges the data for the request body for the update API /tl-services/v1/_update.

If its a direct renewal only one update API is being called which updates the financial year only.

but if its a edit renewal, two updated API is called after the first API successful call the application status gets changed to Initiated but after the second API call its changed to applied. with next action as pending for document verification.

the code for these can be found in utils folder index please refer the below link for the same:

MDMS

MDMS data which is being used here is same as the Apply flow only, as the flow structure used for edit renew trade is same as the Apply for Trade License. Please refer the link for detailed MDMS information.

Localization

For Renew Trade also, the Localization keys are being added in the ‘rainmaker-tl’ locale module. To change, update or adding of any new localization key will be done in the same locale module only.

Objective

To provide the facility for the user to create trade license application for the current year by citizen or counter employee.

Apply for Trade License

Users can apply for trade license application by clicking on the Apply for Trade License button, and while going through the workflow, can add all the information, according to the question asked, at the end of the flow a summary screen will be visible for the review of the answers and on clicking the submit button an Application Trade License will be created for current Financial Year.

Apply Flow - The Trade License Registration screen will be displayed after login, which helps the user to understand the necessary documents needed to complete the new registration for Trade License. A Citizen Info card is also shown at the bottom of the page for any additional information, in here it’s about the maximum size of the file that can be uploaded.

Trade License Details/Assessment Flow - In this flow, the user needs to provide specific information about the trade being registered in order to get the license. Following are the steppers user needs to go through in this flow.

Trade Name - The user needs to give the name of the trade and on this page, only an info card is shown at the bottom which tells about the current financial year the trade application will be created, this financial year value is retrieved from MDMS.

Structure Type - here users need to select yes or no based on whether the trade has mobility or not, if they select Yes, then it will move to vehicle type and if they select No then it will move to the Building type page.

Commencement Date - It defines the date at which the trade had started or will start in the future.

Trade Units - User can enter about the trade category whether its goods or services, according to the option selected, Trade Type will load from MDMS as a drop-down and according to the trade type selected trade sub-type options will load in the trade sub type drop-down. The unit of measure and UOM value cannot be entered by the user, it will get pre-populated according to the options selected above that too from MDMS.

Users need to enter at least one unit to move forward and if needed to enter more, add more unit option can be clicked to do so, and to remove any unit, delete option on the top right of each unit card can be clicked.

Accessories - The Accessory page inquires if there are any accessories required for the business or not. Accessories may not be compulsory for all trades. If yes, it will move to the accessory details page. If no, it will skip it altogether and move to the start of the address flow.

Address Details Flow - After entering the details about the Trade, users will need to enter the address of the Trade, where it is located. The flow is straightforward, without any conditional routing.

Users can pinpoint the location in the Geo-location map, according to which pin code and city, as well as locality, will be automatically filled.

Owner Details Flow - At the end, users need to enter the details, about the Trade owner. Ownership can be Single or Multiple Owners. According to which the details will be filled.

In the case of a single/Multiple Owner following screen will be displayed, rest flow will remain the same.

Users can add multiple owners by clicking on the add owner button, the same functionality as Trade units and accessories. Add Owner button is not visible if the user selects a single owner on the previous page.

The rest of the flow will contain the owner primary address and three documents mainly regarding address proof, owner identity and owner photograph.

Check Page and Acknowledgement Screen - Users can cross-verify the data entered throughout the flow in the Check page and also if needed to change/update any data, can do that by clicking on the change option just mentioned in front of the data, it will credit them to the said page which data needs to be changed and then the whole flow needs to be repeated again in order to submit the application.

For Applying of Trade License Create API is being called, following is the snippet of the Create API being used:1create: "/tl-services/v1/_create"

If the API response is successful, then the Acknowledgement Screen will be displayed, otherwise Failed Acknowledgement Screen will be displayed.

On clicking on the Download Acknowledgement Form, A PDF will be downloaded.

Technical Implementation Details

All the screen has been developed using the new-UI structure followed previously in FSM, PGR and PT, except for multi-component.

The link for the Apply Trade License Main Index is given below, it can be used to understand the starting point of the flow:

TL (Trade License) Module has been segregated into a specified structure, All the screen configuration is inside PageComponent Folder, and the configuration for routing of the pages are mentioned under config folder which is common for both Citizen as well as Employee. Below is the snippet for folder structure and routing configuration.

Pages Folder is where the high-level configuration for controlling the whole flow is mentioned, for citizens and employees. Citizen includes Create, EditTrade, Renewal, Applications and Search Trade. Which inside carry the index (the main starting point of the whole flow).

In the Accessory-details page, Billing slab search API "/tl-calculator/billingslab/_search" is being called, which returns the array list of all the accessories for which the billing slab has been configured, from that object only a list of accessories has been formed, if the response came out to be an empty array then the options are curated from the MDMS API mentioned in the MDMS data section.

After completing the flow the user can download the acknowledgement PDF form of the License created and the config for the PDF generation can be found in the link given below:

Utils Folder basically contains all the methods which are being used throughout the TL module, and if any common method needs to be declared here, which in turn can be imported in other files.

For creating an Application the Create API from Trade License is being called using the React hooks, which has been declared under hooks/elements/TL as TLService.

MDMS Data

Throughout the flow, a few of the page data are being imported from MDMS, Following is the list of pages that are using MDMS data, These pages .js files can be found under page components.

For calling of MDMS data React Hooks has been used, so that it could be shared throughout the modules. Below is the little code snippet for the call used for MDMS.

Localization

Localization keys are added under the ‘rainmaker-tl’ locale module. In future, if any new labels are implemented in the Trade License (Citizen) that should also be pushed in the locale DB under rainmaker-tl locale module. Below is an example of few locale labels.

API Call Role Action Mapping

Introduction

Once the Trade Ontology is defined, the next step is to allocate the license fee associated with the Trades.

Dependent on the Trade Classification Level (/ ), the fee allocated might be the same across the Sate or could vary from ULB to ULB. There could be a distinct fee(s) for two different types of applications (new and renewal).

Following are the key tasks to be executed :

• Allocate the License Fee according to Trade Classification Level (Types/Subtypes).

• Map the License fee with the respective Trade Classification Level.

Data Table

The table above contains sample data.

Procedure

How to fill data

1. Download the data template attached to this page.

2. Get a good understanding of all the headers in the template sheet, their data type, size, and definitions by referring to the ‘Data Definition’ section of this document.

4. Collect the above information and feed it below the “Trade Sub Type Name” column accordingly. The Description of Trade Sub Type Name must be provided as per the language specified in the respective column.

5. Add the “Trade Sub Type Code” respectively against the identified trade type(s).

6. Fill in the New License Fee & New Renewal Fee accordingly. The New License Fee & Renewal Fee can be the same as well as distinct, depending on the by-laws/ mandate followed by the State/ULB.

7. Fill in the fields related to Units of Measurement (UOM Unit, From/To) for the available trades only.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per the expectation. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

This checklist covers the activities which are specific to the entity.

Attachments

My Applications

Users can review the list of applications and their status registered under their mobile number in the My Applications tab. Each Application for the initial view will display Application No, Service Category, Owner Name (Multiple with a comma), status, SLA, Trade Name with View Details option, and if the status is pending for payment it will be View Details & Pay, through which User can look up more details about the Application.

Once the user clicks on the View Details or View Details & Pay button, the Application Details Page will be displayed with all the necessary information about the application.

The user can download the Application Acknowledgement Form (status - pending for payment ) or TL Certificate or receipt if it has been paid from the Download Link button at the top right corner of the page.

Timeline Component - timeline component is present at the end of the application details which tells about the current status and history of the application being initiated, Applied, Pending for Document Verification, Pending for Field Inspection, Pending approval, Pending payment, Approved etc.

Technical Implementation Details

The link for the Applications and Application Details main code is given below, it can be used to understand the working of the code, Below is the folder link.

All the Application list is being retrieved by calling the search API "/tl-services/v1/_search", if the view is set as “bills”, all the application is loaded using the hook useFetchBill which calls the /billing-service/bill/v2/_fetchbill API. SLA value in Application List Screen is being calculated from the data received from workflow API : /egov-workflow-v2/egov-wf/process/_search

Following is the hook used for the Trade search API.

To get the Application details in key-value format, in order to make it more compatible, following hook is being used, which is a common service to be used across modules.

MDMS

No MDMS data is being used here, all the data is being loaded from Search API/Fetch Bill API.

Localization

For My Applications also the Localization keys are being added in the ‘rainmaker-tl’ locale module same as other parts of module TL. To change, update or of adding any new localization key will be done in the same locale module only.

Introduction

The structure type is the first level of classification of the premises where the trade has to be established and conducted. This is mostly used as management information in the trade detail.

Data Table

The table above contains sample data.

Procedure

Data Definition

Steps to fill data

1. Download the data template attached to this page.

2. Refer to the ‘Data Definition’ section of this document for more details on data type, size, and definitions.

3. Contact the person who shared this template with you to discuss and clear your doubts.

4. Enter the relevant structure types.

5. Verify the data once again by going through the checklist and making sure that each and every point mentioned in the checklist is covered.

Checklist

The checklist is a set of activities to be performed once the data is filled into a template to ensure data type, size, and format of data is as per specifications. These activities have been divided into 2 groups as given below.

Common Checklist

This checklist covers all the activities which are common across the entities.

Entity Specific Checklist

A separate entity-specific checklist is not needed for this entity data template.

Attachments