System and method for an enterprise resource planning (ERP)

Abstract

The disclosure herein, this a system (100) for an Enterprise Resource Planning (ERP), the system (100) receiving a request from each employee from a plurality of employees, creating an account for each employee based on a role of each employee in an enterprise, assigning, a task associated with a project to each employee from the plurality of employees upon creation of the account, allowing an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee, receiving, a primary report from each employee in each team from a plurality of teams, and generating, a final report based on the primary report associated with the plurality of teams, wherein the final report is generated using an artificial intelligence technique.

Description

SYSTEM AND METHOD FOR AN ENTERPRISE RESOURCE PLANNING (ERP)CROSS REFERENCE TO RELATED APPLICATION AND PRIORITY

[0001] The present invention claims priority from Indian patent application 202321038563 filed on date 05thSeptember 2023.TECHNICAL FIELD

[0002] The present matter described herein is relates to data-tracking, data-management and guiding the flow-of- works on the projects.BACKGROUND

[0003] The current era is all about digitization which provides storage and management of data in electronic / digital form. With increasing amount of data, data storage and data management need to be handled cautiously.

[0004] In traditional systems, communication largely happens over emails where large amount of data gets shared on daily basis. Such data when downloaded needs proper manual management and tags for the future reference. Many a times, redundancy in data may create data storage issue thus imposing several challenges. Another challenge associated with traditional data communication is that all individuals have a separate data access and hence need different tools for collaboration.

[0005] Therefore, currently organizations require data tracking, management and storage which is much dependent on different roles assigned within the organization and lacks a central management and access.OBJECTS OF THE INVENTION

[0006] Main object of the present disclosure is to provide an Enterprise Resource Planning (ERP) system that is configured to provide data tracking, data management & data storage.

[0007] Another object of the present disclosure is to configure one single platform for managing all project- related-data at one location.

[0008] Yet another object of the present disclosure is that the system creates an account for the employee / user on an Enterprise Resource Planning (ERP) platform.

[0009] Yet another object of the present disclosure is that the system assign a task associated with a project to each employee upon creation of the account as per the associated employee data and role of the employee in an enterprise.

[0010] Yet another objective of the present disclosure is that the ERP system generate a test / work / daily summary report by using an artificial intelligence technique.SUMMARY

[0011] Before describing the data management by this system, it is to be understood that this system is not limited to a particular system and method in providing data management as there may be multiple possible embodiments, which are not expressively illustrated in the present disclosure. It is also to be understood that the terminology used here in the description, for the purpose of describing the particular implementations,1SUBSTITUTE SHEET (RULE 26)versions, or embodiments, is not intended to limit the scope of the present application / ERP. This summary is provided to introduce the aspects related to system and method providing data tracking & management. This summary is neither intended to identify essential features of the claimed subject matter nor intended to use in determining or limiting the scope of the claimed subject matter.

[0012] In one embodiment, this system is an application / system providing data tracking, data management & data storage. The system provides one Single platform configured for managing all project-related-data at one location (sharing & storing both preciously in the required category of Documents) for many industries for example, all construction matters from the stage of Appointing-Project-Teams TO Planning-stage- coordination TO Construction-stage-coordination TO Billing TO Reconciliations TO Project-Closure stage.

[0013] The platform enables all offices involved in the construction matters (i.e. Developer, Architects, Consultants, PMCs, Contractors, Sub-contractors, Suppliers & Financial-Institutes) to share and receive required fdes / docs / drawings / reports as per their roles in the project. In this process of sharing & receiving files / docs, which process / step is not followed by whom can also be tracked & pointed out accurately which helps in reducing the future expected complications due to such missed out steps.

[0014] The present invention discloses a system for an Enterprise Resource Planning (ERP), the system comprising a memory and a processor coupled to the memory. The processor is configured to receive a request from each employee from a plurality of employees. The request is associated with a creation of an account for the employee on an Enterprise Resource Planning (ERP) platform. The processor is further configured to create the account for each employee based on a role of each employee in an enterprise. Further, the processor is configured to assign a task associated with a project to each employee from the plurality of employees upon creation of the account. The task is assigned to each employee based on employee data. The employee data comprises the role of the employee in the enterprise, a prior experience of the employee, a working domain of the employee, a team of the employee, and a current workload of the employee. Furthermore, the processor is configured to allow an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee. The enterprise data comprises files related to the task assigned, and confidential reports related to the enterprise and the task assigned. The processor is further configured to receive a primary report from each employee in each team from a plurality of teams. In one embodiment, the plurality of teams are working on the project in the enterprise. The primary report indicates update associated with the task assigned to each employee in each team. Further, the processor is configured to generate a final report based on the primary report associated with the plurality of teams. The final report is generated using an artificial intelligence technique. The final report is generated based on analysis of the primary report and training data associated with the project. The training data comprises historical reports associated with the project, timelines assigned to each task associated with the project, and project planning information.

[0015] In another embodiment, the final report comprises a number of employees working on the project, updates related to the project, data associated with the purchase order of resources associated with the project, and resources or material used in the project till a defined date.

[0016] In another embodiment, the system is further configured to assign a priority to each task associated with each employee from the plurality of employees.

[0017] In another embodiment, the type of account created for each employee is based on the role of the employee in the enterprise.

[0018] In another embodiment, the system is further configured to automatically send an alert to an employee upon analysis of the final report. The alert is associated with the purchase order of the resources required for the project.

[0019] In another embodiment, the system is configured to track the attendance for each employee based on in-time and out-time of each employee, and calculate the salary of each employee based on the attendance of each employee.

[0020] In another embodiment, the system is configured to send a meeting invite to multiple employees from the plurality of employees using a chat platform associated with the ERP platform. The multiple employees are allowed to share meeting agenda and meeting recordings through the chat platform.

[0021] In another embodiment, the system is configured to restrict the employee from accepting an offer letter from multiple organizations at a time based on tracking real-time information associated with the employee.

[0022] In another embodiment, the system is further configured to audit supplied resources verses the resources used in the project based on analysis of the final report using an Optical Character Recognition (OCR) reader.

[0023] In another embodiment, a method for an Enterprise Resource Planning (ERP). The method comprises receiving, by a processor, a request from each employee from a plurality of employees. The request is associated with creation of an account for the employee on an Enterprise Resource Planning (ERP) platform. The method further comprises creating, by the processor, the account for each employee based on a role of each employee in an enterprise. Further the method comprises assigning, by the processor, a task associated with a project to each employee from the plurality of employees upon creation of the account. The task is assigned to each employee based on employee data. Further, the employee data comprises the role of the employee in the enterprise, a prior experience of the employee, a working domain of the employee, a team of the employee, and a current workload of the employee. Furthermore, the method comprises allowing, by the processor, an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee. The enterprise data comprises files related to the task assigned, and confidential reports related to the enterprise and the task assigned. The method further comprises receiving, by the processor, a primary report from each employee in each team from a plurality of teams. The plurality of teams are working on the project in the enterprise, and the primary report indicates update associated with thetask assigned to each employee in each team. Further, the method comprises generating, by the processor, a final report based on the primary report associated with the plurality of teams. The final report is generated using an artificial intelligence technique, and the final report is generated based on analysis of the primary report and training data associated with the project. Further, the training data comprises historical reports associated with the project, timelines assigned to each task associated with the project, and project planning information.BRIEF DESCRIPTION OF DRAWINGS

[0024] The foregoing detailed description of embodiment is better understood when read in conjunction with the appended drawing. For the purpose of illustrating the present subject matter, an example of construction of the present subject matter is provided as figures; however, the present subject matter is not limited to the specific method for data management by this system.

[0025] Figure 1(a) illustrates a block diagram of a network implementation of a system for optimizing Enterprise Resource Planning (ERP) facilitating communication and data Management, in accordance with an embodiment of the present subject matter.

[0026] Figure 1(b) illustrates a block diagram of a system for facilitating data management, in accordance with an embodiment of the present subject matter.

[0027] Figure 2 illustrates a block diagram showing connectivity of multiple employees working on a project, in accordance with an embodiment of the present subject matter.

[0028] Figure 3 illustrates a block diagram of a first exemplary embodiment of housekeeper connectivity to a housekeeping agencies and subsequent engagement at offices / project sites on behalf of an employer, in accordance with an embodiment of the present subject matter.

[0029] Figure 4 illustrates a block diagram of a second exemplary embodiment of labour connectivity to a contractors / subcontractors / other employers and subsequent engagement at project sites on behalf of an employer, in accordance with an embodiment of the present subject matter.

[0030] Figure 5 illustrates a block diagram of a third exemplary embodiment of a security man connectivity to a security agencies and subsequent engagement at offices / project sites on behalf of the employer, in accordance with an embodiment of the present subject matter.

[0031] Figure 6(a) illustrates a screenshot as a first example showing a report generated by a task manager, in accordance with an embodiment of the present subject matter.

[0032] Figure 6(b) illustrates a screenshot as a second example showing a report generated by the task manager, in accordance with an embodiment of the present subject matter.

[0033] Figure 6(c) illustrates a screenshot as a third example showing a report generated by the task manager, in accordance with an embodiment of the present subject matter.

[0034] Figure 7 illustrates a flow chart performing a method for an Enterprise Resource Planning (ERP), in accordance with an embodiment of the present subject matter.DETAILED DESCRIPTION

[0035] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. The words “including”, “comprising”, “consisting”, “containing”, and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a”, “an” and “the” include plural references unless the context clearly dictates otherwise. Although any system and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the exemplary method for data management by this system 100 is now described. The disclosed embodiments of method for data management by this system 100 may be merely exemplary of the disclosure, which may be embodied in various forms.

[0036] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure for method for data management by this system 100 is not intended to be limited to the embodiment illustrated but is to be accorded the widest scope consistent with principles and features described herein.

[0037] Referring now to Figure 1(a), a network implementation 100a of a system 100 for optimizing Enterprise Resource Planning (ERP) facilitating communication & data management. The system 100 builds an Enterprise Resource Planning (ERP) platform. In one embodiment, the system 100 may be referred to as the ERP system.

[0038] In one aspect, the intent may indicate a context of receiving a request from each employee from a plurality of employees, and the request is associated with creation of an account for the employee on an Enterprise Resource Planning (ERP) platform. The system 100 is configured to create the account for each employee based on a role of each employee in an enterprise. The system 100 further assigns a task associated with a project to each employee from the plurality of employees upon creation of the account. The system 100 further allows an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee. The system 100 further receives a primary report from each employee in each team from a plurality of teams. The system 100 further generates a final report based on the primary report associated with the plurality of teams.

[0039] Although the present disclosure is explained considering that the system 100 is implemented on a server, it may be understood that the system 100 may be implemented in a variety of computing systems, such as a laptop computer, a desktop computer, a notebook, a workstation, a mainframe computer, a server, a network server, a cloud-based computing environment. It will be understood that the system 100 may be accessed by multiple users through one or more user devices 102-1, 102-2... 102-N, collectively referred to as user 102 or employee, hereinafter, or applications residing on the user devices 102.

[0040] In one implementation, the system 100 may comprise the cloud-based computing environment in which a user may operate individual computing systems configured to execute remotely located applications. Examples of the user devices 102 may include, but are not limited to, an loT device, loT gateway, portable computer, a personal digital assistant, a handheld device, and a workstation. The user devices 102 are communicatively coupled to the system 100 through a network 105. In one embodiment, the user may be an employee working in an enterprise. Further, the user device 102 may be used by the employee in the enterprise. In one embodiment, the enterprise may be referred to as an organization.

[0041] In one implementation, the network 105 may be a wireless network, a wired network or a combination thereof. The network 105 can be implemented as one of the different types of networks, such as intranet, local area network (LAN), wide area network (WAN), the internet, and the like. The network 105 may either be a dedicated network or a shared network. The shared network represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Transmission Control Protocol / Intcrnct Protocol (TCP / IP), Wireless Application Protocol (WAP), and the like, to communicate with one another. Further the network 105 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, and the like.

[0042] In one embodiment, during operation, the system 100 may be configured to receive a request from each employee from a plurality of employees. The plurality of employees may be working in an enterprise or organization. In one example, the plurality of employees may include labours, developers, contractors, suppliers, house-keepers, architectures, doctors, and the like. In another example, the plurality of employees may be working in different teams associated with a project in the organization. The plurality of employees working in the organization at different designation or role.

[0043] In one embodiment, the request may be received from the user device 102 used by each employee from the plurality of employees. The request may be associated with creation of an account for an employee on an Enterprise Resource Planning (ERP) platform. The account may be a professional profile of the employee. The request may comprise an employee name, an employee address, an employee designation or role, and the like.

[0044] Further, the system 100 may be configured to create the account for each employee based on a role of each employee in the enterprise. In one aspect, the enterprise may be referred as the organization. The account may be created based on employee data. The employee data may include an employee name, an employee address, an employee blood group, an employee previous experience, and name of previous organizations associated with an employee, an employee designation, and the like. In one embodiment, a single account may be generated for each employee. In one embodiment, the account created for an employee in one organization may be used by the employee in another organization when the employee switches job from one organization to another organization. In one embodiment, the ERP platform may restrict access to data when the employeeswitches job from one organization to another organization. In one embodiment, a type of account created for each employee is based on the role of the employee in the enterprise.

[0045] In one embodiment, the ERP platform may be configured to run entire business, supporting automation and processes in finance, human resources, manufacturing, supply chain, services, procurement, and the like. The ERP platform in the present invention is comprising different modules such as Human Resource (HR) module for managing HR activities, a task manager, a finance module, a data management module, a supplier related module, and the like. In one example, the ERP platform may be a combination of different modules that are configured to manage and streamline multiple processes in the organization.

[0046] Further, the system 100 may be configured to assign a task associated with a project to each employee from the plurality of employees upon creation of the account. The task is assigned to each employee based on the employee data. The employee data may further comprise the role of the employee in the enterprise, a prior experience of the employee, a working domain of the employee, a team of the employee, a current workload of the employee, and the like. Further, the task assigned to the employee may be associated with the working domain of the employee. In one example, the system 100 may be configured to assign a priority to each task associated to each employee from the plurality of employees. The priority may be assigned based on inputs from a manager of a team of the project in which the employee is working.

[0047] In one example, assume a construction site as the organization comprising the plurality of employees. The plurality of employees may comprise labours working at the construction site, developers, contractors, suppliers, finance team, business team, and the like. Further, the system 100 may assign task to each employee working at the construction site based on the designation or role of the employee at the construction site.

[0048] The system 100 may be further configured to allow an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee. The enterprise data may comprise files related to the task assigned, confidential reports related to the enterprise and the task assigned, finance data, HR data, and the like. In one embodiment, the enterprise data may be confidential and access to the enterprise data must be restricted. In one example, the finance team working at the construction site may have access to the finance data. Further, the labours working at the construction site may have access only to personal information i.e., employee profile information like the employee name and the designation, and the like. Furthermore, an employee working at director level may have access to all modules of the ERP platform. In one aspect, the system 100 provides limited access to each employee based on the designation of the employee in the organization.

[0049] Further, the system 100 may receive a primary report from each employee in each team from a plurality of teams. In one embodiment, the plurality of teams may be working on the project in the enterprise. The primary report may be daily -work report. The primary report may indicate update associated with the task assigned to each employee in each team. The primary report may comprise the employee name, the employee designation, working hours of an employee, work completed by the employee, deadline associated with each task, the like. In one embodiment, the primary report of each employee may be shared with a manager of eachteam. In one embodiment, the system 100 may receive the primary report from the user device 102 of each employee. The system 100 may automatically update a database upon receiving the primary report every day.

[0050] Further, the system 100 may be configured to generate a final report based on the primary report associated with the plurality of teams. The system 100 may be configured to generate the final report for a predefined time period. In one example, the predefined time period may be defined by a head of the organization. The final report may be a consolidated report associated with the project. The final report may be associated with the plurality of teams working on the project. The plurality of teams may comprise labours, developers, contractor team, supplier team, business team, HR team, finance team, and the like.

[0051] In one embodiment, the final report may be generated using an artificial intelligence technique. The final report is generated based on analysis of the primary report using a training data model. The training data model may be associated with the artificial intelligence technique. The training data model may comprise training data associated with the project. The training data may comprise historical reports associated with the project, timelines assigned to each task associated with the project, project planning information, a format of historical reports, and the like. The training data model may be automatically trained continuously for each project. The final report may be associated with real-time data of the project. In one embodiment, the training data model may receive the primary report from each employee. Further, the training data model may analyse the primary report based on the training data. Based on the analysis, the system 100 may be configured to generate the final report for the project. In one embodiment, the final report may comprise number of employees working on the project, updates related to the project, data associated with purchase order of resources associated with the project, resources or material used in the project till a defined date, and the like.

[0052] In one embodiment, the system 100 may be configured to automatically send an alert to an employee upon analysis of the final report. The final report may be further analyzed using artificial intelligence technique. The artificial intelligence technique may use the training data to analyze the final report. The training data may further information such as material or resources supplied by the supplier, new purchase order of material or resources, new employees required in each team of the project, and the like. Based on the analysis, the system 100 may send the alert to management team associated with the project. The management team may include a manager of each team, a head of the organization, and the like. In one embodiment, the alert may be associated with the purchase order of the resources required for the project, the new employees required, and the like.

[0053] In one embodiment, the system 100 may be configured to accurately track an attendance of each employee based on in-time and out-time of each employee. Further, the system 100 may be configured to calculate a salary of each employee based on the attendance of each employee. In one embodiment, the system 100 may be configured to send a meeting invite to multiple employees from the plurality of employees using a chat platform associated with the ERP platform. The multiple employees are allowed to share meeting agenda and meeting recordings through the chat platform. The plurality of employees may be able to communicatewith each other through the chat platform. The chat platform may be configured to keep the communication between the plurality of employees associated with the project.

[0054] In one embodiment, the system 100 may be configured to restrict an employee from accepting an offer letter from multiple organizations at a time based on tracking real-time information associated with the employee. The ERP platform may be configured to track the real-time information associated with an interview attended by the employee, offers from different organizations rejected by the employee , offers from different organizations accepted by the employee, organizations joined by the employee, a time spend by the employee in each organization upon joining, and the like. The system 100 may provide full access of the realtime information to the employee, and limited access of the real-time information to different organizations. Based on the real-time information from the employee, the system 100 may not allow the employee to accept offers from multiple organizations at a time.

[0055] In one embodiment, the system 100 may be configure to audit supplied resources verses the resources used in the project based on analysis of the final report using an Optical Character Recognition (OCR) reader. In one embodiment, the system 100 may use the OCR read to analyse and read the final report, generated for the predefined time period, associated with the project. Based on the analysis, the system 100 may perform the auditing for the project. The system 100 may generate the alert for the employees in the organization based on the auditing.

[0056] In an embodiment, the system (100) uses an angular frontend technology. The angular frontend technology is a robust framework for building dynamic and responsive employee interfaces. The system (100) uses Node.js and NesUS backend technology for scalable, efficient server-side architecture, especially in handling I / O-bound tasks, micro-services, and real-time data. A spring framework is used by the system (100) for complex business logic and enterprise-grade applications that require strong transactional capabilities and data-intensive operations. The system 100 integration is illustrated further. The micro-services architecture may allow Node.js and spring to work seamlessly together. Node.js may focus on lightweight, asynchronous tasks while spring manages complex, CPU-intensive operations, optimizing overall performance.

[0057] In accordance with an embodiment, figure 1(b) illustrates a block diagram of a system for facilitating data management, in accordance with an embodiment of the present subject matter.

[0058] The system 100 provides one single platform configured for managing all project-data at one location (sharing & storing both preciously in the required category of Docs) for many industries for example, all construction matters from the stage of Appointing-Project-Teams TO Planning-stage-coordination TO Construction-stage-coordination TO Billing TO Reconciliations TO Project-Closure stage.

[0059] The system 100 comprises a user interface 102, a memory 104, a processor 106 and a communication unit 108. The memory 104 stores a plurality of instructions to be executed by the processor 106. System 100 may be configured as a platform for internal and external deployment in an organization or industry. For example, the system / platform 100 herein will be explained for a construction agency.

[0060] Referring now to Figure 1(b) (100b), the system 100 is illustrated in accordance with an embodiment of the present subject matter. In one embodiment, the system 100 may include, a user interface / devices 102, a memory 104, at least one processor 106, a communication unit 108, and. The at least one processor 106 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and / or any devices that manipulate signals based on operational instructions. Among other capabilities, the at least one processor 106 is configured to fetch and execute computer-readable instructions stored in the memory 104.

[0061] The communication unit 108 may include a variety of software and hardware communication unit, for example, a web interface, a graphical user interface, and the like. The communication unit 108 may allow the system 100 to interact with the user directly or through the user devices 102. Further, the communication unit 108 may enable the system 100 to communicate with other computing devices, such as web servers and external data servers (not shown). The communication unit 108 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. The communication unit 108 may include one or more ports for connecting a number of devices to one another or to another server.

[0062] The memory 104 may include any computer-readable medium or computer program product known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and / or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

[0063] In one embodiment, data sharing through the system 100 ensures that same data / file / doc / dwg is being viewed by each project team-member whether he / she is sitting in the office of Developer / Architect / Consultant / PMC / Contractor / Sub-contractor / Supplier / Financial-Institute. Thus, the system 100 eliminates all possibilities of getting created any confusion about which one is the latest data / file / doc / dwg and when was it issued / uploaded for all to View, by its creator.

[0064] In one embodiment, the system 100 is configured for specific conceivable category of business or company within the construction industry. The system 100 ensures that each employee is having a dedicated account format. In one example, each type of construction-related entity i.e., a developer, contractor, supplier, architect, engineering-consultant, or any other specialized role, has a dedicated account format that not only meets their specific needs but ensures streamline communication and business operations within the construction sector. The system 100 manages project data, ensuring it is shared and stored precisely in the required categories of documents. The system 100 covers all construction aspects from Appointing-Proj ectTeams TO Coordination-and-Tracking-of-Project-Planning TO Coordination-and-Tracking-of-Construction- works TO Quantity-and-Cost-Tracking TO Tracking-of-Invoicing TO Project-Closure stage. In an embodiment, an account-holding organization may simultaneously connect with any number of clients or projects, the platform still provides a comprehensive solution for companies to share, track, and manage all project information in an organized manner. In one embodiment, the account created for each employee in oneorganization may be used by the employee in another organization providing limited access to data of previous organization.

[0065] In an embodiment, the account created for each employee on the ERP platform is further illustrated. The system 100 comprises categorized businesses connected to the construction industry into at least 10 specific categories called as company account. The system 100 is configured to create 10 different types of accounts for these business categories. The categories may include Developer, Architect / Consultant, PMC, Contractor, Supplier, Sub-contractor, Financial Institute, Chartered Accountant, Security Agency, and Housekeeping Agency. Furthermore, the Architect / Consultant category may be subdivided into Municipal Architect (Licensing Architect for the project), Design Architect (Principal Planning Architect for the project), Structural Consultant, MEP Consultant, Interior Architect, Landscape Architect, Lighting Consultant, Facade Consultant, MoEF Consultant, HRC Consultant (High-Rise Consultant), and Green Building Consultant. In one example, 20 distinct business categories connected through the system for the exchange of data related to projects and office operations. In the example, comprehensive categorization ensures that the data being shared is well-segregated, enhancing tracking accuracy and enabling more efficient planning and execution.

[0066] The system 100 requires companies or proprietors involved in multiple facets of the construction industry to register separately for each category of business. In an example, if the plurality of teams operate in various capacities such as Architecture-Planning, Municipal Licensing, structural designs, MEP designs, and interior-planning, then the plurality of teams need to register separately under each relevant category such as design architect, municipal architect, structural consultant, MEP consultant, and interior architect. Similarly, if one team functions as a developer on some projects and as a contractor on others, then the team is required to register under both the developer and contractor categories. Such a dedicated account format ensures that the flow of information is organized, accessible, and relevant, promoting efficient operations, collaboration, and growth within the construction industry ecosystem.

[0067] Further, the system 100 prohibits individuals from having multiple accounts within the same business category. For example, an employee cannot create more than one account as a developer or more than one account as a design architect. However, from a single Developer account, the employee may create as many organizations, teams, companies, offices, and projects as needed. Similarly, from a single design architect account, the employee may create as many organizations, teams, companies, offices, and connect to as many projects as they wish with different developers.

[0068] In one embodiment, if a developer, contractor, or cub-contractor already has an account on the ERP platform and wishes to enter into a joint venture with another developer, contractor, or sub-contractor, then the developer, contractor, or sub-contractor may use a JV Partner feature. In one example, if a design architect is collaborating with a structural consultant, MEP consultant, or green building consultant on a project by forming a consortium, each consultant must be individually connected to the project by the developer. If an employee or a team is found to have multiple accounts on system 100 within the same business category using fabricated details, the system 100 reserves the right to suspend the accounts for a period deemed appropriate.

[0069] In one embodiment, in a project related to a construction site, different teams may send a ‘request to connect’ to the developer, that may then connect the different teams for the projects. The different teams may be referred as company such as sub -contractor, developer, architecture, and the like. Once connected, the different teams may interact with each other regarding project matters and upload related data into the designated modules and sub-modules.

[0070] In one embodiment, the accounts (for Founders and Company Partners) in each of the 20 categories feature designated links (modules and sub-modules) for exchanging data with the other 19 business categories. In one embodiment, the organization partners may have default access to all projects that a founder has. During creating accounts for the key managers and accounts-heads, the founder may either assign specific projects to them individually or set it so that all projects accessible to the founder will automatically be assigned to them as well. The accounts-heads of each company are responsible for connecting all other company employees to the specific account types tailored to suit various profdes, positions, or designations within the organization, as provided in their account. However, the system has also provided both founders and partners with a system-generated account similar to the 'accounts-head' role, which they can access to function as 'accounts-heads' and connect employees to the appropriate account types.

[0071] Further, the system 100 may ensure that if an Accounts-Head leaves the company and a replacement has not yet been appointed, the Founder or Partner may temporarily assume the role of Accounts-Head. The system 100 may prevent any disruption in the ERP flow due to the absence of the main account that links all employees to the company. In one embodiment, the system 100 may automatically assigns the role of one employee, having higher level designation, leaving the organization to another employee, with similar level designation, on a temporary time until a new employee joins the organization at the required designation.

[0072] In one embodiment, the system 100 may assign employees to these account types based on the role of each employee ensuring that each employee has access relevant to their responsibilities. Each team working on the project may have Key-Managers, Accounts-Heads, and various other office-positions. Additionally, developers, PMCs, contractors, and sub-contractors may have site-positions within their accounts to manage site affairs effectively. In one embodiment, different small companies may be working on project of the organization at a time. In the embodiment, the different companies may work as the plurality of teams on the project. In the embodiment, different companies of developers may be working on the project, different companies of architectures may be working on the project, and the like.

[0073] In an embodiment, the system 100 associated with the ERP platform may provide different features to the account of each employee. In an embodiment, managing multiple company accounts in the system 100 is illustrated further, The ERP platform associated with the system 100 may bring the multiple teams together to work on the project. The multiple teams may include developer, municipal architect (licensing architect), design architect (principal planning architect), structural consultant, MEP consultant, interior architect, landscape architect, lighting consultant, facade consultant, MoEF consultant, HRC consultant (High-Rise Consultant), green building consultant, PMC consultant (Project Management Consultant), contractor,subcontractor, supplier, financial institution (Bank), chartered accountant, security agency, housekeeping agency, and the like.

