CN1659568A - 用于项目投标和申请过程的系统和方法 - Google Patents

Abstract

提供了一种用于产生与项目投标管理系统有关的分析数据的、全面的、web使能的计算机系统和方法。与投标和项目有关的事务数据通过在线投标、项目申请和付费过程输入到计算机系统。通过使用被存储在系统内的事务数据，实际上可以生成用于一个或多个买主的、与由一个或多个销售商执行的单个或多个项目有关的、任何类型的分析数据。

Description

用于项目投标和申请过程的系统和方法

              相关专利申请的交叉参考

本美国非临时专利申请是要求2002年4月10日提交的美国临时专利申请序列号No.60/371,488(代理人档案号No.57084-00532USPL)的权益的、2002年9月30日提交的美国非临时专利申请序列号No.10/262,487(代理人档案号No.57084-00532USPT)的部分继续申请。本美国非临时专利申请还主张美国临时专利申请序列号No.60/371,488(代理人档案号No.57084-00532USPL)的提交日的权益。美国临时专利申请序列号No.60/371,488和美国非临时专利申请序列号No.10/262,487整体在此引用，以供参考。

                       发明背景

发明技术领域

本发明涉及用于电子地简化各项目的所有方面的计算机系统和方法，这包括投标(bid)过程、申请(requisition)过程、花费(spend)过程、和执行管理过程，具体地，涉及电子地管理和分析项目的所有的方面。

相关技术描述

公司、商户和其他类型的企业通常利用第三方提供者(销售商)处理各种商业功能，诸如提供货物或服务。典型地，这些外部来源的商业功能是在买主与销售商之间的“项目”、“人员辅助”、或“咨询”(此后合称为“项目工作”)的协定下执行的。项目工作中牵涉的各种任务，诸如销售商参加、项目行政管理、资源管理和项目费用计算，可以是非常复杂的，需要聚集多个买主组织部门，诸如购买、财务、操作、法律、人力资源、安全和项目管理组织。

由于项目工作的复杂性，利用多系统和过程来实施项目工作的管理已成为今天商业环境中的标准。例如，典型地，分开的系统和过程被使用于项目工作的一个或多个方面，诸如销售商资质、投标征求、投标应答、投标评估、合同行政管理、主要管理点/可交付的行政管理、支付凭证和质量控制。当前，存在有在线“投标”和“拍卖”系统，用于处理投标征求和投标应答过程；项目管理跟踪系统，用于提供主要管理点/可交付的行政管理过程；和财务处理系统，用于行政管理支付凭证过程。然而，还没有用于管理项目工作的所有方面的单个系统。

                    发明概要

为了克服现有技术的缺点，本发明的实施例提供一种用于便利和管理项目投标管理系统中项目工作的所有方面的、全面的、web使能的计算机系统和方法。在本发明的实施例中，计算机系统和方法能够产生与项目投标管理系统有关的分析数据。与投标和项目有关的事务数据通过在线投标和项目申请过程被输入到计算机系统。通过使用被存储在系统内的事务数据，实际上可以生成与由一个或多个销售商为一个或多个买主执行的单个或多个项目有关的任何类型的分析数据。

在一个实施例中，分析数据可包括与多个项目、多个销售商和/或多个买主有关的聚集的事务数据。在其他实施例中，分析数据可包括作为事务数据的函数计算的统计数据。如果分析数据是从与多个买主有关的事务数据生成的，则事务数据被存储在中心数据库，中心数据库被配置成接收被存储在买主、销售商或管理机构的数据库系统内的至少一部分个体的事务数据。

在示例性实施例中，事务数据包括在在线投标过程期间输入到投标的数据区的至少投标数据。事务数据还可包括标识与投标有关的项目的一个或多个合同条款的项目跟踪参数以及与由销售商执行该项目有关的项目执行数据。项目跟踪参数还可包括标识该项目的可纳税成分和与每个可纳税成分有关的纳税量的纳税信息。在其他实施例中，事务数据还可包括由买主和销售商输入到与在工程项目执行期间的投标和项目有关的数据域的凭证信息。

在再一个示例性实施例中，分析数据可以根据请求的类型和作为请求的部分所包括的信息，从事务数据被生成。例如，请求可包括与销售商资料性质、买主资料性质、工程项目资料性质和/或商品资料性质有关的一个或多个过滤器。事务数据可以通过使用所包括的过滤器被过滤，以及过滤的事务数据可被使用来生成分析数据。分析数据可以以项目报告视图通过网页呈现给被授权的用户。

                      附图简述

下面参照附图描述本发明，图上显示本发明的重要的样本实施例，以及附图在本说明书中被引用，以供参考，其中：

图1是在本发明中牵涉的项目工作投标过程的高级别功能图；

图2A是本发明的计算机系统的网络图；

图2B是在买主网络实施的本发明的计算机系统的另一个网络图；

图3A和3B显示本发明的计算机系统的物理网络结构；

图4A-4D是与图2A和2B所示的每个用户模块有关的示例性主网页；

图5是显示按照本发明的实施例的、用于参加项目工作投标过程的示例性步骤的流程图；

图6是显示按照本发明的实施例的、用于规定销售商提供和/或买主需要的项目工作类型和为买主考核(qualify)销售商资格的、销售商资格考核过程的电子设施。

图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是显示按照本发明的实施例的、根据销售商投标应答分级进行销售商重新报价(re-quote)过程的流程图；

图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是显示示例性项目报告视图的屏幕快照，每个包含分析数据。

               示例性实施例详细描述

下面具体参照示例性实施例描述本申请的多个创新的教导。然而，应当看到，这些实施例在这里只提供创新的教导的许多有利的使用的几个例子。通常，在本申请的说明书中作出的陈述不一定限定任何的各个要求权利的发明。而且，某些陈述可应用于某些本发明的特性，但不可应用于其他特性。

按照本发明的实施例，销售商是货物和/或业务的任何提供者，买主是货物和/或业务的任何购买者，承包商是被销售商雇佣用于项目工作的资源以及管理机构是第三方系统管理机构或买主雇佣的项目管理机构。买主可以通过使用从预先建立的、与项目类型有关的投标条目列表生成的投标请求，对于以由买主规定形式的特定货物和/或业务(此后称为项目)，向销售商征求投标。所以，由销售商提交的投标应答都具有相同的形式，使得能够经济地和有效地评估投标应答。本发明的实施例还把投标过程与项目管理相组合，使得买主、销售商、承包商、和管理机构能够在投标被发包发包后跟踪项目的进行。

图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所示。用户经由web浏览器20通过数据网40进入计算机系统100。用户5包括与销售商10、买主50、管理机构80(例如，第三方或买主雇佣的管理机构)或被指配给项目的承包商15有关的任何人。作为例子，但不是限制，数据网40可以是互联网或内部网。以及web浏览器20可以是任何可提供的web浏览器或提供接入到数据网40的任何类型的互联网业务提供商(ISP)连接。销售商用户5通过销售商浏览器20b接入计算机系统，买主用户5通过买主浏览器20a接入计算机系统，承包商用户5经由承包商浏览器20c接入计算机系统，以及管理机构用户5通过行政管理浏览器20d接入计算机系统。用户5通过能够把网页分别推送到买主浏览器20a、销售商浏览器20b、承包商浏览器20c、和管理机构浏览器20d的web服务器120或125接入计算机系统100。

投标web服务器20使得销售商10、买主50、承包商15和管理机构80能够接口到数据库系统150，以维护与销售商10、买主50、承包商15和管理机构80有关的数据。与销售商10、买主50、承包商15和管理机构80有关的数据可被存储在单个数据库155中、在多个共享的数据库155中、或出于安全和方便的目的，被存储在数据库服务器150内的分开的数据库155中，后者将被说明。例如，数据库系统150可以分布在一个或多个位置，这取决于销售商10、买主50、管理机构80、和承包商15的位置和偏爱。

到销售商用户5的用户接口由投标web服务器120通过销售商模块115提供。例如，销售商模块115可以通过使用被存储在特定销售商数据库155b中的数据来填充被推送到销售商浏览器20b的网页。到买主用户5的用户接口由投标web服务器120通过买主模块110被提供。例如，买主模块110可以通过使用被存储在特定买主数据库155a中的数据来填充被推送到买主浏览器20a的网页。到承包商用户5的用户接口由投标web服务器120通过承包商模块130被提供。例如，承包商模块130可以通过使用被存储在特定承包商数据库155c中的数据来填充被推送到承包商浏览器20c的网页。到管理机构用户5的用户接口由投标web服务器120通过管理机构模块135被提供。例如，管理机构模块135可以通过使用被存储在特定销售商数据库155d中的数据来填充被推送到销售商浏览器20d的网页。应当指出，销售商模块115、买主模块110、承包商模块130和管理机构模块135，每个模块可包括对于执行销售商模块115、买主模块110、承包商模块130和管理机构模块135的功能所需要的硬件、软件和/或固件，以及可被实施为投标web服务器120的一部分，或在附加服务器(未示出)内被实施。

计算机系统100还通过行政管理web服务器125提供到管理机构用户5的附加用户接口。行政管理web服务器125使得管理机构80能够接口到最高级别数据库160，维护有关向计算机系统100登记的销售商10、买主50和承包商15的数据。例如，最高级别数据库160可维护销售商考核数据162、买主规定的销售商准则数据164、和承包商重新部署数据166。

为了接入与销售商10有关的信息，行政管理web服务器125使用销售商模块145，使网页推送到与销售商10有关的行政管理浏览器20d。例如，销售商模块145可以接入销售商资格信息162以便为特定的买主50或为特定的行业考核销售商10。同样地，行政管理web服务器125可以通过买主模块140使网页推送到与买主规定的销售商准则信息164有关的行政管理浏览器20d，以便为特定的买主50考核销售商10。承包商模块148使得管理机构80能够接入由承包商15通过投标服务器120输入的承包商重新部署数据166以及从承包商数据库155取回到最高级别数据库160。重新部署数据166例如可包括承包商的移动性、想要的地理区域、承包商技术、想要的付费的指示和可被使用来帮助管理机构80为买主50考核销售商10的其他承包商信息。

在另一个实施例中，如图2B所示，计算机系统100可以仅仅在买主网络处被实施。在图2B上，销售商用户5经由数据网40通过销售商浏览器20b进入计算机系统100，如图2A所示。然而，图2B中web服务器120是由单个买主控制和操纵的买主web服务器。数据库系统150只存储与特定买主有关的买主数据和只存储有关该特定买主的销售商、承包商和管理机构数据。例如，仅仅用于被买主考核的那些销售商的销售商考核数据被存储在数据库系统150。

现在参照图3A，图上显示用于实施计算机系统100的示例性物理网络设备。销售商用户、买主用户、承包商用户、或管理机构用户通过分别把计算机60a、60b、60c、或60d连接到数据网40，而接入计算机系统100的web服务器120。每个计算机60a-60d例如可以是个人计算机、膝上型电脑、被连接到无线设备用于远程接入数据网的计算机、提供能够接入数据网的web浏览器的手持无线设备，或实施web浏览器的其他类型的机器。web服务器120例如可以是微软互联网信息业务(IIS)服务器。web服务器120取决于用户的类型而连接到适当的数据库系统150。数据库系统150例如可以在一个或多个SQL服务器中被实施。

现在转到图3B，图上显示在计算机系统100的物理网络设备中实施的示例性功能。用户计算机60可以通过使用位于计算机的贮存媒体64内的web浏览器66，接入数据网40。例如，贮存媒体可以是硬盘驱动、随机存取存储器(RAM)、只读存储器(ROM)、紧凑盘、软盘、磁带驱动或任何其他类型的贮存媒体。在计算机60内的处理器62(例如，微处理器或微控制器)装载和运行web浏览器66以接入数据网40。

在把web服务器120的统一资源定位器(URL)输入到计算机后，创建在计算机60与web服务器120之间的连接。web服务器120使网页61推送到计算机60，供用户在用户接口设备65上观看。在一个实施例中，用户接口设备65是被连接到计算机60的计算机屏幕15。例如，一旦用户被验证(例如，通过输入用户名字和密码)，用户就可观看在计算机屏幕65上的一个或多个网页61，每个包含对于用户输入各种信息到计算机系统100的提示。用户可以经由I/O接口68和任何类型的输入设备70，诸如，例如鼠标、键盘、光笔、触摸屏(未示出)或话音识别软件(未示出)，输入信息到计算机60，用于经由数据网40传输到web服务器120。

在web服务器120处，处理器(例如，微处理器或微控制器)装载和执行位于被存储在贮存媒体124内的软件模块128中的计算机指令，贮存媒体可以是任何类型的贮存媒体，正如以上结合贮存媒体64讨论的。计算机指令可以通过使用任何类型的编程技术被创建，包括面向对象的编程技术。例如，软件模块128可以包含用于销售商模块、买主模块、承包商模块和行政管理模块的计算机指令(图2A和2B上显示的)，用于填充分别用于销售商用户、买主用户、承包商用户和行政管理用户的网页61。根据计算机用户登录到web服务器120，处理器122接入适当的软件模块128，确定与计算机用户有关的数据库系统150以及检索与计算机用户有关的数据来在网页61中填充，以便在计算机60的计算机屏幕65上显示。另外，软件模块128还可被配置成把从计算机用户接收的数据存储在数据库系统150内。

显示给买主用户、销售商用户、承包商用户和行政管理用户的网页61的例子分别显示于图4A-4D。图4A显示在买主用户登录和鉴权(例如，询问和应答鉴权)后，被显示给买主用户的样本的买主主页61a。正如图4A上可以看到的，在买主的主页61a上有多个系统特性可提供给买主用户。例如，买主用户可被提供以链接来更新在系统中的他们的个人资料、创建RFP/RFQ(此后称为投标请求)、行政管理当前的投标请求、批准销售商投标应答，把投标(项目)发包发包给特定的销售商、处理当前的项目、观看直方图投标请求或接入凭证处理系统以观看有关各种项目的事件跟踪请求，诸如承包商时间卡。买主用户还可保持有关系统修正的更新，接收关于如何通过系统操练的指令，和联系系统管理机构(例如，第三方管理机构或买主雇佣的管理机构)以便通过买主的主页61a帮助。

在图4A上，买主用户还在主页61a上提供待决的投标和项目的当前状态。然而，应当看到，当前的活动可以显示在以后的网页上，而不是在主页61a。例如，买主用户可以提供有公开的投标请求(提交的投标请求)的数目和临时保存的投标请求(创建的但尚未提交的投标请求)的数目。通过点击公开的投标请求按钮，买主用户可以被链接到另一个显示公开投标请求列表的网页，有随后的链接到包含实际的公开投标请求网页。所以，从买主主页61a，买主用户可以链接到有关买主用户接入到的投标或项目的任何信息。

图4B显示样本销售商主页61b，包含可提供给销售商用户的多个系统特性。例如，销售商主页61b可以提供更新销售商资料(例如，销售商提供的货物和/或业务的类型)的链接，应答接收的投标请求，处理当前的项目或接入凭证处理系统以观看现有的项目事件完成请求或处理新的项目事件完成请求。在图4B上，销售商用户也提供有待决的投标和项目的当前状态。例如，销售商用户可以确定销售商需要应答的投标请求的数目和销售商尚未完成的临时保存的投标应答的数目。从销售商主页61b，销售商用户可以链接到附加网页，以完成销售商投标应答或接入新接收的投标请求以开始销售商投标应答。

图4C显示样本承包商主页61c，包含可提供给承包商的多个系统特性。例如，在承包商用户第一次进入承包商主页61c时，承包商用户可以在接入系统中任何其他信息之前被引导到同意各种非雇员工人协定。每个非雇员工人协定可以显示给承包商用户，以及承包商用户可以被提示去同意或否则在继续进行之前接受协定的事项。一旦承包商用户完成所有的协定，承包商用户就可接入计时系统以输入承包商时间，更新他们的技艺资料，或提供重新部署偏好。另外，与承包商用户有关的当前活动也可以在承包商主页61c上显示给承包商用户，诸如请求的会晤或对于附加项目而安排的会晤的次数。

图4D显示样本管理机构主页61d，包含可提供给管理机构用户的多个系统特性。例如，管理机构用户可以接入有关买主、销售商或承包商的信息，链接到包含需要被批准的投标请求的网页，批准投标应答以把标权发包发包给特定的销售商，处理当前的项目或接入凭证处理系统以观看现有的销售商/承包商对于项目活动批准的请求，诸如承包商时间卡。另外，管理机构用户的当前活动也可以显示在管理机构主页61d上。例如，等待批准的投标请求数目、新的投标请求的数目和新的销售商应答的数目可被显示给管理机构用户。从管理机构主页61d，管理机构用户可以链接到有关管理机构用户接入的投标过程或项目管理的任何信息。例如，如果管理机构用户是第三方管理机构，则管理机构用户可以接入到被登记到该系统的所有买主和销售商的投标和项目。然而，如果管理机构用户是买主雇佣的管理机构，则管理机构用户只可以接入到与特定的买主有关的投标和项目。

由本发明的项目投标管理系统处理的投标/项目过程500中的示例性步骤被显示于图5。在任何投标请求被提交之前，投标/项目过程中有几个方面要处理(步骤505)。例如，在投标征求期间为了减小处理的时间，买主可能想要对特定的投标请求类型创建合格的销售商清单，正如下面结合图6和7更详细地描述的。作为另一个例子，买主、销售商和管理机构可能想要指定具体的个人来处理投标/项目过程的不同的分量，以便在投标/项目过程期间有效地路由消息和信息，正如下面结合图8-14更详细地描述的。

一旦所有的预投标活动都完成(步骤510)，买主便可以创建对于项目的投标请求(步骤520)，正如下面结合图15-29更详细地描述的，以及如有必要，提交投标请求给管理机构以得到批准(步骤525)，正如下面结合图20更详细地描述的。大多数公司需要对于预算目的的投标请求的批准。然而，如果买主是个人或小的商业机构，买主用户创建投标请求可能不需要从任何其他方得到提交投标请求的批准。

一旦投标请求被批准，投标请求就被广播(例如，经由系统以通过电子邮件的可选通知方式使销售商可得到的)到合格的销售商(步骤530)，正如下面结合图23更详细地描述的，以征求来自销售商的投标应答(步骤535)。每个投标应答被买主评标，正如下面结合图32和33更详细地描述的，以确定哪个销售商投标应答是最合格的(步骤540)。在买主为项目选择特定的销售商后，买主和销售商协商合同的最后条款和条件(步骤545)，这些条款和条件可被装载到系统用于项目跟踪目的(步骤550)，正如下面结合图37更详细地描述的。此后，销售商选择用于项目的特定的资源(承包商)，以及如果项目的条款需要买主批准资源，则买主在项目接着进行之前批准所有指配的资源(步骤555)，正如下面结合图38更详细地描述的。

一旦所有的投标活动完成后(步骤515)，系统还能够处理后投标活动(步骤560)，在项目过程期间跟踪项目的进行和凭证的支付。例如，被指配给该项目的销售商和承包商可以把工作的时间和花费输入到系统(步骤565)，用于生成可支付的凭证，以通过系统提交给买主，正如下面结合图43更详细地描述的。在接收凭证后，买主和/或管理机构可以审阅和批准用于支付给销售商的凭证(步骤570和575)，正如下面结合图49更详细地描述的。其他项目跟踪参数也可以输入到系统，以便通过项目附表跟踪销售商的进展(步骤580)，正如下面结合图39和40更详细地描述的。下面将分开地讨论投标/项目过程的每个主要的部分(预投标活动、投标活动和后投标活动)。另外，下面将分开地讨论在投标/项目过程期间收集的数据的分析和报告。

预投标活动

正如以上讨论的，买主50可能要预先考核用于特定的项目类型的销售商10，以减小对于提交的每个投标请求所需要的处理量。现在参照图6，为了便于由买主进行销售商考核，计算机系统100可以使得买主50能够为销售商建立买主规定的销售商准则数据164，以及把买主规定的销售商准则数据164存储在最高级别数据库160中的主买主列表161内。计算机系统100还可以从销售商10获取相关的销售商考核数据162，以及把销售商考核数据162存储在最高级别数据库160中的主销售商列表163内。

例如，销售商考核数据162可以识别销售商10提供的特定的货物和/或业务以及销售商10能够提供这些货物和/或业务的具体的地理区域，连同其他销售商信息，诸如销售商规模、销售商是否有保险、销售商在一定的行业中是否有合格证明等等。买主规定的销售商准则数据164可以识别买主50想要的特定的货物和/或业务、买主50想要货物和/或业务的具体的地理区域以及其他买主约束条件，诸如销售商的优选的规模、销售商保险需要的必要条件、必不可少的销售商合格证书等等。

根据销售商考核数据162和买主规定的销售商准则数据164，计算机系统100可以确定哪些销售商10具有对于买主50的必要的资格和提供合格的销售商信息170(例如，名字、地址和买主需要的任何其他销售商信息)给买主50，以便审阅。如果买主50或任选地管理机构80批准销售商10，则买主50可以把销售商信息170加到销售商列表158中，该表存储在买主数据库155a中。另外，对于买主以前考核过的那些销售商10的销售商信息172也可被存储在销售商列表158中。而且，销售商列表158的主拷贝(即，用于买主的主销售商列表165)可被存储在最高级别数据库160中，以供冗余度和更新目的。

买主信息174(例如，名字、地址和买主同意提供的其他信息)也可被下载到销售商数据库155b，以便存储在其中的买主列表159中。另外，买主列表159的主拷贝(即，用于销售商的主买主列表167)可被存储在最高级别数据库160中，以供冗余度和更新目的。然而，应当看到，如果计算机系统100只被实施在买主网络处，则最高级别数据库160不存储主拷贝165和167，以及买主50只使用对于买主50已知的、或由销售商10直接提供给买主50的销售商信息172来执行销售商考核。对于由买主50根据销售商考核数据162和买主规定的销售商准则数据164来考核销售商10的完全的讨论，可以参考共同待决的和共同转让的美国专利申请序列号10/141,801，该专利申请在此整体地引用，以供参考。

用于由买主考核销售商的示例性步骤显示于图7。一旦买主规定的销售商准则信息被建立(步骤700)以及从销售商接收到销售商资格信息(步骤710)，就把买主规定的销售商准则信息与销售商资格信息进行比较(步骤720)，以确定销售商资格信息是否与买主规定的销售商准则信息相匹配(步骤730)。如果是的话，则告知销售商和买主：二者匹配(步骤740)，以及如果买主批准该销售商，则与销售商有关的销售商信息被存储到买主的销售商列表中，供以后在准备投标请求时使用(步骤750)。另外，买主信息可被存储在销售商的买主列表中，供在接收投标请求和准备投标应答时参考(步骤760)。

然而，如果销售商资格信息与买主规定的销售商准则信息不匹配(步骤730)，则系统确定是否需要附加的销售商资格信息，以由买主考核销售商(步骤770)。如果是的话，则请求销售商提供这个附加销售商资格信息(步骤780)以便由买主考核销售商(步骤710)。如果不是的话，则销售商对于买主是不合格的(步骤790)以及不把销售商加到买主列表中。

除了为买主考核销售商以外，销售商、买主和管理机构可能想要指定某个个人处理投标/项目过程的各个方面，以便同步跨多个用户平台的通信、数据和事务处理。例如，现在参考图8，投标/项目过程典型地需要包括信息处理和功能部门的宽的谱，以方便投标/项目过程的行政管理和管理。这样的信息处理例如可包括投标请求广播、销售商投标应答、投标部署(评标和发包)、资源提交、时间卡提交、可交付跟踪和付费凭证。这些信息处理部分的每个可以由一个或多个不同的个人或部门(诸如COO，人力资源部，项目用户和财务处理器)来处理。为了满足这个功能需要，本发明的计算机系统可以使能一个共享的工作环境，其中买主、销售商和/或管理机构可以规定需要参加投标/项目过程的多个常规用户角色以及指定个人(资源)到每个用户角色，用于所有的投标/项目或用于特定的投标/项目。

现在参照图9，图上显示用于规定用户角色位置和指定个人到用于销售商、买主或管理机构的用户角色位置的示例性步骤。初始地，销售商、买主或管理机构确定对于投标/项目过程需要的特定的用户角色位置(步骤900)。例如，正如图11的样本买主网页中显示的，买主可确定需要几个不同的用户角色类别，诸如财务批准者、非财务批准者、时间卡审阅者、行政管理代表、项目主要管理点管理机构、财务协调员以及在投标/项目过程期间的人力资源伙伴。销售商、买主或管理机构还可确定，对于投标/项目过程需要一个或多个用户角色类别内的多个用户角色位置。例如，如图11所示，买主可以确定，需要六个财务批准者和两个非财务批准者。

