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.

The template for My Application List is present under https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/tl/src/pages/citizen/Applications/Application.js and Application Details page is present inside https://github.com/egovernments/digit-ui-internals/blob/main/packages/modules/tl/src/pages/citizen/Applications/ApplicationDetails.js .

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.

const { isLoading, isError, data, error, ...rest } = view === "bills" ? Digit.Hooks.tl.useFetchBill(
    {
      params: { businessService: "TL", tenantId, mobileNumber },
      config: { enabled: view === "bills" }
    }
  ) : Digit.Hooks.tl.useTLSearchApplication({}, {
    enabled: view !== "bills"
  });

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.

 const { isLoading, isError, error, data: application, error: errorApplication } = Digit.Hooks.tl.useTLApplicationDetails({
    tenantId: tenantId,
    applicationNumber: id,
  });

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.

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

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.

Inbox page is constituted out of 4 react components:-

ApplicationLinks

ApplicationLinks is a separate component that hold links to other pages of possible navigation from inbox. This component is common in both Mobile and Desktop view. Links are conditionally rendered according to the user roles

SearchApplication

Search Application component is a form based component, that controls the Table component and the search param for Inbox API, it uses FormComposer HOC to render fields.

Validation of these fields are achieved by using controlled component rules

Any number of search fields can be added but by convention, only mobile numbers and appilication numbers are provided

Filters

Filters contain input fields to filter the result of api, by sending search params to inbox api.

It contains 3 sections

1. Assigned to Me/ All - It is a radio component to send assignedToMe param as true or false

2. Locality - Filter result according to the selected locality by sending locality code in moduleSearch params in inbox api

3. Status - Status filters are achieved by sending id received from inbox api response and mapping the name of businessService, status name and count

Table

Table is a react component which uses React-Table plugin, used in multiple modules

However in Mobile view are using cards to list all the applications without pagination support

APIs

API CURL -

Search Application and Search License pages are used for searching any application/ license that may or may not be relevant to the workflow action of the logged-in users.

Search Application has 2 components.

Search Fields

Search field component is a form which takes inputs and pass it into tl-search api params. It utilizes SearchForm and SearchField component to create and arrange the form.

Result Table

Result Table uses Table react component and the result from api is adapted to the table config using a custom hook inside common parent wrapper and passing the response to individual components

Search License has fixed param where the status of the application is “APPROVED”, other than differences in table config

APIs

API end point for searching trade licenses is {env}/tl-services/v1/_search

API CURL -

curl 'https://qa.digit.org/tl-services/v1/_search?tenantId=pb.amritsar&fromDate=1625077800000&toDate=1627410599000&limit=10&sortBy=commencementDate&sortOrder=DESC&status=APPROVED&_=1627375567840' \
  -H 'authority: qa.digit.org' \
  -H 'sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'dnt: 1' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36' \
  -H 'content-type: application/json;charset=UTF-8' \
  -H 'origin: https://qa.digit.org' \
  -H 'sec-fetch-site: same-origin' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-dest: empty' \
  -H 'referer: https://qa.digit.org/digit-ui/employee/tl/search/license' \
  -H 'accept-language: en-US,en;q=0.9,hi;q=0.8' \
  --data-raw '{"RequestInfo":{"apiId":"Rainmaker","authToken":"18158d2b-0a50-4a60-baa3-a83c157e7aad"}}' \
  --compressed

Objective

Provide Employee to purpose workflow actions.

The same screen is used for both application details and trade details.

Based on the conditions, we are showing the details here

example: If the application is not in an approved state and the business Service New TL, then we are showing application details otherwise we are showing trade details.

Application Details

For workflow actions, please refer to the file below.

Trade Details

Timeline View

Workflow is the same as Old UI only, please refer to the documentation link below.

Role Action Mapping

Objective

The trade license 'apply' is the major feature in TL Module. It allows Citizens or Counter Employees to create TL Applications for the current financial year.

Every application is a part of the workflow.

Once the user login with TL_CEMP Role, then the User will get the option for creating a New TL Application in the TL card and as well as in the inbox.

Clicking of New Application it navigates to the New Trade License Application screen.

Technical Implementation Details

Initial MDMS call is being made on page load like old UI.

MDMS Data

Data fetch, load and render

• Clicking on Submit button, tl-services/v1/_create api is called and create the application, after getting success response, we are calling update API tl-services/v1/_update.

Acknowledgement Screen

After Success of create and update calls, will route to the ****acknowledgement screen.

Role Action Mapping

All the fields in this flow are the same as the New TL Application. The difference here is that max fields are having pre-populated data (On Loading the page, search is made for that particular application).

Will get the Renew Trade License option, when the application is in an approved state and the same financial year application is not present in the workflow.

File path: digit-ui-internals/ApplicationDetails.js at main · egovernments/digit-ui-internals

When we click on the Renew Trade License application, it will route to Renew screen

Direct Renewal: There is no change in any fields and directly clicks on submit application, update API call is made for the respective application wit respective to Direct Renewal (applicationType: RENEWAL, workflowCode: DIRECTRENEWAL, )and it will go into direct renewal flow.

Edit Renewal: If there is any change in any fields and clicks on submit application, update API call is made with respect to edit renewal (applicationType: RENEWAL,workflowCode: EDITRENEWAL )and update the application and it will go into edit renewal flow.

Units, Accessories, Owners and documents details in case of Edit/Renewal flow

Acknowledgement Screen

After a successful update call, the user is routed to the acknowledgement screen.

EDIT Flow: It is also the same as renewal flow only, but we are passing the action action: RESUBMIT on the update call with all the changes.

Application/ Trade Details: Application Details/Trade Details

TL Create New Application: New Trade License Application

Role Action Mapping