[0074] In an embodiment, assume that an employee is involved in more than one of the business types. The employee may be able to manage all these businesses within the system 100 using a single Username (email ID) and Password. The employee may be required to register as a 'Founder' in each of the business accounts as required for the project. In one example, the employee may not be a 'Founder' but a 'Company Partner' in more than one of the business types mentioned above, then the employee may still manage all these businesses within the system 100 using a single Username (email ID) and Password. Once the employee have accounts set up either as a 'Founder' or a 'Company Partner,' the employee may switch between them while logged into one of user accounts. The system 100 provides this feature through the 'Switch Account' button located in the 'Top Navigation Bar' or 'Header'. In one embodiment, the system 100 may allow the employee, having a higher level designation in the organization, to switch between different business type or different teams using a switch account button.

[0075] In an embodiment, the system 100 managing multiple employee accounts in is illustrated further. In each business type, the founder i.e., head of each team or business type, establishes connection between the company, clients, and projects. The founder also registers company partners, key-managers (who will oversee business operations on their behalf), and the accounts-head. The accounts-head further connects the plurality of employees to the organization using the ERP platform based on thoughtfully designed account structures, tailored to each employee’s role within the organization. If an employee’s role spans multiple functions, the employee may be connected to more than one account type, thus gaining access to the necessary modules and sub-modules required for broader responsibilities as defined by the system 100. In one example, in a developer team or company, an engineer responsible for general project coordination, bill certification, and site management (as a site-team member) may need to be connected to the 'Project-Planning-&-Coordination Department (Dept'), Purchase-Contract-Billing Dept', and 'Site-Supervision-Team' accounts. The system 100 may be configured to create the account that provides specific access to the data of the project, so it is essential for the employee to be assigned to the correct accounts to effectively perform the responsibilities. In an embodiment, once the employee’s accounts are set up in the necessary types, the employee may be able to switch between different business types while logged into one account.

[0076] In one example, Joint-Venture (JV) partners in developer, contractor, and sub-contractor roles is illustrated further. The developers, contractors, and sub-contractors may add JV Partners to their teams or companies under the 'JV Partner' category. In one embodiment, partners of the organization may automatically have access to all projects where the founder is involved. The JV Partners may be able to see projects that the founder specifically allows them to access. In one embodiment, the JV partners may have limited access to the data associated with the project. The JV partners may have the same project management rights as founders and the partners of the organization but cannot access sensitive information such as HR policies or financialdata. The JV partners may project-related data, including invoices and quotations, for the projects to which the JV partners are connected.

[0077] In an embodiment, the system 100 configured for restricting data access to the plurality of teams in explained. When a team or company is connected to different organizations or projects, the teams may need to upload, respond to, comment on, acknowledge, or receive data in various modules and sub-modules to effectively fulfil the roles and responsibilities. In one embodiment, the system 100 may control access to project data by restricting modules and sub-modules that the multiple employee of the team may view or interact with on the ERP platform. The system 100 may adjust 'Account Permissions' for the multiple employees of the team during the project assignment process. The system 100 may configure the 'Account Permissions' at any time after the team gets associated with the organization. The system 100 may revisit the link — 'Connect to Consultants / Vendors / FIs', and deselect the modules and sub-modules to restrict the access, and submit the changes. The restrictions for the access to the data of the project may be applied on a perproject basis for any team or company.

[0078] In an embodiment, historical data access for newly appointed companies is further illustrated. If employee’s company or the team of multiple employees is appointed to a new project by the developer or has collaborated with another company or team to be connected to the project (though the developer only connects user in this scenario), the employees in the team may be able to access all 'Active' and 'Cancelled' data for each module / sub-module that was available before the appointment.

[0079] In an embodiment, when a new company is added to the project, employees in the new company may receive all historical data for each module / sub-module. However, if this data is not available, it may mean that the developer has restricted the access to the old-data. Such restrictions may be applied on a module-by- module basis at the developer's discretion. If the employee need access to the historical data, the employee may request the developer to lift the restriction. In one embodiment, the system 100 may be able to restrict and provide access to the data of the project at any time during operation of the project based on changing access-related setting at the ERP platform. In one embodiment, the system 100 may allow an appointing authority of the organization to change the access-related settings.

[0080] In an embodiment, historical data access for newly appointed employees is illustrated further. If an employee is newly appointed to the team or the company and granted access to a new project. The employee may be able to access all 'Active' and 'Cancelled' data for each module / sub-module that was available before the appointment of the employee. Typically, when the employees are appointed, the employee may receive all historical data for each module / sub-module of all projects connected to the employee. However, if this data is not available, it may mean that an appointing authority (such as the Founder or Accounts-Head) may have restricted the access to the historical data. The restrictions may be applied on a module-by -module basis at their discretion. If the employee need access to the historical data, the employee may request the appointing authority to remove the restriction.

[0081] In an embodiment, the system 100 for restricting data access for an employee is further illustrated. When the employee is connected to a team, the employee may need to upload, respond to, comment on, acknowledge, or receive data across various modules and sub-modules to effectively fulfil the roles and responsibilities. The employee may control the access to the data of the project by restricting which modules and sub-modules they can view or interact within the ERP platform. The system 100 may be configured to adjust an 'Account Permissions' during the project assignment process.

[0082] In an embodiment, if 'Account Permissions' were not configured during the initial assignment, the employee may make the 'Account Permissions' any time during the project. The employee may need to login to the employee's account, deselect the modules and sub-modules that the employee want to restrict, and submit the changes. The restrictions may be applied based on the account type assigned to the employee, not on a per-project basis.

[0083] In an embodiment, the system 100 for managing access to contact numbers is illustrated. In the system 100, the head of the organization such as the founder and company partners may determine who can view the contact numbers of key-managers and the accounts-head. The key -managers and the accounts-head may be responsible for managing the visibility of contact numbers for all other employees, in conjunction with the founder and company partners. The contact numbers may be visible to other companies in the 'contact details in projects' section once permission has been granted. Additionally, the system 100 may be able to adjust the visibility of the contact numbers on an individual basis if needed.

[0084] In an embodiment, the system 100 provides several modules and sub-modules in the sidebar of each account. If an employee primarily access only a limited number of modules and sub-modules due to role limitations in the projects or for other reasons, the employee may hide the ones that the employee may not need from the sidebar. The employee may change 'Account Permissions' in 'My Profile & MISC Settings', deselect the modules and sub-modules that the employee don’t need, and then submit the changes to 'Edit User Profile'. The feature is available across all type of accounts on the ERP platform.

[0085] In an embodiment, seamless data integration and task management across the system (100) is illustrated further. During accessing data from a module or sub-module in the system, an employee may create a task or a communication in ProCom or ProChat that references this data. The employee may also attach any or all fdes uploaded in that module or sub-module to the task or communication. Similarly, when managing the task in task manager (TM), the employee may create the communication in ProChat or ProCom that refers to the data and files associated with the task, or employee may upload files directly to the relevant modules or sub-modules. Additionally, while viewing a communication in ProChat or ProCom, the emoployee may create a task related to it, referencing any files uploaded within that communication. Alternatively, the employee may upload files directly to the relevant module or sub-module based on the details of the communication they are reviewing. This interconnectivity not only simplifies how the employee interact with data across the ERP system, facilitating collaboration with both internal and external projects teams, but also eliminates the need to manually select project, subject, and other related fields when using the data.

[0086] In an embodiment, backup of account data is illustrated. In an embodiment, a head of the organization may be able to back up the account data for all projects. The system 100 manages backups project-wise, with each project having its own folder. Within each project folder, module names appear as sub-folders, and submodule names appear as sub-sub-folders. Each piece of uploaded data is stored in a separate folder named according to the attachment type, within the relevant sub-folder or sub-sub-folder. Further, files or documents attached to the uploaded data are saved in the same folder.

[0087] Since only the founder of the organization performs these backups, this approach ensures that multiple backups are not created within the organization. The system 100 notifies the head of the organization regarding the recent backup, allowing the head to compare the backup data with data on a local server to prevent duplication of effort. In one embodiment, the backups are taken one project at a time to optimize the process. After each project backup, the system 100 prompts the founder to decide whether to continue with the next project. The system 100 displays all available projects for backup at the start, allowing the founder to choose either all projects or specific ones.

[0088] In one aspect, data uploaded to any module tagged general is stored in a General folder, while data from the HR team and the Accounts team is kept in a separate 'HR and Accounts Management' folder. Further, quotations shared by the employee with the clients are also saved in the 'HR and Accounts Management' folder, under a sub-folder named Enquiries and Quotations.'

[0089] In an embodiment, incremental data entry with 'Save as Draft' Feature" is illustrated further. The 'Save as Draft' button, available in many modules at the submission stage, allows the data preparer to enter details incrementally, as item listing and data preparation often involve a lengthy process. After saving it as a draft, the preparer may have it reviewed by a designated senior before making the final submission for use by other team members.

[0090] In an embodiment, select or change recipients, for data being uploaded in the system 100 is explained further. When uploading a file, the employee may have the option to select or modify the recipients for that data. In some modules, there are 'default recipients' preset for the module, and the employee must 'select' additional recipients from the available list. In other modules, 'default recipients' are provided, but the employee must 'unselect' any recipients from the list if the employee does not wish to share the data with them. Once data is sent to a team, the data sharing may not be 'cancelled' just for that team or 'retrieved' from them. The employee may cancel the data for all recipients or delete it entirely, as described under the Delete Option, After Uploaded Data / File is Read' header.

[0091] In an embodiment, adding recipients, for already uploaded data in the system 100 is illustrated further. If the employee had uploaded some data but either forgot to select certain recipients or mistakenly unselected some, the employee may later 'Forward' the data. To do this, click the 'Forward' button in the 'Action' field of the table on the module's front-page. It's to be noted that data may be 'Forwarded' by anyone who has received the uploaded data to anyone who has not yet received it. It does not need to be limited to the uploading organization, the end-user, or the ultimately -affecting company.

[0092] In the report for the uploaded data, recipients who initially received it will be listed as 'First Recipients of the Data,' while those who receive it later may be listed as 'Subsequent Recipients of the Data.' The 'History' of who viewed the data and when is recorded and may be checked by hovering a mouse over the recipient’s company name. Similarly, the 'History' of who received the forwarded data and when is also tracked and may be viewed in the same way.

[0093] In an embodiment, if all recipients listed by the system 100 have been included when sending the data, or if anyone who was initially not included in the recipient list has been forwarded the data later, the 'Forward' button will no longer appear in the Action field.

[0094] In an embodiment, selecting and pinning approving authority, for efficient data Sending in the system 100 is illustrated further. The "Select the Next Approving Authority' feature is available in all modules and sub-modules, enabling the preparer or the employee to designate the appropriate senior, as defined by the organization management, to review the documents before they are submitted for everyone to view.

[0095] If the employee need to send data to a senior for approval and usually send it to the same person, the employee may 'pin' their name in the list of authorities on both the UPLOADING and APPROVAL forms within the respective modules or sub-modules. The feature helps the employee to avoid errors by quickly selecting the correct person and speeds up the data-uploading or approval process. Further, available on both forms, it streamlines the task of uploading or approving data and files, ensuring they are efficiently routed to the employee designated senior.

[0096] In an embodiment, employee-selected authorities within the modules and sub-modules, as well as the employee accounts team, accounts head, Key -Managers, organization partners, and founders, may view who has been designated as the 'Authority to send data' in the uploading and approval forms where the system 100 requires selection. Additionally, a 'History' of any changes the employee is making, is maintained and visible to both user and these authorities.

[0097] In an embodiment, the customized data approval process and revision tracking in the system 100 is illustrated further. In various modules or sub-modules where the employee has uploaded data requires senior approval, the employee may select the "Approving Authority" who will review and approve the employee data before it is visible to everyone. The feature allows companies to incorporate an intermediate checking or auditing step in the data upload process, if desired. The approver may use the "Send Back to Update" option to return the data to the employee for revisions and may add remarks for guidance. The entire workflow of sending, resending, and approving is meticulously recorded in the "History," offering a comprehensive view of revisions and enhancing overall work quality.

[0098] In an embodiment, expediting data approval process in the system 100 is illustrated further. In various modules or sub-modules with an approval process set up in the system 100, the system 100 requires the uploaded data to be approved by successive individuals within the organization(e.g., one person uploads the data, the next approver reviews and forwards it, then the subsequent approver does the same, and so on). However, if needed, the system 100 allows any subsequent approver to approve the data, even if the previousapprover has not approved the data. Once a subsequent approver has approved the data, the previous approver cannot approve the data. Further, the system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0099] In an embodiment, edit and delete option, immediate after uploading is available in the system 100 that is illustrated further. When the employee upload data or files for review and further processing in any module of the ERP platform, the employee may have the option to 'Edit' or 'Delete' them until they are accessed or read by another employee. Once the uploaded data or file has been viewed by the senior employee, the Edit' and 'Delete' options will no longer be available in the 'Action' field of the table on the modules front-page.

[0100] In an embodiment, delete option, after uploaded data / file is read that is illustrated further. In the embodiment, the Founder or organization Partners may delete all data only from employee’s account. To initiate this process, the employee need to submit a deletion request using the 'Delete' button in the 'Action' field of the table on the module's front-page. Once the employee request is approved by the Founder or organization partners, the data or file may be removed from the employee’s accounts, but it will still be retained on the system 100 server.

[0101] If retrieval of the data or file is needed, the founder or organization partners may contact the system 100 admin using the file's reference number. Further, details of deleted fdes may be viewed by the employee in a 'Trash Bin' tab under the 'My Profile and All Contacts' module. However, once a file is deleted, it cannot be downloaded or opened by anyone in employee’s company.

[0102] In an embodiment, deleting data from all accounts of all companies is illustrated further. The process of deleting data or files from all accounts across all companies may be initiated only by the founder or organization partners of the uploading organization. The request must then be confirmed by the founder or organization partners of the 'end-user organization' or the 'ultimately affecting organization,' or vice versa. It's important to note that while any employee of the organization may can start the deletion request, it must first receive approval from the founder or organization partners of the initiating employee's own company before it can be reviewed by the founder or partners of the affected company.

[0103] In an embodiment, for instance, if a drawing is uploaded by a design architect for a developer, the deletion of this drawing from all organization accounts on system 100 may be initiated by the founder or organization partners of either the design architect or the developer. The deletion of the uploaded drawing must be confirmed by the founder or organization partners of the developer or the design architect, depending on who initiated the request.

[0104] Similarly, if a structural consultant has engaged the services of an MEP consultant under their banner for a project with the developer, and the Developer has connected them separately to the respective account categories for uploading and sharing data with the organizations and the rest of the project teams. If an invoice is uploaded by the MEP Consultant to the Structural Consultant, the deletion request for the uploaded invoice may be initiated by the founder or organization partners of either the MEP consultant or thestructural consultant. The confirmation must come from the founder or organization partners of the organization that did not initiate the request.

[0105] In an embodiment, any employee of the organization who uploaded the file may initiate the deletion, and the founder or partners of the organization who uploaded the file must approve the deletion. Further, the founder or partners of the organization who were the end-users of the uploaded file to re-approve the deletion. In another embodiment, any employee of the organization who were the end-users of the uploaded file may initiate the deletion, and the founder or partners of the organization who uploaded the file must approve the deletion, the founder or partners of the organization who uploaded the file may initiate to reapprove the deletion.

[0106] In an embodiment, to delete a data file, any employee may initiate the process by submitting a deletion request to the founder or partners of their organization using the 'Delete' button in the 'Action' field of the table on the modules front-page. Upon receiving the request, the founder or organization partners must approve the deletion request. Once approved, the request is then sent to the founder or organization partners of the 'end-user organization' or the 'ultimately affecting organization' for final confirmation. Once the request is approved by both parties, the file is immediately removed from all accounts across all organizations. However, the data or file remains on the system’s server for 60 days. During this period, if either organization's founders or partners request retrieval, the system’s admin may recover the file. After 60 days, the file is permanently deleted from the system server. For file retrieval within the 60-day period, the founders or partners may contact the system admin with the file's reference number. Further, a deleted fde may be reviewed in the 'Trash Bin' tab under the 'My Profile and All Contacts' module, but it cannot be downloaded or opened by anyone in employee’s organization once deleted.

[0107] In some embodiment, when a file is initiated for deletion, its status in the 'Status of File' field in the module’s table updates to 'File Initiated for Deletion.' This change signals that the file is pending deletion and may be removed from all accounts at any time. Once a file is marked for deletion, it may not be downloaded or opened by anyone in the organization. If, after initiating the deletion, an employee wishes to cancel the process, they may click the 'Green Check' button available in the 'Action' field of the table on the module's front-page. This will revert the file's status from 'File Initiated for Deletion' to 'Active.'

[0108] In an embodiment, cancelling an uploaded file in the system 100 is illustrated further. An uploaded file may only be 'cancelled' by the team from the uploading company. To 'cancel' a file, click the 'X' button in the 'Action' field of the table on the module's front-page. Once a file is cancelled, it will no longer appear in the module's front-page table. However, if an employee needs to access a cancelled file, they may filter for 'cancelled' files within the module's front-page table to locate and view it.

[0109] In an embodiment, files categorized as 'BOQ: All Project Materials' and BOQ: All Project Works' cannot be cancelled, even if uploaded by the Developer or PMC team. These files may only be cancelled by the developer, partners, JV partners, Key -Managers, or the Accounts-Head. Further, a 'cancelled'file may be restored to 'active' status by clicking the V button in the 'Action' field of the table on the module's front-page.

[0110] In an embodiment, auto-cancellation of an uploaded file in the system 100 is illustrated further. If the employee uploads a data file or document with the same 'title of the attachment,' the previously uploaded data file or document with that title will be automatically 'Cancelled'.

[0111] In an embodiment, recording-history of changes, to uploaded file status is illustrated further. A 'history' of all changes to the 'status of file' is recorded and visible to everyone who has received the file. When data is uploaded and later re-uploaded multiple times due to changes, the 'history' page for each revision, including the most recent, will detail the date, time, and person responsible for each change from the first upload through all subsequent uploads. The comprehensive record allows anyone to review the evolution of the data. If the data is permanently 'cancelled' (with no further revisions), its 'history' may be accessed through the 'history' of the 'cancelled' data.

[0112] In an embodiment, a report button, to view details of uploaded data is illustrated further. Each module or sub-module has a 'report' button in the 'action' field of the table on the module's front page that provides detailed information about the uploaded data, including who uploaded it, which organization they are from, the date and time of the upload, all files associated with the data, all recipients and subsequent recipients of the data, and any remarks from the uploading person.

[0113] In an embodiment, comprehensive project awareness through the system’s acknowledgement process is illustrated further. It is essential for the project team to thoroughly review all drawings and documents related to the project. Staying vigilant and well-informed about project details is crucial for managing the inevitable challenges that arise during construction. Although projects are meticulously planned by experts, they are executed by a mix of skilled and unskilled labourers, which introduces the risk of unforeseen issues. Furthermore, difficult site conditions and unfavourable project locations may often add to the complexity. To ensure that both current and future team members are well-informed about project details, the system 100 features an 'acknowledgement' process in various modules and sub-modules. The process requires individuals to confirm that they have thoroughly read the relevant documents and resolved any questions they may have. The acknowledgment ensures that all team members are adequately prepared to manage forthcoming tasks and issues.

[0114] In an embodiment, setting a reminder, related to uploaded data is illustrated further. While uploading fdes or documents in any module, the employee may set reminders related to the uploaded data. The system 100 will then send a notification, containing the 'reminder note' created by the employee, at the specified date and time, to the employee.

[0115] In an embodiment, group chat management for uploaded data is illustrated further. In the embodiment, the employee may initiate a 'group chat' on any uploaded data by clicking the 'group chat' button in the 'Action' field of the table on the module's front page. The chat maybe visible to all recipients of the data.Further, recipients may not be added or removed in a 'group chat.' If a recipient is added later by forwarding the data to them, they will have access to all previous messages in the 'group chat' upon receiving the data.

[0116] In an embodiment, to address employee matter or query to everyone, start message with '@ALL'. This will ensure that all data receivers notice it and can respond if they have relevant information. However, if the employee want to direct the message to one or more specific recipients, start the message with '@<Receiver_Name>'. This will notify only the tagged individuals, though other recipients can still reply if they choose to.

[0117] In an embodiment, tagging '@ALL' or one or more recipients is required for the very first message in a 'Group Chat' on any uploaded data. For subsequent messages, the employee must either tag the previous message or use '@ALL' or tag specific recipients. Since multiple parties are involved in such chats, this process ensures that all relevant parties are notified appropriately.

[0118] In an embodiment, threaded chat management for uploaded data is illustrated further. In the embodiment, the employee may initiate a 'threaded chat' on any uploaded data by clicking the 'threaded chat' button in the 'action' field of the table on the module's front-page. Each chat message will be visible only to the previous participants in the discussion and to any new participant’s employee add while sending the message.

[0119] In an embodiment, the 'threaded chat' may only begin after the employee select its participants. At any stage of the 'threaded chat', the employee may add or remove participants. When adding new participants, the employee may choose whether to show them all previous messages in the thread or just the last 10 messages, or none at all. This allows new participants to understand the context of the ongoing discussion. The removed participants may no longer receive any further messages in the chat. Further, multiple 'threaded chats' may occur simultaneously, each with different or some common participants.

[0120] Figure 2 illustrates a block diagram (200) showing connectivity of multiple employees working on a project, in accordance with an embodiment of the present subject matter.

[0121] In an embodiment, the candidate's personal account and the candidate's changeable organization account’ on the system (100) is illustrated further. In an embodiment, candidates may be same as the employees working on the project, and the company may be same as the organization. The employees or candidates who are already associated with or aspiring to join any of the following business categories such as developer, architect / consultant, PMC, contractor, supplier, sub-contractor, financial institute, chartered accountant, security agency, and housekeeping agency must create personal accounts categorized as 'candidate's personal account' on the ERP platform of the system 100. The system 100 may facilitate connections with these categories top of form to connect an employee with the company, the company must send an invitation to the employee via the specific account type that aligns with the employee's role and responsibilities within the organization. Once a candidate or employee is connected, they gain access to their "company Account," which, as mentioned earlier, includes designated modules and sub-modules tailored to their role and responsibilities.

[0122] The system 100 allows the candidates to use the same user ID and password for both their candidate's personal account and their "company account." The tailored account design ensures that the sidebar links / modules in the employee's company account adjust based on the company category in which they are connected. As per one example, if an employee is connected with a developer company as a billing engineer, they will have access to specific sidebar links and modules relevant to that role. If the same employee later joins a contractor as a billing engineer, they will have access to a different set of sidebar links and modules tailored to the contractor's needs. In the "company account," employees will only have access to projects and data permitted by the system 100 admin of their company. As soon as a candidate is disconnected by the system 100 admin of their company, their "company account" becomes inaccessible. The system 100 prohibits any practice of moonlighting. Therefore, the candidate may have only one personal account on system 100 linked to a PAN and Aadhaar number, and may be associated with only one company at any given time. However, a company's accounts department may provide multiple accounts to the candidate based on their roles within the company. If the candidate is found to be active with more than one account on the system 100 by providing fabricated details. The system 100 reserves the right to suspend their account for a period deemed appropriate.

[0123] In an embodiment, the companies may register all their sister companies and offices to establish point-to-point connectivity with internal and external teams on the system (100) is illustrated further. In an embodiment, the companies may register their sister companies, providing all details such as CIN number, PAN number, GST number, bank details, billing address, etc. The company may link such details to the invoices they issue to their clients using the 'Invoice' module. This enables founders and partners to quickly and precisely track all invoices issued by any of their companies and all invoices raised for a particular client or project, without involving their accounts department. The developers and the contractors may connect their companies to each of their projects. By specifying the company associated with each project, they can inform vendors connected to the project about which company they should address their invoices to, ensuring a hassle-free experience. The companies may also register details of all their offices, regardless of location or country, providing information such as branch name, geographic location, office hours (in and out times), weekly off-days etc. Such provided details enable the system 100 to accurately track attendance for each employee and subsequently automate salary calculations for all employees.

[0124] In an embodiment, the system 100 is configured for connecting Architects / Consultants / Contractors / Suppliers / Financial-Institutes: Whenever a new Extemal-project-Team- member (user) is connected on any project by the system 100, an admin of the organization may choose data of which module / sub-module / link to be shared with him or not to be shared with him, by other teams, on all projects where he will remain connected. If required, later also the employee can remove / allow sharing of data to / by him by / to other teams through the system 100. The admin of the organization may also choose on which modules / sub-modules / link the new team-member must be permitted uploading / reply / commenting or shouldnot be permitted uploading / reply / commenting. In one embodiment, the office may be referred to as the organization.

[0125] The system 100 is configured for connecting Office-team-members / Sub-users. Whenever a new own Office-Team-member (user) is connected on any project by the system 100, the admin of any office can choose data of which module / sub-module / link to be shared with him or not to be shared with him, by other teams, on all projects where he will remain connected. If required, later also the employee may remove / allow sharing of data to / by him by / to other teams through the system 100. The admin of office can also choose on which modules / sub-modules / link the new team-member must be permitted uploading / reply / commenting or should not be permitted uploading / reply / commenting. These permissions of uploading / replying / receiving data in modules / sub-modules / links may differ as per the designations.

[0126] Further, personal data collection & personal info sharing by employees to their companies thru the system 100. Once a candidate is appointed & connected by any company to it, the company may share Appointment / Appreciation / Increment / Resignation / Termination Letters thru system 100. The company may track any person for his “In & Out Time” for his attendance at his registered Work-Place & his registered Visit-Places. His registered Visit-Places gets created automatically hence the process is simple. The system 100 has its own unique attendance system for preparing salary details of all connected employees in the company.

[0127] The plurality of employees can register their Conveyance & any other Claim thru the system 100. The salary & TDS / PT / PF / GST Reports gets automatically prepared for accounts based on all inputs received. Pay Slips are auto generated based on data accepted by accounts for all employees. The employees may submit their annual self-review report thru the system 100.

[0128] In an embodiment, control of Data-Flow / File-Sharing through the system 100 is illustrated further. Though the ERP system (100) has guided very meticulously whom to share which data in any project, whenever any data is uploaded / shared by any team-member he can separately control / stop sharing of his data being uploaded thru “Change Recipients” Or “Select Recipients” link provided in each module / sub- module / link.

[0129] In an embodiment, setting reminders for himself by the uploading person through the system 100. One can set reminder for himself related to each of his-uploaded-data / his-pending-reply / his-pending- comment / his-received-data.

[0130] The architects & Consultants Detail AND Developer's Suppliers and Contractors Detail AND Contractor's Suppliers and Sub-contractors Detail through the system 100. Without asking to anyone, as soon one is connected on any project (person may be from office of developer / architect / consultant / PMC / contractor / sub-contractor / supplier / financial-institute) he gets complete details (name & contact number) of every team-member on the project, working on it from all offices. As soon as a person changes / is-replaced at any office, one gets a notification of such change in the project-team. Hence, when a team-member changes at any office (whether at office ofdeveloper / architect / consultant / PMC / contractor / sub-contractor / supplier / financial-institute ), his office would neither be required to introduce him to anyone in the project-team / s nor would require to “handover” any project-docs to him, to take-things-forward from there on the project. His office-admin would be just required to connect him to the project. He will automatically get all project details / docs which his predecessor was supposed to handover him or that he may require to manage the project further at his designation.