再次参照图9，一旦用户角色位置被确定，用于销售商、买主或管理机构的相关的个人的数据文件被存储，供对于每个用户角色位置选择适当的个人时使用(步骤905)。销售商、买主或管理机构的一个或多个关键的个人(例如，COO、项目用户等)可被选择来指定要被指配到每个用户角色位置的具体的个人(步骤910)，或替换地，系统可以根据被包含在个人数据文件中的信息指配个人到用户角色位置。在某些公司中，用户角色位置被预先指定(步骤915)，以及在这种情形下，预先指定的个人可被装载到系统(步骤920)以及被存储在用户角色表格中(步骤925)。例如，对于大多数销售商，个人被预先指配到用于所有的项目的各种用户角色位置。在其他公司中，完全没有预先指定，或对于特定的项目没有预先指定一个或多个用户角色位置(步骤915)，以及在这种情形下，所选择的关键的个人或系统可以指配具体的个人到用户角色位置。

为了指配具体的个人到用户角色位置，选择具体的用户角色位置(步骤930)，以及根据用户角色约束条件，从个人数据文件确定可被指配到该用户角色位置的个人的列表(步骤935，940和945)。例如，如果用户角色位置需要特定级别的用户，则只有处在特定的用户级别或更高级别的那些个人才被包括在该列表中，从用于用户角色位置的个人的列表中，选择一个个人用于特定的用户角色位置(步骤950)，以及所选择的个人被存储在用户角色表格中(步骤925)。例如，如图11所示，在选择特定的用户角色位置后(例如，点击用户角色位置)，系统可以搜索合格的个人用于用户角色位置，以及在作出选择后，可以显示用于用户角色位置的、所选择的个人。

下面在表1-9上显示用于为买主选择和指配用户角色位置的数据结构的例子。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于为买主选择和指配用户角色位置所必须的所有的域。表格以分级结构和/或关联的方式相关，这样，对于用户角色位置的所有必要的信息可被精确地存储和访问，正如下面结合图10的示例性数据库表格结构300描述的。然而，应当看到，也可以包括其他买主用户角色结构，以及系统不限于在表1-9或图10上列出的具体的买主用户角色结构。

下面的表1和2分别显示样本的用户角色类别和在每个用户角色类别内的用户角色位置，它们可被分别存储在数据库内表格“tblHMPosition Categories”305和“tblHMPositions”306中，如图10所示。在表1中，每个用户角色类别被指配一个识别号和用于显示在网页上的一个显示次序。用户角色类别识别号在用户角色位置表(表2)内被使用来把用户角色位置与具体的用户角色类别相关。然而，应当看到，根据买主的需要，可以有多个附加的类别和位置。当初始选择用户角色位置时，用户角色类别可以用与每个类别内的具体的用户角色位置的链接来被显示以供用户从中选择。在对于特定的买主已经选择所有的用户角色位置后，所选择的用户角色位置和指配的个人可以是如图11所显示的。

                                           表1

                        示例性用户角色类别(tblHMPositionCategories)

Position_Category_ID	Position_Category_Name	ASP_Category_Display_Order
			1	Financial_Approvers	1
2	Non-Financial_Approvers	2
			3	Timecard_Reviewers	3
4	Administrative_Delegates	4
			5	Project_Milistone_Administrators	5
6	Financial_Coordinators	6
			7	Human_Resource_Partners	7
8	Security_Partners	8
			9	Regulatory_Compliance_Partners	9

                                      表2

                      示例性用户角色位置(tblHMPositions)

Position_ID	Position_Name	Position_Category_ID
			1	MA_Financial_Approval_Level	1
2	MB_Financial_Approval_Level	1
			3	MC_Financial_Approval_Level	1
4	MD_Financial_Approval_Level	1
			5	ME_Financial_Approval_Level	1
6	MF_Financial_Approval_Level	1
			7	Non_Financial_Approver_1	2
8	Non-Financial_Approver_2	2
			9	Timecard_Reviewer_1	3
10	Timecard_Reviewer_2	3
			11	Administrative_Delegate_1	4
12	Administrative_Delegate_2	5
			13	Project_Milestone_Administrator_1	5
14	Project_Milestone_Administrator_2	5
			15	Financial_Coordinator_1	6
16	Financial_Coordinator_2	6
			17	Human_Resource_Partner_1	7
18	Human_Resource_Partner_2	7
			19	Project_Bid_Originator	4
20	Security_Administrator	8
			21	Regulatory_Compliance_Administrator	9

下面的表3显示被存储在用于系统的每个用户的个人数据文件内的样本数据，它们可被存储在数据库内表格“tblUser”302中，如图10所示。从这个用户数据，可以确定用于每个用户角色位置的合格的个人，以及可以查明对于每个用户角色位置的每个指配的用户的必须的信息。表3内的一个域是指配给特定的用户的商业等级。该商业等级表示用户在商业系统中的具体的级别。例如，用户可以是级别3的用户，以及这个信息被存储在用户表中。可提供的商业等级可以映射到用户角色位置，如下面的表4和5所示，表示对于被指配到每个用户角色位置的用户所需要的商业等级，它们可被存储在数据库内表格“tblHMBusinessGrades”303和“tblHMPositiontoGradeMap”304中，如图10所示。

                       表3

                 基本系统用户表(tblUser)

列	数据类型	长度
			User_ID	int	4
Employee_ID	nvarchar	10
			First_Name	nvarchar	50
Last_Name	nvarchar	50
			Last_Name_2nd	nvarchar	50
Middle_Name	nvarchar	10
			SSN	nvarchar	50
Business_Title_Description	nvarchar	50
			Business_Grade_Code	nvarchar	10
Business_Grade_Description	nvarchar	50
			Financial_Approval_Level	int	4
Birthdate	datetime	8
			Business_Unit_Name	nvarchar	100
[Dept/Cost_Center]	nvarchar	10
			Dept_Name	nvarchar	50
Work_Location_Code	numeric	9
			Location_Type	nvarchar	50
Location_Address1	nvarchar	50
			Location_Address2	nvarchar	50
Location_City	nvarchar	50
			Location_State	nvarchar	50
Location_Country	nvarchar	50
			Location_Zip	nvarchar	4
Country_ID	int	4
			Work_Phone_Number	nvarchar	50
Fax_Number	nvarchar	50
			[E-Mail]	nvarchar	50
User_Name	nvarchar	50
			Password	nvarchar	50
Active	bit	1
			Last_Logged_In	datetime	8
Date_Updated	datetime	8
			US_Date_Format	bit	1
Currency_ID	int	4

                          表4

       基本商业等级表(tblHMBusinessGrades)

列名称	数据类型	长度
			Business_Grade_Code	nvarchar	10
Business_Grade_Description	nvarchar	50

                       表5

用户角色到商业等级映射表(tblHMPositiontoGradeMap)

列名称	数据类型	长度
			Position_ID	int	4
Business_Grade_Code	nvarchar	10
			Record_ID	int	4

下面结合图10更详细地描述下面的表6-9

                       表6

位置/角色到投标模板映射表(tblHMPositionsRFXMatrix)

列名称	数据类型	长度
			Position_ID	int	4
RFX_Template_ID	int	4
			Position_Required	char	1

                表7

缺省用户角色映射表(tblHMPositionsRelationships)

列名称	数据类型	长度
			User_ID	int	4
Position_ID	int	4
			Relation_ID	int	4
Identifier	int	4

                    表8

用户角色到投标请求映射表(tblBidHMPositions)

列名称	数据类型	长度
			Bid_Tracking_ID	int	4
User_ID	int	4
			Position_ID	int	4
Relation_ID	int	4
			Current_Status_ID	int	4
Record_ID	int	4

                        表9

 用户位置/角色到批准级别与分级结构映射(tblApprovalLevel)

列名称	数据类型	长度
			Position_ID	int	4
[Approval_Authority]	money	8
			Approval_Routing_Order	numeric	9
Record_ID	int	4

正如在图10上可以看到的，在使能可配置的工作共享和用于买主的具体工作流程部分所必须的所有的域之间有简明的关系。数据库结构300是可缩放的和可配置的，这样，即使当在不太精巧的数据库环境内运行时，只要规定用户角色位置以及个人数据文件是可提供的，功能就仍旧存在。应当看到，类似的数据库表格结构对于销售商和管理机构是可提供的，这将在下面更详细地讨论。

用于买主的数据库表格结构300把来自买主的个人数据(“tblHRdata”301)视为输入，以及创建个人数据文件(“tblUser”302)，包括可能在共享的工作环境中牵涉到的具体的个人。为了简化起见，个人数据被显示为表格“tblHRdata”301。然而，应当看到，个人数据可以具有任何形式，取决于买主数据库系统。可以进行从表格“tblHRdata”301到“tblUser”302的周期下载，来就买主的当前雇员去更新系统，以便保证用户角色位置被适当地指配。由买主指定的各种商业等级也可被存储在表格“tblHMBusinessGrades”303中和映射到表格“tblUser”302，用于商业等级的个人指配，正如以上结合表3和4讨论的。另外，商业等级可被映射到表格“tblHMPositiontoGrade”304中该选择的用户角色，正如以上结合表4和5讨论的。

用户角色类别表(“tblHMPositionCategories”305)和用户角色位置表(“tblHMPositions”306)，以及它们与位置等级和指配的个人的关系也显示于图10。例如，表格“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

      用户角色到网页接入映射表

列名称	数据类型	长度
			ASP_Obiect_ID	int	4
Position_ID	int	4
			Read_Access	char	1
Write_Access	char	1
			Record_ID	int	4

为了保持在用户角色位置、内部的个人与采取正在进行方式的具体事务之间的关系，本发明的系统还被设计成考虑有组织个人的移位以及个人的商业级别和用户权限。现在参照图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)

VendorContactTypeID	说明	ASP显示次序
			1	CEO	1
2	CFO	2
			3	COO	3
4	财经处理监控人员	6
			5	雇用人员	7
6	会计用户	5
			7	项目用户	8
8	总审计师	4

                      表12

        示例性销售商联络(tblVendorContacts)

列名称	数据类型	长度
			VendorContactID	int	4
vcVendorContactGUID	uniqueidentifier	16
			vcPermissionLevel	int	4
vcContactTypeID	int	4
			vcFirstName	varchar	50
vcLastName	varchar	50
			vcPositionTitle	varchar	100
vcSalutation	varchar	50
			vcAddress1	varchar	50
vcAddress2	varchar	50
			vcCity	varchar	50
vcState	varchar	50
			vcCountryID	varchar	50
vcPostalCode	varchar	20
			vcEmail	varchar	50
vcVendorID	int	4
			vcLoginName	varchar	50
vcPassword	varchar	50
			vcStatusID	int	4
vcDateExpire	datetime	8
			vcInternationalFlag	varchar	50

                      表13

  示例性销售商角色许可(tblVendorRolePermissions)

列名称	数据类型	长度
			ASP_Object_ID	int	4
VendorContactTypeID	int	4
			Write_Access	char	1
Read_Access	char	1
			Current_Status_ID	int	4
Record_ID	int	4

对于管理机构，用户角色位置可被规定，以使得能够规定整个处理队伍和队伍成员，以便行政管理与规定的投标类型有关的、和对于规定的位置的事务活动。现在参照图13A-13B，图上显示用于实施行政管理处理队伍的示例性步骤。一开始，建立用于管理机构的行政管理用户表，包含行政管理用户主数据(步骤1300)。从用户表，各种用户可被分配给一个或多个用户组以及用户到用户组的映射可被存储在用户组映射表(步骤1305)。用户组可以与公司内的商业单位或事务类型或二者相联系。对于每个用户组，在用户组内每个用户的功能性权利和责任可以在用户组权利表中被规定(步骤1310)。例如，每个用户可被分配以对于用户组的接入权利(正如以上结合图10讨论的)。实施用户组和用户权利的数据结构的例子显示于下面的表14-19。然而，应当看到，也可以包括其他管理机构用户角色结构，以及系统不限于在表14-19中列出的具体的管理机构用户角色结构。

                           表14

                     示例性管理机构用户表

列名称	数据类型	长度
			Administrative_ID	int	4
mLastName	varchar	50
			mFirstName	varchar	50
Middle_Initial	varchar	50
			Job_Title_ID	int	4
mloginName	varchar	10
			mPassword	varchar	10
Permission	varchar	50
			Phone	varchar	50
Fax	varchar	50
			mEmail	varchar	50
Home_Address1	varchar	50
			Home_Address2	varchar	50
City	varchar	50
			State	varchar	50
Zip	varchar	20
			Home_Phone	varchar	50
Mobile_Phone	varchar	50
			Location_ID	int	4
Date_of_Birth	smalldatetime	4
			Social_Security_No	varchar	20
Date_Start_with_Administrator	smalldatetime	4
			Date_Start_with_Buyer	smalldatetime	4
Schooling_ID	int	4
			Technical_Certifications	varchar	50
Primary_Language_ID	int	4
			Secondary_Language_ID	int	4
MS_Excel_Proficiency	int	4
			MS_Access_Proficiency	int	4
MS_Word_Proficiency	int	4
			MS_PowerPoint_Proficiency	int	4
Application Efficiency	int	4
			Communication_Skills_ID	int	4
mActive	char	1
			Supervisor	int	4
Last_Eval_Date	smalldatetime	4
			Next_Eval_Date	smalldatetime	4
Employee_Type_ID	int	4

                          表15

                示例性管理机构用户组表数值

Admin_User_Group_ID	Admin_User_Group_Name
		1	General_Administration
2	Business_Support
		3	Customer_Service
4	Requisition_Transaction_Processors
		5	Staff_Management
6	Staff_Professional
		7	Supplier_Management
8	Systems_Admin
		9	Application_Support
10	Financial_Processors
		12	RFX_Transaction_Processors

                   表16

      示例性管理机构用户到用户组映射表

列名称	数据类型	长度
			Administrative_ID	Int	4
User_Group_ID	Int	4
			Record_ID	int	4
Date_Created	datetime	8
			Creator_ID	int	4
Current_Status_ID	int	4
			Last_Edit_Date	datetime	8
Last_Edited_By	int	4

               表17

      示例性管理机构用户组权利表

列名称	数据类型	长度
			ASP_Page_ID	int	4
User_Group_ID	int	4
			Record_ID	int	4
Read_Access	char	1
			Write_Access	char	1

一旦用户组被查明，如图13B所示，就可在用户组内创建处理队伍来处理具体的事务类型(步骤1315)。在特定的用户组内的所有的用户可被映射到具体的处理队伍以及可被分配以用于特定的事务类型的路由次序(步骤1320)。用于创建和映射用户到处理队伍的示例性数据结构显示于下面的表18和19。

                        表18

             示例性行政管理处理队伍表

列名称	数据类型	长度
			Team_ID	int	4
Team_Name	varchar	50
			Staff_Supplementation	char	1
Project_Work	char	1
			RFX_Processing	char	1
Requisition_Processing	char	1
			Invoice_Processing	Char	1
Help_Desk_Processing	Char	1
			Quality_Assurance_Processing	Char	1
Created_By	Int	4
			Last_Edited_By	Int	4
Last_Edit_Date	Datetime	8
			Current_Status_ID	Int	4

                   表19

    示例性行政管理处理队伍到用户的映射表

列名称	数据类型	长度
			Administrative_ID	Int	4
Team_ID	int	4
			Date_Created	datetime	8
Record_ID	int	4
			Created_By	int	4
Current_Status_ID	int	4
			Last_Edited_By	int	4
Last_Edit_Date	datetime	8

另外，处理队伍可被映射到具体的地理区域，这样，不同的处理队伍可以处理在不同的区域中的相同的类型的事务(步骤1325)。所以，当特定的类型的事务在特定的位置进行时，系统可以根据事务类型和位置来管理到适当的用户的工作流程(步骤1330)。例如，可以通过电子邮件和/或控制板(dashboard)更新而把事务告知适当的用户。

因此，由本发明的系统支持的用户角色管理提供用于从投标创建到项目完成的整个投标/项目过程的、灵活的、可缩放的和鲁棒的工作共享环境。另外，系统使能进行安全的通信和基于用户角色的事务处理，这使得用户能够在正好的时间与正确的用户接口，而同时保证数据观看和接入的权利只限于对于接入有功能性需要的那些用户。

投标活动

在完成预投标活动后，买主可以创建和发送投标请求给一个或多个销售商以征求来自销售商的、对于特定的项目的投标应答。为了在完全的投标/项目过程方面实施投标过程，投标模板可被使用于具体的项目类型，以统一和全面的方式征求来自销售商的、对于特定的项目类型的必须的信息，以便能对于投标应答进行经济的和有效的评估。

用于利用投标模板创建投标请求的示例性功能显示于图15。按照本发明的实施例，投标模板创建工具180和投标请求创建工具185被显示于图15，分别用于创建投标模板240和从投标模板240创建投标请求200。投标模板创建工具180和投标请求创建工具185可以包括对于执行工具的功能所需要的任何硬件、软件和/或固件，以及可以在web服务器120或附加服务器(未示出)内被实施。取决于由买主外部起源的项目工作的性质，每个买主可以创建一个或多个投标模板240。例如，如果买主需要仅仅在一个部门中的人员辅助，则买主可以只创建一个投标模板240来处理人员辅助投标请求200。

为了创建投标模板240，投标模板创建工具180接入买主数据库155a以检索在投标条目列表194内的投标条目230以及经由买主模块110、web服务器120、数据网40和买主浏览器20a给买主提供投标条目列表230，供买主从中进行选择。投标条目230与由买主、销售商或二者要征求的特定的信息类型有关。从投标条目列表230，买主选择和提供一个或多个投标条目选择235，用于包括在投标模板240中。根据买主结构，一个或多个投标条目230对于投标模板240可以是强制性的，诸如买主名字、要被执行的工作的位置和所请求的项目工作的类型。对于一个或多个强制性投标条目230，除了把强制性投标条目230包括在投标模板240中以外，与每个强制性投标条目230有关的特定的信息也可被包括在投标模板240内的、与强制性投标条目230有关的域。例如，买主名字和项目工作类型可被存储在用于该项目工作类型的投标模板240。由买主创建的每个投标模板240被存储在投标模板列表190内的买主数据库155a中，供以后在创建投标请求200时使用。

为了创建投标请求200，投标请求创建工具185接入买主数据库155a以检索被存储在投标模板列表190内的投标模板240，以及经由买主模块110、web服务器120、数据网40和买主浏览器20a给买主提供投标模板列表240，供买主从中进行选择。在选择适当的投标模板240后，买主把投标请求数据210提供到投标请求创建工具185，用于包括在投标模板240类型的投标请求200中。例如，买主可以把投标请求数据210输入到对于每个投标条目选择235提供的域，它需要在投标模板240内的、来自买主的信息。作为例子，但不是限制，投标请求数据210可包括要被执行的工作的位置、项目的时序和对于项目必须的、特定的销售商考核。

投标请求创建工具185还与买主数据库155a接口以接入用于买主的销售商列表158，以及确定适当的销售商来接收投标请求。适当的销售商可以是根据投标模板240类型和被包括在投标请求200本身内的任何其他销售商考核被选择。因此，销售商列表158可被分开成对于投标模板240类型的预先合格的销售商以进一步减小当提交投标请求200时的处理时间。投标请求创建工具185还使用与选择的销售商有关的用户销售商联络信息250，并及经由销售商模块115、web服务器120、数据网40和销售商浏览器20b广播(发送)投标请求200到适当的销售商(如图1和2所示)，以及把提交的投标请求200存储在用于买主的投标请求列表196。

从征求的销售商处(如图1和2所示)接收的销售商投标应答220还可以以投标应答列表198存储在买主数据库155a中，供以后在比较与分级销售商投标应答220时使用。销售商投标应答220是从被包括在投标请求200中的投标条目生成的。具体地，销售商填充与销售商有关的数据和在投标请求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或图17上显示的具体的投标模板结构。

                       表20

         基本投标条目分段表(tblRFXBidSections)

列名称	数据类型	长度
			RFX_Section_ID	Int	4
RFX_Section	Varchar	255
			ASP_Section_Display_Order	Numeric	9
Label_Comments	Varchar	1000

                        表21

       基本投标条目类别表(tblRFXBidCategories)

列名称	数据类型	长度
			RFX_Category_ID	Int	4
RFX_Category	Varchar	255
			RFX_Section_ID	Int	4
ASP_Category_Display_Order	Numeric	9
			Label_Comments	Varchar	1000

                     表22

          基本投标条目表(tblRFXBidItems)

列名称	数据类型	长度
			RFX_Item_ID	Int	4
PFX_Item	Varchar	255
			Disablement_Allowed	Char	1
Supplier_Bid_Display	Char	1
			Supplier_Response_Item	Char	1
RFX_Category_ID	Int	4
			HM_Data_Type	Varchar	255
HM_Field_Length	Varchar	255
			ASP_Item_Display_Order	Numeric	9
AV_Pesponse_Data_Type	Varchar	255
			AV_Field_Length	Varchar	255

                     表23

   基本投标模板类型表(tblRFXBidTemplates)

RFX_Template_ID	RFX_Template
		1	Project_RFP
2	Project_RFQ
		3	Bulk_Staffing_RFQ
4	Regular_Staff_Supplementation

                 表24

基本投标模板到投标条目映射表(tblRFXTemplateItemMatrix)

列名称	数据类型	长度
			RFX_Item_ID	Int	4
RFX_Template_ID	int	4

                 表25

基本客户投标条目缺省值表(tblRFXBidItemsCDV)

列名称	数据类型	长度
			RFX_Item_ID	int	4
Client_Default_Value	varchar	7500

现在参照图17，图上显示说明在每个以上的表20-25之间的相互关系的数据库表结构。为了方便起见，投标条目230被显示为当创建投标模板240时被组织成投标分段和投标类别，用于方便和逻辑的商业信息处理分段。因此，买主用户被呈现以投标分段250，从其中买主用户可选择一个投标类别255以显示与该投标类别255有关的投标条目230。把投标条目230分割成投标类别255和投标分段250，促进形成买主用户容易理解的相互间隔的格式，由此使得能够进行更经济和有效的投标模板创建过程。

表“tblRFXBidSections”401，具有以上的表20的形式，包括投标分段名称和投标条目230的每个分段250的标识，连同在网页上每个投标分段250的显示次序的指示以及在网页上对于投标分段250的要被包括的任何评注。每个投标分段250可以作为分开的记录被存储在表“tblRFXBidSections”401中，每个记录具有表20的格式。在每个投标分段250内，是一个或多个投标类别255。表“tblRFXBidCategories”402，具有以上的表21的格式，包括类别名称和每个投标类别255的标识号，和对于每个投标类别255的相关的投标分段250。另外，表“tblRFXBidCategories”402还包括在网页上对于每个投标类别255的显示次序以及在网页上对于投标类别255的要被包括的任何评注。每个投标类别255可以作为分开的记录被存储在表“tblRFXBidCategories”402，每个记录具有表21的格式。

每个投标类别255还包括与投标类别255有关的一个或多个投标条目230。所以，表“tblRFXBidItems”403，具有以上的表22的格式，包括投标条目名称和标识号，连同与投标条目230有关的投标类别255。对于每个投标条目230的分开的记录可以存储在表“tblRFXBidItems”403，每个记录具有以上表22的格式。表“tblRFXBidItems”403还包括关于投标条目230的附加信息，诸如是否允许投标条目230的禁用、投标条目230是否显示给销售商、投标条目230是否需要销售商应答、对于投标条目230的、由买主输入的数据类型、对于投标条目230的、由买主输入的数据的域长度、对于投标条目230的、由销售商输入的数据的类型、以及对于投标条目230的、由销售商输入的数据的域长度。例如，以下的表26显示组成投标条目列表194的表“tblRFXBidItems”403中的样本投标条目230。

                                                    表26

RFX_Item_ID	RFX_Item	Disablament_Allowed	Vendor_Bid_Display	Vendor_Response_Item	RFX_Category_ID	HM_Data_Type	HM_Field_Longth	Item_Display_Order	AV_Rasponse_Data_Type	AV_Field_Length
											1	Company/Organization_Information	N	Y	N	1	LongText	5000	5
2	Purpose_of_the_RFP	N	Y	N	2	LongText	5000	5
											3	Business_Strategy/Objectives	N	Y	N	3	LongText	5000	5
4	Business_Infrastructure	Y	Y	N	4	LongText	5000	5
											5	Business_Proceses	Y	Y	N	4	LongText	5000	10
6	Business_Systems	Y	Y	N	4	LongText	5000	15
											7	Internal/External_Clients	Y	Y	N	4	LongText	5000	20
8	Affected_Departments	Y	Y	N	4	LongText	5000	25
											9	Project_Ownership/Management_Considerations	N	Y	N	5	LongText	5000	5
