计划/范围管理中的项目工作项目变更和商业信息协作系统及方法

专利名称：计划/范围管理中的项目工作项目变更和商业信息协作系统及方法
技术领域：
本发明涉及一种计算机系统以及方法，用于电子化地简化企业管理、数据处理、工作流程合作、以及与项目工作的计划或范围中的项目变更有关的管理。

背景技术：
即使当所有工作报表(SOW)和项目计划活动都按原来拟定那样来进行，项目工作的报价单和后续管理仍是一种非常复杂的处理。然而，常常有延迟和或打乱计划的因素，其表示需要管理活动的计划方面项目变更(ClP)。此外，有时会需要专门研究根据项目开始时定义的范围方面项目变更(CIS)活动。这些CIP和CIS活动不仅仅会显著地影响项目计划职能，而且会显著地影响采购、供应商管理、帐目、发货&接收、以及有时会影响整个企业。
这些CIP和CIS活动对项目具有广泛的影响，所述项目诸如但不限于，项目成本/预算、项目时间/调度、项目可交付/输出、项目工作报表、项目供应商的利用、项目人力资源的有效性、项目设备的交付、合同条款&条件以及供应商报酬的核发。因此需要一种系统和方法，用其能够在单个应用处理环境内定义、管理并处理这些CIP和CIS活动，借此提供透明度、决策支持、事务管理的数据处理能力、以及所有被影响的项目工作团队成员之间的协作，所述团队成员处理以下方面的项目工作生命周期要素投标管理、采购定单处理、人力资源管理、资产管理、SOW供应、凭证处理、质量保证、供应商管理、发货/接收、预算、帐目、审计及企业在其合作工作环境内需要采用的其他特定职能角色。


发明内容
一种项目工作行政管理方法，包括从买方接收项目管理配置、存储与要由供应商执行的买方的项目工作有关的交易项目工作数据、从买方接收项目工作报表(SOW)记录集合、对买方的计划/范围记录集合中的项目变更进行处理、对供应商的计划/范围记录集合中的项目变更进行处理、以及利用买方的记录集合和供应商的记录集合来创建计划/范围记录集合中的综合项目变更。
一种项目投资记录创建方法，包括创建适合于存储项目组属性、买方机构、以及商业所有权可信赖性数据的项目组记录、创建适合于存储买方项目数据的至少一个项目主记录、存储项目组记录与至少一个项目主记录之间的联系、存储至少一个项目主记录之间的适当依赖关系、以及存储适用于该项目组的默认买方机构和商业所有权数据。
一种配置项目可交付记录的方法，包括使不可交付的项目工作活动采购定单系列内容与采购定单交付记录的至少一个采购定单可交付系列内容相关、确定与采购定单可交付记录有关的属性数据、创建至少一个项目工作阶段记录、确定与至少一个项目阶段记录有关的属性数据、配置采购定单可交付记录相关性、以及把采购定单可交付记录加入配置到主数据记录。
一种评估计划/范围中的项目变更的方法，包括响应于买方处理的供应商提交的项目工作回执凭证而执行项目可交付依存性和主记录加入分析、识别不符合预定完成日期的采购定单可交付记录、接收对至少一个不符合可交付记录的选择、产生项目风险通信会话、广播项目风险通信包、接收项目风险通信包响应、以及处理该项目风险通信包响应。
一种处理计划/范围中的项目变更的方法，包括创建计划/范围接受包中的项目变更、广播该计划/范围接受包中的项目变更、把该已广播的计划/范围接受包中的项目变更处理完成、以及提供计划/范围接受包中的所完成的被广播的项目变更。
一种创建计划/范围记录集合中的综合项目变更的方法，包括创建计划/范围项目变更定单中的至少一个项目变更、处理计划/范围项目变更定单中的至少一个项目变更、响应于对计划/范围项目变更定单中的至少一个项目变更的批准来处理至少一个主数据记录、以及更新至少一个所处理的主数据记录。



参考附图来描述本发明，其显示了本发明的重要实施例并且其通过参考而引入到此处的说明书中，其中 图1是包含在本发明之中的项目工作投标处理的高级功能视图； 图2A是本发明的计算机系统的网络图； 图2B是在买方网络处实现的本发明的计算机系统的替代网络图； 图3A和3B举例说明了本发明的计算机系统的物理网络体系结构； 图4A-4D是与图2A和2B所示的每一个用户模块相关的示范性主页； 图5是根据本发明的实施例，举例说明用于从事项目工作投标处理的示范性步骤的流程图； 图6根据本发明的实施例举例说明了卖方赋予资格处理的电子化简化过程用于定义卖方提供的和/或买方需要的项目工作的类型以及使买方为卖方赋与资格； 图7是根据本发明的实施例，举例说明用于使买方为卖方赋与资格的示范性步骤的流程图； 图8举例说明了包含在响应投标需要中的示例信息处理以及对该信息处理负责的各种用户角色； 图9是根据本发明的实施例，举例说明用于定义和分配包含在项目工作处理中的各种资源的示范性步骤的流程图； 图10是根据本发明的实施例，举例说明用户角色的定义和分配的数据库表视图； 图11是为用户角色分配资源的示范性屏幕快照； 图12是根据本发明的实施例，举例说明用于在投标或项目交易期间定义和分配用户角色的示范性步骤的流程图； 图13A和13B是根据本发明的实施例，举例说明用于基于用户角色来管理与投标或项目交易相关的工作流程的示范性步骤的流程图； 图14是根据本发明的实施例，举例说明用于改进用户角色分配的示范性步骤的流程图； 图15是根据本发明的实施例，举例说明用于产生对具体项目的投标请求的投标模板创建工具和投标请求创建工具的数据流程图表； 图16A-16D是举例说明用于创建投标模板、根据投标模板创建投标请求、根据投标请求创建投标响应的示范性步骤的流程图； 图17是举例说明从中可创建投标模板的分层次投标内容列表的数据库表视图； 图18是举例说明用于访问该分层次投标内容列表以创建投标模板的示范性步骤的流程图； 图19是举例说明创建投标模板的屏幕快照； 图20是根据本发明的实施例，举例说明用于利用投标模板产生投标请求的示范性步骤的流程图； 图21-22是举例说明与具体的投标模板有关的各种类型的投标内容的屏幕快照，所述具体的投标模板被从中选出以包含于该投标模板类型的一次投标中； 图23是举例说明用于控制给与合格卖方投标请求的通信的示范性步骤的流程图； 图24是举例说明对合格卖方的选择以接收投标请求的屏幕快照； 图25是根据本发明的实施例，举例说明卖方投标响应处理中的示范性步骤的流程图； 图26-28是举例说明卖方投标响应处理的屏幕快照； 图29是根据本发明的实施例，举例说明投标请求和卖方投标响应数据之间的相互关系的数据库表视图； 图30是举例说明提供给买方的各种投标处理特征的屏幕快照； 图31是根据本发明的实施例，举例说明卖方投标响应等级的电子简化的数据流程图； 图32和33是根据本发明的实施例，举例说明用于对卖方投标响应分等级的示范性步骤的流程图； 图34A-34E是举例说明示例投标响应分等级处理的屏幕快照； 图35是根据本发明的实施例，举例说明投标请求、卖方投标响应与卖方投标响应的等级之间的相互关系的数据库表视图； 图36是根据本发明的实施例，举例说明基于卖方投标响应等级的卖方重新报价处理的流程图； 图37是根据本发明的实施例，举例说明项目管理设置处理中的示范性步骤流程图，其中项目被授与卖方并且项目的内容与条件被定稿并输入计算机系统以跟踪重要事件和交付； 图38是根据本发明的实施例，举例说明用于给项目批准所分配的资源的示范性步骤的流程图； 图39A是举例说明示范性买方项目管理特征的屏幕快照； 图39B是举例说明示范性卖方项目管理特征的屏幕快照； 图40A是举例说明用于键入示范性项目纳税信息的界面的屏幕快照； 图40B是举例说明包括所键入的项目纳税信息的示范性请购单信息的屏幕快照； 图40C是举例说明用于键入并处理项目纳税信息的示范性步骤的流程图； 图41是举例说明由本发明的计算机系统处理的各种项目管理组成部分的数据库表视图； 图42是举例说明可由本发明的计算机系统所管理的债务问题的类型的屏幕快照； 图43是根据本发明的实施例，举例说明用于键入项目的承包商时间的示范性步骤的流程图； 图44-46是举例说明保持处理的示例时间的屏幕快照； 图47是根据本发明的实施例，举例说明对项目交付进行跟踪和给予凭证的数据库表视图； 图48根据本发明的实施例，举例说明了用于提交和批准付款凭证并且创建付款凭证的付款凭证处理的电子简化过程； 图49是根据本发明的实施例，举例说明了凭证支付处理的流程图； 图50是根据本发明的实施例，举例说明可支付凭证的产生的数据库表视图； 图51是举例说明项目财务数据的屏幕快照； 图52是举例说明买方、卖方与系统之间的信息交流以简化对信息的分析的流程图； 图53根据本发明的实施例，举例说明了用于把与项目性能有关的项目执行数据键入系统中的示范性功能； 图54-56是举例说明用于键入项目执行数据的示范性步骤的流程图； 图57是根据本发明的实施例，举例说明项目执行数据的存储的数据库表视图； 图58举例说明了与本发明的数据库系统内存储的投标/项目处理有关的示范性交易数据； 图59举例说明了从多个买方数据库到中央数据库的交易数据示范性传送； 图60根据本发明的实施例举例说明了交易数据的分析和报告的电子简化过程； 图61-67是根据本发明的实施例，举例说明了用于分析交易数据并提供分析数据的示范性步骤的流程图； 图68根据本发明的实施例举例说明了用于对交易数据进行过滤以提供与所过滤的交易数据有关的分析数据的过滤处理的电子简化； 图69是根据本发明的实施例，举例说明用于对交易数据进行过滤以提供由过滤的交易数据产生的分析数据的示范性步骤的流程图； 图70是举例说明用于产生并显示分析数据的示范性项目报告类型的屏幕快照； 图71-88是举例说明示范性项目报告视图的屏幕快照，每个项目报告视图包含有分析数据； 图89是与项目工作和对计划或范围的适当项目变更有关的复杂企业商业动态的视图； 图90是描述商业应用处理环境的示意图； 图91是举例说明用于从事项目工作行政管理处理的示范性步骤的流程图； 图92是举例说明用于从事PCIP/S解决方案而不依靠必要的采购功能的示范性步骤的流程图； 图93是表示本发明的各个实施例内采用的代表全部PCIP/S商业方法的处理流程图； 图94A是描述项目组记录的创建的处理流程图； 图94B是描述项目主记录的创建的处理流程图； 图95A是描述预算组记录的创建的处理流程图； 图95B是描述预算主记录的创建的处理流程图； 图96A是描述资产组记录的创建的处理流程图； 图96B是描述资产主记录的创建的处理流程图； 图97是描述合同主记录的创建的处理流程图； 图98是描述商业事件记录的创建的处理流程图； 图99是描述项目主记录到其他主数据组成部分的映射的处理流程图； 图100举例说明了买方用户的示范性项目管理主页用户界面； 图101举例说明了支持预采购数据获取、存储和配置活动的示范性可行的数据库模式； 图102是一种改进的处理工作流程，在此流程中出现了将项目主记录集成到RFx投标处理中； 图103是一种支持把项目主记录集成到项目工作交易数据中的改进数据库模式； 图104是本发明原理的环境中工作报表(SOW)动态的示意图； 图105是经由用户导航和记录选择而从项目管理主页访问的示范性买方用户项目主网页； 图106是描述把项目工作加入可交付/SOW记录的示范性处理工作流程示意图； 图107是描述项目阶段记录创建的示范性处理流程图； 图108是描述把采购定单SOW记录加入/映射到项目阶段记录的示范性处理流程图； 图109是描述SOW记录以进行SOW记录加入和依存性配置的示范性处理流程图； 图110是描述SOW记录以进行预算记录加入的示范性处理流程图； 图111是描述SOW记录以进行资产记录加入的示范性处理流程图； 图112是描述SOW记录以进行合同记录加入的示范性处理流程图； 图113是描述SOW记录以进行商业事件记录加入的示范性处理流程图； 图114是描述项目组的报表总结和项目主记录的示范性用户界面网页； 图115是支持SOW记录配置的示范性数据库模式； 图116是处理和跟踪数据的交易项目工作数据用于报告关于风险依存的SOW和所加入的主数据记录的输出的示范性处理流程图； 图117-119是描述PCIP/S风险通信会话的示范性处理工作流程图； 图120是支持PCIP/S风险通信会话的示范性数据库模式； 图121-122是描述PCIP/S供应商接受包的示范性处理工作流程图；以及 图123是图120的展开图，其中已经集成了PCIP/S供应商接受包的支持数据库模式； 图124举例说明了PCIP/S记录批准和集成会话处理流程； 表的简要说明 除了数据库表1-112之外，参考附加的数据库表而描述了本发明的各个实施例，其中 表113是含有由买方实体所利用的项目组的一般商业数据的特性的示范性存储表； 表114是含有由买方实体所利用的项目主记录的一般商业数据的特性的示范性存储表； 表114A是含有项目组内包含的项目之间的关系的示范性存储表； 表115是含有用于定义项目组内包含的项目之间的关系的相应值的示范性存储表； 表116是含有适用于买方实体内所利用的成本中心、a.k.a.部门的特性和基本属性的示范性存储表； 表117是含有成本中心和项目之间的映射关系的示范存储表； 表118是含有由买方实体所利用的预算组的一般商业数据的特性的示范性存储表； 表119是含有由买方实体所利用的预算主记录的一般商业数据的特性的示范性存储表； 表120是含有成本中心和预算之间的加入关系的示范性存储表； 表121是含有由买方实体所利用的商业事件的一般商业数据的特性的示范性存储表； 表122是含有项目和商业事件之间的加入关系的示范性存储表； 表123是含有由买方实体所利用的合同记录的一般商业数据的特性的示范性存储表； 表124是含有项目和合同之间的加入关系的示范性存储表； 表125是含有由买方实体所利用的资产组的一般商业数据的特性的示范性存储表； 表126是含有由买方实体所利用的资产主记录的一般商业数据的特性的示范性存储表； 表127是含有项目和资产之间的加入关系的示范性存储表； 表128是含有项目和RFx投标之间的映射关系的示范性存储表； 表129是含有项目和采购定单请购单之间的映射关系的示范性存储表； 表130是含有与供应商采购定单有关的特性和属性的示范性存储表； 表131是含有与买方采购定单有关的特性和基本属性的示范性存储表； 表132是含有与买方采购定单系列有关的特性和基本属性的示范性存储表； 表133是含有与包含在买方采购定单系列上的项目工作活动有关的特性和属性的示范性存储表； 表134是含有与买方PO工作报表(SOW)记录有关的特性和属性的示范性存储表； 表135是含有包含在采购订单上的项目工作活动与SOW记录之间的映射关系的示范性存储表； 表136是含有与项目阶段记录有关的特性和属性的示范性存储表； 表137含有项目阶段记录和SOW记录之间的映射关系的示范性存储表； 表138是含有SOW记录之间的适当依存性映射关系的示范性存储表； 表139是含有SOW值到所利用的SOW记录依存性类型的示范性存储表； 表140是含有SOW记录和预算之间的映射关系的示范性存储表； 表141是含有SOW记录和资产之间的映射关系的示范性存储表； 表142是含有SOW记录和合同之间的映射关系的示范性存储表； 表143是含有SOW记录和商业事件之间的映射关系的示范性存储表； 表144是含有与买方PCIP/S风险会话有关的特性和属性的示范性存储表； 表145是含有适用于所利用的PCIP/S风险会话状态码的值的示范性存储表； 表146是含有适用于所利用的PCIP/S风险会话类型码的值的示范性存储表； 表147是含有适用于PCIP/S会话内所包含的SOW记录的特性和属性的示范性存储表； 表148是含有适用于PICP/S会话期间的买方用户响应状态码的值的示范性存储表； 表149是含有对PICP/S会话期间的项目工作采购定单活动记录所做出的状态或可变数据修改的示范性存储表； 表150是含有适用于PCIP/S会话期间所创建的新项目工作活动的特性和属性示范性存储表； 表151是含有定义所利用的项目工作活动可变数据字段修改类型的值的示范性存储表； 表152是含有定义所利用的可变数据字段修改活动的值的示范性存储表； 表153是含有对PICP/S会话期间的主数据记录所做出的可变数据修改的示范性存储表； 表154是含有定义所利用的主数据可变数据字段修改类型的值的示范性存储表； 表155是含有定义所利用的可变数据字段修改活动的值的示范性存储表； 表156是含有与买方PCIP/S供应商接受包会话有关的特性和属性的示范性存储表； 表157是含有适用于所利用的PCIP/S供应商接受包会话状态码的值的示范性存储表； 表158是含有适用于把供应商广播/邮寄记录加入PCIP/S供应商接受包会话的的特性和属性示范性存储表； 表159是含有适用于所利用的PCIP/S供应商接受包会话响应状态码的值的示范性存储表； 表160是含有关于PCIP/S供应商接受包会话期间所处理的记录的供应商数据验证和纳税评估响应的示范性存储表；以及 表161是含有关于在PCIP/S供应商接受包会话期间所处理的新活动记录的供应商数据供应、数据验证和纳税评估响应的示范性存储表。