[0131] In an embodiment, managing Consultant’s Quotes and Appointment Letters through the system 100. The system 100 provides exclusive / separate links for obtaining Quotes from the project Architects / Consultants, communicating with them for finalization & maintaining records for all such communications. Appointment-Letters to Architects / Consultants may also be shared / stored in separate links for ready reference anytime.

[0132] In an embodiment, All RFIs by Project-Design-teams & Concept Dwgs / 3Ds / Docs is illustrated further. The system 100 provides platform for raising RFIs (Request For Information) by each Project-Design-team and tracking of replies by concerned Project-team-members on these, till closer of any RFI. Concept-Drawings may also be shared by each Project-Design-team in prescribed links. Obtaining comments / reviews / replies / suggestions from other Project-team-members, for making necessary corrections, maybe tracked preciously. If there is any pending comment / review / reply for RFI / Concept-Dwg, they are reminded by the system 100 unless they do so.

[0133] The system 100 comprises a RFIs (requests for information) of project design team module. The module includes various features which are explained below in detail. In an embodiment, construction projects often span several years, during which the teams involved may change. This means that decisions and drawings might need revisiting if something questionable is noticed by a new team member. Documenting the decision-making process for designs and drawings is essential. The proposed RFI (request for information) of the project design teams module is a valuable tool for tracking every query raised by any project design team member during the process of finalizing project drawings. The RFI is submitted by a person or office to seek clarification on concerns, queries, or requirements from other project design teams, the developer, or the PMC. These concerns or queries may relate to drawings or designs received from others that are needed to advance their own designs, or they may involve requirements from the developer or other consultants necessary to progress with their designs. The developer, PMC, architects, and consultants must use this module to communicate and seek clarification on concerns, queries, or requirements from other project design teams.

[0134] In an embodiment, steps for addressing a general request for information (RFI) is illustrated further. The RFI raised by a project design team to other teams. In an embodiment, any project design team may submit an RFI to other design teams. When raising an RFI, the initiating team must notify relevant parties if the query could impact the project’s cost or timeline, especially if it involves alternative products or design methods. The RFI must specify the 'RFf response party' responsible for answering the query. However, other teams may also be included as 'recipients' if their input might be useful. This ensures that all potentiallyaffected or knowledgeable teams are informed and may contribute to the response. As the concerns, queries, or requirements raised by the RFI-raising person are of a 'general' nature, the wg / Document no about which the RFI is' field is not required to be filled in. In another embodiment, while replying to the RFI, any office member from the 'RFI response parties' or the 'RFI recipients' may participate in further discussions with the RFI-raising person to clarify their concerns, queries, or requirements. It is important that once the RFI is answered to the satisfaction of the person or office that raised it, they should click the 'close chat' button to end the chat.

[0135] In an embodiment, steps for addressing an RFI against a specific Dwg / document is illustrated further. The RFI raising person must provide the details of the 'Drawing / Document no. This type of RFI is generally raised from the 'All concept Dwgs / 3Ds / Docs', 'All GFCs: Dwgs / 3Ds / Docs', and ProCom modules after reviewing the drawings / documents received there. In an embodiment, these RFIs are not being shared with the site supervision teams of the developer and PMC, nor with the contractor's offices or their site supervision teams.

[0136] In an embodiment, Seamless RFI process for concept drawings, GFC drawings, and ProCom documents is illustrated further. The RFI regarding a drawing / document received in these modules may be raised directly by clicking the 'raise RFI' button in the 'action' field of 'all concept Dwgs / 3Ds / Docs', 'All GFCs: Dwgs / 3Ds / Docs', and ProCom modules. Clicking this button will automatically populate the document number in the rfi upload form, as provided by the system 100. This streamlines the RFI process, allowing a person to raise an RFI immediately and effortlessly after reviewing the received drawing / document.

[0137] In an embodiment, closing an RFI to save time for others is illustrated further. In an embodiment, once the RFI is answered to the satisfaction of the person or office that raised it, they should click the 'Close Chat' button to end the chat. This action not only ensures that all recipients are informed that the RFI has been resolved but also saves others time and energy by preventing further discussions on the concerns, queries, or requirements reported in the RFI.

[0138] In an embodiment, the reporting about RFIs replied and un-replied is illustrated further. When an architect or consultant submits an invoice to the developer, a detailed report on RFIs is automatically attached to the invoice. This report includes: Total RFI raised by user to other Project-Design-Teams, TILL DATE, Total RFI raised by user to other Project-Design-Teams, from last to current invoice, Total other Project-Design-Team's Unreplied RFIs from you, TILL DATE, and Total other Project-Design-Team's Unreplied RFIs from you, from last to current invoice.

[0139] The system 100 further provides RFIs for site execution team module. The module includes various features which are explained below in detail. In an embodiment, construction projects often span several years, during which the teams involved may change. As a result, decisions and drawings might need to be revisited if new team members notice any issues. Documenting the decision-making process for queries raised by site supervision teams of the developer, PMC, or contractors is essential. The RFI (Request For Information) by site execution team’s module is a valuable tool for tracking all queries raised by sitesupervision teams during the execution phase. An RFI is submitted by a person or office to seek clarification on concerns, queries, or requirements from project design teams, the developer, or the PMC. These concerns or queries typically relate to drawings or details received for execution purposes.

[0140] In an embodiment, steps for addressing a general request for information (RFI) is illustrated further. The RFI raising by a site supervision team to design teams / developer-office / PMC-office is explained further. Any site-supervision-team may submit an RFI to them. When raising an RFI, the initiating team must notify relevant parties if the query could impact the project’s cost or timeline, especially if it involves alternative products or execution methods. The RFI must specify the 'RFI Response Party' responsible for answering the query. However, other teams may also be included as 'recipients' if their input might be useful. This ensures that all potentially affected or knowledgeable teams are informed and may contribute to the response. As the concerns, queries, or requirements raised by the RFI-raising person are of a 'general' nature, the 'Dwg / Document no., about which the RFI is' field is not required to be filled in. In another embodiment, while replying to the RFI, any office member from the 'RFI Response Parties' or the 'RFI Recipients' may participate in further discussions with the RFI-raising person to clarify their concerns, queries, or requirements, it is important that once the RFi is answered to the satisfaction of the person or office that raised it, they should click the 'close chat' button to end the chat.

[0141] In an embodiment, steps for addressing an RFI against a specific Dwg / document is illustrated further. The RFI is raised and replied, but the RFI-raising person must provide the details of the 'Drawing / Document no. This type of RFI is generally raised from the 'all GFCs: Dwgs / 3Ds / Docs' and ProCom modules after reviewing the drawings / documents received there.

[0142] In an embodiment, the seamless RFI process for GFC drawings and ProCom documents is illustrated further. The RFI regarding a drawing / document received in these modules may be raised directly by clicking the 'raise RFI' button in the 'action' field of 'all GFCs: Dwgs / 3Ds / Docs' and ProCom modules. Clicking this button will automatically populate the document number in the RFI upload form, as provided by the system 100. This streamlines the RFI process, allowing a person to raise an RFI immediately and effortlessly after reviewing the received drawing / document.

[0143] In an embodiment, closing an RFI to save time for others is illustrated further. Once the RFI is answered to the satisfaction of the person or office that raised it, they should click the 'close chat' button to end the chat. This action not only ensures that all recipients are informed that the RFI has been resolved but also saves others time and energy by preventing further discussions on the concerns, queries, or requirements reported in the RFI.

[0144] In an embodiment, reporting about RFIs replied and un-replied is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on RFIs is automatically attached to the invoice. This report includes total RFI raised to user by site-supervision-teams TILL DATE, total RFI raised to user by site-supervision-teams, from Last to Current Invoice, total sitesupervision team's unreplied RFIs from you TILL DATE, and total site supervision team's unreplied RFIs from you, from last to current invoice.

[0145] The system 100 provides a list and status of all as-built Dwgs. The list of as-built drawings and documents is automatically updated in the list and status. All as-built Dwgs' modules of the system 100 as GFCs are issued. This module ensures that design offices do not miss issuing any final updated as-built drawings or documents, even if team members at the design office or developer office change during the project. It helps new team members stay informed about all issued project drawings and the list of involved consultants.

[0146] In an embodiment, adding, deleting, and strikethrough of DWG titles in the system 100 is illustrated further. The title list of as-built is automatically updated in the system 100. It includes the titles of all uploaded GFC drawings and documents for the project, allowing design offices (architects and consultants) and the developer's office to reference it when preparing and issuing the final as-built drawings and documents. However, it contains only the titles that are 'active' in the GFC drawings and documents, excluding titles of any 'cancelled' drawings and documents. If a design office decides to combine two DWGs or not upload a DWG for a title, it may mark the existing title as 'strikethrough,' but it cannot be 'deleted' or 'cancelled.' If a DWG with a new title is uploaded, the new title will appear in the list as soon as the DWG is added.

[0147] In an embodiment, titles in as-built lists are automatically updated by the system lOO.The list of as-built drawings and documents is automatically updated in this module. This as-built list must also include the 'date of uploading' to show when each GFC drawing / document was uploaded by the concerned office. The history of each uploaded GFC drawing / document, including all revisions, may be viewed by accessing the 'history' button in the 'action' field of the 'list and status of all as-built Dwgs' module. By accessing this button, one may check when the first drawing / document was uploaded under this title and how many times it has been revised.

[0148] In an embodiment, report on all issued as-built drawings and documents is illustrated further. When an architect or consultant submits an invoice to the developer, a detailed report on 'all issued as-builts' is automatically attached to the invoice. This report includes: A list showing the title of Dwg / Docs, GFC issuance date, as-built issuance date, no. of prints issued by consultant, from 1st upload to current invoice, and A list showing the title of Dwg / Docs, GFC issuance date, as-built issuance date, no. of prints issued by the consultant, which were uploaded between last to current invoice.

[0149] The system 100 provides all as-built: Dwgs / docs modules. In an embodiment, as-built drawings and documentation are crucial because they provide an accurate record of the completed construction, reflecting any changes made during the project. They serve as a reference for future maintenance, renovations, or repairs, ensuring that all modifications are documented. These records are essential for regulatory compliance and may assist in resolving disputes. Accurate as-built documentation also supports efficient project handover and facilitates better planning for future projects. Since the list of as-builtdrawings and documents is automatically updated in the list and status: all as-built Dwgs module of the system 100 as GFCs are issued, the all as-built: Dwgs / Docs' module tracks and reports until the as-built drawings / documents are issued by the project consultants.

[0150] In an embodiment, steps for uploading as-built Dwgs / Docs is illustrated further. The project design team may upload their as-built drawings, 3Ds, hand sketches, and documents to a designated link for the developer's or PMC's record-keeping. When a design office uploads a drawing, the 'list of as-built Dwgs' is visible when selecting the 'title of the Dwg.' If the title is not available in the system's prepared 'list of as-built Dwgs,' they may select 'add Dwg title' during the upload process to include it. In another embodiment, the system 100 provides features of uploading as-built 3Ds / Docs. The design office (architect or consultant) must categorize their other files properly when uploading them, distinguishing between 3Ds and documents.

[0151] In an embodiment, mandatory PDF uploading is illustrated further. In an embodiment, uploading a PDF of all DWGs is mandatory in the as-built module. This allows developers or others who are less familiar with AutoCAD to view the uploaded data, should they need to process it further.

[0152] In an embodiment, scheduling prints for stakeholders during file upload is illustrated further. The person uploading fdes from the design office may directly schedule prints of the uploaded drawings and documents for the developer or PMC by instructing their office’s plotting personnel during the upload process. If additional prints are required, the drawing developer may inform the plotting person by accessing the 'print' button in the 'action' field within the module. In one embodiment, record-keeping for issued prints of as-built Dwgs / Docs is illustrated. In the embodiment, the print issuing process is closely linked with each as- built drawing or document issued, tracking the prints sent to the developer’s office or PMC office may be effectively managed for record-keeping purposes.

[0153] In one embodiment, reporting about issued as-built Dwgs / Docs is illustrated. In the embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on 'issued as-built Dwgs / Docs is automatically attached to the invoice. This report includes: Total issued as-built Dwgs / Docs by you, TILL DATE, Total issued as-built Dwgs / Docs by you, from Last to Current Invoice, Total pending as-built Dwgs / Docs (as per system 100 generated list), TILL DATE, and Total pending as-built Dwgs / Docs (as per system 100 generated list), from last to current invoice.

[0154] In an embodiment, project Cost Management and Project Time-Line tracking / management through the system 100 is illustrated further. The system 100 helps / direct Project-team-members (users) to share data related to Cost & Timeline in the exact-required category of doc (List-of- Amenities / Estimates / Monthly-Information-System / Cost-Tracking-Sheet / Project-Schedules / Project- Milestones / Chart-of-current-Project-Status etc.). System’s data-sharing-process and location is designed in such a way that even if the organization is managing any-number of projects, the data may be searched / accessed by a user very easily in future.

[0155] In one embodiment, cost tracking sheet helps the developer in keeping track of Estimated- amount Vs WOs-POs-amount Vs Actual-Executed-amount. Here, an actual executed data gets automatically updated along with each invoice getting certified thru system 100.

[0156] In an embodiment, List & Status of All GFC Dwgs / 3Ds / Docs, All GFCs Dwgs / 3Ds / Docs and All RFIs by Project-Execution-teams related to the issued GFCs supported through the system 100 is illustrated further.

[0157] The system 100 facilitates tracking List & Status of All GFC Dwgs with respect to the scheduled date mentioned there and then reminding Dwg-controllers (i.e. Architects / Consultants) to issue GFCs for timely completion of the project until it is uploaded / issued by them.

[0158] All Dwg-controllers (i.e. Architects / Consultants) to share their All GFC Dwgs / 3Ds / Docs / Hand-sketches thru the specified module / link provided there. They are supposed to upload PDFs also for all their uploaded Dwgs.

[0159] Special feature of the system 100: Once a person takes out prints of downloaded PDF of the GFCs, uploading Company Name and uploading Date & Time gets printed on such taken prints. This feature helps in eliminating the biggest confusion on construction sites i.e. whether all Site-teams / Contractors are carrying the latest issued Dwg or not. Whether all Site-teams / Contractors working at site are carrying the same Dwgs or not for their working may also be checked very easily, even if a designer team has not mentioned revision no. & revision date on the issued Dwgs. Site-team / Contractor may also request for additional prints thru the system 100.

[0160] As the GFCs are uploaded by Dwg-Controllers, List of As-built is automatically gets created for the project so that Developer may ask Dwg-Controller to issue As-Built of all issued GFCs.

[0161] The system 100 comprises a list and status of all GFC Dwgs module. The module includes various features which are explained below in detail. In an embodiment, once the developer's office approves the 'concept' drawings and documents, the design offices (architects and consultants) must prepare a list of GFC (Good for Construction) drawings and documents. The developer / PMC’s project planning and coordination teams will then provide a 'scheduled issuance date' for each drawing or document in alignment with the project execution schedule. Design offices are expected to adhere to these scheduled dates to help keep the project on track. The list and status of all GFC Dwgs module of the system 100 helps to share drawing lists from each architect / consultant with the rest of the project teams, obtain 'scheduled issuance date' for each drawing / document from the planning and coordination teams, and tracks the actual issue dates by the respective design offices.

[0162] In an embodiment, steps for uploading or creating the list of good for construction (GFC) Dwgs / Docs is illustrated further. In an embodiment, the module provides a feature for uploading / creating the list of drawings and documents. The design office (architect or consultant) may choose whether to 'create' or whether to 'upload' the list of GFC Dwgs & Docs. Only one Dwg-List may be uploaded / created per project per wing. Hence, design office must make a consolidated single list of all dwgs & docs which are expected tobe issued by them for a wing in the project. In another embodiment, the module provides a 'scheduled issuance date' for each listed Dwg / Doc. Once the design office (architect or consultant) prepares the list of GFC drawings / documents, the developer / PMC’s project planning & coordination teams provide a 'scheduled issuance date' for each design office are expected to adhere to the scheduled dates.

[0163] In an embodiment, adding, deleting, and strikethrough of DWG titles is illustrated further. In an embodiment, after uploading a list, if a design office decides not to upload a DWG for a title it had previously added, the DWG title may be 'deleted' if the 'scheduled issuance date' was not provided. However, if the 'scheduled issuance date' was provided, the dwg title cannot be 'deleted' or 'cancelled'. Instead, it should be marked as 'strikethrough'. A new DWG title may be added and positioned anywhere in the list. If a new DWG with a different title is uploaded, the newly titled DWG will appear at the bottom of the list.

[0164] In an embodiment, recording of 'actual issuance date' of Dwg / Doc is illustrated further. Once the designated office prepares the list of GFC drawings / documents, the developer / PMC’s project planning and coordination teams provide a 'scheduled issuance date' for each. When a drawing / document is uploaded for the first time, the 'first actual issuance date' is recorded. If a revised version is uploaded, the 'most recent issuance date' is updated. If there are no revisions, only the 'first actual issuance date' is filled, and the 'most recent issuance date' remains blank.

[0165] In an embodiment, maintaining 'history' of Dwg revisions is illustrated further. The history of each uploaded drawing / document, including all revisions, is saved under the 'history' button in the 'action' field of the 'list & status of All GFC Dwgs' module. By accessing this button, one may check when the first drawing / document was uploaded under this title and how many times it has been revised.

[0166] In an embodiment, alert for Design Offices: Upcoming GFC Preparation Required. In an embodiment, taking into account the 'scheduled issuance date' provided by the developer / PMC’s project planning & coordination teams, the system 100 notifies the design offices 7 days before a deadline approaches for issuing the GFC, helping to keep the project schedule on track.

[0167] In an embodiment, Dwg-list upload and cancellation policy is illustrated further. In an embodiment, only one Dwg-list may be uploaded / created per project per wing. Once scheduled issuance dates are set by the developer / PMC teams, the Dwg-List cannot be cancelled. Designer offices may cancel it only with permission from their founder, partners, or key-managers. This ensures senior team oversight of finalized Dwg-Lists shared with project teams.

[0168] In an embodiment, Report on all issued GFC drawings and documents is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on all issued GFCs is automatically attached to the invoice. This report includes: a list showing the title of Dwg / Docs, scheduled issuance date, first actual issuance date, most recent issuance date, no. of revisions till date, no. of prints issued by consultant, from 1st upload to current invoice, and a list showing the title of Dwg / Docs, scheduled issuance date, first actual issuance date, most recent issuance date, no. of revisions till date, no. of prints issued by consultant, which were uploaded between last to current invoice.

[0169] The system 100 provides all GFCs OF Dwgs / 3Ds / Docs module. The module includes various features which are explained below in detail. In an embodiment, the good for construction (GFC) module streamlines the upload and management of construction documents, including GFC drawings, 3Ds, and hand sketches. It features automatic printing of the file number, uploading date, and time on all four sides of PDFs, making revision tracking straightforward even if the design office omits the revision number. This allows users to verify they have the latest version by comparing these details with the most recent file available in the system’s module. Additionally, the system 100 enables direct scheduling of prints and tracks document issuance for accurate record-keeping, while mandatory PDF uploads ensure that files are accessible to those who are less familiar with AutoCAD for viewing the uploaded data.

[0170] In an embodiment, steps for uploading a good for construction (GFC) Dwgs / 3Ds / Docs is illustrated further. The project-design-team may upload their GFC drawings, 3Ds, hand sketches, and documents to their designated link for use by the site-supervision-teams during construction. When a design office uploads a drawing, the 'list of GFC Dwg' is visible to them when selecting the 'title of the drawing.' If they have missed including any drawing in their 'list of GFC Dwgs,' they may select 'add Dwg title' during the upload process to include it. In another embodiment, the module includes features for uploading 3D / hand sketches / Doc for site supervision teams to follow. The design office (architect or consultant) must categorize their other files properly when uploading them, distinguishing among 3Ds, hand sketches, and documents. If the site supervision team requires additional details after a GFC (good for construction) has been issued for better clarity or if something was missed in the drawings or if the design team needs to share hand sketches with the site supervision team for reference during construction, the design office should use the 'hand-sketch' title when sharing these files.

[0171] In an embodiment, verification of the latest drawing version with site teams is illustrated further. The system 100 prints the file number and uploading date & time at the centre of all four sides of the uploaded PDFs. When someone downloads and prints the PDF file, these details will appear on the printout. If there is any confusion about whether the drawing is the latest version or an outdated / cancelled one, the person may access the GFC module to check the file number and uploading date & time of the latest file in the system 100 with the same title. They may then compare these details with those on the drawing to ensure they have prints of the most current version.

[0172] In an embodiment, mandatory PDF uploading is illustrated further. In an embodiment, uploading a PDF of all DWGs is mandatory in the GFC module. This allows developers or others who are less familiar with AutoCAD to view the uploaded data, should they need to process it further.

[0173] In an embodiment, scheduling prints for stakeholders during file upload is illustrated further. The person uploading fdes from the design office may directly schedule prints of the uploaded drawings and documents for the developer, PMC, or site-supervision teams by instructing their office’s plotting personnel during the upload process. If additional prints are required, the drawing developer may inform the plotting person by accessing the 'print' button in the 'action' field within the module.

[0174] In an embodiment, record-keeping for issued prints of GFC Dwgs / Docs is illustrated further. Since the print issuing process is closely linked with each GFC drawing or document issued, tracking the prints sent to the developer’s office, PMC office, or site-supervision-teams may be effectively managed for record-keeping purposes.

[0175] In an embodiment, reporting about GFC Dwg / Docs issued is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on GFC Dwgs / Docs issued is automatically attached to the invoice. This report includes: Total GFC Dwgs / Docs issued by you, TILL DATE, Total GFC Dwgs / Docs issued by you, from last to current invoice, Total Prints of GFC Dwgs / Docs issued by you, TILL DATE, and Total Prints of GFC Dwgs / Docs issued by you, from last to current invoice.

[0176] In one embodiment, instructed changes, in the issued GFSC module. The module includes various features which are explained below in detail. In an embodiment, after GFC (Good For Construction) drawings are issued and execution starts, visiting consultants may suggest minor changes based on site conditions or omissions. These changes are documented in the 'site inspection report' module of the system 100. However, finding and incorporating these changes into as-built drawings may be impractical due to the volume of reports, the 'instructed changes in issued GFCs' module helps the design offices (architects and consultants) track changes suggested by visiting personnel during site checks, preventing omissions in as-built drawings. Site supervision teams should upload these changes under the relevant architect or consultant’s name. The design offices then need only instruct their draftsmen to update the GFCs accordingly. To simplify it for the design offices, the site supervision teams should also note the file / document number where these changes are expected to be incorporated. By using this module effectively, the site supervision teams may ensure that every suggested change by architects or consultants is incorporated into the final as-built drawings issued to the developer’s office.

[0177] In an embodiment, step for uploading instructed changes, in issued GFCs is illustrated further. In an embodiment, upload a photo or pdf of details of instructed changes, where all execution-ready work at the site must be reviewed by the corresponding consultant. The site supervision teams of developers, PMCs, or contractors (whichever is available at site) must receive instructions from the visiting consultant regarding any changes required in the issued GFCs. Typically, the visiting consultant notes such changes in the 'site inspection report,' allowing the site supervision teams to upload a photo of the noted changes. If the visiting consultant provides verbal changes to the GFCs, the site supervision teams should document these instructions on paper and then upload a photo of that document.

[0178] The site supervision teams must upload these documents into the visiting consultant’s account category so that the consultant’s office may download and incorporate the changes into the as built drawings issued at the end of the project. For example, if a structural consultant conducts an audit and instructs changes to their issued GFCs (whether noted or verbal), the site supervision teams should select 'structural consultant'from the available categories in 'Dwg Controller Type' when filling out the upload form and then upload the changes accordingly.

[0179] In an embodiment, improvements through tracking written and verbal changes is illustrated further. In an embodiment, uploaded reports from consultants are categorized into written notes and verbal instructions. This approach improves service quality by ensuring that only written notes are issued during site visits. Systematically documenting verbal instructions helps resolve discrepancies during reconciliation, especially if such instructions lead to significant material usage. By tracking these changes, developers and consultants may plan projects more effectively, minimizing on-site alterations and ensuring timely, cost- controlled execution.

[0180] In an embodiment, as-built accuracy through change tracking is illustrated further. In an embodiment, uploading the instructed changes directly to the designated link for each consultant ensures that updates from site visits are effectively communicated. This process helps ensure that the consultants incorporate these changes into their as-built drawings for accurate record-keeping. Maintaining precise and well-organized documentation contributes to the creation of more accurate As-Built drawings, which are essential for future reference.

[0181] In an embodiment, reporting about instructed changes in issued GFCs is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on 'instructed changes in issued GFCs' is automatically attached to the invoice. This report includes: Total instructed changes in issued GFCs by you, TILL DATE, Total instructed changes in issued GFCs by you, from last to current invoice, Total Instructed changes through site inspection report, TILL DATE, Total Instructed changes through site inspection report, from Last to Current Invoice, Total Instructed changes through verbal instructions, TILL DATE, and Total Instructed changes through verbal instructions, from last to current invoice.

[0182] The system 100 provides platform for raising RFIs (Request For Information) by each Project-Execution-team and tracking of replies by concerned Project-Design-team on these, till closer of any RFI. If there is any pending comment / review / reply for RFI, they are reminded by the system 100 unless they do so.

[0183] The system (100) comprises all concept Dwgs / 3Ds / Docs module. The module includes various features which are explained below in detail. In an embodiment, during the planning stage of a project, many drawings and documents are prepared, known as 'concept' stage drawings and documents. Feedback from various agencies is crucial for accurate planning, which ensures quality execution and controlled pricing. Each drawing or document should receive input from all relevant teams and individuals, and these suggestions need to be well documented. The concept stage in projects often spans several months (sometimes even years), during which the teams involved may change. Without a tracking system, managing feedback and the sequence of feedback may become confusing, leading to a loss of valuable time. Consequently, the document developer and coordinator may be required to spend significant time trackingresponses, managing the sequence of feedback, and addressing team changes at other offices. The system’s all-concept Dwgs / 3Ds / Docs module addresses these issues by tracking all comments on uploaded drawings, 3Ds, and documents. It shows which comments are pending from the recipients of the drawings / 3Ds / documents and who has provided feedback in what sequence, streamlining decision-making and reaching conclusions.

[0184] In an embodiment, steps for commenting a concept Dwg uploaded by others is illustrated further. In an embodiment, a project design team may upload their concept Dwg / Doc in their respective link for other offices to provide their comments. In another embodiment, any office member from the 'Recipients' group may comment on the uploaded concept Dwg / Doc. It is important that once the expected or required comments have been received to the satisfaction of the person or office that uploaded the document, they should click the 'close chat' button to end the chat. Any office member or person may comment multiple times on an uploaded concept Dwg / Docs. In an embodiment, concept Dwg / Docs are not visible to the sitesupervision teams of the developer and PMC, nor to the contractor's offices or their site supervision teams.

