1 of 50

Platform

Release Notes

New release features, enhancements, and fixes

Release Summary

DIGIT-Works release v0.1 is a new release that offers new platform features and functions, the details of which are provided below.

Functional changes

Projects - Create a Project, Modify a Project, View a Project & Search a Project
Estimates - Create an Estimate, Modify an Estimate, View an Estimate & Search an Estimate
Contract - Create a Contract, Modify a Contract, View a Contract & Search for a Contract
Organisation - Create an Organisation, Modify an Organisation, View an Organisation & Search for an Organisation
Attendance - Create an Attendance Register, Modify an Attendance Register, View an Attendance Register & Search an Attendance Register
Muster roll - Create a Muster roll, Update a Muster roll
Expense (Bill) - Create a Wage Bill, Purchase Bill, Supervision Bill, Modify a Wage Bill, Purchase Bill, supervision Bill
Individual - Create an Individual, Modify an Individual, View an Individual & Search an Individual.
Bank account - Create a Bank account, Modify a Bank account, View a Bank account & Search a Bank account.

Non-functional changes

New ‌Feature Additions

Enhancements

It is a fresh development and getting released for the first time.

Known Issues

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

The payment status of bills needs to be updatable after offline processing.
Integration with error queue implementation for all services and requisite measures to fix them need to be in place. In case of unrecoverable failures, this will provide a way to alert and institute measures to resolve.
Alert mechanisms when critical errors occur need to be in place, especially with billing.
Offline & low connectivity use cases need to be handled as a best practice.
Improved logging across services to help troubleshoot
Attendance service and muster roll are to be made configurable by adding a unit of measurement.
Performance testing and benchmarking of services.
Security audit.

Document Resources and Links

Technical Documents

Backend Service Documents

MDMS & Configuration Updates

MDMS Changes

Feature

Service Name

Changes

Description

Config Changes

Infra Changes

Test cases

Platform Capabilities

Works Overview

A Works Management System (WMS) typically is used by various departments in the government to track end to end lifecycle of a project (scope and finances).

The input to Works could be a decision that is taken in the legislature for the construction of new capital works or demand that is generated from within society or officers, for maintenance of existing projects.

Construction of new metro rail is of nature capital works (New Works)
Repair of existing roads is of nature operations and maintenance (O&M)

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

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.
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.
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

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.
A Work order also goes through the approval process.

Measurement

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.
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

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
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.

Assetisation request raised
Final bill approved
Site inspection done
Site handover done
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.

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
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:

Contractor Class Master
Bank Master
Department Master
Department Category Master
Contractor Master
Election Ward Master
Location Master
Work Category Master
Beneficiary Master
Nature of Work Master
Type of Work Master
Sub-Type of Work Master
Recommended Mode of Entrustment Master
Fund Master Master
Function Master
Budget Head Master
Scheme Master
Sub-Scheme Master
Designations Master
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.

Architecture

Works platform design principles, approach and rationale

Principles

The Works platform design approach is based on the principles of interoperability, open, standards-based, real-time, inclusivity, a single source of truth, security and privacy. The principles define the framework for a scalable and reliable platform that adapts to evolving needs. Read more about the platform design principles here.

Works aim to expedite payments for public works projects undertaken by different departments. The platform registries and APIs ensure units have instant access to trusted information that improves coordination between the various departments. The seamless flow of information ensures payments are fast-tracked, projects are managed better, and departments can execute more work.

Approach

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.

High Level Design

The platform architecture illustration below provides a visual representation of the key components and layers that facilitate a seamless flow of information across multiple departments.

The high-level design (refer image above) of the Works System can be divided into three parts:

Master(Reference) Data
Works Registries(Services)
Reused/Enhanced DIGIT Core Services

Master (Reference) Data

Below are classifications of some of the master data used in the Works platform. For a comprehensive list, please refer to the service documentation

DIGIT Core service masters are not covered below.

Simple Masters:
- 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
- Type of work
- Sub-type of work
Location - Same as DIGIT

Works Registries

Individual - stores details of individual citizens. Individuals may or may not be users of the DIGIT system. If they need login access, they will be created in the User registry.
Organisation - This registry holds details of all types of organisations, their functional areas and class.
Bank Accounts - This registry stores bank account details to be used for online payments in a safe and secure manner.

Works Services

The following domain services have been developed/are being planned as part of the Works platform:

Project
Estimate
Contracts
Attendance
Muster roll
Expense/Billing
JIT Adapter (Roadmap)
Milestones (roadmap)
Payment Calendar (roadmap)
Measurement Book (roadmap)

Reused/Enhanced DIGIT Services

The following list consists of major core services from DIGIT that will be reused in Works Project. A few of the common core services might have been missed from the list.

As-is Reused DIGIT Services
1. Master Data Management Service(MDMS)
2. Location Service
3. User Service
4. Access Control Service
5. Zuul API Gateway
6. PDF Service
7. File Store Service
8. IdGen Service
9. Persister
10. Indexer
11. Inbox Service
12. Report Service

Low Level Design

Registries

The Works platform hosts the below registries:

- contains a detailed description of a citizen/individual who may/may not interact directly with the DIGIT platform but is a beneficiary.
- contains the organisation details.
- contains tenant/organisation bank account details.

Individual

Overview

The Individual service is an enhanced version of the User service that houses data about individuals. The Individual service is being re-used from the mission.

Click to access details on the Individual Service.

Bank Account

API Specifications

Base path: /bankaccount-service/bankaccounts/

API Contract Link

API specification is available . To view in Swagger editor, click below.

Data Model

DB Schema Diagram

Web Sequence Diagrams

TBD

Persister

Indexer

No indexer has been configured for this service.

Organisation

API Specification

Base Path: /org-services/organisation

Raw API spec resides . To view in the Swagger editor, click below:

DB Schema

Sequence Diagrams

To be added.

Platform Capabilities

Works Overview

A Works Management System (WMS) typically is used by various departments in the government to track end to end lifecycle of a project (scope and finances).

Construction of new metro rail is of nature capital works (New Works)
Repair of existing roads is of nature operations and maintenance (O&M)

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

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.
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.
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

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.
A Work order also goes through the approval process.

Measurement

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.
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

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
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.

Assetisation request raised
Final bill approved
Site inspection done
Site handover done
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.

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
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:

Contractor Class Master
Bank Master
Department Master
Department Category Master
Contractor Master
Election Ward Master
Location Master
Work Category Master
Beneficiary Master
Nature of Work Master
Type of Work Master
Sub-Type of Work Master
Recommended Mode of Entrustment Master
Fund Master Master
Function Master
Budget Head Master
Scheme Master
Sub-Scheme Master
Designations Master
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.

Expenditure / Billing

