Dependencies

To verify the ids of the individuals, the attendance service depends on Individual Registry. It is an optional dependency. If the no individual registry is linked with the attendance service, then the ids would not be checked for validity and assumed to be correct.

Features & Scope

Attendance Service manages the following:

1. Attendance-Register: It maintains a list of individuals enrolled for a given register.

   1. Staff: Staff members manage the register. Staff can be created or deleted from a register.

   2. Attendee: Attendees are the individuals participating in the register. Attendees can be created or deleted from the register.

2. Attendance-Log: The log entries of the attendance. It will have events of entry and exit.

Muster-Roll is a report built upon the attendance logs. It has computed attendance values. It will pass through an approval workflow.

Use Cases

Mockups

Functional Requirements

Use Cases

Mockups

Deployment

Configuration

Integration

The platform design provides the capability to integrate smart payments with iFIX. The integration enables departments to track project milestones and simplify vendor payments. The multi-layer architecture design ensures transparency, visibility and fast decisions all of which translate to an accelerated pace of development. The registries and APIs ensure information flows seamlessly across channels removing the challenges of siloed data structures and facilitating interoperability.

Click on the page link below to learn more about our platform architecture.

API Contract Link

The API specification is available here. To view it in the Swagger editor, click below.

Data Model

DB Schema Diagram

Web Sequence Diagrams

TBD

Persister

Bank account service persister

Indexer

No indexer has been configured for this service.

Raw API spec resides here.

API Contract

Click below to view the specs in the Swagger editor.

Data Model

DB Schema

Sequence Diagrams

To be added.

User Persona 3: Executive Officer

User Persona 4: President, Self-help Group

Key Functionalities

• Provides create/update/search operations for organisation entities.

• Captures organisation details, contact details and classifications.

• Links organisations to functional areas they are operational in.

Code

Organisation

Deployment

Helm chart

Master Data

OrgType - Defines types of organisations

OrgFunctionCategory - The functional area where an organisation works

OrgFunctionClass - The class (rating) of an organisation in a specific functional area.

OrgTaxIdentifier - The list of tax identifiers that can be entered.

OrgTransferCode - The bank account transfer code (IFSC etc..). This is usually the only one defined in the master data. Can be customised for other countries.

Integration

API spec

Organisation postman collection

Idgen

Persister

Indexer

Workflow

User

Attendance

Code

Module code

Helm charts

Integration

Base path: /muster-roll

API spec

Postman Collection

Steps to run the postman collection:

1. Import the postman collection for Muster Roll.

2. Import the environment variables required for running the postman collection which will create an environment ‘Muster Environment’.

3. MusterRoll requires the below services from Attendance Service API to be run prior to creating muster. So run the below services before running the musterRoll postman collection.

a) create Attendance register - https://<server>/attendance/v1/_create

b) Attendee enroll - https://<server>/attendance/attendee/v1/_create

c) Attendance log create - https://<server>/attendance/log/v1/_create

4. Update the current value of the variable ‘registerId’ in the ‘Muster Environment’ with the id returned by the response of the create attendance register ( in step 3 a)

5. Run the ‘Muster Roll Service’ postman collection as ‘Run Collection’ . It will run the /_estimate, /_create, /_update and /_search APIs success and validation error scenarios.

6. Muster will be created for the attendees enrolled in the attendance register (in step 3 b) using the attendance logs created (in step 3 c).

The current value of environment variables ‘musterRollId’ and ‘musterRollNumber’ will be set from the response of the /_create muster roll which will be used by /_update and /_search APIs.

Measurement Book Registry

MDMS

Non-functional changes

• Added contact details encryption in organisation service

• Removed Tenant ID splitting from all the services and added modules in master-config.json

• Expense service & calculator to read effectiveFrom and effectiveTo dates from master data and pick rates accordingly

• Updated attendance service query while the changing CBO

New ‌Feature Additions

Known Issues

