EP3398129A1 - Système et procédé de gestion de contrats de projet - Google Patents

Système et procédé de gestion de contrats de projet

Info

Publication number
EP3398129A1
EP3398129A1 EP15911658.1A EP15911658A EP3398129A1 EP 3398129 A1 EP3398129 A1 EP 3398129A1 EP 15911658 A EP15911658 A EP 15911658A EP 3398129 A1 EP3398129 A1 EP 3398129A1
Authority
EP
European Patent Office
Prior art keywords
contract
agent
project
item
amount
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP15911658.1A
Other languages
German (de)
English (en)
Inventor
Lincoln Keith EASTON
Mark William BALLINGER
Vito Benito BRUSCELLA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Progressclaim com Pty Ltd
Original Assignee
Progressclaim com Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Progressclaim com Pty Ltd filed Critical Progressclaim com Pty Ltd
Publication of EP3398129A1 publication Critical patent/EP3398129A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/105—Human resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/08—Construction

Definitions

  • the present invention relates generally to the management of contracts associated with projects, and relates particularly, though not exclusively, to systems and/or methods for managing contracts associated with construction, building or development projects. More particularly, the present invention relates to a system and/or method for managing contract payments between a first agent and at least one second agent involved in a construction project.
  • first agent is intended to refer to any suitable 'respondent' (i.e. an individual or organisation responsible for approving contract payments) party to, or otherwise appointed responsible for, one or more contract(s) associated with a construction project managed in accordance with the system and/or method of the present invention.
  • a first agent may include, but is not limited to, a: contract administrator; head or general contractor; developer; owner builder; owner agent; or, architect.
  • second agent is intended to refer to any suitable 'claimant' (i.e.
  • a second agent may include, but is not limited to, a: subcontractor; head or general contractor (if, for example, carrying out some work on a construction project themselves, or if working for a developer, etc.); or, consultant (such as, for example, an architect, engineer, project manager, etc.).
  • the expression "third agent” is intended to refer to any suitable individual or organisation with an interest or authority over a particular construction project managed in accordance with the system and/or method of the present invention.
  • a third agent may include, but is not limited to, a: project manager; architect; owner; owner agent; quality surveyor; assessor; superintendent; or, stakeholder (such as, for example, a financier, lawyer, government agency, insurer, etc.).
  • first, second and third agents along with combinations, substitutions, variations or alternatives thereof, applicable for use with the system and/or method of the present invention. Accordingly, the present invention should not be construed as limited to any one or more of the specific examples provided herein.
  • the definitions of the expressions hereinbefore described are only provided for assistance in understanding the nature of the invention, and more particularly, the preferred embodiments of the invention as hereinafter described. Such definitions, where provided, are merely examples of what the expressions refer to, and hence, are not intended to limit the scope of the invention in any way.
  • first agent may be a general contractor and a second agent may be a subcontractor.
  • the goods may be, for example, building materials, such as bricks, concrete, steel and tiles.
  • the services may, for example, include erecting walls, laying tiles and pouring concrete.
  • goods and/or services applicable to the construction industry.
  • a contract for a construction project is negotiated and agreed, then executed or otherwise formalised (e.g. verbally, electronically, etc.).
  • the contract governs the types of goods and/or services which are to be supplied, when such goods and/or services are to be supplied, the amount of goods and/or services which are to be supplied and the cost of those goods and/or services.
  • a subcontractor When, for example, a subcontractor supplies a good and/or service, the subcontractor will seek payment for the good and/or service supplied, or part payment for the good and/or service partially supplied (i.e. a progress claim, or payment application, etc.), from, for example, a general contractor. Typically, after having supplied a specified good and/or service, the subcontractor would notify the general contractor about the supplied good and/or service.
  • the terms of a construction contract will normally prescribe the process for making claims/applications for payment, including the rights and obligations of both parties (e.g. the general contractor and subcontractor, etc.), the information to be included and the expected timing for the submittal, assessment, approval and payment of a claim/application.
  • the general contractor After being notified of the supply of a good and/or service by the subcontractor (i.e. after having received a progress claim, payment application, etc.), the general contractor would then typically determine (sometimes using a third agent, such as a quantity surveyor or other kind of assessor, etc.) whether the good and/or service has been supplied, and whether the good and/or service has been supplied in the amount, condition or state, claimed by the subcontractor. If the general contractor is satisfied that the good and/or service has been supplied in the amount (state, condition, etc.) claimed by the subcontractor, payment in full would typically be authorised and made in accordance with any contractual conditions which may pertain to the payment (e.g. less retention or retainage funds, etc. - i.e.
  • the general contractor may only approve and authorise payment for a portion of the amount claimed by the subcontractor (less any retention/retainage funds, etc.), or may not approve any payment at all.
  • a claim for payment (e.g. a progress claim, payment application, etc.) in accordance with a construction contract is essentially a pre-cursor to the second agent (e.g. a subcontractor, etc.) submitting a tax invoice to the first agent (e.g. a general contractor, etc.).
  • the second agent e.g. a subcontractor, etc.
  • the first agent e.g. a general contractor, etc.
  • a general contractor, etc. will keep a spreadsheet, or other such accounting instrument, which records contractual items of goods and/or services to be supplied by, for example, one or more subcontractors.
  • a spreadsheet or other such accounting instrument, which records contractual items of goods and/or services to be supplied by, for example, one or more subcontractors.
  • the subcontractor(s), etc. may also keep a similar, but not linked spreadsheet which records details of the goods and/or services supplied to the general contractor to date, and the associated payment amounts received in connection therewith.
  • Such spreadsheets are typically used in the construction industry because: horizontal business accounting systems do not have the construction contract administration functionality needed to be able to provide a sufficient level of detail of the scope of work contracted to facilitate a reasonable level of assessment to be able to verify the claim/application for works actually completed; and, even where sophisticated vertical enterprise resource planning (ERP) systems are used by one or both contract parties that have the contract administration function necessary, the systems of each party are disconnected and therefore require manual spreadsheet reconciliation.
  • ERP enterprise resource planning
  • the first agent such as, for example, a general contractor
  • the first agent must respond to the payment claim/application, after which failure to respond makes the claim/application subject to adjudication; and, a set of criteria with which the respondent must comply in order to have been considered to have adequately met its obligations - this generally constitutes full payment or detailed rationale as to why a claim/application should not be paid in full.
  • the Australian Security of Payments legislation is essentially an extension of the common law contracts between the contractual participants. There are several common requirements typically imposed under these common law contracts in accordance with Australian Standards, such as AS4000-1997, AS4902-2000 and AS4903-2000. Examples include: the party performing the works to be paid for (i.e.
  • the claimant or second agent such as, for example, a subcontractor
  • the party paying for the works i.e. the respondent or first agent, such as, for example, a general contractor
  • insurance certificates of currency e.g. public liability, workers compensation, etc.
  • the claimant usually has to provide a statutory declaration covering the claim period stating that they have paid their workers and subcontractors (if any).
  • contract payment systems are not truly collaborative and do not allow for the first agent to assess the amount of a good and/or service which has been supplied by the second agent, so as to alter the amount paid to the second agent for the amount of the good and/or service actually supplied, or assessed as having been supplied. Further, such contract payment systems do not allow for a second agent to make progressive claims/applications for payment of a good and/or service which is supplied in instalments over a period of time. Other systems, such as document management systems, allow for some collaboration between first and second agents, however such systems only include records of project documentation, such as plans, contracts and other such documents. These known contract payment systems do not include any sort of truly collaborative payment systems or methods.
  • the present invention provides a system for managing contract payments between a first agent and at least one second agent for a project, said system being operable over a communications network, said system including: at least one network server connected to said communications network, said at least one network server acting as a central repository for storing and sharing contract information associated with said project; and, at least one user operable terminal associated with each of said first and second agents, said user operable terminals being configured to be selectively connected to said communications network for creating, editing, viewing and/or approving said contract information associated with said project stored at said at least one network server; wherein said contract information includes: at least one contract which includes at least one contract item entity associated with said project and said second agent, said contract item entity representing a contract item being for a good and/or service provided by said second agent to said first agent in accordance with said contract, each contract item entity including: at least one item identifier for identifying said contract item; an item value representing a first monetary value of said contract item as agreed between said first agent and said second
  • said second agent populates said completion amount, and said first agent populates said approval amount based on assessment and/or agreement of said completion amount.
  • one of said first or second agents populates said completion amount, and also populates said approval amount based on self- assessment and/or agreement of said completion amount.
  • said at least one visual indicator is/are a progress wheel and/or a progress bar. It is also preferred that said progress wheel and/or said progress bar utilise multiple colours or varying shades of a single colour to graphically represent consolidated project-to-date or current claim/approval contract information and/or contract item entity information.
  • said system further includes at least one external software provider or server connected to said communications network, said at least one external software provider or server being selectively integrable with said at least one network server so as to enable data sharing between said at least one network server and said at least one external software provider or server, and/or to enable various external software functions to be automated and/or controlled by way of said at least one network server.
  • said at least one external software provider or server is selected from the group consisting of: an ERP software provider; a project collaboration software provider; a procurement software provider; a cost planning or budgeting software provider; an accounting software provider; and/or, any other suitable software or data provider that may provide associated or desired software or data that may be accessed or otherwise used by said at least one network server.
  • At least one of said at least one user operable terminals is associated with at least one third agent who may also selectively connect to said communications network to at least edit and/or view said contract information associated with said project stored at said at least one network server.
  • said at least one network server or at least third party notification service provider sends multiple notifications to first, second and/or third agents during the various phases or said project, these notifications may be selected from the following group: invitations to first, second and/or third agents to collaborate on said project; reminders to populate said completion amount so as to submit a claim for payment; notifications of submittal of said claims for payment; reminders to populate said approval amount based on assessment and/or agreement of said completion amount so as to approve a claim; reminders of approval deadlines in accordance with legislation governing said contract; notifications of approval of claims; and/or, reminders to claim for final completion and associated retention/retainage release.
  • said contract information further includes at least one variation/change order item entity associated with said project and said second agent, said variation/change order item entity representing a variation/change order item being for a good and/or service associated with said contract, each variation/change order item entity including: at least one item identifier for identifying said variation/change order item; an item value representing a first monetary value of said variation/change order item; a completion amount for said variation/change order item nominated by said first or second agent; and, an approval amount representing a third monetary value approved by said first agent for payment to or by said second agent, wherein said at least one network server generates and provides at least one visual indicator for display on said user operable terminals, said at least one visual indicator being configured to graphically represent consolidated project-to-date variation/change order item entity information.
  • said first or second agent populates said completion amount of said at least one variation/change order item entity, and said first agent populates said approval amount of said at least one variation/change order item entity based on assessment and/or agreement of said completion amount.
  • one of said first or second agents populates said completion amount of said at least one variation/change order item entity, and also populates said approval amount, of said at least one variation/change order item entity, based on self-assessment and/or agreement of said completion amount.
  • any required supporting compliance documents must be submitted and/or verified before a claim for payment or approval of a claim can be made or processed.
  • said at least one network server generates claim and payment schedule documents as part of the process of submitting a claim for payment or for approving a claim, the claim and payment schedule documents complying with relevant statutory adjudication legislation.
  • the present invention provides a method for managing contract payments, via a communications network, between a first agent and at least one second agent for a project, said method including the steps of: providing a central repository for storing and sharing contract information associated with said project; providing said first and said at least one second agents with controlled access to said central repository and said contract information stored therein so that they may selectively create, edit, view and/or approve said contract information associated with said project; wherein said contract information includes: at least one contract which includes at least one contract item entity associated with said project and said second agent, said contract item entity representing a contract item being for a good and/or service provided by said second agent to said first agent in accordance with said contract, each contract item entity including: at least one item identifier for identifying said contract item; an item value representing a first monetary value of said contract item as agreed between said first agent and said second agent; a completion amount for said contract item which said second agent claims to have completed; a claim amount representing a second monetary value which said second agent
  • said second agent populates said completion amount, and said first agent populates said approval amount based on assessment and/or agreement of said completion amount.
  • one of said first or second agents populates said completion amount, and also populates said approval amount based on self- assessment and/or agreement of said completion amount.
  • said at least one visual indicator is/are a progress wheel and/or a progress bar. It is also preferred that said progress wheel and/or said progress bar utilise multiple colours or varying shades of a single colour to graphically represent consolidated project-to-date or current claim/approval contract information and/or contract item entity information.
  • said central repository is at least one network server and said method further includes the step of: enabling at least one external software provider or server to be selectively integrated with said at least one network server so as to enable data sharing between said at least one network server and said at least one external software provider or server, and/or to enable various external software functions to be automated and/or controlled by way of said at least one network server.
  • said at least one external software provider or server is selected from the group consisting of: an ERP software provider; a project collaboration software provider; a procurement software provider; a cost planning or budgeting software provider; an accounting software provider; and/or, any other suitable software or data provider that may provide associated or desired software or data that may be accessed or otherwise used by said at least one network server.
  • said method further includes the step of: providing at least one third agent with controlled access to said central repository and said contract information stored therein, so that said at least one third agent may at least selectively edit and/or view said contract information associated with said project.
  • said method further includes the step of: generating and sending multiple notifications to first, second and/or third agents during the various phases of said project; these notifications may be selected from the following group: invitations to first, second and/or third agents to collaborate on said project; reminders to populate said completion amount so as to submit a claim for payment; notifications of submittal of said claims for payment; reminders to populate said approval amount based on assessment and/or agreement of said completion amount so as to approve a claim; reminders of approval deadlines in accordance with legislation governing said contract; notifications of approval of claims; and/or, reminders to claim for final completion and associated retention/retainage release.
  • these notifications may be selected from the following group: invitations to first, second and/or third agents to collaborate on said project; reminders to populate said completion amount so as to submit a claim for payment; notifications of submittal of said claims for payment; reminders to populate said approval amount based on assessment and/or agreement of said completion amount so as to approve a claim; reminders of approval deadlines in accordance with legislation
  • said contract information further includes at least one variation/change order item entity associated with said project and said second agent, said variation/change order item entity representing a variation/change order item being for a good and/or service associated with said contract, each variation/change order item entity including: at least one item identifier for identifying said variation/change order item; an item value representing a first monetary value of said variation/change order item; a completion amount for said variation/change order item nominated by said first or second agent; and, an approval amount representing a third monetary value approved by said first agent for payment to or by said second agent, wherein said at least one network server generates and provides at least one visual indicator for display on said user operable terminals, said at least one visual indicator being configured to graphically represent consolidated project-to-date variation/change order item entity information.
  • said first or second agent populates said completion amount of said at least one variation/change order item entity, and said first agent populates said approval amount of said at least one variation/change order item entity, based on assessment and/or agreement of said completion amount.
  • one of said first or second agents populates said completion amount of said at least one variation/change order item entity, and also populates said approval amount, of said at least one variation/change order item entity, based on self-assessment and/or agreement of said completion amount.
  • any required supporting compliance documents must be submitted and/or verified before a claim for payment or approval of a claim can be made or processed.
  • said method further includes the step of: generating claim and payment schedule documents as part of the process of submitting a claim for payment or for approving a claim, the claim and payment schedule documents complying with relevant statutory adjudication legislation
  • the present invention provides a non-transitory computer readable medium storing a set of instructions that, when executed by a machine, cause the machine to execute a method for managing contract payments, via a communications network, between a first agent and at least one second agent for a project, said method including the steps of: providing a central repository for storing and sharing contract information associated with said project; proving said first and said at least one second agents with controlled access to said central repository and said contract information stored therein so that they may selectively create, edit, view and/or approve said contract information associated with said project; wherein said contract information includes: at least one contract which includes at least one contract item entity associated with said project and said second agent, said contract item entity representing a contract item being for a good and/or service provided by said second agent to said first agent in accordance with said contract, each contract item entity including: at least one item identifier for identifying said contract item; an item value representing a first monetary value of said contract item as agreed between said first agent and said second
  • FIG. 1 is a block diagram of a system for managing contracts associated with construction projects made in accordance with a preferred embodiment of the present invention
  • FIG. 2 is a flow diagram illustrating a preferred embodiment of a method for managing contracts associated with construction projects, the preferred method being suitable for use with the preferred system shown in Fig. 1 ;
  • Fig. 3 is an exemplary graphical user interface (GUI) screen-shot illustrating a preferred project dashboard or home page screen that may be presented to a user in accordance with the preferred method of Fig. 2, and preferred system of Fig. 1 ;
  • GUI graphical user interface
  • Fig. 4 is an exemplary GUI screen-shot illustrating a preferred detailed project page or screen that may be presented to a user upon the user selecting to view details of a specific project displayed within the preferred project dashboard or home page screen of Fig. 3;
  • Fig. 5 is an exemplary GUI screen-shot illustrating a preferred new contract creation page(s) or screen(s) that may be presented to a user upon the user selecting to add a new contract for a specific project displayed within the preferred detailed project page or screen of Fig. 4;
  • Fig. 6 is an exemplary GUI screen-shot illustrating a preferred detailed contract page or screen that may be presented to a user upon the user selecting to view details of a specific contract displayed within the preferred detailed project page or screen of Fig. 4;
  • Fig. 7 is a flow diagram illustrating, in detail, how claims or payment applications may preferably be made in accordance with the preferred method for managing contracts associated with construction projects shown in Fig. 2;
  • Fig. 8 is an exemplary GUI screen-shot illustrating a preferred page or screen that may be presented to a user upon the user selecting to make a new claim or payment application in accordance with a selected contract displayed within the preferred detailed contract page or screen of Fig. 6;
  • Fig. 9 is a flow diagram illustrating, in detail, how claims or payment applications may preferably be assessed and/or approved in accordance with the preferred method for managing contracts associated with construction projects shown in Fig. 2; and,
  • Fig. 10 is an exemplary GUI screen-shot illustrating a preferred page or screen that may be presented to a user upon the user selecting to assess and/or approve a claim or payment application in accordance with the preferred method for assessing and/or approving claims shown in Fig. 9.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD- ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), erasable programmable read-only memory (EPROMs), electrically erasable programmable read-only memory (EEPROMs), magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • ROMs read-only memories
  • RAMs random access memories
  • EPROMs erasable programmable read-only memory
  • EEPROMs electrically erasable programmable read-only memory
  • magnetic or optical cards or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • a machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer).
  • a machine-readable medium includes read only memory ("ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.
  • Fig. 1 there is shown a preferred system 1 0 for managing contracts 1 2n associated with one or more projects 38n (see, for example, Figs. 3 & 4) , such as, for example, construction projects 38n as hereinbefore described.
  • System 1 0 is configured for managing contract payments between a first agent 1 4 n (e.g. a general contractor, etc.) and at least one second agent 1 6n (e.g. a subcontractor, etc.) involved in a construction project 38n (hereinafter simply referred to as "project(s) 38n”) .
  • first agent 1 4 n e.g. a general contractor, etc.
  • second agent 1 6n e.g. a subcontractor, etc.
  • One or more first agent(s) 1 4 n and their appointed second agent(s) 1 6n may use system 1 0 to (preferably) collaboratively manage contract payments for any number of projects 38n.
  • system 1 0 may be used as a "standalone" system should only one of first agent 1 4 n or second agent 1 6n wish to use system 1 0 so as to "self-assess" one or more contracts 1 2 n for any given project 38n - as will be described in further detail below.
  • System 1 0 is suitable for use over a communications network(s) 1 8n, as shown. It should be understood however, that system 1 0 is not limited to that use only. For example, although not shown in Fig.
  • system 1 0 could be provided to first and/or second agents 1 4 n , 1 6n, by way of software and/or hardware installed locally on a single user terminal 28n (i.e. enabling both a first and second agent(s) 1 4 n , 1 6n, to collaborate using the same user terminal 28n, or enabling one of a first or second agent 1 4 n , 1 6n, to use system 1 0 in a stand-alone mode, without the need of communications network(s) 1 8n) .
  • System 1 0 includes at least one network server 20n, which includes at least one computing device 22 n , which may host and/or maintain a plurality of tools or applications 24 n (e.g. software and/or hardware applications, etc.) and databases/storage devices 26n, that provide a means of managing contract payments between a first agent 1 4 n and second agent(s) 1 6n involved in a project
  • Network server 20n is designed to receive/transmit data from/to at least one user terminal 28n, via communications network 1 8n.
  • user terminal(s) 28n refers to any suitable type of computing device or software application, etc., capable of transmitting, receiving and/or displaying data as described herein, including, but not limited to, a mobile or cellular phone, a smart phone, an App (e.g. iOS or Android) for a smart phone, a connected Internet of Things (“loT”) device; a Personal Digital Assistant (PDA), and/or any other suitable computing device, as for example a server, personal, desktop, tablet, or notebook computer.
  • PDA Personal Digital Assistant
  • Network server 20n is also designed to receive/transmit data from/to at least one external software provider or server 30n (hereinafter simply referred to as “external software provider(s) 30n”) , via communications network 1 8n.
  • external software provider 30n refers to any suitable external service/software provider that hosts and/or maintains software or data (such as, for example, in a cloud environment) for first or second agents 1 4 n , 1 6n, etc., and which software or data may be accessed or otherwise used by system 1 0 for the purpose of integration with system 1 0.
  • External software providers 30n may include, but are not limited to: ERP software providers, such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM (formerly, Sage Timberline OfficeTM), and, Construction Industry Solutions (COINSTM); project collaboration software providers (e.g. document management providers, etc.), such as, for example, AconexTM; procurement software providers; cost planning or budgeting software providers; and/or, accounting software providers, such as, for example, XeroTM, MYOBTM, QuickbooksTM, and, Sage OneTM; and/or, any other suitable software or data providers (whether cloud based, or otherwise) that may provide associated or desired software or data that may be accessed or otherwise used by system 1 0 for the purpose of integration with system 1 0.
  • ERP software providers such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM (formerly, Sage Timberline OfficeTM), and, Construction Industry Solutions (COINSTM)
  • project collaboration software providers e.g. document management providers, etc.
  • procurement software providers e.g
  • User terminals 28n are each configured to be operated by at least one user of system 1 0.
  • the term "user” refers generally to first and second agents 1 4 n , 1 6n, as hereinbefore described.
  • the term “user” may also refer to one or more third agent(s) 32 n which may also use or interact with system 1 0 as will be described in further detail below.
  • First, second 1 4 n , 1 6n, and possibly third agents 32 n are able to interact with system 1 0 by being in possession of, or stationed at, a user terminal(s) 28n.
  • first, second 1 4 n , 1 6n, and possibly third agents 32 n may utilise a user terminal(s) 28n in order to, for example: transmit, receive and/or display data associated with projects 38n and one or more contracts 1 2n associated therewith; submit or exchange information (e.g.
  • User terminals 28n may include various types of software and/or hardware (not shown) required for transmitting, receiving and/or displaying data to/from network server 20n and external software provider(s) 30n, via communications network 1 8n, in accordance with system 1 0 including, but not limited to: web-browser or other GUI 34 n application(s) or App(s) (not shown), which could simply be an operating system installed on user terminal 28n that is capable of actively transmitting, receiving and/or displaying data on a screen without the need of a web-browser GUI, etc.; monitor(s); GUI pointing devices; and/or, any other suitable data acquisition, transmission and/or display device(s) (not shown).
  • External software provider(s) 30n is/are configured to be accessed by first, second and/or third agents 1 4 n , 1 6n, 32 n , by way of their user terminal(s) 28n, for the purpose of them viewing or using the software or data hosted and/or maintained thereat.
  • External software provider(s) 30n is/are also configured to be accessed by network server 20n, preferably after having been authorised to do so by a first, second and/or third agent 1 4 n , 1 6n, 32 n , so that the software and/or data hosted and/or maintained by external software provider(s) 30n can be integrated with system 1 0.
  • system 1 0 may be configured to selectively and/or automatically import and/or exchange data between network server 20n and external software provider 30n so as to, for example, allow invoices to be generated automatically, or to allow accounts to be reconciled, etc.
  • system 1 0 may be configured to selectively and/or automatically import/export and/or exchange data between network server 20n and external software provider 30n so as to, for example, allow ERP project or contract information, reference numbers, etc., to be imported into system 1 0, or to allow system 1 0 records to be reconciled with ERP records, etc.
  • ERP software provider such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM
  • system 1 0 may be configured to selectively and/or automatically import/export and/or exchange data between network server 20n and external software provider 30n so as to, for example, allow ERP project or contract information, reference numbers, etc., to be imported into system 1 0, or to allow system 1 0 records to be reconciled with ERP records, etc.
  • Network server 20n is configured to communicate with user terminals 28n and external software provider(s) 30n via any suitable communications connection or network 1 8n (hereinafter referred to simply as a "network(s) 1 8n").
  • External software provider(s) 30n is/are configured to transmit and receive data to/from network server 20n and user terminals 28n, via network(s) 1 8n.
  • User terminals 28n are configured to transmit, receive and/or display data from/to network server 20n and external software provider(s) 30n, via network(s) 1 8n.
  • Each user terminal 28n and external software provider 30n may communicate with network server 20n (and each other, where applicable) via the same or a different network 1 8n.
  • Suitable networks 1 8n include, but are not limited to: a Local Area Network (LAN); a Personal Area Network (PAN), as for example an Intranet; a Wide Area Network (WAN), as for example the Internet; a Virtual Private Network (VPN); a Wireless Application Protocol (WAP) network, or any other suitable telecommunication network, such as, for example, a GSM, 3G or 4G network; Bluetooth network; and/or any suitable WiFi network (wireless network).
  • LAN Local Area Network
  • PAN Personal Area Network
  • WAN Wide Area Network
  • VPN Virtual Private Network
  • WAP Wireless Application Protocol
  • Network server 20n may include various types of hardware and/or software necessary for communicating with one another via network(s) 1 8n, and/or additional computers, hardware, software, such as, for example, routers, switches, access points and/or cellular towers, etc. (not shown), each of which would be deemed appropriate by persons skilled in the relevant art.
  • various levels or security including hardware and/or software, such as, for example, firewalls, tokens, two-step authentication (not shown), etc., may be used to prevent the unauthorized access to, for example, network server 20n and/or external software provider(s) 30n.
  • network server 20n and/or external software provider(s) 30n may utilise security (e.g. hardware and/or software - not shown) to validate access by user terminals 28n, or when exchanging information between respective servers 20n, 30n. It is also preferred that network server 20n performs validation functions to ensure the integrity of data transmitted between external software provider(s) 30n and/or user terminals 28n.
  • Communication and/or data transfer between network server 20n, external software provider(s) 30n and/or user terminals 28n may be achieved utilising any suitable communication, software architectural style, and/or data transfer protocol, such as, for example, FTP, Hypertext Transfer Protocol (HTTP), Representational State Transfer (REST); Simple Object Access Protocol (SOAP); Electronic Mail (hereinafter simply referred to as "e-mail"), postal or regular mail, Unstructured Supplementary Service Data (USSD), voice, Voice over IP (VoIP), Transfer Control Protocol / Internet Protocol (hereinafter simply referred to as "TCP/IP”), Short Message Service (hereinafter simply referred to as "SMS”), Multimedia Message Service (hereinafter simply referred to as "MMS”), any suitable Internet based message service, any combination of the preceding protocols and/or technologies, and/or any other suitable protocol or communication technology that allows delivery of data and/or communication/data transfer between network server 20n, external software provider(s) 30n and/or user terminals 28
  • any suitable data transfer or file format may be used in accordance with system 1 0, including (but not limited to): text; a delimited file format, such as, for example, a CSV (Comma-Separated Values) file format; a RESTful web services format; a JavaScript Object Notation (JSON) data transfer format; a PDF (Portable Document Format) format; and/or, an XML (Extensible Mark-Up Language) file format.
  • a delimited file format such as, for example, a CSV (Comma-Separated Values) file format
  • RESTful web services format such as, for example, a RESTful web services format
  • JSON JavaScript Object Notation
  • PDF Portable Document Format
  • XML Extensible Mark-Up Language
  • system 1 0 may enable users, e.g. first, second or third agents 1 4 n , 1 6n, 32 n , to, for example, prepare or approval claims or payment applications, etc., in an offline manner, such that when their user terminal(s) 28n is/are again selectively connected to network(s) 1 8n, those claims, payment applications, or approvals related thereto, may be received by network server 20n, of system 1 0, and processed thereafter according to the invention as herein described.
  • users e.g. first, second or third agents 1 4 n , 1 6n, 32 n , to, for example, prepare or approval claims or payment applications, etc., in an offline manner, such that when their user terminal(s) 28n is/are again selectively connected to network(s) 1 8n, those claims, payment applications, or approvals related thereto, may be received by network server 20n, of system 1 0, and processed thereafter according to the invention as herein described.
  • system 1 0 is designed to provide an improved process for managing contract payments between a first agent 1 4 n (e.g. a general contractor, etc.) and at least one second agent 1 6n (e.g. a subcontractor, etc.) involved in a project 38n.
  • System 1 0 is designed and configured to simplify and automate the submission and approval of contract payment claims (e.g. progress claims, payment applications, etc.) between contractual parties (e.g. first and second agents 1 4 n , 1 6n) .
  • System 1 0 facilitates the agreement between the parties 1 4 n , 1 6n, as to the amount payable for any particular claim/application in accordance with a contract 1 2 n , but preferably does not control the transmittal of any actual funds.
  • System 1 0 does not make assumptions about the business/service type of any first or second agent 1 4 n , 1 6n (e.g. financier, head contractor, consultant, subcontractor, etc.). Only their capacity to a specific contract 1 2 n (e.g. whether they are a first or second agent 1 4 n , 1 6n) is considered. Contracts 1 2 n may be managed collaboratively (i.e. where both first and second agents 1 4 n , 1 6n, are system 1 0 users), or in a stand-alone manner (i.e. where only one contractual party, e.g. first or second agent 1 4 n , 1 6n, need be a system 1 0 user).
  • first or second agent 1 4 n , 1 6n e.g. financier, head contractor, consultant, subcontractor, etc.
  • System 1 0 preferably provides a single central repository for all users 1 4 n , 1 6n and 32 n .
  • a single account may preferably be used per first or second agent 1 4 n , 1 6n, regardless of how many other second or first agents 1 6n, 1 4 n , that user is managing contracts 1 2 n with.
  • Each first, second or third agent 1 4 n , 1 6n, 32 n , that uses system 1 0 has the capacity to maintain its own information.
  • first or second agent 1 4 n , 1 6n has created a contract(s) 1 2 n in a stand-alone configuration then that first or second agent 1 4 n , 1 6n, will also have the ability to maintain its own copy of its counterparty's (e.g. second or first agent 1 6n, 1 4 n ) details/information.
  • System 1 0 preferably supports first and/or second agents 1 4 n , 1 6n, having multiple legal entities, so that a parent organisation operating multiple businesses or legal structures can have contracts 1 2 n related to each legal structure within the one system 1 0 account subscription. For example, where a first agent 1 4n operates under different legal entities in various States of Australia, that first agent 1 4n can use one system 1 0 account subscription to manage projects 38n and contracts 1 2 n for all related legal entities.
  • Account subscriptions for use with system 1 0 are preferably managed at an organisation level, wherein one or multiple users may be associated with each account.
  • user permissions and notification options for each account subscription (and each user appointed to an account) are preferably configured at an organisation level, and may also be configured at a project 38n level.
  • one or more contracts 1 2 n exist within the context of a project 38n.
  • Each first, second and/or third agent 1 4 n , 1 6n, 32 n that is a party to one or more contracts 1 2 n for a project 38n can see an aggregated set of values for its contracts 1 2 n on a per project 38n basis.
  • First and second agents 1 4n, 1 6n preferably only ever see contracts 1 2 n to which they are a party thereto.
  • Third agents 32 n are preferably only ever able to see contracts 1 2 n , and associated project 38n information, for projects 38n to which they have been appointed as an authorised third-party agent by at least one of a first and/or second agent 1 4 n , 1 6n.
  • access to contracts 1 2 n may also be preferably further restricted based on user permissions at individual/organisation and/or project 38n level.
  • access to contract payment claim/application information regarding a specific contract 1 2 n may be restricted based upon the status of a claim/application and/or the first or second agents 1 4 n , 1 6n capacity under the contract 1 2 n .
  • a first agent 1 4 n preferably cannot see a contract payment claim/application until it is submitted by a second agent 1 6n, and likewise, the second agent 1 6n preferably cannot see approval values applied to a contract payment claim/application until the approval process is finalised by the first agent 14 n .
  • Contract payment claims/applications for any given contract 12 n may be made at the absolute discretion of second agent 16n, subject to (preferably) having only one pending claim/application per contract 12 n at any time.
  • Each contract payment claim or payment application made in accordance with system 10 constitutes a project-to-date reconciliation of all claims or payment applications made under a specific contract 12 n to that point in time (i.e. the date and time upon which the claim/application is made/approved, or any given date in between claims/applications or approvals).
  • each contract, contract payment claim or payment application clearly and cleverly shows or displays, using progress bars 120b, 122e, progress wheels 1 12b or the likes (e.g.
  • the completion status of all consolidated contracts 12 n associated with the project 38n may be clearly and cleverly displayed by way of, for example, a number representing a completion percentage amount and/or a progress wheel 39n (see, Fig. 4), progress bar, or the like (e.g. other form of colour coded visual indicator, etc.).
  • System 1 0 preferably stores (for example, in databases/storage devices 26n, etc., of network server 20n) a full history of all payment claims/applications relevant to each contract 1 2 n .
  • a full audit trail of claimed versus approved values for contract payment claims/applications as at a point in time, along with all necessary supporting information/documentation is also preferably captured (i.e. attached to, or associated with, contracts 1 2 n , payment claims/applications, approved claims/applications, etc.) and stored (for example, in databases/storage devices 26n, etc., of network server 20n) by system 1 0.
  • Supporting information/documentation can preferably be attached to a first or second agent's 1 4 n , 1 6n, core system data at the following levels: contract 1 2 n ; contract payment claim (e.g. progress claim or payment application, etc.); contract 1 2n line item; and/or, claim line item.
  • system 1 0 is also able to assist all contractual parties (e.g. first and second agent(s) 1 4n, 1 6n) to comply with the relevant statutory adjudication legislation or rules governing a contract 1 2 n , such as, for example the Australian Security of Payments legislation, etc.
  • contractual parties e.g. first and second agent(s) 1 4n, 1 6n
  • the relevant statutory adjudication legislation or rules governing a contract 1 2 n such as, for example the Australian Security of Payments legislation, etc.
  • system 1 0 Given that both network server 20n and user terminals 28n, of system 1 0, are configured to interact with external software provider(s) 30n, system 1 0 also streamlines and improves other processes associated with the management of projects 38n and contracts 1 2 n associated therewith.
  • an ERP software provider such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM
  • compliance with, for example, a first agent's 1 4 n ERP software is very simply and effectively achieved.
  • system 1 0 integration with, for example, cloud based accounting software providers (such as, for example, XeroTM, MYOBTM, QuickbooksTM, and, Sage OneTM), enables system 1 0 to streamline and simplify accounting processes, such as, for example, invoicing and account reconciliations, for first and/or second agents 1 4 n , 1 6n, etc.
  • cloud based accounting software providers such as, for example, XeroTM, MYOBTM, QuickbooksTM, and, Sage OneTM
  • the present invention should not be constructed as limited to any one or more of the integration examples provided herein, but instead should be construed broadly so as to include within its scope any form of integration with external software and/or data that would be deemed appropriate and/or applicable by a skilled person.
  • System 1 0 preferably also generates and sends multiple notifications during the various phases of a project 38n. Such notifications may be generated and sent by network server 20n of system 1 0, or may be generated and sent by an external or third party server or provider 33n, such as, for example, MandrillTM or any other suitable third party notification server/provider 33n.
  • an external or third party server or provider 33n such as, for example, MandrillTM or any other suitable third party notification server/provider 33n.
  • notifications are generated and sent in accordance with system 1 0 : invitations (to first, second and/or third agents 1 4 n , 1 6n, 32 n ) to collaborate using system 1 0 ; reminders (to second agents 1 6n) to submit contract payment claims/applications on a given day of the month (on a per project 38n basis); notifications (to first agents 1 4 n ) of contract payment claim/application submissions, with system-generated documents (and any documents supplied by second agents 1 6n) attached thereto; reminders (to first agents 1 4 n ) that a contract payment claim/application is close to the approval deadline under the relevant legislation, if any, governing the contract; reminders (to approvers, e.g.
  • third agents 32n in a multi-stage approval project 38n) that one or more contract payment claims/applications are up to their approval stage; notifications (to second agents 1 6n, etc.) of contract payment claim/application approvals with system-generated documents (and any documents supplied by first agents 1 4 n , etc.) attached thereto; and/or, reminders (to second agents 1 6n) to claim for final completion and associated retention/retainage release.
  • notifications to second agents 1 6n, etc.
  • system-generated documents and any documents supplied by first agents 1 4 n , etc.
  • reminders to second agents 1 6n
  • the present invention should not be constructed as limited to any one or more of the notification examples provided herein, but instead should be construed broadly so as to include within its scope any form of notification that would be deemed appropriate and/or applicable by a skilled person.
  • the one or more computing device(s) 22 n of network server 20n, of system 10 may host and/or maintain a plurality of applications 24 n (such as software and/or hardware modules or engines) and databases/storage devices 26n that enable multiple aspects of system 10 to be provided over network(s) 1 8n.
  • These applications 24 n and databases/storage devices 26n may include, but are not limited to: one or more databases/storage devices 26n for storing: user (e.g.
  • first, second and third agent 14 n , 1 6n, 32 n information; project 38n information; and/or, contract 12 n information (such as, for example, full history or audit trail of payment claims/approvals made in accordance with a contract 12 n , along with any/all supporting information/documentation applicable to each contract 12 n and/or claim/approval); one or more module(s) or application(s) 24 n for communicating with user terminals 28n for the purpose of receiving, processing and/or capturing: user (e.g.
  • first, second and third agent 14 n , 1 6n, 32n) information (including user permissions and/or access information, multiple entity information, etc.); project 38n information; and/or, contract 12 n information/documentation (including any supporting information/documentation, retention/retainage information, etc.); one or more module(s) or application(s) 24 n for communicating with user terminals 28n for the purpose of receiving, processing and/or capturing contract payment claim/application information (including any variation/change order information, and any supporting information/documentation applicable to each claim/application); one or more module(s) or application(s) 24 n for communicating with user terminals 28n for the purpose of receiving, processing and/or capturing contract payment claim/application approval or disapproval information (including any supporting information/documentation applicable to the approval or otherwise of each claim/application); one or more module(s) or application(s) 24 n for calculating and determining retention/retainage amounts applicable to each contract 12 n and payment claim/application and approval made against each contract 12
  • module(s) or application(s) 24 n for communicating with user terminals 28n and external software provider(s) 30n for the purpose of integrating system 10 with the external software and/or data hosted and/or maintained by external software provider(s) 30 n ; one or more module(s) or application(s) 24 n (which could, for example, be provided by a third party notification server or provider 33n, e.g. MandrillTM, etc.) for generating and sending notifications to users (e.g.
  • first, second and/or third agent 14 n , 1 6n, 32 n via their user terminals 28 n ; and/or, one or module(s) or application(s) 24 n (which could, for example, be provided by a third party payment gateway server or provider 33n, such as, for example, StripeTM, PayPalTM, etc.) for processing user (e.g. first, second and/or third agent 14 n , 1 6n, 32 n ) account subscription payments for system 10.
  • a third party payment gateway server or provider 33n such as, for example, StripeTM, PayPalTM, etc.
  • any one or more of database(s)/storage device(s) 26n and/or modules/applications/engines 24 n could be hosted or provided by a third party server or provider 33n (such as, for example: MandrillTM, or other notification service provider 33n, etc., in the case of the one or more module(s) or application(s) 24 n for generating and sending notifications to users 1 4n, 1 6n, 32 n ; and/or, StripeTM, or other payment gateway provider 33n, etc., in the case of the one or more modules(s) or application(s) 24 n for processing user, 1 4n, 1 6n, 32n, account subscription payments on behalf of system 10).
  • a third party server or provider 33n such as, for example: MandrillTM, or other notification service provider 33n, etc., in the case of the one or more module(s) or application(s) 24 n for generating and sending notifications to users 1 4n, 1 6n, 32 n ; and/or, Strip
  • network server 20n, of system 1 0, of the present invention should not be construed as having to provide all of database(s)/storage device(s)/application(s)/module(s) 26n/24 n in order to perform the teachings of the invention.
  • network server 20n need not provide all of application(s)/engine(s)/module(s) 24 n , or database(s)/storage device(s) 26n, of system 1 0, in order to perform the teachings of the invention, and hence, that any one or more of the database(s)/storage device(s)/application(s)/module(s) 26n/24 n , may be provided by an external third party server(s) or provider(s) 33n, in Fig.
  • network server 20n is depicted as being connected to, or in communication with, third party server(s)/provider(s) 33n by way arrows illustrated in dashed-lines and network(s) 1 8n (which of course may be the same or a different network(s) 1 8n (e.g. a secure network(s) 1 8n) to that of all other network(s) 1 8n depicted in Fig. 1 ) .
  • third party server(s)/provider(s) 33n by way arrows illustrated in dashed-lines and network(s) 1 8n (which of course may be the same or a different network(s) 1 8n (e.g. a secure network(s) 1 8n) to that of all other network(s) 1 8n depicted in Fig. 1 ) .
  • network server 20n and third party server(s)/provider(s) 33n, via network(s) 1 8n, are illustrated in dashed-lines so as to demonstrate that the use of one or more third party server(s)/provider(s) 33n in accordance with system 1 0 is optional, i.e. if desired, network server 20n could readily provide all aspects of system 1 0.
  • GUI screen-shots 34 n e.g. web-browser GUI screen-shots, or other similar GUI screen-shots, as shown
  • Figs. 3, 4, 5, 6, 8 & 1 0 which illustrate preferred constructions of various screens or pages 34 n that may be presented to first, second and/or third agents 1 4 n , 1 6n, 32 n , in accordance with system 1 0 as herein described.
  • exemplary web-browser GUI screen-shots 34 n are shown and described with reference to Figs.
  • GUI 34 n any suitable GUI 34 n may be used depending on the application of system 1 0 (e.g. collaborative versus stand-alone, etc.), and the way in which GUI(s) 34 n of system 1 0 are accessible via, for example, network(s) 1 8n, to first, second and/or third agents 1 4 n , 1 6n, 32 n , via user terminals 28n.
  • the content of GUI screen-shots 34 n shown in Figs. 3, 4, 5, 6, 8 & 10 only represents an example of the type of information that may be displayed to users (e.g. first, second and/or third agents 14 n , 1 6n, 32 n ) of system 10. Accordingly, the present invention should not be construed as being limited to any or more of the specific GUI screen-shot 34 n examples provided.
  • Preferred GUI screen-shots 34 n of Figs. 3, 4, 5, 6, 8 & 10 will be described in conjunction with the flow diagrams of Figs. 2, 7 & 9, which illustrate preferred methods 200, 236, 238, for managing contract payments between a first agent 14 n (e.g. a general contractor, etc.) and at least one second agent 1 6n (e.g. a subcontractor, etc.) involved in a project 38n.
  • Preferred methods 200, 236, 238, are suitable for use with system 10 (shown in Fig. 1 ) of the present invention. It should be understood, however, that preferred methods 200, 236, 238, described with reference to the flow diagrams of Figs.
  • FIG. 2 A flow diagram illustrating a preferred method 200 for managing contract payments associated with projects 38n is shown in Fig. 2.
  • the preferred process of managing contract payments associated with projects 38n in accordance with method 200 commences at one of steps 202a, 202b, or 202c, depending on whether or not a user, e.g.
  • a first, second or third agent 14 n , 1 6n, 32 n already has an existing user account and login details for accessing system 10 (as represented by step 202c), or whether or not the user 14 n , 16n, 32n, elects to sign up and create their own account without being prompted (as represented by step 202a), or is invited or otherwise prompted to sign up and create an account by another user 14 n , 16n, 32 n , so as to be able to collaborate on a project 38n with that other user(s), 14 n , 1 6n, 32 n (as represented by step 202b).
  • step 204 When a user 14 n , 16n, 32 n , wishes, or is prompted, to sign up to create an account by way of either steps 202a or 202b, method 200 continues at step 204, whereat the user 1 4 n , 1 6n, 32 n , is provided with a GUI screen(s) (not shown), accessible via their user terminal(s) 28n, for inputting the required information necessary to create a new account. Should the user (e.g. a first or second agent 1 4n, 1 6n) have been invited to sign up and create an account (as represented by step 202b) by another (existing) user (e.g.
  • a second or first agent 1 6n, 1 4 n of system 10
  • some of the required information such as, for example, the individual/entity name, address, e-mail address, and/or telephone number, etc.
  • the inviting party e.g. second or first agent 1 6n, 1 4 n .
  • Information required for creating a new account may include, but is not limited to: one or more valid e-mail address(es); individual/organisation details (which could include multiple individuals/entities) including name(s), address(es), company registration details, telephone number(s), etc.; logos (e.g. company logos, etc.) or profile pictures; permissions for each individual/entity, if applicable; and/or, payment details (e.g. credit card, direct debit, etc.) necessary for charges associated with the user 14 n , 1 6n, 32 n , account, if applicable.
  • individual/organisation details which could include multiple individuals/entities
  • logos e.g. company logos, etc.
  • payment details e.g. credit card, direct debit, etc.
  • system 10 may provide automated tools (not shown) for capturing certain user 14 n , 1 6n, 32n, information, such as, for example, an automated tool for looking up and capturing an address(es) in the correct format required for a certain jurisdiction, or an automated tool for looking up and capturing company registration details (e.g. an ABN (Australian Business Number) or ACN (Australian Company Number) look up facility for Australian company registration details).
  • automated tools or facilities not shown which could be used for automating the capture of user 14 n , 1 6n, 32 n information in accordance with system 10 of the present invention.
  • step 206 After having signed up and created a new account at step 204, or after having logged into system 10 by way of an existing user 1 4 n , 1 6n, 32 n , account (as represented by step 202c), method 200 continues at step 206, whereat the user 1 4n, 1 6n, 32n, is presented with, or arrives at, their GUI "project dashboard” screen 34n (hereinafter simply referred to as “dashboard screen 34 n ”) , by way of their user terminal(s) 28n.
  • the dashboard screen 34 n is also preferably the "home page" of the preferred GUI 34 n interface(s)/screen(s)/page(s) provided by system 10.
  • An exemplary GUI screen-shot 34 n of a preferred dashboard screen 34 n is shown in Fig. 3.
  • dashboard screen 34n which in this example is that of a first agent 14 n or "builder" (as is indicated by the exemplary generic name (which would normally simply be the user's 14 n name, initials, alias, etc., and not a reference to the user's 14 n , etc., role as part of a project 38n) applied to the button or region 36 toward the top right hand corner of screen 34n - the button/region 36 revealing a drop-down menu or the like (not shown) when selected or hovered over using a GUI pointing device, pen, finger, etc.
  • a first agent 14 n or "builder" as is indicated by the exemplary generic name (which would normally simply be the user's 14 n name, initials, alias, etc., and not a reference to the user's 14 n , etc., role as part of a project 38n) applied to the button or region 36 toward the top right hand corner of screen 34n - the button/region 36 revealing a drop-down
  • dashboard screen 34 n may simply be presented to first user 1 4n as a blank screen (not shown) until such time that one or more new project(s) 38n are created (preferred processes for creating new projects 38n will be described in detail below).
  • dashboard screen 34 n may be configured to display that single project 38n in a more detailed, or expanded manner/view, such that, for example, brief details of any/all contracts 1 2 n associated with that project 38n, and any other desired project 38n related information, is/are visible by default upon logging into system 1 0 and arriving at dashboard screen 34 n (see, for example, the exemplary single project 38n expanded GUI screen-shot 34 n shown in Fig. 4 - which will be described in further detail below).
  • Each project 38n displayed on dashboard screen 34 n in its concise or collapsed format as shown in Fig. 3, preferably provides summary information concerning the status of all contracts 1 2 n associated with that particular project 38n.
  • This summary information may include, but is not limited to: consolidated contract 1 2n completion percentage information, which is preferably presented as both a number and by way of a progress wheel 39n or the like (e.g. other form of visual indicator, etc.), which may preferably, and cleverly, visually display the completion status of all consolidated contracts 1 2 n for a project 38n, using, for example, multiple colours, e.g.
  • the consolidated financial information and/or progress wheels 39n or the like (e.g. other form of visual indicator, etc.) that are displayed within dashboard screen 34 n , of Fig. 3, are generated by financial data display engine 24 n of network server 20n (or a third party service provider 33n, if desired) of system 1 0.
  • financial data display engine 24 n Upon a user 1 4 n , 1 6n, 32 n , requesting or otherwise being provided with dashboard screen 34 n of Fig. 3, financial data display engine 24 n preferably retrieves, calculates, analyses and/or manipulates all necessary financial data, and then populates the relevant fields or regions for each project 38n (displayed in its concise or collapsed form) provided within dashboard screen 34 n .
  • the consolidated financial data for display within dashboard screen 34n may have been prepared in advance by financial data display engine 24 n , i.e. upon a last transaction (e.g. a project 38n or contract 1 2 n being created, a claim/payment application being made or approved, etc.) being completed, or may be prepared in (substantially) real-time upon, for example, a request being received by system 1 0 to display a dashboard screen 34 n .
  • a last transaction e.g. a project 38n or contract 1 2 n being created, a claim/payment application being made or approved, etc.
  • dashboard screen 34 n of Fig. 3, and/or any of the other preferred GUI screens 34 n shown in Figs. 4, 5, 6, 8 & 1 0, may be displayed in a condensed format suitable for display within/on small GUI facilities 34 n , such as, for example, for display on mobile devices or the like (i.e. user terminals 28n, such as, for example, smart phones or tablets).
  • system 1 0 uses a responsive web design (RWD) programming approach such that any content displayed on any of GUI screens 34 n of system 1 0 of the present invention, is automatically condensed when, for example, the GUI screen 34 n is minimised length wise, or otherwise resized, so as to avoid project 38n, contract 1 2 n , etc., information being chopped off, or otherwise not viewable, when GUI screen 34 n is minimised length wise, resized, etc.
  • RWD web design
  • GUI screen 34 n may be readily condensed for display on, for example, a mobile device 28n, or may be condensed upon a GUI screen 34 n being reduced in size, etc. Accordingly, a detailed discussion of how content displayed within GUI screens 34 n may be condensed in accordance with system 1 0 of the present invention need not be provided herein.
  • each project 38n displayed on dashboard screen 34 n may preferably be expanded (to, for example, the exemplary single project 38n expanded GUI screen-shot 34 n shown in Fig. 4) by simply selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) any region of the selected project 38n shown on dashboard screen 34 n .
  • first user 1 4 n may select or hover over (e.g. using a GUI pointing device, pen, finger, etc.) the button or region 40n marked with an ">", toward the right hand side of each project 38n shown on dashboard screen 34 n .
  • Yet a further preferred option for expanding the concise or collapsed view of a particular project 38n shown on dashboard screen 34 n may be to select or hover over (e.g. using a GUI pointing device, pen, finger, etc.) the button or region 42 n marked with the three vertically aligned dots, toward the right hand side of each project 38n shown on dashboard screen 34 n , which may then reveal (by way of, for example, a drop-down menu, pop-up screen or the like - not shown) one or more further buttons or regions (not shown), including a button or region, e.g. a "show project" or "view project” button or region, that may then be selected or hovered over (e.g.
  • buttons or regions 42 n may also reveal a button or region, e.g. an "Edit Project” button or region, which may be selected or hovered over so as to enable a first agent 1 4 n , etc., to edit the particular project 38n if or as desired (examples of how a project 38n may be edited in accordance with system 1 0 will be provided below).
  • a button or region e.g. an "Edit Project” button or region, which may be selected or hovered over so as to enable a first agent 1 4 n , etc., to edit the particular project 38n if or as desired (examples of how a project 38n may be edited in accordance with system 1 0 will be provided below).
  • Fig. 3 may be changed to an expanded view (to, such as, the expanded view shown in Fig. 4) in accordance with system 1 0 of the present invention. Accordingly, the present invention should not be construed as limited to the specific examples provided.
  • first user 1 4 n may return to their dashboard screen 34 n (Fig. 3) at any time by (preferably) either selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) the home button or region 44, or the system 1 0 branded button or region 46, or by using an inbuilt GUI "back" button should one be available.
  • a further preferred option for returning to one's dashboard screen 34 n could be to select or hover over (e.g.
  • the root or first directory e.g. "My 2 Projects", as shown
  • My 2 Projects the root or first directory of the navigation element 48 shown, in Fig. 3, toward the top left hand side of dashboard screen 34 n .
  • the present invention should not be construed as limited to the specific examples provided.
  • buttons or regions may include, but are not limited to: a button/region for accessing one's account settings, e.g. a "My Account” button or region; a button/region for accessing details about client (e.g. developer, owner, etc.) and/or supplier (e.g.
  • subcontractor, engineer, etc. counterparty details, e.g. a "Counterparties" button or region (which may, for example, enable a user 1 4 n , 1 6n, to quickly and conveniently check and/or view details concerning how many clients (i.e. respondents) and/or suppliers (e.g. claimants) they are associated with, etc.); a button/region for accessing demonstrational videos, FAQs and/or help or online chat/forum facilities, e.g. a "Getting Started” or "Help", etc., button or region; and/or, a button/region for logging out of system 1 0, e.g. a "Logout” button or region.
  • a "Counterparties” button or region which may, for example, enable a user 1 4 n , 1 6n, to quickly and conveniently check and/or view details concerning how many clients (i.e. respondents) and/or suppliers (e.g. claimants) they are associated with, etc.
  • dashboard screen 34 n may also preferably include an additional "My Account” button or region 50, that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to access one or more screen(s) (not shown) that list the user's 1 4 n , 1 6n, 32 n , account details.
  • a user 1 4 n , 1 6n, 32 n may add, edit or update information or settings related to their account (which may vary depending on the user's 1 4 n , 1 6n, 32 n , role within system 1 0, e.g. a first agent 1 4 n , such as a general contractor 1 4 n , may be presented with more account related settings (e.g. compliance related settings, etc. - discussed below) than that of say a second agent 1 6n, such as a subcontractor 1 6n, who may have a reduced set of settings if, for example, he/she/they only ever acts as a second agent 1 6n) if and when required or desired in accordance with system 1 0.
  • a first agent 1 4 n such as a general contractor 1 4 n
  • a second agent 1 6n such as a subcontractor 1 6n
  • Information or settings that a user, e.g. 1 4n, 1 6n, may enter, edit and/or update, may include, but is not limited to: their profile details; organisation details (which may include preferences for system 1 0 generated forms and/or invoices - discussed in further detail below); user details (e.g. authorised user settings or information, preferably including means to alter access permissions for each user, if desired); their system 1 0 subscription plan and/or usage details (e.g. type of subscription, expiry dates, etc.); their payment details (e.g. credit card, direct debit details, payment history, etc.); their legal entity details (including a facility and settings for adding and editing legal entity details, etc.); compliance details and settings (e.g.
  • the "addon" details or page(s) may preferably provide user 1 4 n , 1 6n, 32 n , with a means for integrating their system 1 0 subscription/account with, for example, external software provider(s) 30n, such as, for example, cloud based accounting service provider(s) 30n (e.g. XeroTM, MYOBTM, QuickbooksTM, and, Sage OneTM, etc.), or ERP software provider(s) 30n (e.g. ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.), as will be described in further detail below.
  • cloud based accounting service provider(s) 30n e.g. XeroTM, MYOBTM, QuickbooksTM, and, Sage OneTM, etc.
  • ERP software provider(s) 30n e.g. ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.
  • Dashboard screen 34 n may also preferably include a button or region 52 (which may be, or include, a logo or profile picture of a user 1 4 n , 1 6n, 32 n , uploaded as part of the process of signing up for a new account as was described earlier with reference to step 204, of preferred method 200, shown in Fig. 2), which, when selected or hovered over (using a GUI pointing device, pen, finger, etc.) may reveal brief details of the user's 1 4 n , 1 6n, 32 n , system 1 0 subscription account details.
  • a button or region 52 which may be, or include, a logo or profile picture of a user 1 4 n , 1 6n, 32 n , uploaded as part of the process of signing up for a new account as was described earlier with reference to step 204, of preferred method 200, shown in Fig. 2
  • a button or region 52 which, when selected or hovered over (using a GUI pointing device, pen, finger, etc.) may reveal
  • buttons or regions may include, but are not limited to: a button or region 54 that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to access one or more screen(s) (not shown) for generating reports related to project 38 n ; a button or region 56 that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to access a facility for searching for project 38n and contracts 1 2 n should a particular user 1 4n, 1 6n, 32 n , have quite a number of active projects 38n and/or contracts 1 2 n and wish to quickly find one of those projects 38n and/or contracts 1 2 n without having to click though all of their projects 38n, etc.; and/or, a button or region 58 that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to add a new project 38n, e.g.
  • FIG. 4 there is shown an exemplary GUI screen 34 n which illustrates a preferred detailed (single expanded) project 38n page (hereinafter simply referred to as "project screen 34 n ”) that may be presented to a user, e.g. first agent 1 4 n , etc., upon that user 1 4 n , etc., selecting to view details of a specific project 38n displayed within dashboard screen 34 n of Fig. 3.
  • preferred project screen 34 n preferably displays the same project 38n summary information (as that described with reference to Fig. 3) concerning the consolidated status of all contracts 1 2 n associated with the particular project 38n being viewed.
  • project screen 34 n preferably also displays a concise view of all contracts 1 2 n associated with the particular project 38n being viewed.
  • an "Add Contract” or “New Contract” button or region is preferably presented to first user 1 4 n , etc., in a predetermined convenient location on project screen 34 n (such as, for example, centred on screen 34 n in or around the region where a first contract 1 2 n may otherwise be displayed, should one or more contracts 1 2 n already exist for that project 38n) so that the user, e.g.
  • first agent 1 4 n may add one or more contracts 1 2 n for that project 38n as desired.
  • another way to add one or more new contract(s) 1 2 n for the project 38n may include selecting or hovering over the button or region 42 n , which may then reveal a button or region, e.g. an "New Contract" button or region, which may then be selected or hovered over so as to enable the user, e.g. first agent 1 4 n , etc., to add one or more new contracts 1 2 n for that project 38n as desired.
  • An example of a preferred process for adding a new contract 1 2 n , and later editing same if desired, will be described in further detail below with reference to preferred method 200 of Fig. 2, and the exemplary create new contract GUI screen-shot 34 n of Fig. 5.
  • each contract 1 2 n displayed on project screen 34 n preferably provides summary information concerning the status of that particular contract 1 2 n .
  • This summary information may include, but is not limited to: the project 38n or contract 1 2 n name, reference, or similar identifying information; the counterparty name (e.g. claimant name or second agent 1 6n, or one of its legal entities, etc.); an indication (not shown - but which may be presented as, e.g. colour coded text, a colour coded box including text, or a colour coded icon, etc.) as to whether or not: a contract 1 2 n , is in draft form (e.g.
  • a claim or payment application is in draft form (e.g. is a "Draft Claim”); and/or, there are any pending claims awaiting approval or to assess/approve for that contract (e.g. "Pending Claim(s)", etc.); the consolidated amount approved for the contract 1 2 n to date; the total amount of works approved or to be supplied in accordance with the contract 1 2 n ; consolidated contract 1 2 n completion percentage information, which may be presented as a number, as shown, but which could also, or additionally, be presented by way of a progress wheel 39n (not shown) or the like (e.g.
  • the consolidated financial information that is displayed within project screen 34 n , of Fig. 4 is generated by financial data display engine 24 n of network server 20n (or a third party service provider 33n, if desired) of system 1 0.
  • financial data display engine 24 n preferably retrieves, calculates, analyses and/or manipulates all necessary financial data, and then populates the relevant fields or regions for the selected project 38n and each contract 1 2 n (displayed in its concise or collapsed form) provided within project screen 34 n .
  • the consolidated financial data for display within project screen 34 n may have been prepared in advance by financial data display engine 24 n , i.e. upon a last transaction (e.g. a project 38n or contract 1 2 n being created, a claim/payment application being made or approved, etc.) being completed, or may be prepared in (substantially) real-time upon, for example, a request being received by system 1 0 to display a project screen 34 n .
  • a last transaction e.g. a project 38n or contract 1 2 n being created, a claim/payment application being made or approved, etc.
  • Each contract 1 2 n displayed on project screen 34 n may preferably be expanded (to, for example, the exemplary single contract 1 2 n (expanded) GUI screen-shot 34 n shown in Fig. 6) by simply selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) any region of the selected contract 1 2 n shown on project screen 34 n .
  • the user 1 4 n e.g. first agent 1 4 n , may select or hover over (e.g.
  • a user 1 4 n , 1 6n, 32 n may return to the project screen 34n (of Fig. 4), showing the concise or collapsed view of each contract 1 2 n , at any time by (preferably) either using an inbuilt GUI "back" button should one be available, or selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) the project directory (e.g. "Project Name 1 ", as shown) of the navigation element 48 shown, in Fig. 4, toward the top left hand side of project screen 34 n .
  • the project directory e.g. "Project Name 1 ", as shown
  • buttons or regions may include, but are not limited to: a button or region 60 that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to access a facility for searching for specific contracts 1 2 n that exist for the particular project 38n being viewed; a button or region 62 that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to access a pop-up screen or the like (not shown), that a user, e.g. first agent 1 4 n , may use to selectively show or hide certain (by way of, for example, check boxes or the like) summary information (e.g.
  • a button or region 64 e.g. a "Pending Claims” button or region, that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to selectively only display contracts 1 2 n having pending claims; and/or; a button or region 66, e.g. a "Contracts” button or region, that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to selectively display all contracts 1 2 n associated with the particular project 38n.
  • a button or region 64 e.g. a "Pending Claims” button or region, that may be selected or hovered over (using a GUI pointing device, pen, finger, etc.) so as to selectively only display contracts 1 2 n having pending claims
  • a button or region 66 e.g. a "Contracts” button or region, that may be selected or hovered over (using a GUI pointing device, pen, finger, etc
  • step 208 it is determined whether the user 1 4 n , 1 6n, is already associated with one or more projects 38n. If user 1 4 n , 1 6n, is not associated with any projects 38n (and, for example, is presented with a blank dashboard screen 34 n (not shown), as previously discussed with reference to Fig.
  • step 21 0 whereat the user 1 4 n , 1 6n, may selectively choose to add one or more new projects 38n, by way of, for example, "Add Project" button or region 58 (see, Fig. 3). Should user 1 4 n , 1 6n, choose not to add a new project 38n at step 21 0, then method 200 may return to step 206, and then loop between steps 206, 208 & 21 0, until such time that user 1 4 n , 1 6n, elects to add a new project 38n (at step 21 0), signs out or logs out of system 1 0 (not represented in the flow diagram of Fig.
  • step 21 2 If user 1 4 n , 1 6n, choose to add a new project 38n, at step 21 0 (using, for example, "Add Project" button or region 58, of dashboard screen 34 n of Fig. 3), then method 200 may continue at step 21 2, whereat user 1 4 n , 1 6n, is provided with a create new project GUI screen(s) (not shown), accessible via their user terminal(s) 28n, for inputting, and possibly importing (discussed below), the required information necessary to create a new project.
  • Information required for creating a new project 38n for use with system 1 0 may include, but is not limited to: a project name; the proposed commencement date for the project (which may be selected using a pop-up calendar, etc.); the proposed completion date for the project (again, which may be selected using a pop-up calendar, etc.); the monthly claim submission reminder day (i.e. the specific day of each month that notifications will be sent (e.g. by third party notification service provider 33n, e.g. MandrillTM) to all contracted claimants, e.g.
  • third party notification service provider 33n e.g. MandrillTM
  • second agents 1 6n reminding them to submit any claims or payment applications; the project site address (including the street, city, postal or zip code, state and country); and/or, access permissions applicable to the new project 38n.
  • the access permissions for new project 38n may preferably and readily be selectable by way of a series of check-boxes that are all preferably ticked or populated by default (i.e. granting all available access permissions by default). In this way, a user, e.g.
  • first agent 1 4 n may either simply accept the default setting of granting full access to all users 1 4 n , within their organisation, or their appointed third party agent(s) 32 n , that will be collaborating on new project 38n, or may un-tick any check-boxes associated with access permissions that they do not wish to grant to users 1 4 n , 32 n , that will be collaborating on new project 38n.
  • Preferred access permissions that may be set by way of the preferred check-boxes (not shown) presented to user 1 4 n , etc., in accordance with system 1 0, may include, but are not limited to: view rights; rights to change primary contact information (which is used for system 1 0 generated correspondence); rights to create contracts; rights to change claim or payment application submission reminder information or settings (i.e. to select which users 1 4n, or third party agents 32 n , receive what notifications, etc.); rights to submit claims or payment applications; rights to change claim or payment application submission notification information or settings (i.e. to select whether or not a user 1 4n, or third party agent 32 n , receives such notifications, etc.); rights to change claim or payment application approval reminders information or settings (i.e.
  • the preferred access permissions may readily be used to, for example, provide view only (and/or other limited) project 38n access to certain users, such as, for example, third party agents 32 n , etc.
  • view only (and/or other limited) project 38n access to certain users such as, for example, third party agents 32 n , etc.
  • examples of the type of information and settings that may be required in order to create a new project 38n in accordance with step 21 2, of method 200, are provided, it will be appreciated that only some of that information, or those settings, or alternative information/settings, could be used to create a new projects 38n in accordance with the present invention.
  • the present invention should therefore not be construed as limited to the specific examples provided.
  • step 21 2 of creating a new project 38n in accordance with method 200 of the present invention at least some of the necessary new project 38n information/settings may be imported into system 1 0 from, for example, an external ERP software provider 30n (such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.). That is, the create new project GUI screen(s) (not shown) presented to user, e.g.
  • an external ERP software provider 30n such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.
  • 1 4 n for inputting the required information necessary to create a new project 38n may include a facility for integrating system 1 0 with an ERP software provider 30n, etc., so as to enable user 1 4 n to readily retrieve existing ERP project information for automatically populating the necessary information/setting fields as part of step 21 2, of method 200.
  • Access to, or integration with, the ERP software provider 30n, etc. may be enabled, facilitated and/or granted, by way of, e.g. the "Add-On" facility or page(s) (not shown) previously described with reference to dashboard screen 34 n , of Fig. 3.
  • the process of integrating system 1 0 with an ERP or other software provider 30n would include a user, e.g.
  • the user After having entered (and/or imported from, e.g. external ERP software provider 30n, etc.) all necessary information/settings required to create a new project 38n, at step 21 2, the user, e.g. first agent 1 4 n , may then save or submit (using, e.g. an "Update” or “Submit” button or region (not shown) provided within the create new project GUI screen(s) (not shown) presented to user, e.g. 1 4 n , for inputting the required information necessary to create a new project) the new project 38n for use with system 1 0.
  • a notification(s) may be sent (by, e.g. a third party notification service provider 33n, e.g.
  • step 21 4 whereat the user, 1 4n, 1 6n, is presented with either their dashboard screen 34 n (e.g. Fig. 3, showing the concise or collapsed view of the new project 38n, and any other projects 38n), or the project screen 34 n (e.g. Fig. 4, the expanded view of new project 38n) applicable to the new project 38n just created.
  • dashboard screen 34 n e.g. Fig. 3, showing the concise or collapsed view of the new project 38n, and any other projects 38n
  • the project screen 34 n e.g. Fig. 4, the expanded view of new project 38n
  • step 208, of method 200, of Fig. 2 if it is determined that user, e.g. 1 4 n , 1 6n, is already associated with one or more projects 38n (and, for example, is presented with a dashboard screen 34 n populated with existing project(s) 38n, as previously discussed with refer to Fig. 3), then method 200 may continue at step 21 6, whereat user 1 4 n , 1 6n, may selectively choose to add one or more new projects 38n, by way of, for example, "Add Project" button or region 58 (see, Fig. 3) .
  • step 21 6 If user 1 4 n , 1 6n, choose to create a new project 38n, at step 21 6, then method 200 may continue at step 21 2 (i.e. user 1 4 n , 1 6n, creates a new project 38n) , and then step 21 4 (i.e. user 1 4 n , 1 6n, is presented with either dashboard or project screen 34 n , see, for example, Figs. 3 & 4), as hereinbefore described.
  • step 21 2 i.e. user 1 4 n , 1 6n, creates a new project 38n
  • step 21 4 i.e. user 1 4 n , 1 6n, is presented with either dashboard or project screen 34 n , see, for example, Figs. 3 & 4
  • step 21 6 method 200 continues at step 21 8, whereat user 1 4 n , 1 6n, may selectively choose to edit an existing project 38n, by way of, for example, the "Edit Project" button or region (not shown) that may be revealed (and then selected or hovered over, using, e.g. a GUI pointing device, pen, finger, etc.) by way of selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) button or region 42n shown in, for example, Figs. 3 & 4.
  • the "Edit Project" button or region not shown
  • the "Edit Project" button or region may be revealed (and then selected or hovered over, using, e.g. a GUI pointing device, pen, finger, etc.) by way of selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) button or region 42n shown in, for example, Figs. 3 & 4.
  • method 200 may continue at step 21 4 (i.e. user 1 4n, 1 6n, is presented with either dashboard or project screen 34 n ) , as hereinbefore described.
  • step 21 4 i.e. user 1 4n, 1 6n, is presented with either dashboard or project screen 34 n
  • method 200 may continue at step 220, whereat user 1 4 n , 1 6n, is provided with an edit project GUI screen(s) (not shown), accessible via their user terminal(s) 28n, for editing the selected existing project 38n.
  • GUI screen(s) not shown
  • 1 4 n , 1 6n may then edit information/settings for the existing project 38n, as desired (including importing in any missing or new/updated ERP or other software provider(s) 30n information, if desired), so long as they have been granted the necessary access permissions (as hereinbefore described with reference to step 21 2 for creating a new project 38n in accordance with method 200 of Fig. 2) required to do so.
  • user 1 4 n , 1 6n, etc. may then save or submit those changes (using, e.g. an "Update” or "Submit” button or region, etc. - not shown) as previously described.
  • step 21 4 whereat the user, 1 4 n , 1 6n, is presented with either their dashboard screen 34 n (e.g. Fig. 3) or the project screen 34 n (e.g. Fig. 4) applicable to the project 38n just edited.
  • dashboard screen 34 n e.g. Fig. 3
  • project screen 34 n e.g. Fig. 4
  • step 21 4 method 200, of Fig. 2, may continue at step 222, whereat it is determined whether a selected project 38n already has one or more contracts 1 2 n associated therewith. If it is determined that no contracts 1 2 n are associated with the selected project 38n, then method 200 may continue at step 224, whereat the user, e.g. first or second agent 1 4 n , 1 6n, may selectively choose to add one or more new contracts 1 2 n , by way of, for example, any of the "Add Contract" or "New Contract” button(s) or regions(s), etc.
  • method 200 may return to step 21 4 or step 206 (i.e. back to dashboard screen 34 n or project screen 34 n ) , as hereinbefore described.
  • method 200 may continue at step 226, whereat user 1 4n, 1 6n, is provided with a create new contract GUI screen(s) 34 n accessible via their user terminal(s) 28n, for inputting the required information necessary to create a new contract 1 2 n .
  • a preferred process for adding a new contract 1 2 n in accordance with step 226, of method 200, will now be described with reference to exemplary create new contract GUI screen-shot 34 n of Fig. 5.
  • the preferred GUI screen 34 n (which in this instance only shows the preferred screen content so as to simplify the drawing) for creating a new contract 1 2 n (hereinafter simply referred to as "create contract screen(s) 34 n ") in accordance with step 226, is shown in a state part way through the preferred process of creating a new contract 1 2 n in accordance with method 200, of Fig. 2. That is, although not shown, before arriving at the create contract screen 34 n at the stage shown in Fig.
  • an initial screen (or a portion of screen 34 n that has since been collapsed, etc.) was preferably presented to user 1 4 n , 1 6n, etc., by way of their user terminal 28n, requiring them to input or select their role applicable to the new contract 1 2 n , that is, whether or not they will be: a respondent 1 6n (i.e. will be approving claims or payment applications for the new contract 1 2 n ) or a claimant 1 4n (i.e. will be making claims or submitting payment applications in connection with the new contract 1 2 n ). If the user, e.g.
  • a first agent 1 4 n inputted or selected "respondent" as their role applicable to the new contract 1 2 n , then within the initial create contract screen (not shown) they were then preferably only required to input or select details of the counterparty, e.g. a second agent 1 6n, etc., applicable to the new contract 1 2 n , and a contract name or reference for the new contract 1 2 n .
  • Existing counterparty details may preferably have been selected from a drop down menu presented to user 1 4 n , etc., whilst new counterparty details may preferably have been input by either initially entering the counterparty 1 6n, etc., name, which may then have preferably presented a pop-up menu, or the like (not shown), to user 1 4n, that they were then able to use to input the required remaining counterparty 1 6n, etc., details, or by selecting, etc., a button or region, e.g.
  • a "New Counterparty” button or region (not shown), which may then have presented user 1 4 n , etc., with a pop-up menu, or the like (not shown), to user 1 4 n , that they were able to use to input the required remaining counterparty 1 6n, etc., details. Thereafter, the user 1 4 n , was preferably presented with (at least) a "Continue” button or region (not shown), which when selected, etc., took the user 1 4 n to the stage of the preferred new contract 1 2 n creation process shown and represented in/by Fig. 5. Alternatively, if the user, e.g.
  • a second agent 1 6n inputted or selected "claimant" as their role applicable to the new contract 1 2 n , within the initial create contract screen (not shown), they were then preferably required to select, or otherwise, whether or not they will be self- assessing claims made against the new contract 1 2 n on behalf of the counterparty (in this example, first agent 1 4 n ) . If user 1 6n, etc., selected the self-assess option, then system 1 0 will run in its preferred stand-alone mode for the new contract 1 2 n (i.e. the user 1 6n, etc., will have the ability to enter both respondent 1 4 n and claimant 1 6n details themselves for the new contract 1 2 n ) as hereinbefore described.
  • system 1 0 will run in its preferred collaborative mode as hereinbefore described (i.e. with the counterparty, e.g. first agent 1 4 n , later being invited by system 1 0 to collaborate in connection with the new contract 1 2 n ).
  • user 1 6n, etc. was then required to enter the counterparty 1 4 n , etc., and contract name/reference details (as described previously), before selecting, etc., e.g. a "Continue" button or region, which then took the user 1 6n to the stage of the preferred new contract 1 2 n creation process shown and represented in/by Fig. 5.
  • preferred create contract screen 34 n preferably includes various facilities, i.e. panels, text boxes (which may incorporate, for example, drop-down menus with selectable text/data, or automated data retrieval or search facilities, etc., for assisting a user, e.g. a first agent 1 4 n , which inputting the information necessary for creating a new contract 1 2 n ) , check-boxes, buttons or regions, etc., so as to enable a user, e.g.
  • a first or second agent 1 4 n , 1 6n to create a new contract 1 2 n for the selected project 38n.
  • These facilities may include, but are not limited to: a text box 68 for entering/editing the contract name or reference; a text box 70 for entering the contract date (which may, for example, provide a facility for selecting the date from a pop-up calendar, or the like); a text box 72 for entering the proposed commencement date for the contract 1 2 n (which may, for example, provide a facility for selecting the date from a pop-up calendar, or the like); a text box 74 for entering the proposed completion date for the contract 1 2 n (which may, for example, provide a facility for selecting the date from a pop-up calendar, or the like); a text box 76 for entering the defect liability period applicable to the contract 1 2 n ; a text box 78 which may include a selectable drop-down menu (not shown) for nominating the retention/retainage basis (e.g.
  • a text box 80 for entering the cash retention/retainage percentage or dollar limit (depending on the basis selected nominated by user, e.g. first agent 1 4 n , by way of text box 78) applicable to the contract 1 2 n ; a text box 82 for entering the retention/retainage accumulation percentage amount applicable to the contract 1 2 n (although not shown, should user 1 4n, etc., nominate "bank guarantee" as the retention/retainage basis by way of text box 78, then text box 82 will disappear or be greyed out, etc.); a check-box 84 for nominating whether or not the variation retention/retainage is to be the same as the contract 1 2 n (if check-box 84 is not checked, then new variation/change order text boxes appear that are the same as that of text boxes 78, 80 & 82, only this time for variation/change order retention/retainage parameters);
  • second agent 1 6n, etc. which may include a drop-down menu, or the like (not shown) for selecting the applicable trade type
  • a text box 96 for entering any special instructions (comments, or the like) applicable to the contract 1 2 n
  • check-box 98 for nominating whether or not Recipient Created Tax Invoices (RCTI) are to be enabled and generated by system 1 0, in accordance with the contract 1 2 n
  • a panel 1 00 including multiple text boxes, drop-down menus, check-boxes and buttons or regions for entering/setting compliance (e.g.
  • buttons or region 1 02 that may be selected or hovered over (e.g. using a GUI pointing device, pen, finger, etc.) so as to hide all of text boxes/checkboxes 68 to 1 00, after having entered or selected the necessary contract 1 2 n information using those boxes 68 to 1 00 (e.g.
  • preferred panel 100 for entering compliance (e.g. required supporting documents, etc.) information/settings applicable to the new contract 12 n may include multiple line items each relating to a specific compliance document type 100a that must be submitted in accordance with the new contract 12 n .
  • three different document types 100a have been selected, e.g. public liability insurance, workers compensation insurance and subcontractor declaration.
  • These (three) example compliance line items, and their associated settings 100b, 100c, 100d may be provided by default, or may be added one at a time, as desired, by way of the "Add Document" button or region 10Of , or some other similar button or region (not shown).
  • the settings 100b, 100c, 100d, associated with each compliance document type preferably include: a text box 100b, which may include a drop-down menu, or the like (not shown), for selecting a stage, e.g.
  • a check-box 100c for selecting whether or not the expiry date applicable to the particular required supporting document (e.g. the expiry date of an insurance policy, etc.) must also be provided by user 1 6n, etc.; and, a check-box 100d for selecting whether or not a user 1 4n, 1 6n, etc., can make or approve a claim or payment application without submitting/verifying the required supporting document. It is preferred that panel 100 for entering compliance (e.g.
  • each contract item 104n is in the form of a line or row, and each contract item 104 n preferably includes: a text box 104a for entering an item reference (e.g. a unique item reference); a text box 104b for entering an item description (e.g.
  • a description of the good or service to be supplied in accordance with the new contract 12 n a text box 104c for entering the items value when completed (excluding Goods and Services Tax (GST) in this example); a check-box 104d for selecting whether or not the contract item 104 n is to be included or excluded from retention/retainage calculations; and, a check-box 104e for selecting whether or not the contract item 104 n is exempt from tax (e.g. Goods and Services Tax, or GST as it is known in Australia).
  • GST Goods and Services Tax
  • contract items 104 n can be created and grouped in sections such that a section header (not shown) may be provided with one or more sub contract items 104 n disposed thereunder.
  • the section header may include a section title or description 104b (e.g. construction of new dwelling, etc.), with each sub (section) contract item 104 n thereunder having a sub section description 104b (e.g. erecting brick walls, erecting roof, plumbing, etc.).
  • sub section description 104b e.g. erecting brick walls, erecting roof, plumbing, etc.
  • the text box 104c may be omitted altogether for section headings (not shown).
  • the section header may simply provide a consolidated summary and completion amount total of the goods or services to be supplied by way of the sub contract items 104 n for that section, or may simply only provide a description for the contract items 104 n for that section. For this reason, the check-boxes 104d and 104e, need not apply to the section header line or row of preferred panel 104.
  • New sections and contract items 104 n may be added to the new contract 12 n by way of, for example, buttons or regions, e.g. an "Add New Section" button or region 104f, and an "Add New Line” button or region 104g.
  • a button or region 104h associated with each section header (not shown) or contract item 104n may be accessed (e.g. using a GUI pointing device, pen, finger, etc.) so as to reveal a drop-down menu of the like (not shown) for accessing buttons or regions (not shown) for converting a contract item 104 n into a section header and vice versa, or for deleting unwanted sections or contract items 104 n .
  • a button or region 104h associated with each section header (not shown) or contract item 104n may be accessed (e.g. using a GUI pointing device, pen, finger, etc.) so as to reveal a drop-down menu of the like (not shown) for accessing buttons or regions (not shown) for converting a contract item 104 n into a section header and vice versa, or for deleting unwanted sections or contract items 104 n .
  • completion item value text boxes 104c there is automatically calculated total 104i, which represents the total amount of all contract items 104 n
  • contract items 1 04n may be created as a schedule of rates by way of selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) a button or region 104j, and then accessing and selecting, etc., the option of using a "Schedule of Rates" by way of, for example, a drop-down box or the like (not shown).
  • a "Schedule or Rates” is selected (not shown)
  • the text boxes for entering the total amount of the contract item 104 n at completion may be replaced with boxes showing an automatically calculated total for the contract item 1 04n.
  • an additional text box (not shown) for each contract item 1 04 n may be provided so as to select whether or not a user, e.g. 1 6n, can enter any desired quantity amount (e.g.
  • buttons or regions 104k e.g. the "Import from Excel”, etc., button or region
  • 104m e.g. the “Sample Import Files", etc., button or region
  • At least some of the necessary new contract 12 n information/settings may be imported into system 10 from, for example: an external ERP software provider 30n (such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.); an Excel or similar spreadsheet; and/or, from a sample file (in any suitable format) that may be downloaded from, for example, network server 20n of system 10. That is, create contract screen 34 n of Fig. 5, presented to user, e.g.
  • an external ERP software provider 30n such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.
  • an Excel or similar spreadsheet and/or, from a sample file (in any suitable format) that may be downloaded from, for example, network server 20n of system 10. That is, create contract screen 34 n of Fig. 5, presented to user, e.g.
  • a first agent 1 4n for inputting the required information necessary to create a new contract 12 n may include a facility (such as, for example, "Import from Excel” button or region 104k, which may of course be replaced with simply an "Import” button or region, or to an "Import from ERP” button or region, etc.) for integrating system 10 with an ERP software provider 30n, etc.; or for enabling a user to import Excel or similar spreadsheet data, or any other suitable data (whether the user's 14 n own data, or sample data downloaded from, e.g. network server 20n, using, e.g.
  • sample Import Files button or region 104m of create contract screen 34 n ) into system 10, so as to enable user 14 n to readily retrieve existing ERP contract information and/or (user 1 4n or sample) Excel or other spreadsheet or similar contract data, for automatically populating the necessary information/setting fields as part of step 226, of method 200.
  • existing ERP contract information and/or (user 1 4n or sample) Excel or other spreadsheet or similar contract data, for automatically populating the necessary information/setting fields as part of step 226, of method 200.
  • text boxes 68 through to 92, along with some (generally consolidated) contract items 1 04 n of create contract screen 34 n , of Fig. 5, and the counterparty details may be pre-populated by way of the import process.
  • a user 14 n may, if necessary, convert one or more of the imported contract items 1 04 n into a section heading (using, e.g. button(s) or region(s) 1 04h) , and then create a breakdown of the works by way of adding subcontract items 1 04n (the sub-contract item 1 04 n information possibly being imported into system 10 from an Excel spreadsheet, or the like).
  • access to, or integration with, an ERP software provider 30n, etc. may be enabled, facilitated and/or granted, by way of, e.g.
  • a first agent 1 4 n need only alter the pre-populated information in those boxes 68 to 1 04 that he/she wishes to change for the new contract 1 2 n being created.
  • the present invention should therefore not be construed as limited to the specific examples provided.
  • a notification (not shown) may then be sent (by, e.g. a third party notification service provider 33n, e.g. MandrillTM, etc.) to the counterparty, e.g. first, second or third agent 1 4 n , 1 6n, 32 n , applicable to the new contract 1 2 n , inviting them to collaborate on the associated project 38n.
  • a third party notification service provider 33n e.g. MandrillTM, etc.
  • the counterparty 1 4 n , 1 6n, 32 n is a not an existing user 1 4 n , 1 6n, 32 n , of system 1 0, then that notification may also include an invitation, link(s), instructions, etc., for informing/inviting the counterparty 1 4 n , 1 6n, 32 n , to create a new account for use with system 1 0 (e.g. by way of, for example, steps 202a or 202b, and then 204, of preferred method 200, of Fig. 2) .
  • step 226 After creating a new contract 1 2 n for a selected project 38n, at step 226, method 200 (of Fig. 2) may continue at step 228, whereat the user, 1 4 n , 1 6n, etc., is preferably presented with the project screen 34 n (see, Fig. 4), for the selected project 38n, which includes a concise or collapsed view of the new contract 1 2n just created. User, 1 4 n , 1 6n, etc., may then select or hover over (e.g.
  • preferred contract screen 34n which in this example is that of a second agent 1 6n, e.g. a subcontractor or some other "claimant", preferably includes a number of panels, buttons or regions, for displaying information/documents associated with the selected contract 1 2 n and/or for performing various actions in connection with that contract 1 2 n .
  • contract screen 34 n preferably includes, but it not limited to: a panel or region 1 1 2 for displaying consolidated project-to-date summary information; a panel of region 1 1 4 for displaying counterparty (e.g.
  • claimant information should the user be a first agent 1 4 n , or respondent information should the user be a second agent 1 6n, etc.) information; a panel or region 1 1 6 for displaying project-to-date claim or payment application summary information and/or for making/approving claims/payment applications; and/or, a panel or region 1 1 8 for displaying required supporting documentation (i.e. compliance documents/information) that must be (e.g. as was defined in panel 1 00, of create contract screen 34 n , of Fig. 5) , or has been, submitted or otherwise provided in accordance with contract 1 2 n . [01 1 6] Although not shown in Fig.
  • preferred contract screen 34 n may also include an additional (temporary) panel or region (not shown) for displaying summary information (and buttons or regions for performing any desired or necessary tasks) related to that/those draft/pending claim(s)/payment application(s) and/or for viewing, editing, finalising, submitting, assessing, approving, etc., that/those draft/pending claim(s)/payment application(s) in accordance with system 10.
  • summary information and buttons or regions for performing any desired or necessary tasks
  • such draft/pending claim/payment application summary information may instead be included within preferred panel or region 1 1 6.
  • other panels or regions (not shown), or alternatives or variations of the preferred ones described herein may be provided in accordance with the present invention. The present invention should therefore not be construed as limited to the specific examples provided.
  • one or more of preferred panels or regions 1 12, 1 14, 1 1 6 and/or 1 18, may be selectively collapsed or expanded by system 10, or selectively by a user, e.g. second agent 1 6n, as desired, as part of the process of viewing/using preferred contract screen 34 n .
  • each of panels/regions 1 12, 1 14 and 1 18 may preferably be collapsed/expanded by way of the " ⁇ " buttons or regions 1 12a, 1 14a, and 1 18a.
  • each of regions 1 12, 1 14, 1 18 may display a brief description of the respective panel/region, e.g.
  • the compliance documentation panel or region 1 18 (in its concise or collapsed form - not shown) preferably also includes clever, preferably colour coded, visual indicators (e.g. colour coded icons, regions, etc., not shown) so that a user 14 n , 1 6n, may readily determine (e.g. by way of, for example, selecting or hovering over, using, e.g.
  • preferred panel or region 1 1 2 preferably displays consolidated project-to-date summary information for the selected contract 1 2n.
  • the summary information preferably includes, but is not limited to: the project/contract name or reference; 'approved to date' and 'when complete' claim/payment application and contract 1 2 n project-to-date consolidated totals for each of the contract works, approved variations, unapproved variations, total works and rejected variations; the project-to-date revised total amount of the contract 1 2 n ; the project-to-date total retention/retainage amounts withheld in accordance with the contract 1 2 n ; and/or, the completion status of the contract 1 2 n which may clearly and cleverly be displayed by way of, for example, a number representing a completion percentage amount and/or a progress wheel 1 1 2b or the like (e.g.
  • Preferred panel or region 1 1 2 may also include a button or region 1 12c, e.g. an "Edit Contract” button or region 1 12c, which, when selected or hovered over (e.g. using a GUI pointing device, pen, finger, etc.), may provide the user, e.g. a first or second agent 1 4 n , 1 6n, with an edit contract GUI screen(s) (not shown - but which may simply be the same as, or similar to, preferred create contract screen 34 n , shown in Fig. 5) that they may use to edit the selected contract 1 2n if or as desired using (such as, for example, in accordance with step 234, of method 200, of Fig. 2, as will be described below).
  • a button or region 1 12c e.g. an "Edit Contract" button or region 1 12c, which, when selected or hovered over (e.g. using a GUI pointing device, pen, finger, etc.), may provide the user, e.g. a first or second agent
  • the preferred panel or region 1 1 4 for displaying the counterparty information, shown in Fig. 6 as a "Respondent", may simply list or otherwise display important particulars or details concerning the counterparty.
  • Such particulars may include, but are not limited to: the counterparty name (e.g. the individual, business or company name); the counterparty representative (which may not be provided or may be blank should the counterparty be an individual, etc.); the counterparty address; the counterparty e-mail address(es); the counterparty company registration number (e.g. an ABN or ACN number in the case of an Australian business or company, etc.), if applicable; and/or, the counterparty phone number(s).
  • the counterparty name e.g. the individual, business or company name
  • the counterparty representative which may not be provided or may be blank should the counterparty be an individual, etc.
  • the counterparty address e.g. an ABN or ACN number in the case of an Australian business or company, etc.
  • the counterparty company registration number e.g. an
  • Fig. 6 it can be seen that should one or more claims or payment application have already been made and assessed/approved in accordance with the selected contract 12 n , then preferred panel or region 1 16 preferably displays a concise view of all claims/payment applications made and approved in connection with that contract 12 n .
  • panel 1 16 will not be populated with any claim/payment application history.
  • each claim/payment application displayed within panel 1 16 of contract screen 34 n preferably provides summary information concerning the claim/payment application.
  • This summary information may include, but is not limited to: the claim/application number or other reference; the date of submittal of the claim/application; the approval date of the claim/application; the total amount of works claimed; the total amount of variations claimed; the total amount of works approved; and/or, the total amount of variations approved in connection with the claim/application.
  • a user e.g. first, second or third agent 1 4 n , 1 6n, 32 n , wish to inspect or view one of the previously approved claims/applications displayed within panel 1 16n, they may do so by way of, e.g.
  • a button or region 1 16b such as, for example, a "Make Claim” or “Assess Claim” (not shown) button or region.
  • Preferred processes for making and submitting claims or payment applications (at step 236) and assessing/approving claims or payment applications (at step 238) , in accordance with method 200, will be described in detail below.
  • the consolidated financial information that is displayed within contract screen 34 n , of Fig. 6, is generated by financial data display engine 24 n of network server 20n (or a third party service provider 33n, if desired) of system 10.
  • financial data display engine 24 n Upon a user 14 n , 16n, 32 n , requesting or otherwise being provided with contract screen 34 n of Fig. 4, financial data display engine 24 n preferably retrieves, calculates, analyses and/or manipulates all necessary financial data, and then populates the relevant fields or regions (e.g. panel or region 1 1 2 and 1 16, etc.) for the contract 1 2 n (displayed in its concise or collapsed form) provided within contract screen 34 n .
  • the consolidated financial data for display within contract screen 34 n may have been prepared in advance by financial data display engine 24 n , i.e. upon a last transaction (e.g.
  • a project 38n or contract 1 2 n being created, a claim/payment application being made or approved, etc.) being completed, or may be prepared in (substantially) real-time upon, for example, a request being received by system 1 0 to display a contract screen 34 n .
  • the preferred panel or region 1 18 for displaying required supporting documentation (i.e. compliance documents/information) that must be, or has been, submitted or otherwise provided (or must be verified, or has been verified - as will be described below with reference to the process of assessing/approving a claim in accordance with step 238, of preferred method 200) in accordance with contract 1 2n is preferably presented to (at least) claimant's 1 6n, e.g. second agent's 1 6n, in its expanded form as shown in Fig. 6.
  • a second agent 1 6n, etc. chooses to view a selected contract 1 2 n , for any given project 38n, in accordance with step 228 of method 200 (Fig.
  • the second agent 1 6n is automatically, and conveniently, presented with a list of the required supporting documents, if any, that they must submit in accordance with the selected contract 1 2 n (i.e. the supporting compliance documents selected, e.g. by way of preferred panel 1 00 of create contract screen 34 n of Fig. 5, by the user, e.g. the first agent 14 n , that created the selected contract 1 2 n in accordance with the invention).
  • Panel 1 18 may then be readily and selectively collapsed, as desired, by way of, for example, the " ⁇ " button or region 1 18a.
  • Another way of accessing a list of the supporting compliance documents required to be submitted or otherwise provided in accordance with the selected contract 1 2 n , and/or selectively submitting/providing any required compliance documents/information may include selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) a button or region, e.g. a "Manage Contract Attachments" button or region 1 16c, accessible via, for example, preferred panel or region 1 1 6, of contract screen 34 n , which may then bring up a pop-up screen, or the like (not shown), which includes the list of required supporting documents and/or a facility for submitting/uploading those documents, etc..
  • a button or region e.g. a "Manage Contract Attachments" button or region 1 16c
  • the required supporting compliance documentation may include, but is not limited to: insurance certificates of currency (for, e.g. public liability, professional indemnity, etc.), work cover information/documentation and/or, statutory declaration (s) confirming that all workers, subcontractors, etc., have been paid.
  • insurance certificates of currency for, e.g. public liability, professional indemnity, etc.
  • work cover information/documentation and/or statutory declaration (s) confirming that all workers, subcontractors, etc., have been paid.
  • statutory declaration confirming that all workers, subcontractors, etc., have been paid.
  • second agent 1 6n, etc. may then view or attach/upload/otherwise submit (e.g. using drag and drop, etc.) one or more of the required supporting documents by way of contract page 34 n (e.g.
  • a view or upload facility that may be presented to the user 1 6n, etc., upon selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.): a previously submitted document (e.g. the Public Liability Insurance document shown in Fig. 6) or the outline of a "Missing” document (e.g. the "Missing” Workers Compensation Insurance document shown in Fig. 6; and/or, the "Manage Contract Attachments" button or region 1 16c of panel 1 16) of Fig. 6.
  • preferred panel/region 1 18 may also include at least one button or region (not shown), e.g. "Download Compliance Document Template", “Download Statutory Declaration Template” (e.g.
  • a pre-prepared region-specific template possibly configured for the user's 14 n , etc., requirements
  • "Download Sample Compliance Document” so as to readily enable a user 1 6n, etc., to download (or otherwise obtain) and use compliance document templates (e.g. for preparing a required statutory declaration, etc.), or sample compliance documents, to assist them with preparing and submitting various required supporting compliance documents, etc.
  • method 200 may continue at step 230, whereat user 14 n , 1 6n, may selectively choose to add one or more new contracts 12 n , by way of, for example, any of the "Add Contract” or "New Contract” button(s) or regions(s), etc. (not shown), that may be accessible to user 1 4 n , 1 6n, by way of project screen 34 n (as was described previously with reference to Fig. 4).
  • method 200 may continue at step 226 (i.e. user 1 4 n , 1 6n, creates a new contract 1 2 n ) , and then step 228 (i.e. user 1 4 n , 1 6n, is presented with the contract screen 34 n for the new contract 12 n , see for example, Fig. 6, and may then submit any required supporting compliance documents, etc., if needed, or if required to do so, etc.), as hereinbefore described.
  • step 226 i.e. user 1 4 n , 1 6n, creates a new contract 1 2 n
  • step 228 i.e. user 1 4 n , 1 6n, is presented with the contract screen 34 n for the new contract 12 n , see for example, Fig. 6, and may then submit any required supporting compliance documents, etc., if needed, or if required to do so, etc.
  • method 200 may continue at step 232, whereat user 1 4 n , 1 6n, may selectively choose to edit an existing contract 12 n , by way of, for example, selecting or hovering over (e.g. using a GUI pointing device, pen, finger, etc.) an "Edit Contract" button or region 1 12c, provided within contract screen 34 n (see, for example, Fig. 6). Should user 1 4 n , 1 6n, choose not to edit an existing contract 12 n , at step 232, then method 200 may continue at step 228 (i.e.
  • user 1 4 n , 1 6n may be presented with a contract screen 34n for a selected contract 12 n , see for example, Fig. 6, and may then submit any required supporting compliance documents, etc., if needed, or if required to do so, etc.), as hereinbefore described.
  • method 200 may continue at step 234, whereat user 1 4 n , 1 6n, is provided with an edit contract GUI screen(s) (not shown - but which may simply be the same as, or similar to, the create contract screen 34 n , shown in Fig.
  • user e.g. 1 4 n , 1 6n
  • may then edit information/settings for the existing contract 1 2 n including importing in any missing or new/updated ERP or other software provider(s) 30n contract information, reference numbers, etc., or importing in any contract related information from a spreadsheet, e.g. an Excel spreadsheet, if desired), so long as they have been granted the necessary access permissions (as hereinbefore described with reference to step 212 for creating a new project 38n, or step 226 for creating a new contract 12 n , in accordance with method 200 of Fig. 2), as desired or required to do so.
  • step 234 user 1 4 n , 1 6n, etc., may then save or submit those changes (using, e.g. an "Update”, “Submit”, “Save or “Save and Publish” button or region 1 1 0, etc. - see, for example, Fig. 5) as previously described.
  • method 200 may continue at step 228 (i.e. user 1 4n, 1 6n, may be presented with the contract screen 34 n for the existing contract 1 2n, see for example, Fig. 6, just edited, and may then submit any required supporting compliance documents, etc., if needed, or if required to do so, etc.), as hereinbefore described.
  • method 200 may continue at either: step 236, whereat, the user, e.g. a second agent 1 6n, may make a claim or payment application in accordance with the selected contract 1 2 n ; or, step 238, whereat, the user, e.g.
  • a first agent 1 4 n may assess and approve (or otherwise) a claim or payment application in accordance with the selected contract 1 2 n .
  • Preferred processes for making and submitting claims or payment applications (at step 236) and assessing/approving claims or payment applications (at step 238), in accordance with method 200, will be described in detail below with reference to the flow diagrams of Figs. 7 & 9, which will be described in conjunction with the exemplary GUI screen-shots 34 n of Figs. 8 & 1 0.
  • method 200 may simply end, e.g. by way of the user 1 4 n , 1 6n, 32 n , logging out of system 1 0, or by returning user 1 4 n , 1 6n, 32 n , to, for example, dashboard screen 34n (see, Fig. 3) .
  • Fig. 7 there is shown a flow diagram which illustrates a preferred method 236 for making claims or payment applications in accordance with step 236, of method 200, of Fig. 2.
  • the preferred process of making a claim or payment application in accordance with method 236 preferably commences at step 236A, whereat the user, e.g. a first or second agent 1 4 n , 1 6n, is presented with, or arrives at, a GUI "make claim or payment application" page(s) or screen(s) 34 n (hereinafter simply referred to as "make claim screen 34 n "), by way of their user terminal(s) 28n.
  • FIG. 8 An exemplary GUI screen-shot 34 n of a preferred make claim screen 34 n is shown in Fig. 8 (which may display a new claim/payment application being created from scratch, or may show a previously saved draft claim/payment application - which will be described in detail below).
  • step 236A shown in Fig. 7, if any existing claim(s)/application(s) have been made against the selected contract 12 n , then details pertaining to the existing claim(s)/application(s) are retrieved by system 10, and used to generate the display of information shown within make claim screen 34 n .
  • the existing claim(s)/application(s) details preferably include, but are not limited to: the last claim/application number made against the contract 12 n ; previously approved claim amounts (which preferably includes the monetary and percentage, etc., amounts); previously added variation items and amounts; any comments or supporting documents (e.g. photos, documents, etc.) that may have been associated with one or more contract items ' ! 04 n and/or variation/change order items 1 24 n (see, Fig. 8) ; and/or, any supporting compliance documents that may have already been submitted by a user, 14 n , 16n, etc., in connection with the specific contract 12 n .
  • previously approved claim amounts which preferably includes the monetary and percentage, etc., amounts
  • previously added variation items and amounts any comments or supporting documents (e.g. photos, documents, etc.) that may have been associated with one or more contract items ' ! 04 n and/or variation/change order items 1 24 n (see, Fig. 8) ; and/or, any supporting compliance
  • This existing claim(s)/application(s) data is preferably retrieved and/or used by financial data display engine 24 n (and/or any other associated modules or engines 24n, not shown) of network server 20n (or a third party service provider 33n, if desired), of system 10, to calculate, analyse and/or manipulate any necessary data (e.g. financial data) so as to then populate the relevant fields or regions (including the various progress bars 120b, 122e, or other similar visual indicators not shown) of make claim screen 34 shown in Fig. 8.
  • the data necessary for display within make claim screen 34 n may have been prepared in advance by financial data display engine 24 n , i.e. upon a last transaction (e.g.
  • a project 38n or contract 12 n being created, a claim/payment application being made or approved, etc.) being completed, or may be prepared in (substantially) real-time upon, for example, a request being received by system 10 to make a claim (at step 236), and to display make claim screen 34 n .
  • make claim screen 34 n of Fig. 8, has been generated and displayed or otherwise provided to user 16n, etc., in accordance with step 236A, it is preferred that the new claim/application being made is automatically saved as a draft.
  • preferred make claim screen 34 n preferably includes a number of panels, fields, features, buttons or regions, for displaying information/documents associated with the selected contract 1 2 n and for making a claim or payment application in accordance with that contract 1 2 n .
  • make claim screen 34 n preferably includes, but it not limited to: a panel or region 1 20 for displaying consolidated project-to-date claim summary information, which panel 1 20 also preferably includes various fields, buttons or regions for performing various make claim/applications functions in accordance with preferred make claim screen 34 n ; a panel of region 1 1 8 (which may simply be the same as that or panel or region 1 1 8 shown in Fig.
  • a panel or region 1 22 for displaying consolidated project-to-date contract item 1 04 n claim summary information, and for entering new claim information so as to make a new claim/application in accordance with method 236, of Fig. 7; and/or, a panel or region 1 24 for displaying consolidated project-to- date contract variation/change order item(s) 1 24 n claim summary information, and for entering new variation/change order claim information so as to make a new claim/application in accordance with method 236, of Fig. 7.
  • required supporting documentation i.e. compliance documents/information
  • one or more of preferred panels or regions 120, 1 18, 122 and/or 124, of preferred make claim screen 34 n may be selectively collapsed or expanded by system 10, or selectively by a user, e.g. second agent 1 6n, as desired, as part of the process of viewing make claim screen 34n.
  • each of panels/regions 1 18, 122 and 124 may preferably be collapsed/expanded by way of the " ⁇ " buttons or regions 1 18a, 122a, and 124a.
  • each of regions 1 18, 122, 124 may display a brief description of the respective panel/region, e.g.
  • the concise or collapsed compliance documentation panel or region 1 18 preferably also includes clever, preferably colour coded, visual indicators (e.g. colour coded icons, regions, etc., not shown) so that a user 16n, etc., may readily determine (e.g. by way of, for example, selecting or hovering over, using, e.g. a GUI pointing device, pen, finger, etc., one or more of the colour coded icons, etc.) the status (e.g. submitted, missing, expiring soon, not verified, etc.) of the supporting documents to be submitted or otherwise provided in order to make a claim/payment application in accordance with contract
  • preferred panel or region 120 preferably displays consolidated project-to-date claim/payment application summary information for the selected contract 12 n .
  • the summary information preferably includes, but is not limited to: the claim number 120a for the new claim being made; 'approved to date', "amount claimed” and “yet to be claimed” project-to-date consolidated totals for the specific contract 12 n ; and, the completion status of the contract 12 n which is clearly and cleverly displayed by way of, for example, a colour coded progress bar 120b or the like (e.g. a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.).
  • a colour coded progress bar 120b or the like e.g. a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.
  • a blue or first colour region (from left to right) represents the total claim/application amount approved to date, whilst a green or second colour region represents the total claim/application amount now being claimed, and a grey, blank or final colour region represents the amount yet to be claimed by way of a claim or payment application.
  • Preferred panel or region 120 may also include, but is not limited to: a text box or field/region 120c, e.g. a "claim as at” text box or field 120c, which displays the date (e.g. the date of opening/displaying make claim screen 34 n ) applicable to the consolidated claim information shown within make claim screen 34n, and which may selectively be changed (e.g.
  • a drop down menu or pop-up calendar that may appear upon selecting or hovering over, using, e.g. a GUI pointing device, pen or finger, etc., text box or field 120c); a button or region 120d, e.g. an "Attachments" button or region 120d, which may be selected, hovered over, etc., so at to bring up a pop-up window of the like (not shown) for displaying details of any attachments (and for possibly downloading, etc. copies of same) that may have already been associated with contract 12 n , or to submit (e.g.
  • a button or region 120e e.g. a "Draft Claim PDF” button or region 120e, which may be selected, hovered over, etc., so as to generate and download or view a draft claim/compliance document (in accordance with step 236G, of method 236, of Fig. 7 - as will be described below) applicable to the claim/payment application being made; a button or region 120f, e.g. a "Save Draft” button or region 120f, for saving the claim/payment application being made as a draft; and/or, a button or region 120g, e.g.
  • a "Submit Claim" button or region 120g for selectively submitting the claim/application being made for assessment/approval in accordance with the invention.
  • preferred panel or region 1 18 for displaying required supporting documentation i.e. compliance documents/information
  • required supporting documentation i.e. compliance documents/information
  • n is preferably the same as, or similar to, preferred panel/region 1 18 shown in Fig. 6. Accordingly, a detailed discussion of the features and/or operation of preferred panel/region 1 18, of Fig. 8, need not be provided again. Instead, it should be understood that panel 1 18 of Fig. 8, may perform some or all of the aspects/operations, or variations thereof, of panel 1 18 as described above with reference to Fig. 6.
  • preferred panel 1 22 for displaying consolidated project-to-date contract item 1 04 n claim summary information, and for entering new claim information so as to make a new claim/application in accordance with method 236, of Fig. 7, is configured to enable a user, e.g. a second agent 1 6n, to readily view summary information concerning previous claims/applications and to input or add one or more new claim amounts (for one or more contract items 1 04n) as required so as to make a new claim/payment application in connection with the selected contract 1 2 n .
  • a user e.g. a second agent 1 6n
  • each contract item 104 n also includes a number of regions, fields or text boxes for viewing previous claim/application information and for entering new claim/application information.
  • a previously approved automatically calculated amount 122c which when there are more than one contract items 104 n , may also include a consolidated automatically calculated previously approved total 122d; the completion status of the contract item 104 n which is clearly and cleverly displayed by way of, for example, a colour coded progress bar 122e or the like (e.g. a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.) - in the example shown in Fig.
  • a blue or first colour region (from left to right) represents the total claim/application amount approved to date, whilst a green or second colour region represents that total claim/application amount now being claimed, and a grey, blank or final colour region represents the amount yet to be claimed by way of a claim or payment application; a project-to-date percentage and monetary text box 122f for each contract item 104 n , either of which may be selectively altered to input or add new claim/application information so as to make a new claim/application in accordance with method 236, of Fig. 7 (e.g.
  • a user 16n, etc. may readily input/add a new claim amount by varying either the percentage or monetary amounts pre-populated therein, e.g. by changing 25% to say 75%, or by changing $2,500 to $7,500, etc.); a project-to-date automatically calculated claim total 122g, representing the total monetary amount of all of monetary text boxes 122f; and/or, a current claim/application amount text box 122h for each contract item 104 n (which may also be selectively altered to input or add new claim/application information so as to make a new claim/application in accordance with method 236, of Fig.
  • FIG. 8 Also shown in Fig. 8, are regions of conversation icons 122j for each contract item 104 n , which when selected, hovered over, etc., may bring up a pop-up screen or the like (not shown) for reviewing any comments or documents (e.g. photos, etc.) that may have already been added (uploaded, etc.) in connection with a contract item 104 n (e.g.
  • one or more variation/claim order item(s) 124 n may each include a reference 104a, description 104b, when complete amount 104c, and when complete automatically calculated total of all variation/change order items 124i, along with a number of regions, fields or text boxes for viewing previous claim/application variation/claim order information and for entering new claim/application variation/claim order information.
  • regions, fields or text boxes, etc. may include, but are not limited to: a previously approved automatically calculated amount 122c, which when there are more than one variation/change order items 124 n , may also include a consolidated automatically calculated previously approved total 124d; the completion status of the variation/claim order item 1 24n which is clearly and cleverly displayed by way of, for example, a colour coded progress bar 122e or the like (e.g.
  • a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.) - as hereinbefore described with reference to preferred panel/region 122; a project-to-date percentage and monetary text box 122f for each variation/change order item 124 n , either of which may be selectively altered to input or add new claim/application information so as to make a new claim/application in accordance with method 236, of Fig.
  • a project-to-date automatically calculated total 124g representing the total monetary amount of all of variation/change order monetary text boxes 122f; and/or, a current claim/application amount text box 122h for each variation/change order item 124 n (which may be selectively altered to input or add new claim/application information - as hereinbefore described with reference to preferred panel 122), and an associated automatically calculated total 124j for all of current variation/change order claim/application amount text boxes 122h - representing the total amount now being claimed.
  • regions of conversation icons 124k for each variation/change order item 124 n , for viewing or adding comments, documents, etc., as hereinbefore described with reference to preferred panel 122.
  • step 236A of method 236, of Fig. 7, it can be seen that after preferred make claim screen 34 n , of Fig. 8, has been presented to the user, e.g. second agent 1 6n, method 236 may continue at step 236B, whereat user 1 6n, etc., may input/edit new claim information for one or more contract items 104 n , using, e.g. any of text boxes 122f or 122h.
  • user 1 6n, etc. may also selectively add any comments, documents (e.g. photos, etc.), concerning one or more contract items 104 n , as required or desired using, e.g.
  • step 236B After having added/input all required claim/application information concerning contract items 104 n , at step 236B, method 236 may continue at step 236C, whereat the user 1 6n, etc., may selectively choose to edit or input any required variation/change order information, etc.
  • variations/change orders would typically be made by a second or first agent 1 6n, 14 n , depending on access permissions, it will be appreciated that third agents 32 n may also request variations/change orders in some instances.
  • step 236C user 1 6n, etc., (chooses to add/edit variation/change order information, then method 236 may continue at step 236D, whereat user 16n, etc., may input/edit new variation/change order information for one or more variation/change order items 1 24n, using, e.g. any of text boxes 122f or 122h, or may add new variation/change order item(s) 124 n , using, e.g. "Add Variation" button or region 124b.
  • step 236D and as can be seen in Fig. 7, user 16n, etc., may also selectively add any comments, documents (e.g.
  • step 236E user 1 6n may selectively (or may be prompted to) manage using, e.g. preferred panel/region 1 18 of Fig. 8, the required supporting compliance documents that must be submitted in order to make a claim/payment application in accordance with the selected contract 1 2n.
  • user 1 6n may view and add any necessary supporting compliance documents/information (including any related expiry date information, if required in accordance with the contract 12 n - i.e.
  • step 236C, of method 236, should user 1 6n, etc., chooses not to add/edit variation/change order information, then method 236 may continue at step 236E, as hereinbefore described (e.g. user 1 6n, etc., may manage the required supporting compliance documents/information using, e.g. preferred panel/region 1 18, of Fig. 8).
  • step 236F After reviewing, submitting, etc., any/all required supporting compliance documents at step 236E, method 236 may continue at step 236F, whereat a user 1 6n, etc., may selectively choose to view (using, e.g. "Draft Claim PDF" button or region 120e, of Fig. 8) a draft claim document(s) (e.g. a claim document(s) that conform with relevant Security of Payments or similar statutory adjudication legislation) that may be automatically generated in accordance with system 10 of the present invention.
  • a draft claim document(s) e.g. a claim document(s) that conform with relevant Security of Payments or similar statutory adjudication legislation
  • method 236 may continue at step 236G, whereat the required retention/retainage amounts are determined, and thereafter the draft claim document(s) is generated and made available (e.g. viewable in a pop-up window or the likes (not shown), or made available for download, etc.) to user 1 6n, etc. Thereafter, method 236 may continue at step 236H, whereat user 1 6n, etc., may selectively choose whether or not to submit their claim or payment application. Alternatively, and referring back to step 236F, should user 1 6n, etc., choose not to view a draft claim document(s), then method 236 may continue at step 236H (i.e.
  • user 1 6n, etc. may selectively choose whether or not to submit their claim or payment application). If, at step 236H, user 1 6n, etc., chooses not to submit their claim/payment application, then method 236 may return to step 236A (after saving the claim/application as a draft, e.g. using "Save Draft” button or region 120f, of Fig. 8) or may end (not shown) should user 16n, etc., opt to sign or log out of system 10. [01 36] If, at step 236H , a user 1 6n, etc., chooses to submit their claim/payment application using, e.g.
  • method 236 may continue at step 236J , whereat system 1 0 may request any missing required supporting compliance documents/information, and/or then determine the required retention/retainage amounts, before generating any/all claim/compliance document(s).
  • system 1 0 may request any missing required supporting compliance documents/information, and/or then determine the required retention/retainage amounts, before generating any/all claim/compliance document(s).
  • step 236E As is shown in Fig. 7, should any required supporting compliance documents have not been submitted at the "submit claim” stage (e.g. steps 236H , 236J) it is preferred that method 236 continues at step 236E, whereat the user 1 6n, etc., must add/submit any missing documents/information before their claim/payment application can be processed by system 1 0.
  • step 236J If, at step 236J , it is determined that all required supporting compliance documents have been submitted, then after generating the claim/compliance document(s) at step 236J , method 236 may continue at step 236K, whereat it may be determined whether or not the user 1 6n, etc., has integrated, e.g. an external accounting software provider 30n (see, Fig. 1 ) , such as, for example, XeroTM, MYOBTM, QuickbooksTM, Sage OneTM, etc.) with system 1 0, for the purpose of, for example, invoicing and account reconciliations, etc.
  • an external accounting software provider 30n see, Fig. 1
  • XeroTM XeroTM
  • MYOBTM QuickbooksTM
  • Sage OneTM Sage OneTM
  • step 236J if it is determined that the total claim/payment application amount meets or exceeds the percentage of total works previously defined in text box 86, of create contract screen 34 n , of Fig. 5, then at this stage the user 1 6n, etc., may choose to claim Practical Completion, and hence, have a percentage (i.e. the percentage that was defined in text box 88 of create contract screen 34 n , of Fig. 5) of their retention/retainage released upon approval.
  • step 236K If, at step 236K, it is determined that system 1 0 is not integrated with any external accounting software provider(s) 30n, associated with user 1 6n, etc., or if user 1 6n, selectively chooses to skip the accounting software integration step, then method 236 may continue at step 236L, whereat a summary of the claim/application about to be submitted may first be presented to the user 1 6n, etc., for their review/approval, and thereafter (assuming the user 1 6n, etc., does not cancel the submission process) the claim is submitted to system 1 0, along with any supporting documents and/or required supporting compliance documents.
  • a notification e.g. in the form of an e-mail, etc.
  • third party notification service provider(s) 33n such as, for example, MandrillTM, etc.
  • the respondent e.g. first agent 14 n
  • third party notification service provider(s) 33n such as, for example, MandrillTM, etc.
  • the respondent e.g. first agent 14 n
  • no attachments need be sent with the notification sent to first agent 1 4n, etc., as all documents will be readily available to first agent 14 n , etc., upon logging into system 10.
  • links, etc., to the necessary documents, etc. could be supplied as part of the notification. Thereafter, method 236 may end, as shown.
  • step 236K it is determined that system 1 0 is integrated with an external accounting software provider(s) 30n, associated with user 1 6n, etc., or if user 1 6n, selectively chooses to integrate system 1 0 with an external accounting software provider 30n, then method 236 may continue at step 236M, whereat depending on whether or not the user 16n, etc., has chosen (or now selects) to generate an accounting software invoice at the claim/payment application stage (the selection of which may be set when, for example, setting up or enabling integration of external accounting software provider 30n with system 1 0), method 236 may either continue at step 236L (whereat, if accounting invoices are not to be generated at the claim stage, the claim/payment application is submitted/processed and thereafter a notification is generated and sent to the respondent 14 n , etc.) as hereinbefore described, or at step 236N, whereat system 1 0 may exchange necessary information and instructions with the integrated external accounting software provider 30n so as to automatically
  • step 236N user 1 6n, etc., may choose to view the accounting invoice (not shown) by way of, for example, a button or region (not shown) provided within make claim screen 34 n , of Fig. 8, etc. Thereafter, method 236 may continue at step 236L, as before, but may also submit/process the accounting invoice as part of that step (236L). Similarly, upon generating the invoice using external accounting software provider 30n, system 1 0 may automatically attach a copy of the system 1 0 generated claim/compliance document to the invoice (or an associated file location) within the external accounting software 30n, etc. Method 236 may then end, as discussed previously.
  • an external accounting software provider 30n may be enabled, facilitated and/or granted, by way of, e.g. the "Add-On" facility or page(s) (not shown) previously described with reference to dashboard screen 34 n , of Fig. 3.
  • the process of integrating system 10 with an external accounting software or other software provider 30n would include a user, e.g. 1 6n, granting access rights to system 10 (and/or, external software provider(s) 30n) so as to enable data to be shared between system 10 and external software provider(s) 30n.
  • an external accounting software provider 30n may be required to nominate, e.g. a specific company, accounting codes, payment terms, etc. (e.g. one or more accounting sales or other revenue codes, retention/retainage code(s), etc.), that are to be used when an invoice is automatically generated by way of integration with system 1 0.
  • nominate e.g. a specific company, accounting codes, payment terms, etc. (e.g. one or more accounting sales or other revenue codes, retention/retainage code(s), etc.)
  • accounting codes, payment terms, etc. e.g. one or more accounting sales or other revenue codes, retention/retainage code(s), etc.
  • “Add-On" facility or page accessibly to user 1 6n, etc., by way of one or more preferred GUI screens 34 n , the user 1 6n, etc., may be required to nominate whether or not they wish to have invoices generated at the claim or approval stage.
  • a user e.g. second agent 1 6n
  • their external accounting software provider 30n as part of (for example) step 236N, of method 236, accounting tasks and/or reconciliations for that user 1 6n, etc., will be significantly streamlined/improved.
  • Fig. 9 there is shown a flow diagram which illustrates a preferred method 238 for assessing and/or approving claims or payment applications in accordance with step 238, of method 200, of Fig. 2.
  • the preferred process of assessing and/or approving claims or payment application in accordance with method 238 preferably commences at step 238A, whereat the user, e.g. a first, second or third 14 n , 1 6n, 32 n (e.g.
  • a first agent 14 n in his/her capacity as a respondent, a second agent 1 6n if using system 10 in its self-assess or stand-alone mode, and/or a third agent 32 n if granted access rights to assess (and possibly approve) claims or payment applications in accordance with system 1 0) is presented with, or arrives at, a GUI "assess or approve claim or payment application" page(s) or screen(s) 34 n (hereinafter simply referred to as "assess claim screen 34 n "), by way of their user terminal(s) 28n.
  • An exemplary GUI screen- shot 34n of a preferred assess claim screen 34 n is shown in Fig.
  • step 238A shown in Fig. 9, if any existing claim(s)/application(s) have been made against the selected contract 1 2 n , then details pertaining to the existing claim(s)/application(s) are retrieved by system 1 0, and used to generate the display of information shown within assess claim screen 34n.
  • the existing claim(s)/application(s) details preferably include, but are not limited to: the last claim/application number made against the contract 1 2 n ; previously approved claim amounts (which preferably includes the monetary and percentage, etc., amounts); previously added variation items and amounts; any comments or supporting documents (e.g. photos, documents, etc.) that may have been associated with one or more contract items 1 04 n and/or variation/retainage items 1 24 n ; and/or, any supporting compliance documents that may have already been submitted by a user, 1 4 n , 1 6n, etc., in connection with the specific contract 1 2n.
  • previously approved claim amounts which preferably includes the monetary and percentage, etc., amounts
  • previously added variation items and amounts any comments or supporting documents (e.g. photos, documents, etc.) that may have been associated with one or more contract items 1 04 n and/or variation/retainage items 1 24 n ; and/or, any supporting compliance documents that may have already been submitted by a user, 1 4
  • This existing claim(s)/application(s) data is preferably retrieved and/or used by financial data display engine 24 n (and/or any other associated modules or engines 24 n , not shown) of network server 20n (or a third party service provider 33n, if desired), of system 1 0, to calculate, analyse and/or manipulate any necessary data (e.g. financial data) so as to then populate the relevant fields or regions (including the various progress bars 1 20b, 122e, or other similar visual indicator not shown) of assess claim screen 34 n shown in Fig. 1 0.
  • the data necessary for display within assess claim screen 34 n may have been prepared in advance by financial data display engine 24 n , i.e. upon a last transaction (e.g.
  • a project 38n or contract 1 2n being created, a claim/payment application being made or approved, etc.) being completed, or may be prepared in (substantially) real-time upon, for example, a request being received by system 1 0 to assess/approve a claim (at step 238), and to display assess claim screen 34 n .
  • a request being received by system 1 0 to assess/approve a claim (at step 238), and to display assess claim screen 34 n .
  • preferred assess claim screen 34 n preferably includes a number of panels, fields, features, buttons or regions, for displaying information/documents associated with the selected contract 12 n and for assessing/approving a claim or payment application in accordance with that contract 12 n .
  • assess claim screen 34 n preferably includes, but it not limited to: a panel or region 120 for displaying consolidated project-to-date claim summary information, which panel 120 also preferably includes various fields, buttons or regions for performing various make claim/applications functions in accordance with preferred assess claim screen 34 n ; a panel of region 1 18 (which may simply be the same as that or panel or region 1 18 shown in Figs.
  • a panel or region 122 for displaying consolidated project-to-date contract item 104 n claim summary information, and for editing any necessary claim or payment application information so as to assess and approve a claim in accordance with method 238, of Fig. 9; and/or, a panel or region 124 for displaying consolidated project-to-date contract variation/change order item(s) 124 n claim summary information, and for editing any necessary variation/change order claim information so as to assess and approve a claim/application in accordance with method 238, of Fig. 9. [0143] Although not shown in Fig.
  • one or more of preferred panels or regions 120, 1 18, 122 and/or 124, of preferred assess claim screen 34 n may be selectively collapsed or expanded by system 10, or selectively by a user (e.g. by way of the " ⁇ " buttons or regions 1 18a, 122a, 124a, etc.), e.g. first agent 1 6n, as desired, as part of the process of assessing and/or approving claims or payment applications by way of assess claim screen 34 n .
  • each of panels/regions 1 18, 122, 124 may display a brief description of the respective panel/region, e.g.
  • colour coded icons, regions, etc., not shown so that a user 14n, etc., may readily determine (e.g. by way of, for example, selecting or hovering over, using, e.g. a GUI pointing device, pen, finger, etc., one or more of the colour coded icons, etc.) the status (e.g. submitted, missing, expiring soon, not verified, etc.) of the supporting documents to that have been submitted or otherwise provided with the claim or payment application being assess/approved in accordance with assess claim screen 34 n .
  • the status e.g. submitted, missing, expiring soon, not verified, etc.
  • preferred panel or region 120 preferably displays consolidated project-to-date claim/payment application summary information for the selected contract 12 n .
  • the summary information preferably includes, but is not limited to: the claim number 120a for the claim being assessed/approved; 'approved to date', "amount approved", “difference to claimed” (i.e. approved more or less than was claimed), and "yet to be approved” project-to- date consolidated totals for the specific contract 12 n ; and, the completion status of the contract 12 n which may clearly and cleverly be displayed by way of, for example, a colour coded progress bar 120b or the like (e.g.
  • a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.), as hereinbefore described.
  • a blue or first colour region represents the total claim/application amount approved to date
  • a green or second colour region represents the total claim/application amount now being assessed
  • a red or third colour region represents the amount disapproved by the user 1 4n, etc. (and hence, the difference to what was claimed by the claimant, e.g. second agent 1 6n, as part of a subsequent claim or payment application)
  • a grey, blank or final colour region represents the amount yet to be approved by the user 1 4n (i.e. the respondent).
  • Preferred panel or region 120 may also include, but is not limited to: a field/region 120c, e.g. a "claim as at” field/region 120c, which displays the date applicable to the claim or payment application being assessed/approved within assess claim screen 34 n ; a button or region 120d, e.g. an "Attachments" button or region 120d, which may be selected, hovered over, etc., so at to bring up a pop-up window of the like (not shown) for displaying details of any attachments (and for possibly downloading, etc. copies of same) that may have already been associated with contract 12 n , or to submit (e.g.
  • a button or region 120h e.g. a "View Claim PDF” button or region 120h, that may be selected, hovered over, etc., so as to download and/or view the system 10 generated claim/compliance document for the claim or payment application being assessed/approved
  • a button or region 120i e.g. a "Draft Payment Schedule PDF” button or region 120i, which may be selected, hovered over, etc., so as to generate and download or view a draft payment schedule/compliance document (in accordance with step 238G, of method 238, of Fig.
  • a button or region 120f e.g. a "Save Draft” button or region 120f, for saving the claim/payment application being assessed/approved as a draft
  • a button or region 120j e.g. an "Approve Claim” button or region 120j, for selectively approving the claim or payment application being assessed in accordance with the invention.
  • preferred panel or region 1 18 for displaying required supporting documentation i.e. compliance documents/information
  • required supporting documentation i.e. compliance documents/information
  • a detailed discussion of the features and/or operation of preferred panel/region 1 18, of Fig. 10 need not be provided again. Having said that, in this instance, i.e. for assessing and/or approving claims or payment applications using preferred assess claim screen 34 n , of Fig.
  • the user 14 n , etc. is preferably not required to submit any supporting compliance documents, but instead is required to review and verify each document and associated information, e.g. document expiry dates, etc., so as to ensure compliance with relevant Security of Payments or similar statutory adjudication legislation. That is, although not shown in Fig. 10, user 14 n , etc., is preferably required to open, download, etc., each document submitted (by, e.g. user 1 6n) by way of preferred panel/region 1 18, and then review each document and associated details (e.g. expiry date information, etc.) to check whether the documents/information provided is accurate and/or complies with the contract 12 n and/or relevant Security of Payments or similar statutory adjudication legislation. Upon reviewing each document, user 14 n , etc., may be presented with a pop-up screen or the like (not shown), which may include a check-box, or other such facility, for confirming that the document/information has been verified.
  • a pop-up screen or the like
  • preferred panel 122 for displaying consolidated project-to-date contract item claim summary information, and for editing any necessary claim or payment application information so as to assess and approve a claim in accordance with method 238, of Fig. 9, is configured to enable a user, e.g. a first agent 14 n , to readily view summary information concerning previous claims/applications and the current claim/application information, and to edit one or more claim amounts (for one or more contract items 104 n ) as required so as to assess or approve the claim/payment application in connection with the selected contract 12 n .
  • a user e.g. a first agent 14 n
  • one or more claim amounts for one or more contract items 104 n
  • the various contract items 104 n (again, arranged in sections in this example, with section headings, and subsection contract items 104 n ), in addition to including: their reference 104a, description 104b; when complete amounts 104c; when complete automatically calculated total of all contract items 104i; previously approved automatically calculated amounts 122c; previously approved automatically calculated total of all previously approved amounts 122d; the completion status of the contract item 104 n - which may be clearly and cleverly displayed by way of, for example, colour coded progress bar(s) 122e or the like (e.g. a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator(s), etc.) - in the example shown in Fig.
  • colour coded progress bar(s) 122e or the like e.g. a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator(s), etc.
  • a blue or first colour region (from left to right) represents the total claim/application amount approved to date, a green or second colour region represents that total claim/application amount now being assessed/approved, a red or third colour region represents the amount disapproved by the user 14 n , etc. (and hence, the difference to be claimed by the claimant, e.g. second agent 16n, as part of a subsequent claim or payment application), a grey, blank or final colour region represents the amount yet to be approved by the user 14 n (i.e.
  • a GUI pointing device by way of a GUI pointing device, pen or finger, etc.
  • a pop-up menu or screen now shown
  • a drop-down menu or the like not shown
  • a reason for e.g. disapproving or altering a claim or payment application (e.g. actual completion less than claimed, quality of works not to agreed standard, other, etc.)
  • a text box or field for entering any associated description/comments.
  • Modification Reasons fields or text boxes 122k, preferably being compulsory in instances where a user 14 n , etc., disapproves or alters a claim or payment application amount, so as to comply with relevant Security of Payments or similar statutory adjudication legislation.
  • preferred panel 124 for displaying consolidated project-to-date contract variation/change order item(s) 124n (again, here shown in its "lump sum” format, but which could be shown in a "schedule of rates” format, as previously described with reference to drop-down menu 104j, of create contract screen 34 n , of Fig. 5) claim summary information, and for editing any necessary variation/change order claim information so as to assess and approve a claim/application in accordance with method 238, of Fig. 9, is configured to enable a user, e.g.
  • a first agent 14 n to readily view summary information concerning previous variations/claim orders and to edit one or more variations/claim orders as required so as to assess and/or approve a claim/payment application in connection with the selected contract 12 n .
  • the preferred assess claim screen 34 n shown in Fig. 10 like in the case of each contract items 104 n described above in connection with preferred panel/region 122, of Fig.
  • a progress wheel (not shown), or some other form of, preferably colour coded, visual indicator, etc.) - as hereinbefore described with reference to preferred panel/region 122; project-to-date percentage and monetary text box 122f (either of which may be selectively altered as part of the process of assessing/approving a claim/application in accordance with method 238, of Fig.
  • each variation/change order item 124 n also includes an additional field or text box 122k, e.g. a "Modification Reason" field or text box 122k, which when selected, hovered over, etc. (e.g. by way of a GUI pointing device, pen or finger, etc.), preferably brings a pop-up menu or screen (now shown), which preferably includes a drop-down menu or the like (not shown) for selecting a reason, e.g. for disapproving or altering a claim or payment application (e.g.
  • step 238A of method 238, of Fig. 9, it can be seen that after preferred assess claim screen 34 n , of Fig. 1 0, has been presented to the user, e.g. first agent 14 n , method 238 may continue at step 238B, whereat user 14 n , etc., may review and then edit or modify (if necessary) the current claim information (submitted by second agent 1 6n, etc.) for one or more contract items 1 04 n , using, e.g. either of text boxes 122f.
  • the first agent 1 4 n may simply alter either the percentage or monetary amounts, etc., pre-populated and provided within text boxes 122f. For example, and as shown in Fig.
  • user 14 n may also selectively add any reasons, comments, documents (e.g. photos, etc.), concerning one or more contract items 104 n , as required or desired using, e.g. any of regions or conversation icons 122j, etc. (as was described above with reference to panels/regions 122 & 124, of Figs. 8 & 10).
  • the first agent 14 n upon a first agent 14 n making a change to a claim or payment application submitted by a second agent 16n, etc., that the first agent 14 n must at least provide a reason for the change (i.e. a reason for not approving the claimed amount in part, or in full).
  • the region or conversation icon 122j associated with the contract item 104 n is displayed as a dark (or otherwise highlighted) icon 122j, and includes a red or other coloured circle (preferably with a number displayed therein, representing, e.g. the number of attachments submitted in connection therewith), which indicates that reasons/comments for modifying the claimed amount have been added for that contract item 104 n , and at least one attachment (e.g. a photo of a defect, etc.) has been submitted as evidence, etc., so as to show or explain why the claimed amount was modified, etc.
  • a red or other coloured circle preferably with a number displayed therein, representing, e.g. the number of attachments submitted in connection therewith
  • method 238 may continue at step 238C, whereat the user 14 n , etc., may selectively choose to view and/or modify required variation/change order information, etc., if any exists, and/or may selectively choose to add one or more required variations/change order items 124n.
  • step 238C If it is determined at step 238C, that variations/change orders are part of the claim or payment application being assessed/approved, and/or if user 14 n , etc., wishes to add a variation/change order, then method 238 may continue at step 238D, whereat user 14 n , etc., may review and then edit or modify (if necessary) the current variation/change order claim information (submitted by second agent 16n, etc.) for one or more variation/change order items 124 n , using, e.g. either of text boxes 122f, and/or may add variation/change order items 124 n to the payment/claim application, and may then submit or otherwise (using, e.g.
  • region(s) or conversation icon(s) 124j, etc. provide any reasons, comments and/or supporting documents (e.g. photos, etc.) as required/desired, as described above with reference to contract items 104 n , of preferred panel/region 122, of Fig. 10.
  • user 14 n , etc. did not approve of the (in this example, single) variation/change order item 124 n amount submitted by second agent 1 6n, etc., and hence has changed the claimed amount, and also added a reason/comments (as, for example, is indicated by way of the single (in this example) progress bar 122e, and the dark region or conversation icon 124k).
  • method 238 may continue at step 238E, whereat user 14 n may selectively (or may be prompted to) manage using, e.g. preferred panel/region 1 18 of Fig. 10, the required supporting compliance documents that have been submitted by user 1 6n, etc., as part of their claim or payment application lodged in connection with the selected contract 12 n .
  • user 1 4n may review each document and associated details (e.g. expiry date information, etc.) to check whether the documents/information provided are accurate and/or comply with the contract 12 n and/or relevant Security of Payments or similar statutory adjudication legislation. Upon reviewing each document, user 1 4n, etc., may then (using, e.g. a pop-up screen or the like (not shown), which may include a check-box, or other such facility) confirm that the documents/information has/have been verified.
  • a pop-up screen or the like not shown, which may include a check-box, or other such facility
  • step 238C, of method 2308 should no variation/change order item(s) 124 n exist in connection with the claim/application being assessed/approved, or should user 14 n , chooses not to add or modify any variation/change order information, then method 238 may continue at step 238E, as hereinbefore described (e.g. user 14 n , etc., may manage the required supporting compliance documents/information using, e.g. preferred panel/region 1 18, of Fig. 8).
  • step 238F After reviewing and verifying, etc., any/all required supporting compliance documents at step 238E, method 238 may continue at step 238F, whereat a user 14 n , etc., may selectively choose to view (using, e.g. "Draft Payment Schedule PDF" button or region 120i, of Fig. 10) a draft Payment Schedule document(s) (e.g. a payment schedule document that conforms with relevant Security of Payments or similar statutory adjudication legislation) that may be automatically generated in accordance with system 10 of the present invention.
  • a draft Payment Schedule document(s) e.g. a payment schedule document that conforms with relevant Security of Payments or similar statutory adjudication legislation
  • method 238 may continue at step 238G, whereat the required retention/retainage amounts are determined, and thereafter the draft payment schedule document(s) is generated and made available (e.g. viewable in a pop-up window or the likes (not shown), or made available for download, etc.) to user 14 n , etc. Thereafter, method 238 may continue at step 238H, whereat user 14 n , etc., may selectively choose whether or not to approve the claim or payment application (as modified, or as submitted by second agent 1 6n, e.g. should first agent 14 n approve of all claimed amounts as submitted by second user 16n) .
  • step 238F should user 14 n , etc., choose not to view a draft payment schedule document(s), then method 238 may continue at step 238H (i.e. user 14 n , etc., may selectively choose whether or not to approve the claim or payment application). If, at step 238H, user 14 n , etc., chooses not to approve the claim/payment application, then method 238 may return to step 238A (after saving the assessed claim/application as a draft, e.g. using "Save Draft" button or region 120f, of Fig. 10) or may end (not shown) should user 14 n , etc., opt to sign or log out of system 10.
  • step 238H i.e. user 14 n , etc., may selectively choose whether or not to approve the claim or payment application. If, at step 238H, user 14 n , etc., chooses not to approve the claim/payment application, then method 238 may return to step 238A (after saving the assessed claim/application as a draft,
  • step 238H a user 14 n , etc., chooses to approve the claim/payment application using, e.g. "Approve Claim" button or region 120j (of Fig. 10)
  • method 238 may continue at step 238J, whereat system 10 may request that user 14 n review and verify any previously unverified supporting compliance documents/information, and/or then determine the required retention/retainage amounts, before generating any/all payment schedule (compliance document(s)) and a Recipient Created Tax Invoice (RCTI) should the creation of RCTI's have been enabled by user 14 n , etc., by way of, for example, check-box 98 of preferred create contract screen 34 n , of Fig. 5.
  • RCTI Recipient Created Tax Invoice
  • system 10 may check to see whether any/all variations/change order item(s) 124 n information included within the claim/payment application to be approved, is/are linked or reconciled to/with, for example, an external ERP software provider 30n (such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.). That is, when a claim/payment application is submitted for approval, using, e.g. "Approve Claim" button or region 120j of assess claim screen 34 n , of Fig.
  • an external ERP software provider 30n such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.
  • a check may be made to see if, for example, the variation/change order item(s) 124 n , reference numbers 104a, etc., exist within ERP software system 30n, etc. If it is determined that the variation/change order reference numbers 104a, etc., do not exist within ERP system 30n, etc., and integration with ERP software system 30n is crucial or important, then it is preferred that the approved claim/payment application may not be submitted/processed by system 10 until such time that the variation/change order item(s) 1 24 n reference numbers, etc., are reconciled or synchronised with ERP software system 30n, etc.
  • This preferred reconciliation/synchronisation step may be facilitated by way of a "Sync Variations" button or region (not shown) provided within, for example, assess claim screen 34 n , of Fig. 10, such that upon selecting, hovering over, etc., that "Sync Variations" button or region, system 10 may exchange data with external ERP software provider (i.e.
  • ERP variation/change order information may readily retrieve existing ERP variation/change order information so as to display (in the form of a pop-up window, or the like (not shown)), the ERP variation/change order information simultaneously with system 10 variation/change order information, with any unsyncronised variation/change order information highlighted, so that a user 14n, etc., may then, for example, synchronise the system 10 variation/change order information with the necessary ERP software system 30n variation/change order information (this process may also include importing new variation/change order items 1 24n into contract 1 2 n , for future use, as required/desired).
  • access to, or integration with, the ERP software provider 30n, etc. may be enabled, facilitated and/or granted, by way of, e.g.
  • step 238E whereat the user 14 n , etc., must review and verify any documents/information that have not been previously verified, before the claim/payment application can be approved and processed by system 10. If, at step 238J, it is determined that all required supporting compliance documents have been verified, then after generating the Payment Schedule (compliance document(s)), RCTI (if enabled), and synchronising any required variation/change order information with, e.g.
  • step 238J method 238 may continue at step 238K, whereat it may be determined whether or not the user 14 n , 1 6n, etc., has integrated system 10 with any external software provider(s) 30n, such as, for example, an external accounting software provider 30n, e.g. XeroTM, MYOBTM, QuickbooksTM, Sage OneTM, etc., or an external ERP software provider 30n, e.g. ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc., for the purpose of, for example, invoicing, account reconciliations, exporting approval data to an ERP system, etc. Also, at step 238J, if it is determined that the claimant, e.g.
  • second agent 1 6n has claimed for Practical or Final Completion, and hence, has requested that his/her/their retention/retainage funds be released, then at this stage the respondent, e.g. first agent 14 n , may preferably be prompted to authorise or otherwise the release of those retention/retainage funds. If at this point the respondent, e.g. first agent 14 n , declines to release the retention/retainage funds, then it is also preferred that the first agent 14n must provide a reason as to why the funds are not being released. Retention/retainage funds will be released (or not) accordingly.
  • step 238K If, at step 238K, it is determined that system 10 is not integrated with any external software provider(s) 30n, associated with user 1 4 n , 1 6n, etc., or if user 1 4n, 1 6n, selectively chooses to skip the external software integration step, then method 238 may continue at step 238L, whereat a summary of the claim/application about to be submitted for approval may first be presented to the user 1 4 n , 1 6n, etc., for their review/approval, and thereafter (assuming the user 1 4 n , 1 6n, etc., does not cancel the submission process) the claim is submitted and approved by system 10 (which process includes submitting or generating any supporting documents and/or required supporting compliance documents).
  • a notification e.g.
  • a notification (e.g. in the form of an e-mail, etc.), may also be sent to other agents, e.g. a third agent 32n, at step 238L, should that agent(s) 32 n have authorisation to receive/review such information.
  • step 238K it is determined that system 10 is integrated with an external software provider(s) 30n, associated with user 14 n , 1 6n, etc., or if user 14 n , 1 6n, etc., selectively chooses to integrate system 10 with an external software provider 30n, then method 238 may continue at step 238M, whereat one or more preferred integration processes may occur as will now be described.
  • method 238 may either continue at step 238L (whereat, if accounting invoices are not to be generated at the approval stage, the claim/payment application is submitted/processed for approval, and thereafter a notification is generated and sent to the claimant 1 6n, etc.) as hereinbefore described, or at step 238N, whereat system 10 may exchange necessary information and instructions with the integrated external accounting software provider 30n so as to automatically generate an accounting invoice for user 1 6n, etc.
  • step 238N (or after receiving a notification of approval of their claim/payment application), user 14 n , 1 6n, etc., may choose to view the accounting invoice (not shown) by way of, for example, the notification informing them of the approval of their claim/application, and/or a button or region (not shown) provided within assess claim screen 34 n , of Fig. 10, etc. Thereafter, method 238 may continue at step 238L, as before, but may also submit/process the accounting invoice as part of that step (238L). Similarly, upon generating the invoice using external accounting software provider 30n, system 10 may automatically attach a copy of the system 10 generated Payment Schedule (e.g. the payment schedule compliance document) to the invoice (or an associated file location) within the external accounting software 30n, etc. Method 238 may then end, as discussed previously.
  • the system 10 generated Payment Schedule e.g. the payment schedule compliance document
  • step 238M Alternatively, or in conjunction with the preferred integration with external accounting software provider 30n, at steps 238M & 238N, should system 10 be integrated with a user's 14 n , etc., external ERP service provider 30n, such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc., then at step 238M, of method 238 (and preferably in addition to the preferred ERP synchronisation processes previously described with reference to step 238J), depending on whether or not the user 14 n , etc., is required or desires to export claim/payment application approval information, e.g.
  • external ERP service provider 30n such as, for example, ViewpointTM, JobpacTM, Sage 300 Construction and Real EstateTM, and, COINSTM, etc.
  • method 238 may either continue at step 238L, whereat, if it is not required or desired to export claim/payment application approval data to ERP software provider 30n, no such data is sent to ERP software provider 30n, and instead the claim/payment application is submitted/processed for approval, and thereafter a notification is generated and sent to the claimant 1 6n, etc., as hereinbefore described, or at step 238N , whereat system 1 0 may exchange/export/sync the necessary information/data with ERP software provider 30n so as to ensure that ERP software provider 30n is aware of, or receives, the new claim/payment application approval information. Thereafter, method 238 may continue at step 238L, as hereinbefore described. Method 238 may then end, as discussed previously.
  • a user e.g. second agent 1 6n
  • their external accounting software provider 30n as part of (for example) step 238N , of method 238, accounting tasks and/or reconciliations for that user 1 6n, etc., will be significantly streamlined/improved.
  • the user 1 4 n may be presented with a further project GUI screen or page (not shown), which only shows the concise details of contracts 1 2 n having pending claims/applications, and which may include check-boxes or the like (not shown), for selecting two or more contracts 1 2 n with pending claims, and an approve button or region (not shown) for bulking approving the selected claims/applications.
  • system 1 0 may provide one or more varying GUI page(s) or screen(s) (not shown) for access by third agents 32 n .
  • third agents 32 n may be, for example, owner-agents, or some other person with an interest or authority over a particular project 38n or contract 1 2 n .
  • GUI page(s) or screen(s) may only display and/or otherwise provide a limited amount of information to third agents 32 n , and/or may display and/or otherwise provide the same information as that presented to one or more of a first or second agent 1 4 n , 1 6n.
  • approval of claims/payment applications made in accordance with system 1 0 of the present invention may require assessment/approval by multiple agents, e.g. a first agent 1 4 n and one or more third agents 32 n , etc.
  • Such a "multi-stage approval" requirement may be defined or set as part of the process of creating a new project 38n, by way of, for example, a create new project GUI screen(s) (not shown). If multi-stage approval is set as a requirement for a project 38n, then all contracts 1 2 n created under that project 38n, will require assessment and approval by those agents 1 4 n , 32 n , etc., that are defined as having to be part of the multistage approval process.
  • the present invention therefore provides novel and useful systems and/or methods for managing contracts associated with construction projects.
  • Many advantages of the present invention will be apparent from the detailed description of the preferred embodiments provided hereinbefore. Examples of those advantages include, but are not limited to: the ability to manage contracts both collaboratively or in a self-assess/stand-alone mode; the ability to integrate with external software systems or providers so as to streamline processes, assure compliance, etc.; the ability to share documents/information between parties involved in a project in real time so that all parties have a single view of the status of a project or contract, meaning there are no surprises, which will likely lead to fewer disputes, etc.; the ability to enable supporting documentation/information (including, e.g.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Development Economics (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un système et un procédé de gestion de paiements de projet/contrat entre un premier agent et un second agent : comprenant un serveur de réseau destiné à stocker des informations de contrat et un terminal utilisateur associé à chacun des agents, afin de créer/éditer les informations de contrat. Les informations de contrat comprennent au moins une entité formant article de contrat représentant un article de contrat pour un bien/un service fourni par le second agent, chaque entité formant article de contrat comprenant une valeur représentant une première valeur monétaire de l'article de contrat convenu entre les deux agents ; une valeur à l'achèvement de l'article de contrat que le second agent déclare avoir achevé ; une valeur de créance représentant une seconde valeur monétaire que réclame le second agent en guise de règlement, laquelle dépend de la valeur de l'article et de la valeur à l'achèvement ; ainsi qu'une valeur à l'approbation approuvée par le premier agent pour le paiement au second agent, laquelle est située entre 0 % et 100 % de la valeur de créance.
EP15911658.1A 2015-12-30 2015-12-30 Système et procédé de gestion de contrats de projet Withdrawn EP3398129A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/AU2015/050851 WO2017112975A1 (fr) 2015-12-30 2015-12-30 Système et procédé de gestion de contrats de projet

Publications (1)

Publication Number Publication Date
EP3398129A1 true EP3398129A1 (fr) 2018-11-07

Family

ID=59224006

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15911658.1A Withdrawn EP3398129A1 (fr) 2015-12-30 2015-12-30 Système et procédé de gestion de contrats de projet

Country Status (3)

Country Link
EP (1) EP3398129A1 (fr)
CA (1) CA3009941A1 (fr)
WO (1) WO2017112975A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11443326B2 (en) * 2019-06-05 2022-09-13 International Business Machines Corporation Geo-location compliance

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002044863A2 (fr) * 2000-12-01 2002-06-06 James Conlow Presentation efficiente et paiement de factures
US8306883B2 (en) * 2007-04-30 2012-11-06 Textura Corporation Construction payment management systems and methods with specified billing features
US20140297468A1 (en) * 2013-03-27 2014-10-02 Fraser Patterson Consumer Contractor Connector Apparatuses, Methods and Systems

Also Published As

Publication number Publication date
WO2017112975A1 (fr) 2017-07-06
WO2017112975A9 (fr) 2018-07-12
CA3009941A1 (fr) 2017-07-06

Similar Documents

Publication Publication Date Title
US20170193412A1 (en) System and method for project contract management
AU2007201268B2 (en) Construction payment management system and method with document tracking features
US7899739B2 (en) Construction payment management system and method with real-time draw notification features
US20080288379A1 (en) Construction payment management system and method with automated electronic document generation features
KR102197286B1 (ko) 거래업체별 인력 배치, 급여 정산 및 비용 정산을 위한 자동화 서비스 제공 시스템
AU2024219479A1 (en) System and Method for Project Contract Management
CN102122373A (zh) 基于网络的实施门户网站的自动化系统和方法
US20150006393A1 (en) Accelerated payment system for construction projects
US20140095400A1 (en) Mobile Application for a Vendor Management System
US20190318276A1 (en) Automated Booking System
US20100287092A1 (en) Method and system for real estate loan administration
EP3398129A1 (fr) Système et procédé de gestion de contrats de projet
US20130144677A1 (en) Workflow automation system and method for construction industry
CN101042759B (zh) 具有文档跟踪特性的施工支付管理系统及方法
US20140207706A1 (en) Computer Implemented System and Method for Aggregating, Analyzing and Distributing Information Corresponding to Retirement Plans
Board Nunavut Water Board
KR20220120780A (ko) 인테리어 공정에 대한 관리방법
JP2016033740A (ja) 工事管理システム
AU2014200162B2 (en) Construction payment management system and method with document tracking features
AU2012207008B2 (en) Construction payment management system and method with document tracking features
AU2016200117A1 (en) Construction Payment Management System and Method with Document Tracking Features

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20180711

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190702