Background/Context

In a government setting -

Payments are generally made TO and BY the government. In this document, we will refer to payments made by the government as expenses and payments received by the end party as receipts.
Payments made TO the government, ie. Receipt/Revenue to the government can be of two types
1. Demand based collection
  1. First, a demand is generated by the government
    Ex. Demand for Property Tax, Trade license, Water tax etc
  2. Second, An invoice is issued by the government with these demand details for what is owed to the government either as taxes/charges/levies etc.
  3. Third, Citizen acknowledges and pays the respective amount.
  4. Fourth, a receipt is issued against the paid amount.
2. Non Demand based Collection

There is also another type where collections are made without any demand being generated.

DIGIT has this demand & Billing service to accommodate payments made to governments.
1. For payments made BY the governments
  1. Ex - Salaries, Wages, Payments to beneficiaries, Contractors, Ad hoc payments

Approach

For any transaction to happen, there is a payer, payee, amount and entity details
1. Payer and Payee can be individuals or organizations.
2. Entity details contain other information which are important for a bill to be generated but not mandatory for payment advice
  1. Ex. Invoice ID, Invoice date, Verification details etc
Every transaction will ideally start with an invoice equivalent that is generated by the supplier/contractor/muster/contract/payroll etc against which a payee will generate a bill on the name of the payer.
1. A Bill can have single or multiple beneficiaries. It should depend on the source of verifiable information.
  1. Ex. If a muster roll has 20 beneficiaries, Bill also can have 20 beneficiaries. It is not needed to create 20 individual bills.
2. At the same time, A single invoice should not be divided into multiple bills.
  1. Ex. Even though material is supplied in tranches, a single PO can lead to multiple invoices and only after the consumption of entire material as per individual invoice and associated measurement book, Bill for that invoiced amount can be created and paid.
A Payment advice is required to be generated to enable beneficiary payments, module is to be integrated with a payment gateway
1. Hence a payment advice will contain minimal information that is required for bank/gateway to make the payment.
2. Limits on number of beneficiaries and amounts etc to be configurable as will needed by the integration.

Expenditure module

Expenses are created by the JE and approved by ME, EE/ EO depending on amount and associated approval authority.
This module should have the following components
1. Header Details
  1. Bill ID
  2. Bill Date
  3. Party Bill ID
  4. Party Bill Date
  5. Bill Type
    Salary/Pension Bill
    Based on Payroll, leaves, PF, GPF, other allowances
    Advance Bill
    Unlike other bills which are post work/service completion and measurement, advance bill is raised prior and adjusted later.
    Advance bill is horizontal and be applicable on top of all other bill types
    Works/Contractor Bill
    A contractor bill is created and measured against the measurement books and contract(work order) objects for verification.
    When a user selected to pay a contractor bill, user can select against which measurement books of the contract this bill is being raised for, and accordingly bill amount will be calculated.
    Muster/Labour Bill -
    A labour bill is created from muster roll and usually have multiple beneficiaries within the same bill.
    When a user selects to pay a wages bill, user can select which muster rolls to process as part of this bill, and accordingly bill amount and array of beneficiaries will be processed.
    Supplier/Vendor Bill
    A vendor bill is similar to contractor bill where as here instead of measurement book and work order, an invoice and material receipt register or purchase order are used for verification.
    A vendor bill should ideally be against each individual invoice as submitted by the supplier.
    Right now, there is no material receipt register or purchase order against which invoices are verified. Hence invoice in V1, cannot be as verifiable as we are verifying wages bill against muster rolls.
    Contingency/Expense Bill
    Ad Hoc expenses
    Supervision Bill
    This type of Bill is calculated as a percentage on top of other types of approved bills.
    Others (need more usecases)
2. Debit Details
  1. {Account Code, Account head, Debit Amount}
    Treasury Payments - {Major, Sub Major, Minor, Sub Minor, Detail, Object head , Debit Amount}
    ULB Payments - {Fund, Functionary, Budget head, Scheme, Sub Scheme, Debit Amount}
  2. This should be configurable at the tenant level to choose what type of accounting system is followed.
  3. Debit details should ideally be captured at the time of project creation. This helps in budget checks being done.
  4. Each Project will be associated with a set of account codes and percentage amounts of the entire project, from where debit will happen.
  5. Similarly, respective amounts (lumpsum/percentage) should be chosen from these account codes for each bill that is created.
  6. Service should not allow to debit more than the initial quoted amount under respective heads against the sum of all the bills created for the project.
Deductions
Amount that is deducted from gross value of the bill as these are already included in the work line items
Deductions are classified into many types
1. Internal transfer
  1. Ex. SOR line items already include cess 1%. Hence it is deducted here and transferred to labour welfare account head
  2. SOR line items also include royalty on material. That needs to be deducted from here and transferred to tahsildar
2. Advance recoveries
  1. Amount paid earlier for mobilization advancement or material procurement etc are deducted while creating new bill
3. Retention Money
  1. Money is withheld for payments and paid at later date after defect liability period.
Deductions are always done against a beneficiary.
1. If a bill contains multiple beneficiaries, it needs to be specified against which beneficiary the deductions are made.
Credit Details
1. A bill can have multiple beneficiaries. But the nature of payments or beneficiary types should be same for all beneficiaries in one bill.
  1. Wage seekers bill should contain only beneficiaries for wages
  2. Materials bill should contain only vendors and be verified against their invoices

Once the bill of any type is created, this will go for approval and have wfstatus.
Every bill will also have beneficiary payment status.
1. In the absence of intergrations with Banks/IFMS, this status can be updated manually to mark beneficiary payments.
2. In the presence of integration, systems should show the status of payment.
3. Once a bill is approved, a payment advice needs to be created and send to integrated system. This system will send back success/failure status along with reasons.
Incase of payment failure, Works should allow modifying the bill, marking the changes as mentioned in the error codes and resubmit.
1. This will create a new payment advice, linking reference to earlier bill.

Link to Figma

Bill Attributes

Functional Requirements

Bill Objection reasons

Actions to resolve : Works Specifications

Expenditure service domain modeling

Budget Checks

Input to expenditure service is when a project is created and an estimate is to be approved.
1. Expenditure will query the program service to get the status on fund availability.

Budget Blocking

In case funds are available, expenditure service can also ask program service to block respective funds (from estimation) for this project.
1. Budget hence is blocked and won’t be available for next projects to consume.

Release Blocked Budget

Expenditure module should also have provision to release the pre-blocked budget. So this can be used for other projects. Or the existing project for which the budget has been blocked is deferred.

Expense Planning

Expenditure service will also have a planning module which will give timelines of expenses and respective amounts to funding agencies.
1. Blocking module also feeds into the planning module to block funds in a timely manner.