The list below are known issues that need to be addressed as part of the platform roadmap:

• Multiple measurements can not be created at the same time for one contract.

• Integrated error queue implementation for all services along with the necessary measures for addressing issues, is required. In situations of unrecoverable failures, this setup will provide a means to trigger prompt alerts and implement corrective actions.

• Establishing alert mechanisms for critical errors, particularly in the context of billing, is required.

• Managing offline & low connectivity use cases as a best practice.

• Improved logging across services to help troubleshoot.

• The expense service should include the workflow as part of the payload and push it into the Kafka topic for persistence.

• Separate SMS-related localization from all services and migrate it to a dedicated service.

• Performance testing and benchmarking of services.

• Security audit.

• Multiple mdms-v2 calls in services, because mdms-v2 was returning only one master's response.

• Code refactoring of works-services like

  • Remove unused models

  • Change package names

  • Remove duplicate validation logic

Document Resources and Links

Technical Documents

Service Documents

MUKTASoft is a customisation of the basic Works platform. Not all base Works platform features need to be utilised as a part of this solution. The configuration is MUKTA-specific. UI screens will also be MUKTA-specific. Refer to the UI and service configuration sections for details.

MUKTASoft is a work in progress currently with a release targeted in H1 of 2023. Here's a sneak preview of the product demonstrating how daily wage seeker payments are made faster and more efficiently through the use of MUKTA. The demos also show wage seekers receiving SMS notifications on receipt of payment in their bank account.

Browse the explainer video (long version) showing payments made to wage seekers and receipt of SMS notifications by wage seekers on the credit of wages.

Important Links

Find the important Mukta-specific program resources below:

• Release Notes

• User Stories

• Master Data Templates

• UI Configuration

• Creating, updating, and searching for a project

• Adding staff, tasks, resources and facilities to a project

Code

Module code

Deployment in Works

Integration

API Spec

Base path: /project/

Documentation for this service is available here.

Postman Collection

Click here to access the Postman collection used to test APIs. Import the link into Postman and follow the instructions to run the collection.

Master Data

The following primary masters are defined by this module and used for validations. Other common masters such as department, tenant etc..are also used by this module.

• DIGIT backbone services

• Persister

• Indexer

• IDGen

• MDMS

• FileStore

Functionality

This service provides APIs to create, update and search for measurement registries. Refer to the functional specifications here.

Deployment

The below variables should be configured for the measurement registry in the Helm environment file before deployment. The Helm environment file will be located under:

https://github.com/{{ORG}}/DIGIT-DevOps/deploy-as-code/helm/environments/{{EnvironmentFile}}.yaml

Refer to the sample here.

• Add db-host,db-name,db-url,domain and all the digit core platform services configurations (Idgen, workflow,user etc.) in the YAML file.

• Add the ‘egov-mdms-service’ related configuration to the respective environment YAML file. Change the gitsync.branch name.

• Check the measurement-registry persister file is added to the egov-persister.perister-yml-path variable. If not, add the way it's done here.

• Make sure to add the DB (Postgres and flyway) username & password in the respective environment secret yaml file. Follow the steps .

• Make sure to add the DIGIT core services-related secrets configured in the respective environment secret file. Follow the steps .

Configuration

Configure ID Generation

Ensure the id format is configured in the ‘IdFormat.json’ file of the ‘common-masters’ module. The sample is available here.

Configure Persister

Make sure that the file measurement-registry-persister.yml is present in the configs repository in the below location.

https://github.com/<YOUR ORGANISATION>/configs/tree/UNIFIED-DEV/works/egov-persister

In case it is not available, make sure to add the persister YML file.

Role: CBO ADMIN

Details

1. My Works lists all the work orders assigned to logged-in CBO and are segregated by In Progress and Completed works.

2. Time extension requests can be created only for Work Orders for which at least one muster roll is created and approved.

3. Time extension requests can be created only for those Work Orders for which a Project Closure request is not created.