[0185] In an embodiment, only the most recent file receives the comments. In an embodiment, if someone uploads a new drawing or document with the same title as a previously uploaded one, the previously uploaded drawing or document is automatically marked as 'Cancelled.' Therefore, if a person has not reviewed the uploaded drawings or documents for a while, and in the meantime, the document has been revised multiple times by another office, they will only see the most recent file. They will provide comments based on this latest version without needing to identify the most recent document. The system 100 process ensures that other offices do not waste time and energy commenting on outdated drawings or documents.

[0186] In an embodiment, automatic closure of commenting process upon revised file upload is illustrated further. In an embodiment, if a revised drawing or document is uploaded under a title, not only is the previous drawing or document marked as 'Cancelled,' but the chat opened for comments on that file is also automatically 'Closed' for all recipients. This feature ensures that other offices do not waste time commenting on outdated drawings or documents, thereby saving time and resources.

[0187] In an embodiment, closing of commenting process to save time for others is illustrated further. Once the required comments have been received and meet the needs of the person or office that uploaded the drawing or document, they should click the 'Close Chat' button to end the conversation. This action not only informs all recipients that the necessary comments have been received and that the uploading office has begun addressing them, but it also saves time and energy by preventing further discussions on the uploaded drawing or document.

[0188] In one embodiment, reporting about concept Dwg / Docs issued, commented, or not- commented is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on concept drawings / documents indicating which were issued, commented, or not commented is automatically attached to the invoice. This report includes total Concept Dwgs / Docs issued by you TILL DATE, total Concept Dwgs / Docs issued by you, from last to current invoice, total other Project-Design-Team's Concept Dwgs / Docs Commented by you TILL DATE, total other Project-Design-Team's Concept Dwgs / Docs Commented by you, from Last to Current Invoice, total other Project-Design-Team's Concept Dwgs / Docs Not-Commented by you TILL DATE, and total other Project-Design-Team's Concept Dwgs / Docs Not-Commented by you, from last to current invoice.

[0189] In one embodiment, reporting about concept Dwg / Docs issued, commented, or not- commented is illustrated further. In an embodiment, when an architect or consultant submits an invoice to the developer, a detailed report on concept drawings / documents indicating which were issued, commented, or not commented is automatically attached to the invoice. This report includes: Total Concept Dwgs / Docs issued by you, TILL DATE, Total Concept Dwgs / Docs issued by you, from last to current invoice, Total other Project- Design-Team's Concept Dwgs / Docs Commented by you, TILL DATE, Total other Project-Design-Team's Concept Dwgs / Docs Commented by you, from Last to Current Invoice, Total other Project-Design-Team's Concept Dwgs / Docs Not-Commented by you, TILL DATE, and Total other Project-Design-Team's Concept Dwgs / Docs Not-Commented by you, from last to current invoice.

[0190] Instructed changes, in issued GFCs AND Notified MISC Imp. Project-Matters thru the system 100. Instructed changes in the issued GFCs shared files will help Dwg-controllers (i.e. Architects / Consultants) in generating their As-built Dwgs once the project is completed. Notified MISC Imp. Project-Matters will provide tool to the Developer / Architects / Consultants / PMC to issue important notifications to all / specific- team-member at any stage of the project. Such issued notification would be reminded by the system 100 to the person / team-member as per the mentioned / saved Mile-Stone / Date in the notification.

[0191] List & Status of All Supplies & Contracts supported through the system 100. Thru system 100, tracking List & Status for Supplies & Contracts for Developers & Contractors is made easy, with respect to the scheduled date mentioned there and then reminding Project-Planning-Coordinators to appoint Vendors for timely completion of the project, until it is done by them.

[0192] Material Management of Developer's Material, Material Management of Contractor's Material AND Material Management of Sub-contractor's Material through the system 100. Material Management for Developers / Contractors / Sub-contractors includes tracking BOQs of all Project Materials, raising Indents, receiving Quotes, sharing Comparatives & taking approvals, issuing POs, sharing details of Dispatched- Materials by the Suppliers, making Inventory by Security of the received Materials, making Inventory by Sitestore of the received Materials, maintaining details of Material Issued by the Site-store, Issuing Gate-passes to materials being Dispatched-out-from-Site, Stock Status @ Site-Store (Received V / s Issued V / s Dispatched- out-from-Site), making Inventory by CENTRAL-STORE of the received Materials, maintaining details of Material Issued by the CENTRAL-STORE, Issuing Gate-passes to materials being Dispatched-out-from- CENTRAL-STORE, Stock Status @ CENTRAL-STORE (Received V / s Issued V / s Dispatched-out-from- Site) & All Material Complaints to the Suppliers etc.

[0193] The system comprises a status of material / machinery stock @ CENT-stores module. The module includes various features which are explained below in detail. The CENTRAL-STORE stock module is designed to optimize inventory management by providing automatic notifications and detailed reporting. The module ensures that project site teams' Material Requisition Slips (MRS) are matched with available stock, preventing overlooked orders. The module also alerts the Purchase / Accounts Dept about materials approaching expiration or unused for extended periods, enabling timely actions and informed decisionmaking. This system 100 enhances stock control, reduces wastage, and ensures efficient inventory utilization.

[0194] In an embodiment, automated material stock notifications is illustrated further. For maintaining an up-to-date stock record ensures that when project site teams submit Material Requisition Slips (MRS) for any material type, the Purchase / Accounts Department receives an automatic notification if a matching material type (even with different specifications) is available in CENTRAL-STOCK. This prevents the material from being overlooked for ordering. If the Purchase / Accounts Department deliberately ignores this notification, the system 100 alerts the approving authorities to ensure that the authorities are informed of the situation.

[0195] In an embodiment, automated machinery and scaffolding stock notifications is illustrated further. In an embodiment, for maintaining an up-to-date stock record ensures that when project site teams submit Material Requisition Slips (MRS) for any machinery / scaffolding-material. The Purchase / Accounts Department receives an automatic notification if a machinery / scaffolding-material is available in CENTRALSTOCK. This prevents the machinery / scaffolding-material from being overlooked for ordering. If the Purchase / Accounts Department deliberately ignores this notification, the ERP system 100 alerts the approving authorities to ensure they are informed of the situation.

[0196] Alert reports by ERP system 100 for stock @ CENT-STORES. In an embodiment, various reports are prepared by the system 100 related to material stock @ CENTRAL-STORE. The reports include: alert for the Purchase / Accounts Department about materials which are there in CENTRAL-STORE that will expire in the next 30 days, and alerts for the Purchase / Accounts Department if any materials in the CENTRAL STORE have not been used in the past 180 days

[0197] The system 100 provides the status of the material stock of the site-store module. The module includes various features which are explained below in detail. The Site-Stock module is designed to track the Total Received Materials of the Site-Store, compare them with Materials Issued to Contractors, and monitor the Total Materials Dispatched Out of the Site along with the Remaining Stock of the Materials of the Site- Store. This comparative sheet is automatically updated as data is entered in various other modules. By maintaining up-to-date data, the system 100 facilitates the timely creation of material requisition slips (MRSs), ensuring efficient engagement of the contracting team and uninterrupted progress, which enhances the final product's quality. Additionally, it enables the site team to manage material usage effectively by prioritizing the use of older materials first, thus minimizing waste due to expiration.

[0198] In an embodiment, alerts, discrepancy, and confirmation reports by the system 100 is illustrated further. Various reports are prepared by the system 100 related to the material receipt and use at the site. The reports include: alert for the project teams about materials that will expire in the next 30 days, alerts for the project teams if any materials in the site store have not been used in the past 180 days, alert for tracking daily average consumption, lead times provided by the head office for material delivery from the date of MRS receipt, and the duration of the material order process from MRS to receipt alerts project teams to raise MRSs and issue POs to vendors in a timely manner. This results in the timely completion of projects and optimizes cash flow allocations. The alert are further sent to the Site Team of the Developer / PMC / Contractor to check and confirm that excess issued materials by the developer are not left scattered on floors unattended. Their acknowledgment is recorded in the 'History of Material Mismanagement (HMM)' button, allowing everyone to see that material usage and wastage are being effectively tracked by the project teams.

[0199] The system 100 comprises a Bill of Quantities (BOQ) module for all project-materials module. The module includes various features which are explained below in detail. The Bill of Quantities (BOQ) module ensures accurate and controlled management of project materials by detailing procedures for listing, editing, and cancelling BOQs. The BOQ module allow flexible and incremental updates while maintaining consistency in material specifications and quantities. The module facilitates collaboration between stakeholders and streamlines the requisition and ordering process. By enforcing strict control and documentation, this helps to manage costs, ensure quality, and track performance.

[0200] In an embodiment, steps in uploading / creating and changing BOQ items is illustrated further. In an embodiment for uploading or creating BOQ, the BOQ is prepared by authorized persons at PMC or developer office. A type of work may appear only once in the BOQ. Similarly, a type of material with a specific specification may be listed only once for each type of work. When uploading the BOQ, ensure that all relevant AutoCAD, excel, and word files are also uploaded and attached to the corresponding type of material for future reference. A BOQ may be 'uploaded' by first downloading the format excel file and then filling it out according to the sample provided.

[0201] Alternatively, a BOQ may be 'created' directly in the system 100 following the instructions provided in the guided video support. The 'Save as Draft' button at the submission stage allows the BOQ preparer to enter details incrementally, as a BOQ usually involves a lengthy list of items. After saving it as a draft, the preparer may have it reviewed by a designated senior before making the final submission for use in MRS / PO. In another embodiment, for adding a new type of work to the existing BOQ, a new type of work may be added at any time by authorized persons without anyone's permission. In another embodiment, editing, adding, or deleting a type of material in the existing BOQ option is available in the system 100.

[0202] If an authorized person wishes to edit, add, or delete a type of material in any type of work within the existing BOQ, then the authorized person must submit a request to the developer's office. Approval may only be granted by the founder, partners, key managers, or accounts head at the developer's office. Updated items are highlighted separately to ensure they are easily noticeable.

[0203] In an embodiment, BOQ control and approval protocol is illustrated further. Only one BOQ may be 'Active' per project at a time and may only be 'Cancelled' by the founder, partners, key-managers, or accounts-head. A BOQ cannot be 'Edited' without their permission. Only one person may be granted permission to 'Edit' the BOQ at a time. The authorized personnel will see which items have been 'Edited' or 'Deleted' and will receive a history of changes for review. This strict control over the BOQ ensures they have full authority over the items being indented and purchased for the project.

[0204] In an embodiment, BOQ listing and specification guidelines is illustrated further. In an embodiment, a type of work may appear only once in the BOQ. Similarly, a type of material with a specific specification may be listed only once for each type of work. However, if the same type of material has different specifications, it may be included in the BOQ for the same type of work. Items originally entered in the BOQ are termed as 'Listed,' while those that are subsequently identified, approved, and added to the BOQ are referred to as 'Un-Listed.'

[0205] As per one example of the one embodiment, a type of material with a specific specification may be used across different types of work. For example, 43 -grade cement may be listed in the BOQ for civil, waterproofing, and flooring. However, it cannot be listed more than once for each of these types of work. This method ensures that the BOQ preparer effectively consolidates material quantities for each type of work.

[0206] In an embodiment, incremental BOQ updates and material control is illustrated further. In an embodiment, a type of work may be added to the project BOQ at any stage, allowing for flexible, incremental management. However, once a type of work is included, all related types of material and their specifications must be listed simultaneously. Therefore, the BOQ for a type of work should not be finalized until all items are agreed upon by both the architect and the developer. This ensures collaborative decision-making and maintains consistent cost and quality control. This approach also enables flexible management of material quantities through MRS and POs.

[0207] When requisitioning a type of material, the focus is on the quantity needed for that specific type of work at the site. The ordering process involves specifying the type of work associated with the material and its specifications, which streamlines automatic reconciliations. If the material is later used for another type of work, it may be tracked via the material issued register. Comparing the BOQ with Indents, POs, and the Issued Register helps to identify and address any discrepancies.

[0208] In an embodiment, handling 'Un-Listed' materials and the impact of BOQ errors is illustrate further. In an embodiment, new types of material often arise due to misunderstandings by the quantity surveyor or changes in planning. If a new type of material needs to be indented, the site team may proceed to avoid project delays. Once the material is indented and approved by the planning department, it is added to the BOQ as an 'un-listed' item for final approval by the founder, partners, key-managers, or accounts-head of the developer. After receiving this approval, a PO may be issued. During this process, the purchasing department may gather quotes and prepare the PO, but it will only be finalized once the BOQ update is approved. Theerror originated with the BOQ preparer but increased the workload for the entire team. Consequently, it is documented and negatively impacts the BOQ preparer’s annual performance review by the ERP system 100.

[0209] In an embodiment, reporting of Un-Listed BOQ materials is illustrated further. In an embodiment, the performance review of quantity surveyors is explained further. Un-Listed BOQ items (not included in the original BOQ uploaded by the preparer) are reported separately for detailed analysis upon project completion. This analysis helps determine if these items were missed during initial BOQ preparation, were deferred for later inclusion, or resulted from changes in project planning. Investigating these cases is essential to prevent similar omissions or late additions in future projects, ensuring better cost and quality control.

[0210] The system 100 comprises the BOQ for all project works module. The module includes various features which are explained below in detail. The BOQ for all project works module manages and controls work task listings for projects by ensuring only one active BOQ per project with strict permissions for edits or cancellations. It maintains accurate documentation by categorizing types of work and tasks, allowing for detailed tracking and updates. The module supports flexible management by enabling incremental additions and reviews, streamlining task reconciliation, and improving cost control. It also monitors extra items separately for performance analysis to refine future BOQ preparations and project planning.

[0211] In an embodiment, steps in uploading and changing BOQ tasks is illustrated further. In an embodiment, the BOQ may be uploaded by authorized persons at PMC or the developer office. A type of work may appear only once in the BOQ. Similarly, a Type of Task with a specific specification may be listed only once for each Type of Work. When uploading the BOQ, ensure that all relevant AutoCAD, Excel, and Word files are also uploaded and attached to the corresponding Type of Task for future reference. A BOQ may be Uploaded' by first downloading the format Excel file and then fdling it out according to the sample provided. The 'Save as Draft' button at the submission stage allows the BOQ preparer to enter details incrementally, as a BOQ usually involves a lengthy list of tasks. After saving it as a draft, the preparer may have it reviewed by a designated senior before making the final submission for use in Tender / WO. In another embodiment, adding a new type of work to the existing BOQ. The new type of work may be added at any time by authorized persons without anyone's permission. In another embodiment, Editing, Adding, or Deleting a Type of Task in the Existing BOQ.

[0212] If an authorized person wishes to edit, add, or delete a Type of Task in any Type of Work within the existing BOQ, they must submit a request to the Developer's office. Approval may only be granted by the Founder, Partners, Key-Managers, or Accounts-Head at the Developer's office. Updated tasks are highlighted separately to ensure they are easily noticeable.

[0213] The BOQ control and approval protocol is illustrated further. In an embodiment, only one BOQ may be 'Active' per project at a time and can only be 'Cancelled' by the Founder, Partners, key manager, or Accounts head. A BOQ cannot be Edited' without their permission. Only one person may be granted permission to 'Edit' the BOQ at a time. The authorized personnel will be able to see which tasks have been'Edited' or 'Deleted' and will receive a history of changes for review. This strict control over the BOQ ensures that these individuals have full authority over the tasks being tendered for the project.

[0214] In an embodiment, BOQ listing and specification guidelines is illustrated further. The type of Work may appear only once in the BOQ. Similarly, a Type of Task with a specific specification may be listed only once for each Type of Work. However, if the same Type of Task has different specifications, it can be included in the BOQ for the same Type of Work. Tasks originally entered in the BOQ are termed 'Contracted Works,' while those that are subsequently identified are referred to as 'Extra-Items.' A Type of Task with a specific specification may be used across different Types of Work. For example, a 15mm thick internal plaster can be listed in the BOQ for Civil, Waterproofing, and Plumbing works. However, it cannot be listed more than once for each of these Types of Work. This method ensures that the BOQ preparer effectively consolidates material quantities for each Type of Work.

[0215] In an embodiment, incremental BOQ updates and quality control is illustrated further. In an embodiment, a type of work can be added to the project BOQ at any stage, allowing for flexible, incremental management. However, once a Type of Work is included, all related Types of Tasks with their detailed specifications must be listed simultaneously. Therefore, the BOQ for a Type of Work should not be finalized until all tasks are agreed upon by both the architect and the developer. This ensures collaborative decisionmaking and maintains consistent cost and quality control. This approach also enables flexible management of task quantities through Tender and WO. When requisitioning a Type of Material, the focus is on the quantity needed for that specific Type of Work at the site. The ordering process involves specifying the Type of Work associated with the task and its specifications, which streamlines automatic reconciliations.

[0216] In an embodiment, reporting of extra-items is illustrated further. In an embodiment, for performance review of quantity surveyors: Extra items (not included in the original BOQ uploaded by the preparer) are tracked separately for detailed analysis upon project completion. This analysis helps determine if these tasks were missed during initial BOQ preparation, were deferred for later inclusion, or resulted from changes in project planning. Investigating these cases is essential to prevent similar omissions or late additions in future projects, ensuring better cost and quality control.

[0217] The system 100 provides complete Material Management of ALL Developers / Contractors / Sub-contractors materials by tracking Quantities of Estimated / Indented / PO-Issued / Supplier-Delivered / Security-Registered / Store-Registered / Billed / Gate-Pass-Issued materials.

[0218] The system 100 provides issued gate passes for the developer's material module. The module includes various features which are explained below in detail. The Gate-Pass module ensures controlled and documented transportation of materials out of site premises. It facilitates proper authorization and verification processes, including uploading, review, and acknowledgment by relevant teams. This module helps maintain accurate records, prevent unauthorized material movements, and supports audit processes. It ensures compliance with procedural requirements and enhances accountability throughout the material dispatch process.

[0219] Further, steps for issuing gate passes to developer's own materials is illustrated. In an embodiment, a gate pass is generally required for transporting material out of the site premises for the following six reasons: i) Material being returned to the Supplier, ii) Material being transferred to the CENTRAL-STORE, iii) Material being removed as Scrap, iv) Material being removed as Debris-Or-Waste, v) Material being removed due to Date-Expiry, vi) Material adjustment due to Theft / Missing-Items.

[0220] In an embodiment, for uploading gate pass by site teams of developer. The developer's material is being transported out of the site premises, and the site store teams of the developer / PMC must upload the request for a gate pass. If corrections are required, the site supervision team should return the details to the store team for revision before forwarding them to the developer / PMC head office for approval. However, if the site supervision team handles the upload, their request is sent directly to the developer / PMC head office. In another embodiment, for getting review and approval by the developer's accounts department. The Developer's Accounts team will review and approve the details of the Gate-Pass submitted by the Site- Supervision-Teams of the Developer / PMC. In another embodiment, the site security man must inspect the material being dispatched from the site premises and acknowledge the Gate-Pass as part of the audit process. The Supervisor / Manager, located at the head office, must review and verify that the Security Man are maintaining proper records. They must also acknowledge the gate pass as part of the audit process.

[0221] Further, steps for issuing gate passes to contractor's materials is illustrated. In an embodiment, for uploading the gate pass by the site teams of the contractor. When a contractor's material is being transported out of the site premises, the site store teams of the contractor must upload the request for a gate pass. If corrections are required, the Site-Supervision-Team of the Contractor should return the details to the Store-Team for revision before forwarding them to the Site-Supervision-Team of the Developer / PMC. However, if the Site-Supervision-Team of the Contractor handles the upload, their request is sent directly to the Site-Supervision-Team of the Developer / PMC, which may return the request if any changes are required. Once the Site-Supervision-Team of the Developer / PMC approves the request, the subsequent process for Gate-Pass approval remains the same as described above.

[0222] Further, steps for issuing gate-passes to sub-contractors materials is illustrated. In an embodiment, for uploading of gate-pass by site-teams of sub-contractor. When a sub-contractor's material is being transported out of the site premises, their Site-Team must upload the request for a Gate-pass. This request is sent directly to the Site-Supervision-Team of the Contractor, which may return it for revisions if necessary. Once approved by the Contractor’s Site-Supervision-Team, the request is forwarded to the Site- Supervision-Team of the Developer / PMC for final approval, which may also return it for changes if needed. Once the Site-Supervision-Team of the Developer / PMC approves the request, the subsequent process for Gate-Pass approval remains the same as described above.

[0223] In an embodiment, discrepancy and confirmation report by system 100 is illustrated further. Various reports are prepared by the system 100 related to material receipt at the site. The reports include: daily report comprising the date of dispatch that is recorded in the store register but not in the security register ORthat is recorded in the security register but not in the store register. Further, the report includes daily report comprising the vehicle no. that is listed in the store register but not in the security register OR that is listed in the security register but not in the store register. Furthermore, the report includes the daily report, if there is any material whose dispatch has not been confirmed by a contractor, but which has been dispatched from the site.

[0224] The system 100 provides comprises the bar bending schedule (BBS) module. The module includes various features which are explained below in detail. The purpose of the Bar Bending Schedule (BBS) module is designed to accurately track and verify the theoretical consumption of steel and concrete in construction projects. It ensures precise material management by detailing steel requirements and concrete quantities. The module facilitates efficient workflows by managing the upload, review, and approval process, integrating relevant documents, and streamlining communication between teams. This reduces waste and ensures materials are used according to project specifications. The final approval involves multiple stakeholders, including the Structural Consultant, to confirm compliance and accuracy.

[0225] Further, steps for uploading BBS in the project is illustrated. In an embodiment, the Bar Bending Schedule (BBS) is required to verify the theoretical consumption of steel in projects. Alongside the BBS, the theoretical consumption of concrete is also needed. The following are the steps for uploading and approving the BBS and concrete quantities. In one embodiment, a BBS and concrete quantity can be uploaded by the Site- Supervision-Teams of the Developer, PMC, Contractor, or the Contractor's office. It must be ensured that all relevant AutoCAD, Excel, and Word files are attached to the BBS for reference. In another embodiment, the flow of reviewing and approving BBS is explained further. The BBS is finally approved by the Developer's Project-Planning-&-Coordination Dept, PMC's Founder, PMC's Partners, PMC's Key Managers, or PMC's Project-Planning-& -Coordination Dept (any of these). If necessary, they can forward the BBS to the structural consultant for verification and approval. The BBS approval process from the sitesupervision-team to the structural consultant is as follows:

[0226] In one embodiment, the plurality of employees may comprises contractor's team, developer / PMC's Supervision-Team@SITE (any), The developer's Project-Planning-&-Coordination-Dept, PMC's founder , PMC's partners, PMC's Key-Manager, PMC's Project-Planning-&-Coordination-Dept, Structural-Consultant's Master-account, His Partners, His Assistant Designers , and the like.

[0227] The system 100 comprises the material complaints module. The module includes various features which are explained below in detail. The purpose of the Complaint Module is to streamline the process of reporting, reviewing, and resolving product-related issues across project teams. It facilitates clear documentation and tracking of complaints, ensures thorough review and approval by relevant departments, and enhances coordination with suppliers through transparent communication. By providing a structured approach to issue resolution, it promotes higher product quality, reduces disputes, and maintains project timeline clarity. This comprehensive oversight helps in building trust among all parties involved and improves overall project efficiency.

[0228] Further, the steps for making complaints about developer's received material is illustrated. In an embodiment, for uploading complaints by site-supervision-teams, the complaints about materials received by the developer may be uploaded by the Site-Supervision-Teams of the Developer, PMC, Contractor, or the Contractor's office. Photographs of the issues must also be uploaded to help the supplier understand and address the problem. In another embodiment, for Review and Approval of Complaints, wherein the Complaints received by the Site-Supervision-Teams must be reviewed and approved by the Developer's Project-Planning-& -Coordination Department, PMC's Founder, PMC's Partners, PMC's Key -Managers, or PMC's Project-Planning-&-Coordination Department (any of these). After approval, the complaint is forwarded to the Purchase / Accounts Department for final review before being sent to the supplier for necessary action In another embodiment, for coordination with supplier for resolving the complaint. After a complaint is registered with the supplier, a chat trail is created in the module for ongoing coordination. The team involved from the Developer / PMC offices during the complaint approval can participate in these discussions. Additionally, the Developer, company partners, JV partners, key managers, and accounts head may also engage in the chat to facilitate resolution of the issue.

[0229] Steps for making complaints about contractor's received material is illustrated further. In an embodiment, for uploading complaints by site-supervision teams. The Complaints about materials received by the contractor may be uploaded by the Site-Supervision-Teams of the Contractor. Photographs of the issues must also be uploaded to help the supplier understand and address the problem. In another embodiment, for Review and Approval of Complaint, the complaints received by the Site-Supervision-Teams must be reviewed and approved by the Contractor's Project-Coordination Dept.

[0230] After approval, the complaint is forwarded to the Purchase / Accounts Department of the Contractor for final review before being sent to the supplier for necessary action. In another embodiment, for the coordination with Supplier for Resolving the Complaint, after a complaint is registered with the supplier, a chat trail is created in the module for ongoing coordination. The team involved from the Contractor offices during the complaint approval may participate in these discussions. Additionally, the Contractor, company partners, JV partners, key managers, and accounts head can also engage in the chat to facilitate resolution of the issue.

[0231] In an embodiment, steps for making complaints about sub-contractors received material is illustrated further. The complaints about materials received from the sub-contractor may be uploaded by the site teams of the sub-contractor. Photographs of the issues must also be uploaded to help the supplier understand and address the problem. In another embodiment, for Review and Approval of Complaints, when complaints received by the site teams must be reviewed and approved by the sub-contractor, company partners, JV partners, or key managers. After approval, the complaint is sent to the supplier for necessary action. In another embodiment, the coordination with the supplier for Resolving the Complaint. After a complaint is registered with the supplier, a chat trail is created in the module for ongoing coordination. Theteam involved from the sub-contractor offices during the complaint approval may engage in the chat to facilitate the resolution of the issue.

[0232] Improved product quality and project transparency with the system 100 complaint tracking is illustrated further. In an embodiment, each product complaint is fully tracked until resolution in the system 100. This monitoring process helps identify reliable sources for both current and future projects. Once these sources are identified, they gain greater trust, which enhances confidence and dependency on them, increasing the likelihood of delivering a high-quality product on time. Since developers, contractors, and subcontractors involved in the same project may access and review each other’s product-related issues, it creates additional pressure on suppliers to deliver superior products. Additionally, this transparency ensures that all parties are informed about complaints concerning each other’s products, thereby eliminating potential disputes over the causes of delays and maintaining clarity about project timelines.

[0233] Material Management for Developers / Contractors / Sub-contractors also includes obtaining Quotes from his Suppliers. Sharing Comparatives with intemal-project-team at their office, recording their comments on the uploaded comparatives, recording final say in the finalization of Suppliers & Issuing POs to Suppliers.

[0234] The system 100 provides the material receipt register security module. The module includes various features which are explained below in detail. The security man register module serves as the central record for tracking and managing delivery details. It ensures that all information related to deliveries such as the contents, photos of the goods, and vehicle details is accurately documented and easily accessible. This register helps in maintaining accountability, verifying compliance with system 100 requirements, and providing a reliable reference for future audits and reviews.