10	Product_Ownership/Licensing_Considerations	N	Y	N	5	LongText	5000	10

RFX_Item_ID	RFX_Item	Disablemant_Allowed	Vendor_Bid_Display	Vendor_Response_Item	RFX_Category_ID	HM_Data_Type	HM_Field_Length	Item_Display_Order	AV_Response_Data_Type	AV_Field_Length
											11	Project_Work_Location_Considerations	N	Y	N	5	LongText	5000	15
12	Project_Phasing_Consdierations	Y	Y	N	5	长文本HM到子表的超级链接	5000	20
											13	Project_Phasing_Schedule	Y	Y	N	5	ASP		25
14	Project_Resource_Considerations	Y	Y	N	5	长文本HM到子表的超级链接	5000	30
											15	HM_Staffing_Resource_Profiles	N	Y	N	5	ASP		35
16	Resouroe_Backfill_Considerations/Requirements	N	Y	N	5	Text	1000	40
											17	Project_Resource_Travel_Considerations	N	Y	N	5	Text	1000	45
18	Handling_Of_Project_Resource_Expenses_Considerations	N	Y	N	5	LongText	5000	50
											19	Regulatory/Industry_Standards_Compliance_Considerations	Y	Y	N	5	LongText	5000	55
20	Specific_Equipment/Tooling_Considerations	Y	Y	N	5	LongText	5000	60
											21	Specific_Eoonomic_Considerations	Y	Y	N	5	LongText	5000	5
22	Statement_Of_Work	N	Y	N	6	LongText	5000	5
											23	Non-Deliverable_Penalties	N	Y	N	7	LongText	5000	5
24	Supplier_Incentive_Bonus	Y	Y	N	8	LongText	5000	5
											25	Statement_of_Confidentiality	N	Y	N	9	LongText	5000	5
26	RFP_Organization/Contacts	Y	Y	N	10	LongText	5000	5
											27	RFP_Response_Requirements	N	Y	N	11	LngText	5000	5
28	RFP_Supplier_Issuance_Date	N	Y	N	12	datetime		5
											29	Supplier_Acknowledgment_of_Confidentiality_Date	N	Y	N	12	date time		10
30	Supplier_Acknowledgment_of_Response_Intent_Date	Y	Y	N	12	date time		15
											31	Supplier_Suhmission_of_RFX_Questions_Date	Y	Y	N	12	date time		20
32	Client_Posting_of_Answers_Date	Y	Y	N	12	date time		25

RFX_Item_ID	RFX_Item	Disablement_Allowed	Vcndor_Bid_Display	Vendor_Response_Ietm	RFX_Category_ID	HM_Data_Type	HM_Field_Longth	Item_Display_Order	AV_Response_Data_Type	AV_Field_Length
											33	Supplier_Submission_of_Completed_RFP_Response_Date	N	Y	N	12	date time		30
34	Client_Submission_of_RFP_Response_Questions_Date	Y	Y	N	12	date time		35
											35	Supplier_Posting_of_Answers_Date	Y	Y	N	12	date time		40
36	Client_RFX_Evaluation_Completion_Date	N	Y	N	12	date time		45
											37	Client_Disposition_to_Suppliers_Date	N	Y	N	12	date time		50
38	RFX_Instructions	N	Y	N	13	LongText	5000	5
											39	Company_History	Y	Y	Y	14	Text	1000	5	LongText	5000
40	Competitive_Analysis	Y	Y	Y	14	Text	1000	10	LongText	5000
											41	Product/Services_HeritageReview	Y	Y	Y	14	Text	1000	15	LongText	5000
42	Product/Services_Strategy	Y	Y	Y	14	Text	1000	20	LongText	5000
											43	Technology_Vision	Y	Y	Y	14	Text	1000	25	LongText	5000
44	Strategic_Technology_Partners	Y	Y	Y	14	Text	1000	30	AV到子表ASP的超级链接
											45	Track_Record	Y	Y	Y	14	Text	1000	35	AV到子表ASP的超级链接
46	Project_Management_Philosophy	Y	Y	Y	14	Text	1000	40	LongText	5000
											47	PM_Certified_FTEs	Y	Y	Y	14	Text	1000	45	LongText	5000
48	Customer_Referefces	Y	Y	Y	14	Text	1000	50	AV到子表ASP的超级链接
											49	Proposal_Narrative	N	Y	Y	15	Text	1000	5	LongText	5000

RFX_Item_ID	RFX_Item	Disablement_Allowed	Vendor_Bid_Display	Vendor_Response_Item	RFX_Category_ID	HM_Data_Type	HM_Field_Length	Item_Display_Order	AV_Response_Data_Type	AV_Field_Length
											50	Project_Planning/Strategy	N	Y	Y	15	Text	1000	10	LongText	5000
51	Project_Phasing	N	Y	Y	15	Text	1000	15	AV到子表ASP的超级链接
											52	Resource_Model	N	Y	Y	15	Text	1000	20	AV到子表ASP的超级链接
53	Knowledge_Transfer_Plan	Y	Y	Y	15	Text	1000	25	LongText	5000
											54	Deployment_Plan	N	Y	Y	15	Text	1000	30	LongText	5000
55	Customer_Acceptance_Model	N	Y	Y	15	Text	1000	35	LongText	5000
											56	Resource_Labor_Pricing	N	Y	Y	16	Text	1000	5	AV到子表ASP的超级链接
57	Resource_Labor_Pricing_Amount	N	Y	Y	16	Text	1000	10	Currency
											58	Equipment/Tooling_Pricing_Comments	N	Y	Y	16	Text	1000	15	LongText	5000
59	Equipment/Tooling_Pricing_Amount	N	Y	Y	16	Text	1000	20	Currency
											60	Physical_Site_Pricing_Comments	N	Y	Y	16	Text	1000	25	LongText	5000
61	Physical_Site_Pricing_Amount	N	Y	Y	16	Currency		30	Currency
											62	Project_Management_Premium_Comments	N	Y	Y	16	Text	1000	35	LongText	5000
63	Project_Management_Premium_Amount	N	Y	Y	16	Currency		40	Currency
											64	Intellectual_Property_Premium_Comments	N	Y	Y	16	Text	1000	45	LongText	5000
65	Intellectual_Property_Premium_Amount	N	Y	Y	16	Currency		50	Currency
											66	Miscellaneous_Project_Expenses_Comments	N	Y	Y	16	Text	1000	55	LongText	5000

RFX_Item_ID	RFX_Item	Disablement_Allowed	Vendor_Bid_Display	Vendor_Response_Item	RFX_Category_ID	HM_Data_Type	HM_Field_Length	Item_Display_Order	AV_Response_Data_Type	AV_Field_Length
											67	Miscellancous_Project_Expenses_Amount	N	Y	Y	16	Text		60	Currency
68	Antioipated_Margin	N	Y	Y	16	Text	1000	65	Currency
											69	Total_Bid_Price	N	Y	Y	16	Text	1000	70	Currency
70	Resource_Travel_Expenses_Comments	N	Y	Y	17	Text	1000	5	LongText	5000
											71	Resource_Living_Expenses_Comments	N	Y	Y	17	Text	1000	10	LongText	5000
72	Resource_Per_Diem_Comments	N	Y	Y	17	Text	1000	15	LongText	5000
											73	Resource_Mileage_Expense_Comments	N	Y	Y	17	Text	1000	20	LongText	5000
74	Reimbersable_Miscellaneous_Expense_Comments	N	Y	Y	17	Text	1000	25	LongText	5000
											75	Capital_Risk_Model_Comments	N	Y	Y	18	Long Text	5000	5	LongText	5000
76	Capital_Risk_Model_Amount	N	Y	Y	18			10	Currency
											77	Rebate_Model_for_non-deployed_investment	N	Y	Y	19			5	LongText	5000
78	Supplier_Payment_ReleaseSchedule	N	Y	Y	20	Text	1000	5	LongText	5000
											79	Notes_to_MSP	Y	N	N	21	Long Text	5000	5
80	Notes_to_Supplier	Y	Y	N	22	Long Text	5000	5
											81	Project_Phasing_Acceptance	N	Y	Y	15			16	Char	1
82	Statement_Of_Work_Acceptance	N	Y	Y	15			11	Char	1
											83	Statement_OF_Work_Proposed_Changes	N	Y	Y	15			12	LongText	5000
84	Non-Deliverable_Penalties_Acceptance	Y	Y	Y	15			40	Char	1
											85	Non-Deliverable_Penalties_Proposed_Changes	Y	Y	Y	15	Long Text	5000	45	LongText	5000
86	Customer_Acceptance_Model_Agreement	Y	Y	Y	15			36	Char	1
											87	Customer_Acceptance_Model_Proposed_Changes	Y	Y	Y	15	Long Text	5000	37	LongText	5000
88	Preferred_Customer_Acceptance_Model	Y	Y	N	6	Lont Text	5000	6	LongText	5000
											89	Agree_To_Confidentiality_Terms	N	Y	Y	14	Text	1000	1	Char	1
90	Intent_To_Respond	N	Y	Y	14	Text	1000	2	Char	1

RFX_Item_ID	RFX_Item	Disablement_Allowed	Vendor_Bid_Display	Vendor_Response_Item	RFX_Category_ID	HM_Data_Type	HM_Field_Length	Item_Display_Order	AV_Response_Data_Type	AV_Field_Length
											91	Materials_List	Y	Y	Y	16	Text	1000	16	AV到子表ASP的超级链接
92	Materials_Cost	Y	Y	Y	16	Text	1000	17	Currency
											93	Desired_Assignment_StartDate	N	Y	N	12	date time		51
94	Desired_Assignment_End_Date	N	Y	N	12	date time		52

再次参照图17，每个投标条目230可以对于特定的投标模板240被禁用或使能，取决于为其创建投标模板240的项目工作的类型。然而，正如以上结合图15讨论的，可能有某些投标条目230需要被包括在一个或多个投标模板240类型中。所以，对于需要的投标条目230，不允许禁用。如果整个投标分段250或投标类别255不能应用于特定的投标模板240，则数据库表结构400可被配置成允许整个投标分段250内的投标条目230或投标类别255被禁用，如果该投标分段250内的所有投标条目230或投标类别255可被禁用的话。

一旦所有的投标条目230已对于特定的投标模板240被禁用或使能(投标条目选择235是使能的投标条目)，投标模板240和相关的投标条目选择235就可被存储在数据库表结构400。表“tblRFXBidTemplates”405，具有以上的表23的形式，包括投标模板名称和投标模板标识号，用于把投标条目选择235与在具有以上表24的形式的表“tblRFXBidTemplateItemMatrix”404中的投标模板240相联系。可以在表“tblRFXBidTemplates”405中存储分开的记录，每个记录具有表23的形式。另外，用于被包括在特定的投标模板240内的每个投标条目选择235的分开的记录可被存储在表“tblRFXBidTemplateItemMatrix”404中，每个记录具有表24的形式。

如果有特定的投标条目230具有可应用于所有的投标模板240的缺省值，诸如买主名字，则用于该特定的投标条目230的缺省值可被存储在具有表25的形式的表“tblRFXBidItemsCDV”406中。用于与每个投标条目230有关的每个缺省值的分开的记录可被存储在表“tblRFXBidItemsCDV”406中，每个记录具有表25的形式。通过提供以结构的、可配置的和可缩放的格式的、可选择的投标条目，任何投标条目230可以在任何时间被加上或去除，取决于买主的具体的需要。

图18上显示用于通过使用分级结构和关联的数据库表结构创建投标模板的示例性步骤。为了创建投标模板，买主用户输入用于模板的名称，以便创建在数据库表结构中用于模板的记录(步骤1800)。此后，买主用户从投标分段列表中选择特定的投标分段(步骤1805和1810)以及从投标类别列表中选择特定的投标类别(步骤1815和1820)，以开始选择用于包括在投标模板中的投标条目的过程(1825)。

如果需要在所选择的投标类别中的一个或多个投标条目(步骤1830)，则所需要的投标选择被自动包括在投标模板中(步骤1835)。根据买主用户对于特定的类型的投标模板的需要，选择其他投标条目(步骤1840)。这个过程对于在所选择的投标分段内的每个投标类别(步骤1845)和对于在投标分段列表内的每个投标分段(步骤1850)重复进行，直至所有的投标条目都被再审阅以及对于投标模板或者是使能的(选择)或者是禁用的为止。正如上面讨论的，在其他实施例中，在投标分段或投标类别内的所有投标条目可能能够被禁用而不用再审阅各个投标条目，如果允许所有那些投标条目被禁用的话。一旦对于投标模板已作出投标条目选择，投标模板就被存储在投标模板列表(步骤1855)，供以后在创建投标请求时使用。

图19显示用于创建投标模板的示例性网页的屏幕快照。通过使用一个或多个网页(仅仅显示其中的一个)，买主用户可以输入投标模板名称240，选择投标分段250和选择投标类别255来显示在可被包括在投标模板240内的投标类别255内的具体的投标条目230。对于在显示的投标类别255内的每个投标条目230，买主用户可以选择使能或禁用该投标条目230。然而，如果特定的投标条目230不能被禁用，则该禁用按钮被虚化(ghost)以防止买主用户禁用投标条目230。另外，如果任选项是可提供的，买主用户也允许通过点击在当前显示的投标分段250或投标类别255相邻的禁用按钮而禁用在特定的投标分段250或投标类别255内的所有的投标条目230。一旦所有的投标条目230对于投标模板240是使能的或禁用的，买主用户就可以保存该投标模板240。在某些实施例中，买主用户能够临时保存投标模板240，如果所有投标条目选择235还没有完成的话。在一个实施例中，保存按钮被虚化，直至所有的投标条目230被使能或被禁用为止。

图20显示通过使用被组织为分级结构和关联格式的投标条目，如图17所示，用于从投标模板创建投标请求的示例性步骤，如图15所示。初始地，由买主用户从用于投标请求的投标模板列表中选择投标模板(步骤2000)。应当看到，投标模板可以紧接在投标请求生成之前被创建或投标模板可以在投标请求前事先创建好。在用于投标请求的特定的投标模板被选择后，买主用户输入用于该投标请求的投标请求识别符(步骤2005)，诸如投标请求名称或号码。另外，系统将指配投标跟踪号来引用该投标，因为它在整个系统内应用到销售商、买主、承包商和管理机构。

在投标模板中所有的投标条目选择通过投标分段和投标类别被显示给买主用户供查阅(步骤2010)。如果在投标模板中的一个或多个投标条目选择不能应用于特定的投标请求(步骤2015)，以及不想要的投标条目选择可被禁用的话(步骤2020)，买主用户可以禁用对于特定的投标请求不需要的那些投标条目选择(步骤2025)。此后，买主用户把必须的投标请求数据输入到用于在投标请求中使能的投标条目选择的、适当的域(步骤2030)。例如，一个或多个投标条目选择可包含用于买主输入数据的域，诸如要执行的工作的位置或项目工作的类型。这些域可以是可变类型数据域，诸如文本输入域或可选择的任选项域，具有到包含可选择的任选项的网页的链接。

可被显示的、可选择的任选项域的例子包括从多个预先建立的项目类型中选择用于投标请求的特定类型的项目工作。为了实施项目类型选择过程，可以提供可配置的和可缩放的数据库结构，用来使得买主的具体的项目工作商业要求能够以非平凡(non-prose)的方式被归类。通过从预先建立的项目工作类型中进行选择，买主可保证，销售商投标应答是与买主的项目工作要求同步的。当完成用于选择接收投标请求的销售商的销售商考核数据时(如图2所示)，项目工作类型也可以由销售商选择。下面在表27-29上显示用于选择项目工作类型的数据结构的例子。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于把项目工作类型显示给买主用户从中进行选择，和把选择的项目工作类型存储在投标请求的相关投标条目选择的域内所必须的所有域。表格以分级结构和/或关联的方式进行相关，这样，表格以用于把项目工作类型显示给买主用户的特定次序被接入。

下面的表27分别显示样本的项目业务类型，诸如咨询、人员辅助、和其他项目业务。在每个项目业务类型内可以有一个或多个项目扇区，如表28所示，以及在每个项目扇区内可以有一个或多个项目族，如表29所示。所以，为了选择用于投标请求的特定的项目工作类型(项目族)，买主用户可以选择项目业务类型和项目扇区类型，以显示从中进行选择的项目族列表。应当看到，可以包括其他结构和项目类型，以及系统不限于在表27-29中所列出的具体的结构和信息。

                                     表27

                                 项目业务类型表

Project_Work_Type_Name	Services_Type_ID	ASP_Display_Order
			Consulting	1	2
Staff_Supplementation	2	3
			Project_Services	3	1

                                     表28

                                项目扇区类型表

Project_Section_ID	Project_Sector_Name	ASP_Display_Order	Project_Services_ID
				1	咨询/职业服务	2	1
2	工程/建筑	3	1
				3	技术	1	1

                                          表29

                                      项目族类型表

Project_Family_ID	Project_Family_Name	ASP_Display_Order	Project_Sector_ID
				7	Enterprise_Resource_Solutions	5	3
8	E-Business_Solutions	10	3
				9	Telecommunications_Solutions	15	3
10	Technical_Integration_Solutions	15	3
				11	Network_Management_Solutions	25	3
12	Custom_Software_Development/Engineering	30	3
				13	Business_Strategy/Planning_Solutions	5	1
14	Human_Resource_Solutions	10	1
				15	Audit/Assurance_Solutions	15	1
16	Financial_Advisory_Solutions	20	1
				17	Tax_Solutions	25	1
18	Risk_Management_Solutions	30	1
				19	Real_Estate_Services	35	1
20	Legal_Services	40	1
				21	Engineering_Services	5	2
22	Building/Construction_Services	10	2
				23	Product_Development	15	2

再次参照图20，一旦买主用户已输入投标请求数据到所有的需要的投标条目域(步骤2035)，投标请求就完成。应当看到，不是所有的投标条目域都需要用户输入投标请求数据，例如，一个或多个投标条目选择可以是只有销售商应答的、销售商投标应答投标条目选择。对于该销售商投标应答投标条目选择，买主用户可以使能或禁用该投标条目选择，以及不输入任何数据到用于该投标条目选择的域，除非是可以帮助销售商完成用于该投标条目的投标应答的数据。对于投标请求完整性，其中买主用户可以输入投标请求数据的、每个使能的投标条目选择优选地在投标请求被提交之前由买主用户被填满。

在许多公司中，投标请求在发送到销售商之前必须被批准。所以，如果投标请求需要批准(步骤2040)，则投标请求的组织者把投标请求提交到适当的批准者(步骤2045)。在示例性实施例中，正如以上结合图9-14讨论的，预先指定对于所有的投标请求或对于特定的投标请求的批准用户角色位置，这样，投标请求将自动路由到适当的批准者。如果投标请求被批准(步骤2050)，则把该投标请求批准告知组织者(步骤2055)，以及投标请求被发送到合格的销售商(步骤2060)。然而，如果投标请求没有批准(步骤2050)，则把该投标请求拒绝告知组织者(步骤2065)，以及如果可能的话，提供编辑投标请求的机会(步骤2070)。例如，组织者可以禁用需要被包括在用于批准目的的投标请求中的一个或多个投标条目选择，或让一个或多个买主需要的数据域空白。如果投标请求不需要批准(步骤2040)，则投标请求被发送到对于该投标请求的合格的销售商(步骤2060)。

图21和22是可被提供给买主用户用于投标请求创建的示例性网页的屏幕快照。通过使用一个或多个网页，买主用户可以输入投标请求名称200，选择投标分段250和选择投标类别255，以显示可被包括在投标请求200中的投标类别255内的具体的投标条目选择230。图21显示投标请求200的状态的总貌，列出在每个分段250中的投标条目选择235的数目以及在每个分段250中已完成的或禁用的投标条目选择235的数目。为了完成或禁用投标条目选择235，买主用户可以点击投标分段250，以显示投标类别255和在每个投标类别255内的投标条目选择235。一旦所有的投标条目选择235都已完成或禁用，买主用户可以点击提交完成的投标请求按钮，用于批准和/或发送到合格的销售商。

如图22所示，在每个投标分段250内每个投标类别255中的每个投标条目选择235可被审阅，以确定投标条目选择235是否应当被禁用。在一个或多个类别255中的某些投标条目选择235也可能需要来自买主用户的投标请求数据210。对于在投标类别255中的每个投标条目选择235，买主用户可以使能或禁用该投标条目选择235。然而，如果特定的投标条目选择235不能被禁用，则该禁用按钮被虚化，以防止买主用户禁用投标条目选择235。另外，如果任选项是可提供的，则买主用户也允许禁用在特定的投标分段250或投标类别255内的所有的投标条目选择235。如果投标条目选择235被使能和具有域238，用于输入投标请求数据210，则买主用户可以把投标请求数据210输入到相关的数据域238。另外，如果投标模板包含对于特定的投标条目选择235的缺省投标请求数据210，则缺省数据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)。

例如，投标消息板可以由系统提供，销售商和买主都可为特定的投标请求接入该消息板。示例性投标消息板600的屏幕快照显示于图27。只有应答特定的投标请求的买主和销售商才可接入投标消息板600。所有的销售商可被提供到所有的提交的问题和买主回答的接入，或只有提交问题的销售商才允许观看买主的回答，这取决于买主的设置。另外，销售商问题可能是对于销售商和买主，或只对于销售商是匿名的，这取决于销售商和/或买主的喜好。

转回到图25，如果销售商用户没有问题(步骤2540)或所有的销售商问题都已回答(步骤2560)，则销售商用户把必须的销售商应答数据输入到在投标中对于需要的投标条目选择的适当的域(步骤2565)。销售商应答数据可包括花费信息，它包括花费单元(例如，资源需要、花费类型等等)和相关的价格信息(例如，资源率、花费量等等)；以及包括可交付类型的可交付信息(例如，要完成的单位的数目，阶段信息等等)和完成信息(例如，项目结束日期、阶段结束日期等等)。花费单元和可交付类型的每一种与不同的投标条目选择相联系，以使得能够进行有效的比较和销售商投标应答的分级。

投标条目域可以具有各种数据类型，诸如文本/货币/数字-输入域和/或可选择的任选项域。另外，这些域可以具有与用于项目的不同方面的单独的投标应答条目有关的多个细节级别。例如，如果项目具有几个阶段，如由买主和/或销售商确定的，销售商应答域可包括用于项目的每个阶段的、分开的分段。在销售商投标应答的尝试提交后，系统证实在销售商投标应答中销售商完成对于投标条目选择的所有必要的数据域(步骤2570)。如果没有完成所有需要的数据域(步骤2575)，向销售商用户提供一个系统消息，表示有缺陷的销售商应答投标条目选择，以及提示在提交销售商投标应答之前完成需要的投标条目选择(步骤2580)。一旦在投标应答中完成用于投标条目选择的所有的需要的数据域(步骤2575)，就向销售商(在提交后)提供一个消息，表示销售商投标应答已被提交给买主或项目管理机构供审阅(步骤2585)以及经由电子邮件和/或控制板更新把新的销售商投标应答告知适当的买主用户(步骤2590)。

图26A和26B是可被提供给销售商用户的、用于投标应答生成的示例性网页的屏幕快照。销售商用户被提供以显示需要销售商投标应答数据的、在投标请求内的投标条目选择的网页。例如，如图26A所示，销售商投标应答的状态可以显示给销售商用户，列出在每个分段250中的投标条目选择235的数目、销售商用户必须完成的、在每个分段中的投标条目选择235的数目、以及已经完成的、在每个分段250中的投标条目选择235的数目。另外，销售商用户可以接入投标消息板以张贴销售商问题，观看具有可以容易读出的、在线格式的投标应答或提交要被包括在销售商投标应答中的潜在的承包商的简历。而且，一旦已完成对于所有的投标条目选择235的销售商应答，销售商用户就可点击提交完成投标应答按钮用于批准和/或发送到买主或项目管理机构。

为了完成对于投标条目选择235的销售商应答，如图26B所示，销售商用户可以点击投标分段250以显示投标类别255和在每个投标类别155内的投标条目选择235。如果需要对于特定的投标条目选择的销售商应答，则销售商用户可以把销售商应答数据215输入到用于投标条目选择235的数据域238。正如以上讨论的，数据域238可以是直接文本输入域或包括到用于从预先建立的销售商应答中选择适当的销售商应答数据215的其他网页的链接。另外，数据域238可以具有多个级别，具有连接到用于每个级别的网页的链接。而且，数据域238可能能够直接从销售商数据库以缺省销售商应答数据215(诸如销售商名字和销售商地址)被填充。例如，在接收投标请求后，销售商模块可以搜索特定的投标条目选择235，以及用适当的销售商应答数据215填充用于那些投标条目选择235的数据域238。