4. The action menu Request Time Extension option is available only when the above-mentioned conditions are met.

My Works

Each work order card will have the below attributes displayed:

1. Work order number

2. Project description

3. Role of CBO

4. Officer-in-charge

5. Issue Date

6. Due Date

7. Work order amount

8. Status

9. View Details - Link to view the complete details of the work order.

10. Request Time Extension - Action button [This action is shown only when at least one muster roll is submitted and approved].

On Create Time Extension Request,

1. A window to capture the requested extension for the completion period in days is displayed.

2. CBO enters the details below and submits the request.

   • Extension Period (in days) - Mandatory

   • Reason for Extension - Mandatory

Validations

On Request Time Extension - In case the first muster roll is pending to submit for approval.

Not even a single muster roll has been approved for the project. Ensure that the first muster roll is submitted for approval.

Configurations

Not applicable.

Actions

On submit,

1. A time extension request is created and sent for verification/ approval.

2. The Request ID is generated as per the specified format. ID: TE/2022-23/000021.

Notifications

Not applicable.

User Interface

Acceptance Criteria

1. On successful submission, the success page is displayed.

2. On failure, a common failure page is displayed.

3. The request ID is generated as per the specified format.

1. Inbox page for employees to be developed duly taking care of the MUKTA branding aspect.

Attributes

The inbox of employees is divided into 4 sections.

Menu Title

1. Product Name

2. Menu Links

   • Create Work Order - It will take the user to the search estimate page.

   • Search Work Order - It will take the user to search work order.

Search Parameters

1. Work order number

2. Project ID

3. Project type

Filters

1. Assigned to me - It displays the work orders in the inbox which are assigned to the logged-in user.

2. Assigned to all - Selected by default, It displays the work orders in the inbox which are pending for action of role(s) logged-in users have.

3. Ward - Multi-select

4. Locality - Multi-select

5. Workflow state - state of the workflow of the work order.

Result Display Area

1. Work order number

2. Project name

3. CBO name

4. Assignee

5. Workflow state

6. Work Order Amount

7. SLA days remaining

It should be a DIGIT standard Inbox that allows to configure based on a request from the implementation.

Validations

Not applicable.

Configurations

Not applicable.

Actions

Menu links and Search, Filter apply and Numbers h.yperlinks.

Notifications

Not applicable.

User Interface

DIGIT-Works

Acceptance Criteria

1. Master (Reference) Data

This part includes various classifications of master data used in the Works platform. Some examples of this master data include:

• Organisation Class

• Organisation Functional Area

• Organisation Type

• Department

• Nature of Work

• Wage Seeker Skills

• Labour Charges

• Overheads

• Headcodes

• Applicable Charges

• Mode of Entrustment

• Beneficiary Type

• Designations

• Hierarchical Masters like Type of Work, Sub-type of Work

• Location (which is the same as DIGIT)

2. Works Registries

This part comprises various registries that store information related to the Works platform. Some of the key registries are:

• Individual Registry: Stores details of individual citizens, whether or not they are DIGIT system users. In cases where login access is required, user accounts are created and stored separately in the User registry. This allows for a clear distinction between citizen data and user management within the system.

• Organisation Registry: Holds details of different types of organisations, their functional areas, and classes.

• Bank Accounts Registry: Stores bank account details securely for online payments.

Works Services

This part includes domain-specific services (listed below) developed or planned for the Works platform.

• Project

• Estimate

• Contracts

• Attendance

• JIT Adapter (on the roadmap)

• Milestones (on the roadmap)

• Payment Calendar (on the roadmap)

• (on the roadmap)

3. Reused/Enhanced DIGIT Services

This part lists the core services from DIGIT that are reused or enhanced in the Works Project. Some of these as-is reused DIGIT core services include:

• Master Data Management Service (MDMS)

• Location Service

• User Service

• Access Control Service

• Inbox Service

