CN107408232B - 变化管理 - Google Patents

Abstract

呈现了系统和方法，通过该系统和方法，承包商可以发起对于工程合同的提议的变化并且甚至在该变化由工程合同的另一方批准之前针对提议的变化请求支付。当提议的变化被审查、批准和升高成为工程的实际预算的部分时，生成并且维护代表提议的变化的数据结构。因为贯穿整个过程以及在提议的变化被批准之后维护相同的数据结构，所以在提议的变化被批准之前针对该数据结构而采取的支付请求、支付以及任何其他动作在批准之后被自动地链接到实际预算，并且由此由外部记账系统辨识和处理，好像这些变化是由合同的另一方创建的一样。

Description

变化管理

背景技术

本公开涉及用于跟踪和管理预算的系统和方法。具体而言，本文描述的系统处理并且跟踪建设工程的已建立预算的变化，并且相应地控制发票开具(invoicing)和支付处理。

发明内容

提供实施改进的电子过程的系统和方法，通过该系统和方法，承包商可以发起对于工程合同的提议的变化，并且甚至在该变化由工程合同的另一方批准之前针对该提议的变化请求支付。在一些实现方案中，通过实现由承包商生成的提议的变化与由另一方生成的经评估的变化之间的电子匹配过程，改进的电子过程允许承包商在变化被批准之前接收支付。当提议的变化被审查、批准和升高成为工程的实际预算的部分(例如，作为新的合同组分)时，生成并且维护代表提议的变化的数据结构。因为在贯穿整个过程以及在提议的变化被批准之后维护相同的数据结构，所以在提议的变化被批准之前针对该数据结构而采取的支付请求、支付以及任何其他动作在批准之后自动地链接到实际预算，并且由此由外部记账系统辨识和处理，好像这些变化是由合同的另一方创建的一样。

在一个实施例中，提供用于处理承包商和第二方之间的建设工程合同的变化的方法，其中该建设工程合同针对要由承包商为第二方在建设工程上执行的工作。在一些实施例中，第二方是建设工程的总承包商，并且承包商是由该总承包商雇佣的分包商。请求对象数据结构由基于计算机的系统响应于接收到由承包商发起的对建设工程合同的提议的变化而生成。请求对象包括第一新合同组分项目，并且在一些实施例中，请求对象包括多个新合同组分项目。请求对象的第一新合同组分项目包括识别第一新合同组分项目的项目ID的项目ID字段、识别合同预算数据结构中用于新合同组分的存储位置的目标字段、以及识别新合同组分的提议值的提议值字段。请求对象存储在基于计算机的系统的非临时性计算机可读存储器上，并且副本被传输到与第二方(例如，总承包商)相关联的外部系统。然后系统从外部系统接收指示建设工程合同的经评估的变化的响应对象。与请求对象类似，响应对象包括第一新合同组分项目并且有可能包括多个新合同组分项目。响应对象的第一新合同组分项目包括目标字段以及识别新合同行项目的批准值的批准值字段。匹配指令将请求对象和响应对象二者都识别为对应于由承包商发起的同一提议的变化，并且响应对象的第一新合同组分项目的目标字段被自动地更新为包括对应请求对象的第一新合同组分项目的项目ID。然后合同预算数据结构被更新，以在由请求对象的第一新合同组分项目的目标字段识别的存储位置处包括该新合同行项目。基于来自响应对象的批准值来定义与该新合同行项目相关联的成本值。

在一些这样的实施例中，经评估的变化可以包括经批准的变化或者未经批准的变化。经批准的变化成为经批准的合同预算的部分，并且第二方可以以承包商所提议的值来批准变化、编辑提议的变化值或者结构、或者通过将预算值设置为零来拒绝提议的变化。未经批准的变化可以匹配到提议的变化，但是不会成为经批准的合同预算的一部分。相反，未经批准的变化用作提议的变化已经被外部系统辨识的确认。在一些实施例中，系统允许第二方批准已经针对提议的变化请求的支付，只要这些提议的变化已经匹配到来自外部系统的未经批准的变化。

在另一个实施例中，提供用于在基于计算机的预算管理系统上处理预算变化的方法。合同预算数据结构存储在非临时性计算机可读存储器中。合同预算数据结构包括总合同预算量、多个合同预算行项目对象以及每个合同预算行项目对象的行项目值。从第一用户接收针对由第一用户在工程上执行的、对应于一个或多个预算行项目对象的工作的支付请求，并且该请求包括对适当的合同预算行项目的引用。还可以从第一用户接收对于对合同预算数据结构的总合同预算量的新变化的请求，并且作为响应，系统生成提议的预算变化数据结构。提议的预算变化数据结构包括至少一个合同组分项目。提议的预算变化数据结构中的每个合同组分项目包括项目ID以及将被添加到合同预算数据结构的提议的新合同预算行项目对象的值。在创建提议的预算变化数据结构之后，第一用户可以发起对于由第一用户执行的工作的支付请求，该支付请求引用提议的新预算变化数据结构而不是引用来自合同预算数据结构的预算行项目对象。

在一些实施例中，甚至可以在提议的变化由合同的第二方审查和批准之前接收引用提议的新预算变化数据结构的支付请求。然而，在其他实施例中，在可以批准支付请求之前，提议的新预算变化数据结构必须匹配到负责向第一用户支付的第二用户所创建的对应的经评估的预算变化数据结构。

通过考虑具体实施方式和附图，本发明的其他方面将变得明显。

附图说明

图1A是根据一个实施例的具有变化管理功能的建设支付管理系统的框图。

图1B是由图1的建设支付管理系统实现的各种模块的框图。

图1C是存储在图1A的建设支付管理系统的存储器上的分级分层的合同/预算结构的框图。

图2是根据在图1的系统上实现的已建立的合同/预算来处理支付的方法的流程图。

图3是使用图1的系统处理由分包商提议的分包合同变化的一种方法的流程图。

图4A是使用图1的系统处理由分包商提议的分包合同变化的另一种方法的流程图。

图4B是使用图1的系统审查、批准和处理提议的变化的方法的流程图。

图4C是使用图1的系统基于提议的变化而请求和处理支付的方法的流程图。

图5是使用图1的系统显示给分包商的工程主页的屏幕截图。

图6是在图1的系统中显示给分包商用于接收提议的变化的图形用户界面的屏幕截图。

图7是使用图1的系统将提议的预算变化以及经批准的预算变化的列表显示给分包商的图形用户界面的屏幕截图。

图8是使用图1的系统显示给总承包商的工程主页的屏幕截图。

图9是在图1的系统中显示给总承包商用于将经评估的变化匹配到提议的变化的图形用户界面的屏幕截图。

图10是使用图1的系统将提议的预算变化以及经批准的预算变化的列表显示给总承包商的图形用户界面的屏幕截图。

图11是使用图1的系统显示给分包商并且用来输入支付请求的图形用户界面的屏幕截图。

图12是使用图1的系统显示给总承包商并且用来批准从分包商接收的支付请求的图形用户界面的屏幕截图。

图13是使用图1的系统显示给总承包商并且用来在支付之前修改从分包商接收的支付请求的图形用户界面的屏幕截图。

图14是使用图2和图3的方法用于接收并且处理预算变化以及针对未经批准的提议的变化的支付要求的数据存储和处理流程的框图。

图15是使用图4A、图4B和图4C的方法用于接收并且处理预算变化以及针对未经批准的提议的变化的支付要求的数据存储和处理流程的框图。

图16A是在图1A的系统中与提议的变化相对应的请求对象以及与经评估的变化相对应的响应对象的数据生命周期的流程图。

图16B是用于将从外部ERP系统接收的响应对象数据结构与由CPMS生成的请求对象数据结构合并的方法的流程图。

图17是在第一示例中由图1A的系统响应于从分包商接收到提议的变化而生成的请求对象数据结构的表示。

图18是在第一示例中在分包商提交提议的变化之后，图17的请求对象数据结构的表示。

图19是在第一示例中在图1A的系统中由ERP系统生成并且由CPMS接收的响应对象数据结构的表示。

图20是在第一示例中在响应对象数据结构与图18的请求对象数据结构匹配并且合并之后图19的响应对象数据结构的表示。

图21是在第一示例中在图1A的系统中初始存储的总承包商预算数据结构的表示。

图22是在第一示例中与来自图21的总包合同预算数据结构的行项目对应的初始存储的分包合同预算数据结构的表示。

图23是在第一示例中在图18的请求对象数据结构被提升(promoted)之后，图22的存储的分包合同预算数据结构的表示。

图24是在第一示例中在图20的响应对象数据结构由图1A的系统处理之后，图21的所存储的总包合同预算数据结构的表示。

图25是在第一示例中在图20的响应对象数据结构被图1A的系统接收并且处理之后，图23的存储的分包合同预算数据结构的表示。

图26是在第一示例中在图20的批准提议的变化的响应对象数据结构被图1A的系统接收并且处理之前由分包商针对提议的变化提交支付要求的情况下，图25的存储的分包合同预算数据结构的替代表示。

图27是在第二示例中由图1A的系统响应于从分包商接收提议的变化而生成的请求对象数据结构的表示。