Billing management

Bills are created under contracts (projects)
A contract is issued by Payer to Payee.
1. Contract can be materials, labor, services, supervision etc
A payee inturn issues invoices against the contract on supply of material/services.
1. After successful verification of supplies and invoices, payer add bills into the finance system
2. A voucher is created in accounting system for auditing purpose
3. A payment advice is sent to bank for making financial transactions
4. Voucher and bill statues are updated once the payments are made.

Validations
1. A contract can have multiple invoices raised by the payee before the contract is deemed closed.
2. An invoice can be a material invoice, labor invoice (Muster roll), invoice for supervision charges.
3. PS: Not every time an invoice is required to generate a bill.
  1. Ex. Salary Bill, Advance bill, contingency bill etc doesn't need any invoices.
4. An invoice can have multiple line items.
  1. Incase of a restaurant bill - Restaurant captures additional GST amount on net amount. All line items are paid immediately by the service seeker.They pay the taxes collected from all invoices to respective government bodies at set intervals.
  2. Incase of a salary bill - All line items are not immediately paid to the service provider (Employee). Instead the employer deducts TDS and only pays part amount to the employee. Employer remits this amount to government body. Even the employee remits his part if the tax at regular intervals.
  3. An invoice can also have multiple beneficiaries and headwise breakfups for each beneficiary.
5. An invoice when entered into the system creates a Bill. A bill entity internally will have multiple line items each by payer, beneficiary, amount and head combination.
  1. So a muster roll with 1 payer, 3 payees, each payee having 500 rs payable and 50 rs deduction on ESI can be on 1 bill with 6 line items.
6. This bill when processed will create voucher in accounting system
7. A payment voucher however can be a combination of multiple payers and payees by line items. From above example
  1. There can be minimum of 2 payment advices one for all payables of 450 rs to each individual
  2. Other for all ESI deductions directed to ESI department.
  3. This will help payments go faster to respective departments.
8. Once the payments are made, respective bill line items will be updated with statuses. Once all bill line items are updated, overall bill will be updated with status.

Estimates

Overview

Estimates are created for each project/sub-project entity.

Need and Background:

An estimate is prepared for each Works project so as to get technically sanctioned and proceed with tendering/contract.
Estimates are created for each project/sub-project entity.
There are multiple estimate types for each project prepared with different levels of abstraction.

Estimate Type

Definition

Functional Requirements

After creating the project (and getting approved if there is a workflow) JE will start estimating the project.
To create an estimate following details are required.
- Line Items from SOR
- Non-SOR line items
- Overheads
There are 3 ways how estimates can be added.
- Manually adding from SOR Master List
- Using Estimate Template
- Copying the format of existing similar projects and changing the values
To select line items for SOR, select the SOR category, search for the SOR line item by SOR code or SOR description and select the SOR.
- To the SOR line item, add the quantity that is required for this project.
- SOR standard amount multiplied by this quantity gives the line item-wise cost.
Measurements can be captured at the SOR line item level directly by the specified UOM or length, breadth, height, quantity can be captured and stored in an empty measurement book so as to utilise it later for m book recordings.
- Multiplication of L,B,H,Q will give the required quantity of the line item for the estimate.
A non-SOR line item will not be defined in MDMS and hence will not be searchable using the SOR category or Code.
- Rate, Quantity and Description have to be entered manually.
- Just like SOR, instead of quantity directly, L,B,H,Q can also be captured.
All SOR and Non-SOR items in the way captured in the estimates will be created as empty records in the Measurement Book to capture readings later.
Overheads are predefined masters.
- The cost of the project becomes the cost of SOR and Non-SOR items plus overheads.
- Overheads are either added on top of SOR and Non-SoR separately or can be derived from SOR Sub Line items.
- Overheads amount will not be going to the contractor but will be going to specific heads defined in the Master for respective overheads. (GST 12% to GST department, Cess 1% to labour dept etc). This means Contracts will selectively capture only a few overheads for contractors.
Each estimate will have a unique ID that is generated
- ID: EST/<ULB/Department Code>/<Year>/<month>/<Date>/<running sequence number>
Status of an estimate
- Created
- In progress
- Approved
- Rejected
- Cancelled

Masters

Schedule of Rates (SOR)

SOR is a line item that represents the rate for a single unit of work. SOR is defined by the Central PWD or state PWD and is revised based on the market needs from time to time. In general, there are about 3000+ SOR line items
Each executing authority ULB/Department may modify the rates of these SORs by applying lead charges.
- Lead Masters will be varying for each project as the project site will be different for each.
- For simplicity, SORs are usually kept constant under a ULB.
Each SOR Item may have multiple variants with slight changes in description and amounts.
- Ex. Estimate of tiling for the ground floor and estimate of tiling for the first floor will change by 15 Rs to capture the carriage charges. These should be captured with .serial_number. (Parent.Child)

Analysis of Rates

Each line item of a SOR master/SOR variant will further be divided into Sub line items that come from a set of category Masters like Labour Master, Material Master, Royalty Master, Carriage Master etc.
- A group of Sub line items together will form an estimate line item.
- Each sub-line item will have Item detail 1, item detail 2, quantity, UOM, rate, estimated amount.
- The sum of all sub-line items will become the total of the SOR line item
- Item detail 1 will capture whether it is material/labour/carriage/overhead/royalty etc
- Item detail 2 will capture the exact details of the item from the respective item master. rates need to be auto-populated.
With this when extracted, we should be able to produce labour analysis, material analysis and other standard reports, coming from the estimates.

Basic Rates of Materials Master

Note: There are roughly about 200 materials and some of whose rates change quarterly.

Labour Rate Master

There are about 80 types of labour.

Lead Master

Lead Master will have the carriage and royalty details of each item that goes into the individual SOR items.

When a lead master is set on a particular material in a particular ULB, all SOR line items that contain this item will take the amount from the lead master and not from the basic rate master

Non Schedule of Rates (SOR)

Non-SOR items are not defined by CPWD and based on project requirements will get added to the estimate.
They will have the same attributes as the SOR item, but will not have a defined SOR ID or SOR category.

Ex. Purchasing Fancy benches & themed dustbins at Park. The rate, in this case, is fixed by JE upon discussing with potential vendors.

Overheads

Overheads can be of two types.

In-Line Overheads - Defined within the SOR line items
Estimate Level Overheads -
- These are defined on top of estimates. Each overhead will be defined within a time range with either percentage or lump sum value of the entire estimated cost

We should be able to abstract out similar overheads from multiple SOR line items and groups to form a single overall overhead for the estimate.

Revised Estimates

