CN1942887A - 分包商的启用以及管理方法和系统 - Google Patents

Abstract

一种使项目投标过程便利的方法，包括产生一个与买方关的使用从一存储的投标项列表中选择出的至少一部分投标项的投标请求；将该与买方相关的投标请求传给至少一个供应商引发一个供应商投标回执，该投标回执同在所述的与买方相关的投标请求中使用的所述选择出来的投标项一起产生；产生一个与供应商相联系的的使用在所述与买方相关的投标请求中使用的所述选择出来的投标项的投标请求；将所述与供应商相联系的投标请求发送给至少一个分包商来引发一个分包商投标回执，该分包商投标回执同在所述与供应商相联系的投标请求中使用的所述选择出来的投标项一起产生。本摘要符合使检索员或其他读者快速确定公开技术的主题的规定。应当理解，本摘要不会用于解释或限定权利要求的范围或者含义。

Description

分包商的启用以及管理方法和系统

参照的相关专利申请

本发明专利申请是美国专利申请事情10/412,096(代理卷号57084-00532USP1)的部分延续。而美国专利申请号10/412,096是2002年9月30日提交的美国专利申请号10/262,487(代理卷号57084-00532USPT)的部分延续。美国专利申请号10/262,487提出以2002年04月10提交的美国临时专利申请号60/371,488(代理卷号57084-00532USPL)为优先权文本。美国专利申请号10/412,096提出以2002年04月10提交的美国临时专利申请号60/371,488(代理卷号57084-00532USPL)为优先权文本。本专利申请合并了美国临时专利申请号60/371,488、美国专利申请号10/262,487和10/412,096全部公开的内容。本专利申请也合并了2002年05月09日提交的美国专利申请号10/141,801(代理卷号57084-00542USPT)的全部公开的内容。

技术领域

本发明总体上与启用以及管理分包商的方法和系统有关。更加具体的，作为实施例，本发明相关于通过电子手段使为分包商与项目运转相关的各方面作用(包括但不限于：分包商启用、项目投标过程、请求过程、花费过程、以及执行管理过程)提供便利。

背景技术

服务/产品供应商，尤其是产品或服务的主供应商在一个项目工作部分中使用第二级，甚至是随后的更低级别的提供商是一个常见的商业事务。这些第二级或者更低级别的提供商一般被指为分包商(sub-contracting entity(分包商))。分包商是那些与主供应商协力，通过承诺主供应商的产品和/或服务的方式向买方提供产品和/或服务的产品/服务提供商。这些分包商被用来递送被最终的用户或买方要求的可递送的项目工作。经授权的供应商会因为各种原因使用如上所述的所述分包商，如扩展服务/产品的递送能力、当主供应商在后勤上或技术上不能满足需求时提供产品/服务给买方，当所述的产品/服务可以被一个分包商以更加低廉的成本提供给买方时能够减少主供应商的成本。

忽视使用分包商的其他潜在原因，在项目工作部分中使用分包商是一件很平常的事情。在很多实例中，启用分包商的供应商在一个转包合同的活动中都是以这样一种方式的，即供应商对分包商的启用对于买方来说实际上是看不到的。尽管对分包商的使用趋向于向买方提供所要求的项目工作可递送的产品，但是由于分包商活动相对隐蔽的特点，会引发下面的至少一种情况：1)增加了潜在的债务风险；2)买方对分包商无法进行控制；3)隐蔽了分包商的成本/价格数据；4)隐蔽了主供应商加到分包商成本/价格上的边际附加值；5)使买方不能度量分包商的执行情况；6)使买方不能度量与由主供应商直接提供的产品/服务相联系的执行情况；7)减少了对活动和数据处理方面的审计能力；8)使得买方不能有效地管理该项目工作产品以及不能更有效地利用如果分包商的活动能够更加透明和易于管理所带来的商业机会。

发明内容

一种使项目投标过程便利的方法，该方法包括产生一个与买方相关的使用从一存储的投标项列表中选择出的至少一部分投标项的投标请求；将该与买方相关的投标请求传给至少一个供应商引发一个供应商投标响应，该投标响应同在所述的与买方相关的投标请求中使用的所述选择出来的投标项一起产生；产生一个与供应商相联系的的使用在所述与买方相关的投标请求中使用的所述选择出来的投标项的投标请求；将所述与供应商相联系的投标请求发送给至少一个分包商来引发一个分包商投标响应，该分包商投标响应同在所述与供应商相联系的投标请求中使用的所述选择出来的投标项一起产生。

一个计算机系统用来使针对一项目的投标过程便利，所述项目包括买方、供应商以及至少一个分包商，所述的计算机系统包括一个数据库系统用以维持一个可以设置的预先建立该项目的一投标项列表以及一投标模板；其中，所述的投标模板包括从所述的投标项列表中选择出来的投标项选集；一个连接到数据库系统的服务器，该服务器可以与所述的买方、所述的供应商以及所述的至少一个分包商相连；其中所述的服务器可进行下列操作：用所述的投标模板产生一个与买方相关的投标请求、发送所述的与买方相关的投标请求给所述的供应商；通过对所述与供应商相联系的投标请求的拆解产生一个与供应商相联系的投标请求、发送所述的与供应商相联系的投标请求给所述的至少一个分包商、接收一个针对所述的与供应商相联系的投标请求的分包商投标响应、接收一个供应商投标响应，所述的供应商投标响应至少部分与地来自所述分包商投标响应的数据合并。

一种存储在计算机可读介质种的具有计算机可执行指令，所述的计算计可执行指令包括产生一个与买方相关的的使用从一存储的投标项列表中选择出的至少一部分投标项的投标请求的手段；将该与买方相关的投标请求传给至少一个供应商引发一个供应商投标响应，该投标响应同在所述的与买方相关的投标请求中使用的所述选择出来的投标项一起产生的手段；产生一个与供应商相联系的使用在所述与买方相关的投标请求中使用的所述选择出来的投标项的投标请求的手段；将所述与供应商相联系的投标请求发送给至少一个分包商来引发一个分包商投标响应，该分包商投标响应同在所述与供应商相联系的投标请求中使用的所述选择出来的投标项一起产生的手段。

一种管理一个项目投标过程的方法，该方法包括接收一个关于一个分包商的启用请求以及接收一个关于一个主供应商的加入请求。该加入请求请求所述的分包商与所述的主供应商建立关系。该方法还包括发送一个与买方相关的投标请求给所述供应商，发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商，从所述分包商接收一个已经完成的菊花链报价。该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项。该方法还包括用所述已经完成的适用的菊花链报价项中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求，以及发送所述更新的供应商投标响应给所述的买方。

一种存储在计算机可读介质种的具有计算机可执行指令，所述的计算机可执行指令包括接收一个关于一个分包商的启用请求的手段，接收一个关于一个主供应商的加入请求，该加入请求请求所述的分包商与所述的主供应商建立关系的手段，发送一个与买方相关的投标请求给所述供应商的于段，发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商的手段，从所述分包商接收一个已经完成的菊花链报价。该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项的手段。所述的计算机可读指令也包括用所述已经完成的适用的菊花链报价项中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求的手段，以及发送所述更新的供应商投标响应给所述的买方的手段。

一种用于管理一个项目竞价过程的计算机系统，该计算机系统包括一个数据库系统和一个与该数据库系统连接的服务器，其中该服务器可执行下列操作：接收一个关于一个分包商的启用请求，接收一个关于一个主供应商的加入请求，该加入请求请求所述的分包商与所述的主供应商建立关系，发送一个与买方相关的投标请求给所述供应商，发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商，从所述分包商接收一个已经完成的菊花链报价。该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项。所述服务器还执行：用所述已经完成的适用的菊花链报价项中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求以及发送所述更新的供应商投标响应给所述的买方。

附图说明

参考后面有关本发明实施例的纤细描述，能够得到对本发明的方法和系统的更完整的理解，本发明实施例与附图相结合，其中：

附图1A-B演示了分包商管理方法的一个例子；

附图2A-B演示了管理对分包商的启用和授予资格的配置要素的实例；

附图3A-E演示了一个用于与附图2A所示的所述配置要素相联系的数据库模型/方案。

附图4演示了一个用于与附图2B所示的科研是的配置要素相联系的数据库模型/方案。

附图5A-B显示了一个演示一个分包商如何被启用并且与一个主供应商联系的高级流程图的实例。

附图6显示了用于与附图5A-B所示分包商启用过程的实例相联系的数据库模型/方案。

附图7是一个演示一个主供应商是如何选择和包括分包商进入买方投标请求的流程图的实例；

附图8是一个演示一个分包商如何处理一个主供应商发布的菊花链报价的流程图的实例；

附图9是一个演示一个主供应商如何处理一个分包商菊花链报价响应的流程图实例；

附图10是一个演示一个主供应商如何使用针对分包商提供的报价的报价分析工具；

附图11是一个演示一个主供应商如何增加边际价格到已经接受的分包商报价的流程图的实例；

附图12是一个演示与在附图7-11中所描述的分包商菊花链报价响应相联系的数据库模型/方案；

附图13是一个演示一个买方如何处理一个主供应商的报价响应的流程图的实例；

附图14是一个演示了与在购买请求级别与分包商记录创立以及跟踪分包商报价要素相联系的数据库模型/方案的实例；

附图15是一个演示了在一个菊花链购买请求的过程中如何处理税务评估和购买请求被接收的行为的流程图的实例；

附图16演示了一个用于与菊花链购买申请数据处理的数据库模型/方案；

附图17演示了一个买方是如何处理一个与受分包商影响的采购申请相对的采购订单的配置和创建的流程图的实例；

附图18演示了一个用于与同受分包商影响的采购申请相对的购买订单处理联系的数据库模型/方案的流程图的实例；

附图19是一个演示了分包商票据/支付请求凭证被处理的一个流程图的实例；

附图20演示了一个用于与分包商票据/支付请求凭证相联系的数据库模型/方案；

附图21是一个演示分包商票据/支付如何被检查的流程图的实例；

附图22演示了一个用于同提取分包商票据/支付数据文件相联系的数据库模型/方案；

附图23A描述了一个传统的供应链买方的视图；

附图23B是一个演示了如何被买方增强供应链的透明度的模块图；

附图24演示了本发明的各实施例是如何影响买方的供应链的。

具体实施方式

参照附图，这里对本发明的实施例进行比附图中更详细的描述。然而，该发明的实现会有很多种方式，它的实现并不仅仅局限于这里所描述的实施例。该发明仅仅应该被看作是权力要求中的一种存在。

在该详细描述中，对不同的实体，比如，分包商，主供应商，和买方进行了描述。本领域专业人员能够理解，当描述的多个动作被一个实体执行时，其他的一些动作会被和该实体相关的单个用户所执行。

为了避免和发明的主要部分发生混淆，由买方，主供应商或者分包商所执行的专业化的工作流程表在这里将不会被详细的讨论。本领域专业人员理解专业的工作表需要适当的处理而不会偏离发明的精神和范围。

本发明的实施例提供了一个综合的网络系统和方法来推动和管理与项目工作有关的分包商应用中的方方面面，包括分包商准入，项目投标过程，申请过程，消耗过程以及性能管理过程等。在本发明的实施例中，由主供应商启用的分包商对买方是可见的，同时，买方有权利确立和配置在整个项目工作生命周期中启用分包商的控制规则。

与启用分包商有关的传统的隐藏信息系统可能是在以一种结构配置方式引入的，而买方在这种结构配置方式中是可以看到整个流程和进行控制的。一旦分包商获得准入，主供应商可以在一种配置整合模式下提高提交给卖方的投标报价，以便提供透明度以及分包商和具体的投标响应要素之间的关联，比如，成本/价格数据等。

本发明的具体实施例中的分包商投标响应方法可以使得后续的功能适合于采购申请和订单处理。拥有主供应商提供的确认的投标响应，分包商可以在一个整体的环境中为那些适合分包商的采购申请要素提供必要的数据，比如税务数据以及采购申请受理等。

考虑到分包商订购单要素以及在项目过程中分包商要求的直接票据支付凭单处理，本发明的实施例中，买方可以在考虑到上述因素的方式下配置和创建一个订购单，本发明的实施例允许分包商订购单和凭单支付请求可见，而且可能导致单个分包商性能评估和直接或者间接的财务支付过程。通过对订购单要素和适当的汇票支付请求凭证进行在其上的子记录和/或离散数据处理记录层的拆解，核心的数据处理功能能够被应用到主供应商和分包商服务/商品供应商。本发明的实施例为买方、主提供商和分包商提供了增强的可视化功能和数据处理功能。

分包商的级别可能会被放置在买方的主供应商之上，在这种情况下，商品/服务的特定供应商可能有作为主供应商和对于买方来说是分包商的双重身份。这样的分包商，会存在整个生命周期过程的上下文中。生命周期过程指的是像图5A和附录文件美国专利申请号为10/262,487(2002年9月30日申请)中描述的项目工作生命周期。生命周期过程包括从主供应商资格认证/挑选到汇票支付和报告。

现在，我们转到后面的附图，附图1A-B展示了典型的分包商启用和管理。在图1A中，工作流程图100包括步骤102-步骤194，步骤102-106关于分包商启用，步骤108-142关于菊花链投标响应处理。步骤144-150关于买方投标响应处理。在图1B中，步骤152-170是关于订单申请处理的，步骤172-174和步骤178-184是关于凭证处理，步骤186-192是关于应付帐款处理的。步骤194是关于决策支持系统应用的。本领域专业人员会发现，在工作流程图100中的决策图中只有单向肩头。在这种情况下，真正的决策过程并不仅仅是在决策图中箭头所标识出来的那样，为了不混淆发明的重要原则，在这里就不详细讨论。

工作流程图100在步骤102开始，在这一步，买方提出与分包商有关的配置规则。在步骤104，分包商被启用，同时，设置程序配置供应商工作量(supplier load)。在步骤106，分包商将加盟一个或者多个供应商(进行联系)。在步骤108，一个被核准的供应商将收到从买方发出的报价/建议/投标邀请。在步骤110，被核准的供应商决定出具菊花链报价(DCQ)，菊花链这个词用在实体之间的工作流程表要素处理和传送中，在这些实体中，会对从主记录派生出来的一个或者多个记录进行拆解。拆解后的记录会从一个实体传送到另外一个实体，这样，接收记录的实体就可以访问这些拆解记录和传送记录。在随后的处理中，拆解传送记录可能会被整合到主记录中，作为工作流程表的一部分进行处理。菊花链报价和菊花链获得物很好的展示了菊花链概念是怎么运用到这里描述的工作流程处理中。作为对步骤110中决定出具一个菊花链报价的回应，步骤112中被核准的供应商选择感兴趣的投标响应项目包含于菊花链报价中。菊花链报价中的项目必须包含一个能够出具发票的服务/产品项目。