图28是在第二示例中在分包商提交提议的变化之后，图27的请求对象数据结构的表示。

图29是在第二示例中在图1A的系统中由ERP系统生成并且由CPMS接收的响应对象数据结构的表示。

图30是在第二示例中在响应对象数据结构与图28的请求对象数据结构匹配并且合并之后，图29的响应对象数据结构的表示。

图31是在第二示例中在图30的批准提议的变化的响应对象数据结构被图1A的系统接收并且处理之后，存储的分包合同预算数据结构的表示。

图32是在第三示例中由图1A的系统响应于从分包商接收提议的变化而生成的请求对象数据结构的表示。

图33是在第三示例中在分包商提交提议的变化之后，图32的请求对象数据结构的表示。

图34是在第三示例中在图1A的系统中由ERP系统生成并且由CPMS接收的响应对象数据结构的表示。

图35是在第三示例中在响应对象数据结构与图33的请求对象数据结构匹配并且合并之后，图34的响应对象数据结构的表示。

图36是在第三示例中在图35的批准提议的变化的响应对象数据结构被图1A的系统接收并且处理之后，存储的分包合同预算数据结构的表示。

具体实施方式

在详细说明本发明的任何实施例之前，应当理解，本发明在它的应用方面不局限于在下面的描述中陈述或者在下面的附图中例示的组分的构造和布置的细节。本发明能够具有其他实施例并且能够以各种方式实践或者实行。而且，应当理解，本文使用的措辞和术语是为了描述的目的并且不应当认为是限制性的。本文中“包括”、“包含”或者“具有”及其变型的使用旨在涵盖在其后面列出的项目及其等同物以及附加的项目。除非另外指定或者限制，否则术语“安装”、“连接”、“支撑”和“耦合”及其变型被广泛地使用并且涵盖直接和间接的安装、连接、支撑和耦合。

另外，应当理解，本发明的实施例可以包括硬件、软件和电子部件或者模块，为了讨论的目的，它们可以被例示并且描述为好像这些部件中的大多数仅在硬件中实现。然而，本领域普通技术人员基于阅读本详细描述将认识到，在至少一个实施例中，本发明的基于电子的方面可以在可由诸如微处理器和/或专用集成电路(“ASIC”)之类的一个或多个处理单元执行的(例如，存储在非临时性计算机可读介质上的)软件中实现。照此，应当注意，可以利用多个基于硬件和软件的设备以及多个不同的结构部件来实现本发明。例如，在说明书中描述的“服务器”和“计算设备”可以包括一个或多个处理单元、一个或多个计算机可读介质模块、一个或多个输入/输出接口以及连接这些部件的各种连接(例如，系统总线)。

而且，应当理解，用于建设工程交互和文档记录的具体术语在不同的司法管辖区、具体的上下文以及参与者偏好之间变化。例如，工程参与者可以提交包括“发票”、“进度款要求(progress claim)”、“支付申请”、“计费(billing)”或者“取款套包(draw package)”的支付请求。在一些国家以及对于一些工程，在过程中称作“取款”的定义支付周期结束时成批地进行支付。然而，下面在“取款”的上下文中讨论的示例将容易适用于其他类型的结构化的支付周期或者非结构化的间歇性支付。类似地，取决于上下文和商定的实践，术语“变化”可以与例如“变更订单”、“变化订单”或者“采购订单”互换。类似地，这里描述的示例指“总承包商”和“分包商”。应当理解，这些工程参与者在一些上下文和语境(locales)中具有其他头衔。例如，“总承包商”可以可互换地称作“主管承包商”或者“主承包商”。同样地，在一些上下文中，诸如“合同行项目”和“合同组分”之类的术语可以可互换地使用。最后，术语预算旨在广泛地指用来建立工程的财务预测、计划和约束的各种组分和交互。照此，除非另外指定，否则术语“预算”应当广泛地解释为包括“分项值表(schedule of values)”、“工作分解”、“工作分解结构”和/或“行项目细节”，或者在一些上下文中，术语“预算”可以与这种术语可互换地使用。这些或其他术语应当被足够广泛地解释为包括如在建设、银行和房地产行业中适当的用于类似的对应交互和文档记录的任何对应术语，直到本文使用可能对于当地措辞方式(verbiage)和习惯是独特的或者可互换地受制于行业偏好的这些术语的程度。

图1A例示基于网络的计算机系统100，基于网络的计算机系统100用于并发地管理涉及多个参与者的多个建设工程的建设工程支付过程。建设支付管理系统(“CPMS”)服务器101包括处理器103和存储器105，存储器105存储由处理器103执行以提供下面描述的系统功能的指令。存储器105包括一个或多个非临时性计算机可读存储器，诸如例如硬盘、闪存或者其他类型的RAM和ROM存储器单元。处理器103可以包括各种商用处理单元，包括微处理器、微控制器、PC计算机处理器、多核流水线处理器或者并行处理系统控制器中的一者或多者。

CPMS服务器101通过输入/输出(“I/O”)模块107与各种其他联网系统通信。例如，用户可以通过客户终端109访问CPMS服务器101，客户终端109直接连接到CPMS服务器101或者通过局域网连接到CPMS服务器101。替代地或者附加地，客户终端111、113可以通过互联网115访问CPMS服务器101。客户终端109、111、113可以以各种方式实现，包括例如专门设计为与CPMS服务器101接口的专用终端以及通过web接口或者通过在台式计算机上运行的软件程序访问CPMS服务器101的台式计算机。

CPMS服务器101还被配置为与各种外部工程和预算管理系统接口。例如，CPMS服务器101可以(直接地或者经由互联网连接)在通信上耦合到总承包商的外部企业资源计划(“ERP”)系统117。总承包商可以使用该外部ERP系统117来计划和跟踪工程预算、分配资源和装备、处理支付以及跟踪工程状态。ERP系统117的一些功能与CPMS服务器101所提供的功能交互。

CPMS服务器101也被配置为与一个或多个外部银行/支付系统119接口。以这种方式，CPMS服务器101可以响应于通过CPMS服务器101生成、处理和批准的支付请求(例如，发票、进度款要求等)而将支付指令发送到银行系统119。

在美国专利No.7,925,584中更详细地描述诸如图1A中例示的CPMS系统之类的CPMS系统的示例，该专利的全部内容通过引用合并于此。虽然图1A的示例将CPMS服务器101示出为具有单个处理器103和存储器105的单个单元，但是在一些实现方案中，CPMS服务器101可以包括具有多个并行处理核的计算机服务器、具有多个内部存储器单元的计算机服务器、与多个外部存储器单元(或者基于云的存储)交互的计算机服务器、或者一系列多个联网计算机服务器。照此，除非另外指定，否则本文所使用的短语和术语应当解释为包括单个物理部件或者多个物理部件。例如，本文使用的短语“存储器”可以包括单个存储器单元或者多个单独的存储器单元，本文使用的术语“处理器”可以包括单个处理器或者多个单独的处理器，本文使用的术语“CPMS服务器”可以包括单个服务器实现方案或者多个联网服务器，以及本文使用的术语“CPMS”可以包括单个计算机(例如，CPMS服务器101)或者多个联网计算机系统(例如，CPMS服务器101和客户终端109、111、113)。

CPMS 101被配置为实现提供本文的示例中描述的功能的一系列模块。例如，如图1B中所例示的，CPMS 101实现通知/提示模块125、支付请求模块127、保持模块129、预算协调模块131、变化跟踪模块133以及预算更新模块135。如下面更详细描述的，通过通知/提示模块125，CPMS 101检测CPMS 101上某些事件或动作的发生，并且生成通知以显示给一个或多个用户——例如，作为发送到存储在存储器上并且与特定用户相关联的具体电子邮件地址的电子邮件和/或作为显示在用户的工程主页屏幕上的文本通知。在需要由正在被通知的用户的进一步动作的情况下，通知/提示模块在通知中包括文本或者可选择的链接，从而指令被通知的用户执行一个或多个必需的动作。

通过支付请求模块127，CPMS 101征求并且收集来自系统用户的支付请求信息并且将支付请求传送到另一个用户以供审查和/或批准。保持模块129临时地保持和存储还没有准备好进行处理/批准的请求和文档。

通过预算协调模块131，CPMS 101为与工程相关联的用户存储和维护各种预算数据。如下面更详细讨论的，变化跟踪模块133跟踪提议的变化和经评估的变化的状态。除其他的以外，预算更新模块135还基于来自用户的经修改的分项值表以及经批准的变化来更新所存储的预算数据结构。

图1B中例示的模块是示例，并且CPMS服务器101的各种实际实现方案可以被配置为实现附加的模块、更少的模块或者替代的模块。在该示例中，每个模块被实现为由处理器执行以使得CPMS 101以规定的方式起作用的一系列软件指令。每个模块可以实现为所存储计算机指令的单独段落，这些计算机指令由单个计算机上的单个处理器执行或者由一个或多个计算机服务器上的多个处理器执行。而且，在一些实现方案中，至少一些模块可以被实现为仅执行与单个模块相关联的指令的单个专用处理器。