从预先建立的销售商应答来选择销售商应答数据的例子显示于图28。如果投标请求包括投标条目选择，需要销售商提供用于项目的资源需要信息，以及例如与资源需要信息有关的资源速率，则数据域238可以提供连到用于选择预先建立的资源资料参数的其它网页的链接。例如，每个资源资料可以表示特定的资源类型和对于资源资料需要的相关的技艺。为了由买主实施资源资料与速率的有效的比较，销售商可以从多个预先建立的资源类型和相关的技艺进行选择。为了实施资源类型和技艺选择，可以提供可配置的和可缩放的数据库结构，使得销售商特定的资源要求能够以非平凡的方式进行归类。

在下面的表30-37显示用于选择资源类型和相关的技艺的数据结构的例子。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于把资源类型和相关的技艺显示给销售商用户从中进行选择和存储选择的资源资料在相关的投标条目选择的数据域内所必须的所有的域。表格以分级结构和/或关联的方式进行相关，这样，表格以用于显示资源类型和相关的技艺给销售商用户的特定的次序被接入，正如下面结合图29描述的，图29显示代表与完全的销售商投标应答有关的示例性数据方案和在销售商投标应答与买主投标请求之间的相互关系的数据库表结构800。

下面的表30显示样本的商业扇区类别，诸如轻行业、管理/职业、办事处和技术。在每个商业扇区类别内是一个或多个商业场所，如表31所示，以及在每个商业场所内是一个或多个商业族，如表32所示。所以，为了选择与用于投标请求的资源类型有关的特定商业族，销售商用户可以选择商业扇区类别和商业场所，来显示从中选择的商业族列表。一旦商业族被选择，就可以选择与资源类型有关的各种技艺(一般功能和商业技艺)以及把其映射到特定的资源类型，如表33-37所示。例如，一般功能可以识别与资源类型有关的技艺的水平，技艺类别可以识别资源类型拥有的技艺、训练和经验的类型，以及与每个技艺类别有关的一个或多个技艺组可以识别与资源类型有关的特定的经验。另外，某些技艺组通过建立对于资源类型的每个技艺组的优先权水平而可以被强调来超过其他技艺组。应当看到，可以提供其他资源类型和技艺选择，以及系统不限于如表30-37所示的具体的结构和信息。为了更加全面地讨论资源资料，可参考共同待决的和共同转让的美国专利申请序列号10/128,751，该专利申请整体地在此引用，以供参考。

                              表30

                        示例性商业扇区表

Bus_Sector_Name	Bus_Section_ID	ASP_Display_Order
			轻工业	1	4
管理/职业	2	2
			办事处	3	3
技术	4	1

                                    表31

                               示例性商业场所表

Bus_Arena_ID	Bus_Arena_Name	Bus_Sector_ID	ASP_Display_Order
				1	行政管理支持	3	5
2	商业支持	4	5
				3	通信软件	4	10
4	控制器	2	10
				5	企业资源应用	4	15
6	财经	2	15
				7	一般商业支持	3	10
8	一般文书	3	15
				9	一般支持	1	5
10	人力资源	2	20
				11	法律	2	25
12	逻辑支持	1	10
				13	管理信息系统	4	20
14	制造	2	30
				15	材料管理	2	35
16	网络工程	4	25
				17	产品开发	4	30
18	生产	1	15
				21	销售	2	40
22	呼叫中心	2	5

                                 表32

                             示例性商业族表

Bus_Family_ID	Bus_Family_Name	Bus_Arena_ID	ASP_Page_Display
				23	维护	9	5
24	驾驶员/服务员	9	10
				26	货运/接收	12	5
27	分发	12	10
				28	库存控制	12	15
29	轻便组件	18	5
				30	电子组件	18	10
31	质量保证/控制	18	15
				32	资产管理	4	5
33	决算	4	10
				34	预算	4	15
35	花费中心会计	4	20
				36	附加开销	4	25
37	产品花费	4	30
				38	资料中心会计	4	35
39	利润率	4	40
				40	项目会计	4	45
41	纳税	4	50
				42	财务现金管理	4	55
43	可付费账户	6	5
				44	可接受账户	6	10
45	资本投资	6	15
				46	强化	6	20
47	信用/	6	25
				48	一般分类账	6	30
49	其它分类账	6	35
				50	津贴	10	5
51	工资单	10	10
				52	个人	10	15
53	业务	10	20
				54	反垄断法	11	5
55	合同法	11	10
				56	公司法	11	15
57	环境法	11	20
				58	国际法	11	25
59	劳动法	11	30
				60	房地产法	11	35
61	税法	11	40
				62	制造维修	14	5

Bus_Family_ID	Bus_Family_Name	Bus_Arena_ID	ASP_Page_Display
				63	制造过程	14	10
64	制造生产	14	15
				65	制造质量控制	14	20
66	分发/运输/仓库储存	15	25
				67	材料管理	15	30
68	购买	15	35
				69	销售管理	21	5
70	销售营运	21	10
				71	客户服务	22	5
72	运行	22	10
				73	销售/市场	22	15
74	簿记	7	5
				75	数据库支持	7	10
76	台式出版	7	15
				77	电子表格支持	7	20
20	一般文书支持	8	5
				21	行政管理支持	1	5
18	商业分析	2	5
				19	商业支持	2	10
1	网络设计/规划/咨询	16	5
				2	网络基础结构	16	10
3	网络运行/行政管理	16	15
				4	OS编程	3	15
5	应用开发	3	5
				6	数据库开发	3	10
8	产品管理	17	10
				9	产品设计/开发	17	5
10	OS编程	13	9
				11	网络基础结构支持	13	15
12	应用开发	13	5
				13	网络管理/行政管理	13	20
14	SAP	5	20
				15	PeopleSoft	5	15
16	Oracle	5	10
				17	Baan	5	5
78	数据库开发	13	10

                                表33

                         示例性商业一般功能

列名称	数据类型	长度	资源资料信息
				Business_Family_ID	Int	4	78
General_Function_ID	Int	4	3
				General_Function_Name	Nvarchar	100	数据库行政管理

                    表34

           技艺类别表(tblCategory)

列名称	数据类型	长度
			Skills_Category_ID	Int	4
Skills_Category	Nvarchar	255

                      表35

         技艺类别表(tblSkillMap)

列名称	数据类型	长度
			Skill_ID	int	4
Skill_Name	nvarchar	255
			Skills_Category	nvarchar	255
Skills_Category_ID	int	4

                   表36

商业族到技艺类别的映射(tblBusFamtoSkillCat)

列名称	数据类型	长度
			BusinessFamilyID	int	4
Skills_Category_ID	int	4
			Skills_Category	nvarchar	255
Required	char	1
			Record_ID	int	4

                          表37

                  示例性商业技艺优先权

列名称	数据类型	长度	资源资料信息
				Skill_Priority_ID	int	4	2
Skill_Priority_Name	varchar	50	临界

在提交销售商投标应答后，所有的投标条目选择域被填充以投标数据(或者投标请求数据，或者销售商应答数据)，它作为投标以分级结构和关联的方式被存储在系统(买主数据库和销售商数据库)中，正如在图29的数据库表结构800显示的。用于存储投标数据的示例性数据结构被显示在下面的表38-55中，正如结合图29讨论的。

下面的表38和39显示与特定的投标请求有关的样本投标请求数据，它可被存储在表“tblRFX”801和“tblRFXSelectedBidItems”802的数据库中，如图29所示。例如，在表“tblRFX”801中，有关可被存储的投标请求的一般信息，诸如由系统指配给投标请求的投标跟踪号、由组织者指配的投标请求名称、投标请求组织者的身份、投标模板类型、项目类型、项目工作位置、用于项目的预算花费总量、投标请求的状态(例如，新的、提交的、评估的、发包的、等等)、最高级别数据库销售商是否接收投标请求以及是否需要任何批准。然而，应当看到，也可以包括其他投标信息，以及系统不限于表38和39所示的具体的信息。

由用于每个投标条目选择的组织者输入的、被包括在投标请求和投标请求数据(买主评注)内的特定的投标条目选择可被存储在“tblRFXSelectedBidItems”802中。每个投标条目选择可以作为分开的记录被存储在“tblRFXSelectedBidItems”802中，每个记录包含在下面的表39中显示的所有的域。表“tblRFXSelectedBidItems”802被束缚到一般的投标请求信息表“tblRFX”801。正如以上结合图10讨论的，被包含在表“tblRFXSelectedBidItems”802中的投标条目选择是从表“tblRFXBidItems”403中选择的，以及是通过表“tblRFXTemplateItemMatrix”404与被存储在表“tblRFXBidTemplates”405内的特定投标模板类型相联系的。

                        表38

               主投标表(tblRFX-db结构图)

列名称	数据类型	长度
			RFX_Tracking_ID	int	4
Originator_User_ID	int	4
			RFX_Template_ID	int	4
Project_Sector_ID	int	4
			Project_Family_ID	int	4
Project_Type_ID	int	4
			RFX_Status_ID	int	4
Buyer_Bid_ID	varchar	100
			RFP_Title	varchar	100
RFX_Administration_Location_ID	numeric	9
			Primary_Work_Location_ID	numeric	9
External_Work_Location	varchar	500
			Solicit_TLD_Vendors	char	1
Currency_ID	int	4
			Budgeted_Expenditure	money	8
Assigned_to_ID	int	4
			RFQ_Team_Member	int	4
Financial_Approval_Required	char	1
			Non_Financial_Approval_Required	char	1

                     表39

     RFX投标条目列表(tblRFXSelectedBidItems)

列名称	数据类型	长度
			RFX_Tracking_ID	int	4
RFX_Item_ID	int	4
			RFX_Item	varchar	255
Disablement_Allowed	char	1
			HM_Disabled	char	1
Buyer_Comments	varchar	8000
			Vendor_Bid_Display	char	1
Vendor_Response_Item	char	1
			Vendor_Response_Required	char	1
Item_Complete	char	1
			Identity_Key	int	4

关于张贴(发送)投标请求给合格的销售商的样本信息被显示于下面的表40，其可被存储在表“tblRFXPost”803中的数据库中，如图29所示。在示例性实施例中，张贴信息涉及到接收投标请求的每个特定的销售商，以及可以包括例如投标请求被提交(张贴)给合格的销售商的日期和时间、张贴投标请求的管理机构用户的身份、接收投标请求的合格的销售商的身份、销售商投标应答识别符和被指配给销售商的分数，正如下面结合图31-35描述的。然而，应当看到，可以包括其他信息，以及系统不限于在表40中显示的具体的信息。用于接收投标请求的每个销售商的分开的记录可被存储在表“tblRFXPost”803，每个记录包括下面所示的所有的域。

                  表40

               tblRFXPost

列名称	数据类型	长度
			Bid_Tracking_ID	int	4
Vendor_ID	int	4
			Posting_Record	int	4
Post_Time	datetime	8
			Admin_Poster_ID	int	4
Response_ID	int	4
			Score	int	4

关于由销售商接收投标请求和提交销售商投标应答的样本的信息被显示于下面的表41，它们被存储在表“tblRFXResp”804中的数据库中，如图29所示。例如，这样的应答提交信息可包括销售商投标应答识别符、销售商投标应答的状态、销售商的身份、销售商投标应答提交日期、和销售商确认保密性和打算回答协定的日期。可被包括在表“tblRFXResp”804中的状态信息的类型的例子显示于下面的表42中，它可被存储在表“tblRFXRespStatus”805中的数据库中，如图29所示。表“tblRFXResp”804和“tblRFXRespStatus”805被束缚到表“tblRFXPost”803，它又被束缚到表“tblRFX”801，把销售商应答提交信息与用于投标请求的投标张贴信息相联系。然而，应当看到，可以包括其他信息，以及系统不限于在表41和42中显示的具体的信息。用于每个销售商投标应答的分开的记录可被存储在表“tblRFXResp”804，每个记录包括下面表41中显示的域。

                          表41

                       tblRFXResp

列名称	数据类型	长度
			Response_ID	int	4
RFX_Resp_Status_ID	int	4
			Vendor_ID	int	4
Confidentiality_Acceptance_Date	datetime	8
			Intend_to_Respond_Date	datetime	8
RFX_Resp_Submit_Date	datetime	8
			Last_Edit_Date	datetime	8

              表42

 来自tblRFXRespStatus的示例性数据

	1 New
2 Confidentiality_Terms_Accepted
	3 Confidentiality_Terms_Not_Accepted
4 Response_Intended
	5 Response_Declined
6 Temporarily_Sawed
	7 Response_Submitted
8 Bid_Not_Accepted
	9 Awaiting_Re-Bid
10 Re-Bid_Declined
	11 Bid_Accepted
12 Bid_On_Hold
	13 Waiting_Bid_Description

下面的表43显示在从销售商到买主的销售商投标应答中提交的样本的销售商投标应答，它可被存储在表“tblRFXRespMain”806的数据库中，如图29所示。例如，这样的销售商投标应答数据可包括投标跟踪号、销售商应答识别符、销售商的身份、销售商应答的具体的投标条目选择、对于该具体的投标条目选择的销售商应答、与该具体的投标条目选择有关的任何投标请求数据(买主评注)、对于该具体的投标条目选择的销售商应答的记录识别符、由买主给予销售商应答的任何等级，正如结合图31-35更详细地描述的。然而，应当看到，也可以包括其他信息，以及系统不限于表43所示的具体的信息。对于由销售商应答的每个投标条目选择的分开的记录被存储在表“tblRFXRespMain”806，每个记录包括下面表43中显示的域。表“tblRFXRespMain”806被束缚到表“tblRFX”801和“tblRFXPost”803，以把销售商投标应答与投标请求相联系。

                     表43

                 tblRFXRespMain

列名称	数据类型	长度
			Bid_Tracking_ID	int	4
Response_ID	int	4
			Vendor_ID	int	4
Identity_Key	int	4
			RFX_Item_ID	int	4
RFX_Item	varchar	50
			Vendor_Response	varchar	7000
Required_Item	char	1
			Buyer_Comments	varchar	7000
Resp_Recorq_ID	int	4
			Record_Create_Date	datetime	8
Last_Save_Date	datetime	8
			Item_Grade	char	1

把一个或多个销售商应答与投标条目选择相联系的可以是被销售商识别为对于完成项目所必须的、具体资源(承包商)的一个或多个资源资料。资源资料可以事先创建或作为销售商投标应答的一部分。资源资料是通过使用以上结合图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和“tblResourceProfileMasterGF’s”817中，每个记录包含下面的表45-46中显示的所有的域。表“tblResourceProfileMaster”807被束缚到表“tblResourceProfileMasterSkills”816和“tblResourceProfileMasterGF’s”817，把一般功能和技艺组与每个资源资料的资源类型相联系。

                    表44

       tblResourceProfileMaster(db结构图)

列名称	数据类型	长度
			Resource_Profile_ID	int	4
Resource_Profile_Name	varchar	255
			User_ID	int	4
Vendor_ID	int	4
			Bus_Sector_ID	int	4
Bus_Arena_ID	int	4
			Bus_Family_ID	int	4
User_Notes	varchar	1000
			Record_Date	datetime	8
Profile_Status	char	4

                    表45

      tblResourceProfileMasterGFs(db结构图)

列名称	数据类型	长度
			Resource_Profile_ID	Int	4
General_Function_ID	Int	4
			Record_ID	Int	4

                       表46

   tblResourceProfileMasterSkills(db结构图)

列名称	数据类型	长度
			Resource_Profile_ID	int	4
Skill_ID	int	4
			Record_ID	int	4
Skill_Priority	int	4

关于通过销售商投标应答提交的具体选择的资源资料的样本信息显示于下面的表47，它可被存储在图29上的表“tblRFXResourceProfiles”818。例如，这样选择的资源资料信息可以包括资源资料的身份和对于完成项目所需要的具体选择的资源资料的预计量。然而，应当看到，可以包括其他信息，以及系统不限于表47所示的具体的信息。用于项目的每个选择的资源资料的分开的记录被存储在表“tblRFXResourceProfiles”818，每个记录包含下面的表47中显示的所有的域。表“tblRFXResourceProfiles”818被束缚到表“tblRFXResourceProfileMaster”807，以把特定的资源类型、技艺和一般功能与所选择的资源资料相联系。表“tblRFXResourceProfiles”818还被束缚到表“tblRFXSelectedBidItems”802，以把所选择的资源资料与请求该资源资料的特定的投标条目选择相联系。

                    表47

         tblRFXResourceProfile(db结构图)

列名称	数据类型	长度
			Resource_Profile_ID	int	4
Anticipated_Quantity	int	4
			User_ID	int	4
Record_Date	datetime	8
			Identity_Key	int	4
Record_ID	int	4

取决于投标请求，作为对于一个或多个投标条目选择的销售商投标应答的一部分，销售商也可提供与用于项目的具体选择的资源资料有关的价格信息。样本的资源价格信息被显示于下面的表48，它可被存储在表“tblRFXResourcesProfilePricing”819的数据库中，如图29所示。例如，这样的资源价格信息可包括资源资料识别符、对于请求资源资料和价格信息的投标条目选择的销售商投标应答记录的身份、与资源资料有关的资源将工作的预计的小时数、与资源资料有关的计费率、和与资源资料有关的预计的计费量。然而，应当看到，也可以包括其他信息，以及系统不限于表48所示的具体的信息。对于与选择的资源资料之一有关的每个资源的分开的记录被存储在表“tblRFXResourcesProfilePricing”819，每个记录包括下面表48中显示的域。表“tblRFXResourcesProfilePricing”819被束缚到表“tblRFXResourceProfiles”818，把用于特定的资源的资源价格信息与特定的选择的资源资料相联系。另外，“tblRFXResourcesProfilePricing”819被束缚到表“tblRFXRespMain”806和表“tblRFXSelectedBidItems”，把资源价格信息和选择的资源资料与对于特定的投标条目选择的销售商投标应答相联系。

                     表48

    tblRFXResourceProfilesPricing(db结构图)

列名称	数据类型	长度
			Resource_Profile_ID	int	4
Resp_Record_ID	int	4
			Vendor_ID	int	4
Anticipated_Hours	int	4
			Bill_Rate	money	8
Anticipated_Billing	money	8
			Record_Date	datetime	8
Record_ID	int	4
			Identity_Key	int	4

除了特定的资源资料和价格以外，销售商投标应答也可包括与对于项目所需要的材料类型有关的信息。样本的材料信息被显示于下面的表49中，它可被存储在数据库中的表“tblRFXRespMaterials”822内，如图29所示。例如，这样的材料信息可包括对于请求材料信息的投标条目选择的销售商投标应答记录的身份、材料的类型和材料的花费。然而，应当看到，也可以包括其他信息，以及系统不限于表49所示的具体的信息。对于每种材料类型的分开的记录被存储在表“tblRFXRespMaterials”822，每个记录包括下面表49中显示的域。表“tblRFXRespMaterials”822被束缚到表“tblRFXRespMain”806和表“tblRFXSelectedBidItems”，把材料信息与对于特定的投标条目选择的销售商投标应答相联系。

                     表49

           tblRFXRespMaterials(db结构图)

列名称	数据类型	长度
			Resp_Record_ID	int	4
Material_Name	varchar	100
			Material_Description	varchar	500
Material_Manufacturer	varchar	100
			Unit_Cost	money	8
Unit_Count	numeric	9
			Line_Item_Cost	money	8
Record_Date	datetime	8
			Record_ID	int	4
Identity_Key	int	4

销售商投标应答也可包括与项目的阶段有关的信息。样本的阶段信息被显示于下面的表50，它可被存储在数据库中的表“tblRFXRespPhase”823内，如图29所示。例如，对于项目的每个阶段，阶段信息可包括对于请求阶段信息的投标条目选择的销售商投标应答记录的身份、特定的阶段的数量、阶段的说明、阶段的预计的持续时间和阶段结束处的项目可交付(例如，要被完成的单元的数目或其他项目主要管理点)。然而，应当看到，也可以包括其他信息，以及系统不限于表50所示的具体的信息。对于每个阶段的分开的记录被存储在表“tblRFXRespPhase”823中，每个记录包括下面表50中显示的域。表“tblRFXRespPhase”823被束缚到表“tblRFXRespMain”806和表“tblRFXSelectedBidItems”，把阶段信息与对于特定投标条目选择的销售商投标应答相联系。

                            表50

                    tblRFXRespPhase(db结构图)

列名称	数据类型	长度
			Resp_Record_ID	int	4
User_ID	int	4
			Project_Phase_#	numeric	9
Project_Phase_Description	varchar	7000
			Project_Phase_Duration_Anticipated	varchar	1000
Project_Phase_Deliverables	varchar	7000
			Record_Date	datetime	8
Record_ID	int	4
			Identity_Key	int	4

由销售商和买主在投标消息板上张贴的所有的问题和回答以及由买主提交给销售商的、有关销售商投标应答的任何问题也可被存储在系统中，以及与特定的销售商投标应答相联系。样本的问题信息显示于下面的表51和52，它可被存储在数据库中表“tblRFXQuestionsFROMVendor”820和“tblRFXQuestionsFROMBuyer”821内，如图29所示。对于每个销售商问题/买主应答和买主问题/销售商应答的分开的记录被存储在表“tblRFXQuestionsFROMVendor”820和“tblRFXQuestionsFROMBuyer”821中，每个记录包括下面表51和52中显示的域。另外，表“tblRFXQuestionsFROMVendor”820和“tblRFXQuestionsFROMBuyer”821被束缚到表“tblRFXRespMain”806，把问题与特定的销售商投标应答相联系。

                       表51

         tblRFXQuestionsfromVendor(db结构图)

列名称	数据类型	长度
			Vendor_ID	int	4
[Vendor_Question/Comment]	varchar	8000
			Question_Post_Date	datetime	8
Buyer_Response	varchar	8000
			Buyer_Answer_Post_Date	datetime	8
Record_ID	int	4
			Resp_Record_ID	int	4

                      表52

         tblRFXQuestionsfromBuyer(db结构图)

列名称	数据类型	长度
			Vendor_ID	Int	4
Identity_Key	int	4
			[Buyer_Question/Comment]	varchar	8000
Buyer_Post_Date	datetime	8
			Vendor_Response	varchar	8000
Vendor_Response_Date	datetime	8
			Record_ID	int	4
Resp_Record_ID	int	4

销售商投标应答也与关于由销售商执行的帮助投标应答过程的以前的项目工作的细节有关。样本的以前的项目工作细节被显示于下面的表53中，它可被存储在数据库中表“tblRFXRespTrackRecord”824内，如图29所示。例如，这样的以前的项目工作的细节可包括销售商投标应答识别符、项目名称、买主名字、项目的价值、项目的说明、对于项目部署的资源(承包商)的讨论、销售商的进行的讨论、项目开始日期和项目结束日期。应当看到，可以存储附加的以前的项目工作细节，以及系统不限于表53所示的具体的以前项目工作的细节。

                   表53

        tblRFXRespTrackRecord(db结构图)

列名称	数据类型	长度
			Response_ID	Int	4
Project_Name	Varchar	255
			Buyer_Name	Varchar	255
Project_Value	money	8
			Project_Description	varchar	7000
Deployed_Resources	varchar	7000
			Company_Performance	varchar	7000
Project_Start_Date	datetime	8
			Project_End_Date	datetime	8
Record_ID	int	4
			Record_Date	datetime	8

现在参照图30，图上显示用来显示给买主的、用于投标请求和销售商投标应答的行政管理的任选项的样本网页的屏幕快照。从投标请求行政管理网页，买主用户可以把完成的投标请求提交到管理机构(或合格的销售商)，观看对于投标请求的销售商投标应答，给销售商投标应答分级，把有关销售商投标应答的问题提交给销售商，由销售商请求重新报价，请求与销售商进行项目会晤或与用于项目的潜在资源(承包商)进行资源会晤、把投标(项目)发包给特定的销售商，指定用于项目的资源或把投标请求暂时搁置(onhold)。

一旦买主接收到对于特定的投标请求的一个或多个销售商投标应答，买主就可以分级或否则比较销售商投标应答，以便确定哪个销售商将获得该项目的发包。通过使用在投标请求和投标应答中预先建立的投标条目，所有的销售商投标应答具有相同的格式，使能进行经济的和有效的分级和比较销售商投标应答。所以，在开始对销售商投标应答分级以前，买主可以选择一个或多个投标条目用于分级目的。

用于选择分级的投标条目和对被选择的分级的投标条目的销售商应答进行分级的示例性功能被显示于图31。图31上显示按照本发明的实施例的、用于选择分级的投标条目和给销售商应答分级的分级工具188。分级工具188可包括对于执行工具的功能所需要的任何硬件、软件和/或固件，以及它可以在web服务器120或附加服务器(未示出)内被实施。