步骤112到步骤114是一个执行过程，在步骤114，被核准的供应商选择理想的加盟分包商，并发给他们菊花链报价，同时会启动标准解决方案通知。标准解决方案通知包括，例如，所谓的在线公告通知和电子邮件通知。步骤116到步骤118是一个执行过程，在步骤118中，接收到通知的分包商使合适的买方协议生效之后就可以获得对菊花链报价的访问权限。在步骤118中的合适的买方协议生效基础之上，操作过程延续到步骤120。在步骤120，分包商完成合适的报价项，在步骤122，分包商将完成的菊花链报价发回给供应商。Page9 line 31-Page10 line 7

在步骤124，被核准的供应商评估出具的分包商菊花链报价。步骤124结束后，执行过程会转到到步骤126或者步骤128。如果在步骤124中，被核准的供应商决定采用可选择的报价分析工具，执行过程会转到步骤126。如果被核准的供应商不想采用报价分析工具，执行过程会直接转到步骤128。在步骤126，被核准的供应商会启用可选择的报价分析工具。报价分析工具会对菊花链报价进行评级和记录。在步骤128，被核准的供应商可能接受或者拒绝分包商菊花链报价，如果接受了分包商菊花链报价，执行过程会转到步骤130。

在步骤130，被核准的供应商选择菊花链报价响应项。比如，被核准的供应商会选择由分包商发过来的菊花链报价中的适合它自身的响应项，拒绝不适合它自身的响应项。被选择项中必须包括一项可以开具凭证的服务/产品项。作为对理想的菊花链报价选择项的回应，执行过程转到步骤132。在步骤132，会判断是不是所有必要的确认项已经通过。比如，如果被核准的供应商试图对同一个投标项做出多个投标响应项的话，确认就会失败。如果判断出并不是所有必需的确认项都已经得到确认，执行过程会返回步骤130。如果判断结果是所有必需的确认项都已经得到确认，那么，执行过程会从步骤132转到步骤134。

在步骤134中，供应商投标响应会和在步骤132中得到确认的菊花链报价一起更新。在步骤136，会对分包商菊花链报价和供应商投标响应进行合理的状态改变。比如，如果供应商接受了被选择过的菊花链报价响应项，这些项的状态会从未决状态转换为接受状态。在步骤138，会给分包商出具一个标准的通知单。在步骤140，被核准的供应商可能会有选择的对分包商的价格进行一些修改，这样来反映合理的供应商加成。在本发明的实施例中，被核准的供应商对分包商的价格进行修改必须不能消减分包商价格，同时，必须和买方允许设置的加成点数保持一致。在步骤140之后，执行过程会转到步骤142。在步骤142，被核准的供应商将投标响应提交给买方。

在步骤144，买方访问投标响应。在步骤146，被核准的买方将通过用户接口对所有的分包商联合投标响应单细节有选择性的进行访问。在步骤148，买方处理这些投标响应。在步骤150，买方决标。步骤150之后，执行过程将转到步骤152。在步骤152，买方创建一个采购申请。在步骤154，买方向供应商发出申请，请求接受订单，以及进行税务评估。在步骤156，供应商向合适的分包商提交一份对接受报价和相关的申请要素的税务评估进行拆解的请求。在步骤158，合适的分包商完成申请的处理并将处理完的申请回馈给供应商。

在步骤158之后，执行过程转到步骤160。在步骤160，供应商将合计所有的分包商要求审查提请。在步骤162，供应商提交给买方认可的税务评估要求。在步骤164，买方处理订单申请。在步骤164中的买方对订单申请的处理会和程序配置中的一致，而程序配置会随着项目中的商品/服务而有所改变。在步骤166中，买方进行最终的确认，这样就可以启动订单处理流程了。

在步骤166之后，执行过程进行到步骤168。在步骤168中，会判断这是不是一个分包商支付程序。分包商支付程序会被定义为买方将资金直接拨给分包商。如果判断是分包商支付程序，执行过程将直接转到步骤176。如果不是，执行过程将转到步骤170。在步骤176，订购单交给供应商处理，订购单线被分析，以便分割分包商细节，配置通知单进入流程，同时启动凭单系统。结束步骤176的操作后，执行流程进行到步骤178。在步骤178，启动项目的准备工作，分包商制作产品/服务交接凭单。在步骤180，分包商凭单被提交给供应商。

在步骤170，订购单交给供应商处理，配置通知单进入流程，同时启动凭单系统。执行完步骤170后，执行过程将转到步骤172。在步骤172，启动项目的准备工作，供应商为相应的产品/服务交接制作凭单。

步骤172和步骤180的后续步骤都是步骤174。在步骤174，供应商凭单要提交给一个由用户配置的审查体系。完成步骤174的动作后，执行过程将转到步骤182。在步骤182，买方处理在步骤174中提交的产品/服务凭单。比如，不同的处理方式和认证流程可能会按照买方想要的方式进行。在这个过程中，可能会用到决策支持系统，例如，为了评估由主供应商直接提供的产品/服务相关的主供应商和分包商，或者是评估提供转包产品/服务的分包商，集合所有和项目工作生命周期相关数据时就有可能会用到决策支持系统。

步骤184之后，执行过程转到步骤186。在步骤186，一个设定好的批处理流程会从大量的数据中提取出被核准的凭单细节。在步骤188，传递的是一个买方发票文件。在步骤190，买方支付这些发票。在步骤192，服务提供商得到付款。在步骤194中，采用一个决策支持系统。

分包商启用指的是分包商如何获得系统访问权限，以及在后续如何为买方和主供应商服务。分包商启用和本发明的实施例是一致的，这种启用允许加强买方的启用控制，风险管理，商务处理透明/审查功能，以及获得产品信息等各方面的权利。在本发明的实施例中，一种与启用分包商方法有关的的结构化的商品管理方法，相比较主供应商控制链来说，会使得买方能够更好的控制分包商。图2A-B展示了用来控制分包商使用和认证的典型的配置要素。

配置要素200包括项目商品许可配置202，组织架构许可配置204，人员增补商品许可配置206，模版许可配置208，区域许可配置210，以及主供应商状态许可配置212。

项目商品许可配置202包括，例如，配置相关的项目部门和人员，该项目商品许可配置可以按照SIC，NAICS或者其他买方希望的结构框架来配置。组织架构许可配置204允许买方决定是否采用和买方有业务往来而在部门隶属关系、商务单位和成本中心等各个方面都独立于买方的主供应商选取的分包商。人员增补商品许可配置206允许买方按照项目中人员的技能特点来进行配置，比如，买方可以给分包商提供文员，而不会给分包商提供工程服务人员。模版许可配置208允许在图2A中的其他配置应用于报价模版，或者是按照报价类型来构建。区域许可配置210允许按照国家、地区或者城市来配置。主供应商状态许可配置允许买方为主供应商设置不同的状态，并根据主供应商的这些状态，允许或者拒绝他们参与竞标。比如，买方能够设定只有第一级的买方可以在和它发生业务关系的时候启用分包商，而处于不履行合同状态的供应商是不能竞标的，或者是在供应商的状态变成履行合同状态之后才可以竞标。

图2B展示了控制分包商商务条件的典型配置要素。在配置要素250中，展示了条件252中的分包商商业保险资格要求，和在条件254中的分包商商业信息要求。条件252和条件254可能和买方为主供应商设定的要求条件相同或不同。比如，条件252和254可能会比买方要求的主供应商的资质宽松或者更加严苛。

图3A-E展示了一个技术层面的数据库模型/架构，该模型/架构和图2A中列出的配置要素相关联使用。特别是图2A和图3A-E给出了典型的数据变量，买方通过改变这些变量，就可以设置一个符合买方商业要求的配置。在图2A和3A-E中出现的典型变量反映了触及到关键配置要素的变量，比如，区域配置，买方组织架构，商品等级，报价模版类型，以及主供应商状态等等要素之间的良好的配合。分包商的合格配置可以被认为与U.S.专利申请编号为10/262,487和10/412,096中讨论的主供应商的配置类似，而且，在实际上可能表示的是类似功能在不同的商业层面上的启用。在图3A-E中的描述尽可能的缩减，以提供与分包商有关的细节。

表113-118中列出来的是在分包商配置中用到的数据结构的例子，这些数据结构被用来说明数据结构怎么在图表格式中被简单的组织的。在每个表格中，包含了分包商配置方面的所有必需的部分。这些表格处于层级关系或者关系方式，这样，图3A-3E中的相关细节描述的所有配置分包商所必需的信息能够在被正确的存储和访问。然后，应该了解的是其他的一些配置也能够被列在表113-118中或者图3A-3E中，而且系统也不仅仅是局限在表113-118或者图3A-3E列出的具体配置上。

表113 tbISCECommodityConfig(db结构视图)

列名称	数据类型	长度
			ProjectFamilyID	int	4
SCEPermitted	char	1
			RecordID	int	4

表114 tbISCEGeoConfig(db结构视图)

列名称	数据类型	长度
			RegionID	int	4
CityID	Int	4
			LocationID	int	4
SCEPermitted	char	1
			RecordID	int	4

表115 tbISCEBUConfig(db结构视图)

列名称	数据类型	长度
			BUCode	varchar	50
SCEPermitted	char	1
			RecordID	int	4

表116 tbISCECCConfig(db结构视图)

列名称	数据类型	长度
			[Dept/Cost_Center]	varchar	50
SCEPermitted	char	1
			RecordID	int	4

表117 tbISCETemplateConfig(db结构视图)

列名称	数据类型	长度
			RFX_Template_ID	int	4
SCEPermitted	char	1
			RecordID	int	4

表118 tbISCETierConfig(db结构视图)

列名称	数据类型	长度
			TierCode	int	4
SCEPermitted	char	1
			RecordID	int	4

表113-118列出了能够存储在数据库表格中的分包商配置。在表113中显示的分包商商品配置可以被存储在分包商商品配置表304中，表114中的分包商区域配置可以存储在区域配置表310中，表115中的分包商商业单元配置可以存储在分包商商业单元配置表324中，表116中的分包商成本中心配置可以存储在分包商成本中心配置表320中，表117中的分包商模版配置可以存储在分包商模版配置表328中，表118中的分包商分层配置存储在分包商分层代码配置表332中。

在图3A中，用于管理分包商成本和商务组配置的数据库架构包括项目类表302，分包商商品配置表304，商务组表306，以及一个分包商商品配置表308。在图3A中，列出了项目组表302和分包商商品配置表304，表302中有一列为项目组表302中的每一个项目组创建的项目组识别码，项目组名，类须，项目Sector识别码等。表304包括商品记录识别码，失效日期，被批准用户识别码，别批准用户类型识别码，现在状态识别码，主供应商最大加成点数，主供应商加成限制，分包商允许领域以及在表302中用到的项目组识别码。这样，表302和表304就通过项目识别码这一项联系在一起了。

商务组表306包括一个商务组识别码，主营业务，商务组名称，可视标志以及一个分类识别码。分包商商品配置表308和分包商配置商品标相仿，表306和表308通过商务组识别码发生联系。

在图3B中，说明了对分包商的区域配置，分包商区域配置表310中包括国家代码，区域代码，城市代码，地点代码，分包商许可以及记录代码。在国家表312，区域表314，城市表316以及地点表318都和图3B中的分包商区域配置表310相关。

图3C列出了分包商成本中心和商务单元配置。一个分包商成本中心配置表320，商务单元配置表324分别和成本中心表322，成本中心表326相关。图3D列出了分包商模版配置。分包商模版配置表328和报价/建议/投标邀请投标模版表330。表328和表330允许分包商模版配置和上述的报价/建议/投标邀请模版连接。图3E包括分包商分层代码配置表332和报价/建议/投标邀请投标模版表334。表332和表334允许把分层代码分配给一个指定的和特定的报价/建议/投标邀请投标模版相连的分包商。

图4列出了一个可能用来连接图2B中各个直观的配置要素技术数据库模型/架构，图2B和图4都很直观的指出了由买方指定的分包商主供应商资质，与分包商有关的必须要达到的商业保险凭证和通常的商业要求条件来讲，分包商主供应商资质由买方确定。图4很精练的提供了与分包商有关的细节，在编号为10/412,096的美国专利申请中详细讨论了主供应商资质，本领域专业人士会认识到该发明的流程和编号为10/412,096的美国专利申请中讨论的可能用于申请分包商商业资格的流程类似，同时会认识到这将为主供应商和分包商制定不同的条件要求。

表120-125中，列出了具有分包商资格的主供应商的数据接受实例，这些数据结构用来说明表格的组织简洁性，在每一个表中包括了分包商主供应商资质的方方面面。表120-125是以图4描述的相关的分层结构或关系方式联系在一起的。这样，所有的必要的信息可以被正确地存储和访问。然而，应该明白一点，其他的分包商主供应商资质范围也可以被包含在系统中，这些资质并不仅仅局限在表120-125或者图4中列出来的资质范围。

                表120 lkpInsuranceType(db结构视图)

InsuranceType ID	描述	CoverageTypeAllowed
			1	General Liability	1
2	Errors Omissions	0
			3	Automobile	0
4	Dishonesty	0
			5	Workman Compensations	0
6	Fire	1
			7	Theft	1
8	Marine	1

表121 lkpInsuranceCoverageType(db结构视图)

列名称	数据类型	长度
			InsuranceCoverageTypeID	int	4
InsuranceCoverageType	varchar	50
			InsuranceTypeID	int	4

表122 tbISCEQualifiersInsurance(db结构视图)

列名称	数据类型	长度
			InsuranceTypeID	int	4
InsuranceCoverageTypeID	int	4
			SCERequired	Char	1
SCERequired$Amount	Money	8
			CurrentStatus ID	int	4
ApproverUserTypeID	int	4
			ApproverUserID	int	4
ApprovalDate	datetime	8
			DeactivationDate	datetime	8
RecordID	int	4

表123 tbISCEQualifiersBusiness(表格视图)(db结构视图)

列名称	数据类型	长度
			Contracted	char	1
vBusinessEntityTypeID	sql_variant
			vFedIdentity	char	1
vIncorporationCountryID	int	4
			vMinimumYearsInBusiness	numeric	9
vDBECertification	char	1

vSmallBusinessDesignationID	char	1
			vISOCertified	char	1
vMinimumNetFinancialWorth	money	8
			VUses_FT_W2_employees	char	1
vStaffSupplementation	char	1
			vProjectSupplementation	char	1
vEDICapable	char	1
			vEFTCapable	char	1
CurrentStatusID	int	4
			AppproverUserTypeID	int	4
ApproverUserID	int	4
			ApprovalDate	datetime	8
DeactivationDate	datetime	8
			RecordID	int	4

表124 tbISCEQualifiersBusiness(样品值)(db结构视图)

列名称	值
		Contracted	Y
vBusinessEntityTypeID	1，2，4，7，10
		vFedIdentity	Y
vIncorporationCountryID	213
		vMinimumYearsInBusiness	3
vDBECertification	Y
		vSmallBusinessDesignationID	N
vISOCertified	N
		vMinimumNetFinancialWorth	$1,000,000.00