CPMS服务器101为系统所管理的每个建设工程存储并且维护分层合同/预算信息。CPMS服务器101也根据在其上存储和维护的合同和预算来便于支付。图1C例示存储在CPMS服务器101上并且由CPMS服务器101维护的一个这种分层结构化工程预算的示例。每个工程在最高级别处由指示工程的总体成本的工程合同151定义。总包工程合同151进一步由一系列总包合同行项目153、155定义。总承包商可以定义每个合同行项目153的分项值表(SOV)157。分项值表包括一个或多个SOV行项目(例如，GC SOV行1、GC SOV行2以及GC SOV行3)。

例如，总承包商可以将与工程相关联的工作划分成工作类型并且针对电气、水管设施、材料等定义单独的总包合同行项目，并且为每个类别定义值(亦即，总体工程值的一部分)。与“电气”合同行项目153对应的GC分项值表157可以进一步包括多个SOV行项目，如图1C中所示。替代地，GC可以与电气分包商签订合同以为工程提供所有电气工作。在这种情况下，合同行项目153的GC分项值表157可以仅包括单个GC SOV行项目。而且，在一些实现方案中，总包工程合同仅包括单个总值，并且总承包商不是定义多个合同行项目，而是直接基于总工程合同值定义多个SOV行项目——由此删除如图1C中所例示的“合同行项目”层级(亦即，合同行项目153、155)。

GC SOV 157中的每个SOV行项目识别由总承包商承担的直接成本(亦即，直接由GC提供的材料和人力)，或者对应于总承包商与一个或多个分包商或者材料供应商之间的分包合同(例如，分包合同159、分包合同161和分包合同163)。与特定分包合同相关联的工作和材料进一步由一个或多个分包合同行项目165、167定义。分包商通过一个或多个特定的分包合同链接到工程，并且然后分包商能够为每个分包合同行项目创建分项值表——例如，SOV 169由分包商为分包合同行项目165创建。分包商SOV 169包括一个或多个SOV行项目，这一个或多个SOV行项目对应于针对分包合同行项目165由分包商执行的具体任务或者由分包商提供的材料。而且，每个SC SOV行项目还可以对应于分包商与进一步的子层承包商之间的另一个分包合同，由此实现多层分层结构化工程和预算系统。替代地，一个或多个单独的分包合同行项目可以直接链接到GC SOV行项目。在这种实现方案中，分包合同(亦即，分包合同159、161、163)不用作预算层次结构中的中间层级。相反，分包合同各自定义一个或多个分包合同行项目，这一个或多个分包合同行项目然后直接链接到GC SOV行项目。

如果在工程过程期间，分包商发现他们的成本将超出特定分包合同159中的商定值，或者如果附加的工作或者材料是必要的，那么分包商可以请求分包合同的项目的变化。在本文描述的示例中，由总承包商发出的经批准的变化使得具有定义值的新分包合同行项目171被添加到分包合同157。然后分包商能够定义与新分包合同行项目171对应的新的SOV173。因为在大多数情况下添加该新分包合同行项目171改变分包合同159的总值，所以总承包商可以决定请求对工程合同151的对应变化。

虽然本文讨论的示例和系统聚焦于导致新分包合同行项目的添加的变化，但是其他系统可以被配置为响应于经批准的变化请求创建全新的分包合同。而且，可以遍及多层建设工程在其他层级处类似地处理变化。例如，在分包再分包商(sub-of-sub-contractor)层级处添加新合同行项目可以使得分包商请求对应的调整，并且最终可以使得总承包商请求类似的调整。

图1C的示例例示一个具体类型的分层合同预算布置。然而，本文描述的系统和方法可以适用于其他分层合同和/或预算布置。它们也可以适用于管理和修改两方之间的单个合同而没有进一步的分层层级。下面讨论的示例有时可以参考图1C的具体布置，并且在其他时候更一般地参考合同预算数据结构。除非另外指定，否则术语合同预算数据结构应当解释为包括定义与两方之间的合同协议有关的预算信息的任何数据结构，该数据结构被修改以反映对合同协议的改变。

图2例示使用图1的系统处理支付的方法的一个示例。CPMS服务器101从总承包商的ERP系统117接收工程合同和预算信息(步骤201)并且各个SOV行项目通过一个或多个分包合同变得与具体的分包商相关联(或者被指派到具体的分包商)(步骤203)。应当注意，虽然下面描述的示例可以具体地指总承包商与分包商之间的交互，但是这些示例中描述的功能和机制可以提供给建设工程中的参与者的任何组合，其中一个参与者签订合同以执行工作或者提供材料，并且另一个参与者负责监督并且支付给第一参与者。例如，在下面的示例中动态描述的分包商-总承包商可以同等地适用于参与者的各种其他组合，包括但不局限于总承包商对工程所有者、材料供应商对分包商、分包再分包商对分包商、材料供应商对总承包商等。

在来自总承包商的单独SOV行项目通过分包合同(亦即，通过分包合同行项目)指派给分包商(步骤203)之后，分包商通过为每个分包合同行项目创建SOV进一步定义分包商预算(步骤205)。CPMS服务器101例如通过确保SC SOV行项目的总值等于分包合同行项目的对应值来确保分包商预算被协调(步骤207)。分包商定义的预算信息可以例如由CPMS服务器101或者由与CPMS服务器101交互的分包商的ERP系统生成。

如果分包商预算被恰当地协调(步骤207)，那么CPMS服务器101允许分包商生成与经批准的分包合同行项目对应的支付请求(步骤209)。如果分包商预算没有被协调，那么CPMS服务器101实现违规(non-compliance)工作流(步骤211)，除其他以外，该违规工作流还阻止分包商创建支付请求。违规工作流的更多细节和其他示例在上面已经通过引用合并的美国专利No.7,925,584以及通过引用将其全部内容合并至此的美国专利公开No.2008/0281735中描述。

如果分包商预算被恰当地协调(步骤207)并且分包商生成与经批准的分包合同行项目相关联的支付请求，那么CPMS服务器101将支付请求转发到总承包商以供审查(步骤213)。如果总承包商批准支付请求(步骤215)，那么CPMS服务器101发起工作流以便于支付给分包商(步骤217)。如在已经在上面通过引用合并的美国专利No.7,925,584中更详细描述的，CPMS服务器101可以通过将支付指令电子地发送到外部银行系统、打印支票或者其他机制来便于支付。

然而，如果总承包商不批准支付请求，那么CPMS服务器101实现非支付工作流(步骤219)，其中可以通知分包商未经批准(或者经编辑)的发票。在一些实施例中，CPMS服务器101接收来自总承包商的说明为什么拒绝支付请求的注释或者评论。这些评论被显示给分包商并且存储到存储器以用于未来的访问以及记录保持。在一些实施例中，非支付工作流可以包括扩展的编辑过程，其中总承包商和分包商能够交替地对发票进行编辑直到商定出双方同意的支付策略。美国专利No.8,306,883描述了这种系统的一个示例，该专利的全部内容通过引用合并至此。

如上面参考图1C所讨论的，在一些情况下，更改已商定的合同/预算的项目变得必要。例如，材料的成本可能多于最初估计的成本或者物流问题可能延长或者延迟分包商的建设活动。图3例示分包商可以如何通过使用CPMS服务器101请求对建设工程的经批准的预算的修改(或者“变化”)的一个示例。分包商发起变化请求(步骤301)并且CPMS服务器101将该请求转发给总承包商(步骤303)。总承包商通过CPMS服务器101或者通过总承包商的外部ERP系统审查该变化请求，并且确定批准还是拒绝该变化请求(步骤305)。

如果该变化请求被批准，那么CPMS服务器101(例如，通过添加新的分包合同行项目)更新适当的分包合同(步骤307)。然后分包商能够通过CPMS服务器101针对新的预算量请求支付(步骤309)。然而，如果变更订单请求被拒绝，那么对合同/预算不做更新(步骤311)，或者如下面更详细描述的在一些实现方案中更新预算以反映提议的变化，但是该预算被指派值$0而不是分包商所请求的量。在任一情况下，分包商使用CPMS服务器101请求支付的能力受先前建立的预算量限制(步骤313)，并且如果分包商的预算没有与可适用的分包合同的项目恰当地协调，可以阻止分包商请求任何支付。

图4A例示替代的机制，其中CPMS服务器101可以处理预算变化请求，并且甚至允许分包商在预算变化被总承包商批准之前创建新的SC SOV以及针对新的提议的预算量请求支付。在一些实现方案中，CPMS服务器101被配置为提供仅图3的功能或者仅图4A的功能。替代地，CPMS服务器101可以被配置为基于诸如例如总承包商偏好设置、工程位置或者工程类型之类的因素来提供图3的功能或者图4A的功能。在下面描述的示例中，图3的处理功能称作“标准变化处理”并且图4A的功能称作“增强型变化处理”。