Estimate revision can happen before the final bill is submitted and the project is closed. For a revised estimate, the user can come onto the existing estimate and click actions → Revise estimate. This goes for a similar approval cycle as the main estimate.
For a revised estimate -
- New line items can be added.
- Existing line items can be removed
- Quantities in existing estimates can be modified.
A contract that is created from this estimate also needs to be revised and sent to the contractor for approval.
Measurement books accordingly will get changed as per the new estimate.
If some part of the estimate is already measured and the bill has been created/approved, a revised estimate for that line item cannot go under that approved bill quantity for that line item.

Schedule Category

A schedule category is a grouping of SORs for easy identification and filtering. There are a total of about 3000 SOR items divided into 15-20 SOR groups

Examples - Earth Work, Masonry, Brick Work, Painting, etc

Estimate Template

Templates are created for specific types and sub-types of work so they can be reused for future use.
Templates are groupings of SOR items that combine to complete a similar kind of work.
On the UI, the Estimates inbox will have an Estimate Template section and users can see a list of templates and create a new template from there, and modify the existing template.

Ex. Template to build 100 mt of 20 ft road, Template to build 8*10 sq ft standard room.

Mockups

User Acceptance Criteria

A user should be able to

Create an estimate using templates
Add SOR items from SOR Master
Change values as required for current work
Add/auto-populate overheads
Able to generate Material Analysis and Labour Analysis
Download PDFs of Labour analysis, material analysis, and Overall Estimate

Configuration

Common steps to configure platform services

Overview

This page lists common configuration steps that need to be repeatedly performed for all services. Please follow these steps in the context of each service replacing only certain values as needed. The respective service will provide you with information on what needs to be replaced.

Deploying A Service

Deploying a service involves three parts:

Deploying a published docker image of the service in the DIGIT environment
Having the Helm charts are necessary for the service deployment. Helm charts configure the environment variables for the service specific to a Kube cluster. A service can be deployed using OR directly using Helm commands from a system. All helm charts for services are .
Configuring the service
- Set up , , , other masters for the service to work properly on GitHub.

MDMS Role Action Configuration

to find detailed information on MDMS configuration.

All modules expose certain actions (APIs), roles (actors) and role-action mappings (who can access which resource). Role-action mappings are used for access control.

Each service documentation has a role-action table that identifies the actors that can access the resource. Follow the outline below replacing specific actions/roles for each module.

Actions, roles and role-action mapping are defined within a master tenant in folders. The folders have the same name as the module name for easy identification.

Example:

In the above image, "pg" is the state level tenant. The three folders highlighted in orange contain the masters for actions, roleactions and roles respectively.

Folder structures are only for categorisation and easy navigation of master files. The MDMS service retrieves data only through module and master names. Make sure that these are correct.

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. 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

In case 403s are encountered despite configuration, double check the actions.json file to make sure the API in question has a unique ID. In case of duplicate IDs, a 403 will be thrown by Zuul.

Example:

A sample entry given below:

Configure Roles

Configure roles based on 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

Assign EMPLOYEE_COMMON to all actors in the Works platform.

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 below. Each of the actionid fields needs to match a corresponding API from the actions.json file.

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

Note that the actionid and tenantId might differ from implementation to implementation.

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.

Please add that yaml file under the configs repository if not present already.

Make sure to restart MDMS and the persister service after adding the file at the above location.

Indexer Configuration

Estimate

Provides an overview of the configuration of the estimate service

Overview

The estimate service provides the functionality to create, update and search for estimates related to a Works project. An estimate is always linked to a project. For low-level technical design, please refer to this section.

Pre-requisites

The following services need to be running for the estimate service to function:

DIGIT backbone services (PostgreSQL, Elastic Search, Zuul)
Project
MDMS
Persister
Indexer
Workflow
User

Functionality

Please refer to the functional specifications for an overview of functionality provided by this service.

Deployment

Configuration

MDMS Configuration

Configure roles, actions and role-action mappings as per the table below by referring to this doc here:

Sample is here.

Persister configuration

The persister file for the service is called estimate-service.yml.

https://github.com/egovernments/works-configs/blob/DEV/egov-persister/estimate-service.yml

Follow steps here for configuring this.

Indexer configuration

Please ensure the below files are present in https://github.com/egovernments/works-configs/blob/DEV/egov-indexer/estimateservices-indexer.yml

If the above files are not present, add them in the given location and restart the ‘egov-indexer’ service in the respective environment. Before restarting the service please ensure, you have done the below configs

Note: Add this config in the respective environment YAML file in the DevOps repository and then deploy the service.

Idgen configuration

In the common-masters folder of MDMS, locate the IDFormat.json file. ID formats should be configured for the Estimate number as well as Estimate Detail objects. Make sure the following lines are added and the format modified per implementation:

{
  "tenantId": "pg",
  "moduleName": "common-masters",
  "IdFormat": [
    {
      "format": "ES/[fy:yyyy-yy]/[SEQ_ESTIMATE_NUM]",
      "idname": "estimate.number"
    },
    {
      "format": "EP/[fy:yyyy-yy]/[cy:MM]/ESTIMATE_NUM/[SEQ_ESTIMATE_DETAIL_NUM]",
      "idname": "estimate.detail.number"
    }]
}

Other masters for Estimate:

The following masters need to be configured for the Estimate service. Please make sure to use the same master name and module names:

UOM - Unit of measurement

Overheads

Workflow Configuration

The workflow configuration for Estimate is as follows. This payload needs to be called against businessService _create API for workflow configuration:

