Overview

This document says how to generate an APK and its configuration.

Generate APK - Steps

1. Add the .env file at the root of the project with the required config based on the env in the file.

Sample env config:

BASE_URL='https://works-dev.digit.org/'
MDMS_API_PATH='egov-mds-service/v1/_search'
GLOBAL_ASSETS='https://s3.ap-south-1.amazonaws.com/works-dev-asset/worksGlobalConfig.json'
ENV_NAME="DEV"

1. Run the below commands in your terminal from the root of the project

flutter clean
flutter pub get

1. Run the below command in your terminal from the root of the project to generate the APK

flutter build apk --release

Work order is created for an approved estimate in order to award the work to CBO. CBO starts the work to complete it within a given time period.

In case organization comes to know that they are not in a position to complete the work within the given time frame due to various reasons, they need to inform the same to the officer in-charge of project and apply for time extension which is then subject to approval/ canceling of work order based on the analysis done by the ULB.

Requests for time extension can be directly raised by CBO using the mobile application and by the officer in-charge of the project on behalf of CBO using web application. Once a request is raised it goes for verification and approval.

We have the following screens for Time Extension in Web Interface

• Create Time Extension

• View Time Extension

• Edit Time Extension

• Search Time Extension ( Same as search work order screen)

• Inbox ( Same as work order inbox )

Conditions to Create a Time Extension Request

• Work order must be in Accepted state

• Existing Time Extension requests, if already created, must not be in workflow

• At Least one muster roll must be approved

How to Create a Time Extension Request in Web-Interface

• Login with work order creator role and Navigate to Home page.

• Home > Work Orders > Inbox > Search Work Order > View Work Order > Request Time Extension (From Action Menu)

• A screen similar to the Work Order View screen is opened along with two new input fields

• Enter time extension value (in days) and reason in those two inputs and click on Create action button

• A workflow popup is opened where users can enter the assignee and relevant comments. Click on Submit button

• A response page is opened which shows the newly created revised work order application’s number

Inbox, View and Search Screen For Time Extension in Web Interface

There is no separate inbox for time extension. Work order inbox will list the time extension requests which are INWORKFLOW state. Clicking on the time extension request will open a view time extension screen where the user can take actions on the request based on the roles defined in the workflow. Alternatively, users can go to the work order search screen to search for any time extension request.

Workflow for Time Extension

This section provides details for configuring modules or MDMS.

Overview

This section provides details about the MUKTASoft UI configuration required to enable it in any environment.

Steps:

DevOps Configuration

In the DevOps repository of your organization, locate the following - "deploy-as-code/helm/environments/works-dev.yaml".

Add the code block below to the environment YAML file used to deploy the Works platform.

Global Configuration

This section contains the configurations applicable globally to all UI modules. These need to be configured before service-specific UI configurations.

Create a globalconfig.js file - Steps:

1. Generate a configuration file named "globalconfigs.js" using the settings provided (refer to the code below).

2. Set up all the images and logos needed in your S3 storage, and include the links as "footerBWLogoURL" and "footerLogoURL."

3. Specify the state tenant ID as "stateTenantId."

4. If any user roles should be marked as invalid, list them under "invalidEmployeeRoles."

5. Upload this global configuration file to your S3 bucket, naming it "globalconfigs.js."

MDMS Configuration

Roles Configuration

Localization Configuration

Reference Links

Overview

The Estimate module helps in creating estimates based on projects created. This enables in deciding the Tendering, and Quotation.

The module has 5 associated screens :

1. Create Estimate

2. Search Estimate

3. Edit Estimate

4. View Estimate

5. Estimate Inbox

MDMS Configurations

Module Enablement Configuration

Set module code as “Estimate” in Module.js of Estimate Module. Refer to the file

Enable Module in App.js. Update the object ‘enabledModules’. Use the code Estimate. This code should match the code of the cityModule.json, mentioned above.

Role-action Mapping

Sidebar Configuration

Sample object for a sidebar action defined in MDMS (containing navigationUrl )

Screen Configuration

Localization Configuration & Modules

Workflow Configuration

2. For Workflow related actions, the View screens use two components:

Customisation

Custom Components used in Estimate:

1. Document Config -
2. • Used in Create Estimate Screen to capture Non-Sor line items.

3. • Used in Create Estimate Screen to capture Overhead items.