在创建投标请求后的任何时间，负责给销售商投标应答分级的分级机构(例如，买主用户或项目管理机构用户)可以接入分级工具188从投标请求中间选择一个或多个投标条目选择235用于分级目的。分级工具接入被存储在数据库155中的投标条目列表194，从投标条目列表194中检索由分级机构识别的、被包括在特定的投标请求内的投标条目选择235以及经由买主模块110、web服务器120、数据网40和买主浏览器20a把投标条目选择235显示给分级机构以从中进行选择。从投标条目选择235，分级机构可以选择一个或多个分级的投标条目236以及把分级的投标条目236的列表提供到分级工具188。

在接收一个或多个销售商投标应答后，分级工具188可以接入销售商投标应答列表192，检索与在列表192中的一个销售商投标应答的一个分级的投标条目236有关的销售商应答数据215。投标条目应答数据215被显示给分级机构用于分级目的。根据关于被包括在显示的投标条目应答数据215内的质量和信息的不同的因素(客观的和主观的)，分级机构可以对于投标条目应答215指定一个等级，以及把投标条目应答等级260发送到分级工具188。

分级工具188还与数据库155接口，把对于销售商的投标条目应答等级260存储在销售商等级列表198，该销售商等级列表包含对于在销售商投标应答列表192中每个销售商投标应答的所有分级的投标条目236的投标条目应答等级260。另外，根据由分级工具188接收的、对于特定的销售商投标应答的所有分级的投标条目236的所有投标条目应答等级260，分级工具188可以计算对于特定的销售商投标应答的总的销售商分数265以及把销售商分数265存储在销售商等级列表198中。

用于选择分级的投标条目和通过使用分级的投标条目给销售商投标应答分级的示例性步骤被显示于图32和33。对于投标应答分级执行的主处理步骤被显示于图32。在接收销售商投标应答后(步骤3200)，识别要被使用于分级目的的投标条目选择(步骤3210)。投标条目选择与征求销售商投标应答的投标请求相联系，以及销售商投标应答数据被包括在被选出用于分级目的的投标条目选择内。通过使用在分级的投标条目内的销售商投标应答数据，销售商投标应答被分级(步骤3220)。

更详细的分级过程显示于图33。在创建投标请求后，把与投标请求有关的投标条目选择列表提供给买主用户(步骤3330)。从投标条目选择列表，选择一个或多个分级的投标条目(步骤3305)，以及每个分级的投标条目可以指配以一个加权因子(例如，加权百分数)(步骤3310)，以便在最后的分数中比其他应答更重地加权。应当指出，在某些实施例中，加权因子可以是相等的，由此消除买主用户输入特定的加权因子的需要。所有的分级的投标条目的加权因子必须在销售商投标应答可被分级之前完成(步骤3315)。

一旦所有的分级的投标条目被选择和被指配加权因子，就把销售商投标应答列表提供给分级机构(步骤3320)，以及选择一个销售商投标应答用于分级目的(步骤3325)。此后，分级机构选择一个分级投标条目(步骤3330)，来给被包括在分级的投标条目内的销售商投标应答数据分级(步骤3335)。分级机构可以通过使用可提供给分级机构的任何机制对销售商投标应答数据进行分级。在一个实施例中，分级机构可以预先建立用于特定的分级投标条目的分级准则，使得系统能够自动给销售商应答数据分级。例如，为了给价格信息分级，分级机构可以预先指配等级给特定的价格范围，以及系统可以根据在销售商投标应答中提交的价格提供对于该价格分级的投标条目的等级。在其他实施例中，分级机构可以在根据销售商投标应答数据之间的相对差值指配等级之前，初始地比较对于特定的分级投标条目的所有的销售商投标应答数据。在再一个实施例中，分级机构可以预先建立检验表或阈值，用于把每个等级指配给特定的分级的投标条目。

被指配给对于分级的投标条目的销售商应答数据的等级被存储在数据库(步骤3340)，以及对于每个分级的投标条目重复该过程，直至对于特定的销售商投标应答的、被包括在每个分级投标条目内的销售商应答数据被分级为止(步骤3345)。一旦所有的等级已完成，系统就根据指定给每个分级的投标条目的各个等级计算销售商的总的分数(步骤3350)。例如，如果可能的等级是A，B，C和D，销售商分数就可以通过指配A级为4分，B级为3分，C级为2分以及D级为1分而进行计算。

每个销售商投标应答以相同的方式被分级(步骤3355)，使得销售商分数能够按递减的次序被排序(步骤3360)，并显示给买主用户(步骤3365)。除了总的分数以外，分级机构也可被提供以对于分级的投标条目的各个等级，以便确定是否必须有任何重新报价。通过给分级机构提供总分和各个等级，分级机构可以通过视觉确定哪个销售商具有最高的总分以及哪个销售商具有对于特定的分级的投标条目的最高等级，以便作出关于哪个销售商被发包给该项目的决定。然而，应当看到，对于本发明的系统可以使用其他投标应答比较技术，而不用这里描述的具体的分级和定分数。

可被显示给分级机构的、用于选择分级的投标条目和给销售商投标应答分级的示例性网页61的屏幕快照被显示于图34A-34E。在图34A上，网页包含供分级机构从中选择的投标条目选择235列表。对于每个选择的等级的投标条目236，分级机构也可输入对于该分级的投标条目236的加权百分数850。分级机构可以根据预先建立的准则或个人的喜好调节加权百分数850，直至加权百分数850总共等于百分之百为止。正如以上讨论的，在其他实施例中，所有的分级的投标条目236可被指定相等的权重，这样，加权百分数850不需要被显示给分级机构或由分级机构选择。

为了给销售商投标应答分级，如图34B所示，分级机构可被提供以列出特定的分级投标条目236的网页，它或者显示销售商投标应答数据215或者提供连到销售商投标应答数据215的链接。例如，如图34C所示，可以提供连到资源资料的链接和相关的资源价格信息，以便给特定的分级的投标条目分级。再次参照图34B，分级机构还可被提供以提示，以便输入对于与分级的投标条目236有关的销售商投标应答数据215的等级855。在其他实施例中，根据预先建立的分级准则，等级855可以由系统自动地指定。

一旦销售商投标应答被分级，如图34D所示，分级机构可被提供以显示所有的分级的投标条目236、被指定给分级的投标条目236的加权百分数850、和由分级机构指定给每个分级的投标条目236的销售商等级855的网页。另外，总的销售商分数860也可被显示来使得分级机构能够确定销售商投标应答的总的质量。现在参照图34E，根据总的销售商分数860和被指定给每个分级的投标条目236的各个等级855，销售商投标应答可以并行(side-by-side)比较。

下面的表54-56显示被使用于选择分级的投标条目和存储销售商等级的数据结构的例子。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于把投标条目选择显示给买主用户以从中进行选择和存储销售商投标应答的等级和分数所必须的所有的域。表格以分级结构和/或关联的方式进行相关，正如下面结合图35讨论的。

下面的表54显示可被包括在投标请求和相关的销售商投标应答中的样本的投标条目选择。然而，应当看到，也可以包括其他信息，以及系统不限于在表54中显示的具体的信息。对于每个投标条目选择，有关于该投标条目选择是否可分级的指示。例如，不是所有的投标条目选择都可包括销售商应答数据来分级。所以，只有可分级的投标条目选择被显示给买主用户以从中进行选择。

                                         表54

                       示例性潜在的分级的投标条目的销售商列表(按类别)

RFX_Category	RFX_Item	Default_Gradable_Item	AV_Response_Data_Type
				Supplier_General_Information	Agree_To_Confidentiality_Terms		Char
Supplier_General_Information	Intent_To_Respond		Char
				Supplier_General_Information	Company_History		LongText
Supplier_General_Information	Competitive_Analysis		LongText
				Supplier_General_Information	Product/Services_Heritage_Review		LongText
Supplier_General_Information	Product/Services_Strategy		LongText
				Supplier_General_Information	Technology_Vision		LongText
Supplier_General_Information	Strategic_Technology_Partners		到子表ASP的AV超级链接
				Supplier_General_Information	Track_Record		到子表ASP的AV超级链接
Supplier_General_Information	Project_Management_Philosophy		LongText
				Supplier_General_Information	PMI_Certified_FTEs		LongText
Supplier_General_Information	Customer_References		到子表ASP的AV超级链接
				Supplier_Project_Information	Proposal_Narrative	Y	LongText
Supplier_Project_Information	Project_Planning/Strategy	Y	LongText
				Supplier_Project_Information	Statement_Of_Work_Acceptance		Char
Supplier_Project_Information	Statement_Of_Work_Proposed_Changes		LongText
				Supplier_Project_Information	Project_Phasing	Y	到子表ASP的AV超级链接
Supplier_Project_Information	Project_Phasing_Acceptance		Char
				Supplier_Project_Information	Resource_Model	Y	到子表ASP的AV超级链接

RFX_Category	RFX_Item	Default_Gradable_Item	AV_Response_Data_Type
				Supplier_Project_Information	Knowledge_Transfer_Plan	Y	LongText
Supplier_Project_Information	Deployment_Plan	Y	LongText
				Supplier_Project_Information	Customer_Acceptance_Model	Y	LongText
Supplier_Project_Information	Customer_Acceptance_Model_Agreement		Char
				Supplier_Project_Information	Customer_Acceptance_Model_Proposed_Changes		LongText
Supplier_Project_Information	Non-Deliverable_Penalties_Acceptance		Char
				Supplier_Project_Information	Non-Deliverable_Penalties_Proposed_Changes		LongText
Supplier_Project_Pricing	Resource_Labor_Pricing		到子表ASP的AV超级链接
				Supplier_Project_Pricing	Resource_Labor_Pricing_Amount	Y	Currency
Supplier_Project_Pricing	Equipment/Tooling_Pricing_Comments		LongText
				Supplier_Project_Pricing	Materials_List		到子表ASP的AV超级链接
Supplier_Project_Pricing	Materials_Cost	Y	Currency
				Supplier_Project_Pricing	Equipment/Tooling_Pricing_Comments		Currency
Supplier_Project_Pricing	Physical_Site_Pricing_Comments		LongText
				Supplier_Project_Pricing	Physical_Site_Pricing_Amount	Y	Currency
Supplier_Project_Pricing	Project_Management_Premium_Comments		LongText
				Supplier_Project_Pricing	Project_Management_Premium_Amount	Y	Currency
Supplier_Project_Pricing	Intellectual_Property_Premium_Comments		LongText
				Supplier_Project_Pricing	Intellectual_Property_Premium_Amount	Y	Currency
Supplier_Project_Pricing	Miscellaneous_Project_Expenses_Comments		LongText
				Supplier_Project_Pricing	Miscellaneous_Project_Expenses_Amount	Y	Currency
Supplier_Project_Pricing	Anticipated_Margin	Y	Currency
				Supplier_Project_Pricing	Total_Bid_Price	Y	Currency
Supplier_Resource_Expenses_Handling	Resource_Travel_Expense_Comments		LongText

RFX_Category	RFX_Item	Default_Gradable_Item	AV_ResponseData_Type
				Supplier_Resource_Expenses_Handling	Resource_Living_Expense_Comments		LongText
Supplier_Resource_Expenses_Handling	Resource_Per_Diem_Comments		LongText
				Supplier_Resource_ExpensesHandling	Resource_Mileage_Expense_Comments		LongText
Supplier_Resouce_ExpensesHandling	Reimbersable_Miscellaneous_Expense_Comments		LongText
				Capital_Risk_Model	Capital_Risk_Model_Comments		LongText
Capital_Risk_Model	Capital_Risk_Model_Amount	Y	Currency
				Supplier_Rebate_Model_for_Non-deployed_Investment	Rebate_Model_for_non-deployed_investment	Y	LongText
Supplier_Payment_ReleaseSchedule	Supplier_Payment_Release_Schedule		LongText

对于每个分级的投标条目存储分开的等级，如下面的表55所示，它可被存储在表“tblRFXGradeItems”825中数据库表结构1100中，如图35所示。连同用于特定的分级的投标条目236的指定的等级855一起。表“tblRFXGradeItems”825也可包括买主用户分级机构的身份、指定给分级的投标条目236的加权百分数850、和与等级855有关的销售商投标应答识别符。然而，应当看到，也可以包括其他信息，以及系统不限于表55所示的具体的信息。对于每个销售商的每个销售商等级以分开的记录被存储在表“tblRFXGradeItems”825中，每个记录包含下面表55中显示的域。另外，表“tblRFXGradeItems”825被束缚到表“tblRFXRespMain”806，它又被束缚到表“tblRFX”801，二者都如以上结合图29描述的，以便把销售商等级855与销售商投标应答和投标请求相联系。另外，表“tblRFXGradeItems”825被束缚到表“tblRFXSelectedBidItems”802，把销售商等级855与特定的投标条目选择235相联系。

                  表55

   分级的投标条目列表(tblRFXGradeItems)

列名称	数据类型	长度
			User_ID	Int	4
RFX_Item	Varchar	50
			Weight_Percent	percent	4
Grade_Record_ID	int	4
			Record_Date	datetime	8
Grade	char	1
			Response_ID	int	4

对于每个投标条目235的每个销售商等级855的计算的分数865可被存储，如以下表56所示，它们可被存储在数据库中表“RFXItemsScoreVendor”826内，如图35所示。对于每个销售商投标应答的每个分级的投标条目的分开记录被存储在表“tblRFXItemsScoreVendor”826中，每个记录包含表56中显示的域。另外，根据被存储在表“tblRFXItemsScoreVendor”826中的所有的销售商分数865的总分数860也可被存储，如下面的表57所示，它们可被存储在数据库中表“tblRFXScoreVendor”827中，如图35所示。对于每个销售商投标应答的分开的记录被存储在表“tblRFXScoreVendor”827中，每个记录包含表57中显示的域。

表“tblRFXItemsScoreVendor”826被束缚到表“tblRFXGradeItems”825，把每个分数865与对于特定的销售商投标应答的所有分级的投标条目236的适当等级855相联系。另外，表“tblRFXScoreVendor”827被束缚到表“tblRFXItemsScoreVendor”826，对于特定的销售商投标应答的所有分级的投标条目236的所有分数865与对于该特定的销售商投标应答的总共分数860相联系。而且，表“tblRFXScoreVendor”827被束缚到表“tblRFXPost”803，正如以上结合图29讨论的，用销售商分数860更新表“tblRFXPost”。

                  表56

销售商条目分数表(tblRFXItemScoreVender)

列名称	数据类型	长度
			Response_ID	Int	4
RFX_Item	Int	4
			Score	Numeric	4
Buyer_User_ID	Int	4
			Score_Record_ID	Int	4
Identity_Key	Int	4

                  表57

    销售商分数表(tblRFXScoreVender)

列名称	数据类型	长度
			Response_ID	int	4
Total_Score	numeric	9
			Buyer_User_ID	int	4
Score_Record_ID	int	4
			Identity_Key	int	4

在销售商投标应答被接收和分级后，买主用户可以提供由销售商对于一个或多个分级的投标条目的提交重新报价的机会，以提高销售商的分数。例如，买主用户典型地选择的、或对于其他分级的投标条目有高的等级的销售商可能比起另一个销售商具有较低的分数，以及买主用户可能想要给销售商提供对于具有较低等级的一个或多个分级的投标条目进行修订销售商投标应答数据的机会。

用于方便重新报价过程的示例性步骤被显示于图36。当分级机构成为知道对于特定的销售商在一个或多个分级的投标条目是的一个或多个低的等级时，分级机构可以邀请销售商对于一个或多个选择的分级的投标条目重新报价(步骤3600和3610)。对于重新报价的邀请(步骤3620)可以仅仅识别允许销售商重新报价的、特定的分级的投标条目，以防止销售商对于分级机构不想要重新分级的任何其他分级的投标条目重新报价。例如，重新报价可包括原先的销售商投标应答的拷贝，以及只使得由销售商选择的那些重新报价的投标条目能够输入新的销售商应答数据。老的销售商应答数据可被删除或连同新的应答数据一起被存储在数据库，供参考用途。另外，重新报价的邀请可以指示对于每个重新报价的投标条目的销售商等级，连同销售商对于每个重新报价的投标条目的排名，以及其他类似的信息，诸如对于重新报价的投标条目的高的和低的销售商等级。

如果销售商选择在买主约束的时间帧内不重新报价(步骤3630)，则原先的销售商分级和得分应用到销售商投标应答(步骤3640)。然而，如果销售商对于一个或多个重新报价的投标条目进行重新报价(步骤3630)，则销售商用户可以输入新的销售商应答数据到用于选择的重新报价投标条目的投标条目域(步骤3650)。在接收到重新报价后(步骤3660)，分级机构通过使用新的销售商应答数据对于重新报价的投标条目分级，以及随之修正销售商分数(步骤3670)。

用于发包投标和输入项目跟踪参数的示例性步骤被显示于图37。一旦完成所有的销售商投标应答分级和得分(步骤3700)，就可把投标发包给其中一个销售商。如果买主用户具有根据销售商分数和其他因素(例如，个人喜爱项、销售商的信誉的知识、销售商可用性的知识等等)选择销售商的权限(步骤3705)，则买主用户可以选择对于项目的销售商(步骤3710)。否则，具有最高的分数的销售商被发包给该投标(步骤3715)。

一旦对于项目的销售商被选择，系统通知项目管理机构(步骤3720)和投标发包所发包给的销售商(步骤3725)。此后，被发包的销售商和买主进入协商，以及项目的条款和条件被作出结论，正如传统上所完成的(步骤3730)。如果被发包的销售商和买主对于项目的条款和条件不能达成协议(步骤3735)，则买主可以重新开启投标过程，根据现有的销售商分数，根据新的销售商投标应答或根据二者来选择新的销售商(步骤3740)。然而，如果条款和条件都同意(步骤3735)，则买主和被发包的销售商可以把各种项目跟踪参数装载到系统(步骤3745)，诸如项目开始日期、项目结束日期、预计的项目经费(申请量)、指配的资源、项目阶段日程表、项目付费释放日程表、项目可交付、项目材料和项目经费，以便创建对于项目的购买申请。应当看到，附加的项目跟踪参数可被装载到系统中，以跟踪项目的进行，以及系统不限于这里描述的项目跟踪参数。一旦对于项目的购买申请被项目管理机构和买主的适当的批准用户批准(步骤3750)，项目就可开始。

用于项目管理机构和买主装载项目跟踪参数870到系统的示例性网页61的屏幕快照显示于图39A和39B。对于项目管理机构，如图39A所示，各种申请信息可被输入到系统，诸如购买申请创建日期，购买申请状态(它可被系统自动更新)、购买申请量、购买申请货币(例如，美元)、项目开始日期和项目结束日期。另外，项目管理机构也可把各种项目条款和条件输入到系统，诸如工作阐述、项目货物和业务可交付、项目承包、项目材料、指配的项目资源和可计费率、项目经费、项目阶段日程表和项目付费释放日程表。而且项目管理机构可以把管理机构用户指配给还没有被指配用于项目的各种管理机构用户角色。而且，可应用于项目的其他财务跟踪参数也可被输入到系统，诸如记帐指配、分类账代码、花费中心代码、项目代码、纳税代码、和记帐设备(plant)。

如图39B所示，销售商可以访问买主输入的数据，来更新在系统中的以前输入的项目跟踪参数870和/或把新的项目跟踪参数870输入到系统作为项目管理机构。例如，销售商可以输入以上讨论的一个或多个项目条款和条件。各方可以商定谁正在输入项目跟踪参数870，或双方可以输入和/或修正项目跟踪参数870，以及如果作出改变，系统可以向双方提供通知。应当看到，其他的项目跟踪参数也可以插入到系统，以及系统不限于图39A和39B所示的那些项目跟踪参数。

例如，如图40A和40B所示，纳税信息875也可被输入到系统作为项目跟踪参数870的一部分。纳税信息875可以被买主和销售商使用来保证在项目中对于财务管理和纳税义务方面考虑所有的纳税管理机构和可应用的纳税量。如图40A和40B所示，当对于活动创建申请条目行数，例如，在项目过程期间由销售商使用的材料时，买主和销售商可以在系统内指定对于正确地评估纳税所必须的所有适当的事务信息。

例如，如图40A所示，作为材料申请输入的一部分，买主和销售商可以通过输入与买主位置、起源位置、货运地址、实际的传递地址、销售商位置等等有关的位置信息，而发起或更新纳税信息875，所有这些信息可表示可应用的纳税管理机构。买主和销售商还可通过输入可应用的纳税管理机构和纳税百分数率而发起或更新纳税信息875。如图40B所示，当对于特定活动的购买定单被提交用于付费时，系统可接入由买主和销售商对于该特定的活动的以前输入的纳税百分数率，以及计算对于购买定单的纳税量。纳税信息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结构图)

列名称	数据类型	长度
			Submittal_ID	int	4
Bid_Tracking_ID	int	4
			RFX_Resource_Profile_ID	int	4
Profile_ID	int	4
			Candidate_ID	int	4
First_Name	varchar	50
			Last_Name	varchar	50
Middle_Name	varchar	50
			Name_Suffix	varchar	10
Citizenship_Country1	int	4
			Citizenship_Country2	int	4
Authorized_in_Work_Country	char	1
			Authorization_Description	varchar	500
Resume_Attachment	char	1
			Vendor_ID	int	4
Vendor_Contact_Name	varchar	100
			Vendor_Contact_Phone	varchar	50
Vendor_Contact_Email	varchar	100
			Record_Date	datetime	8
Submittal_Status_ID	int	4

                                    表59

                         示例性资源提交状态表(数据图)

Submittal_Status_ID	Submittal_Status	Display_Value
			1	New	Being_Reviewed_by_Admin
2	On_Hold_by_Admin	Admin_Temporary_Hold
			3	Declined_by_Admin	Candidate_Declined_by_Admin
4	Submitted_to_Buyer	Forwarded_for_Buyer_Review
			5	Declined_by_Buyer	Candidate_Declined_by_Buyer
6	Interview_Requested	Interview_Requested
			7	Interview_Scheduled	Interview_Scheduled
8	Interview_Conducted	Interview_Conducted
			9	Offer_Tendered	Buyer_Offer_Tendered
10	Offer_Accepted	Vendor_Offer_Accepted
			11	Candidate_Engaged	Candidate_Assigned_To_Order
12	On_Hold_by_Buyer	Buyer_Temporary_Hold
			13	Withdrawn	No_Longer_Available

用于批准资源候选者的示例性步骤显示于图38。对于被包括在销售商投标应答中的每个资源资料，销售商提交用于资源资料位置的潜在的资源候选者的简历(步骤3800)。买主审阅所有的简历和指配合格的资源候选者给资源资料位置(步骤3810)。

如果一个或多个资源候选者是不能接受的(例如，简历不表示该资源候选者具有对于资源资料必须的技艺)(步骤3820)，和对于资源资料位置没有其他可接受的候选者(步骤3830)，则买主可以重新公开投标过程，以保证用于项目的另一个销售商可提供必要的资源(步骤3840)。然而，如果所有的资源资料位置可被填充以合格的资源候选者，则买主和/或销售商把与每个指配的资源候选者(承包商)有关的资源信息输入到承包商数据库(步骤3850)。例如，关于承包商的个人信息，诸如承包商名字、地址、电话号码和雇员数目，可被输入到承包商数据库。另外，特定的与项目有关的承包商信息，诸如授权的可计费小时的总数、可计费率、授权的花费的总量和类型以及承包商在开始工作之前必须执行或提供的任何协定或文档，可被输入到承包商数据库。

一旦承包商信息被输入，系统就可鉴权承包商，用于计时和系统接入目的(步骤3860)。例如，系统可提供用户名字和密码给承包商用于系统登录和鉴权目的。另外，系统可能要求承包商在被允许接入计时系统之前执行一个或多个协定(例如，通过在线确认协定的条款)和/或提供一个或多个文档。

在初始登录和鉴权时显示给承包商的示例性网页61的屏幕快照显示于图42。网页列出在承包商可以开始进行项目工作之前必须被执行的几个文档。例如，承包商可能需要签署智识产权协定、保密协定、进行的代码(Code-of-Conduct)协定和临时工作确认协定。通过点击每个列出的文档，可以把显示协定的网页显示给承包商，以及承包商可点击接受按钮来执行协定。