"BusinessServices": [
    {
      "tenantId": "statea",
      "businessService": "mukta-estimate",
      "business": "estimate-service",
      "businessServiceSla": 432000000,
      "states": [
	  {
          "sla": null,
          "state": null,
          "applicationStatus": "SUBMITTED",
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "SUBMIT",
              "nextState": "PENDINGFORVERIFICATION",
              "roles": [
                "ESTIMATE_CREATOR"
              ]
            }
          ]
        },
        {
          "sla": 172800000,
          "state": "PENDINGFORVERIFICATION",
          "applicationStatus": "VERIFIED",
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "VERIFYANDFORWARD",
              "nextState": "PENDINGFORTECHNICALSANCTION",
              "roles": [
                "ESTIMATE_VERIFIER"
              ]
            },
            {
              "action": "SENDBACK",
              "nextState": "PENDINGFORCORRECTION",
              "roles": [
                "ESTIMATE_VERIFIER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
				"ESTIMATE_VERIFIER"
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDINGFORTECHNICALSANCTION",
          "applicationStatus": "TECHNICALLY SANCTIONED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "TECHNICALSANCTION",
              "nextState": "PENDINGFORAPPROVAL",
              "roles": [
                "TECHNICAL_SANCTIONER"
              ]
            },
            {
              "action": "SENDBACK",
              "nextState": "PENDINGFORVERIFICATION",
              "roles": [
                "TECHNICAL_SANCTIONER"
              ]
            },
            {
              "action": "SENDBACKTOORIGINATOR",
              "nextState": "PENDINGFORCORRECTION",
              "roles": [
				"TECHNICAL_SANCTIONER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
				"TECHNICAL_SANCTIONER"
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDINGFORAPPROVAL",
          "applicationStatus": "SENT BACK",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "SENDBACK",
              "nextState": "PENDINGFORTECHNICALSANCTION",
              "roles": [
                "ESTIMATE_APPROVER"
              ]
            },
            {
              "action": "SENDBACKTOORIGINATOR",
              "nextState": "PENDINGFORCORRECTION",
              "roles": [
				"ESTIMATE_APPROVER"	
              ]
            },
            {
              "action": "APPROVE",
              "nextState": "APPROVED",
              "roles": [
                "ESTIMATE_APPROVER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
				"ESTIMATE_APPROVER"	
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDINGFORCORRECTION",
          "applicationStatus": "RE-SUBMITTED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "RE-SUBMITTED",
              "nextState": "PENDINGFORVERIFICATION",
              "roles": [
                "ESTIMATE_CREATOR"
              ]
            },
            {
              "action": "SENDBACKTOORIGINATOR",
              "nextState": "PENDINGFORCORRECTION",
              "roles": [
                "ESTIMATE_CREATOR"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "ESTIMATE_CREATOR"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "APPROVED",
          "applicationStatus": "APPROVED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "isStateUpdatable": false,
          "actions": null
        },
        {
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "REJECTED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "isStateUpdatable": false,
          "actions": null
        }
      ]
    }
  ]

Inbox Configuration

Inbox should be configured if Workflow is configured for the estimate service. If there is no workflow involved, this can be skipped.

Please add inbox-v2 configuration in a respective environment in MDMS as it has done in here. Below are the inbox configuration for the Estimate service:

https://github.com/egovernments/works-mdms-data/blob/04ddd79cefa2954d74fa5af9ba118ad29c228d59/data/pg/inbox-v2/InboxConfiguration.json#L5

https://github.com/egovernments/works-mdms-data/blob/04ddd79cefa2954d74fa5af9ba118ad29c228d59/data/pg/inbox-v2/InboxConfiguration.json#L63

Deployment

Below are the variables that should be configured well before deployment of the estimate service build image. These are configured in the DevOps repository:

Add these ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen, workflow,user etc.) in respective environments yaml file.
Add estimate-service related environment variables’ value like the way it's done in ‘dev’ environment yaml file
Add the ‘egov-mdms-service’ related configuration to the respective environment yaml file. Make sure you change the gitsync.branch name.
Check the estimate-service persister file is added in the egov-persister.perister-yml-path variable. If not, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in respective environment secret yaml file the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.

Integration

Postman scripts for Estimate are here:

Project

Steps to configure the project service

Overview

The project service provides APIs to create, update and manage a generic project. A project can have one or more of the following constructs: staff, tasks, beneficiaries and facilities. This service is shared across multiple eGov missions. The source code for this service resides here. For a deeper understanding, please refer to the following:

Low-level design

Functional specifications

Configuration Details

MDMS Configuration

roles.json

 {
      "code": "PROJECT_CREATOR",
      "name": "PROJECT CREATOR",
      "description": "Project Creator"
    },
    {
      "code": "PROJECT_VIEWER",
      "name": "PROJECT VIEWER",
      "description": "Project Viewer"
    },

Define (if not present already) and assign the EMPLOYEE_COMMON role to all project actors.

actions.json

Below are the actions or APIs exposed by the Project service used by the Works platform. Note that the "id" in the attributes needs to be unique and may be different in the implementation environment. It need not be exactly the same as what is shown below.

{
      "id": 51,
      "name": "Create Project",
      "url": "/pms/project/v1/_create",
      "parentModule": "project-management-system",
      "displayName": "Create Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },
    {
      "id": 52,
      "name": "Search Project",
      "url": "/pms/project/v1/_search",
      "parentModule": "project-management-system",
      "displayName": "Search Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },
    {
      "id": 53,
      "name": "Update Project",
      "url": "/pms/project/v1/_update",
      "parentModule": "project-management-system",
      "displayName": "Update Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },

roleactions.json

The following table shows the mapping between the APIs and the roles:

The following role-action mappings derived from the above table are configured for the Project service in the roleactions.json in MDMS. A sample is provided below. Make sure the action ID is correct and corresponds to actions.json.

{
      "id": 51,
      "name": "Create Project",
      "url": "/project/v1/_create",
      "parentModule": "project-management-system",
      "displayName": "Create Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },
    {
      "id": 52,
      "name": "Search Project",
      "url": "/project/v1/_search",
      "parentModule": "project-management-system",
      "displayName": "Search Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },
    {
      "id": 53,
      "name": "Update Project",
      "url": "/project/v1/_update",
      "parentModule": "project-management-system",
      "displayName": "Update Project",
      "orderNumber": 0,
      "enabled": false,
      "serviceCode": "project-management-system",
      "code": "null",
      "path": ""
    },

IdGen Format

Add Id Format as configured in the ‘IdFormat.json’ file of the ‘common-masters’ module here. This format is used to generate the unique ID of the project.

{
    "format": "PJ/[fy:yyyy-yy]/[cy:MM]/[SEQ_PROJECT_NUM]",
    "idname": "project.number"
}

Deployment Details

The image name of the service is available in the release charts in the DevOps repository. The service can be deployed using Helm commands.

Environment variables to be configured in the Helm chart for the service are:

Add the ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen, workflow, user etc.) in respective environments yaml file.
Add project-management-system related environment variables values. A sample from a ‘dev’ environment yaml file is provided below:
Add the ‘egov-mdms-service’ related configuration to the respective environment yaml file. Make sure you change the git-sync branch name to one that is appropriate for the environment.
Check the project management system persister file is added in the egov-persister.persister-yml-path variable. If not, please add the way it's done here.
Check the project management system indexer file is added in the egov-indexer.egov-indexer-yaml-repo-path variable. If not, please add the way it's done here.
Check the project management system persister file is added in the audit-service.persist-yml-path variable. If not, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secrets yaml file the way it's done here.
Make sure to add the DIGIT core service-related secrets that are configured in the respective environment secret file the way it's done here.

NOTE: Restart egov-mdms-service, egov-accesscontrol, egov-persister, audit-service, egov-indexer and zuul after the above changes are performed.

Integration Details

Refer to the API spec for a description of the APIs. The associated Postman scripts are provided here for reference. Use these to understand the request payloads.

Attendance

Overview

The attendance service provides generic attendance logging functionality based on "in" and "out" timestamps. IN and OUT timestamps are recorded per individual. Aggregating and calculating attendance based on these timestamps is the function of the muster roll service.

Pre-requisites

A running DIGIT platform is needed to deploy the attendance service. Specifically, the following dependencies are needed:

Individual
MDMS
Idgen
Persister
Indexer

Functionality

Provides APIs to:

Create an attendance register
Map staff to the register
Map attendees to the register
Log attendance
Edit attendance registers, staff, attendees and attendance.

Base URL:

/attendance/v1/

Deployment

Below are the variables that should be configured for the contract service in the Helm environment file prior to deployment. The Helm environment file will be located under:

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

Please refer to a sample here.

Add these ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen, workflow,user etc.) in respective environments yaml file.
Add attendance-service related environment variables’ value like the way it's done in the ‘dev’ environment yaml file.
Add the ‘egov-mdms-service’ related configuration to the respective environment yaml file. Make sure you change the gitsync.branch name.
Check the attendance-service persister file is added in the egov-persister.perister-yml-path variable. If not, please 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 the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.

Restart egov-mdms-service, egov-persister, egov-indexer, inbox, egov-workflow-v2, egov-accesscontrol and zuul services after the above changes are performed.

Configuration

Configure Actions

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

Module name: ACCESSCONTROL-ACTIONS-TEST

Master name: actions-test

Configure Roles

Configure roles based on the roles column below in roles.json file.

Module name: ACCESSCONTROL-ROLES

Master name: roles

Configure Role-Action:

Role-action mapping is configured in MDMS per the table below .

Module name: ACCESSCONTROL-ROLEACTIONS

Master name: roleactions.json

Idgen Configuration

Make sure the id format is configured in the IdFormat.json file of the common-masters module in MDMS.

Persister

Please make sure that the file attendance-service-persister.yml is present in the MDMS repository of the organisation:

https://github.com/{{ORG}}/works-configs/tree/<BRANCH>/egov-persister

Integration

Sample postman collections are here to demonstrate integration with the attendance service.

Muster Roll

Muster roll is a record of attendance and quantity of work done by wage seekers.

Overview

A muster roll is a record of attendance, wages due and the quantity of work done by labour for a specific period of time.

The attendance service provides raw attendance logs. The muster roll service aggregates attendance logs and computes attendance based on business logic. For eg., whether attendance is to be measured in hours or days, what is considered a half day or a full day of attendance etc.. is business logic that will vary between implementations. These are configurable in this service and calculations on attendance will be performed based on these configurations.

Pre-requisites

Attendance
Individual
Persister
MDMS
Workflow
Idgen
Notification

Functionality

Provides APIs to:

Estimate wages of a wage seeker based on his/her attendance logs
Create a muster roll with a list of wage seekers
Update a muster roll with modified aggregate attendance
Search for a muster roll based on some defined parameters. For more info, please see Swagger contract.

Deployment

Below are the variables that should be configured for the muster roll service in the Helm environment file prior to deployment. The Helm environment file will be located under:

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

Please refer to a sample here.

Add these ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen, workflow,user etc.) in respective environments yaml file.
Add muster-roll-service related environment variables’ value like the way it's done in the ‘dev’ environment yaml file.
Add the egov-mdms-service related configuration to the respective environment yaml file. Make sure you change the gitsync.branch name.
Check the muster-roll-service persister file is added in the egov-persister.perister-yml-path variable. If not, please 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 the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.

Configuration

Configure Actions

Add all the APIs exposed (refer to table below for actual APIs) to the actions.json file in MDMS

Module name: ACCESSCONTROL-ACTIONS-TEST

Master name: actions-test

Configure Roles

Configure roles based on the roles column below in roles.json file.

Module name: ACCESSCONTROL-ROLES

Master name: roles

Configure Role-Action:

Role-action mapping is configured in MDMS per the table below .

Module name: ACCESSCONTROL-ROLEACTIONS

Master name: roleactions.json

Other masters to be added

Other muster roll masters are configured in the common-masters folder:

MusterRoll.json

WageSeekers.json

Integration

Environment file

Postman collection

Steps to run the postman collection:

1. Import the postman collection for muster roll service into the Postman application.

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

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

a) Create Attendance register - https://{hostname}/attendance/v1/_create

b) Enroll attendees to the register - https://{{hostname}}/attendance/attendee/v1/_create

c) Attendance log create - https://{{hostname}}/attendance/log/v1/_create

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