This architectural design ensures seamless data flow across multiple departments and provides a foundation for efficient and integrated operations within the Works Management System.

Config Changes

Infra Changes

Read on to learn more about the features and capabilities supported by Works.

Estimation

• Once the project is decided, the first step is to estimate the cost of the project.

• The estimation includes multiple steps.

  1. Estimate Proposal:

     • The Estimate proposal is for getting the in-principal approval for the project. If approved, the concerned engineer can start to make detailed estimates for the project.

     • The estimate proposal contains high-level details like the name of the project, a brief description, a few line items that constitute the project and the multiple budget heads to finance the project.

  2. Detail Estimate:

     • A detailed Estimate is prepared mostly after the estimate proposal is approved. (In most cases, these start simultaneously, as the concerned engineer would already know the chances for approvals).

     • A detailed Estimate is generally prepared using offline tools supporting advanced functionalities and methods of doing scope estimation. For example, in the case of Civil Projects, an estimation tool/process already has Plinth Area Estimate, Service Unit Method, Floor Area Method, Carpet Area Method, Typical Bay Method, and Cost Comparison Method. It is possible to do a very detailed analysis using these inputs.

  3. Abstract Estimate:

     • An abstract estimate is a grouping and summary of the bill of quantities that evolved from a detailed estimation process.

     • The concerned engineer enters the abstract estimate details into WMS. This goes through an approval process with necessary stakeholders and departments depending on the nature of the work and the estimated cost.

  4. Sub Estimate:

     • An Estimate is sometimes divided into Sub Estimates (For large or multi-location projects etc) for better management purposes.

     • Sub-Estimates are later grouped into work packages for an easy tendering process.

  5. Spill Over Estimate:

     • For a project that spreads into multiple financial years, a spillover estimate is created for that year. Hence no new request for assetisation is needed.

  6. Revised Estimate:

     • Under circumstances where the scope & finances of the project go beyond the estimated amount and the set buffer, a revised estimate needs to be created and moved through the approval process.

Tendering

1. Work Packages created from Estimates/Sub Estimates, essentially comprise the scope & bill of quantities that provide contractors with enough information to bid for the contract.

   • Authorities Draft Tender Papers (DTP) using Work Packages.

2. Bids are invited from contractors between set dates. There is also a negotiation process that happens on the bid amount. The contractor with the lowest bid is selected.

3. The Authority issues a Letter of Intent (LOI) to enter into a contract with the contractor.

   • The contractor issues a Letter of Acceptance in response to the LOI.

Contracting

1. A Work Order is then created and shared with the contractor.

   • A work order is a detailed document that contains Scope, Bill of Quantities, Timelines, Terms and Conditions, Details of Contractor, Liability Periods, Other Documents etc.

2. A Work order also goes through the approval process.

Measurement

1. Before the measurement starts, there are certain offline checks required. For example, acceptance letter issued to date, letter acknowledgement date, work order acknowledgement, signed site handover date, work commenced date etc.

2. Measurement is essentially of two types.

   • Tracking Milestones:

     • Milestones are set up during the contracting phase and before the project starts. These milestones describe the timeline for each phase and the percentage of work that will be completed in various stages.

     • As a milestone is reached, the completion status can be tracked on the WMS.

     • All milestones should be in the completed stage to process the final contractor bill.

   • Tracking Measurement Book:

     • MBook is also set up for detailed project tracking. MBook measurements are derived from abstract estimates and track the day-day progress of completed work.

     • MBook measurements can be entered by the vendor and verified by employees or can be entered by ground inspectors/ field staff on a regular basis.

Contractor Bill Payments

1. As the project progresses, the contractor raises the invoice for which bills are created by the employee in the system under specific budget heads and sent for approval

2. Approved bills are sent to the finance department for disbursement.

   • Advance Bill:

     • Bill that is raised before the commencement of work. For example, to buy construction materials or to procure labour.

   • Part Bill:

     • Bills that are raised during the course of work.

     • In an ideal scenario, these bills are tightly coupled with the amount of work that is done (MBook measurements)

   • Final Bill:

     • The last bill that is raised before completing the project.