4. • Used in Create Estimate Screen to calculate and render Total Estimate Amount.

6. • Used in Create Estimate screen to capture labour and material costs. The total labour and material costs cannot be greater than the total Estimate Amount.

Create Estimate Screen:

1. Use the common Utility “PreProcessMDMSConfig”.

2. Pass the associated dependencies for the config.

3. The utility will return a config which will run through FormComposer.

4. Refer to docs for Pre-Process config in Component comments.

5. UOM and Overheads captured in the create screen are MDMS data.

Inbox / Search Screen:

1. Use the common utility “preProcessMDMSConfigInboxSearch”.

2. Pass the associated dependencies for the config.

3. The utility will return a config which will run through RenderFormFields.

4. Refer to docs for Pre-Process config in Component comments.

Overview

The Project module enables the Junior Engineer to capture the project details, search, view and modify the existing projects. This module is the initial step in starting the work.

The module has 4 associated screens :

1. Create

2. Search

3. Modify

4. View

MDMS Configurations

Module Enablement Configuration

Set module code as “Project” in Module.js of Project Module. Refer https://github.com/egovernments/works-mdms-data/blob/DEV/data/pg/tenant/citymodule.json.

Enable module in App.js. Update the object ‘enabledModules’. Use the code “Project”. This code should match the code of cityModule.json, mentioned above.

PDF Configuration

The project created can be downloaded in PDF format from the View Project screen in the project module. The PDF contains the respective project descriptions, work details, and location details.

PDF URL : https://works-dev.digit.org/egov-pdf/download/project/project-details?projectId=<project-Id>&tenantId=<tenant-Id>

Role-action Mapping

Sidebar Configuration

Sample Configuration

Screen Configuration

Localisation Configuration & Modules

Workflow Configuration

NA

Customisation

Create Screen:

1. Use the common Utility “PreProcessMDMSConfig”.

2. Pass the associated dependencies for the config.

3. The utility returns a config that will run through the FormComposer.

4. Refer to docs for pre-process config in component comments.

Search Screen:

1. Use the common utility “preProcessMDMSConfigInboxSearch”.

2. Pass the associated dependencies for the config.

3. The utility returns a config that will run through the RenderFormFields.

4. Refer to docs for pre-process config in component comments.

Custom Components Used in Projects:

2. Form Validations: Verify that all necessary form validations are included in the screen configurations. Add populators for respective validations and specify the JSON path to enable the pre-process function.

Overview

This module helps in creating a work order for the Project based on the estimates designed. This enables in deciding the Tendering, Quotation and Nomination. Based on the nomination, CBO is being mapped to the respective work order.

This module has 5 associated screens :

1. Create

2. Search

3. Modify

4. View

5. Inbox

MDMS Configurations

Module Enablement Configuration

1. Set module code as “Contracts” in Module.js of Contracts Module. Refer https://github.com/egovernments/works-mdms-data/blob/DEV/data/pg/tenant/citymodule.json

1. Enable Module in App.js. Update the object ‘enabledModules’. Use the code “Contracts”. This code should match the code of the cityModule.json, mentioned above.

Role-action Mapping

Sidebar Configuration

Screen Configuration

Localization Configuration & Modules

Workflow Configuration

Customization

1. API-based Data -

• Name of CBO - This field is being captured on the Create screen and Modify screen. Data for this field comes from the backend.

• CBO ID - This field is being set based on the value selected in the Name Of CBO.

• Name of Officer In Charge - This field is being populated based on the HRMS Search. Here the role is hardcoded to ‘OFFICER_IN_CHARGE’.

• Designation of Officer In Charge - This field is being set based on the value selected in the Name of Officer in charge.

2. Custom Components used in Projects :

• Work Order Terms and Conditions - This component will help input the description in the table. Users can add and delete the rows. The first row will not be deleted, clicking on the delete button will empty the first row. Refer Component - WOTermsAndConditions.

3. Create Screen:

• Please use the common Utility “PreProcessMDMSConfig”.

• Pass the associated dependencies for the config.

• The utility will return a config which will run through FormComposer.

• Refer to docs for Pre-Process config in Component comments.

4. Inbox / Search Screen :

• Please use the common utility “preProcessMDMSConfigInboxSearch”.

• Pass the associated dependencies for the config.

• The utility will return a config which will run through RenderFormFields.

• Refer to docs for Pre-Process config in Component comments.