5. Run ‘Muster Roll Service’ postman collection as ‘Run Collection’ . It will run the /_estimate, /_create, /_update and /_search api’s 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.

Contract

Detailed description of configuring the contract service

Overview

The contract service provides the functionality of a works contract.

Pre-requisites

A running DIGIT platform is needed to deploy the contract service. Specifically, the following dependencies are needed:

Estimate
Organisation
User
Workflow
IDGen
Notification
Persister
Indexer

Functionality

This service provides APIs to create, update and search for contracts. Please refer to the functional specifications for detailed scope and functionality. Low-level technical design is available here.

Deployment

Below are the variables that should be configured for the contract service in the Helm environment file prior to deployment. The Helm environment file will be located under:

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

Please refer to a 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 contract-service related environment variables’ value like the way it's done in ‘dev’ environment yaml file. Search for "contract-service" in the file.
Add the ‘egov-mdms-service’ related configuration to the respective environment yaml file. Make sure you change the gitsync.branch name.
Check the contract-service persister file is added in the egov-persister.perister-yml-path variable. If not, please 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 the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.

Restart egov-mdms-service, egov-persister, egov-indexer, inbox, egov-workflow-v2, egov-accesscontrol and zuul after the above changes are performed.

MDMS Configuration

Configure actions, roles and role-action mappings from the table below. Follow the steps here.

These have to be translated into JSON in the role-action mapping module in MDMS.

Example is here.

Other masters to be added:

The following masters are to be added as per the table below:

Idgen Configuration

Make sure the id format is configured in the ‘IdFormat.json’ file of the ‘common-masters’ module. Sample is here.

Workflow Configuration

The following Workflow JSON needs to be put in the request body of the /egov-workflow-v2/egov-wf/businessservice/_create API.

For more information on configuring workflow, please refer to the Workflow Service documentation here.