[0235] In an embodiment, steps for registering the material receipt of the security man is illustrated further. In an embodiment, a delivery arrives, the security man may upload the details using one of these methods: a) scanning the delivery challans: The security man scans the QR code on the challan. The location in the QR code should match the scanning device’s location. After confirming, the details of the delivered materials are recorded in the security man register. The security man should also upload a photo of the goods, a photo of the truck and its number plate, and scan the truck number for registration, b) photo-graphing the delivery challans: If the scanner is not working, the security man should take a photo of the challan and the goods. They should also upload a photo of the truck and its number plate, and scan the truck number for registration.

[0236] In another embodiment, reviewing and acknowledging of the material receipt by the security man head office, wherein the security man head office consisting of the founder, partners, key-managers, or supervisors will review and acknowledge that the details of the received dispatch are uploaded according to system 100 requirements. Their acknowledgment of the material details in the challans will be recorded in the system 100 for future reference. If the scanner is not working and only photos of the challan are uploaded, the security man's office must manually enter the delivery details into the system 100 for the Developer's office toreview. The security man office must match the scanned or photographed details with the prior-provided dispatch details from the supplier to ensure consistency between the dispatched and received delivery information.

[0237] In another embodiment, for review, and acknowledgment by the developer's accounts department, then the developer’s accounts team will review and acknowledge that the details of the received dispatch match the materials they ordered (note that they will not verify the quantity or quality of the received items). Their acknowledgment of the material details in the challans will be recorded in the system 100 for future reference. Since the accounts team is better informed about which materials have arrived at the site, whether for the developer or a contractor, they are responsible for updating the 'wing no / name' and 'name of material owner' fields with accurate information. The accounts team will review the details after the security man's office has checked them. If the information is incorrect, the accounts team may ask for it to be reviewed again. If the material delivery was for a contractor, their office must register the received stock in their site store.

[0238] The system 100 provides material receipt register for the site-store module. The module includes various features which are explained below in detail. The purpose of the register at site-store module is to ensure accurate tracking and management of material deliveries. It facilitates the upload of delivery details, including photos of challans and goods, and verifies consistency with prior dispatch information. The module enables the developer's accounts team to review and acknowledge receipt details, update critical information, and request revisions if needed. It also supports generating reports to identify discrepancies between the store register and security register, and to track unconfirmed material receipts. This system 100 helps streamline inventory management and invoice adjustments.

[0239] In an embodiment, steps for registering material receipt site-store is illustrated further. The system 100 provides an option for uploading receipt information by the site team. When a delivery arrives, the storekeeper or site supervision team must upload a photo of the challan and the goods. They should verify that the material details on the challan match the prior-provided dispatch details from the supplier to ensure consistency between the dispatched and received items. They should then record the actual received quantity against what was stated in the dispatch details, allowing the supplier to adjust the invoice accordingly.

[0240] In another embodiment, review, and acknowledgment by the developer's accounts department. The developer’s accounts team will review and acknowledge that the details of the received dispatch match the materials they ordered (note that they will not verify the quantity or quality of the received items). Their acknowledgment of the material details in the challans will be recorded in the system 100 for future reference. Since the accounts team is better informed about which materials have arrived at the site, whether for the developer or a contractor. They are responsible for updating the 'wing no / name' and 'name of material owner' fields with accurate information. If the information updated by the site team is incorrect, the accounts team may request a revision.

[0241] In an embodiment, discrepancy and confirmation report by the system 100 is illustrated further. Various reports are prepared by the system 100 related to material receipt at the site. The reports include daily report comprising the supplier name that is listed in the store register but not in the security register OR that is listed in the security register but not in the store register. The report further includes daily report comprising the date of receipt that is recorded in the store register but not in the security register OR that is recorded in the security register but not in the store register. The report further includes the daily report comprising The invoice / challan no. that is listed in the store register but not in the security register OR that is listed in the security register but not in the store register. The report further includes the daily deport comprising the vehicle no. that is recorded in the store register but not in the security register OR that is recorded in the security register but not in the store register. Further, the report includes the daily report in which if there is any material whose receipt has not been confirmed by a contractor, despite being received at the site.

[0242] The system 100 provides a material-issued register for the site-store module. The module includes various features which are explained below in detail. The material-issued register for the site-store module streamlines the management of materials issued to contractors. It ensures accurate documentation and approval of issued materials, facilitates contractor acknowledgment of receipt, and manages the return of surplus materials. This module updates site stock records and reconciles inventory by comparing quantities received, issued, and remaining. It helps maintain precise and up-to-date inventory records and supports efficient reporting and tracking of issued materials.

[0243] In one embodiment, steps for registering material issuing details for the site store is illustrated further. The system 100 provides an option for uploading issuing information by the site store team. When materials are issued to a contractor, the site store team must document the details of the issued materials and upload this information. The site supervision team will then review and approve the submission. In one embodiment, civil materials such as steel, RMC, aggregates, AAC blocks, sand, and rubble should not be entered as "issued materials" in this module. In another embodiment, for review and approval by the site supervision team, when the site store team issues materials to a contractor, the site supervision team must review and approve the details. If corrections are needed, the site supervision team may return the details to the store team. If the site supervision team is uploading the issuance details themselves, the contractor must review and acknowledge them. In another embodiment, for review and acknowledgment by the contractor's team when after receiving materials for use in their on-site work, the contractor must acknowledge receipt of the materials. If there are any issues or discrepancies, the contractor may return the details to the site supervision team for further review and correction.

[0244] The contractor may return surplus materials by uploading the details of the excess items. This process updates the site stock and ensures reconciliation between the quantities received, issued, and remaining, maintaining accurate inventory records at the site store.

[0245] In an embodiment, report on materials not accepted by contractors is illustrated further. In an embodiment, various reports are prepared by the system 100 related to material issued at the site. The reports include if any material is not accepted (as a whole) by any contractor if issued to him on the client account.

[0246] The system 100 provides comparatives of the supplier's quotes module. The module includes various features which are explained below in detail. The comparatives of supplier's quotes module streamlines the evaluation and selection of vendors by generating detailed comparative reports on quotes. It ensures transparency and accuracy by highlighting significant price differences and tracking all changes in quotes. The process facilitates effective communication for final negotiations and adjustments, while also allowing control over vendor data visibility. This structured approach aids in making informed and objective decisions, ultimately leading to a well -documented and transparent vendor selection.

[0247] In an embodiment, steps for supplier comparison and finalization process is illustrated further. In an embodiment, for preparing the comparative report of suppliers, the comparative report for quotes received from suppliers is auto-generated as soon as the quotes are obtained and the purchase / accounts person clicks the 'generate comparative' button for the respective enquiry. In another embodiment, for communication & correspondence to finalize vendor / supplier the purchase / account person can discuss which vendors to shortlist for final negotiation via a dedicated 'Threaded Chat' once the comparative report is shared with all concerned authorities. After negotiating with the vendors and updating the comparative report, further discussions may take place to select the final vendor. This separate chat ensures essential tracking and transparency throughout the vendor finalization process.

[0248] In an embodiment, automated comparative reports and quote management in the system 100 is illustrated further. In the system 100, the comparative report begins generating automatically upon receiving supplier quotes. If enquiries were sent to additional suppliers but their quotes have not yet arrived, their names will be listed at the top of the report, indicating that responses are still pending. If a supplier’s identity was marked as 'confidential' by the developer’s office when the enquiry was sent, their name will not be displayed in a report. Instead, 'XXXX' will appear at the top of the report, indicating that a quote is still awaited from an undisclosed source. Pending quotes are automatically added to the comparative report until a negotiated rate from any supplier is updated.

[0249] Once a negotiated rate is updated in the report even for one vendor, pending or revised quotes from other suppliers will no longer be added automatically. To include pending or revised quotes, the purchase / accounts department must obtain permission from the developer, company partners, JV partners, key managers, or accounts head to edit the report. Once permission is granted, they may effortlessly include pending or revised quotes by clicking the 'PQ' (Pending Quote) or 'RQ' (Revised Quote) buttons. If a negotiated rate is updated in the report, pending or revised quotes will no longer be added automatically. If a pending or revised quote is submitted but not yet included in the report, the 'PQ (Pending Quote)' or 'RQ (Revised Quote)' indicator will appear at the top, notifying the team that a pending or revised quote is available but has not yet been added.

[0250] In an embodiment, enhanced price comparison and rate revision alerts in the system 100 is illustrated further. As per one example, the system 100 highlights suppliers whose rates are more than X% (as specified by the purchase / accounts department) from the lowest rate of all quoted suppliers. This feature ensures that significant price differences are easily noticeable for quicker and clearer comparison to the authorities. The system 100 will notify users of any revised rates provided by suppliers and will display the previous rates for easy comparison. If a vendor does not submit a quote for a particular material type, the system 100 will use the lowest rate from other vendors for comparison purposes. This rate will be highlighted to indicate that it was used only for comparison, as the vendor did not provide a quote for that item.

[0251] In an embodiment, managing supplier confidentiality in the system 100 is illustrated further. In one embodiment, if the developer opts to keep the supplier's identity hidden from the PMC office, they may restrict access to the supplier’s name, quotes, and any related data in the comparative analysis. Additionally, if the developer wishes to keep this information hidden from both their own office and the PMC, the supplier’s name and quotes will be concealed. The developer later decides to disclose the supplier’s name, quotes, and comparative data to the PMC, they can adjust the settings accordingly.

[0252] In an embodiment, vendor finalization and adjustment process is illustrated further. In one embodiment, once a comparative report with at least two vendors is ready, the system 100 reminds authorities every 4 days to negotiate and finalize the vendor. The system 100 offers flexibility for post-negotiation adjustments, allowing the vendor's quoted rates to be corrected by applying a uniform percentage discount across all materials, varying discounts to specific items, or by directly editing the unit rates for particular items. The final approving authority may then designate the selected vendor for the purchase order, ensuring clarity on which vendor has been chosen.

[0253] In an embodiment, transparent and accurate vendor comparison process is illustrated further. In one embodiment, comparing vendor / supplier rates in a detailed and accurate manner gives the developer a clear perspective on which vendor to shortlist for final negotiations. With minimal human involvement and robust controls over the enquiry and comparison processes, where every change in quoted prices is tracked. This approach ensures a high level of transparency in the vendor selection process.

[0254] For absolute transparency, a developer may track whether Contractor has ordered material for his site to any supplier or not, when is his ordered material expected to arrive at site, how much material he has brought at site till date, which material he is taking out from site and how much stock is there in his sitestore through the system 100.

[0255] For absolute transparency, a Contractor may track whether Developer has ordered material for the site to any supplier or not, when is his ordered material expected to arrive at site, how much material he has issued to him at site till date, which material he is taking out from site and how much stock is there in his site-store through the system 100.

[0256] Contract Management of Developer & Contractors AND Contract Management of Contractors & Sub-contractors through the system 100 is illustrated further.

[0257] Contract Management for Developers-&-Contractors AND Contractor-&-Sub-contractors, which includes obtaining Quotes from his Vendors, Sharing Comparatives with intemal-project-team at their office, recording their comments on the uploaded comparatives, recording final say in the finalization of Vendors & issuing WOs to Vendors, issuing Invoice Formats to finalized vendors, issuing latest / updated Work Specs, Safety -Manual & Guidelines and tracking All Insurance / PF / ESIC docs.

[0258] The system 100 comprises the work specs, safety manual and guidelines module. The module includes various features which are explained below in detail. The Work Specs, Safety -Manual & Guidelines module provides a platform for developers and PMC offices to upload essential documents such as work specifications, safety manuals, hygiene and cleanliness guidelines, and other project instructions. Once a contractor is appointed, they may access these documents to ensure their site teams adhere to the required standards. This system 100 streamlines document management, reducing the need for repeated issuance by the Developer and PMC teams. When updates are made, new versions are uploaded, and notifications are sent to all contractors relevant to the specific type of work. While existing contractors may not always receive these notifications if the office decides otherwise, all new contractors will receive the latest documents when they begin work on the project.

[0259] In an embodiment, steps in uploading the work specs, safety-manual and guidelines is illustrated further. In an embodiment, for uploading work specs, safety-manual and guidelines, the Contracts or Accounts Department of the Developer or PMC should upload the documents for contractors to download and follow. In another embodiment, the for taking the Approval of Work Specs, Safety -Manual & Guidelines, Documents uploaded may be approved by the Project-Planning-& -Coordination Department, if available. If this department is not present, the uploading person may proceed without seeking such approval.

[0260] The system 100 comprises the comparatives of the contractor's quotes module. The module includes various features which are explained below in detail. The comparatives of contractor's quotes module automates the generation of a comparative report as contractor quotes are received, integrating all pending and revised quotes until negotiated rates are included. It highlights significant price differences and tracks rate changes for clarity. The module supports secure handling of confidential information, allowing only authorized personnel to update the report. It facilitates efficient vendor finalization through dedicated communication channels and reminders, ensuring a transparent and accurate selection process. This structured approach helps the Developer make informed decisions with minimal manual effort.

[0261] In an embodiment, steps for contractor comparison and finalization process is illustrated further. In an embodiment, preparing the comparative report of contractors. This comparative report is automatically generated as soon as quotes from contractors are received. Pending quotes are automatically added to the report until negotiated rates from any contractor are included. Contractors may only submit revised quotes if requested by the Developer or PMC. In another embodiment, further communication & correspondence to finalize vendor / contractor. Once the comparative report is shared with all concerned authorities, they may discuss which vendors to shortlist for final negotiation via a dedicated 'Threaded Chat.'After negotiating with the vendors and updating the comparative report, further discussions may take place to select the final vendor. This separate chat ensures essential tracking and transparency throughout the vendor finalization process. Automated comparative reports and quote management in the system 100.

[0262] In the system 100, a comparative report begins generating automatically upon receiving contractor quotes. If inquiries were sent to additional contractors but their quotes have not yet arrived, their names will be listed at the top of the report, indicating that responses are still pending. If a contractor’s identity was marked as 'Confidential' by the Developer’s office when the tender was sent, their name will not be displayed in report. Instead, 'XXXX' will appear at the top of the report, indicating that a quote is still awaited from an undisclosed source. Pending quotes are automatically added to the comparative report until a negotiated rate from any contractor is updated.

[0263] Once a negotiated rate is updated in the report even for one vendor, pending or revised quotes from other contractors will no longer be added automatically. To include pending or revised quotes, the Contracts / Accounts Dept must obtain permission from the Developer, Company Partners, JV Partners, Key- Managers, or Accounts-Head to edit the report. Once permission is granted, they may effortlessly include pending or revised quotes by clicking the 'PQ' (Pending Quote) or 'RQ' (Revised Quote) buttons. If a negotiated rate is updated in the report, pending or revised quotes will no longer be added automatically. If a pending or revised quote is submitted but not yet included in the report, the 'PQ (Pending Quote)' or 'RQ (Revised Quote)' indicator will appear at the top, notifying the team that a pending or revised quote is available but has not yet been added.

[0264] In an embodiment, enhanced price comparison and rate revision alerts in the system 100 is illustrated further. The system 100 highlights suppliers whose rates are more than X% (as specified by the Contracts / Accounts Department) from the lowest-rate of all quoted contractors. This feature ensures that significant price differences are easily noticeable for quicker and clearer comparison to the authorities.

[0265] The system 100 will notify the employees of any revised rates provided by contractors and will display the previous rates for easy comparison. If a vendor does not submit a quote for a particular task, the system 100 will use the lowest rate from other vendors for comparison purposes. This rate will be highlighted to indicate that it was used only for comparison, as the vendor did not provide a quote for that task.

[0266] In an embodiment, managing contractor confidentiality in the system 100 is illustrated further. In an embodiment, if the Developer opts to keep the contractor's identity hidden from the PMC office, they may restrict access to the contractor’s name, quotes, and any related data in the comparative analysis. Additionally, if the Developer wishes to keep this information hidden from both their own office and the PMC, the contractor’s name and quotes will be concealed. Should the Developer later decide to disclose the contractor’s name, quotes, and comparative data to the PMC, they may adjust the settings accordingly.

[0267] In an embodiment, vendor finalization and adjustment process is illustrated further. In an embodiment, once a comparative report with at least two vendors is ready, the system 100 reminds authoritiesevery 4 days to negotiate and finalize the vendor. They may choose to dismiss these reminders. The system 100 offers flexibility for post-negotiation adjustments, allowing the vendor's quoted rates to be corrected by applying a uniform percentage discount across all tasks, varying discounts to specific tasks, or by directly editing the unit rates for particular tasks. The final approving authority may then designate the selected vendor for the work order, ensuring clarity on which vendor has been chosen.

[0268] In an embodiment, transparent and accurate vendor comparison process is illustrated further. In an embodiment, comparing vendor / contractor rates in a detailed and accurate manner gives the developer a clear perspective on which vendor to shortlist for final negotiations. With minimal human involvement and robust controls over the tendering and comparison processes, where every change in quoted prices is tracked. This approach ensures a high level of transparency in the vendor selection process.

[0269] The system 100 comprises the issued all WOs (original) modules. The module includes various features which are explained below in detail. The Issued All WOs (Original) module in the system 100 manages and tracks Work Orders (WOs) by categorizing them into Contracted Item / Task WOs and Extra Item WOs. It facilitates the uploading of contract details by the contracts or accounts department and ensures WOs are approved by relevant authorities before being visible to contractors. The module includes an acknowledgment process to keep team members informed and prepared. It also streamlines the distribution of contract information through the 'Issued All WOs (Original)' and 'WO Copies, for Site-Team' modules, reducing redundancy and ensuring efficient communication.

[0270] In an embodiment, WO Types are illustrated further. In an embodiment, WOs in the system 100 are categorized into two types: 1) Contracted Item / Task WOs: These WOs define the scope of work agreed upon and contracted with the contractors at the project's outset. They include details such as the scope of work, terms and conditions, item specifications, and other requirements initially planned by the Developer or PMC office in collaboration with architects and consultants. 2) Extra Item WOs: These WOs address tasks that were not included in the original Contracted WOs but have arisen due to omissions by the quantity surveyor, changes in planning, or modifications requested by architects or consultants. In the system 100, these are labelled as 'Extra Items'. Addendums to these WOs are issued as new extra items arise throughout the course of the project’s execution.

[0271] In an embodiment, steps in Issuing a WO is illustrated further. In an embodiment, the Contracts or Accounts Department of the Developer or PMC should upload a copy of the original contract along with key details such as the total contract amount, retention percentage, defect liability period, contract start and end dates, and the names of the signatories. This information is essential for establishing and managing various tracking mechanisms. In another embodiment, WOs uploading may be approved by the Developer, JV Partners, Company Partners, Key-Managers, or the Accounts-Head at the Developer's office. The WOs will only become visible to the contractor offices after receiving approval.

[0272] In an embodiment, ensuring project awareness of the system’s acknowledgment process is illustrated further. In an embodiment, it is essential for the project team to thoroughly review all drawings anddocuments related to the project. Staying vigilant and well-informed about project details is crucial for managing the inevitable challenges that arise during construction. Although projects are meticulously planned by experts, they are executed by a mix of skilled and unskilled labourers, which introduces the risk of unforeseen issues. Furthermore, difficult site conditions and unfavourable project locations may often add to the complexity. To ensure that both current and future team members are well-informed about project details, the system’s features an 'Acknowledgement' process. This process requires individuals to confirm that they have thoroughly read the relevant documents and resolved any questions they may have. This acknowledgment ensures that all team members are adequately prepared to manage forthcoming tasks and issues.

[0273] In an embodiment, streamlined distribution of contract documents and site: Team Access in the system 100 is illustrated further. The 'Issued All WOs (Original)' module is designed to distribute copies of the signed contract to the Developer's office team, the PMC office team, the Contractor's office team, and financial institutions. However, many developers prefer not to share all detailed contract information with the site teams. Nonetheless, site teams require access to specific details such as the scope of work, terms and conditions, item specifications, and material made while contractors perform their tasks on-site. To address this need, the 'WO Copies, for Site-Team' module in the system 100 provides a platform that allows the Developer and PMC to provide a filtered version of the WO copy to the site teams for their reference. If the Developer or PMC opts to share the original contract copy with the site team, the 'Issued All WOs (Original)' module enables the uploader to simultaneously update the 'WO Copies, for Site-Team' module. This feature streamlines the process by reducing the uploader's workload and minimizing the risk of errors from redundant tasks.

[0274] The system 100 comprises the WO copies, for the site team module. The module includes various features which are explained below in detail. The WO copies, for the Site-Team module facilitate the sharing of key contract documents and details with the site teams of the Developer, PMC, and contractors. It ensures that these teams have easy access to essential documents for quick reference, helping to clarify any potential confusion regarding the scope of work.

[0275] In an embodiment, steps in issuing a WO, for site team is illustrated further. In an embodiment, the contracts or accounts Department of the Developer or PMC should upload a copy of the contract along with key details such as the total contract amount, retention percentage, defect liability period, and contract start and end dates. In another embodiment, WOs uploading may be approved by the Developer, JV Partners, Company Partners, key managers, or the Account head at the Developer's office. The WOs will only become visible to the site team after receiving approval.

[0276] In an embodiment, ensuring project awareness of the system's acknowledgement process is illustrated further. In an embodiment, it is essential for the project team to thoroughly review all drawings and documents related to the project. Staying vigilant and well-informed about project details is crucial for managing the inevitable challenges that arise during construction. Although projects are meticulously plannedby experts, they are executed by a mix of skilled and unskilled labourers, which introduces the risk of unforeseen issues. Furthermore, difficult site conditions and unfavourable project locations may often add to the complexity. To ensure that both current and future team members are well-informed about project details, the system 100 features an 'Acknowledgement' process. This process requires individuals to confirm that they have thoroughly read the relevant documents and resolved any questions they may have. This acknowledgment ensures that all team members are adequately prepared to manage forthcoming tasks and issues.

[0277] The system 100 comprises the invoice formats for the contractor’s module. The module includes various features which are explained below in detail. The Invoice Formats for Contractors module allows Developer and PMC offices to upload invoice templates for different 'Types of Work'. Contractors may access these templates to prepare their invoices. This system 100 reduces the need for the Developer and PMC teams to repeatedly handle the task of issuing formats. When formats are updated, the new versions are uploaded, and notifications are sent to all contractors associated with the relevant 'Type of Work'. Existing contractors may not receive these notifications if the office decides not to send them, but all future contractors will get the latest templates as they begin work on the project.

[0278] In an embodiment, steps in uploading the invoice format for contractors. In an embodiment, for uploading Invoice Formats, the Billing or Accounts Department of the Developer or PMC should upload the invoice formats for contractors to download and use when submitting their invoices. Contractors are expected to follow these formats when raising their invoices. In another embodiment, Invoice Formats uploaded can be approved by the Project-Planning-&-Coordination Department, if available. If this department is not present, the uploading person may proceed without seeking such approval.

[0279] The system 100 comprises the insurance / PF / ESIC copies module. The module includes various features which are explained below in detail. The Insurance / PF / ESIC copies module provides a platform for Developer and Contractor offices to upload essential documents such as Insurances, PF, and ESIC copies. Each office is responsible for uploading the relevant documents within their scope of work. This system 100 streamlines document management, minimizing the need for repeated follow-ups between the Developer and Contractor teams. When documents approach their expiry date, the entire project team receives alerts to renew insurance policies or make timely PF / ESIC payments. The platform ensures these essential documents are easily accessible and helps maintain a comprehensive record, which is crucial for obtaining occupation certificates from municipal authorities.

[0280] In an embodiment, steps for uploading Insurance / PF / ESIC copies is illustrated further. In an embodiment, for uploading Insurance / PF / ESIC copies, the Accounts Department of both the Developer and Contractor should upload documents for each other's reference, as well as for the reference of other project teams. The site teams must ensure that these documents are kept up-to-date throughout the course of the project. In another embodiment, the documents uploaded may be approved by the Project-Planning-&- Coordination Dept or the Billing Dept, if available. If this department is not present, the uploading person mayproceed without seeking such approval. They must review that the Accounts Department is procuring the correct documents required for the project.

[0281] The system 100 provided complete Contract Management for the Developers & Contractor which includes Sharing Rate-Analysis of Extra-Items with intemal-project-team at their office, recording their comments on the uploaded Rate-Analysis, recording final say in the finalized Rate-Analysis.

[0282] The system 100 provides the extra items of the approved rate analysis module. The module includes various features which are explained below in detail. The extra items for the Approved Rate Analysis module provides a platform for the Developer, Contractor, and PMC offices to track and maintain records of approved extra items at their respective offices. It streamlines the approval process and ensures that records are readily available for future reference and audits. By consolidating approval data, the module reduces repetitive efforts in claim settlements, lightening the administrative load on all parties involved and minimizing project delays. It enables systematic tracking of extra item approvals, ensuring that all approvals are documented and easily accessible. This enhances transparency and accuracy in billing by providing a clear record of approved items and their rates, which helps reduce disputes and errors. Additionally, the module stores historical data that can be used for benchmarking and planning in future projects, supporting improved decision-making.

[0283] In an embodiment, steps in uploading the extra item rate analysis is illustrated further. In an embodiment, for uploading extra item rate analysis. The Billing or Accounts Department of the Developer or PMC should upload the rate analysis of extra items of contractors for the project planning team to review and approve. In another embodiment, for approval of extra item rate analysis, the Rate Analysis uploaded must be approved by the Project-Planning and Coordination Department, if available. If this department is not present, the uploading person may proceed without seeking such approval. In another embodiment, re-approval of extra item rate analysis, and rate analysis uploading must be approved by the Developer, JV Partners, Company Partners, Key-Managers, or the Accounts-Head at the Developer's office. Once approved, the Billing or Accounts Department may use the approved rates to certify the extra items claimed by the contractors.

[0284] The system 100 provides enquiries (for supplies) and recd quotes module for all projectmaterials modules. The module includes various features which are explained below in detail. The enquiries and recd quotes module facilitates the creation, management, and tracking of supplier quotations. It allows authorized personnel to prepare and send detailed enquiries, manage responses, and communicate with suppliers. The module ensures that quotes are reviewed effectively, maintains confidentiality as needed, and tracks deadlines and reminders efficiently.

[0285] Steps for sending enquiries and obtaining quotes is illustrated further. In one embodiment, for preparing and sending enquiries to suppliers, the designated persons from the Developer or PMC may prepare and send enquiries to suppliers, along with all relevant documents. The 'save as draft' button at the submission stage allows the enquiry preparer to enter details incrementally, as an enquiry usually involves a lengthy list ofitems. After saving it as a draft, the preparer may have it reviewed by a designated senior before making the final submission to request quotes from suppliers. In another embodiment, suppliers should provide quotes for the items requested by the developer or PMC. They can attach any required brochures or technical data for the items if requested by the Developer or PMC. In another embodiment, for further communication and correspondence with suppliers, the developer's office and the PMC may engage with each other in the 'Threaded Chat' to discuss or clarify any issues related to the enquiry or the quotes sent by the suppliers.

[0286] Supplier enquiry process and confidentiality options is illustrated further. In an embodiment, enquiries to suppliers may be sent based on the MRS received from the site team or the BOQ prepared by the office team. In addition to these two methods, the enquiry may also be generated using system’s inbuilt 'type of works' and 'type of materials.' If the PMC initiates the enquiry, the developer or their office may forward it to their known suppliers and include the PMC for follow-up. If the developer prefers not to share supplier details with the PMC, they can exclude them from the communication, and the PMC will not see the quotes or their data. If the developer wants to keep the supplier's identity hidden from both their office and the PMC, they may do so, and the supplier’s quote will be hidden as well. Later, if the Developer decides to show the quotes to the PMC, they can adjust the settings.