用于存储承包商信息和确保从承包商得到相关的文档或由承包商同意相关的文档的示例性数据结构被显示于下面的表60-63。表60列出需要从承包商得到的或承包商需要在项目期间的某个时间点执行的各种样本文档。表60还列出用于得到或执行这样的文档的时间约束条件。表61列出承包商信息，诸如承包商身份、被授权的可计费小时数、被授权的花费量、各种文档的执行日期和承包商类型。表62列出特定的文件，以及标识承包商是否已执行或提供该文档以及这样的执行或提供的日期。应当看到，每个文件的分开的记录以表62的格式被存储。表63显示标识承包商类型的各种示例性信息，诸如承包商已为买主和还没有为买主工作的天数。然而，应当看到，也可以包括其他信息，以及系统不限于表60-63中显示的具体的信息。

                                   表60

                             示例性承包商文件表

Non-Employee_Document_ID	Document_Description	Due_Diligence_Method	Time_Constraint
				1	保密协定	电子询问/确认	Project_Duration
2	知识产权协定	电子询问/确认	Project_Duration
				3	进行代码协定	电子询问/确认	Project_Duration
4	临时工作分配协定	电子询问/确认	Project_Duration
				5	商业驾驶执照(CDL)	物理拷贝/购买数据库批准	License_Defined
6	药品测试文档	物理拷贝/购买数据库批准	6个月
				7	美国军事许可证	物理拷贝/购买数据库批准	定义的许可证
8	保税的	物理拷贝/购买数据库批准	定义的公证人
				9	遵从美国技术出口的公民	物理拷贝/购买数据库批准	Project_Duration
10	经考核的独立承包商	物理拷贝/购买数据库批准	Project_Duration
				11	W-2验证	物理拷贝/购买数据库批准	6个月
12	合格联盟成员	物理拷贝/购买数据库批准	定义的证书
				13	工作权利国家	物理拷贝/购买数据库批准	Project_Duration

                        表61

                   示例性承包商表

列名称	数据类型	长度
			Requistion_ID	int	4
Buyer_PO_#	varchar	20
			Current_Status_ID	int	4
Contractor_ID	int	4
			Time_Keeping_Only	char	1
Billable_Hours_Authorized	int	4
			Expenses_Authorized	money	8
Vendor_ID	int	4
			User_ID	int	4
Record_ID	int	4
			IP_Agreement_Date	datetime	8
ATW_Agreement	datetime	8
			Confidentiality_Agreement	datetime	8
Drug_Screen	datetime	8
			Code_Of_Conduct	datetime	8
Contractor_Type	int	4
			Profile_ID	int	4

                     表62

              示例性承包商执行数据表

列名称	数据类型	长度
			Contractor_ID	int	4
Non-Employee_Liability_Issue_ID	int	4
			Agreement_Executed	char	1
Agreement_Execution_Date	datetime
			Assessment_Complete_Date	datetime	1
Assessment_Disposition	char	1
			Assessment_User_ID	int	4
Tickler_Date	datetime

                    表63

        示例性承包商类型表(db结构图)

列名称	数据类型	长度
			Contractor_Type_ID	Int	4
Contractor_Type	Varchar	50
			Notes	Varchar	500
Tenure_Days	Numeric	9
			Separation_Days	Numeric	9

在下面的表64-79显示用于存储项目跟踪参数的数据结构的例子。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于跟踪项目的进行所必须的所有的域。该表格以分级结构和关联的方式进行相关，正如下面结合图41讨论的。

下面的表64显示样本的一般购买申请信息，它可被存储在数据库中表“tblPurchaseReq”1000中，如图41所示。例如，这样的一般购买信息可包括由系统指配给购买申请的身份，买主和销售商、申请创建日期、申请量、用于与购买申请有关的投标(投标请求和投标应答)的投标跟踪号、项目开始和结束日期、以及任何其他适当的购买申请信息。然而，应当看到，也可以包括其他信息，以及系统不限于表64中所显示的具体的信息。现在参考图41上的数据库表结构1150，表“tblPurchaseReq”1000被显示为束缚到表“tblPurchaseReqContrators”1012和表“tblluContratorTypes”1013，它们分别包括相应于以上表61和63的数据结构格式的信息，以便把指配的承包商与购买申请相联系。

                       表64

                   tblPurchaseReq

列名称	数据类型	长度
			Requisition_ID	int	4
Req_Created_Date	datetime	8
			Req_Received_Date	datetime	8
Req_Process_Date	datetime	8
			Bid_Tracking_ID	int	4
Requistion_Amount	money	8
			Currency	int	4
Project_Start	datetime	8
			Project_End	datetime	8
Process_Fee	numeric	9
			Vendor_ID	int	4
Buyer_PR_#	varchar	20
			PR_Version	numeric	9
Vendor_PR_#	varchar	20
			Version_Effective_Date	datetime	8
Req_Processor	int	4
			Current_Status_ID	int	4

下面的表65-70显示与纳税代码、记帐设备、花费中心、项目代码、记帐指配和其他类似的买主的具体购买申请信息有关的样本的具体购买申请信息，它们可被存储在数据库中各个表“tblPurchaseReqTaxCode”1001、“tblPurchaseReqAcctPlant”1002、“tblPurchaseReqAcctCostCenter”1003、“tblPurchaseReqProjectCodes”1004、“tblPurchaseReqAcctGL”1005和“tblPurchaseReqAcctAssignment”1006中，如图41所示。然而，应当看到，也可以包括与购买请求有关的附加的表和信息，这取决于购买申请请求。表“tblPurchaseReqTaxCode”1001、“tblPurchaseReqAcctPlant”1002、“tblPurchaseReqCostCenter”1003、“tblPurchaseReqProjectCodes”1004、“tblPurchaseReqAcctGL”1005和“tblPurchaseReqAcctAssignment”1006被束缚到表“tblPurchaseReq”1000，以便把具体的购买申请信息与一般购买申请信息相联系。

                   表65

          tblPurchaseReqTaxcode

列名称	数据类型	长度
			Requistion_ID	int	4
Buyer_PR_#	varchar	20
			Tax_Code	varchar	10
Current_Status_ID	int	4
			Record_ID	int	4

                  表66

          tblPurchaseReqAccPlant

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Accounting_Plant	varchar	10
Record_ID	int	4
			Cunrrent_Status_ID	int	4

                      表67

            tblPurchaseAcctCostCenter

列名称	数据类型	长度
			Requistion_ID	int	4
[Billable_Dept/Cost_Center]	nvarchar	10
			Buyer_PR_#	varchar	20
Record_ID	int	4
			Current_Status_ID	int	4

                      表68

            tblPurchaseReqProjectCodes

列名称	数据类型	长度
			Purchase_Req_ID	int	4
Buyer_PR_#	varchar	20
			Project_Code	varchar	20
[Billable_Dept/Cost_Center]	nvarchar	20
			Record_ID	int	4
Current_Status_ID	int	4

                表69

         tblPurchaseReqAcctGL

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			G_L_Account	varchar	20
Record_ID	int	4
			Current_Status_ID	int	4

                    表70

          tblPurchaseReqAcctAssignment

列名称	数据类型	长度
			Requistion_ID	int	4
Buyer_PR_#	varchar	20
			Account_Assignment	varchar	10
Current_Status_ID	int	4
			Record_ID	int	4

下面的表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结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Deliverable_Description	varchar	1000
Anticipated_Completion_Date	datetime	8
			Payment_Amount	money	8
Partial_Payment_Authorized	char	1
			Current_Status_ID	int	4
Vendor_ID	int	4
			User_ID	int	4