在如图4A中所例示的增强型变化处理中，分包商创建“提议的变化”(步骤401)，该提议的变化如果被批准，就将作为新的分包合同行项目而添加。图5例示在访问CPMS服务器的终端设备上显示给分包商的基于web的用户界面的示例。分包商能够从下拉菜单中选择“提议变化”或者“变化登记”。图6示出当选择“提议变化”时显示给分包商的用户界面。分包商使用表格将编号、标题、描述和量指派给新的提议的变化。诸如日期之类的其他过程数据基于提交的时间和上下文而指派。新的提议的变化保持列示在该屏幕上并且可以由分包商编辑，直到它们由分包商正式地提交(图4A，步骤403)。在图6的示例中，分包商通过选择界面列表左侧上的对应复选框并且点击“提交选择”按钮来提交提议的变化。替代地，分包商可以在提交提议的变化之前选择“保存草稿”，并且保留对提议的变化做出进一步编辑的能力。

一旦被分包商提交(图4A，步骤403)，提议的变化就变成锁定的并且分包商不再能够编辑该提议的变化的细节。分包商仍然可以通过在图5的主屏幕上选择“变化登记”选项来查看所提交的提议的变化并且监控提议的变化的状态。图7例示显示给分包商的“变化登记”屏幕的示例。变化登记屏幕按照编号、标题、描述、提交日期和提交量列示所有已提交的提议的变化。

如下面更详细讨论的，实施例提供改进的电子过程，通过该改进的电子过程，每个提议的变化将在该变化能够被包括作为实际分包合同预算的部分之前由总承包商进行评估。界面右边的标注为“评估”的三个列提供关于总承包商对于每个提议的变化的评估的状态和结果的信息。例如，如果提议的变化已经被批准，那么评估“状态”列将该变化示出为“经批准”并且包括“批准量”。如果提议的变化(例如，图7的变化4)已经被拒绝，那么变化登记将该变化批准量反映为$0.00。如果提议的变化还没有被批准或者拒绝，那么在变化登记中评估“状态”列将该提议的变化示出为“已提交”。评估“变化#”列识别由总承包商的ERP系统指派给变化的识别编号。如果(如下面进一步讨论的)总承包商还没有确认提议的变化，那么不给提议的变化指派评估变化编号(例如，变化7)。然而，如果总承包商的ERP系统确认评估处理已经开始但是还没有批准或者拒绝提议的变化，那么显示指派的评估变化编号并且评估状态被示出为“已提交”(例如，变化5)。

如下面更详细描述的，电子系统使得分包商能够在提议的变化由总承包商实际批准之前或者之后提交与提议的变化量对应的支付请求。如果任何对应的量迄今为止已经由分包商计费，那么已计费的量也在变化登记屏幕上显示给分包商。在图7的示例中，变化登记仅列示与单个具体分包合同对应的变化。分包商可以使用界面左上角中的下拉框选择来自相同工程的不同分包合同以供显示。

一旦提议的变化被分包商提交，就由CPMS服务器101自动地将指示已经请求预算变化的通知发送到总承包商(图4A，步骤407)。该通知可以例如以电子邮件的形式发送，该电子邮件识别提交了提议的变化的参与者、提议的变化量以及对应的合同/工程。CPMS服务器101也可以通过生成消息并且在总承包商的工程主页上显示该消息来通知总承包商，其中通过实现诸如图1B的通知/提示模块125之类的通知/提示机制来生成消息并且在总承包商的工程主页上显示该消息。图8例示包括通知的一个这种工程主页的示例，该通知读作“5个新的提议的变化”从而指示五个新的提议的变化正等待总承包商的进一步动作。

此时，总承包商可以开始评估过程(图4A，步骤409)或者分包商可以开始针对未经批准的提议的变化提交要求(或者请求支付)(步骤411)。在图4B中进一步描述评估过程(步骤409)并且在图4C中描述分包商要求过程。

如图4B中所例示的，总承包商通过将提议的变化导出到他们的外部ERP系统(步骤413)来开始评估过程。总承包商决定是否编辑提议的变化(步骤415)。如果总承包商对于由分包商提议的合同预算值没有做出任何改变，那么基于提议的变化所定义的相同值和合同行项目创建“经评估的变化”(步骤417)。然而，如果做出了改变，那么基于由总承包商提供的新的值、合同行项目以及标题创建“经评估的变化”(步骤419)。(如下面更详细描述的)总承包商可以通过改变新的提议的分包合同行项目的值或者添加比由分包商提议的更多/更少的分包合同行项目来编辑提议的变化。然后总承包商指示是否批准变化(步骤420)。如果变化被批准，那么CPMS服务器101被配置为将经评估的变化合并作为经批准的分包合同预算的部分。如果变化未被批准，如下面进一步讨论的，经评估的变化将保持为“未经批准”状态。而且，在该示例中，可以通过以$0.00的值批准经评估的变化来拒绝提议的变化。