[0287] In an embodiment, reminder and follow-up process for quotation is illustrated further. In an embodiment, the enquiry is sent to suppliers with the 'last date for submission of a quote,' and the system 100 sends reminders every three days. Suppliers can choose to dismiss these reminders. The purchase / accounts department receives follow-up reminders every four days. Reminders stop automatically when the suppliers respond via chat. If additional clarification is needed, reminders may be reactivated by the purchase / accounts department. The chat will close automatically once the 'last date for quote submission' is reached, though this date may be extended by the purchase / accounts department. The system 100 maintains a history of such date changes. Additionally, the purchase / accounts department can close the chat when necessary, after which the suppliers will no longer be able to submit a quote.

[0288] In an embodiment, comprehensive communication tracking is illustrated further. In one embodiment, the "threaded chat" feature facilitates communication between the developer and PMC offices, allowing them to leave notes or instructions for the supplier when requesting a quote. This feature comprehensively tracks all stages of the interaction, including the initial inquiry, the first quote provided by the supplier, the first permission granted for a requote, the second quote from the supplier, and the second permission for a requote. All exchanges between the developer, PMC, and supplier are documented in the system 100. Additionally, the "Threaded Chat" allows for the sharing of files, documents, and other relevant materials, ensuring clarity on any issues raised by either party.

[0289] Highlighted alternative materials for quick finalization is illustrated further. In one embodiment, if a supplier cannot provide an exact match for the requested material, they may offer alternative options. These substituted or newly quoted items will be highlighted separately to draw specific attention from the developer or PMC. This approach ensures a quicker and more efficient supplier finalization process.

[0290] Streamlined quote revision tracking with color-coding is illustrated further. In one embodiment, whenever a supplier submits a revised quote and adjusts the rates for any material type, these changes are clearly highlighted in the received quote. The system 100 employs a color-coding system 100 to distinguish between revisions, such as the first, second, third, and subsequent rate changes. This visual differentiation enables the developer office and PMC offices to quickly identify which material rates have been updated, thereby facilitating a faster and more efficient supplier finalization process.

[0291] Efficient quote revision process for tenders is illustrated further. In one embodiment, the developer or PMC office may request quotes from suppliers and may receive several revised quotes if the tender involves numerous items. However, suppliers may only submit revised quotes if the developer’s office gives specific permission after the initial quote. This helps control the tender process and reduce unnecessary submissions. The developer or PMC may also close the quote submission process early if needed, even before the final deadline. Once permission is given, if a supplier sends multiple revised quotes, the system 100 arranges them in order from the first to the latest. All quotes from the first supplier are shown together, followed by quotes from the second supplier in the same way. This helps the purchase / accounts department easily track and compare the quotes.

[0292] Reporting on performance analysis of quotation processes and enquiry methods is illustrated further. The system 100 generates reports on the duration of the quotation process for each project, the frequency of extensions to the last date for submission of quotes across various tenders, and the number of extensions for each supplier. It also tracks the number of clarifications requested by suppliers before quoting and the follow-ups needed to secure quotes. While initiating enquiries through MRS is ideal for obtaining quotes, it is important to monitor the number of enquiries initiated through MRS, BOQ, and general methods. This data is crucial for assessing the performance of the Tendering Department, as frequent revisions or delays in obtaining quotes may indicate that the department is not providing sufficient information to suppliers, leading to misunderstandings and delays.

[0293] The system 100 provides comparatives of the supplier's quotes module. The module includes various features which are explained below in detail. The comparatives of supplier's quotes module streamlines the evaluation and selection of vendors by generating detailed comparative reports on quotes. It ensures transparency and accuracy by highlighting significant price differences and tracking all changes in quotes. The process facilitates effective communication for final negotiations and adjustments, while also allowing control over vendor data visibility. This structured approach aids in making informed and objective decisions, ultimately leading to a well -documented and transparent vendor selection.

[0294] Steps for supplier comparison and finalization process is illustrated further. In an embodiment, for preparing the comparative report of suppliers, the comparative report for quotes received from suppliers is auto -generated as soon as the quotes are obtained and the purchase / accounts person clicks the 'generate comparative' button for the respective enquiry. In another embodiment, for communication & correspondence to finalize vendor / supplier the purchase / account person can discuss which vendors to shortlistfor final negotiation via a dedicated 'Threaded Chat' once the comparative report is shared with all concerned authorities. After negotiating with the vendors and updating the comparative report, further discussions may take place to select the final vendor. This separate chat ensures essential tracking and transparency throughout the vendor finalization process.

[0295] Automated comparative reports and quote management in the system 100 is illustrated further. In the system 100, the comparative report begins generating automatically upon receiving supplier quotes. If enquiries were sent to additional suppliers but their quotes have not yet arrived, their names will be listed at the top of the report, indicating that responses are still pending. If a supplier’s identity was marked as 'confidential' by the developer’s office when the enquiry was sent, their name will not be displayed in a report. Instead, 'XXXX' will appear at the top of the report, indicating that a quote is still awaited from an undisclosed source. Pending quotes are automatically added to the comparative report until a negotiated rate from any supplier is updated.

[0296] Once a negotiated rate is updated in the report even for one vendor, pending or revised quotes from other suppliers will no longer be added automatically. To include pending or revised quotes, the purchase / accounts department must obtain permission from the developer, company partners, JV partners, key managers, or accounts head to edit the report. Once permission is granted, they may effortlessly include pending or revised quotes by clicking the 'PQ' (Pending Quote) or 'RQ' (Revised Quote) buttons. If a negotiated rate is updated in the report, pending or revised quotes will no longer be added automatically. If a pending or revised quote is submitted but not yet included in the report, the 'PQ (Pending Quote)' or 'RQ (Revised Quote)' indicator will appear at the top, notifying the team that a pending or revised quote is available but has not yet been added.

[0297] In an embodiment, enhanced price comparison and rate revision alerts in the system 100 is illustrated further. As per one example, the system 100 highlights suppliers whose rates are more than X% (as specified by the purchase / accounts department) from the lowest rate of all quoted suppliers. This feature ensures that significant price differences are easily noticeable for quicker and clearer comparison to the authorities. The system 100 will notify users of any revised rates provided by suppliers and will display the previous rates for easy comparison. If a vendor does not submit a quote for a particular material type, the system 100 will use the lowest rate from other vendors for comparison purposes. This rate will be highlighted to indicate that it was used only for comparison, as the vendor did not provide a quote for that item.

[0298] In an embodiment, managing supplier confidentiality in the system 100 is illustrated further. In one embodiment, if the developer opts to keep the supplier's identity hidden from the PMC office, they may restrict access to the supplier’s name, quotes, and any related data in the comparative analysis. Additionally, if the developer wishes to keep this information hidden from both their own office and the PMC, the supplier’s name and quotes will be concealed. The developer later decides to disclose the supplier’s name, quotes, and comparative data to the PMC, they may adjust the settings accordingly.

[0299] In an embodiment, vendor finalization and adjustment process is illustrated further. In one embodiment, once a comparative report with at least two vendors is ready, the system 100 reminds authorities every 4 days to negotiate and finalize the vendor. The system 100 offers flexibility for post-negotiation adjustments, allowing the vendor's quoted rates to be corrected by applying a uniform percentage discount across all materials, varying discounts to specific items, or by directly editing the unit rates for particular items. The final approving authority can then designate the selected vendor for the purchase order, ensuring clarity on which vendor has been chosen.

[0300] In an embodiment, transparent and accurate vendor comparison process is illustrated further. In one embodiment, comparing vendor / supplier rates in a detailed and accurate manner gives the developer a clear perspective on which vendor to shortlist for final negotiations. With minimal human involvement and robust controls over the enquiry and comparison processes, where every change in quoted prices is tracked. This approach ensures a high level of transparency in the vendor selection process.

[0301] The system 100 comprises the Tenders (for Works) and recd Quotes Module. The module includes various features which are explained below in detail. The Tenders (for Works) & recd Quotes module manage the process of soliciting and evaluating contractor quotes efficiently. It allows authorized personnel to prepare and send tenders, track quotes with explanations, and facilitate communication through a "Threaded Chat" feature. Reminders are sent to contractors, and deadlines can be extended or adjusted as needed. The module supports revision tracking and comparison of quotes while generating reports on process duration, extensions, and clarifications. This ensures a streamlined tendering process and effective performance assessment.

[0302] Further, steps in sending tenders and obtaining quotes is illustrated. In an embodiment, for preparing and sending tenders to contractors. The designated persons from the Developer or PMC can prepare and send tenders to contractors, along with all relevant documents. The 'Save as Draft' button at the submission stage allows the Tender preparer to enter details incrementally, as a Tender usually involves a lengthy list of tasks. After saving it as a draft, the preparer can have it reviewed by a designated senior before making the final submission to request quotes from contractors. In another embodiment, system 100 receives the reply from the contractors. The contractors are required to provide quotes for the tasks requested by the Developer / PMC. They may attach any necessary technical data for the task if requested by the Developer or PMC. In another embodiment, for further communication & correspondence with contractors. The Developer's office and the PMC can engage with each other in the 'Threaded Chat' to discuss or clarify any issues related to the tender or the quotes sent by the contractors.

[0303] In an embodiment, contractor tendering process and confidentiality options is illustrated further. Tenders should be sent to contractors based on the BOQ prepared by the office team. If the PMC initiates a tender, the developer or their office can forward it to their known contractors and include the PMC for follow-up. If the developer prefers not to share the contractor's details with the PMC, they can exclude the PMC from the communication, and the PMC will not see the quotes or their data. If the Developer wants tokeep the contractor's identity hidden from both their office and the PMC, they may do so, and the contractor’s quote will remain hidden as well. Later, if the Developer decides to show the quotes to the PMC, they can adjust the settings.

[0304] In an embodiment, reminder and follow-up process for quotation is illustrated further. The tender is sent to contractors with a specified 'Last Date for Submission of Quote,' and the system 100 sends reminders every 3 days. Contractors can choose to dismiss these reminders. The Contracts / Accounts Department receives follow-up reminders every 4 days. Reminders stop automatically when the contractor responds via chat. If additional clarification is needed, the contracts / Accounts Department may reactivate the reminders. The chat will close automatically once the 'Last Date for Quote Submission' is reached, though this date can be extended by the Contracts / Accounts Dept. The system 100 maintains a history of such date changes. Additionally, the contracts / accounts department can close the chat when necessary, after which contractors will no longer be able to submit a quote.

[0305] In one embodiment, comprehensive communication tracking is illustrated further. In an embodiment, the "Threaded Chat" feature facilitates communication between the Developer and PMC offices, allowing them to leave notes or instructions for the contractor when requesting a quote. This feature comprehensively tracks all stages of the interaction, including the initial inquiry, the first quote provided by the contractor, the first permission granted for a requote, the second quote from the contractor, and the second permission for a requote. All exchanges between the Developer, PMC, and contractor are documented here. Additionally, the "Threaded Chat" allows for the sharing of files, documents, and other relevant tasks, ensuring clarity on any issues raised by either party.

[0306] In an embodiment, highlighted ignored task rates for quick finalization is illustrated further. In an embodiment, if a contractor does not provide a quote for a task, they must include a remark explaining the reason for not quoting. It is mandatory for contractors to either provide task rates or offer a detailed explanation. Tasks without quotes will be highlighted separately for review by the Developer / PMC team. This approach ensures a quicker and more efficient contractor finalization process.

[0307] In an embodiment, streamlined Rate revision tracking with color-coding is illustrated further. In an embodiment, whenever a contractor submits a revised quote and adjusts the rates for any task, these changes are highlighted in the received quote. The system 100 employs a color-coding system 100 to distinguish between revisions, such as the first, second, third, and subsequent rate changes. This visual differentiation enables the Developer office and PMC offices to quickly identify which task rates have been updated, thereby facilitating a faster and more efficient contractor finalization process.

[0308] In an embodiment, efficient quote revision management is illustrated further. In an embodiment, the Developer or PMC office may request quotes from contractors and may receive several revised quotes if the tender involves numerous tasks. However, contractors can only submit revised quotes if the Developer’s office gives specific permission after the initial quote. This helps control the tender process and reduce unnecessary submissions. The Developer or PMC can also close the quote submission processearly if needed, even before the final deadline. Once permission is given, if a contractor sends multiple revised quotes, the system 100 arranges them in order from the first to the latest. All quotes from the first contractor are shown together, followed by quotes from the second contractor in the same way. This helps the Contracts / Accounts Department easily track and compare the quotes.

[0309] In an embodiment, reporting on performance analysis of quotation processes is illustrated further. The system 100 generates reports on the duration of the quotation process for each project, the frequency of extensions to the Last for submission of Quote across various tenders, and the number of extensions for each contractor. It also tracks the number of clarifications requested by contractors before quoting and the follow-ups needed to secure quotes. This data is crucial for assessing the performance of the Contracts Dept, as frequent revisions or delays in obtaining quotes may indicate that the department is not providing sufficient information to contractors, leading to misunderstandings and delays.

[0310] Consultant's Invoices to Developers, Consultant's Invoices to Other Consultants, Material Invoices by Suppliers to Developers / Contractor / Sub-contractors, Contract Invoices by Contractors AND Contract Invoices by Sub-contractors provided through the system 100 is illustrated further:

[0311] For action by the Developer’s Office, Architects, Consultants, Contractors & Suppliers may upload their invoices directly from their office without bothering to know the process / flow of invoice certification in the Developer’s Office.

[0312] For action by the Consultant’s Office, other Architects / Consultants may upload their invoices directly from their office without bothering to know the process / flow of invoice certification in the Consultant’s Office.

[0313] For action by the Contractor’s Office, Sub-contractors & Suppliers may upload their invoices directly from their office without bothering to know the process / flow of invoice certification in the Contractor’s Office.

[0314] For action by the Sub-contractor’s Office, Suppliers may upload their invoices directly from their office without bothering to know the process / flow of invoice certification in the Sub-contractor’s Office.

[0315] The system 100 provides a complete tracking feature thru which the Invoice raising company can track the status of certification of their invoice at respective Developer / Consultant / Contractor / Sub- contractor’s site / office.

[0316] The system 100 comprises the invoices by consultant’s module. The module includes various features which are explained below in detail. In an embodiment, the invoices: By Consultants module streamlines the invoicing process by ensuring structured submission, verification, and certification of invoices. It offers a clear view of delivery status and supports efficient tracking of invoice processing and corrections. This enhances transparency and accountability, improving overall efficiency in consultant payments and project management.

[0317] In another embodiment, steps in Uploading Invoice by Architect / Consultant is illustrated further. The architect / consultant’s office must upload their invoice for verification by the head office of thedeveloper or PMC. This should include the supporting documents specified in the appointment letter, which must be tagged along with the invoice. If necessary, the architect / consultant billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer or PMC’s office. The senior manager will then forward the certified invoice to the developer or PMC’s office.

[0318] Invoice Certification by PMC Head-Office - The PMC Billing Department will review the architect / consultant’ s invoice in accordance with the Appointment-Letter terms. Once audited, the PMC head office will forward the certified invoice to the Developer’s office. If necessary, the PMC Billing Engineer may first forward the invoice to a senior manager within the PMC, following internal procedures, before it is sent to the Developer. The senior will then forward the certified invoice to the Developer’s office.

[0319] Invoice Certification by Developer's Billing Engineer for Payment Submission - The Developer's Billing Engineer will re-audit the certified invoice received from the PMC head office. Once verified, the engineer will submit the invoice to their Accounts Department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0320] In an embodiment, detailed Insight into Delivery Status and Compliance via the system 100 is explained further. The system 100 consultant-invoice protocols and process offer a thorough overview of delivery status for office-based personnel, providing a clear account of the deliveries made by the architect / consultant as per the stages outlined in the appointment letter. The architect / consultant may reference and tag drawings and documents from previous invoices to the current one, facilitating quick access for the billing and accounts department.

[0321] In an embodiment, the Invoice Expediting Process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver may approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0322] In an embodiment, Reports on Consultant's Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to Consultant's Invoice Certification. The reports include average no. of days taken by the Site-Team for invoice certification, categorized by consultant, average no. of days taken by the PMC head office for invoice certification, categorized by consultant, average no. of days taken by the Developer head office for invoice certification, categorized by consultant, average no. of times an invoice is returned to the Consultant for correction, categorized by consultant, average no. of times an invoice is returned to the Site-Team by PMC-HO or Developer-HO for correction, categorized by consultant, average no. of times an invoice is returned to the PMC-HO by Developer-HO for correction,categorized by consultant, and No. of times invoice signatures were missed by any PMC and Developer Office Personnel, categorized by individual.

[0323] The system 100 comprises the Invoices for PMCs Module. The module includes various features which are explained below in detail. The Invoices: By PMCs module streamlines the invoicing process by ensuring structured submission, verification, and certification of invoices. It offers a clear view of delivery status and supports efficient tracking of invoice processing and corrections. This enhances transparency and accountability, improving overall efficiency in consultant payments and project management.

[0324] In another embodiment, Steps in Uploading Invoice by PMC is illustrated further. The PMC’s office must upload their invoice for verification by the head office of the developer. This should include the supporting documents specified in the appointment letter, which must be tagged along with the invoice. If necessary, the PMC billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer. The senior manager will then forward the certified invoice to the developer's office.

[0325] Invoice Certification by Developer's Billing Engineer for Payment Submission - The Developer's Billing Engineer will review the PMC’s invoice in accordance with the Appointment-Letter terms. Once verified, the engineer will submit the invoice to their Accounts Department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0326] In an embodiment, Detailed Insight into Delivery Status and Compliance via the system 100 is explained further. The system’s PMC -invoice protocols and process offer a thorough overview of delivery status for office-based personnel, providing a clear account of the deliveries made by the PMC as per the stages outlined in the appointment letter. The PMC may reference and tag documents from previous invoices to the current one, facilitating quick access for the billing and accounts department.

[0327] In an embedment, Invoice Expediting Process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver may approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0328] In an embodiment, Reports on PMC's Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to PMC's Invoice Certification. The reports include average no. of days taken by the Developer head office for invoice certification, categorized by PMC, average no. of times an invoice is returned to the PMC for correction, categorized by PMC, and No. of times invoice signatures were missed by any Developer Office Personnel, categorized by an individual.

[0329] The system 100 provides the Invoices: By Contractors Module. The module includes various features which are explained below in detail. The Invoices: By Contractors module in the system 100 streamlines the invoice management process by requiring contractors to upload invoices with comprehensive supporting documents. It establishes a structured certification hierarchy involving the Site-Supervision Team, PMC head office, and Developer’s Billing Engineer, ensuring thorough review and approval. The module tracks and reports on extra items separately, providing detailed financial oversight. It also monitors performance by reporting delays and compliance issues, thus promoting transparency and efficiency throughout the invoicing process.

[0330] In an embodiment, steps in uploading Invoice by the Contractor is illustrated further. The contractor’s office (whether their Site-Supervision-Team or Office-Team) must upload their invoice for verification by the Site-Supervision-Teams of the Developer or PMC. This should include supporting documents such as drawings used for the work, site-work photos of the tasks claimed in the invoice, housekeeping photos, and completed checklists related to the work. Upon invoice upload, the system 100 automatically attaches reports on checklists, curing, ponding, QRNs, HSNs, DWRs, test reports, snag lists, and other relevant documents. These attachments provide insight into the level of commitment the contracting team is demonstrating towards the project.

[0331] Invoice Certification by Site-Supervision-Team- the Site-Supervision Team of the Developer or PMC will review the contractor's invoice and provide feedback. If additional clarifications are required, they may return the invoice to the contractor for revision. Alternatively, they may approve the invoice and request the contractor to submit any additional documents before forwarding it to the Developer / PMC head office. In some cases, they may approve the invoice and send it directly to the Developer / PMC head office.

[0332] Document Attachment by Contractor, Once Invoice Approved by Site-Team - If the site team has approved the invoice and sent it to the contractor, the contractor’s head office will then attach the necessary documents, as instructed in the invoice format provided by the Developer or PMC, and submit them to the PMC head office. If necessary, the contractor billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer. The senior manager will then forward the certified invoice to the developer or PMC’s office.

[0333] Invoice Certification by PMC Head-Office- the PMC Billing Department will review the contractor’s invoice in accordance with the contract terms and the work completed. Once audited, the PMC head office will forward the certified invoice to the Developer’s office. If necessary, the PMC Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Developer. The senior will then forward the certified invoice to the Developer’s office.

[0334] Invoice Certification by Developer's Billing Engineer for Payment Submission- The developer's Billing Engineer will re-audit the certified invoice received from the PMC head office. Once verified, the engineer will submit the invoice to their Accounts Department for payment processing. Ifnecessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0335] In an embodiment, detailed insight into On-Site works and compliance via the system 100 is explained further. The contract-invoice protocols and process offer a comprehensive overview of on-site work for office-based personnel. Attached drawings, site photos of the tasks claimed in the invoice, and housekeeping photos provide a clear depiction of the work's status after completion. Additionally, the included reports such as checklists, curing records, ponding details, QRNs, HSNs, DWRs, test reports, and snag lists — give valuable insight into whether the site teams are adhering to the procedures set by the Developer / PMC office.

[0336] In an embodiment, Invoice Expediting Process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver may approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0337] In an embodiment, handling 'Extra-Items' invoicing in the system 100 is explained further. Extra-Items claimed by contractors must be invoiced separately to ensure comprehensive tracking within the system 100. The system 100 monitors all extra item invoices from contractors and generates a report upon project completion. This report provides the Developer with a detailed overview of the total number of invoices and the amounts claimed, broken down by contractors.

[0338] In an embodiment, Reports on Contractor Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to Contractor's Invoice Certification. The reports include Average no. of days taken by the Site-Team for invoice certification, categorized by contractor, average no. of days taken by the PMC head office for invoice certification, categorized by contractor, average no. of days taken by the Developer head office for invoice certification, categorized by contractor, average no. of times an invoice is returned to the Contractor for correction, categorized by contractor, average no. of times an invoice is returned to the Site-Team by PMC-HO or Developer-HO for correction, categorized by contractor, average no. of times an invoice is returned to the PMC-HO by Developer-HO for correction, categorized by contractor, and - No. of times invoice signatures were missed by any PMC and Developer Office Personnel, categorized by individual.

[0339] The system 100 provides the Invoices for Suppliers Module. The module includes various features which are explained below in detail. The purpose of the Invoices for Suppliers module is to streamline and standardize the invoice certification process across all parties involved, from the supplier to the Developer’s Accounts Department. It ensures that all supporting documents are accurately reviewed and processed, providing a clear overview of material delivery and acceptance. By establishing a structuredhierarchy and reporting system 100, the module enhances accountability and efficiency in handling invoices, thereby improving overall operational performance and tracking delays.

[0340] In an embodiment, steps in Uploading Invoice by Supplier is illustrated further. The supplier’s office must upload their invoice for verification by the site supervision teams of the developer or PMC. This should include supporting documents such as challans, manufacturer’s certificates / test-reports, mapped delivery details, and photos of the materials planned for delivery or delivered at the site, as mentioned in the invoice. If necessary, the supplier billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer or PMC’s office. The senior manager will then forward the certified invoice to the developer or PMC’s office.

[0341] Invoice Certification by Site-Supervision-Team - The Site-Supervision Team of the Developer or PMC will review the supplier's invoice and provide feedback. If additional clarifications are required, they may return the invoice to the supplier for revision. Alternatively, they may approve the invoice and request the supplier to submit any additional documents before forwarding it to the Developer / PMC head office. In some cases, they may approve the invoice and send it directly to the Developer / PMC head office.

[0342] Invoice Certification by PMC Head-Office - The PMC Billing Department will review the supplier’s invoice in accordance with the PO terms. Once audited, the PMC head office will forward the certified invoice to the Developer’s office. If necessary, the PMC Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Developer. The senior will then forward the certified invoice to the developer’s office.

[0343] Invoice Certification by Developer's Billing Engineer for Payment Submission - The Developer's Billing Engineer will re-audit the certified invoice received from the PMC head office. Once verified, the engineer will submit the invoice to their accounts department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0344] In an embodiment, detailed Insight into delivery status and compliance via the system 100 is illustrated further. The system 100 material-invoice protocols and process provide a comprehensive overview of delivery status for office-based personnel, offering a clear depiction of the material acceptance status from the site team.

[0345] In an embodiment, invoice expediting process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver may approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0346] In an embodiment, Reports on Supplier's Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to Supplier's Invoice Certification. The reports include average no. of days taken by the Site-Team for invoice certification, categorized by supplier, average no. of days taken by the PMC head office for invoice certification, categorized by supplier, average no. of days taken by the Developer head office for invoice certification, categorized by supplier, average no. of times an invoice is returned to the Supplier for correction, categorized by supplier, average no. of times an invoice is returned to the Site-Team by PMC-HO or Developer-HO for correction, categorized by supplier, average no. of times an invoice is returned to the PMC-HO by Developer-HO for correction, categorized by supplier, and No. of times invoice signatures were missed by any PMC and Developer Office Personnel, categorized by individual.

[0347] The system 100 provides the Invoices for Security Agencies Module. The module includes various features which are explained below in detail. The Invoices by Security-Agencies module streamlines the invoicing process by ensuring structured submission, verification, and certification of invoices. It offers a clear view of delivery status and supports efficient tracking of invoice processing and corrections. This enhances transparency and accountability, improving overall efficiency in consultant payments and project management.

[0348] In an embodiment, steps in Uploading Invoice by Security Agency is illustrated further. The Security Agency’s office must upload their invoice for verification by the head office of the developer. This should include the supporting documents specified in the appointment letter, which must be tagged along with the invoice. If necessary, the Security Agency billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer office. The senior manager will then forward the certified invoice to the developer's office. 2) Invoice Certification by Developer's Billing Engineer for Payment Submission. The Developer's Billing Engineer will review the Security Agency’s invoice in accordance with the Appointment-Letter terms. Once verified, the engineer will submit the invoice to their Accounts Department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0349] In an embodiment, detailed Insight into Delivery Status and Compliance via the system 100 is explained further. The system’s Security -Agency -invoice protocols and process offer a thorough overview of delivery status for office-based personnel, providing a clear account of the deliveries made by the Security Agency as per the appointment letter. The Security Agency may reference and tag documents from previous invoices to the current one, facilitating quick access for the billing and accounts department.

[0350] In an embodiment, Invoice Expediting Process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver may approve the invoices, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approvercannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0351] In an embodiment, Reports on Security Agency's Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to Security Agency's Invoice Certification. The reports include average no. of days taken by the Developer head office for invoice certification, categorized by Security Agency, average no. of times an invoice is returned to the Security Agency for correction, categorized by Security Agency, and No. of times invoice signatures were missed by any Developer Office Personnel, categorized by individual.

[0352] The system 100 provides the invoices for CAs Module. The module includes various features which are explained below in detail. Invoices by CAs module streamlines the invoicing process by ensuring structured submission, verification, and certification of invoices. It offers a clear view of delivery status and supports efficient tracking of invoice processing and corrections. This enhances transparency and accountability, improving overall efficiency in consultant payments and project management.