具体实施例方式 具体地参考示范性实施例来描述本申请的许多创造性教导。然而，应当清楚这些实施例仅提供了此处的创造性教导的许多有益应用中的几个例子。通常，在本申请的说明书中所做出的陈述不是界定各个所请求的发明中任一个。此外，一些陈述适用于一些创造性特征，然而并不适用于其他的。
根据本发明的实施例，卖方是货物和/或服务的任意供应者，买方是货物和/或服务的任意购买者，承包商是由项目工作的卖方采用的资源以及管理员是第三方系统管理员或买方雇用的项目管理员。买方能够利用根据与项目类型有关的投标项目的预建立列表而产生的投标请求来以由买方指定的形式从卖方处请求对具体货物和/或服务(以下简称项目)的投标。因此，从卖方处提交的投标响应都具有相同的形式，允许投标响应的有效率且有效果的估价。本发明的实施例更进一步把投标处理与项目管理进行组合以在中标之后允许买方、卖方、承包商和管理员来跟踪项目性能。
根据本发明原理提供了一种计算机激活系统和方法，以便即使当商业机构没有参与到项目本身之中仍把项目工作的活动与其他企业商业机构和人员集成起来。提供了计划/范围(PCIP/S)中的项目变更行政管理功能，其允许企业限制适用于计划/范围中的变更的风险以及通过工作报表(SOW)依存性模型和合作工作流程处理来最优化数据处理和商业管理尝试。
一种典型的实施例包括下列方面的处理1)项目管理配置；2)交易项目工作数据的获取和存储；3)SOW记录配置；4)PCIP/S影响模型；5)风险通信会话；6)PCIP/S接受包会话；以及7)PCIP/S记录修改管理。
借助于下列应用组成部分和功能来支持典型实施例的各种处理 a)一种项目行政管理模式及应用工具组成部分，其允许买方实体来执行下述之一或之几1)创建项目组记录；2)创建项目主记录；3)使项目主记录与项目组相关联；4)定义项目组(项目层次)内的项目之间的关系；5)使各种商业属性既关联到项目组又关联到项目；6)创建SOW记录；7)使SOW记录与项目相关联；8)使SOW记录彼此相关联；9)定义相关的SOW之间的关系；10)创建关于买方实体内的商业事件的记录；11)使商业事件记录关联到项目；12)使商业事件记录关联到SOWs；13)创建预算组记录；14)创建预算主记录；15)使预算主记录关联到预算组记录；16)使预算主记录与项目记录相关联；17)使预算主记录与SOW记录相关联；18)创建合同记录；19)使合同记录关联到项目记录；20)使合同记录关联到SOW记录；21)创建资产组记录；22)创建资产主记录；23)使资产主记录关联到资产组记录；以及24)使资产主记录关联到SOW记录。
b)借助于SOW子模块把项目行政管理模式链接到项目工作解决方案生命周期处理的应用功能1)RFx投标、投标响应、中标；2)购买请购单(SOW元素)；3)采购定单(SOW元素)；4)凭证(对于使买方批准/验证SOW元素已经完成了的供应商请求)5)开具发票(有组织地提取适用于买方实体批准凭证的凭证细节)；6)支付；以及7)报告。
c)允许买方实体来进行以下操作的行政管理模式和应用工具1)管理/配置项目行政管理模块内的记录；2)查看有关/依存项目、有关/依存SOW单元、以及有关/依存商业记录的依存性识别/报告输出功能；3)选择特定SOW记录以及修改记录的状态或属性数据，诸如，状态或期望的完成日期，以基于在前的用户配置来产生系统诊断风险报告，其表表对有关商业记录的影响，诊断风险报告输出典型地提供对受影响的交付、服务单元、货物/发货、项目阶段、人力资源分配、采购订单/资金流动计划、预算/获利、有关商业事件、合同、资产管理、供应商、以及用户的查看；4)创建通信会话，借此可以向受影响的项目工作当事人提供适用于风险SOW元素和项目的信息，其中取决于用户配置和特定广播记录而例如可以以宏观或微观模式来广播所述通信，所述用户配置和特定广播记录是以允许适用于风险SOW元素的双向数据处理能力这种方式来配置的；5)以有组织地更新应用SOW元素、采购定单以及其它相关记录的方式来互相商定通信会话记录的处理，同时维护通信记录的历史以及取代SOW元素、采购定单及其他相关记录的处理；6)在假定SOW记录条件/状态类型变更的前提下有组织地初始化假设的记录集合的全局/宏观条件/状态码变更；7)在假定条件/状态类型变更的前提下有组织地初始化假设的记录集合的全局/宏观记录属性变更；8)依据系统的记录更新修改而向受影响的当事人发送通知；9)有组织地产生包括适用于风险SOW元素的相关RFx投标响应记录的报告；10)有组织地利用RFx投标内容元素以及RFx投标响应内容元素以创建能够被广播同时把数据库记录线程保留回原始SOW元素和关系的新的RFx投标；11)有组织地接收、审阅、分析供应商投标响应以及授予新采购定单同时把数据库记录线程保留回原始SOW元素和关系；12)借助于工作报表子模块依据采购定单SOW元素的集成来有组织地继承适用于失败/原始SOW元素的所有在前联系和依存性，其中利用RFx记录细节来处理新RFx；以及13)允许对于通过PCIP/S管理工具而继承依存性与关系的那些SOW记录的买方用户编辑/修改能力。
现在参考附图，图1是举例说明包含在本发明中的投标处理的高级功能视图。把与具体投标请求200有关的投标请求数据210从买方50提供给项目投标管理系统30。买方50可以是个人、企业实体或需要执行项目的任何其他类型的买方50。项目投标管理系统30处接收的投标请求数据210采用买方50预先指定的形式。例如，所述形式包括根据具体项目类型的投标内容的可配置预建立列表而选择的一个或多个投标内容，以及投标请求数据210可与一个或多个这些所选投标内容有关。
投标请求数据210由项目投标管理系统30来格式化并且作为投标请求200被传送给一个或多个卖方10a...10n以便请求相应的投标响应220。例如，卖方10可以是个人10a、企业实体10b或能够执行所请求项目的任何其他卖方10n。把投标响应220从卖方10提交给项目投标管理系统30以便在把赋予资格的投标响应2201发送给买方50之前进行审阅。例如，可以对项目投标管理系统30进行预配置来强制卖方以特定数据格式来完成所需要的投标响应内容以便允许系统30执行对卖方投标响应220的一些过滤。用这种方法，系统30可以保证买方50仅接收具有投标估价的必要数据的投标响应220。
根据本发明的实施例，项目投标管理系统30能够在计算机系统100内被实现，如图2A所示那样。用户5借助于网络浏览器20通过数据网络40进入计算机系统100。用户5包括与卖方10、买方50、管理员80(例如第三方或买方雇用的管理员)或指派到项目的承包商15有关的任何人。例如，而不是限制，数据网络40可以是互联网或内部网，并且浏览器20可以是任何可用的浏览器或提供对数据网络40进行访问的任何类型的互联网服务供应商(ISP)连接。卖方用户5通过卖方浏览器20b访问计算机系统，买方用户5经由买方浏览器20a访问计算机系统，承包商用户5经由承包商浏览器20c访问计算机系统以及管理员用户5通过管理浏览器20d访问计算机系统。用户5通过能够把网页分别推给卖方浏览器20a、买方浏览器20b、承包商浏览器20c和管理浏览器20d的网络服务器120或125来访问计算机系统100。
投标网络服务器120允许卖方10、买方50、承包商15以及管理员80以联接于数据库系统150，所述数据库系统150用于维护与卖方10、买方50、承包商15和管理员80有关的数据。为了安全和方便的目的，与每个卖方10、买方50、承包商15、以及管理员80有关的数据被存储在数据库服务器150内的单个数据库155、多个共享数据库155、或单独的数据库155中，稍后将举例说明。例如，取决于买方50、卖方10、管理员80、以及承包商15的位置和偏好，数据库系统150可分布在一个或多个位置。
由投标网络服务器120通过卖方模块115来提供卖方用户5的用户界面。例如，卖方模块115可利用具体卖方数据库155b中存储的数据来填充推给卖方浏览器20b的网络页面。由投标网络服务器120通过买方模块110来提供买方用户5的用户界面。例如，买方模块110可利用具体买方数据库155a中存储的数据来填充推给买方浏览器20a的网络页面。由投标网络服务器120通过承包商模块130来提供承包商用户5的用户界面。例如，承包商模块130可利用承包商数据库155c中存储的数据来填充推给承包商浏览器20c的网络页面。由投标网络服务器120通过管理模块135来提供管理员用户5的用户界面。例如，管理模块135可利用管理员数据库155d中存储的数据来填充推给管理浏览器20d的网络页面。应当注意到，卖方模块115、买方模块110、承包商模块130以及管理模块135都可以包括执行卖方模块115、买方模块110、承包商模块130以及管理模块135所需要的任何硬件、软件和/或固件，并且可以作为投标网络服务器120的一部分被实现、或在附加服务器(未显示)内被实现。
计算机系统100更进一步通过管理网络服务器125向管理员用户5提供附加用户界面。管理网络服务器125允许管理员80联接于高级数据库160，所述高级数据库160用于维护利用计算机系统100来登记的与卖方10、买方50以及承包商15有关的数据。例如，高级的数据库160能够维护卖方资格数据162、买方定义的卖方标准数据164、以及承包商再利用数据166。
为了访问与卖方10有关的信息，管理网络服务器125利用供应商模块145把网络页面推给与卖方10有关的管理浏览器20d。例如，卖方模块145可访问卖方资格信息162以使卖方10对于具体买方50或对于具体行业具有资格。同样地，管理网络服务器125可通过买方模块140把网络页面推给与买方定义的卖方标准信息164有关的管理浏览器20d以便使卖方10对于具体的买方50具有资格。承包商模块148允许管理员80访问承包商再利用数据166，所述承包商再利用数据166由承包商15通过投标服务器120而输入并且从承包商数据库155被检索到高级的数据库160中。再利用数据166可包括例如承包商变动性的表示、期望地理区域、承包商技术、期望付费及可用于在使卖方10对于买方50具有资格方面辅助管理员80的其他承包商信息。
在另一个实施例中，如图2B所示，计算机系统统100可以在买方网络中单独地实现。在图2B中，卖方用户5经由数据网络40通过卖方浏览器20b进入计算机系统100，如图2A那样。然而，图2B中的网络服务器120是由单个买方所控制并操作的买方网络服务器。数据库系统150仅存储与具体的买方有关的买方数据以及仅存储关于具体买方的卖方、承包商和管理员数据。例如，由买方赋予资格给仅仅那些卖方的卖方资格数据被存储在数据系统150中。
现在参考图3A，显示了用于实现计算机系统100的示范性物理网络装备。卖方用户、买方用户、承包商用户或管理员用户通过分别把计算机60a、60b、60c或60d连接到数据网络40来访问计算机系统100的网络服务器120。每个计算机60a-60d例如可以是个人计算机、膝上型计算机、连接到用于远程访问数据网络的无线设备的计算机、提供能够访问数据网络的浏览器的手持无线设备或实现浏览器的其他类型的机器。网络服务器120例如可以是微软公司Internet信息服务(IIS)服务器。网络服务器120取决于用户的类型而连接于适当的数据库系统150。数据库系统150例如可以在一个或多个SQL服务器中被实现。
现在转向图3B，显示了在计算机系统100的物理网络装备中实现的示范性功能。用户计算机60可利用计算机存储介质64内驻留的浏览器66来访问数据网络40。例如，该存储介质可以是磁盘驱动器、随机存取存储器(RAM)、只读存储器(ROM)、光盘、软盘、磁带驱动器或任何其他类型的存储介质。计算机60内的处理器62(例如，微处理器或微控制器)加载并运行网络浏览器66以访问数据网络40。
当把网络服务器120的统一资源定位符(URL)键入到计算机中时，就创建了计算机60与网络服务器120之间的连接。网络服务器120把网页61推给计算机60以便由用户在用户界面设备65上进行查看。在一个实施例中，用户界面设备65是连接到计算机60的计算机屏幕15。例如，一旦已经验证了用户(例如，通过键入用户名和密码)，则用户能够在计算机屏幕65上查看一个或多个网页61，每个网页61包含有让用户把各种信息键入计算机系统100中的提示。用户可经由I/O接口68和任何类型的输入设备70而把信息键入到计算机60中以经由数据网络40传送到网络服务器120，所述输入设备70诸如鼠标、键盘、光笔、触摸屏(未显示)或语音识别软件(未显示)。
在网络服务器120，处理器(例如，微处理器或微控制器)加载并运行存储介质124内存储的软件模块128中驻留的计算机指令，所述存储介质124可以是正如以上结合存储介质64所讨论的任何类型的存储介质。可利用任何类型的程序设计技术，包括面向对象编程技术，来创建计算机指令。例如，软件模块128可以包含卖方模块、买方模块、承包商模块和管理模块(图2A和2B所示)的计算机指令以便分别填充卖方用户、买方用户、承包商用户和管理员用户的网页61。根据注册到网络服务器120的计算机用户，处理器122访问适当软件模块128以判断与计算机用户有关的数据库系统150并在网页61中检索与全体计算机用户有关的数据以便在计算机60的计算机屏幕65上显示。此外，软件模块128更进一步被配置成存储从数据库系统150内的计算机用户处所接收到的数据。
图4A-4D分别显示了显示给买方用户、卖方用户、承包商用户以及管理员用户的网页61的例子。图4A举例说明了当买方用户注册和认证(例如，口令和响应认证)时显示给买方用户的示例买方主页61a。如图4A中所见，在买方主页61a上有很多对买方用户有效的系统特征。例如，可向买方用户提供链接以更新他们在系统中的个人概况、创建RFP/RFQ(此处被称为投标请求)、管制当前投标请求、批准卖方投标响应以把投标(项目)授予具体的卖方、处理当前项目、查看历史投标请求或访问凭证处理系统以查看用于跟踪诸如承包商计时卡之类的请求的各种项目相关事件。买方用户能够更进一步保持关于系统修改的更新、接收关于如何通过该系统进行操作以及通过买方主页61a联系系统管理员(例如第三方管理员或买方雇用的管理员)来求援的指令。
在图4A中，更进一步地主页61a上向买方用户提供待定投标和项目的当前状态。然而，应当清楚可以在后续网页中显示当前的活动，而不是在主页61a上。例如，可以向买方用户提供公开投标请求(所提交的投标请求)的数目和暂时保存的投标请求(所创建的而不是所提交的投标请求)的数目。通过点击公开投标请求按钮，买方用户可链接到另一个网页，所述网页显示了一个公开投标请求列表，其中具有到包含实际的公开投标请求的网页的后续链接。因此，从买方主页61a中，买方用户可链接到与买方用户能访问的投标或项目有关的任何信息。
图4B举例说明了包含许多对卖方用户有效的系统特征的示例卖方主页61b。例如，卖方主页61b提供链接以更新卖方概况(例如，卖方提供的货物和/或服务的类型)，响应所接收的投标请求，处理当前项目或访问凭证处理系统以查看现有项目事件完成请求或处理新项目事件完全请求。在图4B中，还向卖方用户提供待定投标和项目的当前状态。例如，卖方用户可判断卖方需要响应的投标请求的数目以及卖方还没有完成的暂时保存的投标响应的数目。从卖方主页61b中，卖方用户能够链接到附加网页以完成卖方投标响应或访问新接收的投标请求以开始卖方投标响应。
图4C举例说明了包含有许多对承包商有效的系统特征的示例承包商主页61c。例如，第一次承包商用户进入承包商主页61c时，在访问系统中的任何其他信息之前可以把承包商用户引导至同意各种非雇员工人协议。可以向承包商用户显示每一个非雇员工人协议，以及可提示承包商用户在继续之前同意或用其它方式接受协议条款。一旦承包商用户完成了所有协议，承包商用户就能够访问计时系统以键入承包商时间、更新他们的技术概况或提供再利用偏好。另外，在承包商主页61c上还可以向承包商用户显示与承包商用户有关的当前活动，诸如所请求的会见的数目或为附加项目所安排的会见。
图4D举例说明了包含有许多对管理员用户有效的特征的示例管理员主页61d。例如，管理员用户能够访问有关买方、卖方或承包商的信息，链接到包含有需要批准的投标请求的网页，批准投标响应以把投标授予给具体的卖方，处理当前项目或访问凭证处理系统以查看项目活动批准的现有卖方/承包商请求，诸如承包商计时卡。另外，管理员用户的当前活动也可以被显示在管理员主页61d上。例如，可以向管理员用户显示等待批准的投标请求的数目、新投标请求的数目以及新卖方响应的数目。从管理员主页61d中，管理员用户能够链接到与管理员用户能访问的投标处理或项目管理有关的任何信息。例如，如果管理员用户是第三方管理员，则管理员用户可访问利用该系统来注册的所有买方和卖方的投标和项目。然而，如果管理员用户是买方雇用的管理员，则管理员用户仅可访问与该具体的买方有关的投标和项目。
图5显示了由本发明的项目投标管理系统所处理的投标/项目处理500中的示范性步骤。在提交任何投标请求之前存在要处理的投标/项目处理的几个方面(步骤505)。例如，买方可能想创建一个具体投标请求类型的合格卖方的列表以减少投标请求期间的处理时间，如以下结合图6和7而详细描述的那样。作为另一个例子，买方、卖方和管理员可能想指定具体的人员以处理投标/项目处理的不同组成部分以便在投标/项目处理期间有效地发送消息和信息，如以下结合图8-14而详细地描述的那样。
一旦完成了所有投标前活动(步骤510)，买方为项目能够创建项目的投标请求(步骤520)，如以下结合图15-29而详细地描述的那样，以及如有必要，向管理员提交投标请求以进行批准(步骤525)，如以下结合图20而详细地描述的那样。大多数公司需要批准投标请求以用于预算目的。然而，如果买方是个人或小型企业，那么创建投标请求的买方用户可能不需要任何其他方面的批准来提交该投标请求。
一旦已经批准了投标请求，把投标请求广播(例如，经由具有可选择通知的系统借助于电子邮件而对卖方适用)给合格卖方(步骤530)，以从卖方处请求投标响应(步骤535)，如以下结合图23而详细描述的那样。由买方评估每一个投标响应，以判断哪个卖方投标响应是最合格的(步骤540)，如以下结合图32和33而详细描述的那样。买方选择了该项目的具体卖方之后，买方和卖方对合同的最终条款进行谈判(步骤545)并且把这些条款加载到用于项目跟踪目的的系统中(步骤550)，如以下结合图37而详细描述的那样。此后，卖方选择项目的特定资源(承包商)，以及如果该项目的条款需要资源的买方批准，则在项目继续之前买方批准所有分配的资源(步骤555)，如以下结合图38而详细描述的那样。
一旦完成了所有投标活动(步骤515)，系统更进一步能够处理投标后活动(步骤560)以在项目期间跟踪项目的执行和凭证的支付。例如，分配给该项目的卖方和承包商把工作时间和支出键入系统中(步骤565)以便产生要通过系统提交给买方的可支付凭证，如以下结合图43而详细描述的那样。当收到凭证时，买方和/或管理员能够对卖方进行审阅和批准该支付凭证(步骤570和575)，如以下结合图49而详细描述的那样。也可以把其他项目跟踪参数键入该系统以通过项目终止来跟踪卖方的执行(步骤580)，如以下结合图39和40而详细描述的那样。现在将在下文中单独地讨论投标/项目处理的每一个主要的组成部分(投标前活动、投标活动以及投标后-活动)。另外，在下文中将单独地讨论分析和在投标/项目处理期间所收集的数据的报告。
投标前活动 正如以上的讨论，买方50想预先对具体项目类型的卖方10赋矛资格以减少每个所提交的投标请求所需要的处理数量。现在参考图6，为了简化对于买方的卖方资格赋予，计算机系统100可允许买方50建立对于卖方的买方定义卖方标准数据164并且在主要买方列表161中的高级数据库160内存储该买方定义卖方标准数据164。计算机系统100能够更进一步从卖方10处获得相关卖方资格数据162并且把该卖方资格数据162存储在主要卖方列表163中的高级数据库160中。
例如，卖方资格数据162能够识别卖方10提供的特定货物和/或服务以及卖方10能够提供这些货物和/或服务的特定地区，以及其他卖方信息，诸如卖方的规模、卖方是否有保险、卖方是否在某些行业中被证明等等。买方定义卖方标准数据164能够识别买方50要求的特定货物和/或服务、买方50想要货物和/或服务的特定地区、以及其他买方约束条件，诸如卖方的优选规模、必要的卖方保险要求、必要的卖方认证等等。
根据卖方资格数据162和买方定义卖方标准数据164，计算机系统100能够判断出哪个卖方10具备买方50必需的资格并且提供合格卖方信息170(例如，名称、地址、以及买方需要的任何其他卖方信息)以供买方50审阅。如果买方50或选择性地管理员80对卖方10表示满意，则买方50可以把卖方信息170增加到卖方列表158，所述卖方列表158存储在买方数据库155a中。另外，买方50预先赋予资格的那些卖方10的卖方信息172也可以存储在卖方列表158中。此外，卖方列表158的主(即，买方的主卖方列表165)可存储在高级数据库160中以用于重复和更新的目的。
买方信息174(例如，名称、地址及买方同意提供的其他信息)也可以被下载到卖方数据库155b以存储在其中的买方列表159中。另外，买方列表159的主(即，卖方的主买方列表167)可存储在高级数据库160中以用于重复和更新的目的。然而，应当清楚如果计算机系统100是在买方网络中被单独地实现的，那么高级数据库160不会存储主165和167，以及买方50会仅利用买方50已知的或由卖方10直接提供给买方50的卖方信息172来执行卖方资格赋与。为了根据卖方资格数据162和买方定义卖方标准数据164来完整的讨论买方50对卖方10赋予资格，参考序号为10/141,801的共同待审及一般指定的美国专利申请，此处通过参考而引入其全部内容。
图7显示了买方对卖方赋予资格的示范性步骤。一旦建立了买方定义的卖方标准信息(步骤700)并且接收了来自卖方的卖方信息资格(步骤710)，就把该买方定义的卖方标准信息与卖方资格信息相比(步骤720)以判断卖方资格信息是否与买方定义的卖方标准信息相匹配(步骤730)。如果是这样的话，向卖方和买方通知该匹配(步骤740)，以及如果买方批准了卖方，则把与卖方有关的卖方信息存储在买方的卖方列表中以便随后用在准备投标请求中(步骤750)。另外，可把买方信息存储在卖方的买方列表中以便在接收投标请求和准备投标响应时参考(步骤760)。
然而，如果卖方资格信息不与买方定义的卖方标准信息相配(步骤730)则系统判断是否需要附加卖方资格信息以使买方对卖方赋予资格(步骤770)。如果是这样的话，则请求卖方提供这些附加卖方资格信息(步骤780)以使买方对卖方赋予资格(步骤710)。否则，买方不对卖方赋与资格(步骤790)，并且不把卖方加到买方列表中。
除了买方对卖方赋予资格之外，卖方、买方以及管理员可能想指定某些人员来处理投标/项目处理的各个方面以跨越多个用户平台实现通信、数据和交易处理的同步。例如，现在参考图8，投标/项目处理典型地需要包含许多信息处理和职能部门以简化投标/项目处理的主管和管理。这种信息处理包括例如投标请求广播、卖方投标响应、投标意向(估价及授予)、资源提供、计时卡提交、交付跟踪以及付款凭证。这些信息处理组成部分中的每个可以由一个或多个不同的个人或部门来处理，诸如COO、人力资源部门、项目用户以及财务处理员。为了满足这种职能需要，本发明的计算机系统允许共享工作环境，其中买方、卖方和/或管理员能够指定需要参与到投标/项目处理中的多个自定义用户角色，为所有投标/项目或具体的投标/项目的每一个用户角色指定人员(资源)。
现在参考图9，举例说明了用于指定用户角色职位和为卖方、买方或管理员的用户角色职位分配人员的示范性步骤。最初，卖方、买方或管理员判断投标/项目处理需要的特定用户角色职位(步骤900)。例如，如图11的示例买方网页所示，买方可决定在项目/投标处理期间需要几种不同的用户角色类别，诸如财务批准员、非财务批准员、计时卡审阅者、主管代表、项目重要事件管理员、财务协调员以及人力资源伙伴。卖方、买方或管理可进一步决定投标/项目处理需要的一个或多个用户角色类别内的多个用户角色职位。例如，如图11所示，买方可决定需要6个财务批准员和2个非财务批准员。
再次参考图9，一旦决定了用户角色职位，则存储卖方、买方或管理员的相关人员的数据文件以用于为每一个用户角色职位选择适当的人员(步骤905)。可选择卖方、买方或管理员的一个或多个主要工作人员(例如，COO、项目用户等等)以指定具体人员分配到每一个用户角色职位(步骤910)，或者系统根据人员数据文件中包含的信息来给人员分配用户角色职位。在一些公司中，用户角色职位是预先指定的(步骤915)，而在这种情况下，可以把预先指定的人员加载到系统中(步骤920)以及存储在用户角色表中(步骤925)。例如，对于大部分卖方来说，把人员预先分配给所有项目的各个用户角色职位。在其他公司中，一个或多个用户角色职位根本不会被预先指定或者对于具体项目而言不会预先指定(步骤915)，而在这种情况下，所选择的主要工作人员或系统能够把特定人员分配给该用户角色职位。
为了把特定人员分配给用户角色职位，选择特定用户角色职位(步骤930)，以及根据人员数据文件来决定人员列表(步骤935940以及945)，所述人员列表可取决于用户角色约束条件而被分配给该用户角色职位。例如，如果用户角色职位需要具体级别的用户，则仅把该具体用户级别或更高级别的那些人员包括在列表中。根据用户角色职位的人员的列表，为具体的用户角色职位选择一个人员(步骤950)，并且把所选人员存储在用户角色表中(步骤925)。例如，如图11所示，当选择具体的用户角色职位(例如，点击用户角色职位)时，系统能够搜索该用户角色职位的合格人员，以及在做出选择之后，显示该用户角色职位的所选人员。
在下文在表1-9中显示了为买方选择和分配用户角色职位的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织，其中每个表包括为买方定义和分配用户角色职位所需的所有字段。该表是以分层次和/或相关的方式而关联的，以便能够准确地存储和访问用户角色职位的所有必要信息，如下文中结合图10的示范性数据库表结构300而描述的那样。然而，应当清楚可以包括其他买方用户角色配置，并且系统不局限于表1-9或图10中所列的特定买方用户角色配置。
下面的表1和2分别举例说明了每一个用户角色类别内的示例用户角色类别和用户角色职位，其分别存储在表tblHMPositionCategories 305和tblHMPositions 306中的数据库中，如图10所示。在表1中，为每个用户角色类别分配标识号以及显示顺序以在网页上进行显示。用户角色类别标识号被用在用户角色职位表(表2)内以使该用户角色职位与特定用户角色类别相关。然而，应当清楚可能会有很多附加的类别和职位，这取决于买方的需要。当最初选择该用户角色职位时，显示用户角色类别以使用户利用每一个类别内的特定用户角色职位的链接来从中进行选择。在为具体的买方选择了所有用户角色职位之后，如图11中那样来显示所选用户角色职位和所分配的人员。
表1 表2 示范性用户角色职位(tblHMPositions) 下面的表3举例说明了系统的每个用户的人员数据文件内存储的示例数据，其可能被存储在表tblUser 302中的数据库中，如图10所示。根据这个用户数据，可以决定每个用户角色职位的合格人员，以及能够确定每个用户角色职位的每个所分配用户的必要信息。表3内的字段之一是为该具体用户分配的商业等级。该商业等级表示用户在商业系统中的具体级别。例如，用户可能是3级用户，并且要把该信息存储在用户表中。把有效的商业等级映射到用户角色职位，如下面的表4和5所示，以表示为每个用户角色职位所分配的用户所需要的商业等级，其可以被存储在表tblHMBusinessGrades303和tblHMPositiontoGradeMap 304中的数据库中，如图10所示。
表3 基本系统用户表(tblUser) 表4 基本商业等级表(tblHMBusinessGrades) 表5 用户角色对商业等级映射表(tblHMPositiontoGradeMap) 在下文中将结合图10来详细描述下面的表6-9。
表6 职位/角色对投标模板映射表(tblHMPositionsRFXMatrix) 表7 默认用户角色映射表(tblHMPositionsRelationships) 表8 用户角色对投标请求映射表(tblBidHMPositions) 表9 用户职位/角色对批准级别和层次映射(tblApprovalLevel) 如图10中可见到的那样，在需要的所有字段之间存在一种简要的关系以允许可配置工作共享和买方的特定工作流程组成部分。数据库结构300是可伸缩且可配置的，以便即使当在更小的成熟数据库环境内操作时，该功能仍然可存在象用户角色职位被指定以及人员数据文件有效那样久。应当清楚类似数据库表结构对卖方和管理员也有效，这将在下文中更详细地讨论。
买方的数据库表结构300从买方取得输入人员数据(tblHRdata 301)并且创建人员数据文件(tblUser 302)，所述人员数据文件包括共享工作环境中所涉及的特定人员。为简单起见把人员数据显示为表tblHRdata 301。然而，应当清楚人员数据可以采用任何形式，这取决于买方数据库系统。可以执行从表tblHRdata 301周期性地下载到表tblUser 302以更新系统，以便买方的当前雇员可保证适当地分配用户角色职位。由买方指定的各个商业等级也可以存储在表tblHMBusinessGrades 303中并且映射到商业等级的个人分配的表tblUser 302，正如以上结合表3和4而进行的讨论。另外，在表tblHMPositiontoGrade 304中可以把商业等级映射到所选用户角色上，正如以上结合表4和5而进行的讨论。
图10还显示了用户角色类别表(tblHMPositionCategories 305)和用户角色职位表(tblHMPositions306)，以及对职位等级和所分配人员的它们的相互关系。例如，表tblHMPositionsRelationship 307包括每个用户角色职位的所分配人员的用户ID。如果用户角色职位与特定投标模板类型(如在下文中结合图15而更详细地描述的那样)有关，则将每个投标模板类型的用户角色职位存储在表tblHMPositionsRFXMatrix 309中。此外，如果用户角色职位被特定地分配给每个投标交易，则对于特定交易的每个用户角色职位的所分配人员的用户ID可被存储在表tblBidHMPositions 308中。
图12显示了在交易期间买方为用户角色职位分配人员的示范性步骤。当交易开始时(步骤1200)(例如，创建投标模板或投标请求、广播投标请求、收到投标响应、评估投标响应、授标、支付凭证等等)，系统和/或主要人员决定是否已经定义了交易的所有所需用户角色职位(步骤1205)。否则，系统和/或主要人员定义交易所需的用户角色职位(步骤1210)。
一旦已经确定了用户角色职位，系统和/或主要人员就决定是否已经预先指定了用户角色职位的特定人员(此处也称作用户)(步骤1215)以及对于该交易来说是否要改变任一个预先指定的用户(步骤1220)。如果一个或多个用户角色职位不具有预先指定用户或者如果要改变一个或多个预先指定的用户，则系统和/或主要人员指定所有用户角色职位的适当用户(步骤1225)并且把用户角色职位的指定用户的身份存储在用户角色表中(步骤1230)(例如图10中的tblBidHMPositions)。如果预先指定了所有用户，则系统存储预先指定的人员(步骤1230)，以及如果适当的话，则通知交易的适当人员(步骤1240)。
再次参考图10，除了把用户分配给投标/项目处理的特定用户角色职位之外，数据库表结构300更进一步提供指定需要批准的交易和由于种种原因而指定特定批准者的能力。因此，在表tblApprovalLevel 310内，把某些用户角色职位分为批准职位，以及对于每个批准职位，指定批准的发送定单。例如，用户角色职位批准者(批准者A)被指定以批准由另一个用户角色职位(用户B)所产生的所有交易，以便系统自动地把所有交易从用户B发送给批准者A。
另外，可以向每个用户提供访问权限以查看和修改系统内的数据。例如，一个用户角色职位可具有通过第一网页而修改或把数据键入系统中的权力，而另一个用户角色职位可能仅具有通过第二网页查看数据的权力。因而，虽然对于两个用户来说网页上显示的信息可能是相同的，但是实际网页是不同的，这取决于用户角色职位的批准级别。当用户登入系统中时，系统确定用户的批准级别并把适当的网页推给用户。以下在表10中显示了实现用户角色对网页访问映射的数据结构的例子。
表10 用户角色对网页访问映射表 为了在正在进行的方式来维护用户角色职位、内部人员以及特定交易之间的关系，本发明的系统更进一步被设计成能解决在机构人员以及商业级别以及人员的用户职权中进行变换。现在参考图14，根据本发明的实施例，其中举例说明了对于修改用户角色职位分配的示范性步骤。根据用户名或交易类型可重新分配用户角色职位(步骤1400)。如果根据用户名而做出修改(步骤1405)，则可以全局地对被用户拥有的所有用户角色职位或者对仅被用户所拥有的特定用户角色职位做出改变。对于全局性变更来说(步骤1410)，选择新用户(步骤1415)并且对于前一用户所拥有的所有用户角色职位均以新用户来代替前一用户(步骤1420)。这类全局性改变是必要的，例如当雇员离开公司时，以及新雇员获得公司内该离开雇员的职位。
对于特定的用户角色职位变更(步骤1410)，可显示由该用户拥有的所有用户角色职位(步骤1425)，以及选择用户角色职位之一以进行改变(步骤1430)。为那个所选用户角色职位选择新用户(步骤1435)以及对于那个所选用户角色职位以新用户代替前一用户(步骤1440)。对于需要变更的每个用户角色职位可重复这种处理(步骤1445)。因为多种理由可能会出现特定用户角色职位项目变更，所述理由诸如宣传、改组、雇员状态改变(例如，专职到兼职)等等。
如果根据交易类型而做出了修改(步骤1405)则可显示所有交易类型的列表(例如，投标请求创建、投标请求广播、投标请求接收、投标响应产生、投标响应接收、投标评估、投标授予、计时、凭证支付等等)(步骤1450)，以及选择具体的交易类型(步骤1455)。显示与那个具体交易类型有关的所有用户角色职位(步骤1460)并且选择要修改的具体用户角色职位(步骤1465)。为那个所选用户角色职位选择新用户(步骤1470)，以及对于那个所选用户角色职位以新用户代替前一用户(步骤1475)。交易类型修改可能是有利的，例如当用户角色职位的具体用户未知时，但是由于顾客投诉的关系会需改变。
用户角色职位修改可应用于现有交易或仅应用于新交易(步骤1480)，这取决于修改的的理由和现有交易中连续性的需要。如果把修改应用于现有交易，则利用新用户来更新用户角色表并且把前一用户记录修改为过时(步骤1485)。然而，如果仅把修改应用于新交易，则利用新用户更新用户角色表，但是不删除前一用户，并且仅把该新用户标记为用于新交易(步骤1490)。
对于卖方而言，典型地预先指定用户角色职位以限制对合格人员的访问。在下文中在表11-13中显示了用于实现卖方用户角色的数据结构的例子。可以看到，为卖方人员分配卖方联系人类别，其可被映射到访问权限以查看和修改系统内的数据，类似于结合表10而对买方进行的以上描述。然而，应当清楚可以包括其他卖方用户角色配置，并且系统不局限于表11-13中所列的特定配置。
表11 示范性卖方角色(tblVendorRoles) 表12 示范性买方联系人(tblVendorContacts) 表13 示范性卖方角色许可(tblVendorRolePermissious) 对于管理员来说，可以定义用户角色职位以允许对整个处理组和队员进行指定以便主管与特定投标类型和对于特定地点有关的交易活动。现在参考图13A-13B，显示了用于实现管理处理组的示范性步骤。最初，建立管理员的管理员用户表，其包含管理员用户主要数据(步骤1300)。根据用户表，可把各种用户分配给一个或多个用户组并且用户对用户组的映射可被存储在用户组映射表中(步骤1305)。用户组可与公司或交易类型或者公司及交易类型内的商业单位有关。对于每一个用户组，可在用户组权利表中定义用户组内的每个用户的职权和责任(步骤1310)。例如，可为每个用户分配用户组的访问权限(正如以上结合图10的讨论)。在下文中在表14-19中显示了用于实现用户组和管理员的用户组权利的数据结构的例子。然而，应当清楚可以包括其他管理员角色配置，并且系统不局限于表14-19中所列的特定管理员用户角色配置。
表14 示范性管理员用户表 表15 示范性管理员用户组表值 表16 示范性管理员用户对用户组映射表 表17 示范性管理员用户组权利表 一旦已经确定了用户组，如图13B所示，就可以在用户组内创建处理组以处理特定交易类型(步骤1315)。具体用户组内的所有用户能够被映射到特定处理组并且被分配一个具体交易类型的发送定单(步骤1320)。在下文中在表18和19中显示了用于创建和把用户映射到处理组的示范性数据结构。
表18 示范性管理处理组表 表19 示范性管理处理组对用户映射表 另外，可把处理组映射到特定地区，以便不同的处理组能够在不同的地区处理相同类型的交易(步骤1325)。因此，当在具体地点执行具体类型的交易时，系统根据交易类型和地点而对适当用户的工作流程进行管理(步骤1330)。例如，可借助于电子邮件和/或操作板更新来向适当用户通知交易。
因而本发明的由系统所支持的用户角色管理提供了一种从投标创建到项目完成的整个投标/项目处理的灵活、可伸缩且有鲁棒性的工作共享环境，另外，系统允许基于用户角色的安全通信和交易处理，这允许用户在适当的时候与正确的人员相连接同时确保把数据查看和访问限限制在具有访问职能需要的那些用户上。
投标活动 完成了投标前活动之后，买方能够创建投标请求并把投标请求传送给一个或多个卖方以从卖方处请求对具体项目的投标响应。为了简化完成投标项目处理的环境中的投标处理，把投标模板用于特定项目类型以便以一种均匀且全面的方式从卖方处请求对特定项目类型的必要信息以允许有效率且有效果地评估投标响应。
图15显示了用于利用投标模板来创建投标请求的示范性功能。根据本发明的实施例，图15中举例说明了投标模板创建工具180和投标请求创建工具185，其分别用于创建投标模板240和根据投标模板240来创建投标请求200。投标模板创建工具180和投标请求创建工具185包括需要执行该工具功能的任何硬件、软件和/或固件，并且可被实现为网络服务器120或附加服务器(未显示)的一部分。每个买方可创建一个或多个投标模板240，这取决于由买方所转让的项目工作的特性。例如，如果买方仅需要在一个部门中进行员工补充，则买方可仅创建一个投标模板240以处理员工补充投标请求200。
为了创建投标模板240，投标模板创建工具180访问买方数据库155a以在投标项目列表194内检索投标内容230并且借助于买方模块110、网络服务器120、数据网络40和买方浏览器20a而向买方提供投标内容列表230以供买方进行挑选。投标内容230与要从买方、卖方或买方和卖方中请求的信息的特定类型有关。根据投标内容230的列表，买方选择并提择并提供一个或多个投标项目选择235以便包含在投标模板240中。取决于买方配置，对于投标模板240来说，一个或多个投标内容230是强制性的，诸如买方姓名、执行工作的地点以及请求的项目工作的类型。对于一个或多个强制投标内容230，除了包括在投标模板240中的强制投标内容230之外，与每个强制投标内容230有关的特定信息也包含于与投标模板240内的强制投标内容230有关的字段中。例如，可把买方姓名和项目工作类型存储在那个项目工作类型的投标模板240中。买方创建的每个投标模板240被存储在投标模板列表190内的买方数据库155a中，以便随后在创建投标请求200中使用。
为了创建投标请求200，投标请求创建工具185访问买方数据库155a以便检索投标项目列表190内存储的投标模板240，并且借助于买方模块110、网络服务器120、数据网络40和买方浏览器20a而向买方提供投标模板240的列表以供买方进行挑选。当选择适当的投标模板240时，买方向投标请求创建工具185提供投标请求数据210以便包含在投标模板240类型的投标请求200中。例如，买方可把投标请求数据210键入到每个投标项目选择235的所提供字段中，所述投标项目选择235需要投标模板240内来自买方的信息。举例来说，而不是限制，投标请求数据210包括要执行工作的地点、项目的时间以及项目所需的特定卖方资格。
投标请求创建工具185更进一步与买方数据库155a相连接以访问买方的卖方列表158并确定适当的卖方以接收投标请求。可根据投标请求200本身内包括的投标模板240类型和任何其他卖方资格而选择适当的卖方。因而，卖方列表158可被分成投标模板240类型的预赋予资格卖方以在提交投标请求200时更进一步减少处理时间。投标请求创建工具185更进一步利用与所选卖方有关的卖方联系人信息250以借助力卖方模块115、网络服务器120、数据网络40和卖方浏览器20b把投标请求200广播(传送)给适当的卖方(如图1和2所示)，并且在买方的投标请求列表196中存储所提交的投标请求200。
从所请求卖方处所接收到的卖方投标响应220(如图1和2所示)可更进一步被存储在投标响应列表198的买方数据库155a中以供随后在对卖方投标响应220进行比较和分等级中使用。根据投标请求200中包括的投标项目来产生卖方投标响应220。具体地说，卖方在投标请求200中的允许投标内容内的数据字段中填写与卖方和投标响应有关的数据。卖方借助于卖方模块115访问投标请求200以查看投标请求并完成卖方响应以及借助于卖方模块115提交所完成的投标响应220以便借助于买方模块110而存储在买方数据库155a中(步骤未显示)。投标响应220包括从卖方数据库115b(未显示)中检索出的数据，并且在投标响应创建期间及之后被存储在卖方数据库155b中。
图16A-16D中显示了用于创建投标模板、根据投标模板来创建投标请求以及根据来自各种系统观点的投标请求来创建投标响应的示范性步骤。图16A显示了对于投标模板创建来说在系统处执行的主要处理步骤。系统通过向买方用户提供一个预定投标内容列表而创建投标模板(步骤1600)。作为对其的响应，系统接收来自投标内容列表的一个或多个投标内容选择以便包含在系统内存储的投标模板内(步骤1610)。为了根据投标模板来创建投标请求，系统把投标模板内的投标内容选择传递给买方用户以利用投标内容选择来产生投标请求(步骤1620)。
在图16B中，在买方端，当收到投标内容列表时，为了创建投标模板，买方用户选择包含在投标模板内的一个或多个投标内容(步骤1630)。为了随后产生投标请求，买方用户接收包括投标内容选择的投标模板(步骤1635)并且把投标请求数据键入到与投标模板中的投标内容选择有关的字段中以创建投标请求(步骤1640)。在买方用户完成了所有适当投标内容选择字段之后，把投标请求传送给系统以广播给合格卖方(步骤1645)。
图16C显示了用于进行投标请求产生和广播的由系统所执行的主要处理步骤。创建了投标模板并且为投标模板存储了投标内容选择(步骤1650)之后，系统利用由买方用户为投标模板类型的投标请求而输入的投标请求数据来产生投标请求(步骤1660)。此后，系统把所产生的投标请求传送给合格卖方以请求投标模板类型的投标响应(步骤1670)。
在图16D中，在卖方端，卖方接收投标请求，所述投标请求包括由买方选择的允许投标内容选择(步骤1680)。为了创建投标响应，卖方用户把投标响应数据键入与投标请求内包含的投标内容选择有关的字段中以创建投标响应(步骤1685)。在卖方用户完成了所有适当投标内容选择字段之后，把投标响应传送给系统以转送给买方(步骤1690)。
在下文中在表20-25中显示了用于创建投标模板的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织，其中每个表包括把投标内容显示给从中进行选择的买方用户所需的所有字段并且存储了投标模板的投标内容选择。如下文中结合图17而描述的那样，该表以分层次且相关联方式相联系。然而，应当清楚可包括其他投标模板配置，并且系统不局限于表20-25显示的特定投标模板配置。
表20 基本投标内容部分表(tblRFXBidSections) 表21 基本投标内容类别表(tblRFXBidCategories) 表22 基本投标内容表(tblRFXBidItems) 表23 基本投标模板类型表(tblRFXBidTemplates) 表24 基本投标模板对投标内容映射表(tblFRXTemplateItemMatrix) 表25 基本客户投标内容默认值表(tblRFXBidItemsCDV) 现在参考图17，显示了举例说明每个上述表20-25之间的相互关系的数据库表结构400。当创建投标模板240时，投标内容230被显示成以投标区域和为了方便起见以投标类别以及逻辑商业信息处理分段进行组织。因而，向买方用户呈现投标区域250，从中买方用户能够选择投标类别255以显示与那个投标类别255有关的投标内容230。把投标内容230拆分成投标类别255和投标区域250形成了一种买方用户容易理解的划分格式，借此允许一种更有效率且更有效果的投标模板创建处理。
具有上述的表20格式的表tblRFXBidSections 401包括投标区域名称和投标内容230的每个区域250的标识符，以及每个投标区域250在网页上的显示顺序的表示和网页上的投标区域250所包括的任何注释。每个投标区域250可被存为表tblRFXBidSections 401中的独立记录，其中每个记录具有表20的格式。每个投标区域250内是一个或多个投标类别255。具有上述表21格式的表tblRFXBidCategories 402包括类别名称、每个投标类别255的标识号以及每个投标类别255的相关投标区域250。另外，表tblRFXBidCategories 402更进一步包括每个投标类别255在网页上的显示顺序以及网页上的投标类别255所包括的任何注释。每个投标类别255可被存为表tblRFXBidCategories402中的独立记录，其中每个记录具有表21的格式。
每个投标类型别255更进一步包括与投标类别255有关的一个或多个投标内容230。因此，具有上述表22的格式的表tblRFXBidItems 403包括投标内容名称和标识号、以及与投标内容230有关的投标类别255。每个投标内容230的独立记录可被存储在表tblRFXBidItems 403中，其中每个记录具有上述表22的格式。表tblRFXBidItems 403更进一步包括与投标内容230有关的附加信息，诸如是否允许废弃投标内容230、是否把投标内容230显示给卖方、投标内容230是否需要卖方响应、买方为投标内容230所键入的数据的类型、买方为投标内容230键入的数据的字段长度、卖方为投标内容230键入的数据的类型以及卖方为投标内容230键入的数据的字段长度。例如，下列表26举例说明了组成投标内容列表194的表tblRFXBidItem 403中的示例投标内容230，如图15所示。
表26 再次参考图17，对于具体的投标模板240，可以禁止或允许每个投标内容230，这取决于为其创建投标模板240的项目工作的类型。然而，正如以上结合图15的讨论，可能有一些需要被包括在一个或多个投标模板240类型中的投标内容230。因此，对于所需的投标内容230，不允许禁止。如果整个投标区域250或投标类别255不适用于具体的投标模板240，那么数据库表结构400可被配置成允许对整个投标区域250或投标类别255内的投标内容230进行禁止，如果可以禁止那个投标区域250或投标类别255内的所有投标内容230的话。
对于具体的投标模板240一旦禁止或允许所有的投标内容230(投标内容选择235是允许的投标内容)，则可把投标模板240和相关投标内容选择235存储在数据库表结构400中。具有上述表23的格式的表tblRFXBidTemplates 405包括投标模板名称和投标模板标识号以便用在表tblRFXTemplateItemMatrix 404中具有投标模板240的相关投标内容选择235中，所述表tblRFXTemplateItemMatrix404具有上述表24的格式。每个投标模板240的独立记录可被存储在表表tblRFXBidTemplates 405中，其中每个记录具有上述表23的格式。另外，具体投标模板240内所包括的每个投标内容选择235的独立记录可被存储在表tblRFXTemplateItemMatrix 404中，其中每个记录具有表24的格式。
如果存在其缺省值(诸如买方名称)适用于所有投标模板240的特定投标内容230，则那个具体投标内容230的缺省值可被存储在表tblRFXBidItemsCDV 406中，所述表tblRFXBidItemsCDV 406具有表25的格式。与每个投标内容230有关的每个缺省值的独立记录可被存储在表表tblRFXBidItemsCDV 406中，其中每个记录具有上述表25的格式。通过在一种结构化、可配置且可伸缩的格式中提供可选投标内容，可以取决于买方的特定需要而随时增加或去除任何投标内容230。
图18举例说明了用于利用分层次且相关的数据库表结构400来创建投标模板的示范性步骤。为了创建投标模板，买方用户键入模板名称以在数据库表结构400中创建模板的记录(步骤1800)。此后，买方用户从投标区域列表中选择具体的投标区域(步骤1805和1810)并且从投标类别列表中选择具体的投标类别(步骤1815和1820)以开始选择投标内容的处理以便包含在投标模板中(步骤1825)。
如果所选投标类别中的一个或多个投标内容是所需要的(步骤1830)，则所需投标选择被自动地包含在投标模板中(步骤1835)。对于具体类型的投标模板可根据买方用户的需要来选择其他投标内容(步骤1840)。对于所选投标区域内的每个投标类别(步骤1845)并且对于投标区域列表内的用于每个投标区域(步骤1850)重复这种处理，直到所有投标内容已经被审阅并且对于该投标模板被允许(选择)或者被禁止。正如以上的讨论，在其他实施例中，如果允许禁止所有那些投标内容，那么投标区域或投标类别内的所有投标内容可被禁止，而不必进行个人投标内容审阅。一旦已经为投标模板做出了投标内容选择，就把投标模板存储在投标模板列表中(步骤1855)以便随后在创建投标请求中进行使用。
图19显示了用于创建投标模板的示范性网页的屏幕快照。利用一个或多个网页(其中仅显示了一个)，买方用户可键入投标模板名称240、选择投标区域250并且选择投标类别255以在包含于投标模板240中的投标类别255内显示特定投标内容230。对于所显示的投标类别255内的每个投标内容230来说，买方用户可进行选择以允许或者禁止那个投标内容230。然而，如果不能禁止具体的投标内容230，则使禁止按钮虚象以防止买方用户禁止该投标内容230。另外，如果选项有效，那么还允许买方用户通过点击紧接于当前显示投标区域250或投标类别255的禁止按钮来禁止具体投标区域250或投标类别255内的所有投标内容230。一旦为该投标模板240已经允许或禁止了所有投标内容230，买方用户就能够保存投标模板240。在一些实施例中，如果还没有完成所有投标内容选择235，买方用户可以暂时地保存投标模板240。在其他实施例中，保存按钮被虚象直到已经允许或禁止了所有投标内容230。
图20举例说明了利用以分层次且相关的格式(如图17所示)来组织的投标内容用于根据投标模板(如图15所示)来创建投标请求的示范性步骤。最初，买方用户根据投标请求的投标模板列表来选择投标模板(步骤2000)。应当清楚，可以紧接在产生投标请求之前创建投标模板或者在投标请求开始前较好地创建投标模板。选择了投标请求的具体投标模板之后，买方用户键入该投标请求的投标请求标识符(步骤2005)，诸如投标请求名称或号码。另外，当它遍及系统而应用到卖方、买方、承包商以及管理员时，系统分配投标跟踪号码以查阅该投标。
由投标区域和投标类别把投标模板中的所有投标内容选择显示给买方用户以供审阅(步骤2010)。如果投标模板中的一个或多个投标内容选择不适用于具体的投标请求(步骤2015)，并且能够禁止不希望有的投标内容选择(步骤2020)，则买方用户能够禁止该具体的投标请求不需要的那些投标内容选择(步骤2025)。此后，买方用户把必要的投标请求数据键入投标请求所允许的投标内容选择的适当字段中(步骤2030)。例如，一个或多个投标内容选择可包含有用于买方键入数据的字段，诸如执行工作的地点或项目工作的类型。这些字段可以是变量类型数据字段(诸如文本项字段)或者可选的选项字段，其具有到包含该可选选项的其他网页的链接。
可被显示的可选选项字段例子包括根据许多预建立项目类型来选择投标请求的具体类型的项目工作。为了实现项目类型选择处理，提供了一种可配置且可伸缩数据库结构，其允许以一种不平凡的方式对买方的特定项目工作商业需求进行分类。通过根据预建立项目工作类型进行选择，买方能够保证卖方投标响应与买方的项目工作需求同步。当完成卖方资格数据(图2所示)以选择卖方来接收投标请求时，卖方也可以选择项目工作类型。在下文中在表27-29中显示了用于选择项目工作类型的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织，其中每个表包括了把项目工作类型显示给从中进行选择的买方用户所需的所有字段，并且存储了投标请求的相关投标内容选择的字段内的所选项目工作类型。该表是以分层次且相关的方式而关联的，以便以具体顺序来访问该表以便把项目工作类型显示给买方用户。
下面的表27举例说明了示例项目服务类型，诸如咨询、员工补充及其他项目服务。每个项目服务类型内可能是一个或多个项目部门，如表28所示，以及每个项目部门内可能是一个或多个项目族，如表29所示。因此，为了为投标请求选择具体的项目工作类型(项目族)，买方用户可选择项目服务类型和项目部门类型以显示从中进行选择的项目族列表。然而，应当清楚可以包括其他配置和项目类型，并且系统不局限于表27-29中所列的特定配置和信息。
表27 项目服务类型表 表28 项目部门类型表 表29 项目族类型表 再次参考图20，一旦买方用户把投标请求数据键入所有所需投标内容字段中(步骤2035)，就完成了投标请求。应当清楚不是所有投标内容字段都需要用户键入投标请求数据。例如，一个或多个投标内容选择可能是仅由卖方响应的卖方投标响应投标内容选择。对于卖方投标响应投标内容选择，买方用户能够允许或禁止那个投标内容选择，并且除了可能会帮助卖方完成那个投标内容的投标响应的数据之外，不会把任何数据键入到那个投标内容选择的字段中。对于投标请求完成，买方用户能够键入投标请求数据的每个允许的投标内容选择最好是由买方用户在提交投标请求之前来填写。
在许多公司中，必须在传送给卖方之前批准投标请求。因此，如果投标请求需要批准(步骤2040)，则投标请求的发起人把投标请求提交给适当的批准者(步骤2045)。在示范性实施例中，正如以上结合图9-14的讨论，对于所有投标请求或者对于具体投标请求来说，批准用户角色职位是预先指定的，以便把投标请求自动地发送给适当的批准者。如果批准了投标请求(步骤2050)，则发起人被通知该投标请求批准(步骤2055)，并且把投标请求传送到合格卖方(步骤2060)。然而，如果没有批准投标请求(步骤2050)，告知发起人该投标请求拒绝(步骤2065)，并且如果可能的话向发起人提供编辑该投标请求的机会(步骤2070)。例如，发起人也许已经为了批准的目的而禁止了需要被包括在投标请求中的一个或多个投标内容选择，或者保留消隐一个或多个买方所需数据字段。如果不需要批准投标请求(步骤2040)，则把投标请求传送到该投标请求的合格卖方(步骤2060)。
图21和22是能够向买方用户提供投标请求创建的示范性网页的屏幕快照。利用一个或多个网页(其中仅显示了一个)，买方用户能够键入投标请求名称200、选择投标区域250并且选择投标类别255以在包含于投标请求200中的投标类别255内显示特定投标内容选择230。图21显示了在每个区域250中列出投标内容选择235的数目以及在每个区域250中列出被完成或禁止的投标内容选择235的数目的投标请求200的状态的概要。为了完成或禁止投标内容选择235，买方用户可点击投标区域250以在每个投标类别255内显示投标类别255和投标内容选择235。一旦已经完成或禁止了所有投标内容选择235，买方用户就能够点击提交已完成投标请求按钮以便批准和/或传送给合格卖方。
如图22所示，每个投标区域250内的每个投标类别255中的每个投标内容选择235可被审阅以确定是否应该禁止投标内容选择235。一个或多个类别255中的一些投标内容选择235也需要来自买方用户的投标请求数据210。对于投标类别255内的每个投标内容选择235来说，买方用户可允许或者禁止那个投标内容选择235。然而，如果不能禁止具体的投标内容选择235，则使禁止按钮虚象以防止买方用户禁止该投标内容选择235。另外，如果该选项有效，则也允许买方用户来禁止具体的投标区域250或投标类别255内的所有投标内容选择235。如果投标内容选择235被允许并且具有用于键入投标请求数据210的字段238，则买方用户能够把投标请求数据210键入该相关数据字段238中。此外，如果投标模板包含有具体投标内容选择235的默认投标请求数据210，可把默认数据显示在数据字段238中，并且默认数据可被允许改变或者不被允许改变，这取决于模板集合。
图23举例说明了用于审阅和向合格卖方传送投标请求的示范性步骤，如图15所示。投标请求的发起人可根据投标模板类型和所键入的投标请求数据而从卖方列表中选择适当的合格卖方，或者可把投标请求提交给项目管理员以选择合格卖方，这取决于买方约束条件。如果是后者，则可以把新投标请求显示给管理员用户(步骤2300)以选择期望的投标请求以便审阅和传送(步骤2305)。在审阅处理期间，如果显著项目变更是必需的，则为了质量控制目的允许管理员用户编辑投标请求，或者管理员用户可请求投标请求的发起人编辑该投标请求(步骤2310)。
一旦投标请求处于已完成形式，管理员用户访问卖方列表(步骤2315)以根据投标模板类型和所键入投标请求数据(例如，根据结合预期地区工作地点的项目族)来确定投标请求的合格卖方(步骤2320)。如果合格卖方的列表是不充分的(步骤2325)，则管理员用户还可以在高级数据库(如图6所示)中查询附加的匹配卖方以添加到合格卖方列表中(步骤2330)。除了利用或代替来自高级数据库的匹配卖方来补充合格卖方列表之外，还向管理员用户提供选项以包括不完全匹配所有投标请求数据的卖方(步骤2335和2340)。
图24示出了显示从中进行选择的所有潜在卖方以包括在合格卖方列表中的示范性网页的屏幕快照。管理员用户可从匹配投标请求数据的与买方有合约的卖方、不完全匹配投标请求数据的与买方有合约的卖方、以及匹配由高级数据库所提供的投标请求数据的无合约的卖方中进行选择。管理员用户可根据许多因素来选择卖方以包含在卖方资格列表中，所述因素包括与该卖方的前一次合约经验、卖方名声和卖方有效性。
回到图23，一旦最后确定了合格卖方的列表(步骤2345)，管理员用户就把投标请求传送给该合格卖方(步骤2350)并且向投标请求的发起人通知投标请求状态(步骤2355)。例如，可以向发起人告知接收该投标请求的具体卖方以及在传送之前对投标请求所做出的任何修改。
图25显示了用于产生卖方投标响应并且向所接收的投标请求传送卖方投标响应的示范性步骤，如通常在图1和15中用220所示的那样。在示范性实施例中，根据卖方用户角色配置，投标请求被传送给卖方并且送给适当卖方用户，正如以上结合图9-14的讨论。当收到投标请求时，适当的卖方用户可借助于菜单或操作板控制通知来访问投标请求(步骤2500)。在进一步的示范性实施例中，利用绑定卖方用户的投标保密协议来提交投标请求以在把投标请求内容显示给卖方用户之前保密投标请求的内容。如果卖方用户承认该保密协议(例如，通过点击接受按钮)(步骤2505)，则卖方用户可获得对投标请求内容的访问(步骤2515)。否则，通知卖方用户该投标内容不可访问并且把投标请求从卖方用户视图中去除(步骤2510)。
为了限制卖方必须提交卖方投标响应的时间量，投标请求还包括一个卖方必须同意在其间作出响应的期限。如果卖方用户不能在该期限内同意作出响应(例如，通过点击接受按钮)(步骤2520)，那么通知卖方用户投标请求的内容不再对卖方用户有效并且把投标请求从卖方用户视图中去除(步骤2525)。同时向买方或项目管理员告知没有确认保密协议或期限约束条件的卖方，以及根据没有确认的卖方的数目，买方或项目管理员可向合格卖方列表中增加卖方并把投标请求传送给该附加卖方以保证接收到足够数目的卖方投标响应。
如果卖方用户同意在期限内作出响应(步骤2520)，那么对卖方授权以开始完成卖方投标响应(步骤2530)。为了响应投标请求，卖方用户通过需要卖方响应数据以进行审阅的投标区域和投标类别来访问投标内容选择(步骤2535)。如果卖方用户关于投标请求有什么疑问(例如，所需要的卖方响应数据的类型或数量)(步骤2540)，那么卖方用户可向买方提交问题以在买方配置的期限内进行投标说明(步骤2545)。适当的买方用户(例如，投标请求发起人或项目管理员)被告知卖方借助于电子邮件和/或操作板更新而提交的每个问题(步骤2550)，并且那个买方用户负责在适当的时间限制内提供所提交问题的答案(步骤2555)。借助于电子邮件和/或操作板更新向卖方告知买方的答案(步骤2560)。
例如，由系统提供投标留言板，卖方和买方都能够访问所述投标留言板以访问具体的投标请求。图27显示了示范性投标留言板600的屏幕快照。仅买方和响应具体投标请求的卖方可以访问该投标留言板600。可向所有卖方提供对所有提交问题和买方答案的访问，或者仅允许提交该问题的卖方查看买方答案，这取决于买方设置。另外，对于卖方和买方或仅对于卖方而言，卖方问题可能是匿名的，这取决于卖方和/或买方偏好。
回到图25，如果卖方用户没有任何问题(步骤2540)或者已经回答了所有的卖方问题(步骤2560)，卖方用户把必要的卖方响应数据键入到投标中的所需投标内容选择的适当字段中(步骤2565)。卖方响应数据包括成本信息和交付信息，所述成本信息包括成本要素(例如，资源需求、开支类型、等等)以及相关价格信息(例如，资源费率、开支数目等等)，所述交付信息包括交付类型(例如，要完成的单位数、阶段信息等等)以及完成信息(例如，项目结束日期、阶段结束日期等等)。每个成本要素和交付类型与不同的投标内容选择有关以允许对卖方投标响应进行有效地比较和分等级。
投标内容字段可以是各种数据类型，诸如文本/货币/数值项字段和/或可选任选字段。另外，该字段可具有与项目的不同方面的奇数投标响应内容有关的多级细节。例如，如果项目具有几个阶段，如买方和/或卖方所确定的那样，则卖方响应字段包括项目的每个阶段的独立区域。当试图提交卖方投标响应时，系统对卖方投标响应中的投标内容选择的所有必要数据字段的卖方完成进行验证(步骤2570)。如果所有所需数据字段没有被完成(步骤2575)，则向卖方用户提供一个系统消息，其表示无效的卖方响应投标内容选择，并且提示卖方用户在提交卖方投标响应之前完成所需投标内容选择(步骤2580)。一旦在投标响应中完成了投标内容选择的所有所需数据字段(步骤2575)，向卖方(当提交时)提供一消息，其表示已经向买方或项目管理员提交了卖方投标响应以供审阅(步骤2585)，并且借助于电子邮件和/或操作板更新而向适当的买方用户告知新卖方投标响应(步骤2590)。
图26A和26B是能够向卖方用户提供投标响应产生的示范性网页的屏幕快照。向卖方用户提供用于显示需要卖方响应数据的投标请求内的投标内容选择的网页。例如，如图26A所示，卖方投标响应的状态可被显示给卖方用户，其列出了每个区域250中的投标内容选择235的数目、卖方用户必须完成的每个区域中的投标内容选择235的数目、以及已经完成了的每个区域250中的投标内容选择235的数目。另外，卖方用户可访问投标留言板以递交卖方问题、以在线形式查看可容易读取的投标响应、或者提交要包含在卖方投标响应中的潜在承包商的简历。此外，一旦已经完成对所有投标内容选择235的卖方响应，卖方用户就能够点击提交已完成投标响应按钮以便批准和/或向买方或项目管理员传送。
为了完成对投标内容选择235的卖方响应，如图26B所示，卖方用户点击投标区域250以显示每个投标类别255内的投标类别255和投标内容选择235。如果需要对具体投标内容选择的卖方响应，则卖方用户把卖方响应数据215键入到投标内容选择235的数据字段238中。正如以上的讨论，数据字段238可以是直接的文本项字段，或者包括到其他网页的链接以便根据预建立的卖方响应来选择适当的卖方响应数据215。另外，数据字段238可具有多个级别，其中具有到每个级别的网页的链接。此外，可根据具有默认卖方响应数据215的卖方数据库来直接填写数据字段238，诸如卖方名称和卖方地址。例如，当收到投标请求时，卖方模块可搜索出具体的投标内容选择235并且利用适当的卖方响应数据215来填写那些投标内容选择235的数据字段238。
图28显示了根据预建立的卖方响应所选择的卖方响应数据的例子。如果投标请求包括需要卖方提供项目资源需求信息以及例如与资源需求信息有关的资源费率的投标内容选择，则数据字段238提供到其他网页的链接以选择预建立的资源概况参数。例如，每个资源概况表示一个具体的资源类型和该资源概况需要的相关技术。为了简化由买方对资源概况和费率进行的有效比较，卖方可从多个预建立资源类型和相关技术中进行选择。为了实现资源类型和技术选择，提供了一种可配置且可伸缩数据库结构，其允许以一种不平凡的方式对卖方的特定资源需求进行分类。
在下文中在表30-37中显示了用于选择资源类型和相关技术的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织，其中每个表包括了把资源类型和相关技术显示给从中进行选择的卖方用户所需的所有数据字段，并且存储了相关投标内容选择的数据字段内的所选资源概况。该表是以分层次且相关的方式而关联的，以便以一种用于向卖方用户显示资源类型和相关技术的具体顺序来访问该表，如下文中结合图29而描述的那样，其举例说明了数据库表结构800，其表示使完成卖方投标响应与卖方投标响应和买方投标请求之间的相互关系关联的示范性数据方案。
下述表30举例说明了示例商业部门类别，诸如轻工业、管理/专家、办公室和技术。在每个企业部门类别内是一个或多个商业界，如表31所示，以及在每个商业界内是一个或多个商业族，如表32所示。因此，为了选择与投标响应的资源类型有关的具体商业族，卖方用户可选择商业部门类别和商业界以显示要从中进行选择的商业族列表。一旦选择了商业族，就可以对与该资源类型有关的各种技术(一般职能和商业技术)进行选择并把它映射到具体的资源类型，如表33-37所示。例如，该一般职能可对与该资源类型有关的技能水平进行识别，技术类别可对该资源类型拥有的技术、培训以及经验的类型进行识别，以及与每个技术类别有关的一个或多个技术集合可对与该资源类型有关的特定经验进行识别。另外，通过建立资源类型的每个技术集合的优先级可以强调某些技术集合超出其他技术集合之上。应当清楚可提供其他资源类型和技术选择，并且系统不局限于表30-37所示的具体配置和信息。为了更全面地讨论资源概况，参考序号为10/128,7515的共同待审且一般指定的美国专利申请，此处通过参考而引入其全部内容。
表30 示范性商业部门表(tblBusSector) 表31 示范性商业界表(tblBusArena) 表32 示范性商业族表(tblBusFamily) 表33 示范性商业一般职能 表34 技术类别表(tblCategory) 表35 按照类别表的技术(tblSkillsMap) 表36 商业族对技术类别映射(tblBusFamtoSldllCat) 表37 示范性商业技术优先级 当提交卖方投标响应时，利用投标数据(投标请求数据或者卖方响应数据)来填写所有投标内容选择字段，其以分层次且相关的方式存储在系统(买方数据库和卖方数据库)中作为投标，如图29的数据库表结构800所示。在下文中在表38-55中显示了用于存储投标数据的示范性数据结构，结合图29对其进行讨论。
下面的表38和39举例说明了与具体投标请求有关示例投标请求数据，其可被存储在表tblRFX801和tblRFXSelectedBidItems 802中的数据库中，如图29所示。例如，在表tblRFX 801中，存储了与投标请求有关的一般信息，诸如系统分配给投标请求的投标跟踪号码、发起人分配的投标请求名称、投标请求发起人的身份、投标模板类型、项目类型、项目工作地点、该项目的预算支出量、投标请求的状态(例如，新、已提交、已评估、已授予等等)、高级数据库中卖方是否接收了投标请求以及是否需要任何批准。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表38和39所示的特定信息。
可以把每个投标内容选择的发起人所键入的投标请求和投标请求数据(买方注释)内所包括的特定投标内容选择存储在表tblRFXSelectedBidItems 802中。每个投标内容选择可以是存为tblRFXSelectedBidItems 802中的独立记录，其中每个记录包含下面的表39所示的所有字段。表tblRFXSelectedBidItems 802依赖于一般投标请求信息表tblRFX 801。正如以上结合图10的讨论，表tblRFXSelectedBidItems 802内所包含的投标内容选择是从表tblRFXBidItems 403中选出来的并且与表tblRFXBidTemplates 405内通过表tblRFXTemplateItemMatrix 404所存储的具体投标模板类型有关。
表38 主要投标表(tblRFX-db structure view) 表39 RFX投标内容表(tblRFXSelectedBidItems) 下文在表40中显示了与把投标请求邮递(传送)给合格卖方有关的示例信息，其可被存储在表tblRFXPost 803中的数据库中，如图29所示。在示范性实施例中，邮递的信息与接收投标请求的每个具体卖方有关，并且包括例如把投标请求提交(邮递)给合格卖方的日期与时间、邮递投标请求的管理员用户的身份、接收投标请求的合格卖方的身份、卖方投标响应标识符和分配给卖方的分数，如以下结合图31-35所描述的那样。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表40所示的特定信息。接收投标请求的每个卖方的独立记录可被存储在表tblRFXPost 803中，其中每个记录包括下文中所示的所有字段。
表40 tblRFXPost 下文在表41中显示了与由卖方接收投标请求和提交卖方投标响应有关的示例信息，其可被存储在表tblRFXResp 804中的数据库中，如图29所示。例如，这种响应提交信息可包括卖方投标响应标识符、卖方投标响应的状态、卖方的身份、卖方投标响应提交日期和卖方确认保密并打算响应协议的日期。下文在表42中显示了包含在表tblRFXResp 804中的该类型状态信息的例子，其可被存储在表tblRFXRespStatus 805中的数据库中，如图29所示。表tblRFXResp 804和tblRFXRespStatus 805依赖于表tblRFXPost 803，依次其依赖于tblRFX 801以使卖方响应提交信息连接到投标请求的投标邮递信息。然而，应当清楚也可以包括其他信息，以及系统不局限于表41和42所示的特定信息。每个卖方投标响应的独立记录可被存储在tblRFXResp 804中，其中每个记录包含下面的表41所示的字段。
表41 tblRFXResp 表42 tblRFXRespStatus的示范性数据 下面的表43举例说明了从卖方向买方提交的卖方投标响应中的示例卖方投标响应数据，其可被存储在表tblRFXRespMain 806中的数据库中，如图29所示。例如，这种卖方投标响应数据可包括投标跟踪号码、卖方响应标识符、卖方身份、卖方已经响应的具体投标内容选择、对那个具体投标内容选择的卖方响应、与那个具体投标内容选择有关的任何投标请求数据(买方注释)、对具体投标内容选择的卖方响应的记录标识符以及由买方给予卖方响应的任何等级，如下文中结合图31-35更详细地描述的那样。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表43所示的特定信息。由卖方响应的每个投标内容选择的独立记录可被存储在tblRFXRespMain 806，其中每个记录包含下面的表43所示的字段。表tbRFXRespMain 806依赖于tblRFX 801和tblRFXPost 803以使卖方投标响应与投标请求相关。
表43 tblRFXRespMain 与对投标内容选择的一个或多个卖方响应有关的可能是具体资源(承包商)的一个或多个资源概况，其中卖方把所述具体资源识别成完成该项目所必需的。可预先创建该资源概况或者把资源概况作为卖方投标响应的一部分。资源概况是利用以上结合图28而讨论且在上述表30-37中所示的商业部门、商业界、商业族、一般职能和技术而产生的。
下文表44-46中显示了资源概况的资源概况信息(资源类型和技术)的例子，其可被存储在表tblResourceProfileMaster 807、tblResourceProfileMasterSkills 816和tblResourceProfileMasterGF′s 817中的数据库中，如图29所示。表tblResourceProfileMaster 807存储了资源概况的资源类型(例如，商业部门、界和族)，而表tblResourceProfileMasterSkills 816存储了与资源类型有关的商业技术(技术集合和技术集合优先级)以及表tblResourceProfileMasterGF′s 817存储了资源类型的一般职能。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表44-46所示的特定信息。每种资源概况的独立记录被包含在表tblResourceProfileMaster 807、tblResourceProfileMasterSkills 816和tblResourceProfileMasterGFs 817中，其中每个记录包含下面在表45-46中所示的所有字段。表tblResourceProfileMaster 807依赖于表tblResourceProfileMasterSkills 816和tblResourceProfileMasterGF′s817以使一般职能和技术集合与每种资源概况的资源类型相关。
表44 tblResourceProfileMaster(db structure view) 表45 tblResourceProfileMasterGFs(db structure view) 表46 tblResourceProfileMasterSkills(db structure view) 下面在表47中显示了与利用卖方投标响应来提交的具体选择的资源概况有关的示例信息，其可被存储在图29中的表tblRFXResourcePfoiles 818。例如，这种所选资源概况信息可包括资源概况的身份和完成该项目所需要的那个具体所选资源概况的预期量。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表47所示的特定信息。该项目的每个所选资源概况的独立记录被存储在tblRFXResourceProfiles818中，其中每个记录包含下面在表47中显示的所有字段。表tblRFXResourcePiofiles 818依赖于表tblRFXResourceProfileMaster 807以使具体资源类型、技术和一般职能与所选资源概况相关。表tblRFXResourceProfiles 818更进一步依赖于表tblRFXSelectedBidItems802以使所选资源概况与请求该资源概况的具体投标内容选择相关。
表47 tblRFXResouceProfile(db structure view) 取决于投标请求，作为对一个或多个投标内容选择的卖方投标响应的一部分，卖方还提供与该项目的具体所选资源概况有关的价格信息。下面在表48中显示了示例资源价格信息，其可被存储在表tblRFXResourcesProfilePricing 819中的数据库中，如图29所示。例如，这种资源价格信息包括资源概况标识符、请求该资源概况和价格信息的投标内容选择的卖方投标响应记录的身份、与该资源概况有关的资源工作的小时的预期数、与该资源概况有关的票据费率以及与该资源概况有关的资源的预期票据量。然而，应当清楚也可以包括其他信息，以及系统不局限于表48所示的特定信息。与所选资源概况之一有关的每个资源的独立记录被存储在表tblRFXResourcesProfilePricing 819中，其中每个记录包含下面在表48中显示的字段。表tblRFXResourcesProfilePricing 819依赖于表tblRFXResourceProfiles 818以使具体资源的资源价格信息连接到具体所选的资源概况。另外，表tblRFXResourcesProfilePricing 819依赖于表tblRFXRespMain 806和表tblRFXSelectedBidItems以使资源价格信息和所选资源概况与对具体的投标内容选择的卖方投标响应相关。
表48 tblRFXResourceProfilesPricing(db structure view) 除了具体资源概况和价格之外，卖方投标响应还包括与项目所需要的物资类型有关的信息。下面在表49中显示了示例物资信息，其可被存储在表tblRFXRespMaterials 822中的数据库中，如图29所示。例如，这种物资信息包括请求该物资信息的投标内容选择的卖方投标响应记录的身份、物资的类型和物资的成本。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表49所示的特定信息。每种类型的物资的独立记录可被存储在表tbRFXRespMaterials 822中，其中每个记录包含下面的表49所示的字段。表tblRFXRespMaterials 822依赖于表tblRFXRespMain 806和表tblRFXSelectedBidItems以使该物资信息与对具体的投标内容选择的卖方投标响应相关。
表49 tblRFXRespMaterials(db structure view) 卖方投标响应还包括与项目的阶段有关的信息。下面在表50中显示了示例阶段信息，其可被存储在表tblRFXRespPhase 823中的数据库中，如图29所示。例如，对于项目的每个阶段，阶段信息包括请求该阶段信息的投标内容选择的卖方投标响应记录的身份、具体阶段的数目、阶段的描述、阶段的预期持续时间以及在该阶段结尾时的项目交付(例如，要完成的单位数量或其他项目重要事件)。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表50所示的特定信息。每种阶段的独立记录可被存储在表tblRFXRespPhase 823中，其中每个记录包含下面的表50所示的字段。表tblRFXRespPhase 823依赖于表tblRFXRespMain 806和表tblRFXSelectedBidItems以使该阶段信息与对具体的投标内容选择的卖方投标响应相关。
表50 tblR FXRespPhase(db structure view) 由卖方和买方在投标留言板上邮递的所有问答以及从与卖方投标响应有关的买方提交给卖方的任何问题也可以存储在系统中，并且可与该具体卖方投标响应有关。下面在表51和52中显示了示例问题信息，其可以存储在表tblRFXQuestionsFrornVendor 820和tblRFXQuestionsFromBuyer 821中的数据库中，如图29所示。每个卖方问题/买方响应和买方问题/卖方响应的独立记录被存储在表tblRFXQuestionsFromVendor 820和tblRFXQuestionsFromBuyer 821中，其中每个记录包含下面在表51和52中所示的字段。另外，表tblRFXQuestionsFromVendor 820和tblRFXQuestionsFromBuyer 821依赖于表tblRFXRespMain 806以使这些问题与该具体卖方投标响应相关。
表51 tblRFXQuestionsfromVendor(db structure view) 表52 tblRFXQuestionsfromBuyer(db structure view) 卖方投标响应还与关于前一项目工作的细节有关，所述前一项目工作已经由卖方执行了以在投标响应处理中给予帮助。下面在表53中显示了示例前一项目工作细节，其可被存储在表tblRFXRespTrackRecord 824中的数据库中，如图29所示。例如，这种前一项目工作细节包括卖方投标响应标识符、项目名称、买方姓名、项目价值、项目描述、该项目所采用资源(承包商)的讨论、卖方的执行的讨论、项目开始日期和项目结束日期。应当清楚，还可存储附加的前一项目工作细节，以及系统不局限于表53所示的特定前一项目工作细节。
表53 tblRFXRespTrackRecord(db structure view) 现在参考图30，举例说明了用于向买方显示选项以管理投标请求和卖方投标响应的示例网页的屏幕快照。根据该投标请求管理网页，买方用户向管理员(或向合格卖方)提交已完成投标请求、查看对设标请求的卖方投标响应、对卖方投标响应分等级、向卖方提交关于卖方投标响应的问题、从卖方处请求重新报价、请求与卖方进行项目会见或者与项目的潜在资源(承包商)进行资源会见、向具体的卖方授予投标(项目)、为项目分配资源或把投标请求放置于拥有状态。
一旦买方已经接收了对具体投标请求的一个或多个卖方投标响应，买方就能够对卖方投标响应划分等级或者相反比较该卖方投标响应以便确定哪个卖方将得到该项目的授权。借助于投标请求和投标响应中的预建立投标内容，所有卖方投标响应具有相同的格式，这允许有效率且有效果地对卖方投标响应进行分等级和比较。因此，在开始对卖方投标响应分等级之前，为了分等级的目的，买方可选择一个或多个投标内容。
图31显示了用于选择已分等级的投标内容和用于对所选已分等级的投标内容的卖方响应进行分等级的示范性功能。根据本发明的实施例，图31中举例说明了一种分等级工具188，其用于选择已分等级投标内容和对卖方投标响应分等级。分等级工具188包括需要执行该工具功能的任何硬件、软件和/或固件，并且可在网络服务器120或附加服务器内实现(未显示)。
创建投标请求之后的任何时候，负责对卖方投标响应分等级的分级员(例如买方用户或项目管理员用户)可访问分等级工具188以从用于分等级目的投标需求中选择出一个或多个投标内容选择235。分等级工具访问存储在数据库155中的投标内容列表194、从由分级员识别出具体投标请求内所包括的投标内容列表194中检索投标内容选择235、以及借助于买方模块110、网络服务器120、数据网络40以及买方浏览器20a来向分级员显示投标内容选择235以从中进行挑选。根据该投标内容选择235，分级员可选择一个或多个已分等级投标内容236并且向分等级工具188提供已分等级投标内容236的列表。
当收到一个或多个卖方投标响应时，分等级工具188可访问卖方投标响应列表192以便为列表192中的一个卖方投标响应检素与已分等级投标内容236之一有关的卖方响应数据215。为了分等级目的把投标内容响应数据215显示给分级员。根据与所显示的投标内容响应数据215内所包括的质量和信息有关的各种因素(客观和主观)，分级员为那个投标内容响应215分配等级并且把投标内容响应等级260传送给分等级工具188。
分等级工具188更进一步与数据库155相连接以把卖方的投标内容响应等级260存储在卖方等级列表198中，所述卖方等级列表198包含卖方投标响应列表192中的每个卖方投标响应的所有已分等级投标内容236的投标内容响应等级260。另外，根据具体卖方投标响应的所有已分等级投标内容236的分等级工具188所接收的所有投标内容响应等级260，分等级工具188可为具体卖方投标响应计算总的卖方分数265并且把卖方分数265存储在卖方等级列表198中。
图32和33显示了用于选择已分等级投标内容和利用已分等级投标内容来对卖方投标响应分等级的示范性步骤。图32显示了用于投标响应分等级所执和垢主要处理步骤。当收到卖方投标响应时(步骤3200)，对为了分等级目的而使用的投标内容选择进行识别(步骤3210)。投标内容选择与请求该卖方投标响应的投标请求有关，以及卖方投标响应数据被包括在为了分等级目的而挑选的投标内容选择内。利用已分等级投标内容内卖方投标响应数据，可以对卖方投标响应进行分等级(步骤3220)。
图33显示了一个更详细的分等级处理。创建投标请求之后，向买方用户提供一个与该投标请求有关的投标内容选择的列表(步骤3330)。从该投标内容选择的列表中，选择一个或多个已分等级投标内容(步骤3305)，以及为每个已分等级投标内容分配一个加权因子(例如，加权百分比)(步骤3310)以在最终分数中使某些响应比其他响应具有更高的权重。应当注意到在一些实施例中，加权因子可能相等，借此消除了买方用户键入特定加权因子的要求。在对卖方投标响应分等级之前，必须完成所有已分等级投标内容的加权因子(步骤3315)。
一旦所有已分等级投标内容已经被选择并分配了加权因子，就能向分级员提供卖方投标响应的列表(步骤3320)并且分级员选择一个卖方投标响应以用于分等级的目的(步骤3325)。此后，分级员选择一个已分等级投标内容(步骤3330)以对已分等级投标内容内所包括的卖方投标响应数据进行分等级。分级员可利用对该分级员有效的任何机制来对卖方投标响应数据进行分等级。在一个实施例中，分级员可预先建立具体的已分等级投标内容的分等级标准以允许系统自动地对卖方响应数据分等级。例如，为了对价格信息进行分等级，分级员可为特定价格范围预先分配等级，以及系统可根据卖方投标响应中所提交的价格而自动地为价格已分等级投标内容提供一个等级。在其他实施例中，在根据卖方投标响应数据之间的相对差来分配等级之前，分级员最初可对具体已分等级投标内容的所有卖方投标响应数据进行比较。在更进一步的实施例中，分级员可预先建立每个等级的清单或阈值以被分配给具体已分等级投标内容。
被分配给已分等级投标内容的卖方响应数据的该等级被存储在数据库中(步骤3340)，以及对每个已分等级投标内容重复该处理直到具体卖方投标响应的每个已分等级投标内容内所包括的卖方响应数据都被分等级(步骤3345)。一旦已经完成了所有的等级，系统就根据分配给每个已分等级投标内容的个人等级来计算卖方的总分(步骤3350)。例如，如果可能的等级是A、B、C和D，则通过为A分配四点、为B分配三点、为C分配两点以及为D分配一点可计算出卖方分数。
同样地对每个卖方投标响应进行分等级(步骤3355)以允许把卖方分数按递减次序进行排序(步骤3360)以便显示给买方用户(步骤3365)。除了总分之外，还向分级员提供已分等级投标内容的个人等级以确定是否需要任何的重新报价。通过向分级员提供总分和个人等级，分级员能够可见地确定对于具体的已分等级投标内容来说哪个卖方具有最高的总分以及哪个卖方具有最高的等级以便做出关于要把项目授予哪个卖方的判断。然而，应当清楚利用本发明的系统可采用其他投标响应比较技术，而不是此处描述的特定分等级和评分。
图34A-34E显示了可被显示给分级员以选择已分等级投标内容和对卖方投标响应进行分等级的示范性网页61的屏幕快照。在图34A中，网页包含投标内容选择列表235以便分级员从中进行选择。对于每个所选择的已分等级投标内容236，分级员还可以键入那个已分等级投标内容236的加权百分比850。分级员可根据预先建立的标准或个人偏好来调整加权百分比850直到加权百分比850总体等于百分之一百。正如以上的讨论，在其他实施例例中，可对所有已分等级投标内容236分配相等的权重，以便不需要向分级员显示加权百分比850或由分级员选择加权百分比850。
为了对卖方投标响应分等级，如图34B所示，向分级员提供其列出了该具体已分等级投标内容236并且显示卖方投标响应数据215或者提供到卖方投标响应数据215的链接的网页。例如，如图34C所示，可提供到资源概况和相关资源价格信息的链接以便对具体的已分等级投标内容进行分等级。再次参考图34B，可更进一步向分级员提供一提示以键入与已分等级投标内容236有关的卖方投标响应数据215的等级855。在其他实施例中，根据预先建立的分等级标准，等级855可由系统自动地分配。
一旦已经对卖方投标响应分等级了，如图34D所示，就向分级员提供一个网页，其中显示了所有已分等级投标内容236、分配给该已分等级投标内容236的加权百分比850以及由分级员分配给每个已分等级投标内容236的卖方等级855，此外，还可以显示总卖方分数860以允许分级员确定卖方投标响应的总品质。现在参考图34E，可根据总卖方分数860和分配给每个已分等级投标内容236的个人等级855而并行地比较卖方投标响应。
下文在表54-56中显示了用于选择已分等级投标内容和存储卖方等级的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织，其中每个表包括把投标内容选择显示给从中进行选择的买方用户所需的所有字段并且存储了卖方投标响应的等级和分数。如下文中结合图35而讨论的那样，该表以分层次且相关方式相关联。
下面在表54中显示了可被包含在投标请求和相关卖方投标响应中的示例投标内容选择。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表54所示的特定信息。对于每个投标内容选择，存在是否那个投标内容选择可分等级的表示。例如，不是所有投标内容选择会包括卖方响应数据以进行分等级。因此，仅向买方用户显示可分等级的投标内容选择以从中进行选择。
表54 潜在已分等级的投标内容的示范性卖方列表(By Category) 为每个已分等级投标内容存储独立的等级，如下面在表55中所示，其可被存储在表tblRFXGradeItems 825的数据库表结构1100中，如图35所示。与具体已分等级投标内容236的所分配等级855一起，表tblRFXGradeItems 825还包括买方用户分级员的身份、分配给已分等级投标内容236的加权百分比850以及与等级855有关的卖方投标响应标识符。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表55所示的特定信息。每个卖方的每个卖方等级855被存储在表tblRFXGradeItems 825中的独立记录里，其中每个记录包含下面在表55中所示的字段。另外，表tblRFXGradeItems 825依赖于表tblRFXRespMina806，其依赖于表tblRFX 801，这两个表都是结合上述图29而描述的，以便使卖方等级855连接到卖方投标响应和投标请求。另外，表tblRFXGradeItems825依赖于表tbRFXSelectedBidItems 802以使卖方等级855连接到具体投标内容选择235。
表55 已分等级投标内容表(tblRFXGradeItems) 每个投标内容235的每个卖方等级855的所计算分数865可以象如下在表56中所示那样进行存储，其可被存储在表RFXItemScoreVendor 826的数据库中，如图35所示。每个卖方投标响应的每个已分等级投标内容的独立记录可被存储在表tblRFXItemScoreVendor 826中，其中每个记录包含下面的表56所示的字段。另外，根据存储在表tblRFXItemScoreVendor 826中的所有卖方分数865的总分数860还可以象下面在表57中所示那样进行存储，其可被存储在表tblRFXScoreVendor 827的数据库中，如图35所示。每个卖方投标响应的独立记录可被存储在表tblRFXScoreVendor 827中，其中每个记录包含下面的表57所示的字段。
表tblRFXItemScoreVendor 826依赖于表tblRFXGradeItems 825以使每个分数865与具体卖方投标响应的所有已分等级投标内容236的相关等级855相关。另外，表tblRFXScoreVendor 827依赖于表tblRFXItemScoreVendor 826以使具体卖方投标响应的所有已分等级投标内容236的所有分数865与那个具体卖方投标响应的总分860相关。此外，表tblRFXScoreVendor 827依赖于表tblRFXPost 803(以上结合图29而对其进行了描述)以利用卖方分数860来更新表tblRFXPost。
表56 卖方内容分数表(tbRFXItemScoreVendor) 表57 卖方分数表(tblRFXScoreVendor) 卖方投标响应被接收并分等级之后，买方用户为卖方提供机会以在一个或多个已分等级投标内容上提交重新报价以提高卖方分数。例如，买方用户典型地选择的或者在其他已分等级投标内容上具有高等级的卖方的分数可比其他卖方低，以及买方用户想要为该卖方提供机会以修正具有低等级的一个或多个已分等级投标内容的卖方投标响应数据。
图36显示了用于简化重新报价处理的示范性步骤。当分级员发觉具体卖方在一个或多个已分等级投标内容上具有一个或多个低等级时，分级员可邀请卖方在一个或多个所选已分等级投标内容上进行重新报价(步骤3600和3610)。对重新报价的邀请(步骤3620)可仅识别允许卖方在其上重新报价的该具体已分等级投标内容以防止卖方在分级员不想要重新分等级的任何其他已分等级投标内容上进行重新报价。例如，重新报价可能包括原始卖方投标响应的副本并且仅允许那些要由卖方用户选择的重新报价投标内容以输入新的卖方响应数据。原卖方响应数据可被删除或与新响应数据一起被存储在数据库中以供参考目的。另外，重新报价邀请表示每个重新报价投标内容的卖方等级，以及每个重新报价投标内容的卖方分级，以及其他类似信息，诸如该重新报价投标内容的高卖方等级和低卖方等级。
如果卖方选择在买方约束的期限内不进行重新报价(步骤3630)，则把原始卖方等级和评分应用于该卖方投标响应(步骤3640)。然而，如果卖方在一个或多个重新报价投标内容上进行重新报价(步骤3630)，则卖方用户可把新卖方响应数据键入所选重新报价投标内容的投标内容字段(步骤3650)。当收到重新报价时(步骤3660)，分级员利用新卖方响应数据来对重新报价的投标内容进行分等级并且相应修改卖方分数(步骤3670)。
图37显示了用于授予投标和键入项目跟踪参数的示范性步骤。一旦完成了所有卖方投标响应分等级和评分(步骤3700)，就可把投标授予给一个卖方。如果买方用户有权根据卖方分数及其他因素(例如，个人偏好、对卖方信誉的认识、对卖方有效性的认识)来选择卖方(步骤3705)，则买方用户可为该项目选择卖方(步骤3710)。否则，把投标授予给具有最高分的卖方(步骤3715)。
一旦已经选择了该项目的卖方，系统就向项目管理员(步骤3720)和该被授予卖方(步骤3725)通知该投标授予。此后，被授予卖方和买方进入谈叛以最后确定项目条款，如通常所做的那样(步骤3730)。如果被授予卖方和买方不同意项目条款(步骤3735)，则买方可以重新打开投标处理以根据现有卖方分数、根据新卖方投标响应或者既根据现有卖方分数又根据新卖方投标响应来选择新卖方(步骤3740)。然而，如果同意条款(步骤3735)，则买方和被授予卖方可把各种项目跟踪参数加载到系统中(步骤3745)，诸如项目开始日期、项目结束日期、预期项目开支(请购单量)、所分配资源、项目阶段进度、项目支付核发进度、项目交付、项目物资以及项目支出，以创建项目的购买请购单。应当清楚也可以把附加项目跟踪参数加载到该系统中以来跟踪项目的执行，该系统不局限于此处描述的项目跟踪参数。一旦项目管理员和卖方的适当批准用户批准了该项目的购买请购单(步骤3750)，项目就可以开始了。
图39A和39B显示了项目管理员和卖方用于把项目跟踪参数870加载到系统中的示范性网页61的屏幕快照。对于项目管理员，如图39A所示，可把各种请购单信息键入系统，诸如购买请购单创建日期、购买请购单状态(其可由系统自动地更新)、购买请购单量、购买请购单货币(例如，美元)、项目开始日期以及项目结束日期。另外，项目管理员还可以向系统中键入各种项目条款，诸如工作报表、项目货物以及服务交付、项目合约、项目物资、所分配项目资源以及可开帐单费率、项目支出、项目阶段进度以及项目支付核发进度。此外，项目管理员可给管理员用户分配尚未被分配给项目的各种管理员用户角色。此外，还可以把适用于该项目的其他财务项目跟踪参数键入系统，诸如账目分配、总帐代码、成本中心代码、项目代码、税款代码及账目装备。
如图39B所示，卖方可访问买方键入的数据以修改预先键入系统中的项目跟踪参数870和/或把新项目跟踪参数870键入系统中作为项目管理员。例如，卖方可键入上述讨论的一个或多个项目条款。该当事人可同意谁将要键入项目跟踪参数870，或者两个当事人都可键入和/或修改项目跟踪参数870，以及如果做出任何项目变更则系统可向两个当事人提供通知。应当清楚可把其他项目跟踪参数插入到系统中，以及系统不局限于图39A和39B所示的那些项目跟踪参数。
例如，如图40A和40B所示，还可以把纳税信息875键入到系统中作为项目跟踪参数870的一部分。纳税信息875可被买方和卖方采用以保证为了财务管理和纳税义务目的而在项目中说明所有纳税职权和适当的纳税数额。如图40A和40B所示，当为一活动(例如在项目过程中由卖方采用的物资)创建请购单内容行号时，买方和卖方可在系统内指定适当地评估纳税所必需的所有相关交易信息。
例如，如图40A所示，作为领料单实体的一部分，买方和卖方可通过键入与买方地点、发起地点、发货地址、实际交货地址、卖方地点等等有关的地点信息而发起或更新纳税信息875，所有这些都可表示适当的纳税职权。另外，如果买方是免税的，则买方可指定免税原因。买方和卖方都可通过键入适当纳税职权和纳税百分率而更进一步发起或更新纳税信息875。如图40B所示，当提交具体活动的采购定单以便支付时，系统可访问买方和卖方为该具体活动而预先键入的纳税百分率并且可为该采购定单计算纳税数额。纳税信息875可被存储在数据库中并且对被批准的用户适用，所述纳税信息875包括纳税职权、百分率、数额、及其他纳税相关交易信息。
图40C显示了用于键入和处理纳税信息的示范性处理。当买方/管理员创建了其指定项目的活动的所有元素的购买请购单时(项目跟踪参数)，所述购买请购单包括人力、支出、物资、交付、单位工作及其他杂项开支、货物/服务被传送或执行的地点(步骤4000)和纳税信息，系统可使购买请购单(其包括纳税信息)对适当卖方有效以进行审阅(步骤4005)。那时，卖方还可以把任何相关纳税信息键入系统中并批准该购买请购单(步骤4010和4015)。把包括卖方批准的买方纳税信息和卖方纳税信息的完整购买请购单提供给买方以进行最后批准(步骤4020和4025)。
当买方批准时，卖方采购定单被创建并发布给卖方(步骤4030)以开始处理目(步骤4035)。在项目开始期间，由卖方执行指定的货物或服务一个或多个采购定单(步骤4040)。如果该货物/服务与承包商的可开票据时间支出有关，那么承包商填写他的或她的计时卡(步骤4045)，如下文中结合图42-47而更详细地描述的那样。对于所有其他货物/服务来说，卖方键入其他凭证信息(步骤4050)，如在下文中结合图48-50而更详细地描述的那样。此后，把凭证传递给所指定买方用户以供审阅(步骤4055)。当买方批准凭证时，系统管理员创建票据文件，在适当地点所述票据文件引入了利用预先键入的纳税百分率而计算的任何适当纳税数额，并且所述票据文件把发票提交给买方以便对其进行支付(步骤4060)。此后，买方付款给管理员(步骤4065)并且管理员付款给卖方(步骤4070)。管理员对与凭证支付有关的票据文件中的财务交易数据进行维护并且授权对财务交易数据进行访问以对买方或卖方人员进行授权(步骤4075)，并且管理员可选择性地把财务交易数据上载给高级数据库以便随后进行处理(步骤4080)，如在下文中结合图59而更详细地描述的那样。
作为可被输入到系统中的项目跟踪参数的另一个例子，在最后谈判期间，买方请求卖方为买方提交资源候选者的简历(实际合同签订人)以同意保证由具有资源概况的实际候选者来填充包括在卖方投标响应中的资源概况位置。下面在表58和59中显示了用于提交资源候选者和对资源候选者进行审阅的示范性数据结构。
下面的表58举例说明了可为由项目中的资源概况职位的卖方所选择的每个资源候选者提交的示例资源候选者信息。例如，资源候选者信息包括与该资源候选者有关的具体投标(投标请求和投标响应)的投标跟踪号码、资源候选者的资源概况的身份、个人资源候选者信息、卖方信息、资源候选者的简历以及资源候选者提供的状态。表59举例说明了包含在表58中的各种资源提供状态信息。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表58所示的特定信息。
表58 示范性资源提供表(db structure view) 表59 示范性资源提供状态表(data view) 图38显示b用于批准资源候选者的示范性步骤。用于卖方投标响应中所包含的每个资源概况，卖方提交该资源概况职位的潜在资源候选者的简历(步骤3800)。买方审阅所有简历并且为资源概况职位分配合格的资源候选者(步骤3810)。
如果一个或多个资源候选者是不可接受的(例如，简历表明该资源候选者不具有资源概况的必要技术)(步骤3820)，以及不存在对该资源概况职位的其他可接受的候选者(步骤3830)，则买方可重新开启投标处理以便为该项目保障能提供必要资源的其他卖方(步骤3840)。然而，如果合格资源候选者能够担任所有资源概况职位，那么买方和/或卖方把与每个所分配资源候选者(承包商)有关的资源信息键入到承包商数据库中(步骤3850)。例如，把关于承包商的人员信息(诸如承包商名称、地址、电话号码以及员工编号)输入到承包商数据库中。另外，特定项目相关承包商信息(诸如授权的可开票小时的总数、可开票的费率、所授权的支出的总额和类型、在开工之前承包商需要运行或提供的任何协议或文档)可输入到承包商数据库中。
一旦输入了承包商信息，系统就能够对承包商进行认证以用于计时和系统访问的目的(步骤3860)。例如，系统为承包商提供用户名和密码以用于系统注册和认证目的。另外，在允许访问计时系统之前，系统需要承包商执行一个或多个协议(例如，通过在线确认协议条款)和/或提供一个或多个文档。
图42显示了在初始注册和认证时被显示给承包商的示范性网页61的屏幕快照。网页列出了在承包商对该项目开工之前必须执行的几个文档。例如，承包商需要签订知识产权协议、保密协议、代码执行协议以及临时性工作确认协议。通过点击每个所列文档，向承包商显示一个示出了该协议的网页并且承包商可点击接受按钮来执行该协议。
下面在表60-63中显示了用于存储承包商信息并且保证从承包商处得到相关文档或由承包商同意相关文档的示范性数据库结构。表60列出了在项目期间需要从承包商处得到的或者承包商需要在某一点执行的各种示例文档。表60还列出了用于得到或执行这种文档的时间限制。表61列举了承包商信息，诸如承包商身份、授权的可开票小时数、授权的支出数额、各种文档的执行日期和承包商类型。表62列举了具体的文档并且识别承包商是否已执行了或者提供了那个文档和这种执行或提供的日期。应当清楚，可把每个文档的独立记录存储成具有表62的格式。表63举例说明了用于识别承包商类型的各种示范性信息，诸如承包商有和没有为买方工作的天数。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表60-63所示的特定信息。
表60 示范性承包商文档表 表61 示范性承包商表 表62 示范性承包商执行日期表 表63 示范性承包商类型表(db structure view) 下文在表64-79中显示了用于存储项目跟踪参数的数据结构的例子。为简单起见把该数据结构举例说明为以表格格式进行组织的，其中每个表包括用于跟踪项目执行所需所有字段。如下文中结合图41而讨论的那样，该表以分层次且相关的方式相关联。
下面的表64举例说明了示例普通购买请购单信息，其可存储在表tblPurchaseReq 1000的数据库中，如图41所示。例如，这种普通采购信息包括系统分配给购买请购单的身份、买方和卖方、请购单创建日期、请购单金额、与该购买请购单有关的投标(投标请求和投标响应)的投标跟踪号码、项目开始和结束日期、以及任何其他相关购买请购单信息。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表64所示的特定信息。现在参考图41中的数据库表结构1150，表tblPurchaseReq 1000显示依赖于表tblPurchaseReqContractors 1012和表tblluContractorTypes 1013，其包括分别与以上表61和63相对应的数据结构格式中的信息，以使所分配的承包商与该购买请购单相关。
表64 tblPurchaseReq 下面的表65-70举例说明了与税款代码、帐目装备、成本中心、项目代码、帐目分配及其他类似买方特定购买请购单信息有关的示例特定购买请购单信息，所有这些均被存储在相应的表tblPurchaseReqTaxCode 1001、tblPurchaseReqAcctPlant 1002、tblPuchaseReqAcctCostCenter 1003、tblPurchaseReqProjectCodes 1004、tblPurchaseReqAcctGL 1005和tblPurchaseReqAcctAssignment的数据库中，如图41所示。然而，应当清楚可以包括与该购买请购单有关的附加表和信息，这取决于购买请购单要求。表tblPurchaseReqTaxCode 1001、tblPurchaseReqAcctPlant 1002、tblPuchaseReqAcctCostCenter 1003、tblPurchaseReqProjectCodes 1004、tblPurchaseReqAcctGL 1005以及tblPurchaseReqAcctAssignment 1006依赖于表tblPurchaseReq 1000以使该特定购买请购单信息与普通购买请购单信息相关。
表65 tblPurchaseReqTaxCodes 表66 tblPurchaseReqAcctPlant 表67 tblPurchaseReqAcctCostCenter 表68 tblPurchaseReqProjectCodes 表69 tblPurchaseReqAcctGL 表70 tblPurchaseReqAcctAssignment 下面的表71-75举例说明了与购买请购单有关的示例请购单支付信息。例如，这种请购单支付信息包括基于项目交付的支付数额(例如，项目结束时或者在项目阶段期间所交付的货物和服务、基于期限的支付数额、基于所填写的单位的数目的支付数额、基于项目物资的支付数额以及基于项目支出的支付数额。在图41中，请购单支付信息显示为存储在表tblPurchaseReqPayDeliverable 1007、tblPurchaseReqPayTimeSpan 1008、tblPurchaseReqPayUnits 1009、tblPurchaseReqPayMaterials 1010以及tblPurchaseReqPayProjectExpenses 1011中的数据库中。表tblPurchaseReqPayDeliverable 1007、tblPurchaseReqPayTimeSpan 1008、tblPurchaseReqPayUnits 1009、tblPurchaseReqPayMaterials 1010以及tblPurchaseReqPayProjectExpenses 1011中的每一个被显示为依赖于表tblPurchaseReq以使支付信息与普通购买请购单信息相关。
应当清楚，可包括附加的表或信息，这取决于购买请购单需要。另外，应当清楚，可包括一个或多个支付表，这取决于项目。此外，应当清楚可包括每个支付数额的独立记录，其具有下面的表71-75之一的格式。
表71 示范性tblPurchaseReqPayDeliverable(db structure view) 表72 示范性tblPurchaseReqPayTimeSpan(db structure view) 表73 Exemplary tblPurchaseReqPayUnits(db structure view) 表74 示范性tblPurchaseReqPayMaterials(db structure view) 表75 示范性tblPurchaseReqPayProjectExpenses(db structure view) 下面的表76和77举例说明了与分配给购买请购单的承包商的报酬费率有关的示例信息。例如，承包商报酬费率信息表示报酬的类型(例如，每小时、固定、加班等等)以及报酬费率数额(例如，每小时的可开票费率、每个加班小时的可开票费率、可开票数额)。报酬费率信息存储在表tblPurchaseReqPayRates 1014和tblluContractorPayRateTypes 1015的数据库中，其显示于图41中，且依赖于表tblPurchaseReq 1000以使报酬费率信息与购买请购单相关。应当清楚，每个承包商的每种报酬费率类型的独立报酬费率记录可被存储在表tblPurchaseReqPayRates 1014中。更进一步应当清楚，能够包括附加的表或信息，这取决于购买请购单需要。
表76 tblPurchaseReqPayRates(db structure view) 表77 tblluContractorPayRateTypes(db structure view) 下面的表78和79举例说明了与分配给购买请购单的承包商的承包商支出有关的示例支付信息。例如，承包商开支信息表示开支的类型和为该开支分配的最高额。承包商开支信息存储在表tblPurchaseReqPayContractorExpenses1016和tblluContractorPayExpenseTypes1017的数据库中，其显示于图41中，且依赖于表tblPurchaseReq 1000以使承包商开支信息与购买请购单相关。应当清楚，每个承包商的每种承包商开支类型的独立承包商开支记录可被存储在表tblPurchaseReqPayContractorExpenses 1016中。更进一步应当清楚，能够包括附加的表或信息，这取决于购买请购单需要。
表78 tblPurchaseReqPayContractorExpenses(db structure view) 表79 tblluContractorPayExpenseTypes(db structure view) 投标后活动 一旦项目已经开始，项目管理员(或买方)就能够利用计时系统来监视项目的进展，其中承包商把时间输入到所执行的项目工作的计时卡片中。该计时卡片可被存储以评估请购单支付信息的项目执行和/或基于工作时间而产生付款凭证，这取决于请购单支付信息。例如，如果请购单支付数额至少在某种程度上基于以一具体报酬费率的具体承包商的预期可开票小时数，并且承包商根据该预期可开票小时数来完成项目，则项目管理员和卖方可就最初基于交付、期限或单位而为支付所设置的请购单支付数额进行重新谈判。
现在参考图43，举例说明了用于实现本发明的系统内的计时系统的示范性步骤。承包商完成了所有必需的文件并且被授权进入该计时系统之后，承包商可进入该计时系统(步骤4300)以便把与承包商所工作的小时数有关的计时信息输入到计时卡片(例如，承包商的计时记录)中(步骤4310)。在计时系统为可访问的任何时候都可以输入计时信息。例如，计时系统可以仅在项目管理员确定的特定时间(例如，星期的结尾、星期的开始等)为可访问的，或者在计时系统没有离线的时间内为可访问的。
一旦承包商已经把计时信息输入到计时卡片中，就把计时卡片提供给项目管理员(步骤4325)以供审阅和批准(步骤4330)。如果没有批准计时卡片(步骤4340)，就告知承包商和卖方该计时卡片被拒绝(步骤4350)，并且委托承包商访问计时系统以修改计时卡片(步骤4300)。例如，如果承包商没有完整地填充计时卡片、输入到计时卡片中的计时信息(例如，小时数)不正常或不合理，或者项目管理员已经知道计时信息不正确，则可拒绝该计时卡片。如果批准了计时卡片(步骤4340)，则利用计时信息来更新系统内的所有适当记录(步骤4360)并且提取与该计时信息有关的任何可支付凭证以进行开发票处理(步骤4370)。例如，如果请购单支付是基于具体期限内所工作的小时数，则需要基于由承包商输入的计时信息而产生可支付凭证。
图44和45显示了通过计时系统提供给承包商的示范性网页61的屏幕快照。图44中举例说明了示例计时系统主页。从该主页中，承包商可以创建新计时卡片、调用暂时保存的计时卡片以用于完成的目的或者查看预先提交的计时卡片。另外，如果承包商被允许输入承包商支出(取决于购买请购单)，则承包商可创建新开支凭证、调用暂时保存的开支凭证以完成或查看预先提交的开支凭证。
为了创建新计时卡片(或完成暂时保存的计时卡片)，如图45所示，承包商可把各种计时信息1150输入到计时卡片1100中。例如，承包商可输入星期结束工作日期、项目的项目代码以及负责支付的成本中心。另外，承包商可输入每天正常标准工时数和每天加班标准工时数(以每种加班费费率)。应当清楚还可以由承包商输入其他计时信息，并且系统不局限于图45所示的具体计时信息。
图46显示了显示给项目管理员以进行所提交计时卡片的审阅的示例网页61的屏幕快照。除了所输入的计时信息之外，还可以向项目管理员提供与该计时卡片有关的其他相关购买请购单信息，诸如当前项目阶段、总账代码、税款使用代码、帐目分配代码以及帐目装备代码。基于所显示的计时信息，项目管理员可拒绝计时卡片或者批准计时卡片。如果项目管理员拒绝计时卡片，则向项目管理员显示一弹出窗口以提供计时卡片拒绝的原因。然而，应当清楚也可以向项目管理员显示用于计时卡片批准目的的其他信息，并且系统不局限于图46所示的特定信息。
下面在表80-83中显示了用于存储计时卡片和承包商开支凭证的示范性数据库结构。为简单起见把该数据结构举例说明为以表格格式进行组织的，其中每个表包括用于存储计时卡片和承包商开支凭证所需的所有字段。该表是以分层次且相关的方式关联的，其中其他表也存储该数据库中，如结合图47所讨论的那样。
下面的表80举例说明了示例普通计时信息，其可存储在表tblTimeCard 1050的数据库表结构1160中，如图47所示。例如，计时信息可包括计时卡片标识符、相关购买请购单标识符、承包商标识符、卖方标识符、关于所输入的时间是否是用于产生帐单记录的可开票时间的表示、与计时卡片有关的星期结束日期、创建日期、审阅日期以及是否已经批准了计时卡片的表示。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表80所示的特定信息。图47中显示了表tblTimeCard1050依赖于表tblPurchaseReqContractors 1012，其依赖于表tblPurchaseReq 1000，以上结合图41而讨论了这两个表，以使计时卡片与承包商和购买请购单相关。另外，图41所示各个其他表也在图47中被举例说明了以显示在各个购买请购单表与计时卡片和承包商开支凭证表之间的相互关系。
表80 示范性tblTimeCard(db structure view) 存储在表tblTimeCard 1050中的计时卡片状态标识符可从表tblluTimeCardStatus 1051中被选择出来，所述表tblluTimeCardStatus 1051存储了计时卡片状态类型(例如，暂时保存、已提交、已批准、已拒绝等等)及它们的相关计时卡片状态标识符。
表81举例说明了示例详细计时信息，其可存储表tblTimeCardDetails 1052的数据库中，如图47所示。例如，这种详细计时信息包括对于具体报酬费率类型在具体日子工作时输入的小时数、与报酬费率类型有关的报酬费率以及其他详细计时信息。表tblTimeCardDetails 1052被显示成依赖于表tblTimeCard 1050以使详细计时信息与普通计时信息相关，此外，表tblTimeCardDetails 1052依赖于表tblluDayCode 1053以使存储在表tblTimeCardDetails 1052中的日代码与具体日相关。应当清楚，对于承包商为其输入时间的每天的每种报酬费率类型来说，采用表81格式的独立记录被存储在表tblTimeCardDetails 1052中。更进一步应当清楚可以包括其他表和计时信息，并且系统不局限于图47所示的特定表和计时信息。
表81 示范性tblTimeCardDetails(db structure view) 下面的表82举例说明了示例普通承包商开支凭证信息，其可存储在表tblContractorExpenseVoucher 1054的数据库中，如图47所示。例如，这种普通承包商开支凭证信息包括开支凭证标识符、相关购买请购单标识符、承包商标识符、卖方标识符、与开支凭证有关的星期结束日期、创建日期、审阅日期以及是否已经批准了开支凭证的表示。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表82所示的特定信息。表tblContractorExpenseVoucher 1054被显示成依赖于表tblPurchaseReqContractors 1012，其依赖于表tblPurchaseReq 1000，以上结合图41而讨论了这两个表，以使承包商开支凭证与具体的承包商和购买请购单相关。
表82 标准tblContractorExpenseVoucher(db structure view) 下面的表83举例说明了示例详细承包商开支凭证信息，其可存储在表tblContractorExpenseVoucherDetails 1055的数据库中，如图47所示。例如，这种详细开支凭证信息可包括在具体日的具体开支类型的开支数额及其他详细开支凭证信息。表tblContractorExpenseVoucherDetails 1055被显示成依赖于表tblContractorExpenseVoucher 1054以使该详细开支凭证信息与一般费用凭证信息相关。另外，表tblContractorExpenseVoucherDetails 1055依赖于表tblluDayCode 1053以使存储在表tblContractorExpenseVoucherDetails 1055中的日代码与该具体日相关。应当清楚，对于承包商为其输入数额的每天的每种类型的开支来说，采用表83格式的独立记录被存储在表tblContractorExpenseVoucherDetails 1055中。更进一步应当清楚可以包括其他表和承包商开支凭证信息，并且系统不局限于图47所示的特定表和承包商开支凭证信息。
表83 标准tblContractorExpeeVoucherDetails(db structure view) 现在参考图48，有许多不同类型的凭证信息1160，其可被输入到系统中并被存储在数据库155中以产生要由买方或项目管理员支付给授权卖方的可支付凭证1180。例如，凭证信息1160可包括计时凭证信息1160a，其包括由承包商所输入的计时信息1150(在上述图45中所示)以及包括由与计时信息有关的所输入项目工作跟踪参数870(在上述图39和40中所示)所确定的请购单支付信息。凭证信息还可以包括项目开支凭证信息1160b、项目交付凭证信息1160c、项目物资凭证信息1160d、承包商开支凭证信息1160e、项目单位完成凭证信息1160f和项目分期付款核发凭证信息1160g。系统可自动地基于预先输入到其他环境(例如，项目跟踪参数项、计时项、承包商开支项和/或项目开支项)中的凭证信息1160而产生可支付凭证1180，或者卖方或买方/项目管理员可产生可支付凭证1180并把凭证信息1160(例如，单位完成项或交付完成项)的各个适当部分输入到可支付凭证1180中。
现在参考图49，举例说明了包含在凭证处理和支付系统中的示范性步骤。最初，各种项目跟踪参数(例如，购买请购单信息)被输入到系统中(步骤4400)，而对于货物和服务的所有卖方职责，无论是可开票的还是不可开票的，都被存储在数据库中(步骤4410)。当卖方提供已授权货物或服务(如由所输入的卖方职责来确定的)时(步骤4420)，卖方访问系统以记录所执行的货物或服务并且请求该货物或服务的支付(步骤4430)。在其他实施例中，支付是由系统在某些时段自动地请求的。系统基于项目跟踪参数及其他凭证信息(例如，计时信息、支出、物资等等)而产生凭证(步骤4440)并且把该凭证传递给适当的买方用户或管理员用户以对该凭证进行批准(步骤4450)。
如果没有批准凭证(步骤4460)，则通知卖方并向卖方提供重新提交该凭证的选项(步骤4470)。如果批准了凭证(步骤4460)，则通知卖方该凭证的批准(步骤4480)。如果凭证是可开票的凭证(步骤4490)，则对该凭证进行处理以便根据规定进度(利用系统或买方约束条件)来开具电子发票。例如，系统采用成批处理以收集在预先指定时期期间所批准的买方的所有付款凭证(对于一个或多个项目)。所有发票均可以根据买方规范的格式或者系统定义的格式而产生。买方接收发票(步骤4498)并且借助于预先配置的方法(例如，EFI、检验等等)向卖方核发发票的支付(步骤4499)。
下面在表84-92显示了用于在可支付的凭证中存储凭证信息并且产生报酬凭证记录的示范性数据库结构。为简单起见把该数据结构举例说明为以表格格式进行组织的，其中每个表包括用于存储凭证信息所需的所有字段。该表是以分层次且相关的方式关联的，其中其他表也存储在该数据库中，如结合图50所讨论的那样。
下面的表84举例说明了示例普通项目单位完成凭证信息，其可被存储在表tblVoucherUnits 1060的数据库表结构1170中，如图50所示。例如，普通项目单位完成凭证信息可包括单位凭证标识符、相关购买请购单标识符、关于是否已经批准了与单位完成有关的所有计时卡片的表示、卖方标识符、与凭证信息有关的星期结束日期、创建日期、审阅日期以及是否已经批准了凭证信息的表示。表tblVoucherUnits 1060被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使凭证信息与购买请购单相关。另外，此处在图50中举例说明了图41所示各个其他表以显示在各个购买请购单表与凭证表之间的相互关系。应当清楚，采用表84的格式的独立记录被存储在每个可支付单位凭证的表tblVoucherUnits 1060中。
此外，虽然没有显示，但是图47所示的表tblContractorExpenseVoucher 1054还被认为是用于产生可支付凭证的凭证表。应当清楚可以包括其他表和凭证信息，并且系统不局限于图50所示的特定表和凭证信息。
表84 tblVoucherUnits(db structure view) 下面的表85举例说明了示例详细项目单位完成凭证信息，其可被存储在表tblVoucherUnitsDetails1061的数据库中，如图50所示。例如，这种详细项目单位完成凭证信息包括单位完成的描述、所授权单位的数目、单位成本、所完成的单位的数目及其他详细项目单位完成凭证信息。表tblVoucherUnitsDetails 1061被显示成依赖于表tblVoucherUnits 1060以使详细项目单位完成凭证信息与普通项目单位完成凭证信息相关。另外，表tblVoucherUnitsDetails 1061依赖于表tblPurchaseReqPayUnits 1009以使请购单单位支付信息与项目单位完成凭证信息相关。
应当清楚，采用表85的格式的独立记录被存储在每个可支付单位凭证的表tblVoucherUnitsDetails1061中。更进一步应当清楚可以包括其他表和项目单位完成凭证信息，并且系统不局限于图50所示的特定表和项目单位完成凭证信息。
表85 tblVoucherUnitsPetais(db structure view) 下面的表86举例说明了示例普通时间完成凭证信息，其可被存储在表tblVoucherTimePayment1062的数据库中，如图50所示。例如，普通时间完成凭证信息可包括时间凭证标识符、相关购买请购单标识符、关于是否已经批准了与时间完成有关的所有计时卡片的表示、卖方标识符、与凭证信息有关的星期结束日期、创建日期、审阅日期以及是否已经批准了凭证信息的表示。表tblVoucherTimePayment 1062被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使凭证信息与购买请购单相关。应当清楚，采用表86的格式的独立记录被存储在每个可支付时间凭证的表tblVoucherTimePayment 1062中。
表86 tblVoucherTimePayment(db structure view) 下面的表87举例说明了示例详细时间完成凭证信息，其可被存储在表tblVoucherTimePaymentDetails 1063的数据库中，如图50所示。例如，这种详细时间完成凭证信息可包括工作开始日期、支付核发日期、支付数额及其他详细时间完成凭证信息。表tblVoucherTimeCompletionDetails 1063被显示成依赖于表tblVoucherTimePayment 1062以使详细时间完成凭证信息与普通时间完成凭证信息相关。另外，表tblVoucherTimePaymentDetails 1063依赖于表tblPurchaseReqPayTimeSpan 1008以使请购单时间支付信息与时间完成凭证信息相关。
应当清楚，采用表87的格式的独立记录被存储在每个可支付单位凭证的表tblVoucherTimePaymentDetails 1063中。更进一步应当清楚可以包括其他表和时间完成凭证信息，并且系统不局限于图50所示的特定表和时间完成凭证信息。
表87 tblVoucherTimePaymentDetails(db structure view) 下面的表88举例说明了示例普通项目开支凭证信息，其可被存储在表tblVoucherProjectExpense1064的数据库中，如图50所示。例如，普通项目开支凭证信息可包括项目开支凭证标识符、相关购买请购单标识符、关于是否已经批准了与项目开支(如果有的话)有关的所有计时卡片的表示、卖方标识符、与凭证信息有关的星期结束日期、创建日期、审阅日期以及是否已经批准了凭证信息的表示。表tblVoucherTimePayment 1064被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使凭证信息与购买请购单相关。应当清楚，采用表88的格式的独立记录被存储在每个可支付项目开支凭证的表tblVoucherProjectExpense 1064中。
表88 tblVoucherProjectExpense(db structure view) 下面的表89举例说明了示例详细项目开支凭证信息，其可被存储在表tblVoucherProjectExpenseDetails 1065的数据库中，如图50所示。例如，这种详细项目开支凭证信息可包括发生开支的日期、项目开支的描述、项目开支数额以及其他详细项目开支凭证信息。表tblVoucherProjectExpenseDetails 1065被显示成依赖于表tblVoucherProjectExpense 1064以使详细项目开支凭证信息与普通项目开支凭证信息相关。另外，表tblVoucherProjectExpenseDetails 1065依赖于表tblPurchaseReqPayProjectExpense 1011以使请购单项目开支支付信息与项目开支凭证信息相关。
应当清楚，采用表89的格式的独立记录被存储在每个可支付项目开支凭证的表tblVoucherProjectExpenseDetails 1065中。更进一步应当清楚可以包括其他表和项目开支凭证信息，并且系统不局限于图50所示的特定表和项目开支凭证信息。
表89 tblVoucherProjectExpenseDetails(db structure view) 下面的表90举例说明了示例普通物资凭证信息，其可被存储在表tblVoucherMaterials 1066的数据库中，如图50所示。例如，普通物资凭证信息可包括物资凭证标识符、相关购买请购单标识符、关于是否已经批准了与物资(如果有的话)有关的所有计时卡片的表示、卖方标识符、与凭证信息有关的星期结束日期、创建日期、审阅日期以及是否已经批准了凭证信息的表示。表tblVoucherMaterials 1066被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使凭证信息与购买请购单相关。应当清楚，采用表90的格式的独立记录被存储在每个可支付物资凭证的表tblVoucherMaterial 1066中。
表90 tblVoucherMaterials(db structure view) 下面的表91举例说明了示例详细物资凭证信息，其可被存储在表tblVoucherMaterialsDetails 1067的数据库中，如图50所示。例如，这种详细物资凭证信息可包括发生物资开支的日期、物资的名称、物资的描述、所购买物资单位数目、物资单位成本以及其他详细项目开支凭证信息。表tblVoucherMaterialsDetails 1067被显示成依赖于表tblVoucherMaterials 1066以使该详细物资凭证信息与普通物资凭证信息相关。另外，表tblVoucherMaterialsDetails 1067依赖于表tblPurchaseReqPayMaterials1010以使请购单物资支付信息与物资凭证信息相关。
应当清楚，采用表91的格式的独立记录被存储在每个可支付物资凭证的表tblVoucherMaterialsDetails 1067中。更进一步应当清楚可以包括其他表和物资凭证信息，并且系统不局限于图50所示的特定表和物资凭证信息。
表91 tblVoucherMaterialsDetails(db structure view) 下面的表92举例说明了示例普通交付凭证信息，其可被存储在表tblVoucherDeliverables 1068的数据库中，如图50所示。例如，普通交付凭证信息可包括交付凭证标识符、相关购买请购单标识符、关于是否已经批准了与交付(如果有的话)有关的所有计时卡片的表示、卖方标识符、与凭证信息有关的星期结束日期、创建日期、审阅日期以及是否已经批准了凭证信息的表示。表tblVoucherDeliverables 1068被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使凭证信息与购买请购单相关。应当清楚，采用表92的格式的独立记录被存储在每个可支付交付凭证的表tblVoucherDeliverables 1068中。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表92所示的特定信息。
表92 tblVoucherDeliverables(db structure view) 下面的表93举例说明了示例详细交付凭证信息，其可被存储在表tblVoucherDeliverablesDetails1069的数据库中，如图50所示。例如，这种详细交付凭证信息可包括交付的描述、交付的预期完成日期、交付的实际完成日期、所请求的支付数额及其他详细交付凭证信息。表tblVoucherDeliverablesDetails 1069被显示成依赖于表tblVoucherDeliverables 1068以使该详细交付凭证信息与普通交付凭证信息相关。另外，表tblVoucherDeliverablesDetails 1069依赖于表tblPurchaseReqPayDeliverables 1007以使请购单交付支付信息与交付凭证信息相关。
应当清楚，采用表93的格式的独立记录被存储在每个可支付交付凭证的表tblVoucherDeliverablesDetails 1069中。更进一步应当清楚可以包括其他表和交付凭证信息，并且系统不局限于图50所示的特定表和交付凭证信息。
表93 tblVoucherpeUverableExpenseDetails(db structure view) 下面的表94举例说明了示例报酬凭证信息，其可被存储在表tblPaidVoucherRecords 1070的数据库中，如图50所示。例如，这种报酬凭证信息包括发票号码、由买方和卖方分配的购买请购单身份、凭证批准日期、批准者姓名、凭证的类型(例如，计时卡片、承包商开支、项目开支、交付、时间完成或单位完成)以及相关凭证标识符、发票金额、支付日及其他报酬凭证信息。
表tblPaidVoucherRecords 1070被显示成依赖于表tblPurchaseReq 1000，以上结合图41而对其进行了讨论，以使报酬凭证信息与购买请购单相关。应当清楚，采用表94的格式的独立记录被存储在每个报酬凭证的表tblPaidVoucherRecords 1070中。然而，应当清楚也可以包括其他投标信息，以及系统不局限于表94所示的特定信息。
表94 示范性tblPaidVoucherRecords(db structure view) 现在参考图51，举例说明了用于显示该项目的财务状况的示范性网页61的屏幕快照。这个网页以一种或多种格式对买方、卖方和/或管理员是可访问的，这取决于系统约束条件。如在图51中可见，显示了不同类型的付款凭证、以及每个付款凭证的估计金额。另外，还可以跟踪每种付款凭证类型所消耗的实际金额以及每种付款凭证类型所要消耗的估计补充资金。用这种方法，买方、卖方和/或管理员可根据财务观点维护对项目执行的工作认识。然而，应当清楚还可以显示其他财务信息而不是图51所示的特定财务信息或除了图51所示特定财务信息之外。此外，应当清楚取决于买方、卖方、管理员和/或系统配置还可以显示其他项目相关信息(代替财务信息或除了财务信息之外)，如下文更详细地讨论的那样。
交易数据的分析和报告 在如上所述的投标前、投标以及投标后活动期间，从该处理所涉及的买方、卖方及其他当事人(例如，管理员)处得到与投标/项目处理有关的各种交易数据。如图58所示，交易数据1195可包括一个或多个组成部分投标数据212、项目跟踪参数870、凭证信息1160以及项目执行数据1190。交易数据1195的每个组成部分是在投标/项目处理的各个阶段期间得到的。交易数据1195中还可以包含其他组成部分，诸如卖方资格信息、买方定义的卖方标准信息、商品信息及其他投标前和项目相关数据。总之，交易数据1195可包括任何存储在数据库系统150的数据. 例如，现在参考图52，举例说明了用于显示买方50、卖方10与PBMS(下文的系统)30之间的信息交换的信号示意图。正如以上的讨论，最初，买方50经由系统30向卖方10传送投标请求(步骤4500)。投标请求包含具有由买方50输入其中的投标请求数据的数据字段以及用于卖方10输入投标响应数据的数据字段。当卖方10把投标响应数据输入到适当数据字段时，包括该投标响应数据的投标响应经由系统30被传送回买方50(步骤4510)。同时，投标请求数据和投标响应数据形成所完成投标的投标数据212。投标数据212被存储在与该投标有关的记录系统数据库中，如上所述。
一旦买方50把投标授予给具体的卖方10，买方50和卖方10就都能够把项目跟踪参数870(例如，购买请购单信息、纳税信息等等)输入到系统30中(步骤4520)以便与投标数据212一起存储在数据库中。项目跟踪参数870可包括可开票的和不可开票的一些或所有合同条款和条件，包括对货物和服务的卖方职责。当卖方10提供授权的货物或服务(如由所输入的项目跟踪参数870所确定的那样)时，如果对于所提供的货物或所执行的服务来说该活动是不可开票的，那么卖方10访问系统以提交凭证以请求支付、或完成的买方确认(步骤4530)。当为同一活动批准凭证并随后开具发票时，买方经由预先配置的方法来向卖方核发支付(步骤4540)。在凭证提供和支付处理期间由买方50和卖方10输入的信息作为凭证信息1160被存储在数据库中。
在项目执行期间，可把各种项目执行数据1190输入到系统30中，或者由卖方10和买方50自动地产生(步骤4550)，如下文中结合图53-57而更详细地描述的那样。例如，项目执行数据1190可包括各种状态信息，诸如计时信息(例如卖方关于项目的一个或多个阶段或组成部分的完成的时间性表示)、或成本信息(例如，同相应项目(请购单)成本比较起来该项目的一个或多个组成部分的实际成本)。项目执行数据1190还包括项目特定信息，诸如项目重要性或该项目对公司其他方面的影响，或者其他的顾客特定信息。
投标数据212、项目跟踪参数870、凭证信息1160和项目执行数据1190全部被存储在系统数据库中以作为与投标和项目有关的交易数据。随着对所有这些交易数据的访问，系统30实际上地执行任何类型的所期望分析并且根据所述分析而产生报告。因而，随着对该分析数据的访问，系统30可操作地从买方、卖方或另外的用户处接收对某些类型的分析数据的请求(步骤4560)。根据该请求，系统30执行交易数据分析以产生分析数据(步骤4570)并且在报告视图中把分析数据提供给请求者(例如，买方50、卖方10或其他用户)(步骤4580)。
例如，买方50可请求其包含有与特定项目、多个项目或多个卖方10有关的分析数据的报告。所述分析数据指向财务信息(例如，发票细节、花费(过去、现在和将来)及其他类型的财务分析)、项目信息(例如，项目执行、未来项目活动及项目计划)、卖方信息(例如，卖方财务信息、卖方操作信息及供应链信息)以及所期望的任何其他类型的信息。另外，买方50可请求其包含有与由多个买方50所代理的多个项目有关的行业分析数据的报告。该行业分析数据可指向财务信息(例如，在项目类型的各个方面上花费的总成本的百分比或在行业范围内花费在各种类型的项目上的总额的百分比)、卖方信息(例如，该行业中卖方的按时百分比或该行业中超出/低于卖方预算的成本百分比)、以及所期望的任何其他类型的行业信息。可把类似的分析数据提供给卖方10或其他授权用户。例如，卖方10或管理员可请求其包含有与在执行中涉及到该卖方10的特定项目、多个项目那些该卖方10有关的分析数据的报告。
现在转向图53，举例说明了用于输入项目执行数据1190的示范性功能。根据本发明的实施例，图53中举例说明了项目执行工具121和比较工具123以用于输入项目执行数据。项目执行工具121和比较工具123可包括需要执行该工具功能的任何硬件、软件和/或固件，并且可在服务器120或附加服务器(未显示)内实现。例如，项目执行工具121和比较工具123可驻留在服务器120内的软件模块128中，如图3B所示。
在一个实施例中，可由买方、卖方或管理员通过项目执行工具180把项目执行数据1190直接输入到数据库155中。买方、卖方或管理员可分别经由买方浏览器20a、卖方浏览器20b或管理员浏览器20c和数据网络40来访问计算机系统100的服务器120。买方模块110、卖方模块115或管理员模块135与项目执行工具121相连接以把网页分别推给请求项目执行数据的买方浏览器20a、卖方浏览器20b或卖方浏览器20b或管理员浏览器20c。项目执行工具121访问数据库155以利用买方、卖方和/或管理员所输入的项目执行数据来填写与具体项目有关的项目执行数据字段。例如，项目执行数据可包括买方、卖方和/或管理员关于到目前为止的状态或个人项目满意度的评述。
当从买方、卖方或管理员处接收项目执行数据1190时，项目执行工具121可更进一步被配置以自动地产生给另一当事人的消息(例如，电子邮件消息)，把新项目执行数据1190通知给他们，借此允许另一当事人输入附加的项目执行数据1190，其阐明、响应或者提供与先前输入的项目执行数据1190无关的数据。
在其他实施例中，根据对项目跟踪参数870和与具体项目有关的凭证信息1160的比较，比较工具123自动地把项目执行数据1190输入到数据库155中。比较工具从数据库155中检索必要的项目跟踪参数870和凭证信息1160、执行对所检索的项目跟踪参数870和凭证信息1160的比较或分析、以及根据比较或分析的结果而把任何必需的项目执行数据1190输入到与数据库155内的项目有关的数据字段中。
举例来说，比较工具123可被配置以监视数据库155的新凭证信息1160的输入，或者相反当输入新凭证信息1160时被触发以把所输入的凭证信息1160与先前存储的该项目的项目跟踪参数870相比较。凭证信息1160可包含成本、时间或其他信息，利用这些信息来与项目跟踪参数870相比较。比较的结果可作为项目执行数据1190而被存储在数据库155中。例如，凭证信息1160表示由买方50在项目上支付的发票金额，并且比较工具123可把该发票金额与请购单金额相比较以确定是否存在差异。在这种情况下，项目执行数据1190包括成本状态的表示，诸如低于预算、超出预算或者预算内，以及如果有的话，包括超出或者低于预算的金额。
作为另一个例子，比较工具123可被配置以在数据库155中搜索具体的项目跟踪参数870，并且输入项目跟踪参数870的状态作为项目执行数据1190。例如，比较工具123可在数据库155中搜索关于项目的到期目标完成日期，并且输入每个项目的逾期天数以作为与那些项目有关的项目执行数据1190。比较工具123更进一步搜索与那些逾期项目有关的凭证信息1160并且根据该凭证信息1160而输入项目的状态。例如，如果卖方已经提交了支付凭证，但是买方还没有付款，则该状态能够表示凭证已提交、等待付款。
图54-56显示了用于根据各种系统观点来输入项目执行数据1190的示范性处理。图54举例说明了诸如买方、卖方或管理员之类的用户把项目执行数据输入到系统中的示范性步骤。当从与项目有关的用户处接收项目执行数据时(步骤4600)，系统把项目执行数据存储在与该项目有关的数据字段中以供随后使用和检索(步骤4610)。如果该项目所涉及的当事人(买方、卖方和管理员)已经建立了用于允许一部分或所有项目执行数据在当事人之间公开的条件，则系统根据该当事人所设置的条件而产生给另一当事人的消息，把已接收的项目执行数据通知给他们(步骤4620)。响应于该消息，另一当事人可选择输入附加的项目执行数据，其阐明、响应或提供了与先前输入的项目执行数据无关的数据。如果接收了附加项目执行数据(步骤4630)，则系统把该附加项目执行数据与先前输入的项目执行数据一起存储在数据库内与该项目有关的数据字段中(步骤4640)。
图55举例说明了用于根据先前存储的项目跟踪参数和凭证信息来自动地把项目执行数据入到系统中的示范性步骤。系统接收具体项目的项目跟踪参数(步骤4700)和凭证信息(步骤4710)之后，该系统把项目跟踪参数与凭证信息进行比较(步骤4720)以确定项目的状态(步骤4730)。项目状态可被输入到系统中并存储为与该项目有关的项目执行数据(步骤4740)。例如，凭证信息可表示关于项目的实际项目完成日期，系统可把该实际项目完成日期与目标项目完成日期相比较以确定是否存在差异。在这种情况下，项目执行数据包括状态的表示，诸如按时完成、逾期完成或提前完成，以及逾期或提前的天数。
图56举例说明了用于根据先前存储的项目跟踪参数的状态来自动地把项目执行数据输入到系统中的示范性步骤。系统接收了诸如目标完成日期之类的具体项目的项目跟踪参数(步骤4750)之后，系统可在数据库中搜索关于项目的到期目标完成日期(步骤4760)。如果找到了到期完成日期(步骤4770)，系统就能够根据已经接收的任何凭证信息来确定项目的状态(步骤4780)，并且把该项目状态输入到系统中作为项目执行数据(步骤4790)。
下面的表95-112显示了用于存储项目执行数据1190的示范性数据库结构。为简单起见把该数据结构举例说明为以表格格式进行组织的，其中每个表包括用于存储项目执行数据1190所需的所有字段。该表是以分层次且相关的方式关联的，其中其他表也存储在该数据库中，如结合图57所讨论的那样。
下面的表95和96举例说明了示例可交付项目执行数据，其可被存储在表tblDeliverableTrackPerformance 1080和表lkpDeliverableStatus 1081的数据库表结构1185中，如图57所示。交付项目执行数据可包括交付状态，如根据表lkpDeliverableStatus 1081而确定的那样。例如，交付状态可以是当前未完成、逾期未完成、当前部分完成、逾期部分完成、按时完成、逾期完成或提前完成。与该状态有关标识符连同存储在表tblPurchaseReqPayDeliverables 1007中与交付项目跟踪参数有关的标识符，当前状态(例如，推迟或提前的天数)以及任何用户注释可被存储在表tblDeliverableTrackPerformance中，。
例如，如果买方、卖方或其他用户已经输入了与该交付的状态有关的任何评述，则把这些评述存储在表tblDeliverableTrackPerformance 1080中。除了评述之外，还可以存储输入评述的用户的身份以及输入评述的日期。如果系统被配置成当买方输入评述时通知卖方，那么还可以存储卖方响应的状态(例如，还没响应、不响应、响应)。
表tblDeliverableTrackPerformance 1080和lkpDeliverableStatus 1081被显示成依赖于表tblPurchaseReqPayDeliverable 1007，其随后依赖于表tblPurchaseReq 1000，以上结合图41对其进行了讨论，以使项目执行数据与凭证信息和项目跟踪参数(例如，购买请购单)相关。另外，此处在图57中举例说明了图41所示各个其他表以显示在各个项目执行表、凭证表与购买请购单表之间的相互关系。应当清楚，采用表95的格式的独立记录被存储在每个可支付交付凭证的表tblDeliverableTrackPerformance 1080中。应当清楚可以包括其他表和项目执行数据，并且系统不局限于图57所示的特定表和项目执行数据。
表95 示范性tblDeliverableTrackPerformance 表96 示范性ikpDeliverableStatus 下面的表97和98举例说明了示例阶段项目执行数据，其可被存储在表tblPhaseTrackPerformance1082和表lkpPhaseStatus 1083的数据库表结构1185中，如图57所示。阶段项目执行数据可包括阶段状态，如根据表lkpPhaseStatus 1082而确定的那样。例如，阶段状态可以是当前开始、过期开始、将来开始、按时结束、过期结束、或提前结束。与该状态有关标识符连同存储在表tblPurchaseReqPhasing1018中与阶段项目跟踪参数有关的标识符，当前状态(例如，推迟或提前的天数)以及任何用户注释可被存储在表tblPhaseTrackPerformance中，，其是类似于图41中所示的表的一个表。
例如，如果买方、卖方或其他用户已经输入了与该阶段的状态有关的任何评述，则把这些评述存储在表tblPhaseTrackPerformance 1083中。除了评述之外，还可以存储输入评述的用户的身份以及输入评述的日期。如果系统被配置成当买方输入评述时通知卖方，那么还可以存储卖方响应的状态(例如，还没响应、不响应、响应)。
表97 示范性tblPhaseTrackPerformance 表98 示范性IkpPhaseStatus 下面的表99和100举例说明了示例单位项目执行数据，其可被存储在表tblUnitsTrackPerformance1084和表lkpUnitStatus 1085的数据库表结构1185中，如图57所示。单位项目执行数据可包括单位状态，如根据表lkpUnitsStatus 1085而确定的那样。例如，单位状态可以是当前未完成、逾期未完成、按时完成、逾期完成、或提前完成。与该状态有关标识符连同存储在表tblPurchaseReqPayUnits 1009中与单位项目跟踪参数有关的标识符，当前状态(例如，推迟或提前的天数)以及任何用户注释可被存储在表tblUnitTrackPerformance中。。
例如，如果买方、卖方或其他用户已经输入了与该单位的状态有关的任何评述，则把这些评述存储在表tblUnitsTrackPerformnce 1084中。除了评述之外，还可以存储输入评述的用户的身份以及输入评述的日期。如果系统被配置成当买方输入评述时通知卖方，那么还可以存储卖方响应的状态(例如，还没响应、不响应、响应)。
表99 示范性tblUnitsTrackPerformance 表100 示范性Ikp TJnitsStatus 下面的表101和102举例说明了示例成本项目执行数据，其可被存储在表tblCostTrackPerformance1086和表lkpCostStatus 1087的数据库表结构1185中，如图57所示。成本项目执行数据与任何类型的凭证的任可支付凭证有关，所述凭证包括物资凭证、支出凭证、交付凭证、阶段凭证、单位凭证以及分期付款凭证。成本项目执行数据由成本状态来表示，如根据表lkpCostStatus 1087而确定的那样。例如，成本可以是超出预算、低于预算或预算内。与该状态有关标识符连同存储在表tblPaidVoucherRecords 1070中与凭证信息有关的标识符，当前状态(例如，超出或低于预算的金额)以及任何用户注释可被存储在表tblCostTrackPerformance中。。
例如，如果买方、卖方或其他用户已经输入了与该成本的状态有关的任何评述，则把这些评述存储在表tblCostTrackPerformance 1086中。除了评述之外，还可以存储输入评述的用户的身份以及输入评述的日期。如果系统被配置成当买方输入评述时通知卖方，那么还可以存储卖方响应的状态(例如，还没响应、不响应、响应)。
表101 示范性tblCostTracfcPerformance 表102 示范性IkpCostStatus 图57中还显示了其他表，其包含与该项目和/或卖方或买方有关的附加数据，所述附加数据用来更进一步地识别项目的类型及先前没有明确地讨论的其他项目变更。所述附加数据还可以被包含于所利用的交易数据中以用于分析和报告的目的。例如，下面的表103举例说明了项目关于买方的其他方面的影响，其被存储在表lkpProjecthnpactCode 1072的数据库表结构1185中，下面的表104举例说明了交付重要性，其被存储在表lkpDeliverableImportance的数据库表结构1185中，以及下面的表105举例说明了项目的所有权状态，其被存储在表lkpPMOwndershipStatus 1073的数据库表结构1185中，如图57所示。
与卖方和买方有关的其他信息可被存储在附加表中。例如，下面的表106举例说明了主要的卖方数据，其被存储在表lkpVendorMaster 1090的数据库表结构1185中，以及下面的表107举例说明了主要的买方数据，其被存储在表lkpBuyerMaster 1095的数据库表结构1185中，如图57所示。另外，下面的表108和109举例说明了卖方等级信息，其表示买方已经分配给卖方的等级组(等级1的卖方是典型地首先采用或最经常采用的卖方)，其被存储在表lkpVendorTier 1091和tblVendorTierMap 1092的数据库表结构1185中，如图57所示。此外，下面的表110-112举例说明了买方行业划分、花费和规模信息，其被存储在表lkpIndustrySegmentation 1096、lkpBuyerSpendProfile1097和lkpBuyerSizeProfile 1098的数据库表结构1185中，如图57所示。行业划分是项目特定的或总体上适用于买方的。
表103 示范性IkpProjectImpactCode 表104 示范性IkpDeliverableImportance 表105 示范性IkpPMOwnershipStatus 表106 示范性IkpVendorMaster 表107 示范性IkpBuyerMaster 表108 示范性IkpVendorTier 表109 示范性tblVendorTierMap 表110 IkpIndustrySegmentation 表111 IkpBuyerSpendProfile
表112 IkpBuyerSizeProfile
如上结合图52所述，项目执行数据形成了存储在数据库中的一部分交易数据。再次参考图58，交易数据1195不仅包括投标数据212，而且包括项目跟踪参数870、凭证信息1160以及项目执行数据1190。所有交易数据1195都被存储在低级数据库系统150中，所述低级数据库系统150包含买方、卖方和管理员的数据库(155，未显示)。在一些实施例中，仅在该低级数据库150处维护交易数据1195，因此，仅把分析数据限制于那个低级数据库内的交易数据1195。例如，买方/管理员或卖方可能不允许由任何外部(第三方)来源来访问他们的交易数据。在这种情况中，为了产生包括买方/管理员或卖方交易数据的分析数据，仅仅把买方/管理员或卖方限制于他们的交易数据。
在其他实施例中，如图59所示，所有或一部分交易数据1195可被传送直至高级数据库160(在下文中为中央数据库160)以便随后为了分析的目的而使用或检索。任何时候或由于任何原因可以把交易数据从低级数据库155传送到中央数据库160。举例来说，可以把分别存储在多个买方数据库155a、155b和115c中的交易数据1195a、1195b和1195c(总起来说为1195)传送到中央数据库160以存储于其中。所述传送可按照批处理方式来发生，其中把特定时期内具有记录创建日期的交易数据1195以成批方式传送到中央数据库160中。例如，每星期，把具有那个星期的记录创建日期的所有交易数据1195以成批方式传送到中央数据库160中。
所传送的交易数据1195可包括低级数据库160中的所有交易数据1195或者由系统或买方/管理员和/或卖方所指定的仅一部分交易数据1195。例如，交易数据1195的各个部分可以不是行业范围分析目的所必需的，因此，传送到中央数据库160中的交易数据1195可排除不必要的那些部分。作为另一个例子，买方/管理员和/或卖方由于保密或其他原因可能希望限制适用于中央数据库160的交易数据1195的类型。
现在参考图60，举例说明了用于产生分析数据270的示范性功能。根据本发明的实施例，图60显示了用于产生分析数据270的报告模块126或127。报告模块126或127可包括需要执行该工具功能的任何硬件、软件和/或固件，并且可分别在服务器120或125或附加服务器(未显示)的一部分实现。例如，报告模块126可驻留在服务器120内的软件模块128中，如图3B所示。
可利用来自低级数据库系统150内的低级数据库(未具体地显示)或来自中央数据库160的交易数据1195来产生分析数据270，这取决于所期望的分析数据270的类型。例如，如果买方用户仅需要关于与买方相关的那些项目的分析数据，那么买方用户会访问低级数据库系统150内的买方的低级数据库内交易数据1195。然而，如果买方用户需要关于与多个买方相关的项目的行业分析数据，那么买方用户会访问中央数据库160内交易数据1195。
为了利用来自低级数据库系统150或中央数据库160的交易数据1195而接收分析数据270，买方用户、卖方用户或管理员用户分别经由买方浏览器20a、卖方浏览器20b或者管理员浏览器20c和数据网络40而访问与数据库150或160有关的相应服务器120或125。买方模块110或140、卖方模块115或145或者管理员模块135或149与报告模块126或127相连接，以便分别把网页推给买方浏览器20a、卖方浏览器20b或者管理员浏览器20c以在产生对于特定类型的分析数据270的请求285的过程中帮助买方用户、卖方用户或者管理员用户。例如，所请求的分析数据270与各种价格和执行因素有关，其与交易数据1195有关。分析数据270与单个项目、多个项目、多个卖方或多个买方有关，后者可能仅具有中央数据库交易数据1195。可产生的不同类型的分析数据270的不同变换和可能性仅仅由所存储的交易数据1195的类型和金额来限制。另外，应当清楚，虽然未显示，但是在其他实施例中，可允许承包商用户访问授权承包商进行查看的各种分析数据270，诸如承包商迄今为止在项目上工作的小时数、在某个时期内所有项目上工作的小时数、不同项目的支付费率、平均支付费率等等。
在一些实施例中，由用户提交的请求285可包含一个或多个过滤器280以分析数据270集中在特定交易数据1195上。例如，用户可能想要仅接收与那些在特定地区中所完成的项目有关的分析数据270或者与特定项目类型或行业划分有关的分析数据270。报告模块126或127利用过滤器280来访问数据库150或160以检索所过滤的交易数据1198，所述交易数据1198仅包含满足过滤器280的需要的那个交易数据。根据所过滤的交易数据1198，报告模块126或127产生分析数据270。
利用该交易数据1195或所过滤的交易数据1198，报告模块126或127可根据请求285而产生分析数据270。例如，如果请求285是对于表示将来几个月在当前项目上的项目花费的财务报告的，则报告模块126或127可访问交易数据1195以检索出与当前项目的未来请购单金额有关的各种项目跟踪参数，并且按月综合请购单金额以产生分析数据270。作为另一个例子，如果请求285是对于等级1的卖方在项目的各种组成部分(例如，物资、支出、交付、劳动力等等)上的开支百分比的统计报告的，则报告模块126或127可访问交易数据1195以检索出各种投标数据(以确定依赖于等级1的卖方的项目)、项目跟踪参数、凭证信息以及项目执行数据，并且利用各种数学和统计学函数来生成分析数据270。报告模块126或127把包括报告视图的网页推给买方浏览器20a、卖方浏览器20b或管理员浏览器20c，所述报告视图包含该分析数据。
图61-67显示了用于利用各种类型的交易数据来产生各种类型的分析数据270的示范性处理。然而，应当清楚所示处理仅仅是能够利用本发明的系统来执行的大量处理的例子。图61是描述用于按照系统用户的要求来产生分析数据的处理的示范性流程图。在这个处理中，接收对与交易数据有关的分析数据的请求(步骤4800)，所述交易数据至少包括在线投标处理期间所收集的投标数据。该请求被提交为搜索和/或分类请求，以便选择如投标中所提交的具体或普通类型的投标数据。另外，该请求可包括一个或多个过滤器，以把投标数据量缩小在产生分析数据中所使用的所选类型的投标数据内。
一旦识别和检索了必要的交易数据，就根据该交易数据而产生分析数据(步骤4810)。在产生分析数据过程中，可利用各种数学和统计学函数来产生用户所请求的各式各样的信息。分析数据可根据与单个项目、多个项目、多个卖方或多个买方有关的投标数据而产生，并且可在各种报告视图中将其呈现给用户。例如，示范性报告视图包括概述视图、综合视图、估计视图、统计视图、项目执行视图或其任意组合。用户可为了各种目的而利用该分析数据，所述目的包括评估个人投标、评估卖方执行、评估花费或收入、评估行业内通货膨胀、生成行业趋势信息等等。
图62是描述用于产生分析数据的处理的示范性流程图，所述分析数据包括该系统内跨越现在、过去和/或将来项目的综合项目执行数据。该项目执行数据由系统来存储(步骤4820)，如上结合图53-56所述。在这个处理中，从系统的授权用户处接收对综合项目执行数据的请求(步骤4830)。该请求可被提交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的项目执行数据。另外，该请求可包括一个或多个过滤器，以把项目执行数据量缩小在产生分析数据中所使用的所选类型的项目执行数据内。应当清楚，该请求将从由一个或多个卖方为一个或多个买方所执行的多个项目之中收集项目执行数据，以便综合该项目执行数据。
一旦识别和检索了必要的项目执行数据，就产生综合项目执行数据(步骤4840)。在产生综合项目执行数据过程中，可利用各种算术和/或统计分析运算。例如，系统可计算与项目有关的各种信息，诸如按时或低于预算的项目的百分比等等。可以在各种报告视图中把该综合项目执行数据呈现给用户。例如，示范性报告视图包括概述视图、估计视图或统计视图。用户可为了各种目的而利用该综合项目执行数据，所述目的包括评估一个卖方相对于其他卖方的个人表现、评估过去、现在或将来的花费或收入、评估行业内通货膨胀、生成行业趋势信息等等。
图63是描述用于产生分析数据的处理的示范性流程图，所述分析数据包括与个人项目有关的综合统计项目执行数据。该项目执行数据由系统来存储(步骤4850)，如上结合图53-56所述。在这个处理中，从系统的授权用户处接收对综合统计项目执行数据的请求(步骤4860)。该请求被提交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的项目执行数据。另外，该请求可包括一个或多个过滤器，以把项目执行数据量缩小在产生分析数据中所使用的所选类型的项目执行数据内。应当清楚，该请求将从由一个或多个卖方为一个或多个买方所执行的多个项目之中收集项目执行数据，以便计算与该个人项目有关的统计数据并综合该统计数据。
一旦识别并检索了必要的项目执行数据，就能利用各种算术和/或统计分析运算来为个人项目计算统计项目执行数据(步骤4870)。统计分析可计算关于项目的各种信息，诸如平均按月成本、平均支出、项目的各个组成部分或方面占总成本的百分比等等。此后，对单独的统计数据进行综合以产生综合统计项目执行数据(步骤4880)。可以在各种报告视图中把该综合统计项目执行数据呈现给用户。例如，示范性报告视图包括概述视图、估计视图，等等。通过跨越由卖方执行的多个项目而对统计数据进行综合，买方可得到被执行的项目的全貌图以从总体上参与评估该项目。
图64是描述根据交易数据而产生分析数据的示范性流程图，其中交易数据至少包括投标数据、项目跟踪参数和项目执行数据。该交易数据由系统来存储(步骤4900)，如上结合图52所述。在这个处理中，从系统的授权用户处接收对分析数据的请求(步骤4910)。该请求被据交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的交易数据。另外，该请求可包括一个或多个过滤器，以把交易数据量缩小在产生分析数据中所使用的所选类型的交易数据内。
一旦识别并检索必要的交易数据，就根据该交易数据的一个或多个组成部分(例如，投标数据、项目跟踪参数和/或项目执行数据)来产生分析数据(步骤4920)。在产生分析数据过程中，可利用各种数学和统计学函数来产生用户所请求的各式各样的信息。分析数据可根据与单个项目、多个项目、多个卖方或多个买方有关的交易数据而产生，并且可在各种报告视图中来将其呈现给用户。例如，示范性报告视图包括概述视图、综合视图、估计视图、统计视图、项目执行视图或其任意组合。可将分析数据用图表显示以帮助用户分析项目或行业趋势。
图65是描述收集交易数据并根据交易数据产生分析数据的更详细处理的示范性流程图。最初，由买方形成投标，其中投标包括数据字段以从买方和卖方处接收投标数据(步骤4950)。例如，该数据字段允许买方和卖方输入与价格、数量、以及采购时间期限有关的投标数据。应当清楚，包含于投标中的数据字段与所选投标内容有关，如以上在投标活动部分中所述。当由系统从买方和卖方处接收投标数据时(步骤4955)，把投标数据存储在系统中作为交易数据(步骤4960)。
当授予项目时，与投标有关的项目的项目跟踪参数被接收(步骤4965)并被更进一步存储为交易数据(步骤4970)。在项目执行期间，与项目有关的各个项目执行数据被接收(步骤4975)并被更进一步存储为交易数据(步骤4980)。一旦已经接收并存储了交易数据，就接收对与交易数据有关的分析数据的后续请求(步骤4985)。该请求由用户提交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的交易数据。另外，该请求可包括一个或多个过滤器，以把交易数据量缩小在产生分析数据中所使用的所选类型的交易数据内。
一旦识别并检索必要的交易数据，就根据该交易数据的一个或多个组成部分(例如，投标数据、项目跟踪参数和/或项目执行数据)来产生分析数据(步骤4990)。在产生分析数据过程中，可利用各种数学和统计学函数来产生用户所请求的各式各样的信息。分析数据可根据与单个项目、多个项目、多个卖方或多个买方有关的交易数据而产生，并且可在各种报告视图中来将其呈现给用户。例如，示范性报告视图包括概述视图、综合视图、估计视图、统计视图、项目执行视图或其任意组合。可将分析数据用图表显示以帮助用户分析项目或行业趋势。
图66是描述用于产生与由一个或多个买方的项目所生成的交易数据有关的行业分析数据的处理的示范性流程图。因为系统能够管理多个买方的项目，所以可根据整个行业内所执行的项目来评估行业分析数据。当然在利用系统的过程中，可借助于交易信息来跟踪利用该系统的买方的各个项目。通过跨越多个买方来分析交易数据，可以发展行业趋势。例如，在电信行业中，其中可能有与中心交换局安装有关的多个项目，可利用本发明的原理来产生中心交换局的平均成本、开发时间、安装时间以及故障率。
最初，当由系统(例如，图2A中的管理员服务器125)接收到对行分析析数据的请求时开始行业分析处理(步骤5000)。该请求可以是来自系统的卖方、买方或管理员的。根据该请求，在中央数据库中访问与跨越多个买方的多个项目有关的交易数据(步骤5010)。该请求由用户提交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的交易数据。另外，该请求可包括一个或多个过滤器，以把交易数据量缩小在产生分析数据中所使用的所选类型的交易数据内。
一旦识别和检索了必要的交易数据，就产生与交易数据有关的行业分析数据(步骤5020)。在产生行业分析数据中，可利用数学和/或统计学函数来在视图中生成用户感兴趣的各种行业分析数据。可以在各种报告视图中把该行业分析数据呈现给用户。例如，示范性报告视图包括概述视图、综合视图、估计视图、统计视图、项目执行视图或其任意组合。可将分析数据用图表显示以帮助用户分析项目或行业趋势。
图67是描述借助于批处理方式从多个买方收集交易数据并根据交易数据产生行业分析数据的更详细处理的示范性流程图。个人项目的交易数据被存储在与该项目所涉及的买方、卖方和管理员有关的低级数据库中(步骤5050)。为了处理对行业分析数据的请求，以批处理方式把每个低级数据库中的必要交易数据和授权交易数据检索至中央数据库中，如上所述且如本领域中所理解的那样(步骤5060)。一旦已经接收并存储了成批交易数据，就接收对与该成批交易数据有关的行业分析数据的后续请求(步骤5070)。该请求由用户提交为搜索和/或分类请求，以便选择如由系统所收集的具体或普通类型的交易数据。另外，该请求可包括一个或多个过滤器，以把交易数据量缩小在产生分析数据中所使用的所选类型的交易数据内。
根据该请求和任何过滤，系统对该成批交易数据进行访问以识别和检索执行所请求的行业分析所需要的具体成批交易数据(步骤5080)。此后，根据所识别的成批交易数据来产生行业分析数据(步骤5090)。在产生行业分析数据过程中，可利用各种数学和统计学函数来产生用户所请求的各式各样的信息。可以在各种报告视图中把该行业分析数据呈现给用户(步骤5095)。例如，示范性报告视图包括概述视图、综合视图、估计视图、统计视图、项目执行视图或其任意组合。可将行业分析数据用图表显示以帮助用户分析项目或行业趋势。
正如以上的讨论，用户提交的分析数据请求可包括一个或多个过滤器以制作在分析处理中所利用的交易数据的类型。现在参考图68，举例说明了示范性类型的过滤器280，其可用于访问数据库155或160以为了分析和报告的目的而检索所过滤的交易数据1198。例如，过滤器280可包括卖方概况属性280a、买方概况属性280b、项目概况属性280c和商品概况属性280d。卖方概况属性280a包括与卖方存关的任何类型的数据，诸如卖方等级组、卖方企业实体类型、卖方资格数据、卖方地理位置等等。同样地，买方概况属性280b类似地包括与买方有关的任何类型的数据，诸如买方行业划分、买方规模或消费能力、买方地理位置等等。项目概况属性280c包括与项目有关的任何类型的数据，诸如项目类型、项目管理所有权类型、商业影响类型、项目地理位置、项目部门/族，其他项目跟踪参数等等。商品概况属性280d包括与商品(例如，人力资源或物资资源)有关的任何类型的数据，诸如与该商品有关的项目部门/族、资源概况、活动类型、地理位置等等。
图69显示了用于从数据库中检索所过滤的交易数据的示范性步骤。在把交易数据存储在数据库中(步骤5100)之后，接收对与交易数据有关的分析数据的后续请求(步骤5110)。基于请求的类型(例如，所请求的分析数据的类型)，系统访问数据库以检索响应该请求所必需的交易数据的类型(步骤5120)。如果请求包括一个或多个过滤器(步骤5130)，那么系统在产生所请求的分析数据(5150)之前对所检索的交易数据进行过滤(步骤5140)。过滤器起缩小分析处理中所使用的交易数据总额的作用。例如，如果该请求是针对其概括了买方在项目上的每月开支财务报告的，那么买方可对该报告进行过滤以仅包括在具体卖方的项目上的每月开支或具体项目类型的项目上的每月开支。
图70-88显示了用于呈现包含有分析数据的报告视图的示范性网页的屏幕快照。图70是买方用户主报表菜单网页61的示范性叙述。应当清楚可以把类似的主报表菜单提供给卖方用户、管理员用户和承包商用户。主报表菜单被设计成能允许用户根据各种观点来对项目进行管理。因此，根据该主报表菜单，用户可选择报告类型350，从中用户可选择具体的报告视图360。例如，图70举例说明了三种报告类型350财务、项目和卖方/人力资本。每个这种报告类型内是大量的报告视图360。
财务报告类型350内的报告视图360的例子是发票细节报告视图、商品概述报告视图、未来消费模式/预算报告视图和已完成项目财务分析报告视图。项目报告类型350内的报告视图360的例子是项目执行报告视图、计划即将到来的阶段和交付活动报告视图以及项目管理计划模块报告视图。卖方/人力资本报告类型350内的报告视图360的例子是财务报告视图、操作报告视图和供应链报告视图。然而，应当清楚，本发明不局限于图70所示的特定报告类型350和报告视图360，并且仅仅为简单起见和示范性目的而在图70中包括了该报告类型350和报告视图360。不同报告类型350和报告视图360的数目仅由系统所维护的交易数据的类型和总额以及用户需要来限制。
图71-88显示了特定类型的报告视图360的例子。例如，图71是用于呈现发票细节报告视图360的网页61的示范性屏幕快照。报告视图360内所包括的是与具体发票(或凭证)有关的分析数据270。发票分析数据270可按照许多变量来进行分类，并利用许多不同的过滤器280来进行过滤以及在许多不同的报告视图360中进行概括。例如，根据发票细节报告视图，用于在发票细节报告视图中产生分析数据的交易数据可由项目类型来概括并且可显示在项目类型发票概述报告视图上以作为项目类型发票分析数据。对发票细节报告视图360而言可能的过滤器280和附加报告视图360不局限于图71中举例说明的那些，并且可被扩展成包括任何顾客特定字段(CSF)。
图72是用于呈现普通每月开支概述报告视图360的网页61的示范性屏幕快照，所述普通每月开支概述报告视图360包含了列出本月和以前月份的总项目开支的分析数据270。从该普通每月概述报告视图360中可链接出很多附加概述报告视图360。例如，形成分析数据270的交易数据可按照地理来概括，并且被显示为地理开支概述报告视图以帮助用户确定在不同地区中项目上的开支总额。
作为另一个例子，如图73所示，形成分析数据270的交易数据可按照项目类型来概括并且被显示在网页61上作为项目交付类型开支概述报告视图360，其包含列出有不同项目交付类型上的每月开支的分析数据270。例如，开支可按照定价交付、基于单位交付、时间和物资交付、时间和支出、仅时间、服务合同或其他项目交付类型来概括，此外，可产生与每个项目交付类型中的开支交易数据有关的统计分析数据270以帮助用户识别每月每个项目交付类型占总支出的百分比。然而，应当清楚很多其他分析/统计数据可产生并且利用相同的开支交易数据在很多其他报告视图中显示。
如在图73显示的网页的底部可见，提供一链接以查看与开支交易数据有关的外部(例如高级数据库)数据。因此，用户不需要注册到不同服务器以访问该高级交易数据。虽然，应当清楚在其他实施例中，可能需要独立的注册程序。如果用户点击到外部数据的该链接，那么向用户呈现图74所示类型的概述报告视图360。
图74是包含外部数据项目交付类型开支概述报告视图360中所呈现的行业分析数据270的示范性网页61的屏幕快照。图74中显示了两个不同的行业分析数据270的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61顶部，显示了自动推进的行业部门中用于识别每月每个项目交付类型占总支出的百分比统计分析数据270。在网页61的中部，显示了用于识别每月每个项目交付类型由超大财力的买方所占总支出的百分比的统计分析数据270。
如在图74所示网页61中可见，提供到不同报告视图的链接，所述报告视图把行业分析数据与用户的个人公司分析数据进行比较。如果用户点击到外部数据的该链接，那么向用户呈现图75所示类型的概述报告视图360。图75举例说明了包含有比较项目交付类型开支概述报告360中所呈现的行业分析数据270与个人买方分析数据270的比较的示范性网页61的屏幕快照。图75中显示了两个不同的比较分析数据270的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61的顶部，把用于识别在按月基础上每个项目交付类型上的个人买方开支的分析数据270与在按月基础上每个项目交付类型上的平均行业开支相比较。在网页61底部，把用于识别由买方每月每个项目交付类型占总支出的百分比与该行业每月每个项目交付类型占总支出的百分比相比较。
图76是包含有与项目成本概述报告视图360中所呈现的具体项目有关的分析数据270的示范性网页61的屏幕快照。该分析数据270包括项目状态、迄今为止的整体项目成本、请购单总额(即，授予该项目的总额)，花费在这个项目上与花费在当前由买方所处理的所有项目相比的百分比，项目利润及其他相关项目成本分析数据。在网页61的底部是到按照交易数据的不同类型来概括的不同项目成本报告视图360的链接，所述交易数据的不同类型诸如商业影响类型、地理、卖方等等。
图77是包含有与项目花费估计报告视图360中所存在的一个或多个项目的估计未来花费有关的分析数据270的示范性网页61的屏幕快照。图77中显示了两个不同的未来花费分析数据270的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61的顶部，显示了与具体项目的估计未来花费有关的分析数据270，同时在网页中间显示了所有项目上的估计未来花费。在网页61的底部是到按照交易数据的不同类型来概括的不同项目花费估计报告视图360的链接，所述交易数据的不同类型诸如商业影响类型、地理、卖方等等。
举例来说，如果用户点击该链接以按照项目部门和族来概括该估计未来项目花费，则在示范性网页61上把类似于图78所示之一的报告视图360呈现给用户。图78所示报告视图360是按照项目部门/族报告视图360来综合的估计未来花费模式，所述项目部门/族报告视图360包含与不同项目部门/族中在项目上的估计未来花费有关的分析数据270。这类报告视图360对用户有用以保证根据商业计划来进行有组织的投资。
图78中显示了三个不同的估计未来项目部门/族花费的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61的顶部，分析数据270包含按照项目部门/族来综合的按月的估计未来花费。在网页的中部，分析数据270包含与具体项目族的估计未来花费有关的统计数据，诸如按月具体项目族所占的总开支的估计百分比。在网页的底部，分析数据270包含与具体项目部门的估计未来花费有关的统计数据，诸如按月具体项目部门所占的总开支的估计百分比。如在网页61的底部更进一步可见，提供了到外部数据的链接以查看包含有项目未来花费的外部分析数据的报告。这种外部数据有助于提供对下述问题的理解，即关于共同市场或特定市场成员如何进行投资或计划满足他们的经营目标。
图79是包含有与项目执行概述报告视图360中所呈现的具体项目的项目执行数据有关的分析数据270的示范性网页61的屏幕快照。分析数据270包括项目状态、项目阶段完成计数、逾期阶段计数、交付完成计数、逾期交付完成计数、按时交付完成百分比、及其他项目执行分析数据。在网页61的底部是到按照交易数据的不同类型来概括的不同项目执行报告视图360的链接，所述交易数据的不同类型诸如商业影响类型、地理、卖方等等。因而，根据这个网页61，可以产生由交易数据所概括的综合及其他统计分析数据。
举例来说，如果用户点击该链接以按照项目管理所有权类型来概括该项目执行分析数据，则在示范性网页61上把类似于图80所示之一的报告视图360呈现给用户。图80所示报告视图360是按照不同所有权类型来管理的项目的操作执行概述，所述不同所有权类型诸如买方自己的、卖方自己的、共同所有权等等，其包含有与执行具有不同所有权的项目有关的分析数据270。这类报告视图360有助于用户理解与项目管理所有权有关的成功/故障率之间的关系。如在网页61的底部更进一步可见，当它涉及项目管理所有权时，提供了到外部数据的链接以查看包含有项目执行的外部分析数据的报告。
举例来说，如果用户在图79中点击网页61的底部上的链接以查看风险/故障报告，则在示范性网页61上把类似于图81所示视图的报告视图360呈现给用户。图81所示的报告视图360是项目风险/故障执行异常报告，其包含与执行具有过期或其他困难的有风险或不适应项目有关的分析数据270。
图82是包含有与计划矩阵报告视图360中所呈现的项目计划有关的分析数据270的示范性网页61的屏幕快照。分析数据270可包括例如本月和未来月份的总项目计数、及其他项目计划分析数据270。图83是包含有与项目计划工具报告视图360中所呈现的更特定的项目计划有关的分析数据的示范性网页61的屏幕快照。例如，用户可从具体项目部门/族并且从诸如地理、卖方等级等等之类的各个影响变量(例如，过滤器280)和各个项目执行报告视图360中选择，以呈现包含有综合概述分析数据270的报告视图360，所述综合概述分析数据270与所列影响变量的每种组合有关，所述影响变量与特定历史项目执行数据有关。这类报告视图360有助于用户提供对哪个商业配置(变量综合)已经成功了以及哪个没有成功进行有意义的理解。
图84是包含有与花费趋势有关的分析数据270的示范性网页61的屏幕快照，所述花费趋势与卖方等级代码花费报告视图360中呈现的卖方等级的有关。图84中显示了两个卖方等级花费数据的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61的顶部，分析数据270包括在逐月基础上特定卖方等级内的一个或多个卖方上的花费总额。在网页61的底部，分析数据270包括卖方等级中的卖方数目、在逐月基础上该卖方等级中卖方的花费总数及其他综合或统计卖方等级花费分析数据270。
图85是包含有与卖方资格报告视图360中所呈现的卖方资格信息有关的分析数据270的示范性网页61的屏幕快照。该分析数据可包括，例如一列买方定义的卖方标准信息、每个卖方的相关卖方资格信息以及卖方是否满足每个买方定义的卖方限定符的表示。在网页61的底部，存在到不同概述报告视图360的进一步链接以在各个卖方资格数据上综合和/或执行统计分析。
图86是包含与人力资源的利用有关的分析数据270的示范性网页61的屏幕快照，所述人力资源利用与地区资源利用报告视图360中呈现的地理有关。分析数据270包括统计信息，诸如特定国家、地区或城市所采用资源的百分比，特定国家、地区或城市中工作时间的百分比以及特定国家、地区或城市中人力资源上所花费的钱的百分比。分析数据270更进一步包括各种综合信息，诸如总资源计数、以及特定国家、地区或城市中所花费的时间和金钱。这类人力资源报告视图360在处理诸如能力管理、价格、共同雇用、重新利用等等之类的问题时对用户有用。
图87是包含有与卖方采用的人力资本资源报告视图360中所呈现的人力资源有关的分析数据270的示范性网页61的屏幕快照。图84中显示了三个不同的人力资源数据的例子，虽然每次仅显示其中之一，这取决于由用户输入的请求和过滤。在网页61的顶部，分析数据270包括与项目执行有关的个人承包商信息。在网页61的中部，分析数据270包括与具体卖方有关的综合和统计承包商信息。在网页61的底部，分析数据270包括与多个卖方有关的综合和统计承包商信息。在网页61的底部，存在到不同概述报告视图360的进一步链接以在各种承包商数据上综合和/或执行统计分析。
图88是包含有与卖方记分卡报告视图360中所呈现的卖方执行有关的分析数据270的示范性网页61的屏幕快照。这个报告视图360包括几个过滤器280，其可被用于把视图360集中在特定类型的交易数据上。应该理解，虽然在上述讨论到的每个报告视图360中没有显示，但是各种过滤都将对一部分或所有报告视图360有效。分析数据270可包括与各个卖方的投标、项目执行以及花费活动有关的综合及统计信息。在网页61的底部，存在到不同概述报告视图360的进一步链接以在各个卖方执行数据上综合和/或执行统计分析。以上描述的报告视图360和此处所呈现的分析数据270的类型意味着仅提供该报告模块的鲁棒性的一个例子。本领域技术人员应当很容易了解利用本发明报告视图的可能的数目和项目变更。在下面的各个图中，已经省略了从处理流程判定模块中扩展出来的反向分支，以免把对本发明的各个特征和实施例的描述不必要地复杂化。本领域技术人员应当理解，根据本发明的原理，该反向分支是被提供为由设计约束条件而不是部门来指定的。
图89举例说明了在系统30上实现的示范性视觉项目工作环境动态8900。动态8900的最内层1显示了与项目有关的且例如由货物交付、服务单位交付、定价交付、人力资源分配(包括劳动力和成本)、其他项目支出、以及项目阶段所表示的项目工作交易数据的基本有形的实际活动单元。单元8905-8930表示实际上获得完成的项目工作。由单元8905-8930表示的活动未必是表示单个乃至综合可开票活动，但是所述活动经常会进行。
单元8905-8930简化了有形项目工作活动的粒状明度和行政管理。交易数据采取如图40A和41中所举例说明的特定数据对象的形式。特定数据对象是复杂的数据储存器，其装有例如多个变量数据类型、代码、数据库查询、以及分层次的相关数据集合。相反，简单的数据对象例如是单个文本字段、成本字段或日期字段对象。这些特定数据对象基本上用于获得、存储和处理交易数据。
层1内还显示了表示为单元8935(a)-(d)的项目工作报表(SOW)组件。在典型实施例中，交付和SOW指的是客观项目输出的有形描述，并且它们是同义的。然而，在一些实施例中，这不是例如当分包商没有生成采购定单交付时的情况。本领域技术人员应当理解这里不必刚好是四个项目SOW组件，而是该数目可由项目重要事件配置设计约束条件来确定。SOW组件8935(a)-(d)表示客观项目输出(例如，项目重要事件或SOW/交付)的有形描述。项目输出可表示为SOW输出并且不会典型地规定关于例如劳动力资源或后勤的细节。因而，一个SOW可映射到一个或多个有形的项目工作单元。项目工作活动典型地是SOW的子组件，其中该子组件的数目在少至一或多至极大值的范围内。层1的组件8940举例说明了传统的项目管理(PM)SOW依存性。SOW输出是以相互关系来组织的。子组件(即，项目工作活动)被集成以便建立有结合性的工作环境。
层2举例说明了动态8900的交易贸易方面，其表示为组件8945-8960，还称为从发起到支付周期。RFx投标模板/内容系统8945用作层1的支持结构。如上所述，内容送到模板，模板用来创建RFx投标，以及把RFx投标广播/邮递给供应商。供应商然后处理该RFx投标响应。买方分析RFx投标响应并发布与特定RFx投标响应单元有关的授予。这些RFx投标响应单元被有组织地集成到购买请购单/定单环境中。当工作完成之时，供应商访问这些特定采购定单(PO)记录以创建项目活动确认凭证，这时买方对该工作进行审阅和品质评估，最终导致买方批准。最后，已批准凭证数据被提取并用于产生开发票数据，其导致付款给供应商。
特定交易数据对象(例如，表26中的RFx投标数据对象)还可以用于投标处理以外。例如，在有些情况下，买方可能没有时间或不希望开始竞标处理。在此情况下，买方例如可以在处理500的购买请购单支路560处开始。
层3举例说明了受项目工作交易贸易方面直接影响的其余的动态8900。虽然所举例说明的行政管理投资组包括预算/现金流量8965、合约量8970、资产量8975、以及内部商业事件量8980，还可很容易有许多其他的，例如制造或内部人力资源功能单元。层3的投资可能会取决于例如企业实体存在于什么行业或者它的商业在哪里进行管理而极大地改变。为了示范性的目的，选择了那些投资，其典型地会影响执行项目工作的任何买方实体。
时常会有许多受项目影响但是实际上不属于项目范围内的商业事件。例如，特定项目可能需要在具体的营业场所中安装计算装置和软件。受这种活动的直接影响，尽管本来没有的一部分项目工作，也可能是企业实体的指南部门。因而，叫做指南人员培训的独特的商业事件是相关的商业事件。层3表示企业实体内项目工作的幕后方面。
视觉动态的下一个且最外面的环境是层4，其包括组件8985-8999。用户8985、通信8990、合作8995以及决策支持8999表示动态8900的人或软件方面。
项目工作常常是复杂的努力。项目工作活动必须与贸易环境相结合(即，从发起到支付数据处理系统)，如图8所举例说明的那样，这个环境随后常常直接影响较高级别的商业管理努力，例如预算、资金流动、合同管理、资产/资本管理、以及许多其他相关商业活动/事件。围绕着所有这些变量的是对在保障和管理合作环境中连接用户和同时通信的需要，以便能够以有组织的方式来处理数据、生成期望输出以及提供合理的决策支持以更进一步为整个商业努力加油。因此，在典型的实施方式中，动态8900可能是极其复杂的。
图89显示了所举例说明的动态单元之间存在的复杂网络。例如，如果货物交付将失败，则特定的SOW可能会被延迟或被取消。这些失败可能会导致需要修改采购定单，其可能会变更预算和资金流动位置。有这样一种可能性，即会改变固定资产储存库，这或许会影响服务和或维修合同，这将导致需要修改装置的物理构型并且最终导致需要再访问所影响的其他相关项目大约十二次。
图90是举例说明用于实现动态8900的商业数据处理环境的高级视图的方框图。数据处理环境9000包括四个高级组件，其被分成核心信息数据组件9001、工作流程实体组件9025、数据处理组件9050以及数据库组件150。数据库组件150是用于存储及检索所处理数据的地方。核心信息数据组件9001具有物理上存在于数据库组件150中的结构和属性；然而将它们单独地显示，以便指出在管理数据和交易数据之间的差异。
根据高级观点，商业数据处理环境9000可被解释为包括用户、信息、处理储存器/表单、工作流程路径以及数据存储组件。核心信息数据组件9001表示这样的信息，其不仅定义了企业(例如，行业、提供的产品或服务等等)的基础结构而且定义了诸如在贸易管理解决方案(即，企业如何与项目工作环境中的解决方案相互作用)的范畴内的企业努力的范围，如图5所示。因而这个信息被认为是与交易数据相反的管理数据(即，该数据不被限于具体项目，而是描述独立于具体项目的企业及其处理)。核心信息数据组件9001还定义了环境9000的范围。
核心信息数据组件9001包括下列八个示范性系统 1)用户角色系统9003，这是一个应用模块，利用它来存储和管理人员/用户身份属性。这个模块的配置方面把用户与环境9000的交互性从基本注册许可简化成工作流程数据处理活动。
2)地理设备系统9005，这是一个用于定义地理范围和买方实体构造以及实际工厂设备如何与那个构造有关的应用模块。配置例如把地理范围定义为国内或国际，或者买方实体是否利用自定义区域分段模式、利用邮件/邮政编码以进行业务处理。除了基本地理构造之外，实际工厂地址可集成于该地理设备系统9005中，其属性适用于所定义的该实际工厂。地理设备系统9005中还可以保存例如关于设备活动、安全规则、行业约束条件、交付访问的属性信息。
3)质量保证系统9007，利用该应用模块可以把业务处理和职能定义为对买方实体很关键。另外，还可以定义适用于该业务处理和职能的相应测量属性。
4)人力资本系统9009，它是用于定义买方实体视图和管理关于非雇员工人的数据的应用模块。在这个模块内，买方实体可为下列一个或多个来定义和配置属性工人类型、工人限定符、工人协议、工人任期、工人就职必要条件、工人离职必要条件、工人劳动力类型、工人开支类型、工人位置规范、工人审计规范以及工人弃权。
5)财务管理系统9011，利用这个财务应用模块，买方实体可对花费管理和财务数据处理努力的各个方面进行管理。典型的信息组件可包括但是不一定限于金钱花费类型的标识和属定义、金钱货币类型的标识和属性定义、付款条件的标识和属性定义、折扣条件的标识和属性定义、回扣条件的标识和属性定义、获利计算的标识和属性定义、税款种类的标识和属性定义、纳税异议的标识和属性定义、以及财务交易批准模式的标识和属性定义。
6)采购管理系统9013，利用这个采购应用模块，买方实体可对采购交易数据处理努力的各个方面进行管理。这个模块内驻留了下列一个或多个的信息和配置商品系统、RFx投标系统、购买请购单/定单系统和凭证(即，工作确认处理)系统，如例如图40C所示。
7)供应商管理系统9015，利用这个供应商应用模块，买方实体可对与他们的贸易环境有关供应商管理的各个方面进行管理。如果这样做所必需的商业信息有效，则可在供应商管理系统9015的配置单元内实现供应商管理的各个交易方面(从特定债务保护到战略供应商花费管理)。典型的配置单元包括但是不一定限于供应商类型的标识和属性定义、供应商商业限定符的标识和属性定义、供应商保险限定符的标识和属性定义、供应商等级的标识和属性定义、供应商协议的标识和属性定义、供应商业务审计的标识和属性定义、供应商业务资格弃权的标识和属性定义、以及与买方利用的商品有关的供应商供应能力的确定的规范。
8)项目管理系统9017，利用这个应用模块，买方实体可对项目管理的各方面进行管理。
工作流程实体组件9025表示用于在环境9000内处理交易信息的信息储存器(例如，表单或网页)。工作流程实体实质上是用于显示或获得信息的可用数据环境(例如，核心信息数据组件9001)的表现。
数据处理组件9050表示环境9000的主要工作流程组件，而组件9001和9025实际上定义了被用于商业数据处理环境9000中的数据和数据处理表单。数据处理组件9050是把数据处理表单配置成沿着他们相应的数据处理路径来移动的地方。
通常就是这样，利用核心信息数据组件9001和工作流程实体组件9025，数据处理组件9050包括预先配置的工作流程路径9054的基本集合，其用于填写工作流程表单，所述工作流程表单例如在特定条件或状态代码的前提下沿着工作流程路径而传播到预定用户角色。可变地配置的工作流程处理9058表示自定义买方实体计划的工作流程处理。该配置工作流程处理9058尤其采用用户角色系统9003的买方用户角色位置、买方工作流程实体组件9025、和买方业务规范(例如，数据值和条件属性)来配置精确的工作流程数据处理以满足业务需要。
数据库组件150表示环境9000的数据库存储方面，其中存储和维护了数据处理组件9050的操作期间所获得的交易数据。在环境9000流程的末端显示了数据库组件150以便强调交易数据获取和存储。然而，数据库组件150遍及所有四个组件9001、9025、9050以及150始终是可操作的。
图91是上述图5的修改方案，并且提供了根据本发明原理的计划/范围处理中的项目变更的高级可见概要。如上述图5中所示的，处理500可被分成投标前活动505、投标活动515、以及投标后活动560。在图5中投标前活动505包括步骤510，而投标活动515包括步骤520-555，以及投标后活动560包括步骤565-580。相反，处理9100被分成投标前活动505、采购活动9125、以及采购后活动9150。在图91中，投标前活动505出现在步骤520之前，采购活动9125出现在步骤560之前，以及采购后活动9150出现在步骤560-580期间。
投标前活动505包括用户角色和工作流程配置9110、RFx投标系统配置9115、以及项目管理配置9120。采购活动9125包括交易项目工作数据设置9127，其包括对项目活动映射的SOW 9130、SOW依存性配置9135以及对项目管理配置的SOW 9140。采购后活动9150包括凭证处理9155、PCIP/S建模9160、PCIP/S协作9165以及PCIP/S记录修改9170。凭证处理9155出现在步骤560-570期间。PCIP/S建模9160、PCIP/S协作9165、以及PCIP/S记录修改9170出现在步骤575或之前。
图92是图91的改进方案，其中没有采用竞标处理。本领域技术人员应当理解本发明的各个实施例不被限于其包括如图92所示的竞标的环境中。图92包括改进以删除图91所示采购/投标活动。在图92中举例说明的处理9200中，项目前活动9210包括用户角色和工作流程配置9110以及项目管理配置9120。项目设置活动9215包括交易项目工作数据设置9227。交易项目工作数据设置9227包括对项目活动映射的SOW 9130、SOW依存性配置9135以及对项目管理配置的SOW 9140。项目跟踪活动9220包括凭证处理9155、PCIP/S建模9160、PCIP/S协作9165以及PCIP/S记录修改9170。在类似于图5和91的方式中，项目前活动9210出现在步骤9205，而项目设置活动9215出现在步骤550，以及项目跟踪活动9220出现在步骤560-565期间。
利用特定数据对象作为投标内容不限于图91所描述的顺序，所述投标内容移植于购买请购单/定单数据中然后移植到交易凭证数据。根本不会有以完全排除采购定单处理的方式来禁止使用特定数据对象的技术约束条件。在这种情况下，相同类型的记录仅仅会用于项目活动数据。然后这种数据可被用于与本发明的各个实施例相结合，就好象已经把它作为系统内的采购活动的结果而获得了一样。此外，例如在图9中那样，以同样的方式来指定用户角色职位和为用户角色职位分配人员不限于投标处理，而可是代之以应用其他的工作流程处理，诸如鉴定和上载潜在卖方或获得承包商协约数据。
图93举例说明了根据本发明原理在计划/范围(PCIP/S)处理流程中的项目变更。在图93中，处理流程9300从采购前数据配置环节开始，所述采购前数据配置环节包括用户角色配置9305、项目管理模块配置9310、以及RFx投标系统配置9315。在采购前数据配置活动9305-9315之后，处理9300的下一个主要环节包括显示为步骤9320-9335的交易项目工作数据的获取和存储。
在步骤9320，买方实体创建并广播RFx投标。在步骤9325，供应商对RFx投标进行响应。在步骤9330，买方评估该RFx投标响应并选择优胜者。在步骤9335，买方创建购买请购单/定单。第三个主要处理环节，即SOW记录配置(步骤9340-9350)，是其中传统项目SOW依存性配置出现以及在项目管理模块配置9310和具有交易项目工作数据的获取和存储的交易数据设置环节中建立的数据结构的结合。
第四个主要处理环节，称为PCIP/S影响模式组件，由步骤9353-9360表示。步骤9353-9360发生在项目工作开始9353时并且包括工作确认凭证的提交。通过重要事件变量配置和凭证重要事件数据管理，各个实施例可为买方实体识别其缺乏重要事件一致性并且因此变为(或者不久会变为)风险活动的那些特定的项目工作活动或SOW记录。
系统的凭证方面简化了风险识别9356。这个第四个处理环节内的最后一个活动是PCIP/S依存性影响报告9360，其利用先前配置的信息以向买方实体显示用于详述潜在地由该风险活动所影响的相关业务记录集合的报告。这个视图给出了关于基于一个风险活动的什么处于危险的买方实体信息。在步骤9360期间，控制买方实体用户可改变关键重要事件可变数据值并且使系统基于该信息变更而产生影响输出报告。
第五处理环节，风险通信会话是由步骤9363-9370表示的。控制买方实体用户可确定该风险活动是否具有足够广泛或重大的影响，以保证警告其他企业用户那些问题存在会导致对一个或多个项目计划或范围的改变。例如，用户可能开始风险管理通信会话9363。一旦创建了会话9363，参考特定风险项目工作单元，控制买方实体用户就能在步骤9365选择要与哪个潜在地波及的企业用户进行通信，并且配置或控制给该用户的个人通信包以适应特定信息需要。一旦配置了个人通信包，买方实体用户就能因此在步骤9368把该通信包广播给其控制着相关业务记录所有者的个人。
在与供应商投标响应220类似的方式中，接收风险通信包的买方实体用户可在步骤9370借助于所提供的用户界面来处理他们的响应。该用户可提供关于对他们的可控制业务记录/事件的预期影响的反馈。当完成了所有接受者的风险通信包时，这个处理环节结束。
利用手中的所有已完成风险通信包，发布买方实体用户现在可进行第六个主要处理环节，即PCIP/S接受包会话，其是由步骤9373-9385表示的。在这个处理内，控制买方实体用户对前一通信会话(即，步骤9363-9370)期间所收集的信息进行综合和评估。该控制用户最终做出关于该风险项目工作活动变量的结局的最后意向，并且保存记录变更。依据这些改变，以该新可变数据为前提，用户能因此在步骤9373产生新依存性影响报告，这提供了相关业务记录和对该记录的可变数据变更的完整视图。
在计算了该新影响模型之后，买方实体用户可在步骤9375继续依照要求把PCIP/S接受包广播给供应商用户。参考存在和开始风险管理通信会话(即，步骤9363-9370)来创建PCIP/S接受包会话，借此已经确定了其参考受影响的系统采购订单的广播目标供应商。步骤9272-9385的处理类似于前一通信处理(即，步骤9363-9370)，借此如果期望这样则做出关于每个个人接受力的个人配置和注释。在数据库级上典型地对步骤9375的广播进行跟踪。
类似于步骤9363-9370的会话，接收PCIP/S接受包的个人用户可在步骤9380和9385对该包进行处理并把它返回给发布用户。响应是典型地被约束于接受改进的可变数据或实际上定义可变数据单元。系统需要按照关于源风险项目工作活动记录而做出的意向来进行考虑的信息值被获得并存储。随着在单个平台(例如，系统30)接受所识别的问题源以及协作，由控制权益当事人进行可变信息修改，同时在企业的充分透明度中对该活动进行跟踪。
当收到该已完成的PCIP/S接受包时，第七个主要处理环节是PCIP/S记录修改管理环节(即，9390-9395)。控制用户例如通过用户界面来激活所提供的控制，并且对要更新的可变数据修改给予批准。当完成步骤9395时，所波及的买方实体用户被有组织地通知已经在系统内做出了期望修改的表示。
采购前数据配置 在获得实际项目工作交易数据之前典型地发生了各种高级配置和数据管理活动。这些采购前配置和数据管理活动提供了未来项目工作交易数据与其相连接的实际信息线程。虽然许多其他的也可能有，但是这些信息线程典型地包括项目组/主、预算组/主、资产组/主、合约主、以及商业事件/主。图94A-101举例说明了图93的步骤9310的更详细描述，在这些步骤期间，买方实体对该管理项目核心信息数据组件9001进行配置。
图94A-B基本上涉及项目组和项目主记录的创建和存储处理流程。项目组是一个或多个项目的集合，其根据诸如技术领域、商业单位、或行业之类的一些预定标准而被集合在一起。项目主记录是与具体项目有关的记录。项目主与项目组记录典型地可在项目管理系统9017内被得到。处理流程引起信息获取和存储在数据库表中，诸如表113-114A。图94A-B中所举例说明的项目组和项目主模式表示整个信息和项目投资管理的基本支持结构。通过把项目或项目组的默认所有权例如指定给任何适当的商业单位、成本中心或人员可以简化项目投资管理。在项目主记录之间可建立项目关系层次，以及可以指定预期的项目管理所有权。可指定项目影响代码以把项目的关系反映到所识别的商业努力(参见，例如表103)。虽然图94A-B中描述了双层的项目结构，但是在不脱离本发明原理的情况下可创建超过两层的分层结构。
现在参考图94A，项目组创建处理流程9400开始于步骤9403。在步骤9403，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9405，用户导航以创建新项目组。在步骤9408，系统向用户提供输入工作流程表单。在步骤9410，用户对项目组进行命名。在步骤9413，用户提供项目组描述。在步骤9417，用户指定授权的项目组所有者/买方人员。在步骤9420，用户选择性地指定默认商业单位。在步骤9423，用户选择性地指定默认成本中心。在步骤9426，用户保存先前做出的输入。在步骤9430，用户设置被存储在数据库中。
现在参考图94B，项目主创建处理流程9450开始于步骤9453。在步骤9453，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9455，用户导航以创建新项目主。在步骤9458，系统向用户提供输入工作流程表单。在步骤9460，用户对项目主进行命名。在步骤9462，用户提供项目主内部代码。在步骤9465，用户提供项目概述描述。在步骤9468，用户选择性地指定默认项目主(PM)所有权代码，其定义了例如如表103中的项目的负责项目管理当事人。在步骤9470，用户指定项目影响代码(参见，例如，表103)。在步骤9473，用户指定项目组从属关系(即，该项目是哪个项目组的成员)。在步骤9475，用户指定项目组内的项目等级从属关系。在步骤9477，用户保存先前做出的输入。在步骤9480，用户设置被存储在数据库中。
图95A-B遵循如上在图94A-B中所述的类似模式以设置项目组/主；然而，图95A-B所示的特定处理流程处理预算组/主记录创建和存储。图95A-B中所描述的数据存储发生在数据库表中，例如表118和119。预算数据是在核心信息数据组件9001的财务管理系统9011内的管理数据。虽然图95A-B中描述了双层的预算结构，但是在不脱离本发明原理的情况下可创建超过两层的分层结构。
在与项目组类似方式中，预算组是一个或多个预算的集合。如本领域技术人员应当理解的那样，预算典型地是例如以分层次的方式根据商业机构来分类的，所述商业机构诸如部门、商业单位和成本中心。然而，相对于预算(包括预算组和预算主的结构)的本发明的原理可用于根据企业需要以很多不同的方式来建立企业的预算功能。预算主和预算组记录典型地可在财务管理系统9011内被得到。
现在参考图95A，预算组创建处理流程9500开始于步骤9502。在步骤9502，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9506，用户导航以创建新预算组。在步骤9510，系统向用户提供输入工作流程表单。在步骤9514，用户对预算组进行命名。在步骤9518，用户提供预算组描述。在步骤9522，用户指定授权的预算组所有者/买方人员。在步骤9526，用户选择性地指定默认商业单位。在步骤9530，用户选择性地指定默认成本中心。在步骤9534，用户指定预算组美元总额。在步骤9538，用户指定预算。在步骤9542，用户保存先前做出的用户输入。在步骤9546，该设置被存储在数据库中。
现在参考图95B，预算主创建处理流程9550开始于步骤9552。在步骤9552，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9556，用户导航以创建新预算主。在步骤9560，系统向用户提供输入工作流程表单。在步骤9564，用户对预算主进行命名。在步骤9568，用户提供预算主概述描述。在步骤9572，用户选择预算组加入(即，该预算属于哪个预算组)。在步骤9576，用户选择性地指定默认商业单位。在步骤9580，用户指定预算。在步骤9584，用户指定预算美元总额。在步骤9588，用户指定授权的预算主所有者/买方人员。在步骤9592，用户保存先前做出的输入。在步骤9596，用户设置被存储在数据库中。
图96A-B遵循如上所述的类似模式以设置如上在图94A-B和95A-B中所述的项目组/主和预算主/组；然而，图96A-B的处理流程适合于资产组/主记录创建和存储。图96A-B举例说明了如通常相对于步骤9310而描述的资产主/组记录的创建。图96A-B中所描述的数据存储发生数据库表中，例如表125-126。图96A-B中所描述的处理流程中所创建的资产数据是管理核心信息数据组件9001的财务管理系统9011内的数据。图96A-B中所描述的资产组/主记录的创建可用来简化各种计费功能，诸如企业内各种商业机构的资产折旧。虽然图96A-B中描述了双层的资产结构，但是在不脱离本发明原理的情况下可创建超过两层的分层结构。
现在参考图96A，资产组创建处理流程9600开始于步骤9602。在步骤9602，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9606，用户导航以创建新资产组。在步骤9610，系统向用户提供输入工作流程表单。在步骤9614，用户对资产组进行命名。在步骤9618，用户提供资产组描述。在步骤9622，用户指定授权的项目组所有者/买方人员。在步骤9626，用户选择性地指定默认商业单位。在步骤9630，用户选择性地指定默认成本中心。在步骤9634，用户保存先前做出的输入。在步骤9638，该设置被存储在数据库中。
现在参考图96B，资产主创建处理流程9650开始于步骤9652。在步骤9652，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9656，用户导航以创建新资产主。在步骤9660，系统向用户提供输入工作流程表单。在步骤9664，用户对资产主进行命名。在步骤9668，用户提供资产组描述。在步骤9672，用户选择资产组加入。在步骤9676，用户指定资产主所有者/买方人员。在步骤9680，用户选择性地指定默认商业单位。在步骤9684，用户选择性地指定默认成本中心。在步骤9688，用户选择性地指定资产美元。在步骤9692，用户选择性地指定资产获得日期。在步骤9696，用户保存先前做出的输入。在步骤9699，该设置被存储在数据库中。
到目前为止相对于图94A-96B而讨论的示范性处理意味着这些一定是连续的过程。然而，本领域技术人员应当承认事实上它们是不必以所描述顺序而执行的独立的应用处理。
图97是用于创建和存储合约主记录以便记录特定合约信息单元以便把合约信息集成到项目并最终集成到项目工作交易数据的处理流程。图97中所描述的处理流程可用于指定企业所利用的合约的各种属性以便确保在企业接受项目工作或代表企业的项目工作期间满足那些属性。合约主记录被存储在数据库表中，诸如表123。本领域技术人员应当理解合约信息典型地以存储在电子文本文档、纸上或者既在电子文本文档上又在纸上的可编程排序程序格式被包含。在此情况下，由于该可编程排序程序文档不表示传统应用处理单元，因此，典型地不存在适用于该合约信息的数据处理能力或配合活动性。虽然图97中没有具体地举例说明，但是本领域技术人员应当理解合约记录可以按与如上所述相对于项目、资产以及预算相类似的方式被分层。合约记录典型地在供应商管理系统9015内被发现。
再次参考图97，合约记录创建处理流程9700开始于步骤9703。在步骤9703，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9706，用户导航以创建新合约主。在步骤9709，系统向用户提供输入工作流程表单。在步骤9712，用户指定合约类型。在步骤9715，用户提供合约参考。在步骤9718，用户指定合约开始和结束日期。在步骤9721，用户选择性地指定最大合约花费总额。在步骤9724，用户选择性地指定默认商业单位。在步骤9727，用户选择性地指定默认成本中心。在步骤9730，用户指定合约活动的范围。在步骤9733，用户选择性地指定所约定的禁止。在步骤9736，用户指定供应商。在步骤9739，用户选择性地指定顾客。在步骤9742，用户指定合约所有者。在步骤9745，用户保存先前做出的输入。在步骤9748，该设置被存储在数据库中。
图98表示关于商业事件主记录的创建和存储的处理流程。商业事件是可能与买方实体所接受的一个或多个项目有关的原因或者效果关系的买方活动，即使不直接与项目工作有关。商业事件的例子是其包括创建新产品的项目。抛售产品的广告和营销运动可被认为是商业事件，因为广告和营销运动可论证地与创建该产品的项目无关；然而，商业事件取决于已经完成的创建产品的项目。例如，如果该产品被确定成由于项目内的一些失败的原因而永远不会被创建，那么在该依存商业事件在花费不必要的钱(即与此相关的广告和营销运动)就是不明智的。商业事件主记录被存储在数据库表中，诸如表121。倘若是较小的严重故障，那么该商业事件可能被推迟或按照项目风险通知而进行间接的物资修改。即使没有象与在项目、预算以及资产的以上讨论中具有分层结构那样明确地举例说明，本领域技术人员仍应当理解在不脱离本发明原理下可以按分层方式来构造商业事件。
再次参考图98，商业事件记录创建处理流程9800开始于步骤9803。在步骤9803，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9806，用户导航以创建新商业事件。在步骤9810，系统向用户提供输入工作流程表单。在步骤9813，用户对商业事件主进行命名。在步骤9816，用户提供商业事件描述。在步骤9820，用户指定商业事件所有者。在步骤9823，用户选择性地指定默认商业单位。在步骤9826，用户选择性地指定默认成本中心。在步骤9830，用户选择性地指定所计划的开始和结束日期。在步骤9833，用户选择性的指定所计划的地点。在步骤9836，用户选择性地指定商业事件的顾客加入。在步骤9840，用户指定商业事件影响代码。在步骤9843，用户保存先前做出的输入。在步骤9846，该设置被存储在数据库中。
一旦把诸如预算、资产、合约及商业事件记录之类的核心信息数据单元加入到项目主或项目组，那么它们就变为主数据。否则，如果在项目工作或一般采购交易数据的环境中未使用，那么它们仅仅是未使用的核心信息数据。一旦构造了项目与核心数据的加入，就把结果设置存储在项目管理系统9017中。
图99举例说明了项目主与核心数据加入的处理流程。处理流程9900描述了项目主记录到其他主记录(例如，预算、资产、商业事件、或合约主记录)的映射。处理流程9900的映射典型地被存储在数据库表中，诸如表117、120、122、124和127。处理流程9900从买方实体项目主记录所有者发起；然而，本领域技术人员应当承认这是一种示范性模式。处理流程9900也可从加入于其的另一个主数据信息组件中发起并在相反方向上进行流动。
如处理流程9900表示的那样，个人信息输入可能会依赖于所进行的加入而发生变化。这些加入表示一旦该项目是投标就可能会变更的默认初始映射。当引入项目工作交易数据时，项目管理系统9017的项目主记录到其他核心信息数据记录的映射典型地变得更加确定。尽管没有明确地显示在处理流程9900内，但是本领域技术人员应当承认现有项目主记录加入的编辑可以在引入该项目记录交易数据之后来执行。
再次参考图99，处理流程9900开始于步骤9903。在步骤9903，授权的买方用户从例如主页导航条中激活项目管理控制。在步骤9906，买方用户导航到管理该项目主。在步骤9910，系统显示对买方用户有效的项目主记录。在步骤9913，买方用户选择期望的项目主记录。在步骤9916，系统向用户显示所配置的项目主相关数据单元。在步骤9920，系统向用户提供标为“视图关系”的控制等等。在步骤9923，用户激活该“视图关系”控制。在步骤9926，系统显示项目主记录关系输出视图。项目主记录关系输出视图典型地被划分成项目、预算、资产、合约以及商业事件。
从步骤9926，执行进行到步骤9930。在步骤9930，提示用户关于用户是否想要对设置进行编辑。以肯定方式响应于步骤9930的响应，则执行进行到步骤9933。在步骤9933，系统提示用户选择核心信息数据类别。在步骤9936，用户选择核心信息数据类别(例如，预算、合约、商业事件或资产)。在步骤9940，系统提示用户选择“编辑现有记录”或“创建新关系”。在步骤9943，如果用户选择“创建新关系”，则在步骤9946系统为用户提供有效的核心信息数据类型主记录的显示。
在步骤9950，用户可选择期望的主记录。在步骤9953，系统提示用户完成加入和所配置的数据输入需求。在步骤9956，用户完成所需输入。在步骤9960，当完成所选择的记录加入时用户保存该设置。在步骤9963，关系加入被存储在数据库中并且用“特定”状态进行标记。
在步骤9966，系统把记录加入广播给受该从属关系影响的所配置的商业记录所有者。在步骤9970，系统提示所波及的商业记录所有者以同意或拒绝该记录加入。在步骤9973，所波及的商业记录所有者被允许同意拒绝所述加入。响应于加入的批准，执行进行到步骤9976，在这个步骤把加入存储在数据库中，其状态为“当前”。然而，如果在步骤9973，记录加入的意向被拒绝，则执行进行到步骤9980，在这个步骤所述加入被存储在数据库中，其状态为“拒绝”。从步骤9976或步骤9980中的任何一个，执行进行到步骤9983。在步骤9983，系统向该意向请求者(即，买方用户)通知记录所有者意向。
因而，当处理流程9900完结时，项目主记录被加入到其他核心信息数据记录，诸如预算主记录、资产主记录、合约主记录、以及商业事件主记录。在本发明的各个实施例中，买方用户设法使项目主记录加入于其中的另一个记录所有者具有同意或拒绝由项目主记录的买方用户所请求的加入的权力。
图100表示了买方用户的示范性项目管理主页用户界面； 图101表示支持此处讨论的活动的示范性允许数据库模式。本领域技术人员应当承认在基于网络工作(例如互联网)的系统上本发明的各个实施例的实施方式典型地利用代码和/或数据库信息处理基础。此处包括的数据库模式以及相应的数据库表用作如何进行这种基于网络的实施方式的例子。
交易项目工作数据的获得以及存储 图102-103更详细地举例说明了通常在图93的步骤9320-9335所举例说明的交易项目工作数据的获得和存储。图102中举例说明的处理流程用来把两个不同的数据集合彼此合并。换句话说，使项目主记录加入到RFx投标。按照这个加入，RFx投标处理类似于在采取图89之前所讨论的那些。
图102通过采购定单激活处理流程10200而举例说明了RFx投标的概述视图。处理流程10200的步骤10215-10240描述了一种利用其把新买方投标请求映射到现有项目主记录的子处理。来自步骤10215-10240的结果关系设置被存储在诸如表128之类的数据库表中，并且用作到后续购买请购单的映射作为投标授予的结果，而在这样情况下关系设置被存储在诸如表129之类的数据库表中。
当用户没有授权查看项目主记录时，变量处理是可能的，诸如但不限于，有效的项目主记录不是关于投标请求活动的，或者项目所有者需要通知或批准对相关项目投标请求的许可。图102中举例说明的项目工作投标请求发源于商业需要或定义的项目。投标请求到项目主记录的映射简化了由于利用先前配置的主数据记录的成功的投标处理而产生的交易数据之间的随后合并。
再次参考图102，处理流程10200开始于步骤10205。在步骤10205，授权买方用户例如从买方主页导航条(参见，例如，图4A)中激活RFP/RFQ创建控制。从步骤10205，执行进行到步骤10210。在步骤10210，买方用户选择“创建新RFQ”。在步骤10215，系统提示买方用户使RFQ加入到有效的项目主记录。在步骤10220，买方用户选择“项目主加入”控制。在步骤10225，系统向用户提供一个有效项目主记录的列表显示。在步骤10230，买方用户选择适当的项目主记录。在步骤10235，买方用户保存该加入。在步骤10240，RFx投标到项目主的加入被存储在数据库中。
在步骤10245，买方例如如图16A-D中那样来处理RFx投标。在步骤10250，供应商例如如图25中那样来处理RFx投标响应。在步骤10255-10260，买方例如如图31-37中那样来处理并授予该供应商RFx投标响应。在步骤10270-10275，买方和供应商例如如图40C中那样来处理购买请购单/定单。在步骤10280，买方如图40C中那样来激活采购定单。
图103举例说明了一种改进的采购数据库模式10300，其包括主数据、投标请求与采购定单数据之间的结合性。模式10300允许项目管理系统9017和采购管理系统9013的高级结合性。
工作报表(SOW)记录配置 图104-115举例说明了工作报表(SOW)记录配置。SOW记录配置处理通常在图93的步骤9340-9350进行描述。
图104举例说明了根据本发明原理的工作报表动态10400。项目A 10405被分解为四个不同的RFx投标10410(a)-(d)。当完成投标及投标响应审阅处理时，RFx投标10410(a)-(d)最终可能引起投标授予的发布10420(a)-(d)。授予项目工作活动10425(a)-(d)被集成到买方和供应商实体进行处理的数据的购买请购单/定单模块10430(a)-(d)中。
采购订单中所确定和存储的个人项目工作活动10425(a)-(d)可被映射到采购定单交付模块10430(a)-(d)上所包含的特定交付。实际上，采购定单系列活动可被综合以反映出它们与什么可交付记录相关或加入。这个映射被表示为单元10432(a)-(d)。利用所加入的活动而产生的交付被表示为单元10435(a)-(b)。
项目级概念表示关系建立的附加级别，其把交付/SOW从供应商特定项目工作组件映射到总项目交付SOW框架中。使多个供应商独立地或协力地向着综合输出工作是常见的，同时处理并生成如相应的投标和采购订单中所规定的他们的个人输出。一个例子是当典型地在诸如阶段之类的进展组块中对项目进行管理时。传统上，当成功地完成时，来自各个供应商的许多交付总的来说会引起交付/SOW被实现，所述许多交付用作不同RFx投标的结果。把较小的交付集合到较大的项目级重要事件中由本领域技术人员识别为传统阶段项目模型。
把各个供应商SOW映射/加入到项目重要事件或阶段中是由单元10438表示的，并且会导致把所捆扎的供应商SOW集成到综合项目阶段中。动态10400到目前为止把各个项目交付分成较大的重要事件集合。在这一点上，在交付之间建立关系并且在所加入的记录集合内配置依存性的层次(即，因果)。由单元10440表示的配置产生已完成项目工作交付层次10445，利用其所有有限的项目工作输出不仅依赖于项目重要事件进展，而且还是以其简化了因果管理的方式而被确定。因而，交付被捆绑在一起以便确定不同交付/SOW记录之间的依存性。
关系建立的下一个方面是项目与项目组关系层。在项目投资内可能有许多发生在具有因果影响的多个项目内的独立活动。因此，需要这种结合性。家族性的项目(即，项目组内的项目)被表示为单元10450，而项目A和项目X之间的关系的映射被表示为单元10455。当关系映射出现在相同数据处理环境和数据库结构内时，即使交付输出属于不同的项目也可能发生相相同的依存性层次配置。这种结合性表示第三层项目SOW集成，其是多项目SOW/交付集成。
接下来描述的是在项目工作环境外且在企业的普通商业框架中的SOW/可交付记录的集成。这种集成分别被表示为单元10462、10468、10472以及10478，并且以核心信息数据单元10460、10465、10470以及10475为目标。
图105是经由用户导航和记录选择而例如从项目管理主页可访问的示范性买方用户项目主网页。图105表示了与授权用户的特定项目有关的原始信息和处理界面入口。在页面上对个人功能控制的用户访问取决于用户许可。
图106是描述把项目工作加入到交付/SOW记录的示范性处理流程。图106所举例说明的处理流程通常在图104的单元10432和10435进行描述。在图106中，采购定单活动到采购定单交付记录的加入处理流程开始于步骤10605。在步骤10605，授权买方用户借助于，例如从项目主主页导航来访问公开采购订单。在步骤10610，买方用户选择适当的采购定单。在步骤10615，系统向用户提供采购定单头和系列内容细节的显示。在步骤10615，采购订单取决于状态码。因而，一些采购订单可能还有待于批准或处于它们仍然是购买请购单的处理状态。因此，步骤10615适合于向用户显示被完成、批准的采购订单，以及为采购定单不交付系列内容到交付/SOW的映射做准备。
在步骤10620，向用户提供主动控制选项以配置活动关系或编辑活动关系。步骤10620反映了能够编辑系列内容与交付的关系的实际需要。响应于在步骤10620所选择的配置活动关系选项，在步骤10625，系统向用户提供一个采购定单交付和采购定单未交付系列内容的分段列表显示。步骤10625根据未交付采购定单系列内容来对交付/SOW记录的区段进行寻址。在步骤10630，用户借助于例如复选框来选择期望的可交付记录。在步骤10635，用户借助于例如单选按钮来选择一条或多条期望的加入未交付系列内容记录。在步骤10640，用户激活“保存设置”控制。在这一点上在处理流程10600中，买方用户已经使采购定单交付加加入一个或多个采购定单未交付系列内容中。
在步骤10645，系统运行验证程序。步骤10645的验证程序典型地需要日期比较操作。例如，因为采购定单未交付系列内容包含关于特定活动的信息，所以可执行简单的日期比较以确保与该活动有关的采购定单未交付系列内容不会在逻辑上例如超出所加入的采购定单交付的到期日。例如，如果采购定单交付在2006年10月15日到期并且买方用户已经使四个采购定单未交付系列内容加入到直到2007年1月都有效并延续的相关活动中，那么步骤10645的验证程序或许会指出冲突。在步骤10650，如果验证通过，则在步骤10655，采购定单系列活动到采购定单交付的加入被存储在数据库中。在步骤10650，如果验证失败，则执行进行到步骤10660。执行还从步骤10655到步骤10660继续进行。
在步骤10660，向用户提供超过所加入的交付到期日还延续采购定单未交付系列内容的列表显示。在步骤10665，向用户呈现选项以放弃未验证记录、修改未交付到期日、改进交付日期、或保存该未验证加入。其中买方用户想要保存该未验证加入的情况的例子可能是在劳动力未交付系列内容的情况下。例如，如果许多项目劳动者自始至终被分配到一具体项目并且他们的工作应用于遍及该项目的多个交付的活动，那么根据采购定单记录观点，如果仅为该劳动者创建一个分配记录，则其中一个或多个雇用的劳动者持续时间就会延续超过具体的所加入采购定单交付的情况，买方用户可以安全地忽略这种明显的冲突。在此情况下，该分配典型地会被映射到多个交付/SOW记录。
在步骤10670，用户响应于在步骤10665所呈现的选项而做出可变意向选择。在步骤10675，所选意向选项产生可变工作流程模型。在步骤10680，用户做出期望的改变。在步骤10685，用户激活“保存设置”控制。从步骤10685，执行回到步骤10645。本领域技术人员应当理解用户可以对任何无从属关系的采购定单记录重复该处理流程10600。关于图106而讨论的配置被存储在诸如表134和135之类的数据库表。处理流程10600最终导致使项目工作活动系列内容确定加入到确定的供应商交付SOW。下一个配置模式是把采购定单交付/SOW记录集成到总项目的框架中。
图107举例说明了用于描述项目阶段记录和阶段模式的创建的项目阶段记录创建处理流程10700。通常在图104的单元10438来描述处理流程10700。流程10700开始于步骤10705。在步骤10705，授权买方用户例如借助于从例如项目主主页导航来访问项目阶段。在步骤10710，系统向用户提供一个项目阶段记录的列表显示。在步骤10715，关于这种记录是否存在做出估计。如果在步骤10715确定是否定的，则执行进行到步骤10720。在步骤10720，用户选择所提供的“创建阶段”控制。在步骤10725，系统向用户提供阶段结构输入阶段。在步骤10730，系统提示用户指定项目阶段的数目。在步骤10735，系统响应于在步骤10730做出的用户输入而向用户提供项目阶段记录的列表显示。在步骤10740，用户选择该期望阶段。在步骤10745，系统向用户提供阶段输入页面。在步骤10750，用户完成输入。在步骤10755，用户保存设置。在步骤10760，该项目阶段被存储在数据库中。在步骤10765，用户对所有适当的阶段记录重复处理流程10700的在前步骤。
处理流程10700描述了其中不存在项目阶段记录的情况以便强调项目阶段记录可能会象一旦创建了记录那样地存在。然而，对于所描述的在前处理流程，阶段模式配置不一定是线性的和按顺序的。例如，买方在投标处理开始前也许在适当位置有一个非常严格的项目计划并且在按特定需求去投标前可能潜在地已经建立了这些阶段记录。相反地，在投标之后建立阶段计划或者接受与项目经理一起工作的供应商或供应商组的阶段计划都不是罕见的。因而，阶段计划的配置是可变的并且取决于所遇到的特定项目工作方案，只要在下面的图108的处理流程之前创建了项目阶段记录。阶段记录被存储在诸如表136之类的数据库表中。
图108举例说明了采购定单交付到项目阶段加入处理流程10800，其是存在于交付/SOW记录与项目阶段记录之间的下一个逻辑综合/映射。这些映射被存储在诸如表137之类的数据库表中。当完成处理流程10800时，已经把项目工作活动(即，交易数据)加入到图107的项目阶段以便简化在适当时期内要满足的目标。
回到图108，处理流程10800开始于步骤10805，在这个步骤授权买方用户借助于例如从项目主主页中进行导航而访问公开项目阶段。在步骤10810，系统向用户提供一个项目阶段记录的列表显示。在步骤10815，用户选择期望的阶段记录。在步骤10820，用户选择所提供的“加入交付”控制。在步骤10825，系统向用户提供一个未加入采购定单交付的列表显示。在步骤10830，用户借助于例如单选按钮来选择期望的采购定单可交付记录。在步骤10835，用户保存在步骤10830所选择的设置。
在步骤10840，系统提示用户完成输入。在步骤10845，用户完成输入。在步骤10850，用户保存输入设置。步骤10840-10850典型地与诸如阶段重要性设置之类的在前确定的阶段设置有关。(参见，例如，表137)在步骤10855，项目阶段交付被存储在数据库中。在步骤10860，用户对所有适当阶段和采购定单可交付记录重复处理流程10800。
图109举例说明了项目SOW/交付依存性配置处理流程10900。处理流程10900开始于步骤10905，在这个步骤授权买方用户借助于例如从项目主主页中进行导航而访问SOW管理信息。在步骤10908，系统向用户提供一个由阶段记录来综合的项目SOW记录的列表显示。在步骤10910，向用户提供选项以查看关系模式、创建关系模式、或编辑关系模式。换句话说，在步骤10910，提示用户关于是否在SOW记录之间创建、查看、或编辑依存性。
响应于在步骤10910用户做出的“创建关系模式”选项的选择，执行进行到步骤10915。在步骤10915，系统提示用户从列表中选择采购定单SOW。在步骤10918，用户选择SOW记录。在步骤10920，系统提示用户选择加入的记录。在步骤10925，用户选择加入的SOW记录。在步骤10925，加入记录的选择被描述成选择一个加入记录。然而，当提供功能来简化一块记录的选择以进行处理之时，不必一定有这种限制。
在步骤10930，系统向用户提供SOW关系配置页面。(参见，例如，表139，其包括配置页面的示范性选据单元)。在步骤10933，用户例如根据下拉菜单来指定SOW关系。在步骤10937，用户指定是否强制依存性约束条件，意味着直到它信赖的SOW记录已经完成之前都不能开始该依存SOW记录。强制的规范或非强制的约束条件暗示着从一个交付到另一个交付的依存的可能性，这表示从属交付不可能完成，然而不会禁止所有活动的发生。在这种情况下，不希望强制一个约束条件。例如，如果交付输出是取决于计算机网络的实际基础结构建立的技术维护手册，那么应当慎重地强制该约束条件，借此规定在完成父母交付之前不能开始该从属交付。
在步骤10940，用户输入期望的任何可选注释。在步骤10945，用户选择“保存关系”控制。在步骤10950，系统利用例如完成日期比较来验证关系变量。在步骤10955，验证意向出现。响应于传送的验证，执行进行到步骤10960。在步骤10960，SOW/交付加入被存储在数据库中。响应于步骤10955的验证失败，执行进行到步骤10965。在步骤10965，向用户提供失败验证变量的列表显示。在步骤10970，向用户呈现选项以退出会话或修改验证变量以便试图根据修改的变量来进行重新验证。响应于用户选择该修改验证变量选项，执行进行到步骤10975。
在步骤10975，用户做出变量意向选择。在步骤10980，该意向选项产生变量工作流程模型。在步骤10988，用户做出期望的改变。在步骤10990，用户激活“保存设置”控制。从步骤10990，执行回到步骤10950。本领域技术人员应当理解，用户可在需要时重复处理流程10900。依存性配置步骤允许连接项目的实际输出重要事件以及建立依存性。表139中以示范性方式公开的关系类型建立了SOW关键相依存。为处理流程10900而描述的记录存储器出现在诸如表138之类的数据库表中。除了功能用户界面呈现SOW/可交付记录的透视图以包括多个项目记录集合之外，项目组内不同项目之间的SOW的映射是类似的。
图110举例说明了如通常在图93的步骤9345所描述的那样把SOW/可交付记录映射到预算主数据记录的示范性处理流程11000。处理流程11000开始于步骤11005。在步骤11005，授权的买方用户从例如项目主主页中激活预算管理控制。在步骤11010，系统向用户提供默认配置项目相关预算主记录的列表显示。在步骤11015，用户选择适当的预算主记录。在步骤11020，系统向用户提供一个由项目阶段来综合的SOW/可交付记录的列表显示。在步骤11025，系统提示用户来选择SOW/可交付记录或项目阶段以便进行加入。
在步骤11030，用户做出选择。响应于在步骤11030的项目阶段的用户选择，执行进行到步骤11035。在步骤11035，系统向用户提供输入页面。在步骤11040，用户借助于例如下拉菜单来选择商业单位。在步骤11045，用户借助于例如下拉菜单来选择成本中心。在步骤11050，用户借助于例如下拉菜单来选择预算主记录所有者。在步骤11055，用户保存先前做出的设置。在步骤11060，系统基于预算主验证程序来运行日期和/或预算。在步骤11065，关于是否已经验证了预算主做出判断。如果在步骤11065判断是这样的话，执行进行到步骤11070，在这个步骤产生给批准的预算管理员的系统化通知。在步骤11075，预算管理员意向出现。在步骤11080，响应于在步骤11075由预算管理员的批准，加入被存储在数据库中。在步骤11085，发生给项目所有者的系统性通知。在步骤11030，响应于SOW/可交付记录的用户选择以便加入，执行进行到步骤11090。在步骤11090，除了要为每个SOW记录完成信息处理之外，个人SOW/可交付记录的用户选择需要与为完成阶段预算加入相同的数据处理流程。从步骤11090，执行回到步骤11055。
处理流程11000的映射被存储在诸如表140之类的数据库表中虽然在图110中没有具体地描述，但是功能上对于在多个商业单位和/或成本中心实体之间对特定交付的预算拨款进行分割有效。本领域技术人员应当理解处理流程11000可随着预算管理员或项目经理开始记录的配置映射而从多个方向开始。
图111举例说明了把SOW/可交付记录映射到资产主数据记录的示范性处理流程11100。处理流程11100开始于步骤11105，在这个步骤授权买方用户根据例如项目主主页而激活资产管理控制。在步骤11110，系统向用户提供默认配置项目相关资产主记录的列表显示。在步骤11115，用户选择适当的资产主记录。在步骤11120，系统向用户提供一个具有由项目阶段来综合的所加入物资系列内容的SOW/可交付记录的列表显示。在步骤11125，用户选择适当的SOW/可交付记录。在步骤11130，系统向用户提供一个加入物资系列内容的列表显示。在步骤11135，用户选择期望的系列内容。在步骤11140，系统向用户提供输入页面。在步骤11145，用户借助于例如下拉菜单来选择商业单位。在步骤11150，用户借助于例如下拉菜单来选择成本中心。在步骤11155，用户借助于例如下拉菜单来选择资产主记录管理员所有者。在步骤11160，用户保存先前做出的设置。在步骤11165，系统基于资产主验证程序来运行日期和/或资本预算。
在步骤11170，进行验证评估。响应于肯定的验证评估，执行进行到步骤11175。在步骤11175，发生给批准资产管理员的系统性通知。在步骤11180，接受预算管理员意向。响应于在步骤11180的批准，执行进行到步骤11185。在步骤11185，加入被存储在数据库中。在步骤11190，发生给项目所有者的系统性通知。处理流程11100的映射被存储在诸如表141之类的数据表中。
与所有主数据映射相类似，处理流程11100可从项目管理或者资产管理记录所有者处开始。本领域技术人员应当理解各个实施例可被配置成要求对项目工作内确定的所有物资活动的处理以保证资产管理透明度和其后续管理。在典型的商业环境中，资产可容易地属于在合约级进行管理的较大的工作报表(即，交付)。甚至在特定合约或资产管理系统的环境内也常常不能确定实际资产。
图112举例说明了把SOW/可交付记录映射到合约记录的示范性处理流程11200。处理流程11200开始于步骤11205，在这个步骤授权买方用户根据例如项目主主页而激活合约管理控制。在步骤11210，系统向用户提供默认配置项目相关合约记录的列表显示。在步骤11215，用户选择适当的合约记录。在步骤11220，系统向用户提供一个由项目阶段来综合的SOW/可交付记录的列表显示。在步骤11225，用户选择适当的SOW/可交付记录。在步骤11230，系统向用户提供输入页面。在步骤11235，用户借助于例如下拉菜单来选择商业单位。在步骤11240，用户借助于例如下拉菜单来选择成本中心。在步骤11245，用户借助于例如下拉菜单来选择适当顾客。在步骤11250，用户借助于例如下拉菜单来选择合约管理员所有者。在步骤11255，用户保存先前做出的设置。
在步骤11260，系统运行合约验证程序。验证不必对时间敏感，但也要对范围敏感。其他敏感的变量可能包括例如金钱或服务/货物供应类型。在步骤11265，进行合约验证的判断。响应于步骤11265的肯定验证，执行进行到步骤11270。在步骤11270，发生给批准合约管理员(即，所配置的合约主记录所有者)的系统性通知。在步骤11275，合约管理员意向产生。响应于在步骤11275的批准，执行进行到步骤11280。在步骤11280，加入被存储在数据库中。在步骤11285，发生给项目所有者的系统性通知。处理流程11200的映射被存储在诸如表142之类的数据库中。处理流程11200是双向的，即使在图112中没有把它明确地描写成这样。
下游客户的规范及后续合约参考可用于使多级合约加入到活动中。这是当例如买方实体根据合约利用外部供应商提供服务给终极用户时的情况下，所述终极用户受与买方实体的货物/服务合约约束。
图113举例说明了把SOW/可交付记录映射到商业事件记录的一处理流程11300。处理流程11300开始于步骤11303，在这个步骤授权买方用户根据例如项目主主页而激活商业管理控制。在步骤11305，系统向用户提供默认配置项目相关商业事件记录的列表显示。在步骤11310，用户选择适当的商业事件记录。在步骤11315，系统向用户提供一个由项目阶段来综合的SOW/可交付记录的列表显示。在步骤11320，用户选择适当的SOW/可交付记录。在步骤11323，系统向用户提供榆入页面。在步骤11325，用户借于例如下拉菜单来选择商业单位。在步骤11330，用户借助于例如下拉菜单来选择成本中心。在步骤11335，用户借助于例如下拉菜单来选择适当顾客。在步骤11340，用户指定关系类型。在步骤11345，用户指定是否强制依存性约束条件。在步骤11350，用户借助于例如下拉菜单来选择事件管理所有者。在步骤11355，用户保存先前做出的设置。
在步骤11360，系统运行商业事件验证程序。在步骤11365，关于该验证是否是肯定的或不是而做出判断。响应于步骤11365的肯定验证，执行进行到步骤11370。在步骤11370，发生给批准的商业事件管理员的系统性通知。在步骤11375，事件管理员意向产生。响应于在步骤11375的批准，执行进行到步骤11380，在这个步骤把加入存储在数据库中。在步骤11385，发生给项目所有者的系统性通知。处理流程11300的映射被存储在诸如表143之类的数据库表中。本领域技术人员应当理解处理流程11300是双向的，即使没有把它明确地描写成这样。
不同于其他主数据记录(即，预算、资产以及合约记录)，商业事件可表示因果性的因素；因此，采用依存性映射以及验证。依存性映射类似于当把SOW映射到SOW时所先前公开的。因为商业事件的开放性性质，实际上企业实体内发生的任何事都经由主数据到SOW的集成而依赖于项目。
图114举例说明描述项目组和项目主记录的的高级报告概述示范性用户界面网页。记录加入配置简化了对所有有关的细节和用户的项目工作用户访问的查看和供应的优化，本领域技术人员应当理解可以提供其他视图来描述关系和时间，描述数据输出视图是为了简化和容易理解的目的。
图115举例说明了结合上述讨论到的处理流程而使用的示范性支持数据库模式。
项目开始和PCIP/S风险概述报告模型 继依存性配置和商业记录到特定项目工作交付/SOW记录的映射之后，最终开始项目。先前描述的活动简化了供应商活动工作凭证的下游提交。凭证处理是这样一种处理，利用该处理供应商向所配置的买方用户提交工作执行确认请求。这个请求可能与开票事件有关或者与开票事件无关。
图116举例说明了产生风险商业记录的标识符和生成如通常在图93的步骤9353-9356所示的风险报告输出的凭证处理流程11600。处理流程11600开始于步骤11605。在步骤11605，项目工作开始。在步骤11610，供应商提交工作确认凭证以进行买方处理。在步骤11615，凭证处理数据表示超出预期完成日期的一个或多个活动。在步骤11620，系统通知SOW所有者活动日期违约行为。
在步骤11625，买方用户从例如项目主页中输入活动/SOW状态概述，或者利用提示链接以直接继续进行到活动记录。在步骤11630，买方用户访问违约活动记录。在步骤11635，系统向用户提供活动凭证交易的概述视图。在步骤11640，用户界面向用户提供主动控制以查看记录依存性。在步骤11645，用户激活该主动控制。在步骤11650，系统向用户提供对采购定单SOW、映射、项目阶段映射、相关采购定单SOW和主数据记录映射的配置活动的概述视图。在步骤11650，用户访问其中显示有所有配置关系的大图片。在这个视图内，典型地有关于关系特性的信息，所述关系是关于所讨论的活动属于的SOW记录的。
在步骤11655，系统提示用户指定预期采购定单SOW完成日期。这一点可能仅会通过项目的实际执行中所涉及的个人而发生在项目SOW所有权级。在步骤11660，用户指定日期和/或条件改变。如果判断出会对采购定单SOW有影响，则用户建立条件或者日期修改。在极个别情况下，条件改变可能是完全失效或取消，而在更极端情况中，或许仅仅所扩展的到期日是合理的。
在步骤11665，系统基于在步骤11660的用户输入而产生PCIP/S依存性影响视图。虽然没有明确地描述，但是可能会有这种情况，其中不会产生采购定单SOW影响或者仅仅是简单的管理问题，也就是即使活动实际上满足了日期，但是供应商在提交凭证方面也延迟了。在此情况下不会改变影响视图并且会话可能会结束。
在步骤11670，对相关风险记录是否是由其他用户所拥有而做出判断。响应于步骤11670的肯定的判断，执行进行到步骤11675，在这个步骤，买方用户激活系统提供的风险记录概述。在步骤11680，系统生成风险报告输出。在步骤11685，用户选择是否开始风险通信会话。
即使在处理11600中没有明确地表示，但是本领域技术人员应当理解，在会仅对相关采购定单SOW(或项目所有者所拥有的附加采购定单SOW)有影响的方案中，由于风险而做出的改变不会影响任何外部记录依存性或关系。在这种方案中，将采用单向的记录修改过程，通过该过程可经由用户控制的输入来更新所有记录。
PCIP/S风险通信会话 在步骤11685，买方实体现在装备有信息结构以推测对许多相关项目和主记录的潜在影响。即使这个信息的拥有不排除出现负面影响，但是它提供了透明度，并且如果使用正确，则会提供计划机会。本领域技术人员应当理解该信息可采用以下方式而被使用，即向用户提供透明度、需要做出通知的数据访问、最新的商业决策、以及关于风险源的维护信息。
图117-119举例说明了PCIP/S风险通信会话处理流程11700-11900，其包括风险SOW记录所有者包配置和将那个包广播给受影响用户，以及用于产生要提交回发布用户的完成记录集合的受影响用户记录数据处理。现在参考图117，处理流程11700开始于步骤11705，这个步骤从处理流程11600的步骤11685继续。在步骤11705，系统发出PCIP/S风险通信会话。在步骤11708，用户完成初始PCIP/S会话表单并且保存该表单。在步骤11710，系统向用户提供对所有受影响记录的显示。这些记录可以是按照例如SOWs、预算、资产、合约、以及商业事件记录而集合的。在步骤11715，系统提示用户确认修改条件和/或SOW到期日。在步骤11720，用户编辑或确认会话变量输入。在步骤11725，系统向用户提供一个已加入采购定单活动系列内容的列表显示。在步骤11730，系统提示用户以选择需要修改的系列内容。在步骤11735，用户借助于例如复选框来选择系列内容。
在步骤11740，系统提供允许编辑系列内容变量的用户界面。在步骤11745，用户修改条件或许可变量与个人选择的采购定单系列内容活动记录有关。在步骤11750，用户保存先前做出的设置。当完成对项目工作活动的编辑时，用户保存这些设置。拟定修改的这些活动记录被存储在诸如表149之类的数据库表中。
在步骤11755，关于用户是否拥有该受影响的依存项目SOWs而做出判断。如果在步骤11755判定为否，则系统更新该受影响记录概述视图并且指明在以依存性配置和可变数据比较为前提下哪个记录是有风险的。如果在步骤11755中判断为肯定的，则执行进行到步骤11760。在步骤11760，系统显示并提示用户配置该依存SOW记录。在步骤11765，用户编辑该依存受影响SOW记录。在步骤11770，系统向用户提供一个已加入采购定单活动系列内容的列表显示。在步骤11775，系统提示用户以选择需要修改的系列内容。从步骤11775，执行回到步骤11770。
一旦报告输出支持PCIP/S会话，用户就响应于利用该输出报告来提供的系统提示/控制而发出PCIP/S会话。在完成基本信息输入表单之后，在步骤11708，系统生成被加入到步骤11710的风险或失败SOW记录的完成记录集合的输出视图。初始表单的完成及其保存被存储在诸如表144之类的数据库表中。
然后系统提示用户以确认最初使用的数据修改以产生风险依存性报告。然后在步骤11720用户确认或修改该原始输入。
因为项目工作活动已经链接到SOW记录，系统能够向用户提供装入SOW的所有活动记录的列表显示。由于预期的SOW变更，其他项目工作活动记录以及因果活动记录可能需要修改。这些活动记录的选择发生在步骤11735。
当选择时，系统向用户提供每个个人选择记录的编辑界面。该编辑界面可基于活动本身而变化。例如，关于人力资源工作分配的条件和/或数据字段典型地不同于对于处理例如物资交付之类的另一个活动有效的那些。这些记录修改被描写成步骤11745。
图118举例说明了通常在图93的步骤9365所描述的PCIP/S风险通信会话处理流理11800。处理流程11800开始于步骤11805，这个步骤是从步骤11780继续的。在步骤11805，关于外部拥有的记录是否存在于该概述视图中而做出判断。如果在步骤11805判断为否，则执行进行到步骤11807，在这个步骤流程进行以在步骤11807进行更新。然而，如果在步骤11805中判断为肯定的，则执行进行到步骤11810。在步骤11810，系统提示用户配置PCIP/S通信包，由此为期望的个人用户(所有者)记录集合产生注释。
从步骤11810，执行进行到步骤11815，在这个步骤系统向用户提供按照商业所有者来集合的所有受影响记录的列表显示。在步骤11820，用户经由例如用户界面提供的复选框来选择期望的商业所有者。在步骤11825，用户提供关于该所选记录的期望注释。在步骤11830，用户保存先前做出的输入。在步骤11835，PCIP/S记录集合被存储在数据库中，状态为“保存”。在步骤11840，就他们是否想要广播该PCIP/S通信包而提示用户。如果用户选择广播该通信包，则执行进行到步骤11845，在这个步骤用户激活“广播买方PCIP/S包”控制。在步骤11850，系统把该包广播给所配置的用户，其中通知典型地是经由电子邮件和系统馈送更新而发布的。
图119举例说明了PCIP/S信息包的受影响用户处理，如通常在图93的步骤9370所显示的。关于由PCIP/S信息包的受影响用户处理的处理流程11900开始于步骤11902，在这个步骤受影响买方用户访问该PCIP/S信息集合。在步骤11905，系统向用户提供PCIP/S会话细节的大略概述，包括诸如发行者、日期广播和收到日期之类的信息。在步骤11908，系统向用户提供对访问受影响商业记录的控制。虽然没有明确地描述，但是根据买方偏好在步骤1908同样可以提供属于其他用户的其他影响记录的视图。在步骤11910，用户激活该控制。响应于在11910的控制激活，执行进行到步骤11912，在这个步骤系统向用户提供受影响记录和记录状态的列表显示。
在步骤11915，关于该记录是否取决于上游SOW处理而做出判断。由于多链依存记录集合的潜在性，如果没有处理相关的上游依存记录，则另一个下游记录的意向是不合逻辑的。如果在步骤11915判断是肯定的，则执行进行到步骤11918。在步骤11918，系统向用户提供依存性处理和适当商业所有者的细节。该记录被标记为无效以进行处理，其状态为“等待上游SOW意向”。在步骤11915，如果判断为否，则执行进行到步骤11920。在步骤11920，用户激活控制允许记录处理。在步骤11922，关于该记录是否是SOW记录而做出判断。如果在步骤11922判断是这样，则执行进行到步骤11925，在这个步骤用户象在步骤骤11725-11775那样处理记录。
从步骤11925，执行进行到步骤11928。在步骤11928，用户保存先前做出的设置。在步骤11930，在数据库中更新记录。在步骤11932，需要时向下游SOW记录所有者通知处理。在步骤11935，下游SOW处理继续直到完成。在步骤11938，关于是否已经处理了所有SOW记录和已加入的采购定单活动记录而做出判断。如果在步骤11938判断是这样，则执行进行到步骤11940。在步骤11940，系统通知主数据记录所有者SOW处理完成。在步骤11942，主记录所有者处理他们的个人记录。在步骤11942还发生配置条件和/或可变数据字段的编辑。响应于在步骤11922的否定判断，还执行步骤11942。
从步骤11942，执行进行到步骤11945，在这个步骤用户保存先前做出的设置。在步骤11948，在数据库中更新记录。主数据记录意向设置被存储在诸如表152之类的数据库表中。如表147的情况那样，复杂数据字段ControllableMDDataElements用作这些记录设置修改的两个处理存储装置，其具有SQL变量的数据类型。这个字段是用于以元数据形式存储设置的实体类型。这个数据模型可包括用于表示设置修改的保留表的个人数据库表；然而，本领域技术人员应当把这看作是替换数据库处理方式。在步骤11950，关于是否已经完成了所有主数据记录更新而做出判断。响应于在步骤11950的肯定判断，执行进行到步骤11952。这意见会生成给会话用户的系统通知并且更新数据库中的PCIP/S会话状态以等待审阅。虽然没有明确地描述，但是在数据处理的所有阶段期间，系统典型地执行验证。在步骤11952，系统产生返回给会话发行者的PCIP/S买方意见。在步骤11955，把系统通知发布给用户。在步骤11960，会话状态转变为“等待审阅”。
在买方偏好的范围内，不是所有记录都一定要被修改，并且各个实施例可以采用各种配置模式来操作，所述模式例如不会实施强制性的依存性约束条件规范或者例如简化修改以记录似乎从最佳实施观点来看不合逻辑条件。虽然整个记录集合典型地会对数据处理有效，但是潜在影响的记录典型地不会被缓存以进行处理，直到已经完成了上游意向置换。因而，在前配置不仅会设置依存性而且会在处理内开始和建立工作流程。
虽然没有明确地描述，但是当所讨论的记录直接与供应商的项目工作活动有关时，记录的修改典型地是一种合作处理。可以为PCIP/S会话来配置和实现在买方和卖方之间简化双向通信的投标留言板。买方可使用该留言板来与供应商就项目工作活动的任何修改条件(例如，价格、日期、数量、人力资源身份)而进行通信。
图120是简化PCIP/S通信会话的示范性数据库模式。
PCIP/S供应商接受包会话 当接收买方PCIP/S风险通信会话输入时，总方法的下一个阶段涉及由受到PCIP/S修改影响的任何供应商进行的发布和处理所获得的输入。
图121举例说明了PCIP/S接受包话会处理理流程12100。处理流程12100开始于步骤12105，在这个步骤通知买方用户PCIP/S“等待审阅”状态。在步骤12110，用户经由例如菜单导航或操作板链接而访问PCIP/S模块。在步骤12115，系统向用户提供概述报告输出，其指出了特定记录状态和可变数据修改。在步骤12120，关于对任何项目工作采购定单系列内容的影响做出系统性判断。
假定在记录集合内采购定单系列内容修改是固有的，那么在步骤12125系统提示对供应商更改定单批准的发布。在步骤12130，假定买方不会忽视这个处理特征的需要。当激活所提供的控制时，系统向用户提供记录输出，其概括了由供应商在步骤12135所综合的受影响采购定单记录。
系统地提示用户以广播/发布该PCIP/S供应商接受包。假定在步骤12140为肯定的用户操作，则系统向用户提供主要的PCIP/S供应商接受包网页。在步骤12150用户提供所需基本输入，以及当在步骤12155用户保存设置时，在步骤12160系统把该PCDP/S供应商接受包广播给适当的供应商并且在步骤12165把交易记录存储在数据库中。在这个处理阶段期间所利用的示范性数据库表被显示为表157-161。
当广播该PCIP/S供应商接受包时，在步骤12170系统就待定活动向所配置的供应商用户发布通知。这时，授权供应商用户被授权访问会话记录并且利用所提供的导航控制来访问适当的会话记录。
图122举例说明了通常在图93的步骤9375描述的PCIP/S接受包会话处理流程12200。处理流程12200开始于步骤12202。在步骤12202，授权供应商用户经由例如所提供操作板控制的标准导航或激活而访问PCIP/S接受包。在步骤12205，显示主要的PCIP/S接受包页面。在步骤12208，用户激活所提供的更改定单控制，这导致在步骤12210的任何或所有波及的采购订单的系统性概述输出。在步骤12212，用户选择个人采购定单以进行处理，这导致在步骤12215的受影响采购定单系列内容的系统性概述输出。在步骤12218，用户选择特定修改的系列内容以进行处理。在步骤12220，系统向用户提供采购定单系列内容细节并且指出哪个数据字段已经受到了影响。提示用户来验证数据和或对活动记录的条件更改。
在步骤12222，供应商用户验证该记录修改并且进行到步骤12225，其中系统基于基本配置而确定数据修改是否需要供应商纳税评估。如果肯定，那么供应商用户提供所需纳税评估数据，所述数据包括例如税务机关、起征限度额、税款百分比等等的输入提供。在步骤12230，用户保存他们的输入。
这个验证和纳税评估处理继续，直到在步骤12235处理了所有采购定单系列活动和采购订单并且没有剩余的未处理的记录时。此时在步骤12238提示用户把他们的输入提交回买方实体。假定合理的选择，在步骤12240供应商用户提交回买方实体。然后在步骤12242系统发布通知给授权买方实体用户并且更新所提交状态的PCIP/S供应商接受包响应。对于所有适当的受影响供应商重复这个处理流程12200，所述供应商与特定PCIP/S供应商接受包相关。当在步骤12248提交所有受影响的供应商的响应时，在步骤12250，PCIP/S供应商接受包状态被更新为“完成”，借此在步骤12252产生给授权买方实体用户的系统通知。
图123举例说明了PCIP/S系统的支持数据库模式。本领域技术人员应当理解，图123中框起来的右下侧部分举例说明了关于图121-122而在以上讨论的该表的模式的主要部分。
PCIP/S记录修改集成 当收到所有供应商PCIP/S接受包响应时，剩余阶段包括对PCIP/S信息的最后记录集合批准和集成。
图124描述了通常在步骤9380-9395中举例说明的PCIP/S记录批准和集成会话处理流程12400。处理流程12400开始于步骤12404，在这个步骤授权买方用户经由例如标准导航或操作板控制而访问所提交的供应商响应PCIP/S接受包。在步骤12408，用户显示主要的PCIP/S接受包页面。在步骤12412，用户激活所提供的变更定单概述控制。在步骤12416，向用户提供所有项目相关采购订单的概述列表显示。在步骤12420，需要最后的变更定单批准。响应于步骤12420的所需批准，执行进行到步骤13424。在步骤12424，提示用户广播更改定单批准请求。在步骤12428，用户激活所提供的更改定单批准控制。在步骤12432，系统广播采购定单批准请求。在步骤12436，向受影响的采购定单记录所有者发布系统性通知。在步骤12440，关于是否已经做出了采购定单批准而做出判断。响应于在步骤12440的肯定判断，执行进行到步骤12444。
在步骤12444，系统向与工作报表相关的主数据记录所有者广播采购定单批准通知。在步骤12448，关于是否已经做出了主数据记录修改而做出判断。响应于在步骤12448的肯完判断，执行进行到步骤12452，在这个步骤用户更新主数据记录。在步骤12456，用户保存新输入设置。在步骤12460，进行最后数据设置的用户批准。响应于在步骤12448的否定判断，执行进行到步骤12460。
从步骤12460，执行进行到步骤12464。在步骤12464，关于是否已经做出所有主日期记录意向而做出判断。响应于在步骤12464的肯定判断，执行进行到步骤12468。在步骤12468，向PCIP/S会话所有者发布系统通知。在步骤12472，PCIP/S会话所有者经由有效的导航控制而访问批准的PCIP/S记录集合。在步骤12476，提示用户更新处理记录。在步骤12480，更新记录。在步骤12484，系统运行日期程序记录。在步骤12488，记录修改被存储在数据库中。在步骤12492，向受影响的PCIP/S记录所有者发布系统通知。
首先办理采购定单批准以确保主数据记录不会得到最后批准或者基于未完成或未批准的采购定单数据而有可能被编辑。
对于交易项目工作数据来说主数据处理是次要的。当希望更新可能会受供应商接受包响应数据设置影响的任何记录时，判定主数据编辑功能。
表113
表114