VUses_FT_W2_employees	Y
		vStaffSupplementation	N
vProjectSupplementation	Y
		vEDICapable	Y
vEFTCapable	Y
		CurrentStatusID	1
AppproverUserTypeID	1
		ApproverUserID	134
ApprovalDate	3/9/2003
		DeactivationDate	NULL
RecordID	1

表125 lkpProcessType(db结构视图)

列名称	数据类型	长度
			Id	int	4
DocType	varchar	20
			Description	varchar	250
WaitingForApprovalStatusID	int	4
			ApprovedStatusID	int	4
DeclinedStatusID	int	4
			TableName	varchar	128
IdFieldName	varchar	128
			StatusFieldName	varchar	128
ApprovalDateFieldName	varchar	128
			DeclineDateFieldName	varchar	128
ProcessingMatrix	char	1
			ApprovalStortPriority	int	4

图4中包括分包商资质保障表402，保障类型表404，保障覆盖类型表406，处理类型表408，分包商资格商务表410和现在状态表412。在图4中列出了表402-412的相互联系。表120中列出的采样数据可以存储在保障类型表404中，表121中列出的采样数据可以存储在表406中，表122中列出的采样数据可以存储在表402中，表124中列出的采样数据可以存储在表406中。表124中列出的分包商商务资质采样数值可以存储在表410中，表125列出的采样数据可以存储在表408中。

分包商资质保障表402中包括多种数据，这些数据是买方用来对分包商保障条件进行分级评估的。保障类型表404包括与分包商的保障要求类型有关的不同信息。与表402和表404之间的关系类似，保障覆盖类型表406包括了与分包商保障覆盖类型要求有关的不同数据。

附图5A-B通过一个高级的流程图演示了一个分包商是如何被启用并且与一个主供应商进行联系的实施例。在一个分包商启用过程中，买方的设置(configuration)被用来与工作流程相结合来管理一个被控制的分包商的启用流程。在附图5A-B所示的一个分包商启用流程500中，各个参与实体在与之相适应的各过程片断中都能获得各自的显著作用和地位并被显示出来。

流程500从步骤502开始。在步骤502，一个有资质的供应商从一个供应商的主页上激活一个管理分包商的链接。在步骤504，提供了一个显示已经加盟的所有分包商以及他们的现状的列表。在步骤506，响应于对一个特定的分包商的选择，显示复数个功能性的选项。在步骤508，4个示例性的选项显示如下：1)查看分包商详细信息；2)查看分包商活动；3)去除对分包商的激活(de-activate SCE)；4)加入新分包商。

从步骤508开始，如果选择了选项1)，在步骤510，能够使被选择的分包商成为被买方许可的用户的主要数据被显示出来。在本发明的实施例中，在步骤510所显示的数据是只读数据。如果在步骤508选择了选项2)，在步骤512，被选择的分包商的活动报告的综合数据会被显示出来。在本发明的实施例中，步骤512所显示的数据为只读数据。如果在步骤508选择了选项3)，在步骤514，所选择的分包商的数据，连同一个“如果取消激活，该分包商将不能再被使用”的警告会被显示出来。如果在步骤508选择了选项4)，在步骤516，一个已经被授权的分包商的列表被显示出来。从步骤514开始，执行过程到步骤520。在步骤520，“去除对分包商的激活(de-activate SCE)”，或者是“取消去除对分包商的激活(cancellation of de-activation of the SCE)”会被选择。

从步骤520开始，如果选择的是“取消去除对分包商的激活”，转到步骤508。如果选择的是“去除对分包商的激活”，执行过程到步骤522。在步骤522，检查将要被取消激活的分包商是否已经打开了活动。如果，在步骤522检查出将要被取消激活的分包商已经打开了活动，执行步骤524。在步骤524，一个消息被显示出来提示供应商当将要被去除激活的分包商现在存在活动时，去除激活的操作将不会发生。

在步骤522，如果并没有检查出将要去除激活的分包商已经打开了活动，执行步骤526。在步骤526，供应商将被提供一个去除激活的系统处理消息。从步骤526，执行过程到步骤528。在步骤528，分包商被通过电子邮件通知该分包商被取消激活，同时系统也针对此进行更新。

从步骤516，执行过程到步骤518。在步骤518，检查所希望加入的分包商是否已经显示出来，执行过程到步骤530。在步骤530，一个列举了已经授权的分包商的列表被显示出来。本领域的技术人员能够理解，出于商业考虑将规定一个列举已经授权的分包商的完全列表不会对使用该系统的某些特定实体显示。

在步骤532，将会检查一希望的分包商是否被显示。如果检查出来是这样的，就执行步骤534。如果在步骤532没有检查出来希望的分包商被显示，执行步骤536。在步骤534，供应商选择分包商并且提交选择。在步骤538，供应商被提示接受或者修改在步骤534所做出的选择。如果供应商接受了步骤534做出的选择，执行步骤540。如果供应商要修改这些选择，转到步骤530。

在步骤540，一个消息显示分包商将要被通知该供应商的激活请求。在步骤542，激活请求的通知通过电子邮件被送到分包商那里，系统被更新来反映由主供应商发给分包商的激活请求。本领域技术人员将会理解，一个分包商/供应商关系的激活不是一个从供应商到分包商的单方面要求，而是必须由分包商和主供应商两方都认可的过程。在步骤544，分包商进入系统。在步骤546，分包商接受或拒绝加入的请求。如果在步骤546分包商拒绝了加入的请求，执行步骤548。在步骤548，供应商被通知分包商拒绝了加入的请求。

如果，在步骤546，分包商接受了加入的请求，执行步骤550。在步骤550，通过电子邮箱，供应商被通知分包商接受了请求，系统进行更新来反映分包商接受了请求。在步骤552，在应用数据库中存储这种联系，供应商/分包商的关系被指定为有效的关系。虽然在附图5A-5B中没有明确地演示，但是将一个供应商和一个分包商加入的过程可以包括在分包商/供应商关系上的各种限制，而这种限制同前面讨论的主供应商/买方关系上的各种限制类似，譬如，由分包商提供给主供应商的产品和/或者服务上的商品或地理限制。

如上所记载的，如果在步骤532没有检查出希望的分包商已经被显示出来，执行步骤536。在步骤536，在供应商面前显示一输入画面，并且由供应商输入相关联系数据。从步骤536，执行过程到步骤554。在步骤554，供应商向程序管理员提交一个请求，并且通知其成功传输。在步骤556，通过电子邮件通知程序管理员添加分包商的请求，系统被更新。在步骤558，程序管理员建立一个分包商的记录，并且指定了适当的进入系统的凭证。在步骤560，该分包商被通知已经提供了该进入系统的凭证。在步骤562，分包商用在步骤558中建立的进入系统的凭证进入系统。

在步骤564，在分包商面前显示一个供应商信息进入画面。在步骤566，分包商完成并提交进入表格。在步骤568，通过电子邮件通知程序管理员分包商提交了表格，系统更新。从步骤568，进行到步骤570。在步骤570，检查该管理员是否已经认可了该进入表格。如果在步骤570检查到管理员已经认可了该进入表格，进行到步骤574。在步骤574，该分包商在系统上被激活，有关激活该分包商的标准通知被提供给分包商和主供应商。从步骤574，转回到步骤532，在这个步骤中希望的分包商将被显示出来，分包商的加入过程开始进行。如果在步骤570该管理员没有认可该进入表格，执行步骤572。在步骤572，该供应商和该分包商被通知该分包商的认可被拒绝。

由于根据规定，分包商不能直接响应投标而被引发，只能通过主供应商的联系，买方和分包商之间的业务才能够产生。在本发明的实施例中，没有所有各方的同意，任何关系都不能成立。

用于分包商的启用和联系主供应商的数据结构的实例被显示在表单126-129。为了简化，该数据结构被组织成表单格式，并且用每个表单包括了分包商的启用和联系主供应商所需的全部域。这些表单以等级和/或相关的方式组织，以便于所有用来分包商启用和联系主供应商必要的信息被累积存储和访问进入，就像下面联系附图6所详细描述的那样。然而，应该能够理解其他的设置也可以被包括进来，而且系统不是仅限于表单113-118和附图6所列出的具体设置。

表126 tbISCESetupRequest(db结构视图)

列	数据类型	长度
			PSVendorID	int	4
UserID	int	4
			RequestDate	datetime	8
SCECandidateName	varchar	100
			SCECandidateContactFN	varchar	50
SCECandidateContactLN	varchar	50
			SCECandidateContactTitle	varchar	50
SCECandidateContactPhone	varchar	50
			SCECandidateContactEmail	varchar	50
SCEApprovalStatus	int	4
			RecordID	int	4

表127 tbISCEAffiliationRequest(db结构视图)

列名称	数据类型	长度
			PSVendorID	int	4
PSVendorContactID	int	4
			RequestDate	datetime	8
SCECandidateVendorID	int	4
			SCEApprovalStatus	int	4
UserTypeReviewerID	int	4
			ReviewerUserID	int	4
ReviewerDispositionDate	datetime	8
			SCEStatusDispositionCode	int	4
RecordID	int	4

表128 lkpSCERequestStatusDisposition(db结构视图)

列名称	数据类型	长度
			SCEStatusDispositionCode	int	4
SCEStatusDispositionDesc	varchar	25

表129 tbISCEMapPrimarySupplier(db结构视图)

列名称	数据类型	长度
			SCEVendorID	int	4
PrimarySupplierID	int	4
			CurrentStatusID	int	4
SCEMapRecord	int	4

表单126-129列出了可以存储在数据库表单中的分包商启用数据。显示在表单126中的该分包商启用数据能够存储在一个SCE setup request Table608中。在表单127中的分包商启用数据能够存储在一个SCE affiliation request Table604中。在表单128中的分包商启用数据能够存储在一个SCE request status disposition Table 612中。在表单129中的分包商启用数据能够存储在一个SCE map primary supplier Table610中。

附图6描述了一个数据库模型/纲要，该数据库模型可用于与附图5A-B中所定义示例的分包商启用过程联系。在附图6中，用于分包商启用的数据库纲要，包括了一个基本供应主表602、SCE联系请求表604、基本供应联系表606、SCE建立请求表608、SCE图基本供应表610、SCE请求状态部署表612、SCE当前状态表614。各个表单602-614之间的联系如附图6演示。

图7是主供应商如何选择并如何将分包商纳入买方的投标邀请系统的典型流程图。工程流程图700开始于步骤702，在该步骤，有资质的供应商会收到买方统一公告的报价/建议/投标邀请。在编号为10/262,487的美国专利申请中详细的解释了怎么创建一个统一公告的报价/建议/投标邀请，而这是买方要先决处理的。

在步骤704，将会判断主供应商是否会邀请加盟的分包商进入到投标响应过程中。如果判断供应商会邀请加盟的分包商进入投标响应过程，执行过程将转到步骤706。在步骤706，供应商激活分包商报价功能。如果在步骤704中，判断供应商会不会邀请分包商进入投标响应过程，执行过程将转到步骤705，在这里，执行过程结束。

步骤706执行完之后，执行过程将转到步骤708，在该步骤，系统将显示一个满足买方资质标准的供应商加盟分包商列表。在步骤710，将会做一个判断，判断列表中是不是至少有一个分包商，如果判断是，在步骤712，促使供应商选择理想的分包商。如果在步骤710，判断结果是没有一个满足条件的分包商在列表上，执行过程将转到步骤714。在步骤714，供应商会得到一个信息，该信息显示，只有在分包商加盟条件有诱惑力以及分包商达到买方资质标准时，工作流程表700的功能才会被启动。

从步骤712开始，进行的是供应商对理想的分包商的选择。执行过程将转到步骤716。在步骤716，供应商将得到一个要求供应商反馈的报价/建议/投标邀请投标项列表。在步骤718，促使供应商选择分包商报价理想的项。执行完步骤718之后，执行过程转到步骤720，步骤720是对供应商做出的理想项的选择的回应。在步骤720，会显示一个供应商上选择的分包商投标项目列表。在步骤722，将会判断对选择的投标项目的编辑是否必要。在步骤722，如果判断是必要的，执行过程返回到步骤718，如果判断不是必要的，执行过程将进行到步骤724。

在步骤724，将判断对分包商的编辑是不是必要的。在步骤724中，如果判断为是，对分包商的编辑功能将激活，执行过程会转到步骤726。在步骤724中，如果判断结果是供应商不想在公告名单上增加新的分包商，公告功能将启动，执行过程将转到步骤728。

在步骤726，会显示没有被供应商选择的分包商的列表。在步骤732，将会判断是否至少有一个分包商在列表上出现。如果是，执行步骤转到步骤734，在步骤734，促使供应商选择理想的分包商。从步骤734开始，作为对供应商做出的选择的回应，执行步骤返回步骤724。如果在步骤732中，判断出没有分包商出现在列表中，执行步骤转到步骤736，在该步骤，推荐供应商公布一个分包商纪录。从步骤736开始，启动公告功能，执行过程将转到步骤728。

像上面说明的那样，从步骤724到步骤728的操作是对没有判断供应商是否想编辑公告上的分包商名单的回应。在步骤728，供应商公布一个分包商报价，分包商总体报价将会被存储在数据库中。在步骤728之后，执行过程将转到步骤730，在步骤730，系统显示一个传送纪录。执行过程从730转到步骤702。

在图7中，虽然没有清晰的描述，主供应商可能创建一个标准的分包商总体报价，该总体报价会系统地按照特定的投标响应项目和分包商进行匹配。举例来说，主供应商会为人力资本工程服务设置一个确定的分包商组，这样，每当主供应商收到包含特定的投标响应项目的报价时，系统会自动地为配置的分包商生成一个具体的分包商总体报价。主供应商也许会创建一个可变的分包商总体报价，其中包括投标项目和被选择的分包商。

图7显示分包商总体报价项目受到包含在买方报价/建议/投标邀请报价中因素的影响。然而，在发明的一些其他实现方法中，分包商总体报价可能会扩展到包含主供应商所创建的动态项目。图7中描述的分包商报价公告过程和编号为10/262,487的美国专利申请中描述的买方为主供应商公告报价/建议/投标邀请过程类似。

表130-132展示的是一个用于在买方竞标申请中选择和包括分包商的数据结构的例子。这些数据结构以表格的形式组织起来，每一个表格都包括在竞标申请中选择和包括分包商的所有必需的领域(fields)。这些表格以层级或者关系方式联系起来，这样，所有用于选择和包括分包商的必要信息可以正确的存储和访问。然而，应当明白的一点是，其他的配置方式也可以包含在系统中，而且系统也不仅仅局限在表130-132中所列出的特定配置方式上。

表130 tbISCEQuoteProfiles(db结构视图)

列名称	数据类型	长度
			VResponse_ID	int	4
VUser_ID	int	4
			CurrentStatus_ID	int	4
DateCreated	datetime	8
			SCEProfileID	int	4

表131 tbISCEQuoteProfilesPost(db结构视图)

列名称