[0353] In an embodiment, steps in uploading Invoice by Chartered Accountants (CA) is illustrated. The CA’s office must upload their invoice for verification by the head office of the developer. This should include the supporting documents specified in the appointment letter, which must be tagged along with the invoice. If necessary, the CA billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the developer office. The senior manager will then forward the certified invoice to the developer's office. Further, invoice certification by developer's billing engineer for Payment submission is illustrated. The Developer's Billing Engineer will review the CA’s invoice in accordance with the Appointment-Letter terms. Once verified, the engineer will submit the invoice to their accounts department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0354] In an embodiment, detailed insight into Delivery Status and Compliance via the system 100 is explained further. The system’s CA-invoice protocols and process offer a thorough overview of delivery status for office-based personnel, providing a clear account of the deliveries made by the CA as per the stages outlined in the appointment letter. The CA can reference and tag documents from previous invoices to the current one, facilitating quick access for the billing and accounts department.

[0355] In an embodiment, the Invoice Expediting Process is explained further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver can approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0356] In an embodiment, the reports on CA's Invoice Certification Metrics is explained further. Various reports are prepared by the system 100 related to CA's Invoice Certification. The reports include average no. of days taken by the Developer head office for invoice certification, categorized by CA, average no. of times an invoice is returned to the CA for correction, categorized by CA, and No. of times invoice signatures were missed by any Developer Office Personnel, categorized by individual.

[0357] The system 100 provides the invoices for housekeeping agencies module. The module includes various features which are explained below in detail. The invoices by housekeeping-agencies module streamlines the invoicing process by ensuring structured submission, verification, and certification of invoices. It offers a clear view of delivery status and supports efficient tracking of invoice processing and corrections. This enhances transparency and accountability, improving overall efficiency in consultant payments and project management.

[0358] In an embodiment, the steps in uploading an invoice by housekeeping agency is illustrated further. The housekeeping agency’s office must upload their invoice for verification by the head office of the developer. This should include the supporting documents specified in the appointment letter, which must be tagged along with the invoice. If necessary, the Housekeeping Agency billing person may first forward the draft-invoice to a senior manager within the company, following internal procedures, before it is sent to the Developer. The senior will then forward the certified invoice to the Developer’s office. 2) Invoice Certification by Developer's Billing Engineer for Payment Submission. The Developer's Billing Engineer will review the Housekeeping Agency’s invoice in accordance with the Appointment-Letter terms. Once verified, the engineer will submit the invoice to their Accounts Department for payment processing. If necessary, the Billing Engineer may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the Accounts Department. The senior manager will then forward the certified invoice to the Accounts Department.

[0359] In an embodiment, detailed Insight into Delivery Status and Compliance via the system 100 is explained further. The system 100 Housekeeping-Agency-invoice protocols and process offer a thorough overview of delivery status for office-based personnel, providing a clear account of the deliveries made by the Housekeeping Agency as per the appointment letter. The Housekeeping Agency can reference and tag documents from previous invoices to the current one, facilitating quick access for the billing and accounts department.

[0360] In an embodiment, the Invoice Expediting Process is illustrated further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the Developer. However, if necessary, any subsequent approver can approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0361] In an embodiment, reports on the housekeeping agency's invoice certification metrics are illustrated further. Various reports are prepared by the system 100 related to Housekeeping Agency's Invoice Certification. The reports include average no. of days taken by the Developer head office for invoice certification, categorized by Housekeeping Agency, average no. of times an invoice is returned to the Housekeeping Agency for correction, categorized by Housekeeping Agency, and No. of times invoice signatures were missed by any Developer Office Personnel, categorized by individual.

[0362] The system 100 comprises the Invoices by Sub-contractors Module. The module includes various features which are explained below in detail. The Invoices by Sub-contractors module aims to streamline and standardize the invoicing process for subcontractors. It ensures that invoices are submitted, reviewed, and certified through a defined workflow, from the Site-Supervision Team to the Contractor’s head office. This module provides a structured approach to track on-site work, including detailed documentation such as task and housekeeping photos, and generates comprehensive reports on invoice processing times and discrepancies. By maintaining a clear and organized process, the module improves accountability, efficiency, and transparency in managing subcontractor payments and project expenses.

[0363] In an embodiment, steps in uploading an Invoice by sub-contractor is illustrated further. The sub-contractors office (whether their Site-Team or Office-Team) must upload their invoice for verification by the Site-Supervision-Teams of the contractor. This should include supporting documents such as site-work photos of the tasks claimed in the invoice and housekeeping photos related to the work. If necessary, the subcontractor billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the contractor. The senior manager will then forward the certified invoice to the contractor's office. Invoice Certification by Site-Supervision-Team. The Site-Supervision Team of the contractor will review the sub-contractor's invoice and provide feedback. If additional clarifications are required, they may return the invoice to the sub-contractor for revision.

[0364] Alternatively, they may approve the invoice and request the sub -contractor to submit any additional documents before forwarding it to the contractor's head office. In some cases, they may approve the invoice and send it directly to the contractor head office. Document Attachment by Sub-contractor, Once Invoice Approved by Site-Team. If the site team has approved the invoice and sent it to the sub-contractor, the sub-contractors head office will then attach the necessary documents, as instructed in the invoice format provided by the contractor, and submit them to the contractor's head office. If necessary, the sub-contractor billing person may first forward the invoice to a senior manager within the company, following internal procedures, before it is sent to the contractor. The senior manager will then forward the certified invoice to the contractor's office. Invoice Certification by Contractor's Billing Engineer for Payment Submission. The Contractor's Billing Engineer will review the sub-contractor’s invoice in accordance with the contract terms and the work completed. Once verified, the engineer will submit the invoice to their Accounts Dept for payment processing. If necessary, the billing engineer may first forward the invoice to a senior managerwithin the company, following internal procedures, before it is sent to the Accounts Dept. The senior manager will then forward the certified invoice to the Accounts Dept.

[0365] In an embodiment, detailed Insight into On-Site Works and Compliance via the system 100 is explained further. The system 100 contract-invoice protocols and process provide a comprehensive overview of on-site work for office-based personnel. Attached site photos of the tasks claimed in the invoice, along with housekeeping photos, offer a clear depiction of the work's status upon completion.

[0366] In an embodiment, invoice expediting process is explained further. In the invoice certification process, the system 100 has established a complete hierarchy from the Site Team to the Accounts Dept of the developer. However, if necessary, any subsequent approver may approve the invoice, even if the previous approver has not. Once a subsequent approver has approved the invoice, the previous approver cannot. The system 100 reports these delays to company management, which may negatively affect the performance reviews of the previous approver.

[0367] In an embodiment, handling 'Extra-Items' invoicing in the system 100 is illustrated further. Extra-Items claimed by sub-contractors must be invoiced separately to ensure comprehensive tracking within the system 100. The system 100 monitors all extra item invoices from sub-contractors and generates a report upon project completion. This report provides the Contractor with a detailed overview of the total number of invoices and the amounts claimed, broken down by sub-contractors.

[0368] In an embodiment, reports on Sub-contractor Invoice Certification Metrics is illustrated further. Various reports are prepared by the system 100 related to Subcontractor's Invoice Certification. The reports include average no. of days taken by the Site Team for invoice certification, categorized by subcontractor, average no. of days taken by the Contractor's head office for invoice certification, categorized by sub-contractor, average no. of times an invoice is returned to the Sub-contractor for correction, categorized by sub-contractor, average no. of times an invoice is returned to the Site-Team by Contractor-HO for correction, categorized by sub-contractor, and No. of times invoice signatures were missed by any Contractor Office Personnel, categorized by the individual.

[0369] In an embodiment, suppliers, CAs, security agencies, and housekeeping agencies may share their quotes, receive POs / WOs / appointment letters, and submit invoices to their clients through the specified modules designed by the system 100 for each function (quotes, letters, and invoices) without needing to be connected to a developer’s project. However, if their clients connect them in reference to a developer’s project, their quotes, letters, and invoices will be tracked using the project reference. Additionally, they can exchange this information through the ProCom mail system 100.

[0370] In an embodiment, Architects, consultants, and PMCs often collaborate on a developer’s project, where the consultant initially approached by the developer is referred to as the 'Principal Consultant'. However, architects, consultants, and PMCs must be connected to a developer’s project to share quotes, receive appointment letters, and raise invoices to the principal consultant through the specified modulesdesigned for these purposes. Without this connection, they cannot use these modules for sharing quotes, letters, or invoices. They can, however, still exchange this information through the ProCom mail system 100.

[0371] In an embodiment, Sub-contractors also cannot share their quotes, receive Work Orders, or raise invoices to the contractor through the specified modules (designed specifically for sharing quotes, Work Orders, and invoices) without being connected to a developer’s project. However, they can still exchange this information through the ProCom mail system 100.

[0372] Management of Project Work-Reporting which includes Meeting-Invites / MOMs, tracking Checklists / Snaglists, tracking Rectification Instructions issued by Architect / Consultants, Daily Work Reports & Monthly Progress Reports through the system 100 is illustrated further:

[0373] The system 100 helps / directs Project-Team-members (users) to share any data in the exact- required category of document (MOMs / Checklists / Snaglists / Site-Inspection-Reports / Quality-Inspection- Reports / Daily-Work-Reports / Monthly-Progress-Report etc.). System’s data-sharing-process and location is designed in such a way that even if the organization is managing any-number of projects, the data may be tracked / searched / accessed by a user very easily in future.

[0374] The system 100 provides a unique way of sending invites for the Meetings & Recording the Minutes of Meeting (MOM). Any project team / member may “Call” for the meeting by sending “blank” invites or invites with his “Agendas”. Other teams / members may “add” their “Agendas” if they wish to add in the “Original Meeting Agenda” prepared by 1stperson. They can amend their self-prepared agenda till the meeting is placed (till meeting “time” is not passed). Once a meeting is “fixed / set” reminder is given in previous evening to every-one expected to attend the meeting. Once the person expected to attend the meeting reaches the “meeting place” the system 100 automatically records his attendance for the meeting. Once the meeting is over, every team is expected to prepare his own MOM (using his previously self-recorded Agenda of the Meeting) and such “individual / isolated” MOM is then clubbed with MOM of all other attendees.

[0375] The system 100 comprises a snaglist module. The module includes various features which are explained below in detail: During the course of work execution, the checklists manage the quality of the work being performed at the site. The QRNs (quality rectification notices) ensure that any missed or omitted quality issues are tracked and rectified to the satisfaction of the reporting individual. However, once the project handover begins, it is crucial that the completed product is handed over to the customer only after a final audit of the executed items. The Snaglist is used for this final review, identifying points that need to be addressed before any type of work may be considered complete.

[0376] In an embodiment, steps for signing snaglists are illustrated further. The snaglists act as a tool for the final auditing of executed work. Firstly, during the final audit of executed works (when signing the snag list), engineers must take photos of all products and make being handed over. As the engineer performs this task, an OCR tool (reader) records details about the "makes" and reports them to the purchasing department. This allows the department to compare the supplied makes with those being handed over to the customer, ensuring that the delivery matches what was promised. If any discrepancies are found between thematerials being handed over and what was ordered, corrective measures can be promptly taken by the designated authority. In another embodiment, replying to final quality audit questionnaires, the engineer must read and respond to all quality-related questions thoroughly. The questionnaires provided in the Snaglists facilitate a point-by -point audit of the product being handed over.

[0377] In an embodiment, corrections about product or work quality are reported with comments on photos. Lastly, the engineer should take photos of areas or elements where product replacements or corrections are needed by the contractor. These photos must be annotated with clear and specific instructions for the contractor to follow. The engineer may also provide additional guidance as necessary. In an embodiment, the contractor has to upload details of completed replacements or rectifications. The contractor's site supervision team addresses the rectifications suggested by the site supervision teams of the developer / PMC and uploads counter photos that address the points raised during the audit. The site supervision teams of the developer / PMC will then visit these areas to verify the corrections, approve them, and issue a closure report along with their review photos. If they are not satisfied with the type of correction made, they may ask the contractor to resubmit the correction after making further adjustments according to the latest suggestions.

[0378] In one embodiment, snaglist signing protocol is illustrated further. In an embodiment, if the site supervision teams of both the developer and PMC are on site, they can decide among themselves who will sign the snaglists first and who will sign subsequently. The contractor should make the necessary rectifications for the raised issues and sign off afterward. However, if the site supervision team of the developer / PMC is not available on-site, the contractor may review their work themselves according to the points mentioned in the snaglists and sign off for documentation purposes to maintain the flow of the handingover process.

[0379] Further, reports of materials handed over to the buyer is illustrated. In an embodiment, while signing the Snaglist for various types of work, the materials being handed over to customers are reported. This information is used by the system 100 to prepare a comprehensive report which showcases Makes in POs (makes ordered through purchase orders), Makes at Store (makes received from the suppliers at the store), Makes at Checklists (makes used at the site), Makes at Snaglists (makes handed over to the customer), and Makes at Certificates (makes identified through certificates uploaded by the purchase department).

[0380] In an embodiment, reporting of signed, and unsigned snaglists is illustrated further. In an embodiment, when a contractor submits an invoice to the developer for completed work, a detailed report on the snaglists is automatically attached to the invoice. This report includes: Snaglists SIGNED / CLOSED TILL DATE, for contractor's scope of works, Snaglists SIGNED but still PENDING TO GET ATTACHED by contractor, CLOSED Snaglists but NOT SIGNED by contractor, TILL DATE, and CLOSED Snaglists but NOT SIGNED by contractor, from last to current invoice.

[0381] The system 100 comprises all meeting details (invites & MOMs) modules. The module includes various features which are explained below in detail. The module streamlines meeting managementthrough ProChat and the system 100 by simplifying the scheduling and invitation process. This ensures all teams are prepared and aware of expectations. By digitizing agendas and minutes preparation, the module enhances accuracy in recording and organizing discussions. The system 100 enables clear documentation, making it easier to track decisions and actions. It also reduces the risk of missing key points and improves accountability. Overall, it facilitates effective meeting preparation, participation, and documentation.

[0382] Steps in making agenda for the meeting (invites) is illustrate further. In an embodiment, by using the project group on ProChat, project teams may set the meeting venue, date, time, and attendees for the meeting. For design review meeting (DRM), coordination should be done in the 'consultants' group on ProChat. For the contract evaluation meeting (CEM), coordination should be done in the 'client & PMC group on ProChat. For the site-progress review meeting (SRM), coordination should be done in the 'SITE' group on ProChat. In another embodiment, the module sends invitations for the meeting.

[0383] Once all attendees, the meeting venue, date, and time are decided, anyone from the attendees can send an 'invite' to other attendees for the project meeting through ProChat or the system’s app module, based on the meeting category (DRM, CEM, or SRM). Invitations to any new office teams (not originally included in the meeting invite) may be sent by any involved party until the meeting's date and time expired. In another embodiment, sharing agenda points for the meeting by attendee offices by through the system 100. Any invitee from each invited office may then access the "list user meeting agenda" page on the meeting 'invite' received, voice record their agenda points, transcribe it, and upload it, categorizing their agenda points under the appropriate 'discussion matter' category. They can also upload reference files that they think might be needed for discussing their agenda points.

[0384] As soon as agenda points are uploaded by each invited office, the system 100 rearranges them according to the selected 'discussion matter' category to create the compiled agenda points for the meeting. Agenda points uploaded by one invited office cannot be edited or deleted by any other invited office. Only the person who uploaded the agenda point or their company colleague may amend, delete, or add more points. However, attendees from the developer / PMC offices can delete any uploaded agenda point, and a history of changes is saved. Agenda points remain 'editable' only until the meeting's date and time expire. Deleted agenda points are visible only to the uploading office. The agenda will be sent only to the invited offices connected to the project.

[0385] Steps in making minutes of meeting (MOM) is illustrated further. In an embodiment, invitee mark their attendance in the meeting by using the MOM module. As soon as an invitee or their office colleague arrives at the meeting venue, if a 'meeting' is set for them or their office at the venue, the system 100 will send a notification to mark their attendance (to add their name to the attendee list). If the meeting venue changes at the last minute and is not updated in the meeting 'invite,' the attending person or their colleague must access the meeting 'invite' to mark their attendance. If any new or unknown person is attending the meeting whose name was not included in the invite, a developer / PMC person can add their name to the meeting attendee list. In another embodiment, the audio recording of the meeting is done through the MOMmodule. The meeting discussion should be recorded by any attendee using the 'record user pre-scheduled meeting' button in the "action" field of the received 'invite,' if the meeting was pre-scheduled based on an 'invite.' In an embodiment, the 'invite' may include preset agenda points or have no agenda points at all. If no 'Invite' was shared, user may use the 'record your meeting' button on the "minutes of meeting" page to record. Ensure clear audio for quality transcription, and avoid any obstructions during recording.

[0386] In another embodiment, the MOM module provides a speech to text conversion and editing option to attendee. The audio file is then processed through speech recognition software which detects words and converts them into a text document. The draft transcript of all meeting points is then shared with each attendee office. They can select their points and then review and edit to correct any transcription errors in their Minutes. In an embodiment, the module provides sharing minutes of meeting (MOM) features. The final transcript is formatted into standard minute styles by the respective attendee office. The discussed points must be then organized under the appropriate 'discussion matter' category by the attendee office, highlighting decisions and action items. Each attendee office must prepare the minutes of meeting (MOM) for the points discussed with others, where decisions, clarifications, or notations were obtained from other project teams. As soon as an office submits its MOM, it becomes visible to all for review and further action.

[0387] Once MOM are uploaded by each attendee office, the system 100 rearranges them according to the selected 'discussion matter' category to create the compiled MOM for the meeting. MOM uploaded by one office cannot be edited or deleted by any other office. Only the person who uploaded the MOM or their company colleague may amend, delete, or add points. However, attendees from developer / PMC offices can delete any uploaded MOM, and a history of changes is saved. MOM remains editable for any attendee office for 72 hours. Deleted MOM are visible only to the uploading office. The MOM will be sent only to the invited offices connected to the project.

[0388] In an embodiment, Hassle-free meeting scheduling, invitations, and notifications is illustrated further. ProChat helps in creating hassle-free meeting 'Invites'. Once the meeting is scheduled, the system 100 creates a calendar entry and notifies all concerned parties the evening before at 7:30 PM about the meeting the next day.

[0389] In an embodiment, optimized meeting preparation and attendance tracking is illustrated further. The unique approach to collecting agenda points through the 'Invites' makes it easier for every team to understand what other teams expect from them, so they can come prepared. Since the responsibility for uploading agenda points (that need clarification from other project teams) and uploading MOM (after doubts or points are clarified) falls on the team with the questions, the chances of missing discussion on important points or failing to record discussed and decided points are eliminated. Additionally, the responsibility for marking attendance is on the attendees, reducing the possibility of omitting names.

[0390] In an embodiment, accurate moms for easy point retrieval is illustrated further. Conventional note-taking in meetings often misses key details, decisions, and nuances, and if the note-taker is absent, minutes might not be recorded at all. Digitally preparing agendas and MOMs eliminates the need for manualnote-taking. Recording and transcribing meetings later not only helps remote teams accurately capture and document discussions but also allows attending staff to participate fully. Well-recorded agendas and MOMs make it easy to search and reference minutes and provide clear documentation and accountability for decisions.

[0391] In an embodiment, reporting of meeting attendees is illustrated further. In an embodiment, any office may check the meetings attended by any other office or individual from any office. This report includes the number of DRM meetings attended by each office (date-wise) TILL DATE, the number of CEM meetings attended by each office (date-wise) TILL DATE, the number of SRM meetings attended by each office (date-wise) TILL DATE, the number of DRM meetings attended by each individual (date-wise) TILL DATE, the number of CEM meetings attended by each individual (date-wise) TILL DATE, and the number of SRM meetings attended by each individual (date-wise) TILL DATE.

[0392] The system 100 provides an issued all POs module. The module includes various features which are explained below in detail. The purchase order (PO) module in the system 100 manages the procurement process by handling two types of POs: Open POs (unit rates only) and Qty-based POs (quantities and unit rates). POs can be issued with or without an MRS but must include an MRS for delivery requests. Approval from designated authorities is required before POs become visible to suppliers. The module ensures efficient PO closing, either automatically or manually, and manages non-BOQ items with fewer formalities to prevent delays.

[0393] In an embodiment, PO types and MRS attachment procedures is illustrated further. The system 100 provides two types of PO’s i.e., Open PO and Qty -based PO. The Open type of PO specifies only unit rates without mentioning quantities. Open POs are not ideal for effectively tracking ordered versus supplied quantities. In another embodiment, the Qty -based PO includes both quantities and unit rates, along with net amounts. The Qty-based POs are preferred because they provide better tracking of ordered versus supplied quantities. In an embodiment, A PO may be issued to suppliers without initially attaching an MRS, but the MRS must be attached to the PO before requesting delivery of the materials if it was not included at the time the PO was created. Conversely, if an MRS was sent to the supplier without an accompanying PO due to urgent circumstances, the PO must be attached to the MRS afterward. This process ensures accurate reconciliation and tracking.

[0394] In an embodiment, steps for issuing a PO is illustrated further. In one embodiment, PO can be prepared by either the PMC's office team or the Developer's Purchase / Accounts dept. POs may be based on either MRSs or the project BOQ. If multiple MRSs are received for different types of materials and work on a project, they may be combined when issuing a PO. For any material type, the quantity specified in the PO may be more or less than the total indented quantity across all MRSs. When a quantity-based PO is issued and includes any part of the indented quantity for a material type, the MRSs for that material type will be closed, even if the PO quantity is less than the total indented quantity in those MRSs. Conversely, if the PO does not include any of the indented quantity from an MRS, that MRS will remain active and unused. In anotherembodiment, the POs can be approved by the developer, JV partners, company partners, key-managers, or the accounts-head at the developer's office. Only after approval will the POs become visible to the suppliers.

[0395] In an embodiment, system 100 alerts for MRS and PO handling is illustrated further. In an embodiment, on any project, if an open PO or Qty -based PO is being sent to a vendor and there is an existing MRS in the system 100 that is not attached to any PO, the system 100 will alert the sender to attach the MRS. The sender may choose to ignore this alert, and their action will be recorded in the 'history'. If an MRS is sent directly to a vendor for supplying materials without attaching a PO, while there is an active PO issued to the vendor for the same materials, the system 100 will alert the sender to attach the PO. The sender may choose to ignore this alert, and their action will be recorded in the 'History'.

[0396] In one embodiment, issuing PO for already received materials is illustrated further. In an embodiment, if the purchase / accounts teams were unavailable to prepare a PO and no active PO was available to attach to a new MRS (for sending to the supplier), and supplies were received based on an MRS approved by the site team and PO approving authorities. The purchase / accounts teams may use the 'issuing PO: for already-received materials button once they return to the office. The system 100 will automatically retrieve details of the received dispatches that lack POs, enabling the creation of a PO and ensuring proper MRS-PO alignment.

[0397] The handling MRS with insufficient quantity in active PO is illustrated further. In an embodiment, if an MRS is requested for a certain quantity, but the active PO with the supplier has a remaining quantity less than this, the MRS quantity will be automatically adjusted to match the remaining quantity on the PO. A system-generated message will notify the user that the MRS quantity being forwarded to the supplier has been reduced and that any additional quantity will require a new MRS along with a new PO.

[0398] In one embodiment, restrictions on PO for suppliers with pending issuance is illustrated further. In an embodiment, when a new PO is being prepared using the button labelled 'Issuing PO. For future supply of materials, if one or more suppliers have already delivered materials without a PO being issued, the system 100 will notify that a new PO cannot be issued to those suppliers until the PO for the already received materials is issued. However, new POs can be issued to other suppliers for any material type.

[0399] The Purchse Order (PO) closing procedures in the system 100 is illustrated further. In an embodiment, the POs issued to suppliers are either closed automatically or the purchase / accounts department of the developer is notified to close them. In the system 100, POs are never left open indefinitely. Suppliers cannot create dispatches for closed POs. In one embodiment, system 100 provides automatic PO Closing option. When a new Open PO or quantity -based (Qty -based) PO is issued to a supplier for the same material type and specification, any previous issued active Open PO for that material type and specification will be automatically closed. Similarly, if an Open PO is issued to a supplier for the same material type and specification, any previous issued active Qty-based PO for that material type and specification will be automatically closed. Additionally, an Open PO or Qty-based PO will be automatically closed if its validitydate expires. A Qty-based PO will also be automatically closed once 100% of the specified quantity has been delivered by the supplier.

[0400] In another embodiment, the system 100 provides manual PO Closing option. If a supplier declines to supply more material or if there are quality issues or disputes, the purchase / accounts department of the developer may manually close the PO. A reason must be provided for the closure, and the action will be recorded along with the name of the person who closed it. Suppliers cannot close POs manually; this may only be done by the purchase / accounts department of the Developer.

[0401] In another embodiment, the system 100 provides reminder to purchase / accounts department to close PO. If no material is supplied under a PO for more than 90 days, the system 100 will remind the purchase / accounts department to close it if no further supplies are expected. If some material was supplied initially but the PO has been inactive for 180 days, the dept will also be reminded to close it if no additional supplies are anticipated. In another embodiment, the system 100 provide an option for addition to the quantity of an existing Qty-based PO, when a new Qty-based PO is issued for the same type of materials and specifications, the quantities of both POs will be combined for the supplier to fulfil.

[0402] In an embodiment, seamless process of issuing PO issuing for Non-BOQ items is illustrated further. In an embodiment, POs for non-BOQ items ('Un-Listed') can be submitted without the usual formalities for handling new materials in the project, thereby avoiding delays and preventing labour idling. Such POs may only be Qty-based POs and cannot be Open POs. the planning or purchasing department must obtain approval from the designated approving authorities. Once approved, the item’s quantity will be updated in the BOQ for future reference, and marked as an Un-Listed' item for quick identification.

[0403] Various reports for reviewing the performance of the site team, purchase / accounts person, and the supplier is illustrated further. In an embodiment, various reports are prepared by the system 100 related to purchase orders (POs) for reviewing the performance of the site teams, purchase / accounts persons, and the suppliers. The reports include reports on the number of open POs issued by the purchase / accounts department: This report details the quantity acquired through Open POs. Open POs are discouraged as they complicate the reconciliation process. The report further includes reconciliation report comprising total project BOQ vs. quantity-based PO vs. actual delivered quantity: This report also details the quantity acquired through Open POs. Open POs are discouraged as they complicate the reconciliation process. The report further includes report on ordered quantity vs. delivered quantity. This report highlights instances where the supplier has reduced the quantity supplied after the order was placed, increasing the workload on purchase / accounts to find alternative sources of supply. The report further includes report on the number of times MRS was sent to the supplier before PO issuance. This report indicates whether the site team requested material at the last minute or if purchase / accounts failed to appoint a vendor promptly. This report shows the quantity ordered through such MRS to inform company management about its impact on the purchasing process. The report further includes report on the date difference between the PO and the earliest dated MRS attached to the PO. Thisreport informs company management about the promptness of the purchase / accounts department in ordering material after receiving the MRS.