表114A
表115(设计)
表115(数据)
表116

表117
表118
表119

表120
表121
表122
表123
表124

表125
表126
表127

表128
表129
表130

表131
表132

表133

表134
表135
表136

表137
表138
表139(设计)
表139(数据)
表140
表141

表142
表143

表144
表145(设计)
表145(数据)

表146(设计)
表146(数据)
表147

表148(设计)
表148(数据)
表149
表150
表151(设计)
表151(数据)
表152(设计)
表152(数据)

表153

表154(设计)
表154(数据)
表155(设计)
表155(数据)

表156
表157
表158
表159
表160
表161
提供了一种用于生成与项目投标管理系统有关的分析数据的全面的、可连网计算机系统和方法。与投标和项目有关的交易数据通过在线投标、项目请购单和付款处理而被输入到计算机系统中。利用系统内所存储的交易数据，实际上可以产生与由一个或多个卖方为一个或多个买方所执行的单个或多个项目有关的任何类型的分析数据。
一种在用于管理一个或多个项目和一个或多个投标并且其中存储有交易数据的系统中生成分析数据的方法，其包括在系统上执行在线投标处理、在在线投标处理期间把投标数据输入到投标的数据字段中作为交易数据的一部分、接收对与交易数据有关的分析数据的请求、以及根据响应于该请求的交易数据而利用交易数据来产生分析数据。
该输入步骤还包括由与投标有关的买方把投标请求数据输入到数据字段中、以及由与投标有关的卖方把投标响应数据输入到数据字段中。
用于生成分析数据的方法还包括把项目的项目跟踪参数输入到与投标有关的数据字段中作为交易数据的一部分、把凭证信息输入到与项目有关的数据字段中作为交易数据的一部分、以及把项目执行数据输入到与项目有关的数据字段中作为交易数据的一部分。这个方法还包括在项目的执行期间由买方和卖方把项目执行数据输入到系统中。
该方法还包括至少利用项目跟踪参数来自动地产生项目执行数据。这个方法更进一步包括利用凭证信息比较项目跟踪参数以确定项目的状态、以及自动地把项目状态作为项目执行数据输入到系统中。
产生步骤可包括搜索项目跟踪参数以确定项目的时间状态以及自动地把项目的时间状态作为项目执行数据输入到系统中。
输入项目跟踪参数的步骤可包括输入用于标识项目的可征税部分以及与每个可征税部分有关的纳税总额的纳税信息。
接收的步骤可包括接收对分析数据的请求，该请求包括一个或多个过滤器，以及对交易数据进行过滤以利用该一个或多个过滤器来生成过滤交易数据，该过滤交易数据用于产生分析数据。
接收包括一个或多个过滤器的请求的步骤还可包括接收对与一种或多种类型的交易数据有关的分析数据的请求，该一个或多个过滤器用于过滤该一种或多种类型的交易数据。
一个或多个过滤器与卖方概况属性、买方概况属性、项目概况属性、以及商品概况属性中的至少一个有关。
用于生成分析数据的方法还可包括在网页上的项目报告视图中提供分析数据。该项目报告视图可以是项目报告类型，项目报告类型是财务类型、项目类型、商品类型或卖方/人力资本类型之一。
产生的步骤还可包括把与多个项目有关的交易数据进行综合以产生分析数据。综合的步骤可包括计算与交易数据有关的统计数据，所述交易数据与每个项目有关，以及跨越多个项目来综合该统计数据。综合的步骤还可包括把与由多个卖方执行的多个项目有关的交易数据进行综合以产生分析数据。这个综合的步骤还可包括把与多个买方有关的交易数据进行综合以产生分析数据。
产生的步骤可包括利用与多个项目有关的交易数据来计算统计数据以产生分析数据。计算的步骤可包括利用与多个买方有关的交易数据来计算统计数据以产生分析数据。
用于生成分析数据的方法还可包括在相应的买方、卖方或管理员的数据库系统中存储与买方、卖方或管理员的投标和项目有关的个人交易数据，以及把存储在数据库系统中的至少一部分交易数据传送到用于存储来自多个数据库系统的多个交易数据的中央数据库中，根据该多个交易数据而产生分析数据。
一种用于生成与用于管理一个或多个项目和一个或多个投标的系统有关的分析数据的计算机系统，其包括所连接的基于万维网界面以接收对与交易数据有关的分析数据的请求，用于维护至少包括投标数据的交易数据的数据库系统，该投标数据经由基于万维网界面而被输入到所述数据库系统中存储的投标的数据字段中，以及连接于所述基于万维网界面以接收该请求并且连接于所述数据库系统以根据该请求而检索交易数据的服务器，所述服务器响应于该请求而根据所检索的交易数据来可操作地产生分析数据。
数据库系统可存储投标数据，所述投标数据包括经由所述基于万维网界面由与投标有关的买方输入到数据字段中的投标请求数据以及由与投标有关的卖方输入到数据字段中的投标响应数据。数据库系统还可存储交易数据，所述交易数据至少包括投标数据、经由所述基于万维网界面由与项目有关的买方和卖方输入到与投标有关的数据字段中的项目的项目跟踪参数、经由所述基于万维网界面由买方和卖方输入到与投标和项目有关的数据字段中的凭证信息以及存储在与投标和项目有关的数据字段中的项目执行数据。数据库系统还可存储项目跟踪参数，所述项目跟踪参数包括输入用于标识项目的可征税部分以及与每个可征税部分有关的纳税总额的纳税信息。
服务器还可可操作地接收下述请求，该请求包括一个或多个过滤器，以及对交易数据进行过滤以利用该一个或多个过滤器来生成过滤交易数据，该过滤交易数据用于产生分析数据。这些一个或多个过滤器与卖方概况属性、买方概况属性、项目概况属性、以及商品概况属性中的至少一个有关。
服务器可更进一步可操作地经由所述基于万维网界面在网页上的项目报告视图中提供该分析数据。该项目报告视图可以是项目报告类型，该项目报告类型是财务类型、项目类型、商品类型或卖方/人力资本类型之一。
服务器可操作地把与多个项目有关的交易数据进行综合以产生分析数据。服务器可操作地计算与交易数据有关的统计数据，所述交易数据与每个项目有关，以及跨越多个项目来综合该统计数据。服务器可操作地把与由多个卖方所执行的多个项目有关的交易数据进行综合以产生分析数据。服务器可操作地把与多个买方有关的交易数据进行综合以产生分析数据。
服务器还可可操作地利用与多个项目有关的交易数据来计算统计数据以产生分析数据。服务器还可可操作地利用与多个买方有关的交易数据来计算统计数据以产生分析数据。
该数据库系统可被配置成存储与买方、卖方或管理员的投标和项目有关的个人交易数据，可包括连接到所述数据库系统的中央数据库以接收存储在数据库系统中的交易数据的至少一部分，所述中央数据库用于存储来自多个数据库系统的多个交易数据，根据该多个交易数据而产生所述分析数据。
在其中存储计算机可执行指令且与用于管理一个或多个项目和一个或多个投标的系统有关的计算机可读介质中，这些计算机可执行指令可包括用于接收对与交易数据有关的分析数据的请求的装置，该交易数据至少包括投标数据，在在线投标处理期间该投标数据被输入到存储在数据库系统中的投标的数据字段中；用于访问数据库系统以根据该请求来检索交易数据的装置；以及用于响应于该请求根据所检素的交易数据来产生分析数据的装置。
一种用于在管理项目和把交易数据存储于其中的系统中生成分析数据的方法，其包括把项目执行数据输入到与每个项目有关的数据字段中作为交易数据的一部分，接收对与交易数据有关的分析数据的请求，以及根据该请求来综合该交易数据以产生综合项目执行数据。
该方法包括把项目的项目跟踪参数输入到与项目有关的数据字段中作为交易数据的一部分、由至少一个买方以及至少一个卖方把凭证信息输入到与项目有关的数据字段中作为交易数据的一部分。
这个方法还可包括在项目的执行期间由至少一个买方和至少一个卖方卖方把项目执行数据输入到工程投标管理系统中。该方法还可包括至少利用项目跟踪参数来自动地产生项目执行数据。
产生步骤可包括把给定的一个项目的项目跟踪参数与该给定项目的凭证信息进行比较以确定给定项目的状态，以及自动地把给定项目的状态作为项目执行数据输入到系统中。
产生步骤还可包括搜索项目跟踪参数以确定项目的时间状态信息，以及自动地把项目的时间状态信息作为项目执行数据输入到系统中。
接收的步骤包括接收对分析数据的请求，该请求包括一个或多个过滤，以及对交易数据进行过滤以利用该一个或多个过滤来生成过滤交易数据，该过滤交易数据用于产生分析数据。
接收包括一个或多个过滤的请求的步骤可包括接收对与一种或多种类型的交易数据有关的分析数据的请求，该一个或多个过滤用于过滤该一种或多种类型的交易数据。
一个或多个过滤与卖方概况属性、买方概况属性、项目概况属性、以及商品概况属性中的至少一个有关。
该方法可包括在网页上的项目报告视图中提供分析数据。该项目报告视图可以是项目报告类型，该项目报告类型是财务类型、项目类型或卖方/人力资本类型之一。
综合的步骤还可包括计算与交易数据有关的统计数据，所述交易数据与每个项目有关，以及跨越这些项目来综合该统计数据。
综合的步骤还可包括把与由多个卖方执行的项目有关的交易数据进行综合以产生分析数据。
综合的步骤还可包括把与多个买方有关的交易数据进行综合以产生分析数据。存储的步骤可包括在相应的买方、卖方或管理员的数据库系统中存储与买方、卖方或管理员的投标和项目有关的个人交易数据，以及把存储在数据库系统中的至少一部分交易数据传送到用于存储来自多个数据库系统的多个交易数据的中央数据库中，根据该多个交易数据而产生分析数据。
一种用于在管理一个或多个投标和一个或多个项目并且其中存储有交易数据的系统中生成分析数据的方法，其包括在在线项目处理期间把投标数据部分输入到投标的数据字段中作为交易数据的一部分、把与项目有关的项目跟踪参数部分输入到与投标有关的数据字段中作为交易数据的一部分，把项目执行数据部分输入到与项目有关的数据字段中作为交易数据一部分，接收对与交易数据的一个或多个部分有关的分析数据的请求，以及根据响应于该请求的交易数据来产生分析数据。
一种用于由多个买方委任的管理多个投标和多个项目并且存储有与该多个项目有关的交易数据于其中的系统中生成分析数据的方法，包括接收对与交易数据有关的行业分析数据的请求，交易数据至少包括表明由与项目有关的一个或多个卖方的项目的执行的项目执行数据，根据该请求而访问交易数据，以及根据响应于该请求的所访问交易数据来产生分析数据。
这个方法可包括在相应的买方、卖方或管理员的数据库系统中存储与买方、卖方或管理员的投标和项目有关的个人交易数据，以及把存储在数据库系统中的至少一部分交易数据传送到用于存储来自多个数据库系统的多个交易数据的中央数据库中，根据该多个交易数据而产生分析数据。
一种用于在管理项目和把交易数据存储于其中的系统中生成纳税总额信息的方法，其包括把纳税信息输入到与项目有关的数据字段中作为交易数据的一部分，把凭证信息输入到与项目有关的数据字段中以作为交易数据的一部分，以及根据该纳税信息而产生与凭证信息有关的纳税总额。这个方法包括向与项目有关的买方和卖方提供该纳税总额以供其批准。
所属领域技术人员应当理解，除了此处描述的系统和方法之外，本发明还指向用于实现上述特征和功能的计算机数据库、软件应用、程序、协议、例程、和指令(总起来说“计算机程序设计指令”)。计算机程序设计指令最好是存储在存储器内，以及可经由通信接口而被接收或传送。
所属领域技术人员应当承认，当前应用中所描述的新颖性概念也可以在很大范围的应用中被修改和变化。因此，特许主题的范围不应当被限制在所讨论的特定示范性教导中的任一个，但是代之以由下列权利要求来定义。
权利要求
1. 一种项目工作行政管理方法，包括
从买方那里接收项目管理配置；
存储与由供应商执行的买方的项目工作有关的交易项目工作数据；
从买方那里接收项目工作报表(SOW)记录配置；
对买方的计划/范围记录集合中的项目变更进行处理；
对供应商的计划/范围记录集合中的项目变更进行处理；以及
利用买方的记录集合和供应商的记录集合来创建计划/范围记录集合中的综合项目变更。
2. 如权利要求1所述的方法，其特征在于所述项目管理配置包含
项目记录集合；
预算记录集合；
资产记录集合；
合同主记录；
非项目商业事件记录；以及
其中项目记录集合、预算记录集合以及资产记录集合中至少一个包括多个分层的记录。
3. 如权利要求1所述的方法，其特征在于存储交易项目工作数据的步骤包括
向供应商提供买方发布的RFx投标；
提供对RFx投标的供应商响应；
接收对RFx投标的供应商响应的买方接受；
基于买方接受的对RFx投标的供应商响应的要素而产生至少一个采购定单；
响应于所提供的项目工作服务而向买方提供供应商工作回执凭证；以及
接收供应商工作回执凭证的买方意向；以及
执行核准的供应商工作回执凭证的财务处理。
4. 如权利要求3所述的方法，更进一步包括利用RFx投标内容来建立项目工作活动。
5. 如权利要求4所述的方法，其特征在于所述利用RFx投标内容来建立项目工作活动的步骤包括
利用适合于获得并处理有关至少一个下列交易数据对象类型的数据的RFx投标内容
人力资源分配；
人力资源劳动力类型；
人力资源费率类型；
人力资源支出类型；
物资；
其他项目支出；
基于单位/按件计酬的交付；
固定价格交付；以及
利用至少一个可交付的RFx投标内容类型。
6. 如权利要求3所述的方法，其特征在于对买方RFx投标的供应商响应包括
适用于RFx投标内容的数据；以及
适用于至少一个可交付项目工作活动的数据。
7. 如权利要求3所述的方法，其特征在于供应商RFx投标响应的买方接受包括
适用于买方项目工作活动的供应商RFx投标响应要素的接受；以及
包括至少一个可交付项目工作活动的供应商RFx投标响应要素的接受。
8. 如权利要求3所述的方法，其特征在于产生至少一个采购定单的步骤包括把所接受的供应商RFx投标响应要素数据集成到采购定单中；
9. 如权利要求8所述的方法，其特征在于把所接受的RFx投标响应要素数据集成到采购定单中的步骤包括
创建采购定单；
建立采购定单系列；以及
使RFx投标响应要素数据加入到采购定单系列中以建立项目工作交易数据。
10. 如权利要求1所述的方法，其特征在于项目SOW记录的配置包括
把采购定单可交付记录指定为SOW记录；
采购定单系列内容的配置，所述采购定单系列内容包括被加入到可交付输出工作活动的不可交付项目工作活动。
项目阶段的配置；
SOW记录依存性的配置；以及
SOW记录主数据加入的配置。
11. 如权利要求1所述的方法，其特征在于处理买方的计划/范围记录集合中的项目变更的步骤包括
产生项目SOW依存性和主记录加入输出；
其特征在于依据企业范围内的连通性来描述该项目；
广播项目风险通信包；
接收项目风险通信包响应；以及
处理所述项目风险通信包响应。
12. 如权利要求1所述的方法，其特征在于处理供应商的计划/范围记录集合中的项目变更的步骤包括
创建计划/范围接受包中的项目变更；
广播计划/范围接受包中的项目变更；
处理所广播的计划/范围接受包中的项目变更；以及
接收所广播的计划/范围接受包中的项目变更的完成。
13. 如权利要求1所述的方法，其特征在于创建所集成的计划/范围记录集合中的项目变更的步骤包括
接收计划/范围项目变更定单中的至少一个项目变更；
对计划/范围项目变更定单中的所述至少一个项目变更进行处理；
响应于计划/范围项目变更定单中的至少一个项目变更的批准而处理至少一个主数据记录；以及
更新至少一个所处理的主数据记录。
14. 一种项目工作投资组合管理记录集合创建方法，所述方法包括
创建项目组合记录集合；以及
创建预算组合记录集合；以及
创建资产组合记录集合；以及
创建合同主记录；以及
创建非项目商业事件记录。
15. 如权利要求14所述的方法，其特征在于创建项目组合记录集合的步骤包括
创建适合于存储项目组属性、买方机构、以及商业所有权可信赖性数据的项目组记录；
创建适合于存储买方项目数据的至少一个项目主记录；
存储所述项目组记录与所述至少一个项目主记录的联系；
存储被加入到项目组的至少一个项目主记录之间的适当依存关系；以及
把适用于所述项目主的默认买方机构和商业所有权数据存储为默认项目组数据的约束条件。
16. 如权利要求14所述的方法，其特征在于创建预算组合记录集合更进一步包括
创建适合于存储买方机构、商业所有权可信赖性、以及财务数据的预算组记录；
创建适合于存储买方预算数据的至少一个预算主记录；
存储所述预算组记录与所述至少一个预算主记录之间的联系；以及
把适用于所述预算主记录的默认买方机构、商业所有权、以及财务数据存储为默认预算组数据的约束条件。
17. 如权利要求14所述的方法，其特征在于创建资产组合记录集合更进一步包括
创建适合于存储买方机构、商业所有权可信赖性、以及财务数据的资产组记录；
创建适合于存储买方资产数据的至少一个资产主记录；
存储所述资产组记录与所述至少一个资产主记录之间的联系；以及
把适用于所述资产主的默认买方机构、商业所有权、以及财务数据存储为资产组数据的约束条件。
18. 如权利要求14所述的方法，其特征在于合同主记录的创建更进一步包括
创建适合于存储适用于买方合同的买方机构、商业所有权可信赖性、财务、以及合同数据的合同主记录。
19. 如权利要求14所述的方法，更进一步包括创建适合于存储买方机构、商业所有权可信赖性、以及商业事件数据的至少一个非项目商业事件记录。
20. 如权利要求15所述的方法，其特征在于所述创建至少一个项目主记录的步骤更进一步包括至少以下之一
将至少一个项目主记录中的每一个加入到至少一个预算主记录；
将至少一个项目主记录中的每一个加入到至少一个资产主记录；
将至少一个项目主记录中的每一个加入到至少一个合同主记录；以及
将至少一个项目主记录中的每一个加入到至少一个商业事件主记录。
21. 一种配置项目SOW可交付记录的方法，所述方法包括
使不可交付项目工作活动采购定单系列内容与至少一个采购定单系列可交付类型记录相关；
指定与采购定单可交付记录有关的属性数据；
创建至少一个项目工作阶段记录；
指定与至少一个项目阶段记录有关的属性数据；
配置采购定单可交付记录依存性；以及
配置把采购定单可交付记录加入主数据记录。
22. 如权利要求21所述的方法，其特征在于创建至少一个项目工作阶段记录的步骤包括将至少一个项目阶段记录加入到主项目记录。
23. 如权利要求21所述的方法，其特征在于创建至少一个项目阶段记录的步骤包括将采购定单可交付记录加入到至少一个项目阶段记录。
24. 如权利要求21所述的方法，其特征在于配置采购定单可交付记录依存性的步骤包括建立项目内的采购定单可交付记录之间的关系。
25. 如权利要求24所述的方法，其特征在于建立项目内的采购定单可交付记录之间的关系的步骤包括
指定所涉及的采购定单可交付记录之间的依存关系类型；以及
指定下游依存采购定单可交付记录完成状态是否是由所涉及采购定单可交付记录的完成状态所约束的。
26. 如权利要求21所述的方法，其特征在于配置采购定单可交付记录依存性的步骤包括建立项目组内的多个项目的采购定单可交付记录之间的关系。
27. 如权利要求26所述的方法，其特征在于建立多个项目内的采购定单可交付记录之间的关系的步骤包括
指定所涉及的采购定单可交付记录之间的依存关系类型；以及
指定下游依存采购定单可交付记录完成状态是否是由所涉及采购定单可交付记录的完成状态所约束的。
28. 如权利要求21所述的方法，其特征在于配置使采购定单可交付记录加入到主数据记录的步骤包括至少以下之一
将采购定单可交付记录加入到被映射至项目主记录的至少一个预算主记录；以及
将包含有至少一个物资记录的采购定单可交付记录加入到被映射至项目主记录的至少一个资产主记录；以及
将采购定单可交付记录加入到被映射至项目主记录的至少一个合同主记录；以及
将采购定单可交付记录加入到被映射至项目主记录的至少一个商业事件主记录。
29. 如权利要求28所述的方法，其特征在于配置使采购定单可交付记录加入到主数据记录的步骤包括
指定适用于采购定单可交付记录到主数据记录加入的属性数据；以及
指定买方人员负有采购定单可交付记录到主数据记录加入的责任。
30. 如权利要求29所述的方法，更进一步包括
在数据库中存储所配置的采购定单可交付记录到主数据记录的加入以及SOW记录依存性；
通知对存储在数据库中的采购定单可交付记录和采购定单可交付记录的主数据记录的加入负责的买方人员；以及
向所通知的买方人员提供对他们的相应记录加入细节的访问。
31. 一种评估计划/范围中的项目变更的方法，所述方法包括
响应于供应商提交的项目工作回执凭证的买方意向而执行项目可交付依存性和主记录加入分析；
识别不符合有关预定完成日期的采购定单可交付SOW记录；
接收对至少一个不符合的可交付记录的选择；
产生项目风险通信会话；
广播项目风险通信包；
接收项目风险通信包响应；以及
处理所述项目风险通信包响应。
32. 如权利要求31所述的方法，更进一步包括，响应于至少一个不符合的可交付记录的选择
产生风险交付输出，其包括潜在影响的交付和加入到所选不符合的可交付记录的主数据记录；
对加入到所选的不符合的可交付记录的风险交付记录进行识别；以及
接收对所识别的风险交付记录的状态或者完工日期的修改。
33. 如权利要求32所述的方法，更进一步包括，响应于所述修改
产生由风险可交付记录影响的主数据记录和可交付记录的更新模型；以及
识别对由风险可交付记录所影响的可交付记录负责的买方人员；以及
初始化风险通信会话。
34. 如权利要求31所述的方法，其特征在于产生项目风险通信会话的步骤包括
创建项目风险通信会话记录集合；
由项目风险通信会话所有者提供对采购定单项目工作活动系列内容的访问，所述采购定单项目工作活动系列内容被加入到至少一个不符合的可交付记录；以及
响应于采购定单项目工作活动系列内容修改而存储设置。
35. 如权利要求34所述的方法，更进一步包括，响应于存储步骤，向项目风险通信会话所有者呈现由买方人员可信赖性所综合的受影响的商业记录，其特征在于用户界面适合于向所涉及的人员发布广播。
36. 如权利要求31所述的方法，其特征在于处理项目风险通信包响应的步骤包括
显示可交付记录上游或下游依存性；
显示所加入的可交付记录的状态；
允许可交付记录修改；以及
允许主数据记录修改。
37. 如权利要求36所述的方法，更进一步包括存储可交付记录修改。
38. 如权利要求37所述的方法，更进一步包括
响应于存储可交付记录修改的步骤
验证与依存可交付记录有关的交付完成日期；
响应于不存在加入的可交付记录完成日期冲突而向买方人员提供成功验证通知；以及
更新项目风险通信包响应状态码以完成。
39. 如权利要求37所述的方法，更进一步包括
响应于验证可交付完成日期的步骤
响应于至少一个加入的可交付记录完成日期冲突而提供失败验证通知；
更新冲突的项目风险通信包响应状态码；以及
显示特定冲突的被加入的可交付记录细节；
响应于用户输入而修改冲突记录细节。
40. 如权利要求38所述的方法，更进一步包括，响应于更新所述项目风险通信包响应状态码以完成，向项目风险通信会话所有者提示项目风险通信包响应记录更新的提交。
41. 如权利要求40所述的方法，更进一步包括
响应于把项目风险通信包响应记录更新提交给项目风险通信会话所有者
验证所有项目风险通信包响应的完成状态；
判断通信包响应记录更新是否包括采购定单变更；以及
向下游可交付记录所有者通知所提交的项目风险通信响应。
42. 如权利要求41所述的方法，更进一步包括，响应于验证所有通信包响应的完成状态，设置项目风险通信会话状态码以等待审阅的步骤。
43. 如权利要求42所述的方法，更进一步包括，响应于在通信包响应内没有采购定单系列内容修改
向项目风险通信会话所有者提供适当的用户界面，利用该用户界面可以把可交付记录和主数据记录修改集成为有效企业数据；以及
响应于项目风险通信会话所有者活动而利用可交付记录和主数据记录修改来更新有效企业数据。
44. 一种处理计划/范围中的项目变更的方法，所述方法包括
创建计划/范围接受包中的项目变更；
广播所述计划/范围接受包中的项目变更；
处理所广播的计划/范围接受包中的项目变更以完成；以及
提供计划/范围接受包中的已完成的所广播的项目变更。
45. 如权利要求44所述的方法，其特征在于创建计划/范围接受包中的项目变更的步骤包括
创建适合于存储属性信息的计划/范围接受包记录中的项目变更；以及
为计划/范围接受包记录中的项目变更分配公开状态码。
46. 如权利要求44所述的方法，其特征在于广播所述计划/范围接受包中的项目变更的步骤包括
呈现按照供应商职责而综合的受影响的采购定单记录；以及
提供适合于广播所述接受包的用户界面。
47. 如权利要求44所述的方法，其特征在于所述处理所广播的计划/范围接受包中的项目变更的步骤包括
通知适当的供应商人员计划/范围接受包中的待定项目变更数据处理；以及
其特征在于给定供应商人员的数据处理被限制在供应商人员的个人影响采购定单系列内容记录集合。
48. 如权利要求44所述的方法，其特征在于响应于广播接收而处理所述计划/范围接受包中的项目变更以完成的步骤包括
向供应商人员提供所述受影响采购定单系列内容记录；
接收供应商人员受影响采购定单系列内容记录批准；以及
响应于所述记录批准而存储批准的交易。
49. 如权利要求48所述的方法，其特征在于处理所广播的计划/范围接受包中的项目变更以完成的步骤包括
确定至少一个受影响采购定单系列内容记录是否需要供应商纳税评估；
响应于至少一个受影响采购定单系列内容记录需要供应商纳税评估的判定而存储纳税评估数据；以及
更新计划/范围接受包中的项目变更状态码以表明响应于已经存储了所有受影响采购定单系列内容记录的纳税评估数据的判定的完成。
50. 如权利要求44所述的方法，其特征在于提供已完成的所广播计划/范围接受包中的项目变更的步骤包括
向计划/范围中的买方项目变更的会话所有者通知计划/范围中的项目变更的包响应；
向相关买方人员记录所有者通知计划/范围接受包响应中的项目变更的采购定单系列内容记录；
以及
验证计划/范围接受包响应中的项目变更的状态。
51. 如权利要求50所述的方法，其特征在于所述验证的步骤包括
向计划/范围中的买方项目变更的会话所有者通知计划/范围接受包响应中的项目变更的完成；
修改计划/范围接受包状态中的项目变更以表明批准。
52. 一种创建计划/范围记录集合中的集成项目变更的方法，所述方法包括
创建计划/范围项目变更定单中的至少一个项目变更；
处理所述计划/范围项目变更定单中的至少一个项目变更；
响应于计划/范围项目变更定单中的至少一个项目变更的批准而处理至少一个主数据记录；
更新至少一个所处理的主数据记录；以及
激活计划/范围记录修改中的所有项目变更。
53. 如权利要求52所述的方法，其特征在于创建计划/范围项目变更定单中的至少一个项目变更的步骤包括
由有责任的买方人员记录所有者来综合所修改的项目工作采购定单记录；以及
开始变更定单批准请求；以及
广播所述变更定单批准请求。
54. 如权利要求53所述的方法，其特征在于广播变更定单批准请求的步骤包括
向有责任的采购定单记录所有者买方人员通知待定变更定单批准请求；
响应于有责任的采购定单记录所有者买方人员输入，而处理变更定单批准请求；以及
其特征在于，对于给定买方人员，买方人员变更定单批准处理被限制在采购定单记录，对此买方人员是有责任的记录所有者。
55. 如权利要求54所述的方法，其特征在于处理变更定单批准请求的步骤包括
修改变更定单批准请求的状态以表明批准；
把变更定单批准请求交易存储在数据库中；以及
向计划/范围中的买方项目变更会话所有者通知变更定单批准。
56. 如权利要求52所述的方法，其特征在于处理至少一个主数据记录的步骤包括
向计划/范围中的买方项目变更会话所有者提供项目主数据记录，所述项目主数据记录附属于所加入的已批准变更定单并且是由适当买方人员记录所有者来综合的；以及
向负责附属于已批准变更定单的项目主数据记录的买方人员发布通知，所述通知是所加入的项目主数据记录对于其他处理有效。
57. 如权利要求56所述的方法，其特征在于向负责附属于已批准变更定单的主数据记录的买方人员发布通知的步骤包括
向买方人员提供用户界面，所述用户界面适合于允许对主数据记录进行修改；以及
响应于记录修改而存储输入设置。
58. 如权利要求57所述的方法，更进一步包括
响应于存储输入设置的步骤，其中所述存储输入设置响应于记录修改
通知买方会话所有者所保存的主数据记录输入设置；
判断是否已经存储了附属于所有变更定单的所有主数据记录；
修改计划/范围会话状态中的项目变更以表明响应于存储附属于所有变更定单的所有主数据记录仍然需要执行的集成。
59. 如权利要求52所述的方法，其特征在于激活的步骤包括
执行更新过程，利用该过程记录修改变为有效；
响应于所述更新过程，把记录修改存储为有效企业数据；以及
向买方人员通知所述记录修改。
60. 一种用于项目工作管理的计算机系统，所述计算机系统包括
界面，适合于接收项目管理配置以及与由供应商为买方执行的项目工作有关的交易项目工作数据；
数据库系统，用于存储所接收的项目管理配置和交易项目工作数据；以及
服务器，连接到所述界面并且连接到所述数据库系统；以及
其特征在于所述服务器适合于判断与预定完成日期不一致的交易项目工作数据的采购定单交付数据；
响应于所述判断，利用交易项目工作数据和项目管理配置来产生项目风险通信会话；以及
处理项目风险通信包响应。
61. 一种项目工作管理制品，所述制品包括
至少一个计算机可读介质；
包含在至少一个计算机可读介质上的处理器指令，所述处理器指令被配置成可以通过至少一个处理器从至少一个计算机可读介质中读取，并借此使得至少一个处理器以进行下述操作
从买方那里接收项目管理配置；
存储与要由供应商执行的买方的项目工作有关的交易项目工作数据；
从买方那里接收项目工作报表记录的配置；
处理买方的计划/范围记录集合中的项目变更
处理供应商的计划/范围记录集合中的项目变更；以及
利用买方的记录集合和供应商的记录集合来创建集成的计划/范围记录集合中的项目变更。
全文摘要
一种项目工作管理方法，包括从买方接收项目管理配置、存储与要由供应商为买方所执行的项目工作有关的交易项目工作数据、从买方接收项目工作报表记录的配置、处理买方的计划/范围记录集合中的项目变更、处理供应商的计划/范围记录集合中的项目变更、以及利用买方的记录集合和供应商的记录集合来创建集成的计划/范围记录集合中的项目变更。
文档编号G06Q10/00GK101283317SQ200680000937
公开日2008年10月8日 申请日期2006年2月10日 优先权日2005年2月11日
发明者A·A·库伦三世, 史蒂文·A·肖, L·齐尔伯曼 申请人:伏特资讯科学公司