数据类型

长度

SCEProfileID	int	4
			SCEPrimary supplierID	int	4
Post_Date	datetime	8
			PostingRecordID	int	4

表132 tbISCEQuoteProfilesItems(db结构视图)

列名称	数据类型	长度
			SCEProfileID	int	4
RFX_Item_ID	int	4
			RecordID	int	4

表130-132是用在联接图7中的工作流程表700的典型的分包商表格。表130-132用于竞标项的基本存储。表130包括response识别码，用户识别码，现在状态识别码，创建日期以及profile识别码组成的一列要素。作为公告纪录的表131，包含主供应商识别码，profile识别码，公告日期以及公告纪录。表132可能被用来进行分包商报价可以被主供应商接受的事件的自动上传。

附图8是一个示例流程图来解释一个分包商如何处理一个主供应商发布的菊花链报价单。在本发明的各个实施例中，与美国专利申请U.S.Patent Application No.10/262,487所描述相似的用于在投标响应过程的主供应商的功能将被授与分包商。附图8中所示的分包商报价过程与美国专利申请U.S.Application No.10/262487所描述的用于主供应商的逻辑相似。在附图8中，分包商对报价情况的观看受主供应商选择的项的限制；然而，如果主供应商将其视为与分包商的答复相关，任何出价的要素都可以显示给分包商。

在附图8中，流程800从步骤802开始。在步骤802，一个分包商通过被允许访问系统已经接受了一个供应商的报价请求。在步骤804，检查买方协议是否要实施。譬如，买方可能会要求主供应商执行一个不公开的协议作为投标过程的条件。以类似的方式，被要求执行不公开的协议的主供应商可能要求与该主供应商联系的分包商服从于菊花链式的报价过程来执行不公开的协议。如果在步骤804检查到是这样的，就前进到步骤806，在步骤806，检查分包商是否在一个具体的时间框架中执行了需要的协议。如果在步骤806，检查到分包商已经在具体实践框架中执行了协议，执行步骤810。在步骤810，分包商访问报价。如果在步骤804，并没有检查到买方的协议需要执行，执行步骤810。在步骤808，如果没有检查到分包商已经在具体的时间框架内执行了协议，该分包商被从报价过程中排除，供应商被通知协议没有该分包商顺从地执行。

从步骤810，执行步骤812。在步骤812，检查该分包商是否已经在指定的时间框架内完成了所有要求的输入要素。如果在步骤812，检查该分包商已经完成了所有在指定时间内要求的输入要素，执行步骤814。在步骤814，该分包商的报价被认为是能够合格地提交给该供应商。在步骤816，该分包商提交该分包商的报价给该供应商，该供应商被通过电子邮件或系统的通知的方式告知。

如果在步骤812，并没有检查到该分包商已经在规定的时间内完成了所有要求的输入要素，执行步骤818。在步骤818，该分包商被排除出提交报价并且发行的供应商被通知报价提交最后期限(quotation-submittal-deadline)已经过期。

在分包商处理主供应商发布的菊花链报价中所使用的数据结构被显示在表单133-142中。该数据结构被简化显示为表单格式，通过每一个表单而包括了该分包商处理主供应商发布的菊花链报价所需要的全部的域。这些表单以一个等级和/或相关的方式产生联系，以便所有用于分包商配置的必要信息能够被累积存储和访问。然而，应当理解其他的配置也包括在内，这个系统不局限于表单133-142所列出的具体配置。

表133 tbISCEQuoteResp(db结构视图)

列名称	数据类型	长度
			SCEPostingRecordID	int	4
SCEQuoteStatusID	int	4
			SCEQuoteCreateDate	datetime	8
SCEQuoteSubmitDate	datetime	8
			SCEQuoteResponseID	int	4