"BusinessServices": [
    {
      "tenantId": "pg",
      "businessService": "contract-approval-mukta",
      "business": "contract-service",
      "businessServiceSla": 604800000,
      "states": [
        {
          "sla": null,
          "state": null,
          "applicationStatus": null,
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "CREATE",
              "nextState": "PENDING_FOR_VERIFICATION",
              "roles": [
                "WORK_ORDER_CREATOR"
              ]
            }
          ]
        },
        {
          "sla": 172800000,
          "state": "PENDING_FOR_VERIFICATION",
          "applicationStatus": "SUBMITTED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "VERIFY_AND_FORWARD",
              "nextState": "PENDING_FOR_APPROVAL",
              "roles": [
                "WORK_ORDER_VERIFIER"
              ]
            },
            {
              "action": "SEND_BACK",
              "nextState": "PENDING_FOR_CORRECTION",
              "roles": [
                "WORK_ORDER_VERIFIER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "WORK_ORDER_VERIFIER"
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDING_FOR_APPROVAL",
          "applicationStatus": "VERIFIED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "APPROVE",
              "nextState": "APPROVED",
              "roles": [
                "WORK_ORDER_APPROVER"
              ]
            },
            {
              "action": "SEND_BACK",
              "nextState": "PENDING_FOR_VERIFICATION",
              "roles": [
                "WORK_ORDER_APPROVER"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "WORK_ORDER_APPROVER"
              ]
            },
            {
              "action": "SEND_BACK_TO_ORIGINATOR",
              "nextState": "PENDING_FOR_CORRECTION",
              "roles": [
                "WORK_ORDER_APPROVER"
              ]
            }
          ]
        },
        {
          "sla": 604800000,
          "state": "APPROVED",
          "applicationStatus": "APPROVED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "ACCEPT",
              "nextState": "ACCEPTED",
              "roles": [
                "ORG_ADMIN"
              ]
            },
            {
              "action": "DECLINE",
              "nextState": "PENDING_FOR_REASSIGNMENT",
              "roles": [
                "ORG_ADMIN"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "ORG_ADMIN"
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDING_FOR_CORRECTION",
          "applicationStatus": "SENT_BACK",
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "EDIT",
              "nextState": "PENDING_FOR_VERIFICATION",
              "roles": [
                "WORK_ORDER_CREATOR"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "WORK_ORDER_CREATOR"
              ]
            }
          ]
        },
        {
          "sla": 86400000,
          "state": "PENDING_FOR_REASSIGNMENT",
          "applicationStatus": "DECLINED",
          "docUploadRequired": false,
          "isStartState": true,
          "isTerminateState": false,
          "isStateUpdatable": true,
          "actions": [
            {
              "action": "EDIT",
              "nextState": "PENDING_FOR_VERIFICATION",
              "roles": [
                "WORK_ORDER_CREATOR"
              ]
            },
            {
              "action": "REJECT",
              "nextState": "REJECTED",
              "roles": [
                "WORK_ORDER_CREATOR"
              ]
            }
          ]
        },
        {
          "sla": null,
          "state": "ACCEPTED",
          "applicationStatus": "ACCEPTED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "isStateUpdatable": false,
          "actions": [
          ]
        },
        {
          "sla": null,
          "state": "REJECTED",
          "applicationStatus": "REJECTED",
          "docUploadRequired": false,
          "isStartState": false,
          "isTerminateState": true,
          "isStateUpdatable": false,
          "actions": [
          ]
        }
      ]
    }
  ]

Sample CURL is also included below.

Note that authToken and other requestInfo parameters should be updated as per your environment.