Project Closure

Closing the project is a set of activities/checklists (prospective list given below) that are run to ensure all requirements are fulfilled.

1. Assetisation request raised

2. Final bill approved

3. Site inspection done

4. Site handover done

5. Contractor feedback submitted etc

Reports & Dashboards

Reports and Dashboards give employees views and ways to analyze project performance within their jurisdiction. This also includes timelines, delays, risks, projections etc.

1. Some of the reports are

   • Work progress register

   • Estimate appropriation register

   • Estimate abstract report by the department

   • Contractor bill report

   • Works utilisation report

   • Retention money recovery register

2. Each report will be made available to be downloaded in PDF as well as Excel.

DSS dashboard will also be included.

Master Records

Many master records are required for the smooth functioning of WMS.

Some of these are listed below:

1. Contractor Class Master

2. Bank Master

3. Department Master

4. Department Category Master

5. Contractor Master

6. Election Ward Master

7. Location Master

8. Work Category Master

9. Beneficiary Master

10. Nature of Work Master

11. Type of Work Master

12. Sub-Type of Work Master

13. Recommended Mode of Entrustment Master

14. Fund Master Master

15. Function Master

16. Budget Head Master

17. Scheme Master

18. Sub-Scheme Master

19. Designations Master

20. User Master

Find the detailed process flow illustrating the steps in Works within various value bundles is given below. Refer to the colour legend on top of the attached diagram for a better understanding.

Deploying a service encompasses three key aspects:

1. Service Image Deployment: This entails deploying a published Docker image of the service within the DIGIT environment.

2. Helm Charts Requirement: Helm charts play a crucial role in service deployment as they configure environment variables tailored to the specific Kubernetes cluster. You can deploy a service either through CI/CD pipelines or directly by utilizing Helm commands from your system. All helm charts for MUKTA services are available in this repository.

3. Service Configuration: To ensure the service functions seamlessly, it is essential to configure it correctly. This includes setting up MDMS, IDGen, Workflow, and other masters as necessary, all of which can be done on GitHub.

In summary, deploying a service involves these three fundamental steps, each contributing to the successful deployment and operation of the service within the DIGIT environment.

MDMS Role Action Configuration

Click here to find detailed information on MDMS configuration.

Each module offers specific actions (APIs), roles (actors), and role-action mappings (defining access permissions). Role-action mappings control the access and permissions for each role. Each service documentation contains the role-action table that specifies the actors authorized to access particular resources. Adhere to the structure below, substituting specific actions and roles as required for each module.

Actions, roles, and role-action mappings are organised within the master tenant and corresponding folders. These folders are conveniently named after the module, making it easy for users to identify.

Example:

In the image above, "pg" represents the state-level tenant. The highlighted orange folders contain the masters for actions, role actions, and roles.

Configure Actions

• Add all the APIs exposed by the service (refer to service for actual APIs) to the actions.json file in MDMS.

• Keep appending new entries to the bottom of the file.

• Make sure the id field is unique. The best practice is to increment the ID by one when adding a new entry. This id field will be used in the role-action mapping.

Module name: ACCESSCONTROL-ACTIONS-TEST

Master name: actions-test

Example: A sample entry is given below:

Configure Roles

Configure roles based on the details given in the roles column (refer to service documentation) in the roles.json file. Make sure the role does not exist already. Append new roles to the bottom of the file.

Module name: ACCESSCONTROL-ROLES

Master name: roles

Example: A sample entry is given below:

Configure Role Action

Role-action mapping should be configured as per the role-action table defined. Add new entries to the bottom of the roleactions.json file.

Identify the action ID (from the actions.json file) and map roles to that ID. If multiple roles are mapped to an API, then each of them becomes a unique entry in the roleactions.json file.