表134 tblSCEQuoteRespMain(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponseID	int	4
RFX_Item_ID	int	4
			Required_Item	char	1
SCE_Response	varchar	5000
			Record_Create_date	datetime	8
Last_Save_Date	datetime	8
			RFX_Section_id	int	4
RFX_Category_id	int	4
			RFX_Response_Complete	char	10
RFX_Grade	char	1

RFX_Points

int

4

表135 tblSCEQuoteRespMaterials(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponesMainID	int	4
SCEProfileItemID	int	4
			RFX_Item_ID	int	4
Identity_Key	int	4
			RFXRespMateriaIRowID	int	4
Material_Category	varchar	100
			Material_Name	varchar	100
Material_Description	varchar	1000
			Material_Manufacturer	varchar	100
Unit_Count	int	4
			Unit_Cost	money	8
Line_Item_Cost	money	8
			Client_Comments	varchar	1000
SCE_User_ID	int	4
			SCE_User_Contact_ID	int	4
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
SCEMatRecordID	int	4

表136 tblSCEQuoteRespDeliverables(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponesMainID	int	4
SCEProfileItemID	int	4

RFX_Item_ID	int	4
			Identity_Key	int	4
RFXRespDeliverableRowID	int	4
			DeliverableName	varchar	50
Deliverabledescription	varchar	1000
			AnticipatedCompletionDate	datetime	8
BillableDeliverable	char	1
			PaymentAmount	money	8
PartiaIPaymentAuthorized	char	1
			Client_Comments	varchar	1000
SCE_User_ID	int	4
			SCE_User_Contact_ID	int	4
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
SCEDeIRecordID	int	4

表137 tblSCEQuoteRespUnits(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponseMainID	int	4
SCEProfileItemID	int	4
			RFX_Item_ID	int	4
Identity_Key	int	4
			RFXRespUnitRowID	int	4
UnitName	varchar	50
			UnitCompletionDescription	varchar	1000
UnitCount	float	8

UnitCost	float	8
			LineUnitCost	float	8
UnitsAuthorized	char	1
			BillableUnits	char	1
PartialPaymentAuthorized	char	1
			Client_Comments	varchar	1000
SCE_User_ID	int	4
			SCE_User_Contact_ID	int	4
Record_Create_Date	datetime	8
			Last_Edit_Date	datetime	8
SCEUnitRecordID	int	4

表138 tblSCEQuoteRespProjExp(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponesMainID	int	4
SCEProfileItemID	int	4
			RFX_Item_ID	int	4
Identity_Key	int	4
			RFXRespProjExpID	int	4
ProjectExpenseName	varchar	50
			ProjectExpenseDescription	varchar	1000
BillableExpense	char	1
			MaxAmount	money	8
PartiaIPaymentAuthorized	char	1
			CurrencyID	int	4
SCE_User_ID	int	4

SCE_User_Contact_ID	int	4
			Record_Create_Date	datetime	8
Last_Edit_Date	datetime	8
			SCEProjExpID	int	4

表139 tblSCEQuoteRespStaffprofiles(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponesMainID	int	4
SCEProfileItemID	int	4
			RFX_Item_ID	int	4
RFXStaffingProfileID	int	4
			pAnticipatedHours	int	4
pQuantity	int	4
			pBilling	money	8
Client_Comments	varchar	1000
			SCE_Use_ID	int	4
SCE_User_Contact_ID	int	4
			Record_Create_Date	datetime	8
Last_Edit_Date	datetime	8
			SCEStaffingRecordID	int	4

表140 tblSCEQuoteRespStaffProfilePrice(db结构视图)

列名称	数据类型	长度
			SCEStaffingRecordID	int	4
SCEStaffingProfilePriceID	int	4
			Anticipated_Hours	float	8

Bill_Rate	money	8
			Anticipated_Billing	money	8
RecordCreateDate	datetime	8
			RecordID	int	4

表141 tblSCEQuoteRespStaffProfileExpense(db结构视图)

列名称	数据类型	长度
			SCEStaffingRecordID	int	4
ContractorExpenseTyPeID	int	4
			ContractorExpenseTyPeMax	money	8
SCEContractorExpenseID	int	4
			RecordCreateDate	datetime	8
RecordID	int	4

表142 tblSCEQuoteRespPhasing(db结构视图)

列名称	数据类型	长度
			SCEQuoteResponesMainID	int	4
SCEProfileItemID	int	4
			RFX_Item_ID	int	4
RFXRespPhaseID	int	4
			Project_Phase_Number	int	4
Project_Phase_Description	varchar	3200
			Start_Date	datetime	8
End_date	datetime	8
			Total_Days	numeric	9
Client_Comments	varchar	1000
			SCE_User_ID	int	4

SCE_User_Contact_ID	int	4
			Record_Create_Date	datetime	8
Last-Edit_Date	datetime	8
			SCEPhaseRecordID	int	4

表单133-142是用于与附图8中的流程800相联系的示例表单。表单133-142类似于一个用于一相关的申请中披露的主供应商-主供应商关系的主供应商表单。尽管表单133-142的数据模型与优先申请中用于主供应商-主供应商关系的主供应商表单所披露的数据模型类似，对于本领域技术人员而言，其区别还是很明显的，包括一个拆解功能，在下面将会讨论其更多的细节。

附图9是一个显示了一主供应商如何处理一个分包商菊花链报价响应的示例流程图。附图9显示了分包商的报价响应被选择和整合到主供应商的投标响应。在本发明的各个具体实施例中，一个数据库方案和投标响应项拆解程序允许该主供应商选择希望分包商的报价要素和整合这些选择的分包商的报价要素进入他们的合适的位置持有者。附图9并没有明确的演示该分包商能够接受或拒绝一个主供应商对分包商报价的接受；然而，根据本发明的宗旨，这种能力可以很容易的设置的。

参见附图9，一个流程900从步骤902开始。在步骤902，该供应商正在接受该分包商的报价响应。在步骤904，该供应商通过标准RFx过程进入投标响应。在步骤906，供应商的投标响应的状态被显示出来，同时显示是否有任何现存的总体报价的存在以及是否有任何分包商的报价已经被相对于总体报价被接收。响应于步骤906和供应商激活一个分包商总体报价的链接，执行步骤908。在步骤908，一个列出与可使用的分包商总体报价相关联的分包商的列表被显示出来。

在步骤910，该供应商可选择性地创建一个分包商总体报价分析方案来管理相对于简单的分包商总体报价的多个报价。在与一个买方能够以不定的方式等待供应商的投标响应项的方式相似，该供应商能够以不定的方式等待来自分包商的投标响应项从而便于分析和做出可能的决标。在步骤912，该供应商将各个分包商报价分级。在步骤914，各个分包商报价的积分被计算出来。在步骤916，该供应商访问一个分包商总体报价分析总结来比较适用的分包商报价积分。

在步骤918，检查该供应商已经接受还是已经拒绝了该分包商报价。如果在步骤918，该供应商接受了该分包商的报价，执行步骤920。在步骤920，该供应商选择了一个单独的分包商报价记录并且激活一个接受功能。在步骤922，一个“Are You Sure？”的提示将被提供。如果回答“Yes”，执行步骤924。如果回答“No”，转回到步骤918。

在步骤924，该分包商报价被显示出来。在本发明的各实施例中，所有的适用于该供应商的投标响应的项目已经联系到检验栏(checkbox)，该检验栏对于任何的在其中投标响应项已经被一个接受的供选择的分包商阻碍的项是不活动的。在步骤934，该供应商选择适当的报价项并且激活一个“接受选择”功能。在步骤936，检查该供应商是否已经选择了至少一个包含了票据的(billable)服务和材料。如果在步骤936没有检查出，执行步骤938。在步骤938，一个错误消息被显示，提供一个提示来再次选择可以接受的报价项目。从步骤938开始，执行步骤934。

在步骤918，如果该供应商拒绝了该分包商的报价，执行步骤926。在步骤926，个别分包商报价记录被选择并且一个拒绝功能被激活。在本发明的各实施例中，个别分包商报价记录能够通过相应的检查栏被选择。在步骤928，一个“Are You Sure”的提示被显示。如果回答“Yes”，执行步骤30。在步骤30，该分包商报价状态被更新为“Declined”。如果回答“No”，重新回到步骤918。

回到对步骤936的讨论，在步骤936检查出该供应商已经选择了至少一个项目包含了一个票据(billable)服务或材料，执行步骤940。在步骤940，检查该供应商是拥有全部还是部分分包商报价。如果在步骤940，所有的分包商报价的项目已经被该供应商所接受，执行步骤942。在步骤942，一个“Acceptance”的消息被提供给该供应商，报价价值被存储到该供应商的投标响应中。如果，在步骤940，该供应商已经接受仅仅一部分分包商报价，执行步骤944。在步骤944，一个“Acceptance”消息被提供给供应商并且报价的价值被储存到该供应商的投标响应中。此外，该分包商报价的状态可以改变至“部分接受”。从步骤942和步骤944，执行步骤932。在步骤930，执行步骤932。在步骤932，标准通知被通过系统更新和电子邮件的方式发行。

图10是主供应商怎样采用报价分析工具队分包商提供的报价单进行分析的典型流程图。图10说明了主供应商怎么像买方那样利用投标响应评分工具使报价过程更加简单。图10并没有很清楚地说明配置一个将在主供应商的投标响应系统中的最佳分包商得分自动上传的能力，然而，如果符合发明的原则，这项能力可以通过配置来获得。

在图10中，工作流程表1000开始于步骤1002。在步骤1002，供应商选择一个理想的分包商总体报价。在发明的多种实现方法中，分包商总体报价列表通过广播按钮来显示，供应商可以通过激活和特定的广播按钮相连的链接启动理想的分包商总体报价。在步骤1004，判断对于特定的分包商总体报价，是否存在多个分包商报价。如果不是，执行过程将转到步骤1006。在步骤1006，供应商将得到一个说明评分分析系统只适用于有多个报价的情况。如果在步骤1004判断出对于特定的分包商总体报价，存在多个分包商报价，那么，执行过程将转到步骤1008。

在步骤1008，供应商可以采用加权和评分工具对报价质量进行分级。买方在对主供应商提供的投标响应进行分级采用分级工具在编号为10/262,487的美国专利申请中过详细的描述过。在这里提及分级工具，是为了评估分包商投标响应报价质量，分级工具和编号为10/262,487的美国专利申请中的分级工具有相似的功能。在步骤1010，将显示一个合适的分包商总体报价中包含的报价响应项列表。在步骤1012，供应商指出哪些投标响应项会被用于分析，并建立对被选项的相关的重要加权。在步骤1014，供应商需要做一个是要编辑还是要保存设置的选择，如果供应商选择编辑设置，执行过程返回到步骤1010，如果供应商选择保存设置，执行过程转到步骤1016。

在步骤1016，包括用在分析中的投标响应项的集合将作为分包商总体报价分析架构来存储。在发明的多种实现方法中，合适的分包商报价适合用于分级和评估分析。在步骤1018中，供应商选择理想的分包商报价，并激活一个分级函数。比如，按照预定的标准，一个许可的供应商会用一个A-E的等级体系对分包商进行评级。在步骤1020中，一个分包商报价将显示给供应商，那些适合用于建立一个分包商总体报价分析架构的项目将被重点标示出来，用于供应商输入的一个分级领域也被显示出来。在步骤1022中，供应商对合适的项目按从A-E的等级进行分级

在本发明的实施例中，保存设置的功能只有在所有要求的项目都被供应商进行了等级评定之后才被激活。一旦所有要求的项目都被进行了登记评定，控制设置保存的能力就会被激活，执行过程转到步骤1024。在步骤1024，供应商需要做是编辑还是保存设置的选择。如果在步骤1024中，供应商选择编辑设置，执行过程返回步骤1022，如果在步骤1024，供应商选择保存设置，执行过程转到步骤1026。

在步骤1026，供应商会收到一个处理成功信息，同时，会保存分包商的报价等级。在步骤1028，促使供应商做一个是否对分包商报价进行比较的选择。如果供应商选择进行比较，在步骤1028中会比较分包商报价，执行过程转到步骤1030。

在步骤1030中，判断对于分包商总体报价分析架构是不是存在多个级别评定过的分包商报价。如果有多个级别评定过的分包商报价用来进行分包商总体报价分析架构，执行过程转到步骤1032。在步骤1032，供应商选择理想的分包商总体报价。在发明的多种实现方法中，供应商激活一个或者多个广播按钮来显示作为连接的列表。

在步骤1034，显示所有的分包商报价列表。在发明的多种实现方法中，显示列出了所有的可以进行评分的项目，适合等级，指明项目权重和总的项目分数。总的报价分数和统计排名也可能在总表中显示出来。作为上述内容的补充，供应商还可以从主报价/建议/投标邀请响应菜单中队分析概要进行访问。

附图11是演示一个主供应商如何在已经接受的分包商报价的基础上增加边际价格的流程示例图。特别的，附图11演示了主供应商如何修改或标高分包商报价给买方。在本发明的各个实施例中，一个买方可以设置或者限制许可的对价格的标高。前面讨论的数据表单可以用来支持附图11中功能演示。譬如，在表单130-142中演示的该分包商投标响应表单类似于美国专利申请U.S.Patent ApplicationNo.10/267,487中所述的主供应商的投标响应表单。

在附图11中，流程1100从步骤1102开始。在步骤1102，该供应商进入包含有分包商接受的报价要素的投标响应。在步骤1104，该供应商能够标高接受的报价要素的价格。如果在步骤1104，供应商标高了价格，执行步骤1106。如果供应商没有标高价格，执行步骤1130。

在步骤1106，该供应商可选择一个修改分包商价格的功能。响应于选择该修改分包商价格的功能，从步骤1106执行步骤1108。在步骤1108，一个列举了被接受的分包商报价要素和可使用的价格的列表被显示。在步骤1110，该供应商选择希望的项，激活一个修改价格的功能。在步骤1112，检查该供应商是想要定义一个具体的标高价格的百分比，还是手动修改价格。如果在步骤1112，该供应商想要定义一个具体的标高价格的百分比，执行步骤1114。如果，在步骤1112，该供应商想要手动修改标高价格，执行步骤1118。

在步骤1114，该供应商被提供一个显示和一个输入百分比的域。在步骤1116，该供应商输入希望的标高价格的百分比然后激活一个更新价格的功能。在步骤1118，向该供应商显示为每个分包商项目输入现金数目的域。在步骤1120，该供应商输入对每个项目都适用的希望的价格，更新价格功能被激活。

从步骤1116和1120的每一个，执行步骤1122。在步骤1122，从步骤1116或是1120接收的输入被与配置规范相对比地计算。例如，如附图2A和3A所示，一个买方能够设置最高的为主供应商输入的标高价格上限。在步骤1124，检查在步骤1122执行的确认是否已经通过。如果在步骤1124，检查到在步骤1122执行的该确认没有被通过，该供应商被提供一个错误消息，显示在步骤1126确认失败。从步骤1126，执行步骤1112。

如果，在步骤1124，检查到在步骤1122执行的确认已经通过，执行步骤1128。在步骤1128，系统更新该供应商带有新的价格和适用的数据库记录的投标响应。在步骤1130，该供应商利用一个标准过程模式提交投标响应给买方。在步骤1132，系统通知被送给适用配置的各方。

附图12演示了一个比用于与附图7-11中描述的分包商菊花链投标响应的实例相联系的数据库模型/方案。如同附图12所显示的那样示例，主提供商投标响应被收集到多个表单而不是只有一个表单。因此，RFx响应主表单128能够从RFx响应材料表单1210、RFx响应递送表单1212、RFx响应单元表单1214、RFx响应项目费用表单1216、Rfx profile perresponse表单1218、和RFx响应拆解表单1220收集信息。因此，上面所述的表单132-140是一套为存储在适用的专门的投标项中的分包商所建立的多余的投标响应表单。根据本发明的宗旨，不同的投标项包含了连同多个域的多个要素，例如，材料价格。例如，材料项是一个允许将众多的材料的总体进入一个预先成立的表单的投标项。

如附图12所示的，RFx响应主表单1208可以收集数据的每一个表单都有响应的分包商表单。例如，RFx响应材料表单1210同分包商报价响应材料表单1234相联系、RFx响应递送表单1212与分包商报价响应递送表单1236相联系、RFx响应单元表单1214与分包商报价响应单元表单1238相联系、RFx响应项目费用表单1216与分包商报价响应项目费用表单1240相联系、RFx响应拆解表单1220同分包商报价响应拆解表单1242相联系。同样的，RFx总体响应表单1218、RFx资源总体价格表单1222、RFx资源总体费用表单1224与分包商报价响应职员(staff)总体费用表单1228、分包商报价响应职员总体价格表单1230、以及分包商报价响应职员总体表单1232相联系，如附图12所示。

与上面讨论的相似，分包商报价响应主表单1246与表单1234、1236、1238、1240、1242中的每一个联系。同时也显示了分包商报价响应主表单1246与分包商报价响应表单1248、分包商总体报价项表单1250、分包商报价总体邮递(post)表单1252相联系。分包商总体报价表单1254被显示与表单1250、1252和1204的每一个联系。相似的，主供应商主表单1202被显示与响应表单1204和分包商映射主供应商表单1206相联系。响应表单1204与RFx响应主表单1208联系。

如附图12所演示的，该数据库模型/方案允许从主供应商到分包商以及相反方向的信息流。拆解数据可能优先在任何一个方向上进行传输之前发生。附图12所示的数据库模型/方案允许在买方的投标项、主供应商的投标响应项、以及分包商的投标响应项之间产生连通性。

图13是买方处理主供应商投标响应的典型的流程图。图13还说明了买方如何能够看到分包商投标响应包含项。图13说明了买方投标响应处理阶段的投标响应分级，投标响应决标以及购买申请等各个部分。

在本发明的具体实施例中，买方对主供应商的投标响应进行分级/评分过程以及投标响应决标过程可以用和编号为10/262,487的美国专利申请中阐述的方法相仿的方法来实现。符合发明原则的分包商报价要素的可见性会使买方可以功过综合或者分割的方式看到附加的报价和应用信息。买方看到标价和应用信息，会极大的增强买方的与最佳反应有关的决策过程能力，另外，还会提供给买方的议价和/或服务谈判工具。

在图13中，工作流程图1300开始于步骤1302。在步骤1302，买方访问投标响应列表，在本发明的具体实施例中，用户对投标响应的访问可以利用编号为10/262,487的美国专利申请中描述的标准处理功能来实现。在步骤1304，买方访问基本供应商投标响应，在步骤1306，系统提供一个附加的控制，来访问供应商分包商资产配置概况，或者让买方访问单个投标响应。例如，供应商分包商资产配置情况可以让买方从不同的角度以及相关的不同的票据分类方法来评估主供应商和分包商对一个项目的相对贡献的大小。

从步骤1306开始，如果启动了总体控制，执行过程会转到步骤1308。在步骤1308，系统会显示主供应商投标响应的概要细节。这些主供应商投标响应的概要细节可能会包括：1、投标响应的分包商识别，2、每一个分包商的资产配置概况，3、主供应商的资产配置概况，4、主供应商加成概况，5、总体成本中的分包商总量百分比概况，6、总体成本中的主供应商总量百分比概况。

在步骤1306，如果买方访问了单个投标响应，执行过程会转到步骤1310。在步骤1310，系统为买方指出了分包商报价相关项目，并提供一种访问分包商报价细节的控制方法。在步骤1312，买方可以启动分包商报价细节控制。在步骤1314中显示的投标响应项可能会包括以下细节：1、分包商识别；2、原始分包商报价清单；3、主供应商加成点数；4、主供应商加成量等。在步骤1306中，买方可以按照自己的配置情况对投标响应进行处理。在步骤1318中，对投标响应进行登记评定，在步骤1320中，对投标响应进行决标。在步骤1322，会产生一个购买申请表。对这些有所了解的人会意识到步骤1316-1322中的每一步骤都包含一个附加的工作流程表，这个工作流程表是由买方根据自己的商业需要设定的，在编号为10/262,487的美国专利申请中对这些作为步骤1316-1322一部分的典型的工作流程表作了详细的描述。

虽然在图13中并没有很详细的在不考虑分包商投标响应项目的情况下，对买方查看主供应商投标响应评级/打分的能力进行描述。该能力在不偏离发明原则的情况下被实现。在需要的时候，用同样的方式，分包商可以被单独的评分。

图14列出的是一个典型的技术层面的数据库模型/架构，该模型/架构用于和分包商纪录创建的连接中，以及在购买申请层面上跟踪分包商报价要素。图14详细说明了如何将分包商数据传送到购买申请或者订购单阶段。

采购申请表1402从采购申请可支付表1404，采购申请支付单元表1406，采购申请支付材料表1408，采购申请支付项目费用表1410，采购申请支付比率表1428，采购申请承包商列表1430，以及采购申请支付承包商费用表1432等表格中搜集数据。报价/建议/投标邀请响应和分包商报价层面上的相应的表格和适当的采购申请表之间是相互联系，特别的，表1404，1412，1420中的数据，表1406，1414，和1422中的数据，表1408，1416，1424中的数据，表1410，1418，1426中的数据是双向传递的。同样，数据可以在表1428，1434，1440之间，表1430，1436，1442之间以及1432，1438，1444之间双向传递。

图14中的数据库模型/架构允许一个所谓的自动反馈功能，在这项功能中，在买方没有再返参数的情况下产生一个投标响应决标。在发明的一些实现方法中，买方拥有编辑功能，虽然买方并不一定使用这些功能。。

和图14中的数据库模型/架构相对应，主供应商会从分包商quote response中取出数据并将这些数据存进报价/建议/投标邀请回应中。用同样的格式，可以将主供应商的报价/建议/投标邀请response中的数据取出并输入到买方的采购申请中。通过这种方式，数据库可以跟踪从分包商创建菊花链报价到买方启动采购申请的流程中的方方面面。

附图15是一个演示了在菊花链式购买申请的过程中税务评估和接受购买申请是如何处理的流程图的实例。在附图15中演示了一个流程1500。在本发明的各实施例中，流程1500通过允许对分包商特有的采购申请要素进行拆解和重组的数据库来启动。主供应商处理税务评估和接受采购申请在美国专利申请U.S.Patent Application No.10/412,096中被公开。在附图15中所示的分包商菊花链子申请过程类似于处理税务评估和接受申请的主供应商，并且允许以一种审计和整合的方式从适当的一方得到适当的信息。流程1500被用于确保参与的各方都意识到所有的购买申请要素和条款，并且达成了一致。

流程1500在步骤1502开始。在步骤1502，主供应商进入买方的包含有分包商采购申请要素的采购申请。在步骤1504，系统指示哪个采购申请要素是分包商提供的采购申请要素。在步骤1506，系统提供主供应商活动控制(active control)来创建一个分包商菊花链子申请。响应步骤1506和供应商对子申请控制的激活，执行步骤1508。在步骤1508，系统提供一个所有分包商和适用的采购申请要素的总览。该系统也允许指定的个别要素被送到分包商来进行税务评估和接受，或者是代表分包商处理分包商要素。在本发明的各个实施例中，通过一个检查栏来做出指定。

在步骤1510，当所有分包商要素都已经被选择时，为主供应商呈现出一个“AcceptSelections”的活动控制。在本发明的各实施例中，分包商要素被通过一个相关联的检查栏选择。响应于步骤1510和由供应商控制的“接受选择”的激活，执行步骤1512。

在步骤1512，系统提供该主供应商一个过程概要显示。该过程概要显示演示了哪些分包商已经被通知一个未决的分包商菊花链子申请已经在等待过程中。在本发明的各实施例中，系统也提供给该供应商一个购买申请分包商要素，要素列举了包括挑选出来被主供应商处理的那些要素。在步骤1514，系统传送电子邮件和系统通知给适用的分包商。

在步骤1516，该分包商进入菊花链子申请。在步骤1518，呈现给该分包商一个税务评估界面。一个税务评估界面的例子在美国专利申请U.S.Patent Application No.10/412，096中被描述。在步骤1520，当SCE已经为所有适用的要素完成了税务评估时，一个“Submit For Processing”活动控制被激活。响应步骤1520和被分包商控制的活动，执行步骤1522。在步骤1522，系统向分包商提供一个画面显示税务评估已经完成以及提供一个“Accept Requisition Elements”活动控制。

响应步骤1522和分包商激活的“Accept Requisition Elements”活动控制，执行步骤1524。在步骤1524，系统处理事务，并且提供给分包商一个“Transaction-Completion”消息。此外，通过系统更新或者电子邮件，主供应商被通知一个已经完成的菊花链子申请已经可以处理。在步骤1526，该primary供应商进入包含有分包商购买申请要素的买方购买申请。该主供应商也被提供一个“Administer SCE Daisy Chain sub-requisition”的活动控制。响应步骤1526，以及被主供应商控制的“Administer SCE Daisy Chain sub-requisition”的活动控制的激活，系统提供给主供应商一个过程概要显示。该过程概要显示指示了那些适用的分包商被包括在该活动的菊花链子申请，并且也提供了该分包商响应的状态。一个“View Details”活动控制也被激活。

响应步骤1528和控制菊花链子申请的“View Details”活动控制的激活，执行步骤1530。在步骤1530，该主供应商被提供该分包商菊花链子申请的详细情况。该主供应商也被提供一个“Add To Purchase Requisition”的活动控制。

响应于步骤1530和由主供应商控制的“Add To Purchase Requisition”的活动控制的激活，执行步骤1532。在步骤1532，系统更新该采购申请并且主供应商被提供一个上载的消息。在步骤1534，主供应商更新了所有的菊花链子要素到采购申请。在步骤1536，该主供应商完成所有的主供应商所有的购买申请要素。在步骤1538，该主供应商被提供一个“Accept买方Purchase Requisition”活动控制。响应步骤1538和被主供应商控制的“Accept买方Purchase Requisition”活动控制的激活，执行步骤1540，在该步骤系统处理事务并且发行标准通知。此外，在步骤1540，该采购申请将可用于买方进行最后处理。

该发明的各实施例，提供了一个综合的数据模型从投标响应中结转分包商和主供应商的详细情况至采购申请，在该数据模型中该分包商被介绍去进行税务评估和接受采购申请的处理，并且提供买方有关采购订单的设立以及数据处理模型的配置能力和灵活性。根据本发明的财务处理的宗旨为依据的灵活的项目产品/服务凭证，买方在其中可以根据要求处理分包商的财务。

用于税务估算和接受采购申请的数据被显示在表单143-147中。这些数据结构被简化演示组织成表单形式，用每个表单包括了税务估算和接受采购申请所需的全部域。这些表单以一种等级或/和相关的方式联系在一起，这样用于分包商设置的全部必要信息将被累积存储和访问，就向下面结合附图16将要被描述。然而，应该理解其他的配置也可以包括进来，而且系统不限于表单143-147和附图16所列出的具体配置。

          表143 tblTaxNode(db结构视图)

列名称	数据类型	长度
			TaxNodeID	int	4
ParentGUID	uniqueidentifier	16
			ParentTable	varchar	100
ParentID	int	4
			CurrentStatusID	int	4
SpendingTypeID	int	4
			ReqID	int	4

        表144 tblTaxLineItem(db结构视图)

列名称	数据类型	长度
			TaxNodeID	int	4
ItemValue	varchar	1000
			TemplateGUID	uniqueidentifier	16
TaxAuthorityID	int	4
			TaxableAmount	numeric	9
TaxPercent	float	8
			TaxBurden	numeric	9
UserID	int	4
			RecordDate	datetime	8
TaxLineRecordID	int	4

       表145 tblTaxAuthority(db结构视图)

列名称	数据类型	长度
			rowid	int	4
SpendingGUID	uniqueidentifier	16
			TaxAuthorityName	varchar	100
Tax_Percent	float	8
			RegionID	int	4
CountyID	int	4
			CountryID	int	4
CityID	int	4
			MuniID	int	4
TaxAuthorityID	int	4

         表146 tblSCETaxNode(db结构视图)

列名称	数据类型	长度
			TaxNodeID	int	4
ParentGUID	uniqueidentifier	16
			ParentTable	varchar	100
ParentID	int	4
			RecordAvailableDate	datetime	8
PrimaryVendorContactID	int	4
			CurrentStatusID	char	10
SCESubmitDate	datetime	8
			RecordID	int	4
SCEVendorID	int	4

          表147 tblSCETaxLineItem(db结构视图)

列名称	数据类型	长度
			TaxNodeID	int	4
ItemValue	varchar	1000
			TemplateGUID	uniqueidentifier	16
TaxAuthorityID	int	4
			TaxableAmount	numeric	9
TaxPercent	float	8
			TaxBurden	numeric	9
SCEUserID	int	4
			RecordDate	datetime	8
SCENodeRecordID	int	4
			SCETaxLineRecordID	int	4

表单143-147演示了用于菊花链采购申请数据处理的表单。显示在表单143中的Taxnode数据可以存储在一个tax node表单1618的。表单144中的tax line item数据能够存储在一个tax line item表单1622。显示在表单145中的tax authority数据能够存储在一个tax authority表单1620中。在表单146中显示的分包商tax node数据能够被存储在一个分包商tax node表单1624中。在表单147中显示的分包商tax line item数据能够被存储在一个分包商tax line item表单1626中。

附图16显示了可用于启动如附图15所示的菊花链采购申请数据处理的数据库模型/方案。在附图16中，parchase requistion表单1602能够与purchase requisition paymaterials表单1604、purchase requisition paydelivery表单1606、purchaserequisition pay units表单1608、phurchase requisition pay contractor expenses表单1610、purchase requisition pay raise表单1612、purchase requisition payproject expenses表单1614、vendor master表单1616以及tax node表单1618中的任何一个交换数据。如附图16所示的互相连接那样，显示了tax authority表单1620、taxline item表单1622、分包商tax node表单1624以及分包商tax line item表单1626。附图16中所示的数据库模型/方案允许从分包商级别通过primary供应商级别到买方采购申请级别的菊花链采购申请数据处理。

图17是买方如何处理与受分包商影响的购买申请单相关的订购单的配置和创建。和发明原则一致，订购单最少可以采用下列三种方式来配置：1、忽视分包商的存在；2、不和分包商发生直接业务往来的情况下，跟踪分包商的财务流程；3、出于帐单和支付的目的，直接和分包商发生业务往来。这样，发明的原则可以用来扩展买方的数据处理选择和商务选择。

在图17中，工作流程表1700开始于步骤1702。在步骤1702中，买方访问由主供应商完成并接受的订购申请单，在步骤1704中，根据自己的工作流程，买方会在程序许可的配置范围内处理采购申请，在步骤1706，采购申请得到批准。在步骤1708，买方得到采购申请被批准的通知。在步骤1710中，买方使用标准系统接口来处理主供应商订购单，在步骤1712中买方提出选择来指定财务处理偏好。在步骤1714中，买方可以有以下三种选项：1、只和主供应商发生财务往来关系；2、把款项拨给主供应商，但是会跟踪和审查主供应商对分包商的财务活动；3、和主供应商和分包商都发生财务往来关系。

在步骤1704中，如果选择了1，执行过程将转到步骤1716，在步骤1716，为了满足不同客户的订单偏好，来设置项目支付节点。在步骤1718，买方接受订单偏好，在步骤1720，将创建客户订单和供应商订单。在步骤1722，向主供应商出具采购订单，并激活凭单部分。

在步骤1714中，如果选择了2，执行过程将会抓到步骤1724，在步骤1724，买方根据自己的工作流程，为了满足客户订单的偏好，来设置项目支付节点。在步骤1726，买方接受订单偏好，在步骤1728，客户订单包含一个菊花链TIER II处理标志，在步骤1730，为主供应商出具订购单，并激活凭单部分。

在步骤1714中，如果选择了3，执行过程会转到步骤1732，在步骤1732，买方为满足客户的订单偏好来设置项目支付节点。在步骤1734，买方认可采购单偏好，在步骤1736，创建客户采购单和主供应商采购单，另外，在步骤1736中，客户采购单中包含一个TIER 1处理标志。在步骤1738，为主供应商出具订购单，并激活凭单部分。

像在图17中列出的那样，在发明的多种实现方式中，有三种基础的处理模式分别对应于连接买方、主供应商之间以及买方、主供应商和分包商之间的采购单的建立和他们之间的关系。实际上，选项1表明，从与买方和主供应商有关的数据处理和数据跟踪方面来看，没有任何的偏好处理。在选项1中，在处理过程中基本上忽略了分包商的存在。选项2表示的TIER II模式下，从数据处理的角度看，买方偏好依然存在。在大多数情况下，这种偏好表现为存在于买方和主供应商之间的一对一的汇票支付关系。然而，在选项2中，存在一种对从主供应商到分包商的资金流动进行跟踪和审查的冲动。比如，有两个主要的原因使买方想要跟踪和审查从基本供应商转到分包商的资金。

第一个原因可能是，从供应商管理的角度看，买方想保证对分包商支付系统的整体性。举例来说，多元化的开支计划出现在政府采购中，这要求花费在政府项目上的资金支付给相对少的公司。在一些情况下，TIER II的性能显示，从政府的观点来看，支付关系并不需要在买方和分包商之间形成一对一的支付关系，而买方和分包商之间的支付可以通过第三方来完成。在本发明中，扮演这个角色的是主供应商。然而，为了保证多元信用体系的完整性，需要建立一个审查跟踪机制，这样，在选项2中，买方和基本供应商之间继续保持直接票据支付关系，但制定审查和跟踪机制，通过这样的机制，才能保证分包商能够得到被支付的资金。

在选项3中，买方和分包商会进行直接的商务往来，并产生商务和财务往来关系。举例来说，如果一个特定项目的部分资金必须通过多元支付的方式花费出去。许多政府合同要求买方和服务提供商(比如分包商)之间有直接的支付关系。这样，在选项3中，购买申请经分析后，创建一个使买方和分包商之间直接相关支付项的处理更加简便的订购单，买方可以直接支付分包商提供的服务项目。再举一例，买方可能想跟踪当地开支，而不管主供应商在项目上处于公共关系目的而发生的开支。当分包商和主供应商位于不同的地点进行项目工作时，这一点变得非常重要。

表148-152中列出的是用于与受分包商影响的采购申请有关的订单处理中的数据结构，这些数据结构展示的是表格组织的简洁性。这些表格包括了与受分包商影响的采购申请有关的订单处理中必要的各个方面。这些表格通过层级或关系方式联系在一起。这样，所有用于分包商配置的必要信息可以正确的被存储和访问，就像图18中相关的细节描述的那样。然而，，需要明白的一点是其他的配置也可以包括进来，同时，系统也不仅仅局限于图18或者表148-152中列出的那些配置。

             表148 tblPO_Vendor(db结构视图)

列名称	数据类型	长度
			POIdentityID	int	4
POIdentity	uniqueidentifier	16
			ClientPONum	varchar	12
PurchaseReqID	int	4
			POStart	datetime	8
POEnd	datetime	8
			POApprovedAmount	money	8
POProjectedAmount	money	8
			CurrencyID	int	4
POVersion	int	4
			VersionEffectiveDate	datetime	8
VendorPONum	varchar	14
			POProcessorID	int	4
ProcessFee	numeric	9
			CurrentStatusID	int	4
Response_id	int	4
			Order_ID	int	4
OrderGUID	uniqueidentifier	16
			Vendor_ID	int	4
PO_RFX_TemplateID	int	4
			PO_Project_Type_ID	int	4
PODays	int	4
			POStatusID	int	4
User_ID	int	4
			User_type	int	4
ClientPOSetUpStatus	int	4
			POApprovedTaxAmount	money	8
PMOwnerShipID	int	4
			ProjectImpactCodeID	int	4
PODynamicTypeID	int	4
			PO_Modified	datetime	8
POApprovedAmount_Modified	datetime	8

            表149 tbIPOCIient(db结构视图)

列名称	数据类型	长度
			POClientID	int	4
POIdentityID	int	4
			POClientIdentity	uniqueidentifier	16
POIdentity	uniqueidentifier	16
			CreatedDate	datetime	8
SCETierlPO	char	1
			SCETier2PO	char	1

        表150 tbIPOClientLine(db结构视图)

列名称	数据类型	长度
			POClientLineIdentityID	int	4
POClientID	int	4
			POClientLineIdentity	uniqueidentifier	16
POClientIdentity	uniqueidentifier	16
			PoIdentity	uniqueidentifier	16
LineName	varchar	100
			Description	varchar	1000
SortOrder	int	4
			CreatedDate	datetime	8
PoLineNumber	int	4
			LastModified	datetime	8

            表151 tbIPOClientSubLine(db结构视图)

列名称	数据类型	长度
			POClientSubLineIdentityID	int	4
POClientLineIdentityID	int	4
			POClientSubLineIdentity	uniqueidentifier	16
POClientLineIdentity	uniqueidentifier	16
			ActivityType	varchar	5
EarningCode	varchar	5
			ParentRefGuid	uniqueidentifier	16
ParentRefTableName	varchar	200
			ActivityGuid	uniqueidentifier	16
Poidentity	uniqueidentifier	16
			ActivityTypeName	varchar	50
SortOrder	int	4
			CreatedDate	datetime	8
LastModified	datetime	8
			PRPDeliverableID	int	4
PRPMaterialBundleID	int	4
			ProjectExpensesID	int	4
PurchaseReqPayRateID	int	4
			ContractorExpensesBundleID	int	4
PRPUnitID	int	4
			SCETier1PO	char	1
SCETier2PO	char	1

表152 tbISCEPOTier(db结构视图)

列名称	数据类型	长度
			POClientID	int	4
SCEVendorID	int	4
			TierPOType	int	4
RecordID	int	4

图18列出了一个技术层面的数据库模型/架构，该数据库模型/架构的应用和与受分包商影响的购买申请有关的订单处理。在图18中，列出了表1802-1822。采购申请表1802可以从采购申请支付合同费用表1804，采购申请支付比率表1806，采购申请支付项目费用表1808，采购申请支付单位表1814等表格中提取数据。表格1804-1814中的任何一个都是和订单客户排列项目表1822相互关联的，表1822和订单客户排列项目表1820相互关联。订单客户表1818可以从分包商订单层级表1824中提取数据，并和订单卖方表1816相互关联。订单卖方表1816和订单申请表1802相互关联。在图18中列出的数据库模型/架构支持三种配置选项，包括一对一的配置关系，一对多的配置关系以及一个可变配置关系。可变配置关系指的是申请排列项被传送到订单的方法。选项1接受为每一个合适的采购中请排列项创建一个采购记录线的设置。选项2是一个格式化设置，该设置允许买方将所有的申请排列项目都放置到主客户订单记录线上。选项3允许买方进行可变设置，人工选择单个采购申请排列项，通过创建订单排列项来可变的配置他们。这样，一个十个中请排列项按照买方的偏好，又可能被转化为一个三线订单记录，所有的物料在一个排列项上，所有的人工在一个排列项上，以及一个可交付排列项。订单必须按照用户需要的格式创建。

附图19是一个演示分包商票据/支付请求凭证如何被处理的流程图的实例。附图19与主供应商和分包商的项目工作凭证的处理相联系；核心的凭证处理过程已经在美国专利申请U.S.Patent Aplication No.10/262,487中描述。分包商的处理旅行服务或者发送产品的凭证的能力启动一个可以不受所谓的中间人干涉的凭证处理过程；所以由分包商提供给主供应商和买方的不受限制的信息的不恰当的解释将会被避免。当凭证已经与分包商相结合时，在一个更加详细和恰当的层面上执行评估就变得可能。此外，通过主供应商执行分包商凭证也增加了可视度。以本发明的宗旨为依据的凭证允许更强有力的项目跟踪、质量管理以及实行支付。在附图19中所示的凭证功能，在很多方面与美国专利申请U.S.PatentApplication No.10/262487相似，并且现在被扩展到处理的另一个层面(例如，分包商)。

在附图19中，流程1900从步骤1902开始。在步骤1902，项目工作开始。在步骤1904，分包商进入凭证组件。在步骤1906，分包商访问具体项目/采购订单详情。在步骤1908，分包商选择适用的凭证线(voucher line)项来处理。在步骤1910，该凭证被分包商处理。在步骤1912，该凭证提交给主供应商。在步骤1914，该主供应商访问凭证组件。在步骤1916，该主供应商访问提交的分包商凭证。在步骤1918，检查该主供应商是否接受了该分包商的凭证。如果在步骤1918，该主供应商没有接受该分包商的凭证，执行步骤1920。例如，该主供应商可以在步骤1918根据其了解的相关事实通知在分包商提交的凭证中存在错误。所以，在这种情况下，在步骤1920，该主供应商提供短笺(notes)给分包商拒绝该凭证，从而可以避免该主供应商将错误的凭证提交给该买方。在步骤1920，该主供应商提供短笺给分包商拒绝该凭证。从步骤1920，转回到步骤1908。

在步骤1918，如果该主供应商接受该分包商的凭证，执行步骤1922。在步骤1922，该主供应商提供可选择的短笺给该买方并且提交该凭证以过得买方的认可。在本发明的各实施例中，标准通告被激活。从步骤1922，执行步骤1924。在步骤1924，该买方可接受或拒绝该主供应商的凭证。如果，在步骤1926，该买方接受了该主供应商的凭证，执行步骤1936。如果在步骤1926，该买方没有接受该主供应商的凭证，执行步骤1928。在步骤1928，该主供应商提供短笺给分包商并且拒绝该凭证。从步骤1928，转到步骤1916。在步骤1936，该凭证的状态被更新，系统通告夜被激活。此外，在步骤1936，该凭证记录变成有效于票据的抽取。本领域技术人员将会理解，步骤1926、1928和1936可以包括根据该买方设置的工作流程的多个步骤。

表单153中显示了在与分包商票据/支付请求凭证中使用的数据结构的实例。该数据结构被简化按照表单的形式组织，用表单153包括了分包商票据/支付请求凭证过程所需的全部的域。应该理解其他的配置夜包括在内并且该系统步限定于表单153和附图20所列举的具体配置。

表153 tbISCEVoucherMaterialDetails(db结构视图)

列名称	数据类型	长度
			SCE_Mat_vRecord_ID	int	4
SCEMatRecordID	int	4
			ppmRecord_ID	int	4
Expense_Incurred_Date	datetime	8
			Material_Name	varchar	100
Material_Description	varchar	500
			Unit_Count	numeric	9
Unit_Cost	money	8
			Line_Item_Cost	money	8
SCE_User_ID	int	4
			SCE_Submit_Date	datetime	8
Status_ID	int	4
			psApproval_Date	datetime	8
psDeclination_Date	Datetime	8
			psNotes	varchar	1000

附图20演示了可用于与分包商票据/支付请求凭证相联系的数据库模型/方案。在附图20中，只有材料相关的可以票据的事件(material-related billable events)被演示；然而本领域技术人员将会认识到相似的数据库模型/方案夜可以用于可以票据的(billable)事件的每个类别中。附图20包括了所演示的表单2002-2032。

图21是分包商办理票据/支付的典型流程图。在本发明的各个实施例中，买方依靠完全的供应链和并不完全依靠对主供应商的支付来查看财务活动。在一些实施例中，买方以某种形式来处理财务往来，以说明第一层和第二层供应商支付信用。这种方法经常用于和多元化/少数实体商务有关的情况，特别是在处理政府代理项目/合同中。

在图21中，列出了流程图2100，这是一个依赖于之前买方处理的选择和存储的数据库数值的财务处理流程的精简过程。精简过程可由买方配置，这意味着时间和组织变量可以影响批处理或实时处理。

在本发明的各个实施例中，第二级分包商应付款处理代表第一级应付款处理的一个有限版本。在很多情况下，买方希望确认服务提供商能够以契约方身份获得补偿。然而，在一些情况下，人们更倾向于认为第二层是多元化商务实体支出信用。

在图21中，流程图2100开始于步骤2102。在步骤2102，激活一个已经被核准的单据帐单时间流程。在步骤2104，把所有配置的适当的时间间隔认可的平淡提取出来做处理，在步骤2106，判断提取出来的票据中是否包含有作为客户订购单标记的用于进行第一级或者第二级分包商处理的被认可的票据。

在步骤2106，如果判断结果是没有客户订单被标记用于第一级分包商或者第二级分包商处理，执行过程转到步骤2108，在步骤2108，创建一个标准的帐单文件。在步骤2110，只在买方和主供应商之间进行应收/应付帐款处操作。在步骤2112，如果有分包商而买方不希望进行分包商跟踪或分包商财务处理时，主供应商和分包商之间进行离线操作。

在步骤2106，如果判断结果是有客户订单被标记一个第一级分包商订单，执行过程转到步骤2114。在步骤2114，创建一个拆解的帐单文件。步骤2114中创建的拆解帐单文件包含一个主供应商文件和一个分包商文件。在本发明的各个实施例中，主供应商文件仅仅包括服务/产品的直接供给。此供给是为了实现那些可行记录的边际营业额。在此客户已经同意支付给主供应商一个高于分包商价格的加成。这就允许在营业额项目上主供应商被支付可行的加成，此加成由买方直接支付给买方直接支付给分包商。在本发明的各个实施例中，分包商文件只包括指定做第一级订单分包商处理的直接服务/产品提供活动。在步骤2116中，买方分别直接支付给主供应商和分包商。另外，在步骤2116中，激活第一级分包商应付帐款。在步骤2118，合计系统中所有支付款项，以正确反映项目和订单中总的支付情况。

在步骤2106中，如果判断结果是订单被标记作分包商第二级处理，执行过程转到步骤2120，在步骤2120，创建一个标准帐单文件。执行完步骤2120，执行过程会转到步骤2122和步骤2124。在步骤2122，创建一个分包商第二级跟踪和审查文件。在步骤2124，从买方和供应商搜集应收/应付款信息，在步骤2126，主供应商向合适的分包商出具已支付款项说明，在步骤2128，分包商认可支付款项的收据，并激活第二级分包商应收款项。执行完步骤2128，执行过程会转到步骤2122。

附图22表述了一个用于同分包商联系的票据/支付(bill/pay)数据相关的数据库模型/方案。在附图22中，一个invoice表单2202同一个分包商的invoice Tier 2表单2204以及一个分包商invoice Tier 1表单2206相联系。表单2202-2206的每一个都包含了不同的域来发货并且如上面所讨论所能理解的，允许第1级和第2级发货。

附图23A描述了一个供应链中一个买方的一个传统的视图。在块图2300中，子块2302、2304、2306和2308被显示。所以，按照传统的方法，这个买方只能够看到主供应商的开销2302、主供应商的执行情况2304、主供应商的地理和商品专业程度2306以及主供应商的风险管理2308。由于该买方不能看到或得到有关在子块2302-2308之上的供应链的其他方面的信息，因此该买方无法对其他方面做出评估、度量以及管理。

附图23B是一个演示了根据本发明的宗旨强化了该买方对供应链的可视度的模块图。模块2350包括模块2352-2366。在本发明的各实施例中，该买方可以获取有关主供应商以及分包商的花费2352和2354。以类似的方式，该买方能够访问该主供应商以及该分包商的执行情况2356和2358。另外，该买方能够检查主供应商和分包商供应商的地理和商品专业程度。此外，在本发明的各实施例中，该买方能够进入主供应商和分包商供应商的风险管理2364和2366。

根据以上的内容，很显然本发明的宗旨允许执行如美国专利申请号10/412,096所记载的评估和度量工具并将这些工具扩展到分包商，而通过主供应商链的集合和隔离，借助或不借助与其在一起的分包商的详细信息，主供应商的执行情况能够被更好的访问。在本发明的一些实施例中，分包商的活动和执行情况将被估算并且将对其在估算的主供应链上的活动和执行情况产生影响。

附图24演示了本发明的实施例是如何影响买方的供应链的。附图24包括了一个分包商空间2402、一个主供应商空间2404、和一个买方空间2406组成一组同心圆，该分包商空间2406在中心。本发明的各实施例允许买方不仅可以访问买方空间2406和主供应商空间2404的数据，还可以访问分包商空间2402的数据。所以该买方获取的信息能够在多个方面影响该买方的业务，包括但不限于整个供应链的管理、风险管理、价格/成本、地理服务/产品提供能力、战略联盟、递送执行情况、多变的业务支持以及花销的管理。

前面的描述是执行本发明的实施例，本发明的范围不应当必须限定在此描述中。本发明的范围实际上是被后面的权利要求所限定或与其相等。

Claims (96)

1.一种使项目投标过程便利的方法，该方法包括：

产生一个与买方相关的使用从一存储的投标项列表中选择出的至少一部分投标项的投标请求；

将该与买方相关的投标请求传给至少一个供应商引发一个供应商投标响应，该投标响应同在所述的与买方相关的投标请求中使用的所述选择出来的投标项一起产生；

产生一个与供应商相联系的使用在所述与买方相关的投标请求中使用至少一部分所述选择出来的投标项的投标请求；

将所述与供应商相联系的投标请求发送给至少一个分包商来引发一个分包商投标响应，该分包商投标响应同在所述与供应商相联系的投标请求中使用的所述选择出来的投标项一起产生。

2.如权利要求1所述的方法，其中产生所述与买方相关的的投标请求的步骤进一步包括：

从发送所述的与买方相关的投标请求的买方处接收与买方相关的投标请求数据；

存储该与买方相关的投标请求数据于与至少一部分所述的选择出来的投标项相关联的域中。

3.如权利要求2所述的方法，进一步包括：

接收所述供应商投标响应；并且

其中所述的供应商投标响应包括在与至少一部分在所述与买方相关的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

4.如权利要求3所述的方法，进一步包括：

接收所述的分包商投标响应；以及

其中所述的分包商投标响应包括在与至少一部分在所述与供应商相联系的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

5.如权利要求4所述的方法，进一步包括在所述供应商完成所有要求的所述域之后发送所述的供应商投标响应给所述的买方。

6.权利要求5所述的方法，进一步包括在所述的分包商完成所有要求的所述域之后将所述的分包商投标响应发送给所述的供应商。

7.如权利要求4所述的方法，进一步包括

接收所述的分包商投标响应被接受的消息；

接收包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据；以及

用所述的包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据更新所述的供应商投标响应。

8.如权利要求7所述的方法，进一步包括发送所述的供应商投标响应给所述的买方。

9.如权利要求8所述的方法，进一步包括接收一个买方请求来进入关于所述分包商投标响应的数据。

10.如权利要求3所述的方法，其中发送所述与买方相关的投标请求的步骤包括选择所述的至少一个供应商来接收使用所述的与买方相关的投标请求数据的所述的与买方相关的投标请求。

11.如权利要求4所述的方法，其中所述的发送所述与供应商相联系的投标请求的步骤包括选择至少一个分包商来接收使用所述的与供应商相联系的投标请求数据的所述的与供应商相联系的投标请求。

12.如权利要求10所述的方法，其中所述选择至少一个供应商的步骤进一步包括：

维持与至少一个供应商相关联的供应商信息；并且

将所述的与买方相关的投标请求数据与所述的供应商信息进行比较来选择至少一个供应商。

13.如权利要求11所述的方法，其中在所述的选择所述的至少一个分包商的步骤进一步包括：

维持与至少一个分包商相关的分包商信息；并且

将所述的与分包商相联系的投标请求数据与所述的分包商信息进行比较来选择至少一个分包商。

14.如权利要求1所述的方法，进一步包括：

接收所述的分包商投标响应；

接收所述的供应商投标响应；

接收一个供应商的决标；

发送一个采购申请给所述的供应商；

发送一拆解的采购申请给所述的分包商；以及

其中所述的拆解的采购申请是所述采购申请的一个子集。

15.如权利要求14所述的方法，其中为了获得接受和税务评估的目的，所述采购申请被提交给所述供应商。

16.如权利要求14所述的方法，其中为了获得接受和税务评估的目的，所述的拆解的采购申请被提交给所述的分包商。

17.如权利要求14所述的方法，进一步包括：

从所述的分包商接收一已经完成的拆解的采购申请；以及

产生一个已经完成的采购申请。

18.如权利要求17所述的方法，其中所述的产生所述的已经完成的采购申请的步骤包括集合至少一个已经完成的采购申请。

19.如权利要求17所述的方法，进一步包括：

产生一个与买方相关的采购订单给所述供应商；

产生一个与供应商相联系的采购订单给所述的分包商；

响应一个所述的买方直接支付所述的分包商的检查，产生一个与买方相关的采购订单给所述的分包商。

20.如权利要求1所述的方法，其中所述的产生所述的与供应商相联系的投标请求的步骤进一步包括：

为了所述的与供应商相联系的投标请求，从所述的供应商接收与供应商相联系的投标请求数据；

其中所述的与供应商相联系的投标请求数据被从与买方相关的投标请求数据中选择；以及

在与在所述与买方相关的投标请求中使用的至少一部分所述选择出来的投标项相关联的域中存储所述的与供应商相联系的投标请求数据。

21.一个计算机系统用来使针对一项目的竞价过程便利，所述项目包括买方、供应商以及至少一个分包商，所述的计算机系统包括：

一个数据库系统用以维持一个可以设置的预先建立该项目的一投标项列表以及一投标模板；

其中，所述的投标模板包括从所述的投标项列表中选择出来的投标项选集；

一个连接到数据库系统的服务器，该服务器可以与所述的买方、所述的供应商以及所述的至少一个分包商相连；以及

其中所述的服务器可进行下列操作：

用所述的投标模板产生一个与买方相关的投标请求；

发送所述的与买方相关的投标请求给所述的供应商；

通过对所述与供应商相联系的投标请求的一个分解产生一个与供应商相联系的投标请求；

发送所述的与供应商相联系的投标请求给所述的至少一个分包商；

接收一个针对所述的与供应商相联系的投标请求的分包商投标响应；

接收一个供应商投标响应，所述的供应商投标响应至少部分地乐来自所述分包商投标响应的数据合并。

22.如权利要求21所述的计算机系统，其中所述的与买方相关的投标请求的产生进一步包括：

为了所述的与买方相关的投标请求，从所述买方接收与买方相关的投标请求数据；

存储该与买方相关的投标请求数据于与至少一部分所述的选择出来的投标项相关联的域中。

23.如权利要求22所述的计算机系统，其中所述的供应商投标响应包括在与至少一部分在所述与买方相关的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

24.如权利要求23所述的计算机系统，其中所述的分包商投标响应包括在与至少一部分在所述与供应商相联系的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

25.如权利要求25所述的计算机系统，其中所述的服务器进一步可以执行操作发送所述的供应商投标响应给所述的买方。

26.如权利要求25所述的计算机系统，其中所述服务器进一步可执行操作发送所述的分包商投标响应给所述的供应商。

27.如权利要求24所述的计算机系统，其中所述的服务器进一步可执行操作：

接收所述的分包商投标响应被接受的消息；

接收包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据；以及

用所述的包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据更新所述的供应商投标响应。

28.如权利要求27所述的计算机系统，其中所述的主服务器更进一步可执行操作发送所述的供应商投标响应给所述的买方。

29.如权利要求28所述的计算机系统，其中所述的服务器更进一步的可执行操作接收一个买方请求来进入关于所述分包商投标响应的数据。

30.如权利要求23所述的计算机系统，其中发送所述与买方相关的投标请求包括选择所述的至少一个供应商来接收使用所述的与买方相关的投标请求数据的所述的与买方相关的投标请求。

31.如权利要求24所述的计算机系统，其中所述的发送所述与供应商相联系的投标请求包括选择至少一个分包商来接收使用所述的与供应商相联系的投标请求数据的所述的与供应商相联系的投标请求。

32.如权利要求30所述的计算机系统，其中所述选择至少一个供应商进一步包括：

维持与至少一个供应商相关联的供应商信息；并且

将所述的与买方相关的投标请求数据与所述的供应商信息进行比较来选择至少一个供应商。

33.如权利要求31所述的计算机系统，其中所述的选择所述的至少一个分包商进一步包括：

维持与至少一个分包商相关的分包商信息；并且

将所述的与分包商相联系的投标请求数据与所述的分包商信息进行比较来选择至少一个分包商。

34.如权利要求31所述的计算机系统，其中所述的服务器进一步可执行操作：

接收一个供应商的决标；

发送一各采购申请给所述的供应商；

发送一拆解的采购申请给所述的分包商；以及

其中所述的拆解的采购申请是所述采购申请的一个子集。

35.如权利要求34所述的计算机系统，其中为了获得接受和税务评估的目的，所述采购申请被提交给所述供应商。

36.如权利要求34所述的计算机系统，其中为了获得接受和税务评估的目的，所述的拆解的采购申请被提交给所述的分包商。

37.如权利要求34所述的计算机系统，其中服务器进一步包括以下操作：

从所述的分包商接收一已经完成的拆解的采购申请；以及

产生一个已经完成的采购申请。

38.如权利要求37所述的计算机系统，其中所述的产生所述的已经完成的采购申请的步骤包括集合至少一个已经完成的采购申请。

39.如权利要求37所述的计算机系统，其中所述服务器进一步可操作：

产生一个与买方相关的采购订单给所述供应商；

产生一个与供应商相联系的采购订单给所述的分包商；

响应一个所述的买方直接支付所述的分包商的检查，产生一个与买方相关的采购订单给所述的分包商。

40.如权利要求41所述的计算机系统，其中所述的产生所述的与供应商相联系的投标请求进一步包括：

为了所述的与供应商相联系的投标请求，从所述的供应商接收与供应商相联系的投标请求数据；

其中所述的与供应商相联系的投标请求数据被从与买方相关的投标请求数据中选择；以及

在与在所述与买方相关的投标请求中使用的至少一部分所述选择出来的投标项相关联的域中存储所述的与供应商相联系的投标请求数据。

41.一种存储在计算机可读介质种的具有计算机可执行指令，所述的计算计可执行指令包括：

产生一个与买方相关的使用从一存储的投标项列表中选择出的至少一部分投标项的投标请求的手段；

将该与买方相关的投标请求传给至少一个供应商引发一个供应商投标响应的手段，该投标响应同在所述的与买方相关的投标请求中使用的所述选择出来的投标项一起产生；

产生一个与供应商相联系的的使用在所述与买方相关的投标请求中使用的所述选择出来的投标项的投标请求的手段；

将所述与供应商相联系的投标请求发送给至少一个分包商来引发一个分包商投标响应的手段，该分包商投标响应同在所述与供应商相联系的投标请求中使用的所述选择出来的投标项一起产生。

42.如权利要求41所述的计算机可执行指令，其中产生所述与买方相关的的投标请求的手段进一步包括：

为了所述的与买方相关的投标请求，从所述买方接收与买方相关的投标请求数据的手段；以及

存储该与买方相关的投标请求数据于与至少一部分所述的选择出来的投标项相关联的域中的手段。

43.如权利要求42所述的计算机可执行指令，进一步包括：

接收所述供应商投标响应的手段；并且

其中所述的供应商投标响应包括在与至少一部分在所述与买方相关的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

44.如权利要求43所述的计算机可执行指令，进一步包括：

接收所述的分包商投标响应的手段；以及

其中所述的分包商投标响应包括在与至少一部分在所述与供应商相联系的投标请求中使用的所述选择出来的投标项相关联的域中的投标响应数据。

45.如权利要求44所述的计算机可执行指令，进一步包括执行在所述供应商完成所有要求的所述域之后发送所述的供应商投标响应给所述的买方的手段。

46.如权利要求45所述的计算机可执行指令，进一步包括执行在所述的分包商完成所有要求的所述域之后将所述的分包商投标响应发送给所述的供应商的手段。

47.如权利要求44所述的计算机可执行指令，进一步包括

接收所述的分包商投标响应被接受的消息的手段；

接收包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据的手段；以及

用所述的包括在所述的分包商投标响应中的选择出来的至少一部分所述投标响应数据更新所述的供应商投标响应的手段。

48.如权利要求47所述的计算机可执行指令，进一步包括发送所述的供应商投标响应给所述的买方的手段。

49.如权利要求48所述的计算机可执行指令，进一步包括接收一个买方请求来进入关于所述分包商投标响应的数据的手段。

50.如权利要求43所述的计算机可执行指令，其中发送所述与买方相关的投标请求的手段包括选择所述的至少一个供应商来接收使用所述的与买方相关的投标请求数据的所述的与买方相关的投标请求的手段。

51.如权利要求44所述的计算机可执行指令，其中所述的发送所述与供应商相联系的投标请求的手段包括选择至少一个分包商来接收使用所述的与供应商相联系的投标请求数据的所述的与供应商相联系的投标请求的手段。

52.如权利要求50所述的计算机可执行指令，其中所述选择至少一个供应商的手段进一步包括：

维持与至少一个供应商相关联的供应商信息的手段；并且

将所述的与买方相关的投标请求数据与所述的供应商信息进行比较来选择至少一个供应商的手段。

53.如权利要求51所述的计算机可执行指令，其中在所述的选择所述的至少一个分包商的手段进一步包括：

维持与至少一个分包商相关的分包商信息的手段；并且

将所述的与分包商相联系的投标请求数据与所述的分包商信息进行比较来选择至少一个分包商的手段。

54.如权利要求41所述的计算机可执行指令，进一步包括：

接收所述的分包商投标响应的手段；

接收所述的供应商投标响应的手段；

接收一个供应商的决标的手段；

发送一个采购申请给所述的供应商的手段；

发送一拆解的采购申请给所述的分包商的手段；以及

其中所述的拆解的采购申请是所述采购申请的一个子集。

55.如权利要求54所述的计算机可执行指令，其中为了获得接受和税务评估的目的，所述采购申请被提交给所述供应商。

56.如权利要求54所述的计算机可执行指令，其中为了获得接受和税务评估的目的，所述的拆解的采购申请被提交给所述的分包商。

57.如权利要求54所述的计算机可执行指令，进一步包括：

从所述的分包商接收一已经完成的拆解的采购申请的手段；以及

产生一个已经完成的采购申请的手段。

58.如权利要求57所述的计算机可执行指令，其中所述的产生所述的已经完成的采购申请的手段包括集合至少一个已经完成的采购申请的手段。

59.如权利要求57所述的计算机可执行指令，进一步包括：

产生一个与买方相关的采购订单给所述供应商的手段；

产生一个与供应商相联系的采购订单给所述的分包商的手段；

响应一个所述的买方直接支付所述的分包商的检查，产生一个与买方相关的采购订单给所述的分包商的手段。

60.如权利要求51所述的计算机可执行指令，其中所述的产生所述的与供应商相联系的投标请求的手段进一步包括：

为了所述的与供应商相联系的投标请求，从所述的供应商接收与供应商相联系的投标请求数据的手段；

其中所述的与供应商相联系的投标请求数据被从与买方相关的投标请求数据中选择；以及在与在所述与买方相关的投标请求中使用的至少一部分所述选择出来的投标项相关联的域中存储所述的与供应商相联系的投标请求数据的手段。

61.一种管理一个项目竞价过程的方法，该方法包括：

接收一个关于一个分包商的启用请求；

接收一个关于一个主供应商的加入请求，该加入请求请求所述的分包商与所述的主供应商建立关系；

发送一个与买方相关的投标请求给所述供应商；

发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商；

从所述分包商接收一个已经完成的菊花链报价，该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项；

用所述已经完成的适用的菊花链报价项中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求；以及

发送所述更新的供应商投标响应给所述的买方。

62.如权利要求61所述的方法，进一步包括：

发送一个买方的决标给所述的供应商；

发送一个采购申请给所述的供应商；

拆解所述的采购申请；以及

发送所述的拆解的采购申请给所述的分包商。

63.如权利要求62所述的方法，进一步包括：

从所述分包商接收一个已经完成的采购申请；

集合从所述分包商接收的所述已经完成的采购申请；

发送一个采购订单给至少一个所述供应商和所述分包商。

64.如权利要求63所述的方法，其中发送所述采购订单的步骤包括：

检查是否由所述的买方直接支付给所述的分包商；

如果检查到是由所述的买方直接支付所述的分包商，那么：

发送一个采购订单给所述的供应商；

拆解所述发送的采购订单成关于所述分包商的采购订单片段的详细情况；以及

发送一个拆解的采购订单给所述的分包商。

65.如权利要求63所述的方法，其中发送所述采购订单的步骤包括：

检查是否由所述的买方直接支付给所述的分包商；

如果检查出并不是由所述的买方直接支付所述的分包商，发送一个采购订单给所述的供应商。

66.如权利要求63所述的方法，进一步包括发送一个分包商凭证给所述的供应商。

67.如权利要求63所述的方法，进一步包括发送一个供应商凭证给所述的买方。

68.权利要求66所述的方法，进一步包括，发送一个供应商凭证给所述的买方。

69.如权利要求67所述的方法，进一步包括接收一个买方凭证认可。

70.如权利要求68所述的方法，进一步包括接收一个买方凭证认可。

71.如权利要求69所述的方法，进一步包括发送一个发票给所述的买方。

72.如权利要求70所述的方法，进一步包括发送一个发票给所述的买方。

73.一种存储在计算机可读介质种的具有计算机可执行指令，所述的计算机可执行指令包括：

接收一个关于一个分包商的启用请求的手段；

接收一个关于一个主供应商的加入请求的手段，该加入请求请求所述的分包商与所述的主供应商建立关系；

发送一个与买方相关的投标请求给所述供应商的手段；

发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商的手段；

从所述分包商接收一个已经完成的菊花链报价，该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项的手段；

用所述已经完成的适用的菊花链报价项中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求的手段；以及

发送所述更新的供应商投标响应给所述的买方的手段。

74.如权利要求73所述的计算机可执行指令，进一步包括：

发送一个买方的决标给所述的供应商的手段；

发送一个采购申请给所述的供应商的手段；

拆解所述的采购申请的手段；以及

发送所述的拆解的采购申请给所述的分包商的手段。

75.如权利要求74所述的计算机可执行指令，进一步包括：

从所述分包商接收一个已经完成的采购申请的手段；

集合从所述分包商接收的所述已经完成的采购申请的手段；

发送一个采购订单给至少一个所述供应商和所述分包商的手段。

76.如权利要求75所述的计算机可执行指令，其中发送所述采购订单的步骤包括：

检查是否由所述的买方直接支付给所述的分包商的手段；

响应检查到是由所述的买方直接支付所述的分包商的手段，用来：

发送一个采购订单给所述的供应商；

拆解所述发送的采购订单成关于所述分包商相关的采购订单片段的详细情况；以及

发送一个拆解的采购订单给所述的分包商。

77.如权利要求75所述的计算机可执行指令，其中发送所述采购订单的步骤包括：

检查是否由所述的买方直接支付给所述的分包商的手段；

如果检查出并不是由所述的买方直接支付所述的分包商，发送一个采购订单给所述的供应商的手段。

78.如权利要求75所述的计算机可执行指令，进一步包括发送一个分包商凭证给所述的供应商的手段。

79.如权利要求75所述的计算机可执行指令，进一步包括发送一个供应商凭证给所述的买方的手段。

80.如权利要求78所述的计算机可执行指令，进一步包括，发送一个供应商凭证给所述的买方的手段。

81.如权利要求79所述的计算机可执行指令，进一步包括接收一个买方凭证认可的手段。

82.如权利要求80所述的计算机可执行指令，进一步包括接收一个买方凭证认可的手段。

83.如权利要求81所述的计算机可执行指令，进一步包括发送一个发票给所述的买方的手段。

84.如权利要求82所述的计算机可执行指令，进一步包括发送一个发票给所述的买方的手段。

85.一种用于管理一个项目竞价过程的计算机系统，该计算机系统包括：

一个数据库系统；

一个与该数据库系统连接的服务器，其中该服务器可执行下列操作：

接收一个关于一个分包商的启用请求；

接收一个关于一个主供应商的加入请求，该加入请求请求所述的分包商与所述的主供应商建立关系；

发送一个与买方相关的投标请求给所述供应商；

发送一个与该与买方相关的投标请求相关的一个菊花链报价给所述的分包商；

从所述分包商接收一个已经完成的菊花链报价，该已经完成的菊花链报价包括发送给该分包商的所述菊花链报价的已经完成的适用的菊花链报价项；

用所述已经完成的适用的菊花链报价项目中的至少一些更新一个供应商投标响应给所述的与买方相关的投标请求；以及

发送所述更新的供应商投标响应给所述的买方。

86.如权利要求85所述的计算机系统，其中该服务器进一步可执行下列操作：

发送一个买方的决标给所述的供应商；

发送一个采购申请给所述的供应商；

拆解所述的采购中请；以及

发送所述的拆解的采购申请给所述的分包商。

87.如权利要求86所述的计算机系统，其中该服务器可进一步执行下列操作：

从所述分包商接收一个已经完成的采购申请；

集合从所述分包商接收的所述已经完成的采购申请；

发送一个采购订单给至少一个所述供应商和所述分包商。

88.如权利要求87所述的计算机系统，其中发送所述采购订单包括：

检查是否由所述的买方直接支付给所述的分包商；

如果检查到是由所述的买方直接支付所述的分包商，那么：

发送一个采购订单给所述的供应商；

拆解所述发送的采购订单成关于所述分包商的采购订单片段的详细情况；以及

发送一个拆解的采购订单给所述的分包商。

89.如权利要求87所述的计算机系统，其中发送所述采购订单包括：

检查是否由所述的买方直接支付给所述的分包商；

如果检查出并不是由所述的买方直接支付所述的分包商，发送一个采购订单给所述的供应商。

90.如权利要求87所述的计算机系统，其中该服务器进一步可执行下列操作：发送一个分包商凭证给所述的供应商。

91.如权利要求87所述的计算机系统，其中该服务器可进一步执行下列操作：发送一个供应商凭证给所述的买方。

92.如权利要求90所述的计算机系统，其中该服务器可进一步执行下列操作：发送一个供应商凭证给所述的买方。

93.如权利要求87所述的计算机系统，其中该服务器可进一步执行下列操作：接收一个买方凭证认可。

94.如权利要求92所述的计算机系统，其中该服务器可进一步执行下列操作：接收一个买方凭证认可。

95.如权利要求93所述的计算机系统，其中该服务器可进一步执行下列操作：发送一个发票给所述的买方。

96.如权利要求94所述的计算机系统，其中该服务器可进一步执行下列操作：发送一个发票给所述的买方。

Images