Overview

Features & Scope

• Feature 1

• Feature 2

Functional Requirements

Use Cases

Mockups

Overview

Attendance Management is divided into 2 parts:

1. Attendance Service

2. Muster-Roll Service

Dependency

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

Features & Scope

Attendance Service manages the following:

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

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

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

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

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

Use Cases

Mockups

Background/Context

In a government setting -

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

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

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

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

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

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

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

1. Expenses are created by the JE and approved by ME, EE/ EO depending on amount and associated approval authority.

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

         1. Salary/Pension Bill

            1. Based on Payroll, leaves, PF, GPF, other allowances

         2. Advance Bill

            1. Unlike other bills which are post work/service completion and measurement, advance bill is raised prior and adjusted later.

            2. Advance bill is horizontal and be applicable on top of all other bill types

         3. Works/Contractor Bill

            1. A contractor bill is created and measured against the measurement books and contract(work order) objects for verification.

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

         4. Muster/Labour Bill -

            1. A labour bill is created from muster roll and usually have multiple beneficiaries within the same bill.

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

         5. Supplier/Vendor Bill

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

            2. A vendor bill should ideally be against each individual invoice as submitted by the supplier.

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

         6. Contingency/Expense Bill

            1. Ad Hoc expenses

         7. Supervision Bill

            1. This type of Bill is calculated as a percentage on top of other types of approved bills.

         8. Others (need more usecases)

   2. Debit Details

      1. {Account Code, Account head, Debit Amount}

         1. Treasury Payments - {Major, Sub Major, Minor, Sub Minor, Detail, Object head , Debit Amount}

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

3. Deductions

4. Amount that is deducted from gross value of the bill as these are already included in the work line items

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

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

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

1. Once the bill of any type is created, this will go for approval and have wfstatus.

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

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

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

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

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

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

1. Bills are created under contracts (projects)

2. A contract is issued by Payer to Payee.

   1. Contract can be materials, labor, services, supervision etc

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

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

Overview

Projects are the first work entity defined by the State/Department/ULB or any executing authority. This consists of basic details like IDs, descriptions, addresses, sub-project details, project types, start and end dates etc.

Projects may not focus on just construction or civil works. A health campaign, an office decoration, a pre-contractual phase with an IT vendor for new software, new service delivery initiatives etc are examples of projects.

Users: Junior Engineer or Assistant Engineer who creates Works Projects for the ULB/Department

Description

1. JE creates projects with the below-mentioned attributes.

2. A project can have sub-projects as well depending on the way of executing the project.

   • When a project is divided into sub-projects, each will have the same attributes to be captured as the main project.

3. A project can be sent for approval depending on the need.

   • Usually, the administrative sanction is done on projects by EO. Post approval, detailed and abstract estimates are done.

     • Once the admin sanctions the project, the fund is also blocked for the respective heads of accounts.

     • Project status -

       • Created

       • In progress

       • Approved

       • Rejected

       • Cancelled

4. Once a project is created on the UI, the system generates a unique ID for each project/sub-project.

   • ID: PROJ/<ULB/Department Code>/<Year>/<month>/<Date>/<running sequence number>

5. The project details capture the financial details such as the funding source for the project. These details, however, are not part of the Project Service but are captured as part of the Program Service.

Features & Scope

The table below provides the list of project attributes.

Use Cases

A project can be divided into multiple sub-projects, each with its own workflows/business requirements defined.

Mockups

Overview

1. A contract document is a legal & financial obligation between any two parties entering into the contract.

2. After the estimates are created and approved, they are grouped or individually tendered/direct assigned to vendors to execute the work.

3. A works package is typically not seen in all Works Management Products. it is used only where high-complexity projects are executed where packaging is needed to form smaller or larger chunks so as to increase operational efficiency.

4. The current contract service includes Line items of estimates, Works packaging, Negotiation, Contract Terms, and Milestones.

Actors

The Junior Engineer/Assistant Engineer creates the contracts and the Municipal Engineer/Executing Officer approves the contract depending on its value. (Workflow configurations based on amount subject to platform capability in v1).

Create Contract

Story Detail

• After Estimates are created and approved for projects/sub-projects, these estimates can be grouped in specific ways to form works packages.

• The need for grouping arises in the way how the JE/ULB wants to execute the project(s). For instance -

  • Small Projects(Estimates) of similar types in nearby localities can be grouped to form a single works package. This work package can be tendered, negotiated and contracted. (Most common need of work package)

  • A huge project(estimate) can be broken down into multiple work packages by the line items approved within the estimate. The value of the work packages in this case will be proportional to the costs of the line items. (This breakdown is already achieved by dividing projects into sub-projects and hence might not be needed during estimations)

• Works package will go for tendering or direct assignment depending on the project.

  Tendering/Negotiation can be of two types

  1. Lumpsum - Entire package will be negotiated by a percentage value or lump sum value.

     • Running bills will be validated by the measurements of the line items in the works package.

     • The final bill will be adjusted to the remaining amount

  2. Percentage line item

     • Each line item will be negotiated and negotiated values will be paid as part of the contract

     • Running bills will be validated by the measurements of line items in te works package

     • The final bill will be adjusted to the remaining negotiated amount of each line item.

• The contract will have milestones and only when milestones are met, payments will be made to the contractors.

• The contract will also have terms and conditions (text only in v1, to be codified in v2)

• The contract will have an approval workflow. Upon clicking proceed to forward on the last tab, the user will be shown a popup to select forwarding details.

• Rejected contracts will come to the inbox of the creator for any modifications.

• Statuses of Contract

  1. Created

  2. In progress

  3. Approved

  4. Rejected (Rejected in Workflow. Comes to the inbox of the creator. Can be edited and resent for approval)

  5. Cancelled (Completely Cancelled. Cannot be edited)

Overview

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

Need and Background:

1. An estimate is prepared for each Works project so as to get technically sanctioned and proceed with tendering/contract.

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

3. There are multiple estimate types for each project prepared with different levels of abstraction.

Functional Requirements

1. After creating the project (and getting approved if there is a workflow) JE will start estimating the project.

2. To create an estimate following details are required.

   • Line Items from SOR

   • Non-SOR line items

   • Overheads

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

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

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

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

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

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

9. Each estimate will have a unique ID that is generated

   • ID: EST/<ULB/Department Code>/<Year>/<month>/<Date>/<running sequence number>

10. Status of an estimate

    • Created

    • In progress

    • Approved

    • Rejected

    • Cancelled

Masters

Schedule of Rates (SOR)

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

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

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

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

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

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)

1. Non-SOR items are not defined by CPWD and based on project requirements will get added to the estimate.

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

1. In-Line Overheads - Defined within the SOR line items

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

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

2. For a revised estimate -

   • New line items can be added.

   • Existing line items can be removed

   • Quantities in existing estimates can be modified.

3. A contract that is created from this estimate also needs to be revised and sent to the contractor for approval.

4. Measurement books accordingly will get changed as per the new estimate.

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

1. Templates are created for specific types and sub-types of work so they can be reused for future use.

2. Templates are groupings of SOR items that combine to complete a similar kind of work.

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

1. Create an estimate using templates

2. Add SOR items from SOR Master

3. Change values as required for current work

4. Add/auto-populate overheads

5. Able to generate Material Analysis and Labour Analysis

6. Download PDFs of Labour analysis, material analysis, and Overall Estimate