Record_ID	int	4
			Record_Date	datetime	8

                    表72

    示例的tblPurchaseReqPayTimespan(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Current_Status_ID	int	4
Work_Start_Date	datetime	8
			Payment_Release_Date	Datetime	8
Payment_Amount	Money	8
			Vendor_ID	Int	4
User_ID	Int	4
			Record_ID	Int	4

                      表73

      示例的tblPurchaseReqPayUnits(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Current_Status_ID	int	4
Unit_Completion_Description	varchar	1000
			Unit_Count	numeric	9
Unit_Cost	money	8
			Partial_Payment_Authorized	char	1
Vendor_ID	int	4
			User_ID	int	4
Record_ID	int	4

                      表74

    示例的tblPurchaseReqPayMaterials(db结构图)

列名称	数据类型	长度
			Requisition_ID	Int	4
Buyer_PR_#	Varchar	20
			Vendor_ID	int	4
Material_Name	varchar	100
			Material_Description	varchar	500
Material_Manufacturer	varchar	100
			Unit_Cost	money	8
Unit_Count	numeric	9
			Line_Item_Cost	money	8
Currency_ID	int	4
			Current_Status_ID	int	4
User_ID	int	4
			Record_ID	int	4
Record_Date	datetime	8

                        表75

   示例的tblPurchaseReqPayProjectExpenses(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Project_Expense_Description	varchar	500
Maximum_Threshold	money	8
			Currency_ID	int	4
User_ID	int	4
			Vendor_ID	int	4
Current_Status_ID	int	4
			Record_ID	int	4
Record_Date	datetime	8

下面的表76和77显示对于被指配以购买申请的承包商的、与付费率有关的样本的信息。例如，承包商付费率信息可表示付费类型(例如，按小时、固定、超时等等)和付费率量(例如，每小时可计费率、每个超时小时的计费率、可计费量)。付费率信息可被存储在数据库中表“tblPurchaseReqPayRates”1014和表“tblluContractorPayRateTypes”1015中，它们在图41上被显示为束缚到表“tblPurchaseReq”1000，把付费率信息与购买申请相联系。应当看到，用于每个承包商的每个付费率类型的分开付费率记录可被存储在表“tblPurchaseReqPayRates”1014中。还应当看到，取决于购买申请要求，可以包括附加的表或信息。

                   表76

      tblPurchaseReqPayRates(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Current_Status_ID	int	4
Contractor_ID	int	4
			Pay_Rate_Type	int	4
Pay_Rate	money	8
			Currency_ID	int	4
User_ID	int	4
			Vendor_ID	int	4
Record_ID	int	4

                    表77

      tblluContractorRateTypes(db结构图)

列名称	数据类型	长度
			Hour_Type_ID	Int	4
Hour_Type_Description	varchar	50

下面的表78和79显示对于被指配以购买申请的承包商的、与承包商经费有关的样本的付费信息。例如，承包商经费信息可表示花费类型和对于花费分配的最大量。承包商经费信息可被存储在数据库中表“tblPurchaseReqPayContractorExpenses”1016和表“tblluContractorExpenseTypes”1017中，它们在图41上被显示为束缚到表“tblPurchaseReq”1000，把承包商经费信息与购买申请相联系。应当看到，用于每个承包商的每个承包商经费类型的分开的承包商经费记录可被存储在表“tblPurchaseReqPayContractorExpenses”1016中。还应当看到，取决于购买申请要求，可以包括附加的表或信息。

                    表78

tblPurchaseReqPayContractorExpenses(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Buyer_PR_#	varchar	20
			Current_Status_ID	int	4
Contractor_ID	int	4
			Expense_Type_ID	int	4
Maximum_Threshold	money	8
			Currency_ID	int	4
User_ID	int	4
			Vendor_ID	int	4
Record_ID	int	4

                      表79

     tblluContractorPayExpenseTypes(db结构图)

列名称	数据类型	长度
			Contractor_Expenst_Type_ID	Int	4
Contractor_Expense_Type	varchar	50

后投标活动

一旦项目开始，项目管理机构(或买主)就可以通过计时系统监视项目的过程，其中承包商把时间输入到用于执行项目工作的时间卡。时间卡可被存储来对于申请付费信息进行项目执行的评估，和/或根据工作的时间生成付费凭证，这取决于申请付费信息。例如，如果申请付费量至少部分基于以特定的付费率的特定承包商的预计数目的可计费小时以及承包商在预计数目的计费小时下完成项目，则项目管理机构和销售商可能能够重新协商申请付费量，该申请付费量初始地是根据可交付、时间帧或单位对付费设置的。

现在参照图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中显示的具体信息。表“tblTimeCard”1050在图47上被显示为被束缚到表“tblPurchaseReqContractors”1012，它又被束缚到表“tblPurchaseReq”1000，这两者都如上面结合图41讨论的，以便把时间卡与承包商和购买申请相联系。另外，图41上显示的各种其他的表在图47上被显示，以用来显示在各种购买申请表与时间卡和承包商经费凭证表之间的相互关系。

               表80

      示例性tblTimeCard(db结构图)

列名称	数据类型	长度
			Time_Card_ID	int	4
tcStatus_ID	int	4
			Requisition_ID	int	4
Contractor_ID	int	4
			Vendor_ID	int	4
Billable_Time	char	1
			HM_Submitter_ID	int	4
Vendor_Submitter_ID	int	4
			Reviewer_ID	int	4
Week_Ending_Date	datetime	8
			Record_Create_Date	datetime	8
Last_Edit_Date	datetime	8
			Submit_Date	datetime	8
Review_Date	datetime	8
			Approval_Date	datetime	8
Date_Rejected	datetime	8
			Contractor_Notes	varchar	1000
Client_Notes	varchar	1000

被存储在表“tblTimeCard”1050中的时间卡状态识别符可以从表“tblTimeCardStatus”1051中被选择，该表存储时间卡状态类型(例如，暂时保存、提交、批准、拒绝等等)和它们的相关的时间卡状态识别符。

表81显示样本的详细的计时信息，它可被存储在数据库中表“tblTimeCardDetails”1052中，如图47所示。例如，这样的详细的计时信息可包括作为以特定的付费率类型在特定的一天工作的、输入的小时数，与付费率类型有关的付费率以及其他详细的计时信息。表“tblTimeCardDetails”1052被显示为束缚到表“tblTimeCard”1050，把详细的计时信息与一般计时信息相联系。另外，表“tblTimeCardDetails”1052被束缚到表“ tblluDayCode”1053，把被存储在表“tblTimeCardDetails”1052中的日代码与特定的日相联系。应当看到，以表81的格式的分开的记录被存储在用于在承包商输入时间的每日的每种付费率类型的表“tblTimeCardDetails”1052。还应当看到，可以包括其他表和计时信息，以及系统不限于图47所示的具体的表和计时信息。

                       表81

        示例性tblTimeCardDetails(db结构图)

列名称	数据类型	长度
			Time_Card_ID	int	4
Record_ID	int	4
			Pay_Rate_Type_ID	int	4
Day_Code	int	4
			Quantity	float	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	nvarchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Account	varchar	20
Pay_Rate	money	8

下面的表82显示样本的一般承包商经费凭证信息，它可被存储在数据库中的表“tblContractorExpenseVoucher”1054中，如图47所示。例如，这样的一般承包商经费凭证信息可包括经费凭证识别符、相关的购买申请识别符、承包商识别符、销售商识别符、与经费凭证有关的星期结束日期、创建日期、审阅日期和关于经费凭证是否被批准的指示。然而，应当看到，可以包括其他信息，以及系统不限于表82所示的具体信息。表“tblContractorExpenseVoucher”1054被显示为束缚到表“tblPurchaseReqContrators”1012，它被束缚到表“tblPurchaseReq”1000，它们是以上结合图41讨论的，以便把承包商经费凭证与具体的承包商和购买申请相联系。

                   表82

  标准tblContractorExpensesVoucher(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Expense_Voucher_ID	int	4
			tcStatus_ID	int	4
Contractor_ID	int	4
			Vendor_ID	int	4
HM_Submitter_ID	int	4
			Vendor_Submitter_ID	int	4
Approver_ID	int	4
			Week_Ending_Date	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Submit_Date	datetime	8
			Approval_Date	datetime	8
Date_Rejected	datetime	8
			Contractor_Notes	varchar	1000
Client_Notes	varchar	1000

下面的表83显示样本的详细的承包商经费凭证信息，它可被存储在数据库中表“tblContractorExpensesVoucherDetails”1055中，如图47所示。例如，这样的详细的经费凭证信息可包括在特定的一天特定的花费类型的花费量以及其他详细的经费凭证信息。表“tblContractorExpensesVoucherDetails”1055被显示为束缚到表“tblContractorExpensesVoucher”1054，把详细的经费凭证信息与一般经费凭证信息相联系。另外，表“tblContractorExpensesVoucherDetails”1055被束缚到表“tblluDayCode”1053，把被存储在表“tblContractorExpensesVoucherDetails”1055中的日代码与特定的日相联系。应当看到，以表83的格式的分开的记录被存储在用于在承包商输入量的每日的每种花费类型的表“tblContractorExpensesVoucherDetails”1055。还应当看到，可以包括其他表和承包商经费凭证信息，以及系统不限于图47所示的具体的表和承包商经费凭证信息。

                       表83

 标准tblContractorExpensesVoucherDetails(db结构图)

列名称	数据类型	长度
			Expense_Voucher_ID	int	4
Record_ID	int	4
			Expense_Type_ID	int	4
Day_Code	int	4
			Expense_Amount	money	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	varchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Accout	varchar	20

现在参照图48，有多种不同类型的凭证信息1160可被输入到系统和被存储在数据库155，用于生成由买主或项目管理机构付费给发包的销售商的可付费凭证1180。例如，凭证信息1160可包括计时凭证信息1160a，它包括由承包商输入的计时信息1150(以上的图45所示的)和通过被输入的关于计时信息的项目工作跟踪参数870(以上的图39和40所示的)确定的申请付费信息。凭证信息也可包括项目经费凭证信息1160b、项目可交付凭证信息1160c、项目材料凭证信息1160d、承包商经费凭证信息1160e、项目单位完成凭证信息1160f、和项目定时付费释放凭证信息1160g。系统可以根据以前在其他上下文(例如，项目跟踪参数入口、计时入口、承包商经费入口和/或项目经费入口)输入的凭证信息1160自动生成付费凭证1180，或销售商或买主/项目管理机构可以生成可支付的凭证1180和把凭证信息11160的各种可应用的部分(例如，单位完成入口或可交付完成入口)输入到可支付的凭证1180。

现在参照图49，图上显示在凭证处理和付费系统中牵涉到的示例性步骤。初始地，各种项目跟踪参数(例如，购买申请信息)被输入到系统(步骤4400)，以及可计费的和不可计费的、用于货物和业务的所有的销售商责任被存储在数据库(步骤4410)。当销售商提供被授权的货物或业务时(如由输入的销售商责任确定的)(步骤4420)，销售商接入该系统，以记录被执行的货物或业务和请求为货物或业务付费(步骤4430)。在其他实施例中，付费可以由系统在一定的时间间隔内被自动请求。系统根据项目跟踪参数和其他凭证信息(例如，计时信息、花费、材料等等)生成凭证(步骤4440)，以及把凭证路由到适当的买主用户或管理机构用户，用于凭证的批准(步骤4450)。

如果凭证没有被批准(步骤4460)，则销售商被告知和被提供以重新提交凭证的任选项(步骤4470)。如果凭证被批准(步骤4460)，则销售商被告知凭证批准(步骤4480)。如果凭证是可计费的凭证(步骤4490)，则根据规定的日程表(使用系统或买主约束条件)，处理凭证用于电子货品计价(步骤4495)。例如，系统可以采用批处理，收集在预先指定的时间周期期间批准的对于买主(对于一个或多个项目)的所有的付费凭证。所有的发票可以以基于买主技术规范的格式或以系统规定的格式被生成。买主接收发票(步骤4498)和经由预先配置的方法把发票的付款发放给销售商(例如，EFI、支票等等)(步骤4499)。

在下面的表84-92中显示用于存储凭证信息到可支付的凭证中和生成付费凭证记录的示例性数据库结构。为了简化起见，数据结构被显示为组织成表格的格式，每个表格包括对于存储凭证信息所必须的所有的域。表格以分级结构和关联的方式与被存储在数据库中的其他表相关，正如下面结合图50讨论的。

下面的表84显示样本的一般项目单位完成凭证信息，它可被存储在表“tblVoucherUnits”1060中数据库表结构1170中，如图50所示。例如，一般项目单位完成凭证信息可包括单位凭证识别符、相关的购买申请识别符、关于与单位完成有关的所有的时间卡是否被批准的指示、销售商识别符、与凭证信息有关的星期结束日期、创建日期、审阅日期和关于凭证信息是否被批准的指示。“tblVoucherUnits”1060被显示为束缚到表“tblPurchaseReq”1000，其在上面结合图41讨论，以便把凭证信息与购买申请相联系。另外，图41所示的各种其他表在这里图50上被显示为表明在各种购买申请表与凭证表之间的相互关系。应当看到，以表84的格式的分开的记录被存储在用于每个可支付单位凭证的表“tblVoucherUnits”1060中。

而且，虽然未示出，但图47上显示的表“tblContractorExpenseVoucher”1054也被认为是用于生成可支付凭证的凭证表。应当看到，也可以包括其他表格和凭证信息，以及系统不限于在图50上显示的具体的表和凭证信息。

                  表84

          tblVoucherUnits(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Unit_Voucher_ID	int	4
			tcStatus_ID	int	4
Vendor_ID	int	4
			Week_Ending_Date	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Submit_Date	datetime	8
			Approval_Date	datetime	8
Review_Date	datetime	8
			Date_Rejected	datetime	8
Reviewer_ID	int	4
			Vendor_Notes	varchar	1000
Buyer_Notes	varchar	1000

下面的表85显示样本的详细的项目单位完成凭证信息，它可被存储在数据库中表“tblVoucherUnitsDetails”1061中，如图50所示。例如，这样的详细的项目单位完成凭证信息可包括单位完成的说明、被授权的单位的数目、每个单位的花费、完成的单位数和其他详细的项目单位完成凭证信息。表“tblVoucherUnitsDetails”1061被显示为束缚到表“tblVoucherUnits”1060，以便把详细的项目单位完成凭证信息与一般项目单位完成凭证信息相联系。另外，表“tblVoucherUnitsDetails”1061被束缚到表“tblPurchaseReqPayUnits”1009，以便把申请单位付费信息与项目单位完成凭证信息相联系。

应当看到，以表85的格式的分开的记录被存储在用于每个可支付的单位凭证的表“tblVoucherUnitsDetails”1061中。还应当看到，也可以包括其他表格和项目单位完成凭证信息，以及系统不限于在图50上显示的具体的表和项目单位完成凭证信息。

                     表85

         tblVoucherUnitsDetails(db结构图)

列名称	数据类型	长度
			Unit_Voucher_ID	int	4
puRecord_ID	int	4
			Unit_Completion_Description	varchar	1000
Units_Authorized	numeric	9
			Unit_Cost	money	8
Units_Completed	numeric	9
			Line_Item_Cost	money	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	nvarchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Account	varchar	20
Record_ID	int	4

下面的表86显示样本的一般时间完成凭证信息，它可被存储在数据库中表“tblVoucherTimePayment”1062中，如图50所示。例如，一般时间完成凭证信息可包括时间凭证识别符、相关的购买申请识别符、关于与时间完成有关的所有的时间卡是否被批准的指示、销售商识别符、与凭证信息有关的星期结束日期、创建日期、审阅日期和关于凭证信息是否被批准的指示。表“tblVoucherTimePayment”1062被显示为束缚到表“tblPurchaseReq”1000，它是以上结合图41讨论的，以便把凭证信息与购买申请相联系。应当看到，以表86的格式的分开的记录被存储在用于每个可支付的时间凭证的表“tblVoucherTimePayment”1062中。

                      表86

        tblVoucherTimePayment(db结构图)

列名称	数据类型	长度
			Requistion_ID	int	4
Time_Pay_Voucher_ID	int	4
			tcStatus_ID	int	4
Vendor_ID	int	4
			Week_Ending_Date	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Approval_Date	datetime	8
			Date_Rejected	datetime	8
Review_ID	int	4
			Vendor_Notes	varchar	1000
Buyer_Notes	varchar	1000

下面的表87显示样本的详细的时间完成凭证信息，它可被存储在数据库中表“tblVoucherTimePaymentDetails”1063中，如图50所示。例如，这样的详细的时间完成凭证信息可包括工作开始日期、付费释放日期、付费量和其他详细的时间完成凭证信息。表“tblVoucherTimepaymentDetails”1063被显示为束缚到表“tblVoucherTimepayment”1062，以便把详细的时间完成凭证信息与一般时间完成凭证信息相联系。另外，表“tblVoucherUnitsTimepaymentDetails”1063被束缚到表“tblPurchaseReqPayTimeSpan”1008，以便把申请时间付费信息与时间完成凭证信息相联系。

应当看到，以表87的格式的分开的记录被存储在用于每个可支付的单位凭证的表“tblVoucherTimePaymentDetails”1063中。还应当看到，也可以包括其他表格和时间完成凭证信息，以及系统不限于在图50上显示的具体的表和时间完成凭证信息。

                        表87

         tblVoucherTimePaymentDetails(db结构图)

列名称	数据类型	长度
			Time_Pay_Voucher_ID	int	4
pptRecord_ID	int	4
			Work_Start_Date	datetime	8
Payment_Release_Date	datetime	8
			Payment_Amount	money	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	nvarchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Account	varchar	20
Record_ID	int	4

下面的表88显示样本的一般项目经费凭证信息，它可被存储在数据库中表“tblVoucherProjectExpense”1064中，如图50所示。例如，一般项目经费凭证信息可包括项目经费凭证识别符、相关的购买申请识别符、关于与项目经费(如果有的话)有关的所有的时间卡是否被批准的指示、销售商识别符、与凭证信息有关的星期结束日期、创建日期、审阅日期和关于凭证信息是否被批准的指示。表“tblVoucherProjectExpense”1064被显示为束缚到表“tblPurchaseReq”1000，它是以上结合图41讨论的，以便把凭证信息与购买申请相联系。应当看到，以表88的格式的分开的记录被存储在用于每个可支付的项目经费凭证的表“tblVoucherProjectExpense”1064中。

                      表88

         tblVoucherProjectExpense(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Project_Expense_Voucher_ID	int	4
			tcStatus_ID	int	4
Vendor_ID	int	4
			Week_Ending_Date	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Submit_Date	datetime	8
			Approval_Date	datetime	8
Date_Rejected	datetime	8
			Reviewer_ID	int	4
Vendor_Notes	varchar	1000
			Buyer_Notes	varchar	1000

下面的表89显示样本的详细的项目经费凭证信息，它可被存储在数据库中表“tblVoucherProjectExpenseDetails”1065中，如图50所示。例如，这样的详细的项目经费凭证信息可包括发生花费的日期、项目经费的说明、项目经费量、和其他详细的项目经费凭证信息。表“tblVoucherProjectExpenseDetails”1065被显示为束缚到表“tblVoucherProjectExpense”1064，以便把详细项目经费凭证信息与一般项目经费凭证信息相联系。另外，表“tblVoucherProjectExpenseDetails”1065被束缚到表“tblPurchaseReqPayProjectExpense”1011，以便把申请项目经费付费信息与项目经费凭证信息相联系。

应当看到，以表89的格式的分开的记录被存储在用于每个可支付的项目经费凭证的表“tblVoucherProjectExpenseDetails”1065中。还应当看到，也可以包括其他表格和项目经费凭证信息，以及系统不限于在图50上显示的具体的表和项目经费凭证信息。

                    表89

      tblVoucherProjectExpenseDetails(db结构图)

列名称	数据类型	长度
			Project_Expense_Voucher_ID	int	4
Expense_Incurred_Date	datetime	8
			ppeRecord_ID	int	4
Project_Expense_Description	varchar	500
			Project_Expense_Amount	money	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	nvarchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Account	varchar	20
Record_ID	int	4

下面的表90显示样本的一般材料凭证信息，它可被存储数据库中表“tblVoucherMaterials”1066中，如图50所示。例如，一般材料凭证信息可包括材料凭证识别符、相关的购买申请识别符、关于与材料(如果有的话)有关的所有的时间卡是否被批准的指示、销售商识别符、与凭证信息有关的星期结束日期、创建日期、审阅日期和关于凭证信息是否被批准的指示。表“tblVoucherMaterials”1066被显示为束缚到表“tblPurchaseReq”1000，它是以上结合图41讨论的，以便把凭证信息与购买申请相联系。应当看到，以表90的格式的分开的记录被存储在用于每个可支付的材料凭证的表“tblVoucherMaterials”1066中。

                   表90

         tblVoucherMaterials(db结构图)

列名称	数据类型	长度
			Reqisition_ID	int	4
Material_Voucher_ID	int	4
			tcStatus_ID	int	4
Vendor_ID	int	4
			Week_Ending_Date	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Submit_Date	datetime	8
			Approved_Date	datetime	8
Reviewed_Date	datetime	8
			Date_Rejected	datetime	8
Reviewer_ID	int	4
			Vendor_Notes	varchar	1000
Buyer_Notes	varchar	1000

下面的表91显示样本的详细的材料凭证信息，它可被存储在数据库中表“tblVoucherMaterialsDetails”1067中，如图50所示。例如，这样的详细的材料凭证信息可包括发生材料花费的日期、材料的名称、材料的说明、购买的材料的单位数目、每个材料单位的花费和其他详细的项目经费凭证信息。表“tblVoucherMaterialsDetails”1067被显示为束缚到表“tblVoucherMaterials”1066，以便把详细材料凭证信息与一般材料凭证信息相联系。另外，表“tblVoucherMaterialsDetails”1067被束缚到表“tblPurchaseReqPayMaterials”1010，以便把申请材料付费信息与材料凭证信息相联系。

应当看到，以表91的格式的分开的记录被存储在用于每个可支付的材料凭证的表“tblVoucherMaterialsDetails”1067中。还应当看到，也可以包括其他表格和材料凭证信息，以及系统不限于在图50上显示的具体的表和材料凭证信息。

                    表91

      tblVoucherMaterialsDetails(db结构图)

列名称	数据类型	长度
			Material_Voucher_ID	int	4
Expense_Incurred_Date	datetime	8
			ppmRecord_ID	int	4
Material_Name	varchar	100
			Material_Description	varchar	500
Unit_Count	numeric	9
			Unit_Cost	money	8
Line_Item_Cost	money	8
			[Billable_Dept/Cost_Center]	nvarchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	1-
			G_L_Account	varchar	20
Record_ID	int	4

下面的表92显示样本的一般可交付凭证信息，它可被存储在数据库中表“tblVoucherDeliverables”1068中，如图50所示。例如，一般可交付凭证信息可包括可交付凭证识别符、相关的购买申请识别符、关于与可交付(如果有的话)有关的所有的时间卡是否被批准的指示、销售商识别符、与凭证信息有关的星期结束日期、创建日期、审阅日期和关于凭证信息是否被批准的指示。表“tblVoucherDeliverables”1068被显示为束缚到表“tblPurchaseReq”1000，它是以上结合图41讨论的，以便把凭证信息与购买申请相联系。应当看到，以表92的格式的分开的记录被存储在用于每个可支付的可交付凭证的表“tblVoucherDeliverables”1068中。然而，应当看到，也可以包括其他信息，以及系统不限于在表92上显示的具体的信息。

                   表92

         tblVoucherDeliverables(db结构图)

列名称	数据类型	长度
			Requisition_ID	int	4
Deliverable_Voucher_ID	int	4
			tcStatus_ID	int	4
Vendor_ID	int	4
			Week_Ending_ID	datetime	8
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
Submit_Date	datetime	8
			Approval_Date	datetime	8
Review_Date	datetime	8
			Date_Rejected	datetime	8
Reviewer_ID	int	4
			Vendor_Notes	varchar	1000
Buyer_Notes	varchar	1000

下面的表93显示样本的详细的可交付凭证信息，它可被存储在数据库中表“tblVoucherDeliverablesDetails”1069中，如图50所示。例如，这样的详细的可交付凭证信息可包括可交付的说明、可交付的预计完成日期、可交付的实际完成日期、请求的付费量、和其他详细的可交付凭证信息。表“tblVoucherDeliverablesDetails”1069被显示为束缚到表“tblVoucherDeliverables”1068，以便把详细的可交付凭证信息与一般可交付凭证信息相联系。另外，表“tblVoucherDeliverablesDetails”1069被束缚到表“tblPurchaseReqPayDeliverables”1007，以便把申请可交付付费信息与可交付凭证信息相联系。

应当看到，以表93的格式的分开的记录被存储在用于每个可支付的可交付凭证的表“tblVoucherDeliverablesDetails”1069中。还应当看到，也可以包括其他表格和可交付凭证信息，以及系统不限于在图50上显示的具体的表和可交付凭证信息。

                        表93

      tblVoucherDeliverableExpenseDetails(db结构图)

列名称	数据类型	长度
			Deliverable_Vendor_ID	int	4
ppdRecord_ID	int	4
			Deliverable_Description	varchar	1000
Anticipated_Completion_Date	datetime	8
			Actual_Completion_Date	datetime	8
Payment_Amount_Requested	money	8
			Account_Assignment	varchar	10
[Billable_Dept/Cost_Center]	nvarchar	10
			Accounting_Plant	varchar	10
Project_Code	varchar	20
			Tax_Code	varchar	10
G_L_Account	varchar	20
			Record_ID	int	4

下面的表94显示样本的付费凭证信息，它可被存储在数据库中表“tblPaidVoucherRecords”1070中，如图50所示。例如，所述付费凭证信息可包括发票号、由买主和销售商指配的购买申请身份、凭证批准日期、批准者名字、凭证的类型(例如，时间卡、承包商经费、项目经费、可交付、时间完成或单位完成)和相关的凭证识别符、发票量、付费日期和其他付费凭证信息。

表“tblPaidVoucherRecords”1070被显示为束缚到表“tblPurchaseReq”1000，它是以上结合图41讨论的，以便把付费凭证信息与购买申请相联系。应当看到，以表94的格式的分开的记录被存储在用于每个付费凭证的表“tblPaidVoucherRecords”1070中。然而，应当看到，也可以包括其他信息，以及系统不限于在表94上显示的具体的信息。

                         表94

          示例性tblPaidVoucherRecords(db结构图)

列名称	数据类型	长度
			Invoice_ID	int	4
Buyer_PR_#	varchar	20
			PR_Version	numeric	9
Vendor_PR_#	varchar	20
			Approval_Date	datetime	8
Approver_Name	varchar	100
			Approver_Employee_ID	nvarchar	10
Time_Card_ID	int	4
			Expense_Voucher_ID	int	4
Material_Voucher_ID	int	4
			Project_Expense_Voucher_ID	int	4
Deliverable_Voucher_ID	int	4
			Time_Pay_Voucher_ID	int	4
Unit_Voucher_ID	int	4
			Invoice_Amount	money	8
Account_Assignment	varchar	10
			[Billable_Dept/Cost_Center]	varchar	10
Accounting_Plant	varchar	10
			Project_Code	varchar	20
Tax_Code	varchar	10
			G_L_Account	varchar	20
Currency_ID	int	4
			File_Extract_Date	datetime	8
EDI_File_Transmission_Date	datetime	8
			Buyer_Check_Register_Date	datetime	8
Vendor_Payment_Date	datetime	8
			Vendor_AP_Register_#	varchar	20
Vendor_Check_#	varchar	25
			Vendor_Check_Issuance_Date	datetime	8
Record_ID	int	4

现在参照图51，图上显示说明项目的财务状态的示例性网页61的屏幕快照。这个网页是以一个或多个格式对于买主、销售商、和/或管理机构可接入的，这取决于系统约束条件。正如可以从图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牵涉到的多个项目有关的分析数据的报告。

现在转到图53，图上显示用于输入项目进行数据1190的示例性功能。图53上显示按照本发明的实施例的、用于输入项目进行数据的项目进行工具121和比较工具123。项目进行工具121和比较工具123可包括对于执行工具的功能所需要的任何硬件、软件和/或固件，它们可以在服务器120或附加服务器(未示出)内实施。例如，项目进行工具121和比较工具123可以处在服务器120内的软件模块128内，如图3B所示。

在一个实施例中，项目进行数据1190可以由买主、销售商或管理机构通过项目进行工具180直接输入到数据库155。买主、销售商或管理机构可以分别经由买主浏览器20a、销售商浏览器20b、或管理机构浏览器20c，和数据网40接入计算机系统100的服务器120。买主模块110、销售商115或管理机构模块135与项目进行工具121相接口，把网页分别推送到买主浏览器20a、销售商浏览器20b、或管理机构浏览器20c，征求项目进行数据。项目进行工具121接入数据库155，用由买主、销售商和/或管理机构输入的项目进行数据填充与特定的项目有关的项目进行数据域。例如，项目进行数据可包括由买主、销售商和/或管理机构对于至今的状态或个人项目满意度作出的评注。

在从买主、销售商或管理机构接收项目进行数据1190后，项目进行工具121还可被配置成自动生成给其他方的消息(例如，电子邮件消息)，把新的项目进行数据1190告知它们，由此使得其他方能够输入附加项目进行数据1190，澄清、应答、或提供与以前输入的项目进行数据1190无关的数据。

在其他实施例中，比较工具123可以根据项目跟踪参数870和与特定的项目有关的凭证信息1160的比较结果把项目进行数据1190自动输入到数据库155。比较工具从数据库155检索必不可少的项目跟踪参数870和凭证信息1160，执行检索的项目跟踪参数870和凭证信息1160的比较或分析，以及根据比较或分析的结果，把任何必须的项目进行数据1190输入到数据库155内与项目有关的数据域。

作为例子，比较工具123可被配置成对于新的凭证信息1160输入而监视数据库155，或否则在新的凭证信息1160输入后被触发成将输入的凭证信息1160与以前存储的、对于项目的项目跟踪参数870进行比较。凭证信息1160可以包含花费、定时或与项目跟踪参数870进行比较的其他信息。比较的结果可以作为项目进行数据1190被存储在数据库155中。例如，凭证信息1160可以表示由买主50对于项目支付的发货单量，以及比较工具123可以把发货单量与申请量进行比较以确定是否存在差异。在这种情形下，项目进行数据1190可包括花费状态的指示，诸如欠预算、超预算或在预算中、以及超过预算的量或欠预算的量，如果有的话。

作为另一个例子，比较工具123可被配置成对于特定的项目跟踪参数870搜索数据库155，以及输入项目跟踪参数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显示样本的可交付的项目进行数据，它们可被存储在表“tblDeliverableTrackPerfomance”1080和表“lkpDeliverableStatus”1081中的数据库表结构1185中，如图57所示。可交付的项目进行数据可包括从表“lkpDeliverableStatus”1081确定的可交付状态。例如，可交付状态可以是“未完成-当前”、“未完成-超期”、“部分完成-当前”、“部分完成-超期”、“完成-按时”、“完成-超期”、或“完成-提早”。与状态有关的识别符可以连同与被存储在表“tblPurchaseReqPayDeliverables”1007中的可交付项目跟踪参数有关的识别符、当前的状态(例如，推迟或提早的天数)和任何用户票据一起被存储在表“tblDeliverableTrackPerfomance”中。

例如，如果买主、销售商或其他用户已输入与可交付的状态有关的任何评注，则这些评注可被存储在表“tblDeliverableTrackPerfomance”1080中。除了评注以外，输入评注的用户的识别符，连同评注被输入的日期一起也可被存储。如果系统被配置成告知销售商：买主何时输入评注，则销售商应答的状态(例如，还没有应答、无应答、应答)也可被存储。

表“tblDeliverableTrackPerfomance”1080和“lkpDeliverableStatus”1081被显示为束缚到表“tblPurchaseReqPayDeliverables”1007，它又被束缚到表“tblPurchaseReq”1000，二者都如以上结合图41讨论的，以便把项目进行数据与凭证信息和项目跟踪参数(例如，购买申请)相联系。另外，在图41上显示的各种其他表在这里的图57上被显示，以显示在各种项目进行表、凭证表与购买申请表之间的相互关系。应当看到，以表95的格式的分开的记录可被存储在用于每个可交付的表“tblDeliverableTrackPerfomance”1080中。应当看到，可以包括其他表和项目进行数据，以及系统不限于图57所示的具体的表和项目进行数据。

                  表95

    示例性tblDeliverableTrackPerfomance

列	数据类型	长度
			DeliverableID	int	4
DeliverableStatusID	int	4
			CurrentStatus	varchar	1000
BuyerUserID	int	4
			BuyerUserNotes	varchar	1000
BuyerRecordDate	datetime	8
			VendorUserID	int	4
VendorUserNotes	varchar	1000
			VendorRecordDate	datetime	8

                     表96

         示例性lkpDeliverableStatus

DeliverableStatusID	DeliverableStatusDesc
		1	Incomplete-Current
2	Incomplete-PastDue
		3	PartialComplete-Current
4	PartialComplete-PastDue
		5	Complete-OnTime
6	Complete-PastDue
		7	Complete-Early

下面的表97和98显示样本的阶段项目进行数据，它们可被存储在表“tblPhaseTrackPerfomance”1082和表“IkpPhaseStatus”1083中的数据库表结构1185中，如图57所示。阶段项目进行数据可包括从表“IkpPhaseStatus”1082确定的阶段状态。例如，阶段状态可以是“打开-当前”、“打开-过时”、“打开-将来的日期”、“关闭-按时”、“关闭-过时”、或“关闭-提早”。与状态有关的识别符可以连同与被存储在“tblPurchaseReqPhasing”1018(它可以是类似于图41上所显示表的表)中的阶段项目跟踪参数有关的识别符、当前的状态(例如，推迟或提早的天数)和任何用户票据一起被存储在表“tblPhaseTrackPerfomance”中。

例如，如果买主、销售商或其他用户已输入与阶段的状态有关的任何评注，则这些评注可被存储在表“tblPhaseTrackPerfomance”1083中。除了评注以外，输入评注的用户的身份也可以连同评注被输入的日期一起被存储。如果系统被配置成告知销售商：买主何时输入评注，则销售商应答的状态(例如，还没有应答、无应答、应答)也可被存储。

                      表97

          示例性tblPhaseTrackPerfomance

列	数据类型	长度
			PhaseID	int	4
PhaseStatusID	int	4
			CurrentStatus	varchar	1000
BuyerUserID	int	4
			BuyerUserNotes	varchar	1000
BuyerRecordDate	datetime	8
			VendorUserID	int	4
VendoruserNotes	varchar	1000
			VendorRecordDate	datetime	8

                  表98

         示例性lkpPhaseStatus

PhaseStatusID	PhaseStatusDesc
		1	当前开放
2	过时的开放
		3	将来的开放
4	及时关闭
		5	过时的关闭
6	提早关闭

下面的表99和100显示样本的单位项目进行数据，它们可被存储在表“tblUnitsTrackPerfomance”1084和“IkpUnitsStatus”1085中的数据库表结构1185中，如图57所示。单位项目进行数据可包括从“IkpUnitsStatus”1083确定的单位状态。例如，单位状态可以是“未完成-当前”、“未完成-超期”、“按时-完成”、“完成-超期”、、或“完成-提早”。与状态有关的识别符可以连同与被存储在“tblPurchaseReqPayUnits”1009中的单位项目跟踪参数有关的识别符、当前的状态(例如，推迟或提早的天数)和任何用户票据一起被存储在表“tblUnitTrackPerfomance”中。

例如，如果买主、销售商或其他用户已输入与单位的状态有关的任何评注，则这些评注可被存储在“tblUnitsTrackPerfomance”1084中。除了评注以外，输入评注的用户的身份也可连同评注被输入的日期一起被存储。如果系统被配置成告知销售商：买主何时输入评注，则销售商应答的状态(例如，还没有应答、无应答、应答)也可被存储。

                    表99

         示例性tblUnitsTrackPerfomance

列	数据类型	长度
			UnitsID	int	4
UnitsStatusID	int	4
			CurrentStatus	varchar	1000
BuyerUserID	int	4
			BuyerUserNotes	varchar	1000
BuyerRecordDate	datetime	8
			VendorUserID	int	4
VendoruserNotes	varchar	1000
			VendorRecordDate	datetime	8

                表100

         示例性IkpUnitsStatus

UnitsStatusID	UnitsStatusDesc
		1	Incomplete-Current
2	Incomplete-PastDue
		3	Complete-Current
4	Complete-PastDue
		5	Complete-Early

下面的表101和102显示样本的花费项目进行数据，它们可被存储在表“tblCostTrackPerfomance”1086和“IkpCostStatus”1087中的数据库表结构1185中，如图57所示。花费项目进行数据可以与用于任何类型的凭证的任何付费凭证有关，包括材料凭证、经费凭证、可交付凭证、阶段凭证、单位凭证和时间付费凭证。花费项目进行数据是由从表“IkpCostStatus”1087确定的花费状态来代表的。例如，花费状态可以是“过预算”、“欠预算”、或“在预算中”。与状态有关的识别符可以连同与被存储在表“tblPaidVoucherRecords”1070中的凭证信息有关的识别符、当前的状态(例如，过预算或欠预算的量)和任何用户票据一起被存储在表“tblCostTrackPerfomance”中。

例如，如果买主、销售商或其他用户已输入与花费的状态有关的任何评注，则这些评注可被存储在表“tblCostTrackPerfomance”1086中。除了评注以外，输入评注的用户的识别符也可连同评注被输入的日期一起被存储。如果系统被配置成告知销售商：买主何时输入评注，则销售商应答的状态(例如，还没有应答、无应答、应答)也可被存储。

                    表101

         示例性tblCostTrackPerfomance

列	数据类型	长度
			PaidVoucherRecordID	int	4
CostStatusID	int	4
			CurrentStatus	varchar	1000
BuyerUserID	int	4
			BuyerUserNotes	varchar	1000
BuyerRecordDate	datetime	8
			VendorUserID	int	4
VendoruserNotes	varchar	1000
			VendorRecordDate	datetime	8

                 表102

          示例性lkpCostStatus

CostStatusID	CostStatusDesc
		1	Over-Budget
2	Under-Budget
		3	In-Budget

图57上显示其他表，它们包含与项目和/或销售商或买主有关的附加数据，这些数据可用来进一步识别以前没有明确讨论的项目的类型与其他项目变量。附加数据也可被包括在被利用于分析和报告目的的事务数据中。例如，下面的表103显示项目对于买主的其他方面的影响，它可被存储在表“IkpProjectImpactCode”1072的数据库表结构1185中，下面的表104显示可交付重要性，它可被存储在表“IkpDeliverableImportance”中的数据库表结构1185中，以及下面的表105显示项目的拥有状态，它可被存储在表“IkpPMOwnershipStatus”1073中的数据库表结构1185中，如图57所示。

与销售商和买主有关的其他信息可被存储在附加的表中。例如，下面的表106显示主销售商数据，它可被存储在表“IkpVendorMaster”1090中的数据库表结构1185中，以及下面的表107显示主买主数据，它可被存储在表“IkpBuyerMaster”1095中的数据库表结构1185中，如图57所示。另外，下面的表108和109显示销售商层级信息，它表示买主指配给销售商(例如，层级1销售商典型地是首先或最经常被使用的销售商)的层级组，它可被存储在表“lkpVendorTier”1091和“tblVendorTierMap”1092中的数据库表结构1185中，如图57所示。而且，下面的表110-112显示买主行业分段、花费和尺寸信息，它们可被存储在表“IkpIndustrySegmentation”1096、“IkpBuyerSpendProfile”1097和“IkpBuyerSizeProfile”1098中的数据库表结构1185中，如图57所示。行业分段可以是项目特定的或可作为整体应用于买主。

                        表103

              示例性lkpProjectImpactCode

ProjectImpactCodeID	ProjectImpactCode
		1	EmployeeHealty & Safety
2	EmployeeTraining
		3	FacilitiesImprovement
4	InternalProcessImprovement
		5	LiabilityReduction
6	MarketShareIncrease
		7	MarketShareRetention
8	ProductDevelopment-Core
		9	ProjectDevelopmentNon-Core
10	ProfitabilityGains
		11	ProvisionClientServices
12	PublicReputationEnhancement

                            表104

              示例性lkpDeliverableImportance

DeliverableImportanceID	DeliverableImportanceDesc
		1	临界
2	高优先权
		3	中优先权
4	低优先权

                     表105

          示例性lkpPMOwnershipStatus

PMOwnershipID	PMOwnershipDesc
		1	ClientOwned
2	SupplierOwned
		3	JointOwnership-ClientPM
4	JointOwnership-SupplierPM
		5	3rdPartyConsultantPM

                       表106

               示例性lkpVendorMaster

列	数据类型	长度
			VendorID	int	4
vCompanyName	varchar	100
			vParentCompanyName	varchar	100
vBusinessEntityTypeID	int	4
			vFedIdentity	varchar	50
vYearCorp	varchar	50
			vFTEmployees	int	4
vURL	varchar	100
			vPhone	varchar	50
vFax	varchar	50
			vEmail	varchar	50
vCountryID	int	4

                    表107

             示例性lkpBuyerMaster

列	数据类型	长度
			BuyerID	int	4
bCompanyName	varchar	100
			bParentCompanyName	varchar	100
bBusinessEntityTypeID	int	4
			bFedIdentity	varchar	50
bYearCorp	varchar	50
			bFTEmployees	int	4
bURL	varchar	100
			bPhone	varchar	50
bFax	varchar	50
			bEmail	varchar	50
bCountryID	int	4

                    表108

             示例性lkpVendorTier

列	数据类型	长度
			TierCode	int	4
TierCodeDesc	varchar	50
			CurrentStatusID	int	4
UserTypeID	int	4
			UserID	int	4
RecordDate	datetime	8

                  表109

         示例性tblVendorTierMap

列	数据类型	长度
			VendorID	int	4
TierID	int	4
			CurrentStatusID	int	4
UserTypeID	int	4
			UserID	int	4
RecordDate	datetime	8
			RowID	int	4

                   表110

              lkpIndustrySegmentation

IndustrySegmentID	IndustrySegmentDesc
		1	Aerospace
2	Automotive
		3	Banking
4	Engineering
		5	Finance
6	Government
		7	Insurance
8	Manufacturing
		9	Medical/BioResearch
10	Pharmaceutical
		11	Retail
12	Telecommunications
		13	Transportation

                      表111

                lkpBuyerSpendProfile

BuyerSpendProfileDeac	SpendThresholdLow
		ExtraLargeCommoditySpender	$250,000,000
LargeCommoditySpender	$100,000,000
		MidSizeCommoditySpender	$40,000,000
SmallCommoditySpender	$5,000,000

                    表112

              lkpBuyerSizeProfile

BuyerSizeProfileDesc	CapLowThreshold
		XLCap	$10,000,000,000
LCap	$5,000,000,000
		MCap	$1,000,000,000
SCap	$100,000,000

正如以上结合图52描述的，项目进行数据形成被存储在数据库中的事务数据的一部分。再次参照图58，事务数据1195不单可包括投标数据212，而且也可包括项目跟踪参数870、凭证信息1160和项目进行数据1190。所有的事务数据195被存储在包含用于买主、销售商和管理机构的数据库(155，未示出)的、较低级别的数据库系统150。在某些实施例中，事务数据1195仅仅被保持在较低级别数据库150中，所以，分析数据仅仅被限于在较低级别数据库内的事务数据1195。例如，买主/管理机构或销售商不可能允许它们的事务数据被任何外部(第三方)源访问。在这种情形下，为了生成包括买主/管理机构或销售商事务数据的分析数据，买主/管理机构或销售商被限于仅仅是他们的事务数据。

在其他的实施例中，如图59所示，全部的或部分的事务数据1195可被传送直到最高级别数据库160(此后，称为“中心数据库160”)，用于以后使用或检索用于分析目的。事务数据可以在任何时间或为了任何原因从较低级别数据库155被传送到中心数据库160。作为例子，分别被存储在多个买主数据库155a、155b和155c中的事务数据1195a、1195b和1195c(合在一起，1195)可被传送直到中心数据库160，用于贮存在其中。传送可以在批处理模式过程中发生，其中具有在特定的时间周期内的记录创建日期的事务数据1195以批处理被传送直到中心数据库160。例如，每个星期，具有在该星期内的记录创建日期的所有的事务数据1195以批处理被传送直到中心数据库160。

传送的事务数据1195可包括在较低级别数据库160中的所有的事务数据1195，或如由系统或买主/管理机构和/或销售商指定的仅仅一部分。例如，事务数据1195的各种部分可能不是必须用于行业范围的分析目的，所以，被传送到中心数据库160的事务数据1195可以排除不必要的那些部分。作为另一个例子，买主/管理机构和/或销售商可能希望限制对于中心数据库160来说可提供的事务数据1195的类型，用于隐私或其他原因。

现在参照图60，图上显示了用于生成分析数据270的示例性功能性。图60显示按照本发明的实施例的、用于生成分析数据270的报告模块126或127。报告模块126或127可包括任何对于执行该模块的功能所需要的硬件、软件和/或固件，以及可以分别在服务器120或125内或在附加服务器(未示出)内被实施。例如，报告模块126可以驻留在服务器120内的软件模块128中，如图3B所示。

分析数据270可以通过使用来自较低级别数据库系统150内的较低级别数据库(未具体显示出)的或来自中心数据库160的事务数据1195被生成。例如，如果买主用户需要仅仅涉及到与买主有关的那些项目的分析数据，则买主用户将接入在较低级别数据库系统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。报告模块126或127使用过滤器280来接入数据库150或160以检索只包含满足过滤器280要求的事务数据的过滤的事务数据1198。从过滤的事务数据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，以及仅仅为了简化和示例性目的，报告类型350和报告视图360被包括在图70。不同的报告类型350和报告视图360的数目仅仅限于由系统保持的事务数据的类型和数量以及用户的要求。

图71-88显示报告视图360的具体类型的例子。例如，图71是呈现发货单细节报告视图360的网页61的示例性屏幕快照。被包括在报告视图360内的是与具体的发货单(或凭证)有关的分析数据270。发货单分析数据270可被多个变量分类，通过使用多个不同的过滤器280被过滤，并在多个不同的报告视图360上被总结。例如，从发货单细节报告视图，被使用来在发货单细节报告视图中生成分析数据的事务数据可以被项目类型总结，以及在项目类型发货单总结报告视图上被显示为项目类型发货单分析数据。过滤器280和对于发货单细节报告视图360可能的附加报告视图360不限于图71所示的那些图，以及可被扩展成包括任何的客户特定的域(CSF)。

图72是呈现一般的每月支出总结报告视图的网页61的示例性屏幕快照，它包含列出对于当月和以前月的总的项目支出的分析数据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的底部，标识由买主按每月在每个项目传递类型上作出的总支出的百分数的分析数据270与由该行业按每月在每个项目传递类型上作出的总支出的百分数进行比较。

图76是包含与在项目费用(cost)总结报告视图360上呈现的特定项目有关的分析数据270的示例性网页61的屏幕快照。分析数据270可包括项目状态、至今的总项目费用、申请量(即，对于项目授权的量)、与当前正在由买主处理的所有项目相比较而花费在这个项目上的百分数，项目余量和其他相关的项目费用分析数据。在网页61的底部是连到由不同类型的事务数据，诸如商业影响类型、地理、销售商等等，而总结的不同项目费用报告视图360的链接。

图77是包含与在项目花费(spending)估计报告视图360上呈现的一个或多个项目的估计的将来花费有关的分析数据270的示例性网页61的屏幕快照。将来花费的分析数据270的两个不同的例子显示于图77，虽然取决于用户输入的请求和过滤器，一次可能只显示其中的一个。在网页61的顶部，显示与在特定的项目上的估计的将来花费有关的分析数据270，而在网页的中部，显示在所有项目上估计的将来花费。在网页61的底部是连到由不同类型的事务数据，诸如商业影响类型、地理、销售商等等，总结的不同项目花费估计报告视图360的链接。

作为例子，如果用户点击链接以由项目扇区和族总结估计的将来项目花费，则类似于图78所示的报告视图360可以在示例网页61上呈现给用户。在图78上所示的报告视图360是一个估计的将来花费模型，其由项目扇区/族报告视图360聚集，该报告视图包含与在不同的项目扇区/族中项目的估计的将来花费有关的分析数据270。这种类型的报告视图360对于用户保证有组织的投资是按照商业计划作出来说可以是有用的。

估计的将来项目扇区/族花费的三个不同的例子显示于图78，虽然取决于由用户输入的请求和过滤器，一次可能只显示其中的一个。在网页61顶部，分析数据270包含由项目扇区/族聚集的、按月的估计的将来花费。在网页中部，分析数据270包含与特定的项目族的估计的将来花费有关的统计数据，诸如对于特定的项目族按月作出的总支出的估计的百分数。在网页底部，分析数据270包含与特定的项目扇区的估计的将来花费有关的统计数据，诸如对于特定的项目扇区按月作出的总支出的估计的百分数。正如可以在网页61的底部看到的，可提供到外部数据的链接，以观看包含有关项目的将来花费的外部分析数据的报告。这样的外部数据对于提供关于一般市场或具体市场成员如何投资或计划满足他们的商业目标的看法是有用的。

图79是包含与在项目进行总结报告视图360上呈现的特定项目的项目进行数据有关的分析数据270的示例性网页61的屏幕快照。分析数据270可包括项目状态、项目阶段完成计数、超期阶段计数、可交付完成计数、超期可交付完成计数、按时可交付完成的百分数、和其他项目进行分析数据。在网页61的底部是连到由不同类型的事务数据，诸如商业影响类型、地理、销售商等等，总结的不同的项目进行报告视图360的链接。因此，从这个网页61，可以生成由事务数据类型总结的聚集的和其他统计的分析数据。

作为例子，如果用户点击该链接来由项目管理所有权类型总结项目进行分析数据，则类似于图80所示的报告视图360可以在示例网页61上呈现给用户。在图80上所示的报告视图360是由不同的所有权类型(诸如买主拥有、销售商拥有、联合拥有等等)管理的项目的工作进行概要，包含与具有不同所有权的项目进行有关的分析数据270。这种类型的报告视图360对于用户理解在作为项目管理所有权的函数的成功/失败率之间的相互关系来说是有用的。正如可以在网页61的底部看到的，可提供到外部数据的链接，以观看包含有关项目进行的外部分析数据的报告，因为它涉及项目管理所有权。

作为另一个例子，如果用户点击图79上网页61的底部的链接以观看风险/失败报告，则类似于图81所示的报告视图360可以在示例网页61上呈现给用户。在图81上所示的报告视图360是项目风险/失败进行排除报告，包含与具有超期日期或其他困难的风险或非依从的项目进行有关的分析数据270。

图82是包含与在规划矩阵报告视图360上呈现的项目规划有关的分析数据270的示例性网页61的屏幕快照。分析数据270可包括例如，对于当前月和将来月的总的项目计数、和其他项目规划分析数据270。图83是包含与在项目规划工具报告视图360上呈现的更具体的项目规划有关的分析数据的示例性网页61的屏幕快照。例如，用户可选择特定的项目扇区/族，和从各种“影响变量”(例如，过滤器280)，诸如地理、销售商层级等等以及各种项目进行报告视图360进行选择，呈现一个报告视图360，该报告视图包含与列出的有关具体历史项目进行数据的影响变量的各种组合有关的聚集的概要分析数据270。这种类型的报告视图360对于用户了解在哪些商业配置(变量聚集)是成功的和哪些是不成功的方面是有用的。

图84是包含与在销售商层级代码花费报告视图360上呈现的、作为销售商层级的函数的花费趋势有关的分析数据270的示例性网页61的屏幕快照。销售商层级花费数据的两个例子显示于图84，虽然取决于由用户输入的请求和过滤器，一次只可能显示其中的一个。在网页61顶部，分析数据270包括在具体的销售商层级内一个或多个销售商的逐月的花费量。在网页61的底部，分析数据270包括销售商层级中销售商数目、在销售商层级内销售商的逐月花费的量，以及其他聚集的或统计的销售商层级花费分析数据270。

图85是包含与在销售商考核报告视图360上呈现的销售商考核信息有关的分析数据270的示例性网页61的屏幕快照。分析数据可包括例如，买主规定的销售商准则信息列表、对于每个销售商的相关的销售商考核信息和关于销售商是否满足每个买主规定的销售商合格者的指示。在网页61的底部有连到不同的概要报告视图360的链接，以聚集和/或执行各种销售商考核数据的统计分析。

图86是包含与在地理资源部署报告视图360上呈现的、作为地理的函数的人力资源的部署有关的分析数据270的示例性网页61的屏幕快照。分析数据270可包括统计信息，诸如在具体的国家、地域或城市部署的资源的百分数、在具体的国家、地域或城市工作的时间的百分数、和在具体的国家、地域或城市在人力资源上花费的金钱的百分数。分析数据270还可包括各种聚集信息，诸如总的资源计数、在具体的国家、地域或城市花费的时间和金钱。这种类型的人力资源报告视图360在处理诸如容量管理、价格、共同雇佣、重新部署等等的问题时可能是有用的。

图87是包含与在销售商部署的人力资本资源报告视图360上呈现的、人力资源有关的分析数据270的示例性网页61的屏幕快照。人力资源数据的三个不同的例子显示于图84，虽然取决于由用户输入的请求和过滤器，一次只可能显示其中的一个。在网页61的顶部，分析数据270包括作为项目进行的函数的各个承包商信息。在网页61的中部，分析数据270包括与特定的销售商有关的聚集的和统计的承包商信息。在网页61的底部，分析数据270包括与多个销售商有关的聚集的和统计的承包商信息。在网页61的底部，还有连到不同的概要报告视图360的另外的链接，以聚集和/或执行各种承包商数据的统计分析。

图88是包含与在销售商分数卡报告视图360上呈现的销售商性能有关的分析数据270的示例性网页61的屏幕快照。这个报告视图360包括可被利用来把视图360集中在具体类型的事务数据的几个过滤器280。应当看到，虽然在以上讨论的每个报告视图360上未示出，但各个过滤器对于某些或所有的报告视图360是可提供的。分析数据270可包括与各个销售商的投标、项目进行和花费活动有关的、聚集的和统计的信息。在网页61的底部，还有连到不同的概要报告视图360的链接，以聚集和/或执行各种销售商进行数据的统计分析。上述的报告视图360和这里呈现的分析数据270的类型是指仅仅提供报告模块的鲁棒性的例子。本领域技术人员应当容易看到，通过本发明，报告视图的数目和变化是有可能的。

正如本领域技术人员将会看到的，在本申请中描述的精巧的概念可以在各种各样的应用中被修正和改变。因此，受专利保护的主题的范围不应当限于所讨论的具体的示例性教导，而是由以下的权利要求规定。

Claims (56)

1.一种用于在管理一个或多个项目和一个或多个投标以及具有被存储在其中的事务数据的系统中产生分析数据的方法，包括：

在该系统上进行在线投标过程；

在进行在线投标过程期间输入投标数据到投标的数据域作为该事务数据的一部分；

接收对于作为事务数据的函数的分析数据的请求；以及

响应于该请求，根据该事务数据，通过使用事务数据来生成分析数据。

2.权利要求1的方法，其中所述输入还包括：

由与该投标有关的买主输入投标请求数据到数据域；以及

由与该投标有关的销售商输入投标应答数据到数据域。

3.权利要求1的方法，还包括：

把项目的项目跟踪参数作为该事务数据的一部分输入到与投标有关的数据域；

把凭证信息作为事务数据的一部分输入到与项目有关的数据域；以及

把项目进行数据作为事务数据的一部分输入到与该项目有关的数据域。

4.权利要求3的方法，还包括：

在项目进行期间由买主和销售商把项目进行数据输入到系统。

5.权利要求3的方法，还包括：

通过使用至少项目跟踪参数来自动生成项目进行数据。

6.权利要求5的方法，其中所述生成还包括：

把项目跟踪参数与凭证信息进行比较，以确定项目的状态；以及

把项目的状态作为项目进行数据自动输入到系统。

7.权利要求5的方法，其中所述生成还包括：

搜索项目跟踪参数，以确定项目的时间状态；以及

把项目的时间状态作为项目进行数据自动输入到系统。

8.权利要求3的方法，其中所述输入项目跟踪参数还包括：

输入标识项目的可纳税部分和与每个可纳税部分有关的纳税量的纳税信息。

9.权利要求1的方法，其中所述接收还包括：

接收对于分析数据的请求，该请求包括一个或多个过滤器；以及

通过使用一个或多个过滤器过滤事务数据，以产生过滤的事务数据，该过滤的事务数据被使用来生成分析数据。

10.权利要求9的方法，其中所述接收包括该一个或多个过滤器的请求还包括：

接收对于分析数据的请求作为一种或多种类型的事务数据的函数，该一个或多个过滤器过滤一种或多种类型的事务数据。

11.权利要求9的方法，其中该一个或多个过滤器涉及到销售商资料性质、买主资料性质、项目资料性质、和商品资料性质的至少一个性质。

12.权利要求1的方法，还包括：

在网页的项目报告视图中提供分析数据。

13.权利要求12的方法，其中项目报告视图是项目报告类型的，项目报告类型是财务类型、项目类型、商品类型或销售商/人力资本类型之一。

14.权利要求1的方法，其中所述生成还包括：

聚集与多个项目有关的事务数据，以生成分析数据。

15.权利要求14的方法，其中所述聚集还包括：

计算统计数据作为与每个项目有关的事务数据的函数；以及

聚集多个项目上的统计数据。

16.权利要求14的方法，其中所述聚集还包括：

聚集与由多个销售商执行的多个项目有关的事务数据，以生成分析数据。

17.权利要求14的方法，其中所述聚集还包括：

聚集与多个买主有关的事务数据，以生成分析数据。

18.权利要求1的方法，其中所述生成还包括：

通过使用与多个项目有关的事务数据来计算统计数据以生成分析数据。

19.权利要求18的方法，其中所述计算还包括：

通过使用与多个买主有关的事务数据来计算该统计数据以生成分析数据。

20.权利要求1的方法，还包括：

把与买主、销售商或管理机构的投标和项目有关的各个事务数据存储在各自的买主、销售商或管理机构的数据库系统，以及

把被存储在数据库系统的、至少一部分事务数据传送到存储来自多个数据库系统的多个事务数据的中心数据库，从该多个事务数据生成该分析数据。

21.一种用于产生涉及到管理一个或多个项目和一个或多个投标的系统的分析数据的计算机系统，包括：

基于网络的接口，被连接来接收对于作为事务数据的函数的分析数据的请求；

数据库系统，用于维持包括至少投标数据的事务数据，该投标数据经由基于web的接口被输入到被存储在所述数据库系统中的投标的数据域；以及

服务器，被连接到所述基于网络的接口，以便接收请求，以及被连接到所述数据库系统，以便根据该请求来检索事务数据，所述服务器用来响应于该请求而根据检索的事务数据生成该分析数据。

22.权利要求21的计算机系统，其中所述数据库系统存储投标数据，包括由与投标有关的买主输入到数据域的投标请求数据和由与投标有关的销售商经由所述基于web的接口输入到数据域的投标应答数据。

23.权利要求21的计算机系统，其中所述数据库系统还存储事务数据，至少包括投标数据、由与项目有关的买主和销售商经由所述基于web的接口输入到与投标有关的数据域的项目的项目跟踪参数、由买主和销售商经由所述基于web的接口输入到与投标和项目有关的数据域的凭证信息、以及被存储在与投标和项目有关的数据域中的项目进行数据。

24.权利要求23的计算机系统，其中所述数据库系统存储项目跟踪参数，包括标识项目的可纳税部分和与每个可纳税部分有关的纳税量的纳税信息。

25.权利要求21的计算机系统，其中所述服务器还用来接收包括一个或多个过滤器的请求以及通过使用一个或多个过滤器过滤事务数据，以产生过滤的事务数据，过滤的事务数据被使用来生成分析数据。

26.权利要求25的计算机系统，其中该一个或多个过滤器涉及到销售商资料性质、买主资料性质、项目资料性质、和商品资料性质的至少一个性质。

27.权利要求21的计算机系统，其中所述服务器还用来经由所述基于web的接口在网页上的项目报告视图中提供分析数据。

28.权利要求27的计算机系统，其中项目报告视图具有项目报告类型，项目报告类型是财务类型、项目类型或销售商/人力资本类型之一。

29.权利要求21的计算机系统，其中所述服务器还用来聚集与多个项目有关的事务数据，以生成分析数据。

30.权利要求29的计算机系统，其中所述服务器还用来计算统计数据作为与每个项目有关的事务数据的函数，以及聚集跨多个项目的统计数据。

31.权利要求29的计算机系统，其中所述服务器还用来聚集与由多个销售商执行的多个项目有关的事务数据，以生成分析数据。

32.权利要求29的计算机系统，其中所述服务器还用来聚集与多个买主有关的事务数据，以生成分析数据。

33.权利要求21的计算机系统，其中所述服务器还用来通过使用与多个项目有关的事务数据计算统计数据以生成分析数据。

34.权利要求33的计算机系统，其中所述服务器还用来通过使用与多个买主有关的事务数据计算统计数据以生成分析数据。

35.权利要求21的计算机系统，其中所述数据库系统被配置成存储与买主、销售商或管理机构的投标和项目有关的各个事务数据，以及还包括：

被连接到所述数据库系统的中心数据库，接收被存储在该数据库系统的、至少一部分事务数据，所述中心数据库存储来自多个数据库系统的多个事务数据，从多个事务数据生成分析数据。

36.在具有被存储在其中的计算机可执行指令和涉及到管理一个或多个项目和一个或多个投标的系统的计算机可读媒体中，所述计算机可执行指令包括：

用于接收对于作为事务数据的函数的分析数据的请求的装置，事务数据至少包括投标数据，该投标数据在在线投标过程期间被输入到被存储在数据库系统中的投标的数据域；

用于根据请求接入该数据库系统以便检索事务数据的装置；以及

用于响应于请求而根据检索的事务数据生成分析数据的装置。

37.一种在用于管理项目和在其中存储事务数据的系统中产生分析数据的方法，包括：

把项目进行数据作为事务数据的一部分输入到与每个项目有关的数据域；

接收对于作为事务数据函数的分析数据的请求；以及

根据请求来聚集事务数据，以生成聚集的项目进行数据。

38.权利要求37的方法，还包括：

把项目的项目跟踪参数作为事务数据的一部分输入到与项目有关的数据域；以及

由至少一个买主和至少一个销售商把凭证信息作为事务数据的一部分输入到与项目有关的数据域。

39.权利要求38的方法，还包括：

在项目进行期间，由至少一个买主和至少一个销售商把项目进行数据输入到项目投标管理系统。

40.权利要求38的方法，还包括：

通过使用至少项目跟踪参数来自动生成项目进行数据。

41.权利要求40的方法，其中所述生成还包括：

把给定的一个项目的项目跟踪参数与该给定项目的凭证信息进行比较，以确定给定项目的状态；以及

把给定项目的状态作为项目进行数据自动输入到系统。

42.权利要求40的方法，其中所述生成还包括：

搜索项目跟踪参数，以确定项目的时间状态信息；以及

把时间状态信息作为项目进行数据来自动输入到系统。

43.权利要求37的方法，其中所述接收还包括：

接收对于分析数据的请求，该请求包括一个或多个过滤器；以及

通过使用一个或多个过滤器过滤事务数据，以产生过滤的事务数据，该过滤的事务数据被使用来生成分析数据。

44.权利要求43的方法，其中所述接收包括该一个或多个过滤器的请求还包括：

接收对作为一种或多种类型的事务数据函数的分析数据的请求，该一个或多个过滤器过滤一种或多种类型的事务数据。

45.权利要求43的方法，其中该一个或多个过滤器涉及到销售商资料性质、买主资料性质、项目资料性质、和商品资料性质的至少一个性质。

46.权利要求37的方法，还包括：

在网页上的项目报告视图中提供分析数据。

47.权利要求46的方法，其中项目报告视图是项目报告类型的，项目报告类型是财务类型、项目类型或销售商/人力资本类型之一。

48.权利要求37的方法，其中所述聚集还包括：

计算统计数据作为与每个项目有关的事务数据的函数；以及

聚集跨项目的统计数据。

49.权利要求37的方法，其中所述聚集还包括：

聚集与由多个销售商执行的项目有关的事务数据，以生成分析数据。

50.权利要求37的方法，其中所述聚集还包括：

聚集与多个买主有关的事务数据，以生成分析数据。

51.权利要求50的方法，其中所述存储还包括：

把与买主、销售商或管理机构的投标和项目有关的各个事务数据存储在各自的买主、销售商或管理机构的数据库系统，以及

把被存储在数据库系统的、至少一部分事务数据传送到存储来自多个数据库系统的多个事务数据的中心数据库，从多个事务数据生成分析数据。

52.一种在用于管理一个或多个投标与一个或多个项目以及在其中存储事务数据的系统中产生分析数据的方法，包括：

在在线投标过程期间把投标数据分量作为事务数据的一部分输入到投标的数据域；

把与项目有关的项目跟踪参数作为事务数据的一部分输入到与投标有关的数据域；

把项目进行数据分量作为事务数据的一部分输入到与项目有关的数据域；

接收对于作为事务数据的一个或多个分量的函数的分析数据的请求；以及

响应于请求而根据事务数据生成分析数据。

53.一种在用于管理由多个买主委托的多个投标与多个项目以及在其中存储涉及到多个项目的事务数据的系统中产生分析数据的方法，包括：

接收对于作为事务数据的函数的行业分析数据的请求，事务数据至少包括表示与项目有关的一个或多个销售商的项目的进行的项目进行数据；

根据请求而接入事务数据；以及

响应于请求根据接入的事务数据生成分析数据。

54.权利要求53的方法，还包括：

把与买主、销售商或管理机构的投标和项目有关的各个事务数据存储在各自的买主、销售商或管理机构的数据库系统，以及

把被存储在该数据库系统中的、至少一部分事务数据传送到存储来自多个数据库系统的多个事务数据的中心数据库，从多个事务数据生成分析数据。

55.一种在用于管理项目和在其中存储事务数据的系统中产生纳税量信息的方法，包括：

把纳税信息作为事务数据的一部分输入到与项目有关的数据域；

把凭证信息作为事务数据的一部分输入到与项目有关的数据域；以及

根据纳税信息生成与凭证信息有关的纳税量。

56.权利要求55的方法，还包括：

把纳税量提供给与项目有关的买主和销售商，用于得到批准。

Images