Overview

This module helps in creating an individual (Wage Seeker), it is needed in Mukta to assign work, track attendance and process DBTs.

This module has 3 associated screens :

1. Search

2. View

3. Modify

MDMS Configurations

Module Enablement Configuration

1. Set module code as “Masters” in Module.js for the Masters (Organization) Module. Refer

1. Enable Module in App.js. Update the object ‘enabledModules’. Use the code “Masters”. This code should match the code of the cityModule.json, mentioned above.

Role-action Mapping

Sidebar Configuration

Sample object for a sidebar action defined in MDMS (containing the navigation Url)

Screen Configuration

Localization Configuration & Modules

Workflow Configuration

NA

Customization

1. Modify Individual Screen

   • Use the common Utility “PreProcessMDMSConfig”.

   • Pass the associated dependencies for the config.

   • The utility will return a config which will run through FormComposer.

   • Refer to docs for Pre-Process configuration of Component comments.

2. Search Individual Screen

   • Use the common utility “preProcessMDMSConfigInboxSearch”.

   • Pass the associated dependencies for the config.

   • The utility will return a config which will run through RenderFormFields.

   • Refer to docs for Pre-Process configuration of Component comments.
3. Validations added

   • Form validations are integrated within the Screen Configurations. To facilitate this, include the appropriate populators for the respective validations. Additionally, make sure to specify the JSON path necessary for the pre-processing to function correctly.

4. Delete API Usage

   • To modify existing skills, the "deleteIndividual" and "update Individual" APIs are utilized.

   • If skills are already present, they can be updated using the "update" API. If any skills need to be removed, the "delete" API is used. In the case of skill removal, the entire skill object should be sent with the 'isDeleted' flag set to true.

Overview

This module helps create wage seekers.

ROLE: ORG_ADMIN

This module contains 4 linked forms

4. Summary Details

Individual Details

Address Details

Financial Details

This form combines the details of the previous 3 forms, and users can tap on the respective edit icon to edit the particular details.

On submit, the wage seeker is created successfully.

API Details

JIT stands for Just in Time e-Payment. We are utilizing JIT in MUKTASOFT for payments.

We have the following screens for JIT in Web-Interface

• Search Payment Instruction

• View Payment Instruction

• Create Payment Instruction (Temporary Screen)

Create Payment Instruction (Temporary Screen)

Payment Instructions are created at the Backend when a bill gets approved. This is handled via cron jobs. We have kept a temporary flow for a user to create Payment for testing cases, or for when cron jobs are not running at Backend properly. In production this flow will be disabled.

To create Payment Instruction from UI. Navigate to Search Payment Instruction screen from home screen card and click on Create Payment Instruction. Search bill screen is opened, the user can select for which bills payment has to be created and click on Generate payment. A relevant toast message is displayed.

Search Payment Instruction

1. gate, login and go to the Home Page. Then click on Payment Instruction on Mukta Home page card

2. This screen is utilized to search payments. It has 2 tabs.

3. • Pending For Action -> This tab will, by default, show all the payments that are either in FAILED or PARTIAL state

   • Open Search -> This screen can be utilized to search any payment

4. Mdms Configs for Search Screen -> Search Payment Instruction

5. Payment Instruction type config -> Payment Instruction Type

6. Payment Instruction Status config -> Payment Instruction Status

View Payment Instruction

Users can navigate to the view payment instruction screen from the search payment instruction screen. It shows detailed information about the payment, Beneficiary, and list of payment instructions associated.

Sometimes payment gets failed or partially successful. For these use cases we have two options which are as follows :

• For FAILED payments : If a payment is in a failed state, an action button is shown on the view screen to take a retry action. Upon retrying, a new payment instruction gets generated and a toast message is displayed. Also the View screen is refreshed which now includes the newly created payment instruction in INITIATED state.

• For PARTIAL payments : If a payment is in PARTIAL state. This basically means payment for at least one beneficiary was successful. In this case we have an option to generate a revised payment instruction which creates a new child payment instruction associated with the original payment instruction. Again, a success toast is displayed and the View screen gets refreshed with newly generated payment instruction. Newly generated payment instruction is now referred to as revised payment instruction.

List of statuses available for payment

Mdms config -> Payment Status

• INITIATED

• APPROVED

• FAILED

• INPROCESS

• SUCCESSFUL