Module name: ACCESSCONTROL-ROLEACTIONS

Master name: roleactions.json

Example: A sample set of role-action entries is shown in the code block below. Each of the actionid fields should match a corresponding API in the actions.json file.

In the example below, the ESTIMATE_CREATOR is given access to API actionid 9. This maps to the estimate created API in our repository.

Persister Configuration

Each service has a persister.yaml file which needs to be stored in the configs repository. The actual file will be mentioned in the service documentation.

Add this YAML file to the configs repository if not present already.

Fund Allocation Register

Reports → Fund Allocation Register

Actors

Employee

Role: Fund Allocation View

Details

1. Virtual Allotment Details (VA) is the API to fetch the fund allocation details.

2. MUKTA as a scheme has multiple HOAs for which fund is sanctioned and allocated.

3. Fund Allocation Register has to be developed to see and download the details.

4. For Request/ Response parameters, please refer to the integration approach document.

5. This data is stored and maintained at MUKTASoft for every financial year and used for reporting and reference purposes.

6. APIs will be triggered daily at 10 PM.

Search Parameters

Search Result

Validations

1. While fetching the details, from date should be taken care of properly.

2. The records/transactions are sorted in chronological order.

Configurations

Master Data

The master data that needs to be configured.

1. Special Spending Unit

   • SSU ID

   • SSU Name

   • Grantee Code

   • DDO Code

   • Tenant ID

2. Head of Accounts

   • Code

   • Name

• 221705789358641045908 (MUKTA - SC Component)

• 221705800358641045908 (MUKTA - General Component)

• 221705796358641045908 (MUKTA - ST Component)

Attachments

Not applicable.

Workflow

Not applicable.

Actions

Search - Fetch and display the records based on the search parameters.

Clear - Clear the search parameters.

Download - The option to download the report into PDF format is provided as per the attached format.

Notifications

Not applicable

User Interface

Acceptance Criteria

1. Data fetched is stored for reporting and reference purposes.

2. The report is developed with the option to download it into PDF.

Payment Instruction

Search Payment Instruction to Generate Revised PI

Actors

Employee

Role: Accountant

Home Page > Payment Instructions > Search Payment Instruction

Details

1. Search Payment Instruction to be provided to list all the PIs which have the failed transaction and the revised PI to be generated for them.

2. Two types of searched to provided with 2 different tabs.

   1. Pending for Action

   2. Open Search

3. Below are the search parameters to search such payment instructions.

Search Logic

1. “Pending for Action” tab is displayed by default with the search result of PIs which are pending for action. It means.

   1. The payment instructions which have the status Completed, Declined, and Pending.

   2. Additional condition for Completed PI, It should have at least one beneficiary payment status as Payment Failed .

2. Open Search, it will allow users to search any payment instruction and view the details.

   1. In this case, at least one parameter is must to search.

   2. For name, fuzzy search is enabled.

   3. Created from and To are considered as one parameters as date range.

Search Result

Validations

Not applicable

Configurations

Master Data

Not applicable.

Attachments

Not applicable.

Workflow

Not applicable.

Actions

Not applicable.

Notifications

Not applicable

User Interface

Acceptance Criteria

1. Search enables users to see the pending correction PI by default.

2. Search for any PI is also provided to search and view the details.

Details

1. Search Project action has to be configurable and allow mapping with a role on demand.

2. Search Project is provided to allow the users to search Work and view its details/ create estimates.

Search Criteria

Search Result

1. The search result is shown as given below.

2. Pagination is displayed to handle the big result set. 10 records are displayed per page.

3. The option to download the result set in Excel/ PDF is provided.

Validations

All the actions are displayed based on role action mapping and the user role assignment.

Actions

1. Search - It will perform the search based on the values supplied for search parameters and the logic defined.

2. Clear Search - It will clear the values filled for searched parameters.

3. Project ID - It will take the user to the View Project Details Page.