Overview

Attendance Management is divided into 2 parts:

1. Attendance Service

2. Muster-Roll Service

To verify the IDs of the individuals, the attendance service depends on the 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.

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

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

Overview

Features & Scope

• Feature 1

• Feature 2

Functional Requirements

Use Cases

Mockups

Overview

Measurement books or M-Books help track the work progress once the execution of the contract is initiated. The page provides detailed steps on how to use a measurement book.

• Measurement Books are legal copies signed and issued by contract_creator to the contractor noting down the Book ID, Number of Pages, and Title (as per project title).

• In offline methods, measurements can be filled daily, weekly, monthly or as per demand (usually before the time of bill creation) to raise a bill and attach a copy of the book as a reference document validating the bill information.

• Measurement Books are initially empty. The M-Books will be filled with the estimated line items only. Once all the estimated line items are filled/counted in the MBook, they can be submitted along with the final Bill.

• The Book is also sent as an attachment to the accountant for bill approval.

MBook Create

Need

Digitising offline measurement books offers several advantages, including:

1. Faster Measurement Capture: Digital tools allow for quicker and more efficient recording of measurements, reducing the time required for data entry.

2. Timely Data Capture: Real-time or near-real-time data capture ensures that measurements are recorded promptly, eliminating delays in processing.

3. Error-Free Calculation: Automated calculations reduce the risk of human errors in measurement calculations, leading to more accurate results.

4. Automation of Billing: Digital systems can automate the billing process, generating invoices and reports based on the captured measurements, further streamlining operations.

Overall, digitisation enhances efficiency, accuracy, and the overall effectiveness of measurement and billing processes.

User

• The system creates the M-Book automatically while the contract is accepted.

• Contractor/MBook-tracker will track M-Book readings

• MBook-Checker will check the measurements

• MBook-Approver will approve the measurements

Details

1. While creating an estimate, the estimate creator can add measurement rows for each SOR /Non-SOR line item. It is not mandatory to fill in these measurements unless the user clicks the "+" icon in the Quantity section of the SOR line item row.

2. Upon selecting the measurement box, an expansion slide-down will appear. Here he/she can enter the measurement details

3. The user can delete or add multiple measurement items.

4. The measurement box will contain fields for quantity, length, width, and height/depth and the product of these three values will be automatically calculated and populated in the Quantity box.

5. In cases where an object's area is not measured using length, width, and height, the user can directly enter the area in the Quantity field. The fields for length, width, and size should be greyed out and not editable in such cases.

6. The summation of all the measurement quantities will be automatically populated in the SOR/Non-SOR Quantity row. This quantity will then be multiplied by the rate to calculate the final amount.

7. Measurement Book will be created only when the contract is accepted.

8. Mbook line items will be SOR line items if while creating an estimate, a sub-line item under SOR is not created.

   1. If SOR sub-line items are created, the M-Book will have to be tracked at the SOR sub-line items level.

9. There should be an option to capture images of physical mbook and site photos along with m-book readings for each date.

10. Each M-book entry will go for approval workflow

Specifications

Acceptance Criteria

1. Create an M-Book when the contract is accepted with the start and end dates as per the contract

2. Measurements can be taken both on the web and mobile (Mobile First).

3. Measurement books initially will have line items from estimates with zero quantities. These will get filled as the project progresses and cannot go beyond what is estimated.

4. Measurement Book readings can be sent for approval for any duration/marked period, from the last marked period.

5. Once approved, that corresponding amount will be allowed for payment to the contractor.

MBook Track

Need

Tracking of MBook will be required to know the project progress and subsequently pay to contractor based on work done

User: Mbook-Tracker

Detail:

1. Mbook tracking can be done only against the line items that are captured in the estimate.

   • This can be done at the estimate SOR line item level or sub-line item level.

2. At least one measurement needs to be filled in to submit an MBook for approval.

3. Each submission of the measurement book can use the same ID of the MBook with a running sequence number appended at the end.

4. To add another measurement reading for the same project, users can click on Actions > Add New Measurements, which opens another tab.

5. The overall measurements cannot exceed the estimated quantities.

6. A project can have any number of measurement entries.

7. M Book tracking can only be done until the last date of Mbook.

8. Each mBook recording will have an approval workflow.

   • MBook is created by contractor/mbooktracker,

   • Checked by m-book checker,

   • Approved by m-book approver.

9. An Mbook should be able to tell using analysis of rates, how much labour, material and other heads as bifurcated in the estimate under SOR item detail 1.

   1. Upon each mBook entry creation, a labour consumption log and material consumption log should also be generated as to how much material from the last entry till this entry is consumed.

   2. Only based on material consumed, the material supplier is eligible to get paid.

MBook Cancel

Need:

Cancelling of Mbook is only possible with the cancellation of the contract

Roles: Contract_Canceller

Detail

1. If a contract gets cancelled Mbook will also get cancel status.