• PARTIAL

• COMPLETED

List of Payment Types

Mdms config -> Payment Types

• Original

• Revised

API's Used for JIT in UI

• /wms/ifms-pi/_search -> for Searching PI's

• /ifms/pi/v1/create -> For Retry and Partial action

Sample Curl's:

curl 'https://works-qa.digit.org/ifms/pi/v1/_create?_=1693813763900' \
  -H 'authority: works-qa.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'content-type: application/json' \
  -H 'cookie: __cuid=59fd9aac25b044f6af006bd4b159cbbf; amp_fef1e8=f4fc07f6-3fb0-4c67-8114-a1beb906e625R...1h2nk91dr.1h2nk91du.a.0.a' \
  -H 'origin: https://works-qa.digit.org' \
  -H 'referer: https://works-qa.digit.org/works-ui/employee/expenditure/view-payment?tenantId=pg.citya&paymentNumber=EP/0/2023-24/09/04/000172' \
  -H 'sec-ch-ua: "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36' \
  --data-raw '{"tenantId":"pg.citya","referenceId":"EP/0/2023-24/09/04/000172","RequestInfo":{"apiId":"Rainmaker","authToken":"fb30f563-c053-46e2-acfd-6e1ebdf75827","msgId":"1693813763900|en_IN","plainAccessRequest":{}}}' \
  --compressed

curl 'https://works-qa.digit.org/wms/ifms-pi/_search' \
  -H 'authority: works-qa.digit.org' \
  -H 'accept: application/json, text/plain, */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'content-type: application/json' \
  -H 'cookie: __cuid=59fd9aac25b044f6af006bd4b159cbbf; amp_fef1e8=f4fc07f6-3fb0-4c67-8114-a1beb906e625R...1h2nk91dr.1h2nk91du.a.0.a' \
  -H 'origin: https://works-qa.digit.org' \
  -H 'referer: https://works-qa.digit.org/works-ui/employee/expenditure/search-payment-instruction' \
  -H 'sec-ch-ua: "Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36' \
  --data-raw '{"inbox":{"moduleSearchCriteria":{"tenantId":"pg.citya","status":["PARTIAL","FAILED"]},"tenantId":"pg.citya","limit":10,"offset":0},"RequestInfo":{"apiId":"Rainmaker","authToken":"fb30f563-c053-46e2-acfd-6e1ebdf75827","userInfo":{"id":444,"uuid":"bff9c3f6-6a25-45c4-b7ae-dddc016598fd","userName":"SMS QA testing","name":"SMS QA testing","mobileNumber":"9043685314","emailId":"","locale":null,"type":"EMPLOYEE","roles":[{"name":"HRMS Admin","code":"HRMS_ADMIN","tenantId":"pg.citya"},{"name":"WORK_ORDER_VIEWER","code":"WORK_ORDER_VIEWER","tenantId":"pg.citya"},{"name":"BILL_ACCOUNTANT","code":"BILL_ACCOUNTANT","tenantId":"pg.citya"},{"name":"WORK ORDER CREATOR","code":"WORK_ORDER_CREATOR","tenantId":"pg.citya"},{"name":"ESTIMATE VERIFIER","code":"ESTIMATE_VERIFIER","tenantId":"pg.citya"},{"name":"BILL_VERIFIER","code":"BILL_VERIFIER","tenantId":"pg.citya"},{"name":"ESTIMATE APPROVER","code":"ESTIMATE_APPROVER","tenantId":"pg.citya"},{"name":"Organization viewer","code":"ORG_VIEWER","tenantId":"pg.citya"},{"name":"WORK ORDER VERIFIER","code":"WORK_ORDER_VERIFIER","tenantId":"pg.citya"},{"name":"PROJECT VIEWER","code":"PROJECT_VIEWER","tenantId":"pg.citya"},{"name":"BILL_APPROVER","code":"BILL_APPROVER","tenantId":"pg.citya"},{"name":"MUSTER ROLL VERIFIER","code":"MUSTER_ROLL_VERIFIER","tenantId":"pg.citya"},{"name":"OFFICER IN CHARGE","code":"OFFICER_IN_CHARGE","tenantId":"pg.citya"},{"name":"PROJECT CREATOR","code":"PROJECT_CREATOR","tenantId":"pg.citya"},{"name":"Employee Common","code":"EMPLOYEE_COMMON","tenantId":"pg.citya"},{"name":"BILL_VIEWER","code":"BILL_VIEWER","tenantId":"pg.citya"},{"name":"TECHNICAL SANCTIONER","code":"TECHNICAL_SANCTIONER","tenantId":"pg.citya"},{"name":"BILL_CREATOR","code":"BILL_CREATOR","tenantId":"pg.citya"},{"name":"MUSTER ROLL APPROVER","code":"MUSTER_ROLL_APPROVER","tenantId":"pg.citya"},{"name":"ESTIMATE VIEWER","code":"ESTIMATE_VIEWER","tenantId":"pg.citya"},{"name":"WORK ORDER APPROVER","code":"WORK_ORDER_APPROVER","tenantId":"pg.citya"},{"name":"ESTIMATE CREATOR","code":"ESTIMATE_CREATOR","tenantId":"pg.citya"},{"name":"State Dashboard Admin","code":"STADMIN","tenantId":"pg.citya"},{"name":"MUKTA Admin","code":"MUKTA_ADMIN","tenantId":"pg.citya"}],"active":true,"tenantId":"pg.citya","permanentCity":null},"msgId":"1693813698339|en_IN","plainAccessRequest":{}}}' \
  --compressed