curl --location 'http://localhost:8020/egov-workflow-v2/egov-wf/businessservice/_update' \
--header 'Content-Type: application/json' \
--data '{
    "RequestInfo": {
    "apiId": "estimate",
    "action": "",
    "did": 1,
    "key": "",
    "msgId": "20170310130900|en_IN",
    "requesterId": "",
    "ts": 1513579888683,
    "ver": "1.0.0",
    "authToken": "{{REPLACE THIS}}",
    "userInfo": {
      "uuid": "{{REPLACE WITH VALID USER ID}}"
    }
  },
  "BusinessServices": [
        {
            "tenantId": "pg",
            "uuid": "c798a157-b494-4b61-acb9-6c5923f2fc10",
            "businessService": "mukta-estimate",
            "business": "estimate-service",
            "businessServiceSla": 432000000,
            "states": [
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "35fd0feb-319f-4af2-bfa1-faa770ec05cb",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": null,
                    "state": null,
                    "applicationStatus": null,
                    "docUploadRequired": false,
                    "isStartState": true,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "a5689bee-5d02-4311-9ad4-62959bb50e8c",
                            "tenantId": "pg",
                            "currentState": "35fd0feb-319f-4af2-bfa1-faa770ec05cb",
                            "action": "SUBMIT",
                            "nextState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "roles": [
                                "ESTIMATE_CREATOR"
                            ],
                            "active": true
                        }
                    ]
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": 172800000,
                    "state": "PENDINGFORVERIFICATION",
                    "applicationStatus": "SUBMITTED",
                    "docUploadRequired": false,
                    "isStartState": true,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "381cfe14-296f-4e03-8475-31495341a788",
                            "tenantId": "pg",
                            "currentState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "action": "VERIFYANDFORWARD",
                            "nextState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "roles": [
                                "ESTIMATE_VERIFIER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "ca298290-42db-47c0-ae1d-f2e1249cc582",
                            "tenantId": "pg",
                            "currentState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "action": "SENDBACK",
                            "nextState": "06da8fe1-1d68-4ea8-9409-217182b58846",
                            "roles": [
                                "ESTIMATE_VERIFIER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "8dcacc97-36a4-42f1-8fab-8393cb3171c8",
                            "tenantId": "pg",
                            "currentState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "action": "REJECT",
                            "nextState": "37615e97-0eba-4022-be8b-3feaf0bf4441",
                            "roles": [
                                "ESTIMATE_VERIFIER"
                            ],
                            "active": true
                        }
                    ]
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": 86400000,
                    "state": "PENDINGFORTECHNICALSANCTION",
                    "applicationStatus": "VERIFIED",
                    "docUploadRequired": false,
                    "isStartState": false,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "bf5e5d56-9662-4077-b08b-fd3a678942d2",
                            "tenantId": "pg",
                            "currentState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "action": "TECHNICALSANCTION",
                            "nextState": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                            "roles": [
                                "TECHNICAL_SANCTIONER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "bb623a34-015b-4ce2-8167-d5333b5ffbce",
                            "tenantId": "pg",
                            "currentState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "action": "SENDBACK",
                            "nextState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "roles": [
                                "TECHNICAL_SANCTIONER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "b08b8f1d-6fc6-49ab-98c2-887b90ff5d90",
                            "tenantId": "pg",
                            "currentState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "action": "SENDBACKTOORIGINATOR",
                            "nextState": "06da8fe1-1d68-4ea8-9409-217182b58846",
                            "roles": [
                                "TECHNICAL_SANCTIONER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "0dacba16-22bf-44e3-bdc9-8dc54c215cbf",
                            "tenantId": "pg",
                            "currentState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "action": "REJECT",
                            "nextState": "37615e97-0eba-4022-be8b-3feaf0bf4441",
                            "roles": [
                                "TECHNICAL_SANCTIONER"
                            ],
                            "active": true
                        }
                    ]
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": 86400000,
                    "state": "PENDINGFORAPPROVAL",
                    "applicationStatus": "TECHNICALLY SANCTIONED",
                    "docUploadRequired": false,
                    "isStartState": false,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "bbb05598-8a74-42c4-8e04-b9499c571fda",
                            "tenantId": "pg",
                            "currentState": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                            "action": "SENDBACK",
                            "nextState": "98a0383d-5367-4f1e-a4f2-82a0b7ad6b9f",
                            "roles": [
                                "ESTIMATE_APPROVER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "94d39cba-3271-4dae-b014-8eae07657bcc",
                            "tenantId": "pg",
                            "currentState": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                            "action": "SENDBACKTOORIGINATOR",
                            "nextState": "06da8fe1-1d68-4ea8-9409-217182b58846",
                            "roles": [
                                "ESTIMATE_APPROVER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "97e550ff-20eb-4fd5-85ae-e395ba9dd358",
                            "tenantId": "pg",
                            "currentState": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                            "action": "APPROVE",
                            "nextState": "fcd34bba-9f52-4de6-9a16-2a50315cfb91",
                            "roles": [
                                "ESTIMATE_APPROVER"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "eaca07c5-d361-41a2-8d77-0063a075d2f3",
                            "tenantId": "pg",
                            "currentState": "c3249e25-9d3b-4b6f-9029-8a69b0b60415",
                            "action": "REJECT",
                            "nextState": "37615e97-0eba-4022-be8b-3feaf0bf4441",
                            "roles": [
                                "ESTIMATE_APPROVER"
                            ],
                            "active": true
                        }
                    ]
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "06da8fe1-1d68-4ea8-9409-217182b58846",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": 86400000,
                    "state": "PENDINGFORCORRECTION",
                    "applicationStatus": "SENT BACK",
                    "docUploadRequired": false,
                    "isStartState": false,
                    "isTerminateState": false,
                    "isStateUpdatable": true,
                    "actions": [
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "6228efd7-30c5-4bef-ae67-0c6517707b37",
                            "tenantId": "pg",
                            "currentState": "06da8fe1-1d68-4ea8-9409-217182b58846",
                            "action": "RE-SUBMITTED",
                            "nextState": "6cc0eebd-e9f5-485b-94cd-cd28e7733974",
                            "roles": [
                                "ESTIMATE_CREATOR"
                            ],
                            "active": true
                        },
                        {
                            "auditDetails": {
                                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                                "createdTime": 1678950370209,
                                "lastModifiedTime": 1678950370209
                            },
                            "uuid": "fc711556-4849-4ca1-a47b-54f3facaac79",
                            "tenantId": "pg",
                            "currentState": "06da8fe1-1d68-4ea8-9409-217182b58846",
                            "action": "REJECT",
                            "nextState": "37615e97-0eba-4022-be8b-3feaf0bf4441",
                            "roles": [
                                "ESTIMATE_CREATOR"
                            ],
                            "active": true
                        }
                    ]
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "fcd34bba-9f52-4de6-9a16-2a50315cfb91",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": null,
                    "state": "APPROVED",
                    "applicationStatus": "APPROVED",
                    "docUploadRequired": false,
                    "isStartState": false,
                    "isTerminateState": true,
                    "isStateUpdatable": false,
                    "actions": null
                },
                {
                    "auditDetails": {
                        "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                        "createdTime": 1678950370209,
                        "lastModifiedTime": 1678950370209
                    },
                    "uuid": "37615e97-0eba-4022-be8b-3feaf0bf4441",
                    "tenantId": "pg",
                    "businessServiceId": "c798a157-b494-4b61-acb9-6c5923f2fc10",
                    "sla": null,
                    "state": "REJECTED",
                    "applicationStatus": "REJECTED",
                    "docUploadRequired": false,
                    "isStartState": false,
                    "isTerminateState": true,
                    "isStateUpdatable": false,
                    "actions": null
                }
            ],
            "auditDetails": {
                "createdBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                "lastModifiedBy": "7e46e32c-187c-4fb4-9d6b-1ac70fa8f011",
                "createdTime": 1678950370209,
                "lastModifiedTime": 1678950370209
            }
        }
    ]
}'l

Persister Configuration

Please make sure that the file contract-service-persister.yml is present in the configs repository in the below location.

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

If not present, please make sure to add the persister YML file.

Make sure to restart MDMS and the persister service after adding the file at the above location.

Indexer Configuration

Please make sure that the file contractservices-indexer.yml is present in the configs repository in the below location.

https://github.com/{{your organisation}}/works-configs/tree/DEV/egov-indexer

Inbox Configuration

In the MDMS repository, locate the inbox configuration file. Make sure the following JSON is added to the inbox configuration:

{
      "module": "contract-service",
      "index": "contract-inbox",
      "allowedSearchCriteria": [
        {
          "name": "tenantId",
          "path": "Data.tenantId.keyword",
          "isMandatory": true,
          "operator": "EQUAL"
        },
        {
          "name": "workOrderNumber",
          "path": "Data.contractNumber.keyword",
          "isMandatory": true,
          "operator": "EQUAL"
        },
        {
          "name": "status",
          "path": "Data.currentProcessInstance.state.uuid.keyword",
          "isMandatory": false
        },
        {
          "name": "projectId",
          "path": "Data.additionalDetails.projectId.keyword",
          "isMandatory": false,
          "operator": "EQUAL"
        },
        {
          "name": "projectType",
          "path": "Data.additionalDetails.projectType.keyword",
          "isMandatory": false,
          "operator": "EQUAL"
        },
        {
          "name": "ward",
          "path": "Data.additionalDetails.ward.keyword",
          "isMandatory": false,
          "operator": "EQUAL"
        },
        {
          "name": "locality",
          "path": "Data.additionalDetails.locality.keyword",
          "isMandatory": false,
          "operator": "EQUAL"
        },
        {
          "name": "wfStatus",
          "path": "Data.contractStatus.keyword",
          "isMandatory": false
        },
        {
          "name": "assignee",
          "path": "Data.currentProcessInstance.assignes.uuid.keyword",
          "isMandatory": false
        }
      ],
      "sortBy": {
        "path": "Data.auditDetails.createdTime",
        "defaultOrder": "DESC"
      },
      "sourceFilterPathList": ["Data.contractNumber" ,"Data.additionalDetails.projectName","Data.additionalDetails.orgName", "Data.currentProcessInstance", "Data.totalContractedAmount", "Data.auditDetails"]
    }