2. MBook reading entry if is in the approval workflow, will be moved to cancel status as well.

3. Whatever approvals done so far on Mbook workflows are eligible for payments.

   1. Since we do automatic payments, a bill would have already been created for such mbook entries.

Mockups

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. Examples of projects - a health campaign, office decoration, a pre-contractual phase with an IT vendor for new software, new service delivery initiatives etc.

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

Features & Scope

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

Masters

The table below provides the list of project attributes.

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

Use Cases

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

Mockups

Related Topics

Overview

In a government setting, payments can be categorized into two main types: payments made to the government and made by the government.

Payments made to the government are payments received by the government, categorized as receipts or revenue. Payments to the government can be divided into two types: demand-based collection and non-demand-based collection.

Payments made by the government are expenses incurred by the government. Examples include - Salaries, Wages, Beneficiary payments, Contractor Payments, or Ad Hoc Payments.

Demand-Based Collection

1. Demand Generation: The government generates a demand for payments.

   • Examples: Property Tax, Trade License, Water Tax.

2. Invoice Issuance: An invoice is issued by the government detailing the demands. This invoice specifies what is owed to the government, including taxes, charges, or levies.

3. Payment by Citizen: The citizen acknowledges the demand and pays the specified amount.

4. Receipt Issuance: A receipt is issued to the citizen upon payment, acknowledging the receipt of the amount.

Non-Demand-Based Collection

• Collections are made without a prior demand being generated by the government.

The DIGIT demand and billing service is used to manage payments made to governments.

Approach

For any transaction to happen, there is a payer, payee, amount and entity details

• Payer and payee can be individuals or organizations.

• Entity details contain other information which are important for a bill to be generated but not mandatory for payment advice

  Examples - Invoice ID, Invoice date, Verification details etc

Every transaction ideally starts with an invoice equivalent that is generated by the supplier/contractor/muster/contract/payroll etc against which a payee generates a bill in the name of the payer.

A bill can have single or multiple beneficiaries depending on verifiable information sources.

Example - If a muster roll has 20 beneficiaries, Bill also can have 20 beneficiaries. It is not needed to create 20 individual bills.

A single invoice should not be split into multiple bills.

Example - Even though the material is supplied in tranches, a single PO can lead to multiple invoices and only after the consumption of the entire material as per individual invoice and associated measurement book a bill for that invoiced amount can be created and paid.

Payment advice is generated to enable beneficiary payments and the module is integrated with a payment gateway.

Hence payment advice contains minimal information required for the bank/gateway to make the payment. Limits on the number of beneficiaries and amounts etc are configurable as needed by the integration.

Expenditure

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

This module should have the following components

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, the 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 selects to pay a contractor bill, the user can select against which measurement books of the contract this bill is being raised, and accordingly bill amount will be calculated.

   • Muster/Labour Bill -

     • A labour bill is created from a muster roll and usually has multiple beneficiaries within the same bill.

     • When a user selects to pay a wages bill, the 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 a contractor bill where as here instead of a 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 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 wage bills 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 use cases)

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

6. Service should not allow debit more than the initial quoted amount under respective heads against the sum of all the bills created for the project.

Deductions

1. The amount that is deducted from the gross value of the bill as these are already included in the work line items

2. Deductions are classified into many types

   • Internal transfer

     • Example - SOR line items already include cess 1%. Hence it is deducted here and transferred to the labour welfare account head.

     • SOR line items also include royalty on the material. That needs to be deducted from here and transferred to Tahsildar.

   • Advance recoveries

     Amounts paid earlier for mobilization advancement or material procurement etc are deducted while creating a new bill.

   • Retention Money

     Money is withheld for payments and paid at a later date after the defect liability period.

3. Deductions are always done against a beneficiary.

   If a bill contains multiple beneficiaries, it needs to be specified against which beneficiary the deductions are made.

4. Credit Details

   A bill can have multiple beneficiaries. However, the nature of payments or beneficiary types should be the same for all beneficiaries in one bill.

   • Wage seekers bill should contain only beneficiaries for wages

   • Material bills should contain only vendors and be verified against their invoices

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

6. Every bill will also have a beneficiary payment status.

   • In the absence of intergrations with Banks/IFMS, this status can be updated manually to mark beneficiary payments.

   • In the presence of integration, systems should show the status of payment.

   • Once a bill is approved, payment advice needs to be created and sent to an integrated system. This system will send back the success/failure status along with the reasons.

7. In case of payment failure, Works should allow modifying the bill, marking the changes as mentioned in the error codes and resubmitting.

   • This will create a new payment advice, linking reference to an earlier bill.

Figma Link

Bill Attributes

Functional Requirements

Bill Objection - Reasons

Expenditure Service Domain Modeling

Budget Checks

1. Input to expenditure service is when a project is created and an estimate is to be approved.

   • Expenditure will query the program service to get the status of fund availability.

Budget Blocking