User Roles Required for JIT

Roles related to Bill accountant are used here:

Overview

This module helps in taking the measurement, for an accepted contract

This module has 5 associated screens :

1. Create

2. Inbox

3. Edit

4. View

5. Search

Module enablement configuration

1. Set module code as "Measurement" in Module.js of Measurement Module. Refer https://github.com/egovernments/works-mdms-data/blob/DEV/data/pg/tenant/citymodule.json

{
        "module": "Measurement",
        "code": "Measurement",
        "active": true,
        "order": 13,
        "tenants": [
            {
                "code": "pg.cityb"
            },
            {
                "code": "pg.cityc"
            },
            {
                "code": "pg.citya"
            }
        ]
}

1. Enable Module in App.js. Update the object ‘enabledModules’. Use the code “Measurement”. This code should match with the code of the cityModule.json, mentioned above.

Role-action mapping

Sidebar configuration

{
      "id": 59,
      "name": "MEASUREMENT",
      "url": "url",
      "displayName": "MEASUREMENT Inbox",
      "orderNumber": 2,
      "parentModule": "",
      "enabled": true,
      "serviceCode": "ATTENDENCEMGMT",
      "code": "null",
      "navigationURL": "/works-ui/employee/measurement/inbox",
      "path": "4MEASUREMENT.Inbox",
      "leftIcon": "dynamic:AttendanceIcon"
}

Document Configuration

https://github.com/egovernments/egov-mdms-data/commit/85761f2c82ced17a0259e077f6b82355e62ce35c

Screen configuration

Localization Configuration and Modules

Workflow Configuration

Custom Components

1. MeasureTable:

This is the main component that handles the Logic for capturing the measurement for SOR / NONSOR based on the given processed Line items from the Estimate.

The same component has been used in the Detailed estimate which captures the detailed measurement information

The same component has the capability to be used in both create and view screens.

1. MeasureCard:

   This component handles the logic of the inner table present inside the MeasureTable.

Overview

This module helps in viewing and updating the muster rolls.

ROLE: ORG_ADMIN

This module has 2 associated screens :

1. View Muster Rolls Inbox

2. Muster Roll Table Screen

MDMS Configurations

Based on the business workflow state set for Muster Roll ( Sent BAck for Correction) in respective environments, Add the corresponding code in Sent Back to CBO Code MDMS

User actions

On this page, the following actions need to be performed: If the muster roll is in workflow, User can only view the muster roll, If the muster roll is sent back to CBO,then user can edit the attendance and resubmit the muster roll,

Validations

• If Muster Roll is in Workflow, The screen will only be a view page and Save as Draft and Re-Submit button will not be shown in the screen

• Based on the Attendance Hours list, users will be allowed to mark the attendance as Full Day, Half Day, or absent. If the list is of length 2, users will be allowed to mark only Full and Absent, Else, users can mark halfday as well.

API Details

DIGIT Components and Custom Components Used

Localization Configuration and Modules

Reference Files

1. Blocs :

• Attendance Create Log Bloc

• Search Muster Rolls in a Tenanat

• Muster Search From Muster ID Bloc