由ERP系统生成的经评估的(经批准的或者未经批准的)变化然后被导入到CPMS中(步骤421)，并且可用于匹配到对应的提议的变化(步骤423)。该匹配过程可以通过如图9中所例示的CPMS界面执行。图9示出在用户终端上显示给总承包商的基于web的用户界面的示例。用户界面在屏幕顶部附近的表格中示出已经从ERP系统导入的未匹配的经评估的变化(亦即，变化#SV03)的细节，并且(在“状态”列下)指示该经评估的变化已经被批准。界面也在下方表格中列示所有未决定的、未匹配的提议的变化的细节。通过使用这个界面，总承包商从下方表格中选择适当的未匹配的提议的变化并且按下屏幕上的“匹配”按钮。

一旦匹配完成，那么如果经评估的变化是“经批准”的，就通过将新分包合同行项目添加到适当的分包合同来更新合同预算(步骤427)。如果经评估的变化没有被批准并且执行了匹配，那么来自总承包商ERP系统的任何细节或者识别信息仍然变得与已匹配的提议的变化相关联；然而，没有“经评估的值”被导入或者显示给分包商。系统可以被配置为使得总承包商能够在没有批准提议的变化的情况下执行匹配，以便确认接收到提议的变化、更新总承包商的ERP系统并且允许分包商在总承包商与工程所有者协商对总包合同的对应调整的同时继续工作。

在图9的示例中，通过勾选每个列示的提议的变化左边的复选框中的一个或多个，单个经评估的变化可以与一个或多个提议的变化相匹配。在系统的一些实现方案中，单个变更订单可以由总承包商的ERP系统发出，该变更订单批准与已经由分包商提交的多个提议的变化对应的(一个或多个)合同变化。相反地，如下面详细描述的，总承包商可能想要对分包合同做出多个改变而不是由分包商提议的单个变化。因此，其他实现方案可以支持单个提议的变化由改进的电子过程匹配到多个经评估的变化的机制。类似地，一些实现方案可以允许若干个提议的变化到若干个经评估的变化的批量匹配。

在本文描述的许多示例中，系统被配置为基于从总承包商接收的经批准的变化来自动地更新分包合同预算——即使总承包商的经批准的变化的值不同于分包商的提议的变化的值。在一些实现方案中，当经批准的变化具有与提议的变化不同的值或者结构时，由CPMS实现的通知/提示机制(诸如图1B的通知/提示模块125)生成通知并且将通知传输/显示给分包商。由CPMS实现的通知/提示机制然后提示分包商接受经修改的变化或者提交新的提议的变化。以这种方式，分包商保留针对分包合同如何由总承包商修改的一些输入。类似地，在一些实现方案中，在经批准的变化有效地改变工程预算之前，经修订的分包合同必须由分包商和总承包商执行(亦即，电子地或者手动地签字)。CPMS系统可以利用签字要求作为分包商能够审查总承包商的经批准的变化并且确定是否接受该经批准的变化(亦即，通过执行经修订的分包合同)的机制。在由同一分包商提交多个提议的变化的情况下，CPMS系统可以被配置为将与这些提议的变化对应的所有经批准的变化聚集(group)成单个经修订的分包合同或者补充分包合同，以由分包商和总承包商执行。

总承包商也能够通过CPMS界面访问变化登记屏幕。图10例示一个这种变化登记的示例。与图7的分包商的变化登记屏幕类似，GC的变化登记显示由分包商提交的每个提议的变化以及由总承包商生成的不对应于任何分包商提议的变化的任何其他变化。对于最初由分包商提议的变化，图10的变化登记(在“提交量”列中)示出由分包商提议的变化量，并且在可适用时(在“批准量”列中)示出来自总承包商的对应的经批准的变化的量。“状态”列指示提议的变化是已经被批准、已经被拒绝、还是仍然等待来自总承包商的批准决定。已经被总承包商拒绝的提议的变化在“批准量”列中具有值$0。针对不同于分包商所提议的量的已经被批准的提议的变化在“状态”列中被指定为“经批准”，但是在“批准量”列中反映实际的经批准的变化量。如上面参考图7所讨论的，已经匹配到来自总承包商的ERP系统的“经评估的变化”的提议的变化将示出“已提交”的状态并且将示出总承包商指派的“变化#”(例如，变化5)。然而，还没有匹配到“经评估的变化”的提议的变化将示出“已提交”的状态，而没有任何评估变化编号并且没有任何“批准量”(例如，变化7)。总承包商也可以包括没有显示给分包商但是可以由总承包商使用以记录各种其他信息的“私有评论”，这些其他信息包括例如提议的变化为什么被拒绝或者被编辑或者提议的变化为什么还没有被批准。

应当注意，参考图4B描述的系统和方法仅提供一个具体的示例。例如，在CPMS的其他实现方案中，总承包商可以能够直接通过CPMS界面审查、编辑和批准变化。在这种系统中，提议的变化将不必被导出到任何ERP系统，经评估的变化也将不导入回到CPMS。而且，在一些实现方案中，CPMS被配置为通过基于接收到的经评估的变化以及任何剩余的未匹配的提议的变化的细节来预测最可能的匹配或者通过使用共同标识符来自动地匹配提议的变化与经评估的变化。在一些这样的系统中，CPMS可以被配置为询问总承包商以确认自动识别的匹配。

被配置为自动地识别匹配的提议的变化和经评估的变化的系统也可以被配置为自动地确定什么时候从ERP系统接收的经批准的变化不具有由分包商在CPMS上发起的对应的提议的变化。在这种情况下，系统将被配置为将传入的经批准的变化(例如，图10中的“GC变化2”)视为由总承包商发起的预算变化并且将相应地更新分包商预算和分包合同值。

图4C例示使用增强型变化处理功能的分包商的要求提交过程。分包商将支付请求输入到CPMS中(步骤445)。图11例示可以用来输入支付请求细节的基于web的用户界面的一个示例。图11的用户界面列示由分包商提交的所有经批准的预算行项目和未经批准的提议的变化(但是仍然待由总承包商批准)。分包商使用该界面来识别要针对其提交要求的预算行项目，并且(例如通过编辑“本周期”列中的字段)输入在本支付周期期间将要请求的新的支付量。

图11的界面仅允许分包商请求具体地引用经批准的分包合同行项目或者提议的变化的支付。请求支付界面的功能只有在分包商的预算被恰当地协调的情况下是可访问的。然而，与图2的示例不同，分包商可以创建与未经批准的提议的变化对应的SOV，并且针对提议的变化请求支付(在一些实现方案中，分包商SOV将仅作为提议的变化的单个行项目而创建，并且不能够扩展到多个行项目，直到该变化被批准)。而且，如果请求的支付对应于已建立的分包合同预算的行项目(步骤447)，那么图11的界面仅允许分包商请求量小于或者等于分包合同行项目的剩余的经批准的预算的支付(步骤449)。然后支付请求被转发到总承包商(步骤451)。如果总承包商批准该支付请求(步骤453)，那么CPMS服务器发起工作流以便于支付(步骤455)。相反地，如果请求被拒绝，那么发起非支付工作流(步骤457)。

通过使用图11的界面，分包商还可以针对未经批准的提议的变化请求支付。如果提议的变化已经由总承包商匹配到“经评估的变化”(步骤459)——由此确认提议的变化已经由总承包商的ERP系统确认——那么CPMS甚至可以允许总承包商针对未经批准的提议的变化进行支付。然而，因为分包合同还没有修改，所以CPMS首先确定所请求的支付量是否小于经批准的分包合同行项目的剩余余额(步骤449)。如果所请求的支付量小于经批准的分包合同行项目的剩余余额，那么支付请求被转发到总承包商(步骤451)以供审查和批准(步骤453)。如果所请求的支付量不小于经批准的分包合同行项目的剩余余额，那么支付请求被记录并且由CPMS实现的保持机制(例如，图1B的保持模块129)可以保持该支付请求(步骤463)用于随后的处理和批准(亦即，直到提议的变化已经被批准并且底层的分包合同已经被相应地修改)。在需要提交支付请求并且按照“取款”日程支付该支付请求的其他实现方案中，如果所请求的支付量超过经批准的分包合同行项目的剩余余额，那么该支付请求将被拒绝并且分包商将被要求在下一个取款周期期间重新提交该支付请求。

这种“计帐式支付(pay on account)”机制允许只要所请求的支付量不超过经批准的分包合同的剩余值(或者指派给分包商的工程的所有分包合同的总剩余值)就批准支付。例如，如果分包商提议分包合同中的附加的$1000的预算变化并且然后请求支付提议的变化的全部$1000，那么如果该分包合同的未支付余额等于或者超过$1000，系统就将允许总承包商批准该支付。以这种方式，如果支付被进行并且提议的变化最终被拒绝，那么调整分包商的分包合同的SOV以计入已支付的量就变成分包商的责任。

CPMS也允许分包商针对还没有匹配到经评估的变化的提议的变化请求支付(步骤461)。然而，因为总承包商没有确认提议的变化已经被他们的ERP系统确认(亦即，通过执行到导入的经评估的变化的匹配)，所以CPMS保持所有这种支付请求(步骤463)至少直到提议的变化已经被匹配。在一些实现方案中，当已经针对未匹配的提议的变化请求支付时，由CPMS实现的通知/提示机制(例如，图1B的通知/提示模块125)指令总承包商评估提议的变化并且执行匹配。

图12例示由总承包商使用以审查所有未决定的支付要求(亦即，图4C的步骤453)的基于web的界面的示例。除其他信息以外，该界面还显示每个分包商组织的总合同值、所请求的支付量、剩余的经批准的合同余额、以及针对未经批准的变化做出的任何支付请求的总量(在“未经批准的要求”列中显示)。总承包商可以通过在“未经批准的要求”列内的字段上点击来查看承包商的任何未经批准的变化。“状态”列指示对于当前的取款周期是否已经接收到每个分包商组织的支付请求。

除了批准和拒绝支付请求之外，还可以允许总承包商使用图13的基于web的界面在支付之前修改由分包商提交的支付请求。显示给总承包商的“修改”页面在内容和功能方面类似于显示给分包商的分包商要求页面(图11)。然而，除了改变对于当前支付周期将要支付的量之外，总承包商还可以提供向分包商解释为什么编辑支付量的评论。

在上面描述的系统和示例中，分包商可以能够在任何时候(或者根据设置的日程)提议预算变化。然而，支付请求可以根据诸如例如在美国专利No.7,899,739中描述的更加严格定义的支付日程被征求、批准和处理以供支付，该专利的全部内容通过引用合并至此。

上面从系统用户的角度讨论标准变化处理(图2-图3)与增强型变化管理(图4A-图4C)之间的功能差异。然而，这些差异整体地与CPMS服务器如何在硬件/数据结构级别实现和跟踪预算方面的差异有关。图14例示在标准变更订单处理期间CPMS服务器101与ERP系统117之间的数据结构和过程流程交互。CPMS 1401存储包括任何先前批准的变化1407的基础合同1405的组分。未经批准的提议的变化1409由CPMS 1401单独地存储和跟踪。当分包商将提议的变化输入到系统中时，变化请求1411生成并且传输到外部ERP系统1403。如果请求1411被批准，那么总承包商(通过他们的ERP系统)必须更新合同值，从而将新的批准的变化1413作为工程预算/合同的部分添加到存储在CPMS 1401上的经批准的变化1407的列表。

虽然在图14的示例中分包商能够通过经由CPMS 1401输入提议的变化1409而生成变化请求1411，但是实际的变化1413必须直接来自总承包商。照此，没有维护可以被系统用来将所请求的支付链接到由用户生成的变更订单请求1411和从总承包商接收的经批准的变化1413这二者的真实数据。为了让分包商针对未经批准的提议的变化1409请求支付，分包商可能不得不在CPMS 1401外部生成发票1415并且将它转发到总承包商以供手动审查和批准。即使CPMS 1401被配置为了允许分包商针对未经批准的提议的变化1409生成支付请求，要求1415也必须由总承包商手动审查并且数据必须被手动输入到ERP 1403中。

与之相比，图15例示在增强型变化管理期间CPMS 1501与ERP 1503之间的数据流和交互过程。CPMS 1501存储包括任何经批准的变化1507的基础合同组分1505。CPMS 1501也将所请求的/未经批准的变化1509连结到基础合同组分1505，使得当被批准时，提议的变化数据变得直接链接到经批准的合同预算。当由分包商创建并且提交提议的变化时(图4A，步骤401、403)，系统生成存储在CPMS上的请求对象1511。当提议的变化被导出到ERP系统时(图4B，步骤413)，请求对象1511的副本被传输到ERP系统1503。在总承包商已经完成他对提议的变化的审查之后，(如下面详细描述的)满足某种格式和内容准则的响应对象1513从ERP 1503导入到CPMS 1501(图4B，步骤421)。在经评估的变化与提议的变化匹配之后(图4B，步骤423)，响应对象1513被更新为目标指向(target)对应的请求对象1511。虽然当响应对象1513批准变化时，响应对象1513的(一个或多个)值和行项目结构取代请求对象1511的(一个或多个)值和行项目结构(这在下面更详细地讨论)，但是请求对象1511经历完(passthrough)未经批准的变化1509并且变得直接连结到经批准的预算作为经批准的变化1507。如果响应对象1513不包含经批准的变化，那么请求对象1511保持与未经批准的变化1509相关联，直到从ERP 1503接收到随后的包含经批准的变化的响应对象1513。

以这种方式，CPMS 1501可以允许用户采取目标指向未经批准的请求对象数据结构的动作——诸如例如提交支付要求1515。当请求对象1511与响应对象1515匹配并且变成经批准的变化1507的部分时，支付请求1515与请求对象1511之间的关联然后变成与经批准的变化1507的关联。不需要手动审查支付要求或者不需要将数据手动输入到ERP系统中。相反，CPMS 1501被配置为在整个提议和批准预算变化的过程中维护数据结构对象，同时提供CPMS与外部ERP系统之间的交互。而且，一旦响应对象与已匹配的请求对象链接，由分包商在CPMS中采取的目标指向请求对象的任何动作就将由总承包商的ERP系统类似地索引和辨识为对应于由ERP系统生成并且从ERP系统发送的响应对象。因此，即使在ERP系统上创建经批准的变化之前由分包商在CPMS系统上采取动作，数据和功能也在CPMS系统与外部ERP系统之间无缝地集成。

在下面讨论的示例中，该数据匹配和集成过程由如图16A中所例示的独特数据结构生命周期命令和控制。当新的数据结构对象(请求对象或者响应对象)进入系统时，该新的数据结构对象被指派初始状态——在CPMS上创建的请求对象初始地具有“未提交”状态1601并且被导入到CPMS中的响应对象初始地具有“未匹配”状态1602。当数据结构对象准备好由CPMS动作时(亦即，在与请求对象对应的提议的变化被提交之后以及在与响应对象对应的经评估的变化“已匹配”之后)，该对象被指派“已筹划”(“staged”)状态1603。一旦CPMS已经在数据结构对象上动作并且该数据结构对象已经到达它的最终的结束状态，该数据结构对象的状态就改变为“已提升”(“promoted”)1605或者“已合并”(“merged”)1607的“结束状态”状态。

例如，当新的提议的变化由分包商创建时(图4A，步骤401)，请求对象数据结构被创建并且指派“未提交”的初始状态1601。当请求对象具有“未提交”状态1601时，分包商可以编辑提议的变化的数据并且CPMS不会开始处理该请求对象。当用户提交提议的变化用于由总承包商考虑时，请求对象被指派“已筹划”的状态1603，从而指示CPMS可以开始处理该请求对象。一旦CPMS已经处理请求对象，目标字段就被更新为指代分包合同预算数据结构中潜在的新分包合同行项目的未来位置(这在下面将更详细地描述)并且请求对象被导出到ERP系统，存储在CPMS上的请求对象被指派“已提升”的状态1605。

类似地，在需要总承包商将经评估的变化手动匹配到提议的变化的实现方案中，由CPMS从ERP接收(图4B，步骤421)的响应对象被初始地指派“未匹配”的状态1602。在总承包商已经将与响应对象对应的经评估的变化匹配到提议的变化之后，该请求对象的状态更新成“已筹划”1603，从而指示CPMS可以开始处理响应对象。然而，与请求对象不同，响应对象具有两种潜在的结束状态——“已提升”1605和“已合并”1607。在响应对象已经到达“已筹划”状态1603之后，CPMS执行如图16B中例示的合并例程，以将响应对象链接到与已匹配的提议的变化对应的请求对象。来自响应对象的与请求对象的项目对应的各个项目被更新为目标指向请求对象的对应项目(如下面详细描述的)并且被指派“已合并”状态1607。相反地，响应对象中不具有请求对象中的对应项目的的任何项目被更新为直接目标指向分包合同预算数据结构中的新分包合同组分的位置并且被指派“已提升”状态1605。

虽然“已合并”1607和“已提升”1605都是数据结构对象以及数据结构对象内的各个项目的潜在的结束状态，但是它们各自表示不同的目标指向过程。“已提升”的数据对象和项目直接目标指向分包合同预算数据结构中新的分包合同组分的位置。“已合并”的数据对象和项目通过目标指向另一个数据结构对象而间接地目标指向分包合同预算数据结构(亦即，响应对象目标指向请求对象，该请求对象继而目标指向分包合同预算数据结构)。

图16B更详细地例示合并例程。在总承包商已经将经评估的变化与提议的变化匹配(由此识别与响应对象对应的请求对象)(步骤1611(亦即，图4B，步骤423))之后，CPMS确定是否返回经评估的变化而没有任何编辑(步骤1613)。如果返回经评估的变化而没有任何编辑，那么响应对象将包括与已匹配的请求对象相同数量的项目和相同的值。然后CPMS更新响应对象使得它目标指向已匹配的数据结构并且将对象以及对象内所有项目的状态更新为“已合并”(步骤1615)。如果响应对象指示变化已经被批准(步骤1616)，那么分包合同预算数据结构被更新为包括与经批准的变化对应的新的分包合同组分(步骤1617)。如果响应对象不包括变化已经被批准的指示，那么提议的变化保持为未经批准的变化，并且请求对象和响应对象还没有被升高成为经批准的分包合同预算的部分(步骤1618)。

如果提议的变化已经被编辑(步骤1619)，那么响应对象可以包括在已匹配的请求对象中不存在的附加项目和/或在已匹配的请求对象中的项目的不存在的不同值。在请求对象中具有对应项目的任何响应项目被更新为目标指向对应项目并且它们的状态被改变为“已合并”(步骤1621)——即使响应对象中的值与请求对象中的对应值不同。如果已经在响应对象中添加新的项目(步骤1623)，那么这些新项目被更新为直接目标指向分包合同预算数据结构中新的分包合同行项目的位置并且被指派“已提升”状态(步骤1625)。

在被拒绝的变化的特殊情况下(步骤1627)，响应对象将具有与已匹配的请求对象相同的项目，但是响应对象将把变化的值定义为零美元($0)。响应对象被更新为目标指向请求对象并且响应对象的状态被改变为“已合并”(步骤1629)。新的分包合同行项目以$0的值添加到分包合同预算数据结构(步骤1617)。

图17例示当新的提议的变化由分包商创建(亦即，图4A，步骤401)时由CPMS生成的请求对象数据结构的一个示例的内容和格式。该请求对象是具有多个项目的包裹(parcel)的形式。包裹数据结构包括包裹ID、包裹类型和状态。包裹数据结构也包括两个项目：变更订单项目和合同组分项目。两个项目都具有项目ID、类型、状态、目标和量。在图17中，因为提议的变化请求还没有由分包商“提交”(亦即，图4A中的步骤403还没有发生)，所以包裹和两个项目的状态都是“未提交”。

一旦分包商提交变更订单请求(图4A，步骤403)，包裹和所有项目的状态就改变为“已筹划”。然后CPMS通过将每个项目的“目标”字段更新为指代另一个数据结构或者对象的物理存储位置来处理请求对象。然后每个项目和包裹自身的状态被更新为“已提升”，从而指示请求对象已经到达其结束状态。图18例示“已提升”的请求对象数据结构的示例。包裹和每个项目的状态列示为“已提升”并且每个项目包括目标。“合同组分”项目目标指向分包合同预算数据结构中将用于新的分包合同行项目的位置。变更订单目标指代被用来便于由匹配导致的项目与请求之间的关系的唯一存储器地址或者文档识别编号。

当分包商创建新的草稿的提议的变化(图4A，步骤401)时，生成图17的数据结构。如图18中所示，在提交潜在的变化(图4A，步骤405)之后，改变该数据结构的状态。在总承包商已经评估提议的变化并且从ERP系统导入经评估的变化(图4B，步骤413)之后，新的响应对象数据结构被存储在CMPS存储器中。图19例示这种响应数据结构的一个示例。同样的，响应数据结构是具有一个或多个相关联的“项目”的包裹。包裹和项目由ID识别并且被指派状态和目标。虽然图19中没有例示，但是从ERP系统接收的响应对象也将包括指示变化是经批准还是未经批准的标记或者字段。

诸如图19的示例中例示的从ERP系统接收的响应对象初始地不具有目标，并且包裹和所有项目的状态列示为“未匹配”。一旦经评估的变化匹配到提议的变化(图4B，步骤414)，就根据图16B的方法“合并”包裹，并且使用适当的目标更新响应对象数据结构。图20例示“已合并”的响应数据结构的一个示例。包裹的“目标”被更新为反映目标请求包裹的包裹ID——在该示例中为包裹5(亦即，图18的请求对象)。

然而，在该示例中，响应数据结构包括比已匹配的请求数据结构更多的“项目”。总承包商不是简单地批准由分包商提交的提议的变化，而是选择创建两个新的分包合同行项目并且在这两个新的分包合同行项目之间划分$1000的经批准的附加预算量。照此，响应包裹包括两个“合同组分”项目——一个具有$900的量并且另一个具有$100的量。当响应包裹与请求包裹合并时，第一合同组分项目与请求包裹的合同组分项目合并——响应包裹中的第一合同组分项目的目标被更新为反映请求包裹中合同组分项目的项目ID(在该示例中为项目11)，并且第一合同组分项目的状态被改变为“已合并”。因为在图18的对应请求包裹中不存在对应的第二合同组分项目，所以响应包裹的第二合同组分项目被更新为目标指向分包合同预算数据结构的新的附加的分包合同行项目，并且第二合同组分项目的状态被改变为“已提升”(由此指示第二合同组分项目直接目标指向分包合同预算数据结构，而不是通过请求对象间接地目标指向分包合同预算数据结构)。

图21-图26例示当CPMS处理如图17-图20中所例示的请求对象和响应对象时存储在CPMS的存储器上的分包合同预算数据结构和总包合同预算数据结构是如何更新的。图21示出工程的包括三个合同行项目的原始的未经更改的总包合同预算。总体工程合同的总合同量是$4,000,000.00，如由每个相关联的行项目量所指示的，该总合同量在三个合同行项目之间划分。图21的示例指示仅一个分包合同当前对应于每一个总包合同预算行项目。图22示出具有与来自总包合同预算数据结构的“电气”预算行项目对应的分包合同的分包商的分包合同预算数据结构。该分包合同的总预算量是$500,000。

当分包商创建并且提交提议的变化(亦即，图18的请求对象)时，分包合同预算数据结构可以以两种方式(或者上下文)存储和显示——经批准的分包合同预算(图22)和潜在的分包合同预算(图23)。然而，直到提议的变化由总承包商审查和批准，总承包商视角的分包合同预算数据结构是未经更改的并且保持为图21中所例示的那样。一旦提议的变化被总承包商批准，它就变成分包合同预算的部分并且作为总体工程预算的部分而反映。如图24中所例示的，经更新的总承包商预算包括由响应对象(亦即，来自总承包商的经批准的变化)命令的用于电气行项目的增加量以及增加后的总合同量。

一旦提议的变化被总承包商批准，分包合同预算数据结构就也被更新以反映由响应对象所命令的提议的变化的量或者术语的任何改变。图25例示在图20的响应对象已经由CPMS处理之后的更新后的分包合同预算数据结构。在该示例中，如上面参考图19-图20所讨论的，总承包商不是以$1000的量批准单个新的分包合同行项目，而是批准两个单独的新的分包合同行项目——“GC CC 1”为$900.00以及“GC CC 2”为$100.00。

也如上面所讨论的，在一些实现方案中，分包商能够在提议的变化被添加到经批准的分包合同预算之前针对该变化创建并且提交支付请求。根据图20的响应对象，总承包商已经批准$900和$100的两个新的分包合同行项目而不是$1000的单个行项目。然而，如图26中所示，为了对由分包商针对所请求的$1000分包合同行项目而提交的先前的支付请求做出解释，分包合同预算数据结构被更新为使得整体$1000的提议的变化量被分配到由分包商提议的单个新分包合同行项目(亦即，请求对象)。为了符合由总承包商的响应对象定义的结构，添加第二新分包合同行项目，但是初始地示出值$0。因为该分配不直接与由总承包商的响应对象命令的经批准的变化一致，所以该分包商可能需要更新并且协调每个新的分包合同行项目的分包合同SOV，以在可以代表分包商生成进一步的支付请求之前对该矛盾做出解释。

图27-图31提供总承包商与分包商之间的交互的另一个示例。与上面参考图17-图26所描述的示例相比，在本示例中，总承包商仅仅恰好如由分包商提议的那样来批准变化。图27示出请求值为$1000的新的分包合同行项目的“未提交”的请求对象。在图28中，在提议的变化被分包商提交之后，该请求对象已经被“提升”。图29示出从ERP系统接收的“未匹配”的响应对象。不像图19的示例那样，图29的响应对象包括与图28的已匹配的请求对象相同数量的项目和相同的合同组分值。在图30中，响应对象已经与请求对象合并——目标被更新为指向对应的包裹和项目ID，并且响应对象中的包裹和所有项目的状态被改变为“已合并”。因为图28的请求对象包括针对图30的响应对象中的每个项目的对应项目，所以响应对象中没有项目被直接置为目标指向分包合同预算数据结构或者使它们的状态改变为“已提升”。如图31中所示，当变化恰好如请求的那样被批准时，实际的分包合同预算数据结构最终被更新为恰好匹配提议的分包合同预算数据结构(亦即，图23)。

图32-图36例示又另一个示例。在该场景中，总承包商已经拒绝分包商所请求的变化。图32和图33中“未提交”的请求对象和“已提升”的请求对象分别与先前的示例中相同。然而，在图34和图35的“未匹配”的响应对象和“已提升”的响应对象中，新的合同组分的值分别被设置为$0而不是$1000。作为结果，在完成匹配和合并之后，分包合同预算数据结构被更新为包括由分包商提议的新的分包合同行项目，但是如响应对象所命令的，该新的行项目的值被设置为$0。

上面讨论的具体示例和场景旨在是示例性而不是排他性的。例如，上面描述的机制可以用来调控在美国的发票的创建，在澳大利亚的进度款要求，或者与其他司法管辖区有关的其他支付请求机制。照此，上面使用的预算和支付术语旨在同等地应用于其他司法管辖区中所使用的其他各种术语。

虽然上面讨论的示例数据结构包括文本组分——例如，文本“状态”指示符，但是将理解的是，可以用数字地实现这些状态标识符。例如，“未提交”或者“未匹配”的初始态状态可以指派第一状态标识符值“1”，而“已筹划”阶段由第二状态标识符值“2”代表，并且“已合并”和“已提升”的结束状态分别由第三状态标识符值和第四状态标识符值3和4代表。而且，如上面讨论的，本文的示例主要讨论总承包商与分包商之间的交互。然而，该系统和方法可以同等地应用于其他参与者，包括例如建设师、银行、产权人、总承包商、主管承包商、分包商、材料供应商等。

因此，除其他以外，本发明还提供用于通过使用链接的数据结构处理预算变化并且根据这种提议的预算变化来跟踪和便于支付的系统。本发明的各种特征和优点在下面的权利要求书中陈述。

Claims (22)

1.一种处理建设工程合同的变化的计算机实现的方法，所述建设工程合同在承包商与第二方之间，所述建设工程合同针对要由所述承包商为所述第二方在建设工程上执行的工作，所述方法包括：

响应于接收到对所述建设工程合同的提议的变化,由基于计算机的系统生成请求对象数据结构，所述提议的变化由所述承包商发起，所述请求对象数据结构包括至少一个新的合同组分项目，所述请求对象数据结构的所述至少一个新的合同组分项目包括第一新的合同组分项目，该第一新的合同组分项目包括识别第一新的合同行项目的项目ID的项目ID字段、识别在合同预算数据结构中用于新的合同行项目的存储位置的目标字段，以及识别所述新的合同行项目的提议值的提议值字段；

将所述请求对象数据结构存储在所述基于计算机的系统的非临时性计算机可读存储器上；

将所述请求对象数据结构的副本传输到与所述第二方相关联的外部系统；

由所述基于计算机的系统从与所述第二方相关联的所述外部系统接收响应对象数据结构，所述响应对象数据结构指示对所述建设工程合同的经批准的变化，所述响应对象数据结构包括至少一个新的合同组分项目，所述响应对象数据结构的该至少一个新的合同组分项目包括第一新的合同组分项目，该第一新的合同组分项目包括目标字段以及识别所述新的合同行项目的批准值的批准值字段；

通过至少识别被包括在所述请求对象数据结构的所述提议的变化和所述响应对象数据结构的所述经批准的变化二者中的相似的标识符而自动地确定匹配数据结构，其中所述请求对象数据结构对应于所述响应对象数据结构；

响应于自动地确定所述匹配数据结构，由所述基于计算机的系统接收匹配指令，所述匹配指令将所述请求对象数据结构和所述响应对象数据结构识别为都对应于由所述承包商发起的所述提议的变化；

自动地将包含所述提议的变化的所述请求对象数据结构链接到包含所述经批准的变化的所述响应对象数据结构，以使得在所述请求对象数据结构上采取的后续动作被索引和识别为与所述响应对象数据结构相对应；

响应于接收到所述匹配指令，将响应对象数据结构的第一新的合同组分项目的目标字段自动地更新为包括对应的请求对象数据结构的第一新的合同组分项目的项目ID；以及

将所述合同预算数据结构更新为在由所述请求对象数据结构的第一新的合同组分项目的目标字段识别的所述存储位置处包括所述新的合同行项目，所述新的合同行项目包括基于来自所述响应对象数据结构的第一新的合同组分项目的批准值而定义的成本值。

2.根据权利要求1所述的方法，其中生成所述请求对象数据结构包括当生成请求对象时生成包括指示所述请求对象的状态条件的状态字段的请求对象数据结构，并且将第一状态条件指派给所述请求对象数据结构，所述方法还包括：

从所述承包商接收用于所述请求对象的提交指令；

响应于接收到所述提交指令，更新所述状态字段以将第二状态条件指派给所述请求对象；以及

仅当所述请求对象数据结构的状态字段指示所述请求对象数据结构的状态条件是所述第二状态条件时，将所述请求对象数据结构的第一新的合同组分项目的目标字段更新为识别所述合同预算数据结构中用于所述新的合同行项目的存储位置。

3.根据权利要求2所述的方法，还包括：

当所述请求对象数据结构的状态字段指示所述请求对象数据结构的状态条件是所述第一状态条件时，允许所述承包商编辑所述请求对象数据结构的细节；以及

当所述请求对象数据结构的状态字段指示所述请求对象数据结构的状态条件不是所述第一状态条件时，阻止所述承包商编辑所述请求对象数据结构的细节。

4.根据权利要求1所述的方法，还包括由所述基于计算机的系统发起支付给所述承包商的支付请求，其中在接收所述响应对象数据结构之前接收所述支付请求，并且其中所述支付请求根据所述项目ID识别所述请求对象数据结构的第一新的合同组分项目。

5.根据权利要求4所述的方法，还包括仅在接收到所述响应对象数据结构之后并且只有当所述支付请求所请求的支付量不大于所述新的合同行项目的由所述响应对象数据结构定义的批准值时，才处理对所述支付请求的批准。

6.根据权利要求1所述的方法，还包括：

由所述基于计算机的系统从与所述第二方相关联的所述外部系统接收第二响应对象数据结构，所述第二响应对象数据结构指示对所述建设工程合同的未经批准的变化，所述第二响应对象数据结构在指示经批准的变化的所述响应对象数据结构之前被接收；以及

由所述基于计算机的系统接收第二匹配指令，所述第二匹配指令将所述请求对象数据结构和所述第二响应对象数据结构识别为都对应于由所述承包商发起的所述提议的变化。

7.根据权利要求6所述的方法，还包括：

由所述基于计算机的系统发起与所述提议的变化对应的支付给所述承包商的支付请求；以及

在接收到所述第二匹配指令之后并且在接收到指示经批准的变化的响应对象之前，处理对所述支付请求的批准。

8.根据权利要求1所述的方法，其中接收所述响应对象数据结构包括接收包括比对应的请求对象数据结构至少多一个新的合同组分项目的响应对象数据结构，所述响应对象数据结构的至少一个多的新的合同组分项目包括第二新的合同组分项目，所述第二新的合同组分项目包括第二新的合同行项目的目标字段和批准值，所述方法还包括：

将所述响应对象数据结构的第二新的合同组分项目的目标字段自动地更新为识别所述合同预算数据结构中用于所述第二新的合同行项目的存储位置；以及

将所述合同预算数据结构更新为在由请求对象的第二新的合同组分项目的目标字段识别的存储位置处包括所述第二新的合同行项目，所述第二新的合同行项目包括基于所述响应对象数据结构的第二新的合同组分项目的批准值而定义的成本值。

9.根据权利要求8所述的方法，还包括：

将所述响应对象的至少一个新的合同组分项目中的每个新的合同组分项目的状态字段更新为当目标字段识别与所述请求对象相关联的项目ID时指示第一状态条件，并且当目标字段识别所述合同预算数据结构中用于新的合同行项目的存储位置时指示第二状态条件。

10.根据权利要求1所述的方法，其中第二参与者包括所述建设工程的总承包商，并且所述承包商包括分包商，所述方法还包括：

将所述建设工程的总承包商预算存储在所述基于计算机的系统的非临时性计算机可读存储器上，所述总承包商预算包括多个总承包商预算行项目以及每个总承包商预算行项目的成本值；

将所述合同预算数据结构存储在所述基于计算机的系统的非临时性计算机可读存储器上，所述合同预算数据结构链接到所述多个总承包商预算行项目中的第一总承包商预算行项目并且包括多个合同行项目以及每个合同行项目的成本值；以及

响应于所述合同预算数据结构被更新为包括所述新的合同行项目，更新所述第一总承包商预算行项目的成本值。

11.根据权利要求1所述的方法，还包括在用户界面上向所述第二方显示所有未决定的提议的变化的列表，并且其中接收匹配指令包括接收从所有未决定的提议的变化的列表中对与所述请求对象数据结构对应的未决定的提议的变化的选择。

12.根据权利要求1所述的方法，其中接收所述响应对象数据结构包括接收包括识别所述请求对象数据结构的字段的响应对象数据结构，并且其中接收所述匹配指令包括基于识别请求对象数据结构的响应对象数据结构的字段而将请求对象与响应对象配对。

13.根据权利要求1所述的方法，还包括：

由所述基于计算机的系统从与所述第二方相关联的所述外部系统接收第二响应对象，所述第二响应对象指示对所述建设工程合同的第二经批准的变化，第二响应对象数据结构包括至少一个新的合同组分项目，所述第二响应对象数据结构的所述至少一个新的合同组分项目包括第三新的合同组分项目，所述第三新的合同组分项目包括目标字段以及识别第三新的合同行项目的批准值的批准值字段；

接收确认所述第二响应对象数据结构将不匹配到任何请求对象的指令；

响应于接收到该指令，将所述第二响应对象数据结构的第三新的合同组分项目的目标字段自动地更新为识别合同预算数据结构中用于所述第三新的合同行项目的存储位置；以及

将所述合同预算数据结构更新为在由所述第二响应对象的第三新的合同行项目的目标字段识别的所述存储位置处包括所述第三新的合同行项目，所述第三新的合同行项目包括基于来自所述第二响应对象数据结构的第三新的合同组分项目的批准值而定义的成本值。

14.根据权利要求13所述的方法，其中接收确认所述第二响应对象数据结构将不匹配到任何请求对象的指令包括通过用户界面从所述第二方接收用户输入。

15.根据权利要求13所述的方法，其中接收确认所述第二响应对象数据结构将不匹配到任何请求对象的指令包括自动地识别所述第二响应对象数据结构中指示所述第二响应对象数据结构不对应于任何请求对象的指示符。

16.根据权利要求1所述的方法，其中接收所述响应对象数据结构包括接收响应对象数据结构，在所述响应对象数据结构中所述新的合同行项目的由所述响应对象数据结构的第一新的合同组分项目的批准值字段识别的批准值与所述新的合同行项目的由所述请求对象数据结构的第一新的合同组分项目的提议值字段识别的提议值不同。

17.一种在基于计算机的预算管理系统上处理预算变化的计算机实现的方法，所述方法包括：

将合同预算数据结构存储在非临时性计算机可读存储器上，所述合同预算数据结构包括总合同预算量、多个合同预算行项目对象以及所述多个合同预算行项目对象中的每个合同预算行项目对象的行项目值；

由所述预算管理系统从第一用户接收针对由所述第一用户在工程上执行的工作的第一支付请求，所述第一支付请求引用至少一个合同预算行项目对象；

由所述预算管理系统从所述第一用户接收对于所述合同预算数据结构的总合同预算量的新变化的请求；

响应于接收到对于所述新变化的请求，生成提议的预算变化数据结构，所述提议的预算变化数据结构包括合同组分项目，所述合同组分项目包括要被添加到所述合同预算数据结构的提议的新的合同预算行项目对象的值和项目ID；

通过至少识别被包括在包含所述总合同预算量的所述合同预算数据结构和所述提议的预算变化数据结构二者中的相似的标识符而自动地确定匹配数据结构，其中所述合同预算数据结构对应于所述提议的预算变化数据结构；

自动地将包含所述总合同预算量的所述合同预算数据结构链接到包含对于所述新变化的请求的所述提议的预算变化数据结构，以使得在所述合同预算数据结构上采取的后续动作被索引和识别为与所述提议的预算变化数据结构相对应；

由所述预算管理系统从所述第一用户接收针对由所述第一用户在所述工程上执行的工作的第二支付请求，所述第二支付请求引用所述提议的预算变化数据结构的所述提议的新的合同预算行项目对象；以及

更新所述合同预算数据结构以包括被链接到所述合同预算数据结构的所述提议的预算变化数据结构的所述提议的新的合同预算行项目对象。

18.根据权利要求17所述的方法，还包括：

将工程预算数据结构存储在所述非临时性计算机可读存储器上，所述工程预算数据结构包括多个行项目对象以及所述多个行项目对象中的每个行项目对象的行项目值，

其中所述工程预算数据结构的所述多个行项目对象中的第一行项目对象与所述合同预算数据结构相关联，使得所述第一行项目对象的行项目值等于所述合同预算数据结构的总合同预算量；

从第二用户接收对于所述合同预算数据结构的总合同预算量的所述新变化的请求的批准；

将所述合同预算数据结构更新为包括所述提议的预算变化数据结构的所述提议的新的合同预算行项目对象；

基于所述提议的新的合同预算行项目对象的值，增加所述合同预算数据结构的总合同预算量；以及

将所述工程预算数据结构的所述第一行项目对象的行项目值更新为等于所述合同预算数据结构的增加后的总合同预算量。

19.根据权利要求18所述的方法，其中接收所述第二支付请求包括在从所述第二用户接收对于所述合同预算数据结构的总合同预算量的所述新变化的请求的批准之前接收所述第二支付请求。

20.一种建设工程合同和预算系统，被配置为处理建设工程合同的变化，所述建设工程合同在承包商与第二方之间，所述建设工程合同针对要由所述承包商为所述第二方在建设工程上执行的工作，所述系统包括：

处理器；以及

存储指令的非临时性计算机可读存储器，所述指令当由所述处理器执行时，使得所述系统执行如权利要求1-19中任一项所述的方法。

21.一种存储指令的非临时性计算机可读存储器，所述指令在由一个或多个处理器执行时，使得所述一个或多个处理器执行如权利要求1-19中任一项所述的方法。

22.一种包括用于执行如权利要求1-19中任一项所述的方法的单元的装置。

Images