1. In case funds are available, the expenditure service can also ask the program service to block respective funds (from estimation) for this project.

   • The budget hence is blocked and won’t be available for the next projects.

Release Blocked Budget

1. The expenditure module should also have a 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. The expenditure service will also have a planning module which will give timelines of expenses and respective amounts to funding agencies.

   • The blocking module also feeds into the planning module to block funds on time.

Billing management

1. Bills are created under contracts (projects)

2. A contract is issued by Payer to Payee.

   • The contract can be materials, labour, services, supervision etc

3. A payee in turn issues invoices against the contract on the supply of material/services.

   • After successful verification of supplies and invoices, the payer adds bills into the finance system

   • A voucher is created in the accounting system for auditing purposes.

   • Payment advice is sent to the bank for making financial transactions.

   • The voucher and bill statutes are updated once the payments are made.

4. 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, labour invoice (Muster roll), or invoice for supervision charges.

   3. PS: Not every time an invoice is required to generate a bill.

      • Ex. Salary Bill, Advance bill, contingency bill etc don't need any invoices.

   4. An invoice can have multiple line items.

      • In case 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.

      • In the case 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 a government body. Even the employee remits his part of the tax at regular intervals.

      • An invoice can also have multiple beneficiaries and head-wise breakdowns for each beneficiary.

   5. An invoice when entered into the system creates a Bill. A billing entity internally will have multiple line items each by payer, beneficiary, amount and head combination.

      • 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 a voucher in the accounting system

   7. A payment voucher however can be a combination of multiple payers and payees by line items. From above example

      • There can be a minimum of 2 payment advises one for all payables of 450 rs to each individual

      • Other for all ESI deductions directed to the ESI department.

      • 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, the overall bill will be updated with status.

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 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 (refer to the table below).

Functional Requirements

1. After creating the project (and getting it approved if it is in the workflow) the Junior Engineer estimates it.

2. The following details are required to create an estimate -

   • Line items from SOR

   • Non-SOR line items

   • Overheads

3. There are 3 ways how estimates can be added.

   • Manually adding from the 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 required for the project.

   • SOR standard amount multiplied by this quantity gives the line item-wise cost.

5. Measurements are captured at the SOR line item level directly by the specified UOM or length, breadth, height, and quantity are captured and stored in an empty measurement book. The measurement book recordings can be used later.

   • Multiplication of L, B, H, and 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, capture L,B,H,Q details.

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

   • Overhead amounts 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 vary 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.

   • Example: The estimate of tiling for the ground floor and the 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, and 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

The 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. CPWD does not define non-SOR items and based on project requirements will get added to the estimate.

2. They will have the same attributes as the SOR item but not a defined SOR ID or SOR category.

Example - Purchasing fancy benches & themed dustbins at the Park. The rate, in this case, is fixed by JE upon discussion 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 is defined within a time range with either a percentage or lump sum value of the 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 created from this estimate needs to be revised and sent to the contractor for approval.

4. Measurement books accordingly will be 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 - Earthwork, masonry, brickwork, 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 similar kinds of work.

3. On the UI, the Estimates inbox will have an Estimate Template section and users can see a list of templates, create a new template from there, or modify the existing template.

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

Master Data Sample

Mockups

User Acceptance Criteria

A user should be able to -

1. Create an estimate using templates

2. Add SOR items from the 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

Related Topics

• Configure Estimates Service

• Configure Estimates for MUKTASoft

• MUKTASoft Detailed Estimate user stories

• MUKTASoft - Configure UI for the Estimate module

• MUKTASoft - Estimate module user manual

Overview

This section gives information related to Organisation Services. An organisation can be any contractor/vendor/business unit that works with the government and helps in citizen service delivery.

Features & Scope

1. A contractor/vendor is someone who does projects with the government. Every Project, after estimation approval and tendering, will have to be assigned to a contractor/vendor for it to be executed.

2. Works contractors bid for or are assigned works' contracts depending on the mode of entrustment for specific projects

3. Process of registering a contractor.

   • A contractor will apply for registration with any of the government departments. The contractor will be assigned a class and ID upon registration. A contractor will be issued projects that will fall into that class.

   • A contractor can have multiple staff that manage contractor organisation with permissions

   • List of things done by contractors for a project -

     1. (Offline) Bid for contracts

     2. (Offline)Negotiate contracts

     3. (Offline)Accept Letter of Intent

     4. (Offline) Issue Letter of Acceptance

     5. (System) Accept/Reject Contract

     6. (System) Track Work Measurements

        1. (System) Track Attendance Measurements

     7. (System) Create Running/Final Bills

     8. (System) Download and upload relevant documents

Masters

Contractor Class

1. Each contractor organisation is given a contractor class/grade depending on the screening/validation process.

2. Following are the fields required to grade contractors. This constitutes the MDMS data.

Contractor Organisation

A contractor organisation has a class associated with at least one department; type and subtype based on what the organisation supplies to the government, staff details to know who is managing the organisation and financial details to make payments.