• Get Muster Roll Workflow Bloc

• Muster Get Attendance Log Bloc

• Create and Update Muster Roll Bloc

1. Models :

• Estimate Muster Roll Model

• Search Muster Roll Model

• Muster Workflow model

1. Repositories:

• Attendance Register Repo

• Muster Roll Repo

• Workflow Repo

1. Screens

• Muster Inbox Screen

• Muster Roll View and Edit Table

Overview

This module helps in logging the attendance of each individual in a register and creating the muster roll for a particular week.

ROLE: ORG_ADMIN

This module has 2 associated screens: View Register Inbox Track Attendance Table Screen

MDMS Configurations

User Actions

This page involves several actions:

1. The CBO Admin selects a date range using the Date Picker.

2. Upon selecting a date, the entire week is automatically chosen.

3. After selecting the week, by clicking "Apply," the pre-saved attendance log for that week becomes visible.

4. The user can then modify the attendance log for each individual and save it as a draft using the "Save as Draft" button.

5. The user can also submit the muster roll. Upon submission, the user will be prompted to enter skills for each individual.

6. After entering skills, the user can submit the muster roll for that specific week.

Validations:

• If no date range is selected or cleared, attempting to use the "Save as Draft" button will display an error, prompting the user to select a date range.

• The ability to submit the muster roll depends on the CBOMusterSubmission MDMS Config.

isEndOfWeek && selectedDateRange!.endDate > DateTime.now().millisecondsSinceEpoch


code": "END_OF_WEEK",            "value": "end of week",            "active": false

Depending on the value of END_OF_WEEK:

1. If END_OF_WEEK is false, users can create the muster roll on any day of the week.

2. If END_OF_WEEK is true, users can submit the muster roll only on or after the last day of the week (Sunday).

If an existing muster roll for the selected range is in a workflow state, the Track Attendance page will be a view-only page. Otherwise, users will be able to log attendance and submit the muster roll.

The options for marking attendance are determined by the Attendance Hours list:

• If the list contains two options, users can mark attendance as Full Day or Absent.

• If the list has more than two options, users can mark attendance as Full Day, Half Day, or Absent.

API Details

Sidebar Configuration

<details>

DIGIT Components & Custom Components Used

Localization Configuration & Modules

Reference Files/Links

1. Blocs:

   • Search Registers

   • Search Individual Register

   • Attendance Create Log Bloc

   • Muster Search With From and To Date Bloc

   • Get Muster Roll Workflow Bloc

   • Muster Get Attendance Log Bloc

   • Create and Update Muster Roll Bloc

2. Models:

   • Attendance register Model

   • Estimate Muster Roll Model

   • Search Muster Roll Model

   • Muster Workflow model

3. Repositories:

   • Attendance Register Repo

   • Muster Roll Repo

   • Workflow Repo

4. Screens:

   • Register Inbox Screen

   • Track Attendance Screen

Find below the module-wise required MDMS data -

This module helps in creating an organization which are business functions that work with ULB to execute projects. These can be typical contractors, SHGs or material vendors. All of them are registered under the same Organization Master.

This module has 4 associated screens :

1. Create

2. Search

3. View

4. Modify

MDMS Configurations

MDMS Configurations

Module enablement configuration

1. Set module code as “Masters” in Module.js for Masters (Organization) Module. Refer CityModule.json

 {
            "module": "Masters",
            "code": "Masters",
            "active": true,
            "order": 6,
            "tenants": [
                {
                    "code": "pg.cityb"
                },
                {
                    "code": "pg.cityc"
                },
                {
                    "code": "pg.citya"
                }
            ]
     }

1. Enable Module in App.js. Update the object ‘enabledModules’. Use the code “Masters”. This code should match with the code of the cityModule.json, mentioned above.

Role-action mapping

Sidebar configuration

Screen configuration

Localization Configuration and Modules

Workflow Configuration

NA

Customization

1. Custom Components used

TransferCodeTable -

• This component is a common component used to show Tax identifiers and Transfer Codes input options in the ‘Financial Details’ section in Create screen

• Dropdown options for tax identifiers and transfer codes are populated by MDMS data

• Used can select type via dropdown and value needs to be entered for the corresponding type

• Users can add and delete rows for tax identifiers since there can be multiple identifiers. First row won't be deleted.

• Refer Component: TransferCodeComponent