[0404] The system 100 provides delivery details of the Developer-material & entry permissions module. The module includes various features which are explained below in detail. The purpose of the delivery detail module is to streamline the management of construction material deliveries by ensuring accurate documentation and efficient processing. It facilitates the upload and review of delivery details by suppliers and stores and helps the site team assess site conditions before authorizing deliveries. The module also tracks and manages partial deliveries, ensuring that materials are dispatched and processed in the order of their requests. By integrating MRSs and POs into the system 100, it improves stock management and delivery planning, minimizing discrepancies and delays.

[0405] In an embodiment, steps in providing delivery details of materials and entry permissions are illustrated further. In one embodiment, construction materials are procured by developers, contractors, and sub-contractors. Site teams issue MRSs based on project material requirements. The purchase / accounts Department to finalize the supplier to fulfil these requirements. Materials are typically sourced from existing godowns, where surplus materials are stored for future project use, or from external vendors. Following are the steps in providing delivery details:

[0406] As per on embodiment, for uploading delivery details by the supplier / existing store, the designated person at the external supplier or internal company store is responsible for uploading the 'delivery details' for the materials being supplied, based on the received Material MRS / PO. Existing godowns provide delivery details upon receiving the MRS, while external vendors provide delivery details upon receiving the MRS or PO. In another embodiment, for reviewing material being delivered and issuing 'entry permission', once the Delivery Details' are received from the supplier or store, the site team must evaluate the available unloading space, storage capacity, and storage conditions at the site. This assessment ensures that materials can be unloaded, properly stored, and protected from weather and potential damage until they are needed. If the site conditions are deemed satisfactory, the site-team to issue 'Entry Permission' to the supplier or store, authorizing the delivery of the materials. The site team must also verify that the materials being dispatched match the original request. If there are discrepancies, the accounts or purchase department should be informed to take the necessary steps to resolve the issue. In another embodiment, acknowledgment by the supplier / existing store and site-security. Once the site team issues the 'Entry Permission,' both the supplier and existing store responsible for the delivery and site security must acknowledge receipt of the permission. If no objections are raised, the delivery will proceed as scheduled.

[0407] MRS selection and closing procedures for dispatches are illustrated further. In one embodiment, when suppliers use the MRS to initiate a dispatch, they may easily navigate through client names and review the pending MRSs for each project individually. The details of all MRSs will be displayed collectively, allowing suppliers to assess their stock levels and plan the dispatch according to the requested materials. If the supplier is delivering only part of the requested materials, the MRS closing will be processedin the order they were received: the first MRS will be closed first, followed by the second, depending on the quantities being dispatched.

[0408] Similarly, when central-store uses the MRS to initiate a dispatch, they can review the pending MRSs for each project individually. The details of all MRSs will be displayed together, enabling the store to assess stock levels and plan the dispatch based on the requested materials. If only part of the requested materials is being delivered, MRSs will be closed in the order they were received: the first MRS will be closed first, followed by the second, depending on the quantities being dispatched.

[0409] The PO selection and closing procedures for dispatches are illustrated further. In one embodiment, when suppliers use the PO to initiate a dispatch, they may easily navigate through client names and review the issued & active POs for each project individually. The details of all materials quantity asked in the POs and the balance yet to be supplied in the POs will be displayed collectively, allowing suppliers to assess their stock levels and plan the dispatch according to the ordered materials. If the supplier is delivering only part of the ordered materials, the PO closing will be processed in the order they were received: the first PO will be closed first, followed by the second, depending on the quantities being dispatched.

[0410] Checklists are designed & connected in such a way that if any Site-team misses the “primary” checklists & directly fills the “secondary” checklists, it is notified to the seniors. If Site-team misses “Primary / Secondary” checklists and directly fills the “Pour-card”, it is notified to the seniors. Once a filled checklist / pour-card is attached with any invoice, the same cannot be attached with any further invoice. This feature helps in forcing site-team to maintain records well in-line for getting attached with invoices-of- contractors for the works claimed in any invoice. If cubes casting is registered while filling a pour-card, system 100 will remind the site-team for testing of cubes as per registered dates of cube-testing. Once testing is accepted, system 100 will remind site-team to upload Test-Reports of the tested cubes. If Pour-card was filled for any pour, de-shuttering & curing stages of the pours are well tracked. Site-team has to report / upload photos of these stages, else it is notified to the seniors.

[0411] System 100 provides feature for raising Snaglists and then tracking those till all issues raised are not attended / rectified by the respective contractor.

[0412] If the Developer / Architects / Consultants make any un-scheduled visit and notices any wrong- doing / mistake / issue at site which they want to bring to the notice of site-team / contractor / other-team-members, they can upload their concern on All Rectifications / QIRs issued to Contractors. Such uploaded concern is tracked by system 100 and notified owners specifically. This forces site-team / contractor to rectify / resolve the concern.

[0413] Daily Work Reporting is no more a headache of a site engineering team with uniquely designed Daily Work Reporting in the system 100. Individual contractor / his-supervision-team may upload their individual DWR of the day which is then checked & verified by Developer / PMC’s site-team. Contractor’s individual labour is expected to upload photos of his work-area at Start-of-the-Day & At-End-of-the-Day / After-completing-the-assigned-work, which can be viewed / tracked by person monitoring their daily activities and all others connected on DWR.

[0414] Preparing Monthly Progress Report, review of it by Seniors / Managers and sharing the reviewed / completed MPR is made very smooth by system 100.

[0415] The system 100 comprises a checklist work modules. The module includes various features which are explained below in detail:

[0416] The checklist module streamlines construction quality assurance by automating checklist workflows, tracking material usage, and ensuring thorough inspections. The checklist module facilitates corrective actions, monitors essential tests, and generates detailed reports for effective documentation and accountability, thereby enhancing project oversight and maintaining high quality standards.

[0417] In an embodiment, checklist flow for any type of work: primary, secondary, and associated checklists is illustrated further. The system’s checklist module offers site-supervision-teams from the developer, PMC, and contractor a detailed overview of all required checklists for auditing various types of work. Once the first checklist for a task is signed off, the module automatically makes the associated second checklist available for review. Once the second checklist is signed off, the subsequent checklist automatically becomes available for review. However, if teams miss signing a checklist on time, they may skip it and proceed to sign the subsequent checklist. Once a subsequent checklist is signed, earlier checklists cannot be signed by the Site-Supervision-Teams.

[0418] Steps to be followed for signing up the checklists is illustrated further. In an embodiment, the system 100 receives inspection request (IR) by the contractor. The checklists serve as a tool for auditing executed works and guide engineers on what is expected during the inspection of specified tasks. The checklist outline the next steps for the site supervision team. Contractors who wish to have their completed work audited by the site-supervision-team of the developer / PMC must send an inspection request (IR) detailing the elements to be checked, along with photos of the work status. If the attached photos are not clear enough to explain the status of the work at the time of the request, the site supervision team of the developer / PMC may request additional photos. In another embodiment, reporting on products and usability of products is checked.

[0419] Firstly, during the audit of executed works (when signing the checklist), engineers has to take photos of all products and makes used in the execution of the tasks being reviewed. Whereas, the engineer performs this task, an OCR tool (reader) records details about the "makes" and reports them to the purchasing department. This allows the department to audit the supplied makes versus the makes used on-site, ensuring the quality of the work. If any discrepancies are found between the materials used on the project and what was ordered by the purchasing department, corrective measures can be taken promptly by the designated authority. In another embodiment, the checklist is replying to quality audit questionnaires. Secondly, the engineer must read all quality-related questions and respond responsibly. The questionnaires provided in the system’schecklists not only facilitate a point-by-point audit of executed works but also guide the engineer on what to check during the inspection.

[0420] In another embodiment, the checklist suggestions about work quality are reported with comments on photos. The engineer should take photos of areas or elements where corrections are needed by the contractor. These photos must be annotated with clear and specific suggestions for the contractor to follow. Additionally, the engineer may provide other instructions for the contractor. Architects and consultants can review the quality checklists maintained by the site teams to stay informed about the procedures being followed for the work executed on site. This enables them to be more confident in the strict measures implemented by the developer / PMC when conducting site inspections later. In another embodiment, if the contractor to upload details of completed rectifications. The contractor's site-supervision-team address the rectifications suggested by the site-supervision-teams of developer / PMC and uploads counter photos that address the points raised during the audit. The site-supervision-teams of the developer / PMC will then visit these areas to verify the corrections, approve them, and issue a closure report with their review photos, allowing the work to proceed. If they are not satisfied with the type of correction made, they may ask the contractor to resubmit the correction after making further adjustments according to the latest suggestions.

[0421] In an embodiment, checklist signing protocol is illustrated further. In an embodiment, if the site-supervision-teams of both the developer and PMC are on site, then the team may decide among themselves who will sign the checklists first and who will sign subsequently. The contractor should make the necessary rectifications for the raised issues and sign off afterward. However, if the site-supervision-team of the developer / PMC is not available on site, the contractor may review their work themselves according to the points mentioned in the checklists and sign off for documentation purposes to maintain the flow of quality control documentation.

[0422] In an embodiment, escalation of missed checklists to senior personnel is illustrated further. In an embodiment, if the engineer forgets to sign the first checklist (indicating that the work was executed but the engineer missed signing it on time). The engineer can still sign the second checklist. However, the missed checklist will be reported to their senior, who is responsible for reviewing the quality steps followed by the site-supervision-team. This omission will also be reported to key managers, the accounts-department, and the "site execution group" on the Prochat. If key managers are not connected to the project, any lapses by the sitesupervision-team and the contractor will be reported to the founder and partners of both the developer and the PMC. If the engineer signs the first checklist but misses the second, they may still sign subsequent checklists when relevant. However, this omission will be reported in the same manner.

[0423] In an embodiment, test report tracking and activity management via checklists is illustrated further. In an embodiment, filing a checklist also triggers the associated tests required to assess and record the quality of materials and completed work. Once a checklist for a task is signed off, the system 100 automatically initiates the requirement to upload the related test reports, ensuring that the site supervision team does not overlook this important activity. If the team fails to perform the testing and upload the report,this omission will be reported to designated seniors, key managers, and the accounts department. Additionally, the system 100 tracks the activities and effectively guides and manages each step in their execution. Some of the tracked and managed activities and tests are listed below:

[0424] Cube test tracking - In an embodiment, once the pour card is signed off and if concrete cube casting is registered, the system 100 automatically initiates the uploading of the cube test reports associated with the pour card. The engineer is reminded to initiates the tests in a timely manner and upload the reports.

[0425] Monitoring of curing - In an embodiment, curing processes for RCC, masonry, plaster, waterproofing, and other materials are comprehensively tracked on the system 100. Once the checklist for such work is signed off, the curing reporting page becomes accessible to the site supervision team and contractor. They are required to upload photos three times a day for all nine days of curing. Each day’s upload window opens three times. If photos are not uploaded within the designated time each day, the window will close, and the lapse will be reported to seniors, key managers, and the accounts department. If curing is performed using chemicals, the reporting process will be adapted accordingly in the system 100.

[0426] Report tracking for post-de-shuttering and re-propping - In an embodiment, it is necessary to check the quality of executed work after de-shuttering so that necessary rectifications can be initiated immediately. Simultaneously, re-propping should be carried out as soon as de-shuttering is completed. Once the pour-card is signed off, the reporting threads for issues in the executed work following de-shuttering and re-propping are automatically initiated. These reporting threads are tracked until the contractor makes the necessary corrections to the satisfaction of the site supervision team of the developer / PMC.

[0427] Tracking and management of waterproofing activities - In an embodiment, waterproofing activities involve several key steps to monitor, including surface preparation, application of waterproofing chemicals, protection of the applied chemicals, filling sunken areas or providing slopes (using brick, AAC blocks, or screed), and finally, applying a top protection layer. The system’s checklist ensures that all necessary steps for each type of waterproofing are followed effectively and records the quality of the executed work. Additionally, the system 100 provides essential guidance for even less experienced engineers at every stage of the execution process.

[0428] In an embodiment, reporting on materials used in the project is illustrated further. In an embodiment, while signing the checklist for various types of work, the materials used at the site are reported. This information is used by the system 100 to prepare a comprehensive report which showcases: Makes in the POs (makes ordered through purchase orders), Makes at Store (makes received from the suppliers at the store), Makes at Checklists (makes used at the site), Makes at Snaglists (makes handed over to the customer), and Makes at Certificates (makes identified through certificates uploaded by the purchasing department).

[0429] Further, reporting of signed and missed checklists are illustrated further. In embodiment, when a contractor submits an invoice to the developer for completed work, a detailed report on the checklists is automatically attached to the invoice. This report includes Checklists SIGNED / CLOSED TILL DATE, for contractor's scope of works, Checklists SIGNED but still PENDING TO GET ATTACHED by contractor,CLOSED Checklists but NOT SIGNED by contractor, from last to current invoice, and Checklists SKIPPED by the contactor, from last to current invoice.

[0430] Figure 3 illustrates a block diagram of a first exemplary embodiment of housekeeper connectivity to a housekeeping agencies and subsequent engagement at offices / project sites on behalf of an employer, in accordance with an embodiment of the present subject matter.

[0431] The system 100 comprises a quality rectification notices (QRNs) and housekeeping & safety notices (HSNs) modules. The module includes various features which are explained below in detail: The purpose of QRN and HSN modules is to solve matters related to quality, housekeeping, and safety which are frequently reported, and notices are issued to contractors to address these issues. However, without a robust tracking tool, these matters can be overlooked, leading to repeated offenses by contractors and diverting the focus of the site team towards unproductive issues. The system 100 provides a tool to track every reported matter until it is rectified to the satisfaction of the site supervision team of the developer / PMC or the individual who reported it. If a matter is noticed by an office-bearing authority (rather than a member of the site-supervision-teams of the developer / PMC) and to report and track the issue until a resolution is reached, it can be challenging without a robust tracking tool. This situation becomes even more difficult if the issue is observed during a casual site visit in the absence of the site-supervision-teams of the developer / PMC / Contractor. In such cases, the reporting person may struggle to determine whom to report the issue to, ensuring that it is addressed and resolved properly. Often, the reporting person may not know which contractor is associated with the issue, making it difficult to identify and address the problem effectively. The QRN (Quality Rectification Notice) and HSN (Housekeeping & Safety Notice) modules offer a solution for tracking and resolving issues related to quality, housekeeping, or safety.

[0432] In an embodiment, steps for signing a QRN or HSN is illustrated further. In an embodiment, if reporting issues related to work quality, housekeeping, or safety with comments on photos then the sitesupervision-teams of the developer and PMC, as well as any office-bearing authority from the developers, architects, consultants, or PMC’s offices, may upload photos and annotate issues observed at the site. If the person uploading the photos does not know the responsible contractor, they can simply upload the photos and annotate the issues directly. It is then the responsibility of the site supervision team of the developer / PMC to direct the matter to the concerned contractor, including any necessary instructions for the rectification method or process.

[0433] In another embodiment, the contractor uploads details of completed rectifications. The contractor's site supervision team must address the rectifications suggested by the site supervision teams of the developer / PMC and upload counter photos that address the points raised. The site supervision teams of the developer / PMC visit areas to verify the corrections, approve them, and issue a closure report along with their review photos. If the matter was raised by someone other than the site supervision team of the developer / PMC that person may also review the rectifications and raise further concerns if they are not satisfied. Thecontractor and the site supervision teams of the developer / PMC review the matter again until the issue is resolved to the satisfaction of the reporting individual.

[0434] In an embodiment, notifying unresolved QRNs and HSNs on ProChat is illustrated further. In an embodiment, unresolved QRNs and HSNs for any project will be highlighted in the 'site execution group' on prochat so that the site-supervision-teams of the developer / PMC / contractors do not miss to close them.

[0435] Reporting of resolved, and unresolved QRNs and HSNs is illustrated further. In an embodiment, when a contractor submits an invoice to the developer for completed work, a detailed report on the QRNs (quality rectification notices) is automatically attached to the invoice. This report includes total QRNs INFORMED to the contractor TILL DATE, total QRNs CLOSED by contractor TILL DATE, total QRNs INFORMED to the contractor from last to current invoice, and total QRNs CLOSED by contractor, from last to current invoice.

[0436] In another embodiment, similarly, when a contractor submits an invoice to the developer for completed work, a detailed report on the HSNs (housekeeping & safety notices) is automatically attached to the invoice. This report includes total HSNs INFORMED to the contractor TILL DATE, total HSNs CLOSED by contractor TILL DATE, total HSNs INFORMED to the contractor from last to current invoice, and total HSNs CLOSED by contractor, from last to current invoice.

[0437] All test reports management through the system 100 is illustrated further. The system 100 provides sharing various-test-reports etc. to concerned project team-members. Obtaining comments / reviews / replies / suggestions from them for making necessary corrections at user end. If there is any pending comment / review / reply, they are reminded by the system 100 unless they do so. The design of Test- Report module in the system 100 guides users about all generally / minimum required Tests in any Contractwork.

[0438] Further, list & status of all as-built Dwgs provided through the system 100 is illustrated further. System 100 provides tracking of list & status of all as-built Dwgs, of all the Dwg-controllers (i.e., Architects / Consultants) .

[0439] Figure 4 illustrates a block diagram of a second exemplary embodiment of labour connectivity to a contractors / subcontractors / other employers and subsequent engagement at project sites on behalf of an employer, in accordance with an embodiment of the present subject matter. The system 100 comprises a daily work reports (DWR) module. The module includes various features which are explained below in detail. The purpose of the daily work report (DWR) module is to streamline labour management by ensuring accurate tracking and assignment of labourers through real-time updates in the daily reports. It facilitates efficient connection and categorization of labourers, precise recording of work activities, and seamless updates for any changes in tasks or locations. The module also prevents duplication in labour counting and minimizes the need for manual intervention, thereby enhancing operational transparency and efficiency.

[0440] In an embodiment, steps for making a daily work report (DWR) is illustrated further. In an embodiment, the connecting labourers to the contractor and their attendance marking. The labourer may register on a b. support app and provide all required details before being connected to any organization. In one embodiment, the b. support may be referred to as a support application and used by the labourer. Any of the following contractor's supervisor, engineer, purchase / contract / billing engineer, project coordinator, accounts assistant, accounts head, key managers, partners, or founder may connect labourers to the organization by simply scanning the labourer's QR code (personal-ID). When a contractor assigns a labourer to their organization, they may categorize them as 'foreman / mukadam,' 'skilled labourer,' or 'unskilled labourer.'

[0441] In an embodiment, if the contractor's office later changes the category of any labourer, this update is reported in the DWR to ensure transparency for all parties. The labourer may remain connected with only one contractor at any time on ERP system 100. Labourers may be instructed to mark their attendance by taking a selfie at their 'work area of the day' so that their presence may be vaguely identified by the accounts team (or whoever is remotely maintaining track of them).

[0442] In another embodiment, assigning labourers to the activities, when a labourer marks their intime for the first time on a project, their presence is recorded in the DWR as 'today's untracked labourers.' The contractor's supervisor or engineer may then assign the labourer a type of work, activity type, and location. Once assigned, the photos taken by the labourer at the start ('photo @ work-start') and end ('photo @ workclosing') of their workday will be linked to the activity locations where they work that day.

[0443] In another embodiment, updating DWR, in case the labourer starts a new activity after completing the previous one (intraday process). Each day, the labourer is required to take only one 'photo @ work-start' and one 'photo @ work-closing' if their activity location does not change. However, if a labourer completes an activity and starts a new one at a different location on the same day, the labourer may first take the 'photo @ work-closing' for the completed activity before moving to the new location. At the new location, the labourer should take a 'photo @ work-start' and the 'photo @ work-closing' at the end of the new activity or the end of the day, whichever comes first.

[0444] In an embodiment, the labourer may take a 'photo @ work-start' and a 'photo @ work-closing' each time they begin and complete an activity during the day. In another embodiment, assigning labourers to activities. The next day, when the same labourer marks their in-time, they are automatically linked to the same work, activity, and location as the previous day. The contractor's supervisor or engineer does not need to reassign work, activities, or activity locations. However, they may modify the types of work, activities, or activity locations as needed for their day's planning.

[0445] In an embodiment, precise tracking of every 'present' labourer and their output is illustrated further. In an embodiment, if labourers who have already been assigned a type of work, activity, and activity locations mark their attendance but do not upload a 'photo @ work-start,' the contractor team may be alerted in the daily work report (DWR) to follow up. In another embodiment, if labourers upload the photo but no activities have been assigned to them by the contractor, the contractor team may be notified in the daily workreport (DWR) to assign the activities. This way, if labourers mark their presence for the day, the labourers may always be tracked on the system 100. Photos taken at the start and end of each workday by every labourer ensure that labourers daily output is accurately recorded and available for review by their organization's audit department. If the work area covered by the labourer is less than expected or planned, the labourer may be consulted to improve performance, or the organization may make alternative arrangements to meet targets.

[0446] In an embodiment, seamless labourer assigning and daily updates are illustrated further. In an embodiment, each person in the organization has a distinct list of labourers associated with them for connecting to project activities. Initially, the labourers they have connected to the organization are listed at the top, making it easier to assign these labourers to activities. Later, this list is automatically updated daily. On the next day, the person may find the names of the labourers they assigned activities to the previous day at the top of their list. This way, a person needs to work hard only the first time when assigning activities to the long list of labourers associated with the project.

[0447] In an embodiment, automated and real time labour strength tracking is illustrated further. In an embodiment, if the labourers are connected with the contracting organization and the organization is linked to the project. The present labour strength is automatically updated on DWR as soon as labourers mark their in-time or out-time, even if the contractor's team is not available for reporting. No human intervention is needed in system 100 to update the 'present' labour strength. The contractor's team is then needed only to assign the working labourers to the project activities. Duplication in counting is prevented because each labourer is uniquely identified through app registration and their connection with the contractor. When a labourer marks their in-time, their count is added to the 'present' labour strength. When they mark their out- time, their count is removed. Thus, the labour strength reported in the DWR system 100 is updated in realtime throughout the day.

[0448] In an embodiment, evaluating output changes of the contractors are illustrated further. In an embodiment, movement of all labourers is fully tracked in the system 100. If a drop in the contractor's output is observed, it is easier to determine whether the reason is a reduction in labour strength, a swap of skilled labourers with those from another project, or an unorganized allocation of activities to the labourers.

[0449] In an embodiment, reporting of improper labour management is illustrated further. In an embodiment, when a contractor submits an invoice to the developer for completed work, a detailed report on the labour strength is automatically attached to the invoice. This report includes total labour category changes made by contractor TILL DATE, total labour category changes made by contractor TILL DATE, total labour category changes made by contractor, from last to current invoice, total DWRs where labourers remained untracked TILL DATE, total DWRs where labourers remained un-tracked, from last to current invoice, total DWRs where labourers did not upload Photos TILL DATE, total DWRs where labourers did not upload photos, from last to current invoice, total average engineering / supervisory staff, foremen, skilled, and unskilled workers TILL DATE, total average engineering / supervisory staff, foremen,...

Claims

What is Claimed is:

1. A system (100) for an Enterprise Resource Planning (ERP), the system (100) comprising: a memory (104); and a processor (106) coupled to the memory (104), wherein the processor (106) is configured to: receive a request from each employee from a plurality of employees, wherein the request is associated with creation of an account for the employee on an Enterprise Resource Planning (ERP) platform; create the account for each employee based on a role of each employee in an enterprise; assign a task associated with a project to each employee from the plurality of employees upon creation of the account, wherein the task is assigned to each employee based on employee data, wherein the employee data comprises the role of the employee in the enterprise, a prior experience of the employee, a working domain of the employee, a team of the employee, and a current workload of the employee; allow an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee, wherein the enterprise data comprises files related to the task assigned, and confidential reports related to the enterprise and the task assigned; receive a primary report from each employee in each team from a plurality of teams, wherein the plurality of teams are working on the project in the enterprise, and wherein the primary report indicates update associated with the task assigned to each employee in each team; and generate a final report based on the primary report associated with the plurality of teams, wherein the final report is generated using an artificial intelligence technique, and wherein the final report is generated based on analysis of the primary report and training data associated with the project, wherein the training data comprises historical reports associated with the project, timelines assigned to each task associated with the project, and project planning information.

2. The system (100) as claimed in claim 1, wherein the final report comprises a number of employees working on the project, updates related to the project, data associated with purchase order of resources associated with the project, and resources or material used in the project till a defined date.

3. The system (100) as claimed in claim 1, further configured to assign a priority to each task associated to each employee from the plurality of employees.

4. The system (100) as claimed in claim 1, wherein a type of account created for each employee is based on the role of the employee in the enterprise.

5. The system (100) as claimed in claim 1, further configured to automatically send an alert to an employee upon analysis of the final report, wherein the alert is associated with the purchase order of the resources required for the project.

6. The system (100) as claimed in claim 1, further configured to accurately track an attendance for each employee based on in-time and out-time of each employee, and calculating a salary of each employee based on the attendance of each employee.

7. The system (100) as claimed in claim 1, further comprises sending a meeting invite to multiple employees from the plurality of employees using a chat platform associated with the ERP platform, wherein the multiple employees are allowed to share meeting agenda and meeting recordings through the chat platform.

8. The system (100) as claimed in claim 1, further comprises restricting an employee from accepting an offer letter from multiple organizations at a time based on tracking real-time information associated with the employee.

9. The system (100) as claimed in claim 1, further configured to audit supplied resources verses the resources used in the project based on analysis of the final report using an Optical Character Recognition (OCR) reader.

10. A method for an Enterprise Resource Planning (ERP), the method comprising: receiving, by a processor (106), a request from each employee from a plurality of employees, wherein the request is associated with creation of an account for the employee on an Enterprise Resource Planning (ERP) platform; creating, by the processor (106), the account for each employee based on a role of each employee in an enterprise; assigning, by the processor (106), a task associated with a project to each employee from the plurality of employees upon creation of the account, wherein the task is assigned to each employee based on employee data, wherein the employee data comprises the role of the employee in the enterprise, a prior experience of the employee, a working domain of the employee, a team of the employee, and a current workload of the employee; allowing, by the processor (106), an access for enterprise data to each employee from the plurality of employees based on the task assigned and the role of the employee, wherein the enterprise data comprises files related to the task assigned, and confidential reports related to the enterprise and the task assigned; receiving, by the processor (106), a primary report from each employee in each team from a plurality of teams, wherein the plurality of teams are working on the project in the enterprise, and wherein the primary report indicates update associated with the task assigned to each employee in each team; andgenerating, by the processor (106), a final report based on the primary report associated with the plurality of teams, wherein the final report is generated using an artificial intelligence technique, and wherein the final report is generated based on analysis of the primary report and training data associated with the project, wherein the training data comprises historical reports associated with the project, timelines assigned to each task associated with the project, and project planning information.

11. The method as claimed in claim 10, further comprises assigning a priority to each task associated to each employee from the plurality of employees.

12. The method as claimed in claim 10, further comprise automatically sending an alert to an employee upon analysis of the final report, wherein the alert is associated with the purchase order of the resources required for the project.

13. The method as claimed in claim 10, further comprises accurately tracking an attendance for each employee based on in-time and out-time of each employee, and calculating a salary of each employee based on the attendance of each employee.

14. The method as claimed in claim 10, further comprises sending a meeting invite to multiple employees from the plurality of employees using a chat platform associated with the ERP platform, wherein the multiple employees are allowed to share meeting agenda and meeting recordings through the chat platform.

Images