CN1471680A - 利用数据网络完成用户产品的订货、履行与交付的集成系统 - Google Patents

Abstract

一种通过数据网络实现电子商务的技术，该数据网络包括多个子系统，这些子系统形成的集成系统可通过数据网络接收所选物品的客户订单，履行该客户订单并将订购的产品交付给客户。而且按照一个特定的实施例，本发明系统结构的集成本质允许在线商人向客户保证在规定的送货日期、时间及地点将所订购的物品送给客户。

Description

利用数据网络完成用户产品的订货、履行与交付的集成系统

发明背景

发明领域

本发明涉及电子商务领域，尤其是本发明涉及利用数据网络将用户产品销售和送货给用户的技术。

相关技术的描述

这么多年来公司一直在利用多种不同的送货系统将货物送货给用户家庭。这样的示例包括从邮件订货目录购买到在线订货和送货服务，例如由Amazon.com和peapod.com所提供的这些服务。实际上，家庭购买与家庭送货的需求一直在增长着，很多提供家庭购买与家庭送货服务的系统具有重大的缺陷，不能大规模地采有用。

例如，由peadod.com提供的在线货物送货服务(由peapod公司实施)允许用户访问一个在线货物商店以放置货物订单。“商家”(即peadod的雇员)通过进到本地货物商店并购买由用户订购的货物来履行该订单，货物随后送货到该用户的家庭。为了在这种交易中获取收益，peadod在货物账单中增加了收费，这就使得这样的货物比起用户亲自到商店购买这种货物要贵。

而且，当用户放置订单时，peadod并不能保证所订购的物品是可送货给该用户的。因此，如果该货物商店不具有该订购的物品(例如没货了)，那么该商家就不能将该物品送货给用户。

而且送货规划问题也随着在线购买服务(如由peadod提供的)而产生，通常很难以与订单被放置相同方式对要送货的订单履行一个送货请求，因此很多的商品购买服务并不提供这种特征。另外，错过一个规划好的用户送货最佳时间也是不寻常的，因为该订单占用大多的时间而不能由该“商家”履行。

除了peadod技术，还有其它的传统在线技术使用户可以通过因特网购买用户商品，并随后可使购买的产品送货到用户的送货地址。例如，在线零售商如Amazon.com公司提供了用户通过因特网或万维网可选择并购买各种产品的能力。利用传统的技术，在线的产品购买交易一般地包括下列步骤：

首先，用户选择一个或多个要购买的产品，一旦用户完成了选择要购买的产品，该用户随后就可以进到结帐或订单确认页。在结帐或订单确认过程中，该用户提供必要的用于完成该购买交易的信息，例如用户的名称、信贷(credit)卡号、送货地址等。在订单被在线零售商(例如Amazon.com)确认之前验证和处理记帐和金融信息。例如用户使用一个信用卡来在线购买产品，那么在购买订单被该商家确认和履行之前验证对于该交易总额的信用卡交易。一旦该购买交易被授权，那么在线商家一般地通过获得所购买的产品来履行该订单，并有利用通用的运载工具(如第三方的快递)将所购买的产品送货到用户的送货地址，如UPS、USOS、联邦快递等。该用户的信用卡一般地在发货的同时进行记帐。

尽管上面提到的在线产品购买技术可方便地使用户购买和接收希望的产品而不必冒险地到其家外购买，但是当前的在线购买技术却具有很多的附加的缺点(也就是前面所描述的)。例如，很多的在线商人提供有关在线产品购买的足够的用户服务，但是却一般地不能提供足够的用于处理退货或用户抱怨的用户服务。而且一旦用户的订单被处理了，用户一般地不能改变或变更或取消该订单，而且在用户接收到原始订货的货物之前用户只能等，以及必须随后递交一个请求给在线商家用于退货或修改该订单的至少一部分，在商家一方，后一个请求一般地作为一个独立交易进行处理并且要有较长的延迟。而且，如果用户希望退货一个或多个产品，商家一般地要求该用户首先获得一个退货授权号(在第一次递交一个退货请求后)，并且用户一般地要对将所退货的产品送货给商家付费。

下面几个示例也有助于说明在用户通过在线零售商或商家购买产品时可能遇到的问题，首先假定用户利用在线商家如Amazon.com已选择好了两个书要购买，当用户进到结帐页时，该用户授权要对其信用卡记帐的总额(即书/税和送货)。一旦接收到对总额的信用卡授权后，该商家就履行该订单并将其转发给一般的运送者进行送货，此时对上面说明的总额对用户的信贷总额进行记帐。

在商家履行完该订单后，用户一般地不能修改或取消该订单，因此，例如如果用户在该商家已履行完该订单后要取消其中一本所订购的书时，该用户首先必须一直等到接收到该书，然后提交一个单独的在线请求用于退货该书，由于所购买的物品(item)一般地利用一个独立的运送者服务或通用的运行者如UPS、联邦快递或美国邮政服务等，因此这种订货和退货变得毫无价值，也不存在着一种机构，在此用户能以立即退还方式将不希望的产品(如书)等退货给送货的运送者。而且，作为一种典型的情况，用户必须首先多该商家获得一个退货授权号，重新对不想要的产品进行包装，并将不想要的产品发送回给该商家。一般地，要求用户支付退货产品的送货费，即使是该产品是有缺陷的也是如此。

商家一旦接收退货的产品，一般地要在4-6周内处理，这就意味着对所退货的产品的信贷一般地要在商家接收该产品4周后才能发放给用户。在上面所示的例子中，当发行后在用户的信用卡帐户上信贷是以退还款或信贷方式出现的。

对于传统在线购买交易的另一个问题涉及商品的可用性。例如当一个商家接收到产品退货的请求后，该商家一般地不能将所退货的产品作为该商家当前库存的一部分，直到所退货的产品在商家方是实际上接收到并经过处理后才行，一般地要占用4-6周。而且，在处理所退货的订单之前，所退货的商品一般地不作为用户可购买的库存的一部分，这将导致资源分配的不够有效。

总而言之，一直存在着改进电子商务和在线购买技术的需求。

发明内容

按照本发明的特定实施例，描述了利用数据网络实现电子商务的技术，该数据网络包括多个子系统，这些子系统一起形成一个用于通过一个数据网络接收所选择的物品的用户订单、履行该用户订单并将该订货的产品送货给用户的集成系统。而且，按照一个特定的实施例，本发明的系统体系的集成本质允许在线商家向用户保证所订购的物品可在规定的最佳时间发送时间内送货给用户。

按照一个特定的实施例，公开一种集成系统，用于通过数据网络实现电子商务。该系统包括一个含有存储器的库存子系统。该库存子系统包括一个配置或设计成维护多项商品的库存记录的库存目录，该系统还包括一个与该库存子系统通信的用户接口子系统。该用户接口子系统被配置或设计成存储可用的库存信息，以及配置或设计成通过该数据网络提供有关该库存商品的可选物品信息给至少一个用户。该用户接口子系统还配置或设计成便于用户的商品交易以及存储用户的订单信息。该集成的子系统还包括一个与该库存子系统进行通信的订单履行子系统。该订单履行子系统配置或设计成接收由用户接口子系统捕获的用户订单信息。该订单信息包括针对至少一物品的至少一个用户订单。该订单履行子系统还配置或设计成便于履行用户订单。在特定的实施例中，履行用户订单包括获取有关该订单的至少一部分物品并且准备所获取的物品以发送给用户。另外，该集成系统包括与该用户接口子系统和库存子系统进行通信的送货子系统。该送货子系统配置或设计成接收有关至少一个已履行的用户订单的物品，并且也配置或设计成便于将所接收的物品送货给该用户。

上述实施例的另一个方面在于，该系统还包括一个与库存子系统和用户接口子系统进行通信的发布子系统，用于管理与多个商品项相关的物品和目录数据。本实施例的另一方面在于，该用户接口子系统包括一个用于管理与多个子系统中每一个相关的数据容量的容量数据库。按照一个实施例，该容量数据包括对于每个子系统的可用容量数据以及为每个子系统所保留的容量数据，其中所保留的容量数据与所放置的、还没有交付给用户的用户订单相关。该用户接口子系统还配置或设计成利用容量数据，在订货的同时管理用户订单流入。

本发明的另一个实施例致力于用于通过数据网络实现电子商务的方法。该数据网络包括用于方便由至少一个用户所选的物品的订单交易的用户接口子系统；订单管理子系统，用于管理用户订单，以及用于管理库存采购和库存数据；订单履行子系统，用于便于用户订单的履行；以及一个送货子系统，便于用户订单到用户的送货。在用户接口子系统中接收用户的订单，该用户订单包括关于至少一个订购物品的信息，以及包括有关规定的送货最佳时间时间的信息。在通过了预定的截止时间后有关该用户订单的信息被发送给订单履行子系统。用户订单的至少一部分是在订单履行子系统处履行了。订单的履行包括验证已被成功地履行并处理以发货给用户的每一个库存物品，随后该送货子系统用于交付所履行的订单物品给用户。在交付所履行的订单物品给用户的同时，产生由用户接收的每一物品的记录。在订单已被交付给用户后，随后对用户针对该订单进行记帐。本实施例的另一个方面在于，用户能在交付订单给用户的同时修改用户订单。在特定的实施例中，该用户订单的修改(在交付订单给用户过程中开始)可以由交付运送者利用一个移动场装置来处理，其中该装置被配置或设计成处理和存储用户订单数据，而且，利用该移动场装置，该交付运送者可以在交付的同时处理其它的用户服务请求，例如用户返货、信贷或其它调整请求。

本发明的另一个实施例致力于一种用于通过数据网络实现电子商务的集成体系系统，该系统包括一个用户接口子系统，用于通过数据网络向用户展示所选产品的描述。该用户接口系统还配置成可使用户通过该数据网络为所有选择的产品产生订单。该系统进一步包括与该用户子系统进行通信的一个库存子系统，该库存子系统被配置成维护并控制与展示给用户的产品相关的库存数据，该系统进一步包括一个与库存子系统进行通信的订单履行子系统，该履行子系统配置成通过数据网络处理用户订单。该系统还包括一个与用户接口子系统和订单履行子系统进行通信的运输子系统，该运输子系统配置成规划交付并管理与用户订单的履行和交付相关的运输资源。集成系统体系的每一个子系统可通过该数据网络利用这些子系统之间彼此的交互而实现各种功能。

本发明的另一个方面是致力于用于通过数据网络实现电子商务的集成系统。该系统包括用于服务于与第一地理区域相关第一多个用户的第一商业单元；用于服务于与第二地理区域相关第二多个用户的第二商业单元；以及用于管理由每一个商业提供给各自用户的信息内容的中央管理单元。而且，每一个商业单元包括一个库存子系统，一个用户接口子系统，一个订单履行子系统以及一个交付子系统。按照一个特定的实施例，该集成的系统可配置成基于与某一用户相关的地理位置将某一用户连接到一个相应的商业单元。

本发明的各方面的其它特征和优点将通过下列优选实施例的描述结合附图变得更清楚。

附图的简要描述

图1是按照本发明的一个特定的实施例一个集成系统体系100的示意方框图；

图2是按照本发明的一个特定的实施例一个集成系统体系200的示意方框图；

图2A表示描述在图2的系统200内所示的至少一部分单元之间发生的各种交互的示意方框图；

图3是按照本发明的一个不同的实施例的一个集成系统体系300的示意方框图；

图4表示按照本发明特定实施例的状态图，说明了通过与库存流入有关的子系统交互的高水平(level)。

图5表示按照本发明特定实施例的状态图，说明了与库存流出有关的子系统交互的高级预排；

图6、7A和7B表示按照本发明一个特定实施例用于描述通过数据网络实现电子商务的本发明的各种系统、子系统和部件在正常的商业操作中是如何交互的流程图；

图8表示按照本发明一个实施例描述了流过订单管理子系统(OMS)的各种类型数据的示意方框图；

图9描述了按照本发明一个特定实施例的各种SKU和目录流；

图10表示按照本发明一个特定实施例的数据库报告和分析环境的示意方框图；

图11表示按照本发明一个实施例说明了目录/物品清单以及存储物品之间的关系的方框图

图12表示按照本发明一个特定实施例说明了在绘制的地区区域的送货地址、区内区域以及可交付区域之间关系的方框图；

图13表示按照本发明一个实施例的分发中央操作的方框图；

图14表示按照本发明一个实施例的OFS销往外地进程1400的流程图；

图15表示按照本发明一个实施例的OFS销往内地进程1500的特定实施例。

优选实施例

按照本发明的特定实施例，描述用于通过数据网络实现电子商务的技术，尤其是本发明的技术利用集成系统体系通过该数据网络实现电子商务，该数据网络可以由多个分离的网络如广域网(WAN)、局域网(LAN)或因特网等组成。

本发明的集成系统体系可以用于实现各种电子商务技术。例如，按照一个特定的实施例，该集成的系统体系可用于实现一个在线商店，该商店可以由用户通过因特网或万维网访问。利用本发明的技术，在线商店可以配置成便于用户交易，包括，例如向用户提供有关可购买的物品的目录信息；使用户可以规划订单的交付目的地、日期以及交付时间；接收和管理用户订单；便于履行用户订单；便于交付用户订单等。这种在线商店包括多个系统、子系统和/或与用户通过数据网络进行接口的部件。

在线商店所接收的用户订单可以转发给一个实际的分销中央，在此处理和履行订单以发货给用户。一旦已经处理完一个订单以发货给用户，就可以使用一个交付系统在规定的日期和时间将该订单交付给用户。按照本发明的特定的实施例，该集成的系统体系还包括用于管理与电子商务交易相关的履行和交付内容的系统单元。

图1是按照本发明的一个特定的实施例一个集成系统体系100的示意方框图，表示各种系统、子系统和/或系统部件。如图1所示，系统100包括多个子系统和其它的用于通过数据网络实现电子商务的部件。下面给出该系统100的多个子系统的至少一部分。例如图1的系统100包括：

(1)发布子系统(PUB)140，管理SKU和目录信息(例如SKU，UPS，产品，目录，描述性属性等)以及提供到商家133的接口；

(2)网络商店子系统(WS)132，管理与用户的在线商店接口，包括用户的购买与订单交易；

(3)运输子系统(XPS)124，管理交付最佳时间规划，交付车辆的路线，容量计划以及由交付运送者所使用的移动场装置(MFD)数据；

(4)订单管理子系统(OMS)150，管理定价数据、物品可用性数据、库存数据、销售商数据、金融、获取(procurement)等；

(5)公司支持子系统(CSS)146，管理金融和人力资源信息以及与其它的子系统进行通信以授权用户和分配任务；

(6)订单履行子系统(OFS)160，便于用户订单的履行和管理分销中央(170)的运行；

(7)用户关系管理(CRM)子系统126，使用用户服务代表(CSR)143对用户的请求服务并跟踪用户交易；

(8)食品生产管理子系统(MFG)154，管理信息和购买有关接收处方、子处方、成份、菜单、食品安全过程、设备使用等的要求；

(9)数据仓库子系统(DWS)180，用于存储和分析由集成系统的其它子系统报告的数据；以及

(10)电子数据交易(EDI)子系统182，提供到销售商185的接口，并且管理销售商购买订单和发票数据；

本发明的集成系统的其它实施例可包括：

(11)自动呼叫分布(ACD)子系统，当在用户服务中央接收到用户呼叫时管理并路由用户呼叫；

(12)网络系统管理(NSM)子系统，监视和诊断系统100内的所有网络和子系统；

(13)系统和网络基础结构(SNI)子系统，包括硬件和/或用于优化网络性能、规模及可靠性的软件；

(14)公司网络和系统(CNS)子系统，代表公司系统正在运行的网络功能；以及

(15)内容管理子系统(CMS)，用于管理利用本发明的集成系统的多个在线商店的目录内容。

从图1中可以看出，系统100可包括至少一部分上面描述的子系统，另外，每个子系统可配置成使用一个专用或共享的数据服务器作为其它持久的和交易数据中枢。用户可以访问存储在一个子系统的数据库服务器(如网络商店数据库)上的数据，执行相应的商业逻辑和/或商业目标。

每个子系统可以配置或设计成通过多个接口彼此进行通信。按照一个特定的实施例，该多个接口包括同步和异步的接口。多各不同系统的接口配置成异步的，其中数据是以备份模式通过级连(staging)表(例如数据库)或平文件(flat file)(例如分离值文件)交付的。但是至少一部分系统接口是配置成同步接口的。一般地，一个同步接口可用于要求从服务器或部件有立即响应的场合。图1的系统100内的同步接口可存在于WS 130与XPS 124、XPS 124与路由计划器118、WS 130与税收服务器114、以及MFD服务器112与税收服务器114之间。

理论上，图1的系统100可以分成两个通用的子系统，即前端办公系统和后端办公系统。前端办公系统一般地用于相对于用户交易而发生作用，例如用户订单、记帐交易、交付规划、用户服务等。在图1的实施例中，例如前端办公系统130包括网络商店子系统132，运输子系统124以及用户关系管理子系统126。前端办公系统130还可包括其它的子系统或部件，如移动场装置(MFD)部件112、税部件114、信贷或记入借方卡收费部件116、交付路线部件118、搜索引擎120、目录部件122、帮助桌面部件114等。上面描述的前端办公系统130的子系统和部件将在下面进行详细地说明。

而且，前端办公系统130可包括一个中央化的数据库131，该数据库可以由系统100的子系统和/或部件访问。可替换地，一个或多个前端办公系统和/或部件每一个都可包括各自的数据库，这些数据库可由系统100的其它子系统和/或部件访问。

后端办公系统一般地包括所有的不属于前端办公系统的子系统和/或部件。因此，在图1中，后端办公系统包括PUB 140，MFG 154，OMS 150，EDI 182，CSS 146，DWS 180以及OFS子系统。但是，本发明并不限于图1的特定实施例，可以理解系统100的特定的实施例可以由本技术领域内的人按照特定的实施例进行修改。

子系统功能

本部分将对形成本发明的集成系统体系例如图1的各种子系统和部件进行更详细的描述。

发布子系统(PUB)

参照图1，发布子系统140维护和管理用户可购买的关于零售对象(例如SKU，产品，目录等)的信息数据。

库存中每一个不同物品都与一个各自的库存保持单元或SKU相关联，而不管该物品对于用户来说是否是可以购买的。一种产品是SKU的一个群组，该产品信息是对于群组中所有的SKU来说最相关的较高级的信息。目录是根据用户希望这些产品如何进行逻辑分组来进行层级分类的。例如，目录“土豆条”可能包括产品“商标X”土豆条和“商标Y”土豆条。而且，商标X土豆条产品可以包括16盎司的商标X土豆条物品(与第一个SKU相关)以及一个20盎司的商标X土豆条物品(与第二个SKU相关)。

PUB子系统140可维护和管理所有SKU信息的主目录，包括产品和仅提供SKU。而且，该PUB子系统还可对为不同的在线商店产生和管理不同的目录，每个商店目录可包括从主目录中选择的SKU子集。

如图1所示，该发布子系统包括数据库141。按照一个特定的实施例，该PUB数据库可以利用一个运行在数据库服务器上的Oracle数据库来实现，该数据库用作为所有公开数据的仓库以及实现预定的商业规则的代码仓库。

存储在PUB数据库141内的数据可能被分组成多个不同的计划(schema)，例如数据入口计划，在此存储所有的初始变化；集成计划，其中集成了至少来自一个用户的变化；掌管者计划，存储了所有零售目标的主要拷贝；目录计划，被配置为由其它系统接口使用的销往外地的分段运输区域；公开使用计划，包括所存储的可由预定的商业规则实现的进程和条款；以及公开API计划，允许内部和外部客户连接到该PUB数据库等。

商人和内容管理者可以利用PUB WEB GUI接口134和PUBBULK LOADER(大装载器)接口136进入和维护存储在PUB数据库内的SKU信息。该SKU信息可以包括SKU属性值如UPC，销售商、目录、目录层级、图像、条款、描述性信息等。该PUB WEB GUI接口134允许商人编辑SKU信息、产品和/或目录。该PUB BULKLOADER136支持将来自PUB子系统外的数据文件处理进该PUB数据库141。按照一个特定的实施例，该PUN BULKLOADER配置成允许商人将各种数据库文件类型上载进该PUB数据库，包括平(flat)数据文件和图像文件。该BULK LOADER处理该平文件信息以便为该PUB目录生成相应的数据库记录。

图9描述在本发明的特定实施例的各种子系统之间的目录数据流和SKU。如前面描述的，商人和内容管理者可以利用PUB WEBGUI接口134或PUB BULK LOADER接口136进入和维护在PUB子系统内的SKU信息，经过处理的SKU信息随后被转发给PUB子系统并存储在PUB数据库141内。按照一个特定的实施例，一个PUB子系统利用一个目录输出文件的形式输出与销售有关的SKU信息。该目录输出信息可以首先由一个PREP系统135来校验，该PREP系统可以配置成是网络商店132的一个独立但相同的实例，它包括一个相关的数据库。除了校验该目录输出文件外，该PREP系统135还可以用作为一个最终的集成检查站，用于检查由市场产生的所有的非SKU内容。一旦该目录输出文件被PREP系统校验通过后，该网络商店子系统132就可以自由地将该目录输出文件输入进它的数据库131。这些可以在周期性的基础上完成，例如可以在日常的规划的停工期间每天地进行。

包含在目录输出文件中的SKU是网络商店可以显示并提供给用户进行销售的那些。按照另外一个实施例，该PUB子系统可以产生多个目录输出文件，包括，例如含有所有书籍的SKU信息的主目录输出文件，以及分离的商店目录输出文件(例如杂货商店、便利品商店、专卖店等)，其中每一部分仅包含在主目录中所包括的SKU信息的一部分。

按照特定的实施例，PUB子系统确保所有输出数据是一致并且符合某些条款，如确保没有空页目录被输出。在该实施例中，网络子系统并不需要对输出的数据进行运行时检查，因此可以自由地加速SKU、产品以及目录显示给用户。

周期性地(例如分钟、小时、天数)，OMS轮询该PUB数据库查找新和更新的SKU信息，并将所检索的数据存储进OMS数据库151。按照特定的实施例，OMS为每一个SKU维护可用立约(ATP)、价格以及库存(例如补充与购买)信息。OMS也可捕获和/或管理与每一个SKU相关的销售和发货数据。周期性地，OMS传递新和更新它从该PUB子系统获得的SKU信息给OFS。该SKU住处可以由OFS使用，例如维护物理库存和履行数据。

前端办公体系层

如图1所示，前端办公130包括多个独立的子系统，例如网络商店子系统(WS)132，运输子系统(XPS)124以及用户关系管理子系统(CRM)126，每个子系统可以通过硬件和/或软件组合的方式来实现，以及进一步可包括多个不同的功能部件、模块和/或插件应用程序。

驻留在前端办公系统的软件的至少一部分可包括一个表示层，一个应用层，一个商业目标层，一个数据库访问层或它们的组合。按照一个特定的实施例，表示层通过相应的介质处理给用户的实际表示信息，而应用层(可能是stateless)可以为前端办公的各种系统处理相应的应用逻辑。例如在网络子系统132内，是应用层(在此记为购买引擎)确定用户不能查看或订货，直到用户选择了一个交付最佳时间或者提供了记帐信息。商业层(可以是有货币的(stateful))提供给目标一套固定的功能(例如方法或进程)，这些功能可以由应用层使用，该商业目标层还可以通过数据的缓存而实现写操作。按照一个特定的实施例，这些商业目标彼此之间并不了解，并且应用层处理各种商业目标之间的协调，数据库访问层向前端数据库131(在此也称作网络商店数据库)提供连接和数据访问API。按照特定的实施例，在合适的时候，该数据库访问层执行连接对象的轮询和缓存。

使通用数据库计划被前端办公系统中每一个所采纳也是非常重要的。按照一个特定的实施例，数据库131是作为一个共享数据库来实现的，它可由前端办公系统中的每一个来访问。

网络商店子系统(WS)

网络商店子系统(WS)132提供一个使用户访问在线商店(如网络商店)的接口，在网络商店是作为万维网上的一个网站实现的特定的实施例中，用户可以利用多个传统的浏览器技术通过因特网或万维网访问该网络商店。网络商店用户接口可以设计成提供的丰富功能集，而不会要求特定的浏览器插件。因此用户可以利用任意的客户机访问该网络商店，而不必理会机器的操作系统平台，为了安全的目的网络商店接口还支持用户与网站之间的敏感的或私有信息的交换，该安全的网络接口是利用安全的HTTP协议实现的，这在本技术领域是一致的

按照一个特定的实施例，网络商店子系统132支持多个与用户相关的特点，例如：自注册；访问客户帐户信息；浏览产品目录和目录结构；查看产品图象和产品信息；关键词搜索；交付规划；访问客户定单历史；定制购物清单；再线购买和订货等。

网络商店子系统可以利用连接到数据网络的至少一个服务器来实现的，按照一个特定的实施力，该网络商店是利用多个网站服务器实现的(例如：网站服务器农场)这些服务器有助于最小化，服务器享用时间，并提供实时的纠错(failover)和冗余性能。而且按照一个特定的实施例，为了使响应时间最小，该网络商店还可以配置成在一个处理进程内在一个单一的服务器执行所有的处理。在使用多个网络商店服务器的场合，可以由这些服务器的至少一部分执行冗余的处理，以便一个单一的网络商店服务器可以处理与一个特定的在线用户相关的所有的网络商店处理任务。应明白，该网络商店服务器界限在适当的时候时对销的，例如当通过数据网络访问前端办公数据库时。

按照一个特定的实施例，WS软件的表示层可以在微软动态服务器页内实现，该表示层可以产生发送回给用户浏览器的HTML数据。该应用软件层或购物引擎可以作为微软部件对象模型(COM)对象来实现。软件的商业对象层可提供下列商业对象：(1)用户对象，可实现用户功能和属性；(2)目录对象，可实现产品目录层级结构、SKU、价格以及可用立约(ATP)信息；(3)定单对象，可以实现购物车、定单管理、记帐以及检查程序；(4)会话对象，可以实现HTTP上的状态；以及(5)交付对象，可以实现用户交付规划。而且，该WS最好配置或设计成最小化用户响应时间以及提供稳定性。在其它实施例中，该表示层可以利用Java和/或Perl来实现，而应用软件层可以利用NSAPI或Apache模块实现。

附加地，如图1所示，前端办公系统可包括多个提供附加功能的集成的部件。例如，WS可包括多个提供附加功能如税务计算搜索能力、信用卡记帐等的部件。因此如图1所示，例如WS 132包括至少一个目录部件122；税收计算部件114，用于为卖出的每个定单行物品计算税收；搜索部件120，用于处理文本检索要求；以及信用卡(或记帐卡)服务器(CC)部件116，用于处理信用卡和/或记帐卡的授权与资金捕获。按照至少一个实施例，这些部件中的一个或多个可以作为一个异步的进程来实现，以便减少或最小化对网络服务器的响应时间及可用性的影响。

运输子系统(XPS)

该运输子系统(XPS)124一般地处理送货最佳时间规划、送货车辆路线、容量(capacity)计划以及由送货人使用的移动场装置的编程。因此，该运输子系统可以配置成提供下列功能特点：(1)送货规划，以及送货最佳时间保留；(2)送货给用户区，并进行相应的记帐和处理，包括调整的处理、信贷以及退货；以及(3)调整送货操作参数，例如，卡车路线计划、送货车辆使用、服务周期、停车时间、送货人规划、要下载进MFD的数据等。

如图1所示，例如该运货124可包括多个部件和/或其它的子系统，这些其它子系统包括路线计划器118，MFD服务器112、场移动装置106、运输资源管理(TRM)软件108以及送货人110。在其它的实施例中，这些部件中的至少一部分例如MFD服务器112可以实现为一个独立的子系统，并且可驻留在该运输子系统的外部。

路线计划器118提供了访问运输资源管理(TRM)软件108的接口，该TRM部件可以利用一个规划和优化部件(SOC)软件包(例如由加拿大的Descarts Systems Group所制造的)来实现。按照该实现例，TRM部件可以跟踪所有的按照每个区的基础上组织的送货最佳时间的当前状态，送货车辆可以作为送货计划的一部分而分配给这些区，与TRM108一起工作的路线计划器118分配特定的路线和站点给特定的送货车辆，最好，在该用户选择的送货时间最佳时间内为一个特定的用户规划一个站点。

运输子系统的一个功能是根据运输能力数据如可用的送货人的数量、可用的送货车辆的数量以及当天的定单数量、卡车路线等产生可用的送货最佳时间的清单(以展示给用户)。

在至少一个实施例中，运输子系统124还包括一个区最佳时间生成器部件，它可为每一天生成送货最佳时间时间规划并产生由网络商店子系统使用的最佳时间模板。该运输子系统还包括一个送货最佳时间估计器部件，它确定哪一个送货最佳时间次数被保留以及哪一个送货最佳时间次数是可由用户保留的。利用由该送货最佳时间估计器产生的数据，该网络商店随后显示所保留的以及可用的送货最佳时间给用户。

按照另外一个实施例，在网络商店子系统内的送货商业对象估计并缓存关于每个区、每个子区和每个用户基础上的送货最佳时间可用性的信息。当用户请求查看可用的送货最佳时间时，该送货商业对象使用该区的用户送货地址数据和当前的行进(van)路线和站点集来估计并将用户可用的送货最佳时间时间隙展示给用户。按照一个特定的实施例，该可用的送货最佳时间信息是利用一个送货最佳时间栅格(grid)被提供给用户。

当用户选择一个送货最佳时间时，该送货最佳时间商业对象提交该请求给运输子系统的路线计划器118，该计划器随后执行一个校验检查以确保所选择的送货最佳时间可以向用户承诺。按照一个特定的实施例，该送货商业对象连续地调整它的送货世界的查看以便获取小于1％的估计误差。

按照一个特定的实施例，该运输子系统可包括多个路线计划器，这些计划器每一个配置成同时运行。每个路线计划器能分配或规划一组区域的送货。按照一个实施例，一个路线计划器只服务于一个区。在路线计划器失效的情况下(例如由于硬件失效)，该运输子系统可设计或配置成导致不同的路线计划器接管由失效的路线计划器处理的该组区域的送货规划任务。并且在另一个实施例，纠错可以在响应该失效检测后自动地执行。

派遣子系统

按照至少一个实施例，该运输子系统可包括一个派遣子系统(在图1中没有示出)，用于对送货人和送货车辆资源的状态的实时访问。利用派遣子系统，派遣器可以与正在途中的送货人进行通信，并且可以使用派遣子系统提供实时的送货路线的再规划。按照一个特定的实施例，该派遣子系统可以利用该TRM部件实现。

移动场装置(MFD)子系统

尽这在理论上说，MFD服务器112可以与运输子系统分在一组，但是该MFD服务器部件112也可以配置成包括至少一个驻留在区域数据中央的后端服务器。因此不同的区域可以由不同的MFD服务器来服务。而且，在一个特定区域的每个区可以通过数据网络由连接到该区域数据中央的站来服务。每一个移动场装置(MFD)单元或客户106可以通过该数据网络与一个区域MFD服务器112进行通信，并且可以下载或上载各种类型的信息，包括客户订单历史信息，送货信息(例如车辆送货路线、站点等)，客户退货信息、信贷以及调整等。

按照一个特定的实施例，每个送货人在其送货到客户区时都携带一个MFD装置，每个MFD装置可以配置成通过一个无线通信系统与一个MFD服务器进行通信。例如，该MFD装置可以包含一个射频异频雷达收发机，该收发机与一个射频发送接收器进行通信，以便与MFD服务器通信。在本实施例中，利用该MFD装置是有可能将它在该场内捕获或产生的所有的期望的数据立即发送给MFD服务器的。例如该MFD装置可以实时地发送送货人在某一个客户站点的到达与离开时间。利用该信息，一个派遣操作员就能自动地跟踪在该场内的送货人的状态。而且按照一个特定的实施例，当MFD装置与MFD服务器之间的通信链接中断时，该MFD装置可以存储它在该场内产生和搜集的所有的处理过的数据，并随后在到MFD服务器的通信链接重新建立起来后，通过一个批处理过程将所存储的数据发送给MFD服务器。而且，可以理解，MFD装置可以配置成当其不能与MFD服务器通信时可充分地执行所有的功能和操作。

在送货期间，MFD装置106可能配置成向送货操作员或送货人提供送货路线信息，包括送货路线和站点。而且，MFD装置也可以配置成校验送货的物品。另外，利用该MFD，送货人可以立即处理在客户区内(例如在送货给用户时)的用户的各种请求，例如订单修改、客户退货、记帐调整、库存调整、信贷等。MFD装置能利用存储在该装置内的数据处理各种用户服务请求，所有这些在送货之前已下载到MFD单元内，因此在送货时处理客户服务请求的同时MFD装置并不与MFD服务器进行通信。可替换地，MFD装置可配置成在处理客户服务请求期间利用任意一种标准的移动通信技术通过区域MFD服务器通信，这种技术如RF数据系统、蜂窝数据系统等。在后一个实施例中，MFD装置可以配置成即使当MFD装置暂时地不能与MFD服务器通信也可以处理客户服务请求。

当MFD在客户送货区处理完所有相应的交易后(包括校验由用户接收的当前订单的物品)，MFD也可配置或设计成向客户提供一个调整过的记帐收据(即零余额收据)，表示在考虑了与所有的处理过的退货、信贷以及调整等后应收费的总额。

当在送货路线上完成了送货后，在退货到站之前，可能将MFD装置106连接到MFD服务器112，并将所有处理过场交易上载进该区域数据中央，在此，在前端办公数据库131内进行处理和存储，所上载的MFD数据可包括送货事件发生的次数。

按照一个特定的实施例，直到订单已被送货并且有关该送货的MFD数据被在前端办公系统接收到才会为该送货订单对用户进行记帐，也会针对要调整的应记帐的总额对该用户进行记帐，这在经过调整的记帐收据上会指示出来(在送货时会提供给客户)。以这种方式，该用户可以在送货时知道应对该用户收取的全部费用。

客户关系管理(CRM)子系统

客户管理子系统126是一个交互式应用，客户业务代表(CSR)143可以利用它来管理客户业务请求以及跟踪客户的交互。由CRM子系统提供的功能包括如访问客户信息；对于各种客户问题(例如抱怨、退货以及损坏的货物等)发放信贷；处理用于处理客户问题的工作流等。CRM子系统按照客户请求也提供具有访问、查看以及编辑客户信息的CSR(有时也称作客户业务操作员)。

CRM子系统的一般体系类似于网络商店。例如在特定的实施例中，CRM子系统可以使用同一应用、商业对象以及由网络商店使用的数据库访问层。

在图1所示的实施例中，CRM子系统包括一个帮助桌面部件144，该桌面部件是利用一个Remedy软件包来实现的，由MountainView的Remedy公司制造。该帮助桌面部件管理用于处理特定的用户请求或问题的所有工作流。例如网络商店和运输子系统可以为各种事件如无效的信用卡授权或在送货中客户报告的短缺等产生故障通知(ticket)。该CSR通过CRM子系统的帮助桌面部件144处理这些通知。利用这些帮助桌面部件，CSR能初始化和跟踪有关所处理的故障通知所有的客户合同。该CSR也可以通过帮助桌面GUI142访问这些帮助桌面部件144。

按照一个特定的实施例，帮助桌面部件包括一个数据库145，用于管理客户业务请求和/或问题，可替换地，该帮助桌面部件可能配置成共享前端办公室数据库131。

订货管理子系统(OMS)

订货管理子系统(OMS)150管理与本发有的集成系统体系相关的多个方面，包括例如定价，可用性，库存、销售商、金融、过程以及各种子系统之间的数据流。

图8表示由订货管理子系统提供的不同的功能元件方块图，该图还示出了在订货管理子系统与本发明的其它子系统之间流动的各种数据类型。如图8所示，该OMS子系统包括企业资源计划系统810，用于处理从其它子系统的至少一部分接收的数据。该数据处理系统810包括一个订货管理部件812，购买部件814，金融部件816，收费部件818以及库存部件820。订货管理部件812负责管理客户订货。购买部件814负责发布购买订单给相应的销售商，金融部件816负责管理帐目以及与整个系统操作有关的信息，收费部件818负责管理客户的收费信息，包括收费交易，以及库存部件820负责维护库存记录，确定库存的可用性以及库存的补充。在OMS处接收的和/或从OMS交付给其它子系统的各种数据(例如130A，140A，154A，180A，190A)将在下面参照附图6、7A、7B进行更详细的说明。

如图1所示，OMS子系统150包括图形用户接口152，以及用于存储从其它子系统的至少一部分接收的各种数据的至少一个数据库151。按照一个特定的实施例，该数据库151配置成包括多个架构(schemas)，例如标准包应用架构和/或定制的架构。按照一个特定的实施例，OMS数据库配置为一个运行在SUN Solaris服务器上的单一的Oracle数据库。

该订货管理子系统还可以配置成包括用于管理金融和分发应用的软件和/或硬件，在一个实施例中，这种软件是由加利福尼亚Pleasanton的PeopleSoft公司提供，另外该应用软件可包括多个部件，例如用于查询和在线交易入口的用户接口，用于数据、报告等的背景处理的批处理。

OMS批处理可能利用一个过程规划器来控制，该过程规划器可以管理当前正在运行的过程号以及某一过程将要运行或执行的日期和/或时间。该过程规划器可以使得当前正在运行的所的过程的中央可视性有效。批处理以及报告可以利用多个不同的技术来建立，这在本技术领域内是已知的。

订货管理子系统也可以配置成支持与其它子系统的同步或异步接口。在一个特定的实施例中，OMS配置成支持与其它所有的子系统的异步接口，这种具有多个优点，下面将进行讨论。另外每一个OMS接口是可配置的，并且可以配置成支持批处理的运行。

按照一个特定的实现，所有的PUB-OMS和WS-OMS接口被配置成运行在数据库架构级。新的和更新的数据可以邮寄到该数据源数据库内的一个永久的消息队列(例如一个级连表)，在这里，数据可以处理成目的数据。

而且，按照一个特定的实现，在PUB与OMS之间的接口可以配置为一个简单的执行程序，它支持数据(例如SKU、目录以及UPC等)从PUB到OMS的移动。该接口程序通过呼叫PUB数据库内的一个存储进程来请求新和或更新的数据的级连(stage)，然后利用确保数据有效性的相应软件来插入和/或更新在OMS数据库内级连的数据。

在OMS与其它子系统之间的各种接口的实现可以利用本技术领域内已知的各种不同技术来实现，下面所描述的提供了这种技术中至少一些的示例，来用于将OMS与其它子系统进行接口，但是应明白，一些特定的接口也可以使用本技术领域所知的其它的技术来实现。

在OMS与网络商店之间的接口可以利用例如多个可执行程序来实现，可执行程序的第一部分负责将数据从网络商店移动到OMS，这些数据包括例如新/更新客户数据、新/更新订货数据、订货截止信息、订货收费信息、客户退货信息、客户信贷以及费用(收费调整数据)等。可执行程序的第二部分负责将数据从OMS移动到网络商店子系统，这些数据包括例如库存数据、可用数据、定价数据以及关于发货客户订单的信息。

在OMS与订单履行子系统(OFS)160之间的接口可以作为例如一个平文件接口来实现，不同的文件可以用于系统内的每个交易类型。例如该OFS-OMS接口可以支持下列交易：(1)从OMS到OFS的新/更新的SKU和UPC数据；(2)从OMS到OFS的期望的收据(用于销售商购买订单和专用的客户订单)；(3)从OFS到OMS的期望的订单确认；(4)从OMS到OFS的计划的客户发货数据；(5)从OFS到OMS的发货确认数据；(6)以及从OFS到OMS的库存同步和调整数据。按照一个特定的实施例，第三方的软件包如Mercator(来自Connecticut Wilton的TSISoft)可以用于将来自OMS数据库的数据映像到ASII文件(例如平文件)，相反亦如此。出站的(outbound)数据(来自OMS)可以直接从OMS数据库表中选择并格式化成用于交付的相应的文件格式。进入(inbound)的数据(到OMS)可能处理进OMS内的级连表，在此，它随后处理成由OMS批处理支持的交易表。

食物生产管理子系统(MFG)

食物生产管理子系统(MFG)管理有关处方、子处方、成份、菜单、食物安全程序、设备使用等的信息与购买要求。按照一个特定的实施例，SKU数据和费用数据可以从OMS到MFG来划分。MFG随后计算所生产的销售“SKU”(例如烹调的食物)的费用和营养内容，并把该信息交付回给OMS。MFG也可以使用食物生产计划以及处方信息来确定成份的购买要求，这些要求随后交付给OMS以便获取。

订单履行子系统(OFS)

订单履行子系统160管理分发中央(DC)170的所有功能。在图1的实施例中，OFS包括管理DC设备170的相应的硬件和/或软件，包括例如，仓库管理系统(例如软件应用)，至少一个数据库161，至少一个接口162以及一个自动材料处理(AMH)控制器中央163，其管理传送带、转盘以及扫描仪部件。

在一个特定的实现中，该订单履行子系统160可以利用一个仓库管理系统如由加利福尼亚州的Costa Mesa的Optum公司提供的MOVE仓库管理系统来实现，该仓库管理系统也提供了与订单管理子系统的接口。在特定的实施例中，该接口是利用一个商业主机接口(BHI)实现的，该仓库管理子系统可以提供使得OMS子系统与OFS数据库161进行通信的接口。

该仓库管理系统将指令(如任务清单)传送到自动材料处理控制器(AMH)163，该AMH控制器处理这些指令并管理传送带服务器178和转盘服务器172。该转盘服务器172和传送带服务器178每一个都包括各自的数据库171，175。转盘服务器172发出控制信号给转盘客户端(client)173，它驱动转盘硬件174和控制转盘移动。类似地，该传送带服务器178处理来自AMH的指令，并发出控制信号给传送带客户177，它控制和驱动用于路由库存和管理交通的扫描仪硬件176和传送带。另外，该传送带客户177和转盘客户也可以利用接口监视传送带和转盘硬件的接口。

仓库管理系统也与处理计算装置164通过一个无线接口例如一个射频接口进行通信。处理计算设备164由分发中央雇员使用来执行和/或确认库存移动操作。也可以提供一个图形用户接口162与订单履行子系统进行接口以便向用户提供监视分发中央操作和/或手动地分配订单的能力。

按照该实施例，OFS可以定义成包括该分发中央170以及所有相关部件，包括硬件、人力资源、库存量等。在一个替换实施例中，如图1所示，该分发中央170可以定义成包含OFS和它的部件(160，161，162，163)；转盘和传送带部件172，173，174，176，177，178；以及处理计算装置。

数据仓库子系统(DWS)

该数据仓库子系统180是来自构成本发明的集成系统的子系统的至少一部分的信息的仓库。该DWS子系统配置成分析各种子系统数据并基于所分析的数据产生报告。按照一个特定的实施例，该数据仓库子系统维护一个中央数据库。按照另一个实施例，数据仓库子系统可包括多个数据库其它的部件，如一个运行数据贮藏室(ODS)181，数据仓库(DW)189，数据分析部件和报告产生部件。

该数据仓库子系统周期性地轮询或捕捉来自每个运行子系统数据库的数据，并将信息存储进一个运行数据贮藏室(ODS)181。通过将来自各个子系统的数据搜集进一个单一的ODS，可以更有效地对ODS数据进行复杂的报告和/或查询，而不会影响到运行子系统的性能。

每个运行子系统可包括一套独立的表，称为数据源，数据源中的表可以驻留在一个数据库中，也可以驻留在不同的数据库中，并且在这些表之间还具有引用限制。一种称作“变化捕捉”的处理不断增加地搜集来自每个数据源的更新和新的插入行，并将它们存储在ODS内的级连表。数据源的一系列连续变化可以以周期性的间隔(例如24小时)从这些级连表中移进ODS。

按照该特定的实施例，ODS包括来自每个运行子系统的所有的数据源表或一部分，除非有些表是子系统的管理员请求明显地排除的。该ODS数据可以用于例如每天或每周期地报告活动以及用于调查先前发生的操作细节。

数据仓库(DW)189包括从ODS中导出的表。最好，该DW表设计成便于报告和商业分析。按照一个特定的实施例，在数据仓库中的表集成的并且去标准化以产生可提供高级商业描述的更少、更宽的表。

该数据仓库子系统180还包括可运行和可分析的报告功能，来自前一天或更早时候的详细数据的报告可查询ODS数据库。分析性报告可访问ODS和DW表。如果想要对对子系统的每分钟状态的报告，可以提供一个或更多个接口以允许数据仓库子系统查询该期望子系统的运行数据库。

按照一个特定的实施例，该数据仓库子系统数据库利用例如“快照日志”和“可序列化事务”这样的特征。当对一个给定的表生成一个快照日志时，该数据库软件就生成一个副(side)表和一个可一直地触发更新该副表触发器，以将所改变的、增加的、或删除的记录存储进该表中。该DWS随后可以检查该副表并在某一时间拖出已变化的表。可序列化事务可以确保在记录中事务级的连续性，数据可以周期性地拖进该级连区域(例如每小时、每天等)。而且，连续性事务也可以周期性从该级连区域拖进ODS数据库(例如每小时、每天等)。

如图10所示，ODS数据库181和数据仓库数据库189可以用于提供多个报告，包括例如特别报告1002，状态报告1004、每天报告1006、年度报告1008、总结性报告1010以及其它类型的分析报告1012。

集成系统体系操作

为了更好地理解本发明的系统体系的集成本质，回顾在正常的商业操作期间各子系统的交互是有助于理解的。

图4和图5提供了在正常的商业操作期间各子系统交互的高级数据流框图，尤其是图4提供了有关库存流入(即库存补充)的子系统交互的高级预排(walkthrough)。图5提供了有关库存流出(例如客户订单履行和送货)的子系统交互的高级预排。

参照图4，在(1)处，新或修改物品(SKU)信息由商人通过PUB网站GUI(134，图1)或大装载器接口(136，图1)键入到PUB子系统140中。SKU信息可包括关于诸如UPC码、图像、营养信息、属性、产品名称等的物品。

在(2a)处，OMS周期性轮询该PUB以查找新或更新的数据。该新或更新的SKU数据存储在OMS数据库51(图1)。在(2b)处，SKU数据也自动地输出到数据库以及前端办公系统130的目录部件。按照图4的实施例，引入到主网络商店目录的的新物品对于客户来说是不可用的，除非对该新物品客户已发出了新的订单。在(2c)，OMS周期性地发送新的或更新的SKU数据到OFS，该新的或更新的SKU数据存储在OFS数据库161(图1)。

在(3)处假定一个购买者已认可了一个购买订单(PO)(已在订单管理子系统150处针对一个新物品产生)。一旦PO得到认可，在(4a)处，PO自动地通过EDI子系统182发送给相应的销售商。另外，在(4b)处，一个用于购买订单荐的期望的收据(ER)自动地从OMS发布给OFS160。该期望的收据通知OFS特定物品的数量(有关该购买订单)期望在某上日期或接近某上日期到达分发中央。

附加地，在已经认可了用于新物品的购买订单后，在(4c)OMS自动地通知前端办公系统130新物品的可用性及价格。在至少一个实施例中，可用性包括关于在特定的日期有多少新物品的单元是可用的特定数据，这些可用性数据称作可用立约(ATP)数据。

而且，在至少一个实施例中，价格数据可以计算或设置以及在OMS中得到许可(例如，通过购买者)。按照一个特定的实现，定价可以基于费用加定价的方法来计算。因此，在第一地理区域客户看到的某一物品(SKU)的价格可能不同于在第二地理区域内显示给客户的定价信息，这些取决于在每个地理区域内在存储特定物品时所涉及的相关费用。当新的价格得到许可后，OMS公开它们组网络商店子系统，随后更新显示给客户的定价信息。

针对某一物品的定价可以基于商人提供该物品或SKU的描述性信息，因此，可以利用一个预先确定的规则自动地确定定价信息，这套规则可能在不同的地理区域是不同的。例如，当发生对某一物品的购买订单时，与该物品(SKU)相关的属性就被分配一个费用因子或专用于该地理区域(在该区域内交付该物品)的号。对于订购物品的定价随后自动地根据该费用因子来确定。

一旦该网络商店接收到新物品的ATP和价格数据后，在(5)处新物品的信息就自动可用于客户的查看和购买。显示给客户的物品信息可以从先前从PUB子系统注入到网络商店目录的目录数据中获得。

在(6)处假定有关新购买订单物品的销售商发货在该分发中央接收到，在(7)处处理所接收的发货，包括进行库存和将所接收的发货的每一物品存储起来。一旦完所接收的发货，就会在(8)处从OFS 160到OMS 150发布一个期望的收据确认。另外OFS提供了有关原始购买订单和所接收的发货的所有库存调整(例如短缺)。当OMS接收到所期望的收据确认数据后，在(9)处OMS处理该数据并更新的它的库存记录和ATP信息。一旦更新了OMS库存记录后，在(10a)处OMS根据期望的收据确认数据执行有关该购买订单的所有必须的金融交易。另外在(10b)处有关所接收的物品的修改的ATP和库存数据从OMS 150发送给前端办公系统130。在(11)处前端办公系统(例如网络商店)根据从OMS接收的修改的数据对相应的物品更新它的ATP和库存记录。

在(12)处，销售商通过EDI子系统182发布一个针对该购买订单发货的发票，但是应明白，后一事件可以发生在销售商接收到该购买订单后任一时刻。

图4的例子描述了对于本发明的系统体系的集成本质独特和有利的特征。例如后台办公系统的异步体系使得商人能在任意时刻输入描述性的产品信息到该PUB子系统140。PUB子系统部件例如大装载器136自动地分类、编目录、分类和编目录所接收的商人数据。一旦处理完，所接收的商人数据就存储进该PUB子系统。因此可以理解本集成系统的整个公开和编目录过程可能自动地由商人驱动，该过程通过消除劳动费用(否则要由PUB系统的操作员手动地维护和更新该公开/编目录数据库)而提供了费用的有效性。

本发明的集成体系的另一个显著的优点是允许根据任一个子系统内所发生的单一事件而自动地更新各个子系统的信息。因此，如图4所示，针对一个新物品(在3处)的购买订单可自动地使得该购买订单发布到相应的销售商，并且针对该购买订单的期望的接收发布到订单履行子系统160，并且自动地使得更新的ATP和价格数据传送到前台办公系统，由此所更新的ATP和价格信息就自动显示给客户。另外，在在PO涉及一个库存的一个新物品时，该新物品信息利用先前由商人提供的描述性信息自动地变得对用户是可用的。而且期望的收据的自动的发布导致自动地跟踪有关该购买订单的状态、付款、送货以及实际接收的库存。而且，按照该特定的实施例，当一项新产品发货到达时，该库存系统将已配置成识别该产品的UPC码。另外，显示给用户的该产品可用性(ATP)将自动地根据该订单的状态以及产品的期望的到达日期以及它当到达分发中央后的产品可用性而进行更新。以这种方式，本发明的技术大大地减少了为管理和维护库存流入的所有方面所需要的手工劳动量。

参照图5，示出了关于库存流出(例如用户订货、履行和送货)的子系统交互的高级预排。在(1)处用户通过前台办公系统130放置一个订单。按照一个特定的实施例，该用户订单是在该用户执行了一个“结帐”程序后放置的，由此来自用户电子购物车的物品就被处理进行销售。在用户完成了该检查程序后，在(2a)处网络商店执行税务的计算和和对该订单的总值进行信用卡授权。按照至少一个实施例，此时并不对该订单向该用户收费，而是利用用户的信用卡或记帐卡信息，获取一个可验证可用的信贷限制以及用户信贷或记帐的有效性的授权。按照该特定的实施例，税务的计算和信用卡的授权可由税务和信用卡系统414(图5)来执行。在图1的实施例中，是网络商店子系统132的部件。而且，按照一个特定的实施例，每个规划的订单将具有一个相关的信用卡授权。

在放置了客户订单后，但在通过一个预定的截止时间之前，该客户可以取消或修改该订单的任何部分，包括修改与该订单相关的交付时间最佳时间，也允许客户服务代表(CSR)以截止时间之前对规划的订单进行修改。另外，在这段时间期间，在(2b)处OMS周期性地轮询该网络商店以查找新或更新的规划的任务以便该OMS可以处理任何必要的请求计划。按照一个特定的实现，对于一个特定的客户订单的截止时间是基于该规划的订单的交付最佳时间来确定的。

在特定的实施例中，可以通过制作一个新的网络商店订单来实现对订单的修改，这个动作可以产生新的规划订单或改变已有的规划的订单。客户或CSR可以改变例如删除订单物品、修改一个或多个已订物品的数量、修改交付时间或交付的目的地、或取消整个发货等。如果这些变化要求任何的信用卡重新授权，则前台办公软件处理它。

在截止时间，前台的运输子系统将最后定下来路线信息加到该客户订单。在截止时间之后，在(3)处该OMS轮询该网络商店以获取有关该规划的订单的最后信息。另外，该网络商店更新它的与该规划的订单相关的物品的ATP数据。按照另一个实施例，该网络商店可在每个它修改客户的电子购物车的内容时更新它的ATP数据。一旦该网络商店将更新后的ATP数据提供给OMS后，该OMS就更新它的ATP数据以便与该网络商店的ATP数据同步。按照一个特定的实施例，OMS与WS ATP数据不同步的仅有时间是当在分发中央接收到新的交付时，并且该新的ATP数据还没有传播到该网络商店。该OMS根据在网络商店处客户订单以及在分发中央接收的发货计算它的ATP数据。

按照一个特定的实施例，在截止时间发生之前，该OMS可将客户订单放置在货仓(hold)内以防止它被传送给OFS进行履行。在截止时间后，当该订单结算或“冻结”时，该OMS将删除该订单上的货仓以便将订单传送给OFS 160进行履行，如在(4)处所示。当所有信息(例如订单信息和交付信息)结算时，一个订单可以认为是结算或冻结了。传送给OFS子系统160的订单数据可包括SKU数据和运输/交付数据(例如交付车路线、停站等)。

在(5)处，在OFS子系统处接收的订单被履行并处理以发货给客户。在容器或集装箱中运输所订购的物品。每个集装箱具有唯一的物理授权平板(plate)ID，该ID包括可由一个扫描仪阅读的条形码。每个集装箱与一个相应的客户订单相关联，每个客户订单可包括一个或多个集装箱。

在订单已履行并处理完可进行发货后，在(6)处OFS传送一个与该客户订单相关的后(post)履行状态数据给OMS。该后履行状态数据可包括例如集装箱的数量、与该客户订单相关的每个集装箱的物理授权平板ID、用于将集装箱向或从该交付卡车上移动的每个运货移动车，和/或与该运货订单相关的车辆ID。在(7)处，该OMS将运货状态数据中继给前台系统130的网络商店。该运货状态数据可包括对还没有履行的订货物品的调整。在接收到运货状态数据后，该网络商店更新该运货订单的订单状态，它是可由客户或CSR访问的。

一旦在前台系统130接收到发货状态信息后，在(8)处前台办公系统下载交付清单数据、客户订单历史数据以及给移动场设备(MFD)系统412的交付路线数据。按照一个特定的实施例，前台办公的该运输子系统传送交付清单、客户历史清单以及给MFD服务器的交付路线数据，随后将这些数据下载进一个移动场设备(例如MFD或MFD客户)。

在将正确的数据下载进MFD后，就可以派遣该交付的人以将该订单交付给客户。在(9)该订单被交付人送到该客户。此时，交付人可以使用移动场设备来处理集装箱退货、物品退货、订单修改、订单调整、信贷、税务计算等。按照一个特定的实施例，该移动场设备(MFD)配置成处理上述的客户服务交易而不必传送给MFD服务器。在MFD处理完各种客户服务请求后，交付人可以向客户提供一个修改的收费收据，包括考虑到所有的处理退货、订单修改、调整信贷、和/或新的税务计算等的调整总量。

另外，在货物送给客户时，该交付人可以利用MFD扫描所送的货物以便生成一个客户实际接收到的物品，该信息连同一个交付时间标记一起存储在MFD中。

当交付人退货到区站时，存储在MFD中的经过处理的数据被上载到MFD服务器中。按照该特定的实施例，当交付人在场内时，该MFD数据也可以通过一个无线通信系统一载到MFD服务器中。在(10)处，交付交易数据从MFD系统412传送到前台办公系统130。按照一个特定的实施例，MFD服务器将交付交易数据传送给运输子系统，它随后更新前台办公数据库内的订单状态信息。在(11)处，前台办公系统根据更新的订单状态信息计算最终的税务，并利用客户的收费信息起动一个资金获取，也就是在此点才对用户针对该订单进行收费，但是收费的帐目会考虑到在交付时由MFD处理的任何退货、订单修改、调整和/或信贷。

在(12)处，网络商店将最终的发票数据和退货数据传送给OMS，该OMS处理最后的发票数据以及退货数据，并相应地更新客户发票和收费记录。另外，在(13)处OMS通知OFS任何退货(通过事先发货通知一ASN)以便OFS一旦接收到所退货的物品可以正确地进行处理。在(14)所退货的物品由OFS进行接收和处理，在所退货的物品在分发中央进行处理和再储存后，在(15)处OFS传送退货确认数据给OMS，该OMS根据从OFS接收的退货确认数据随后更新的它的库存以及ATP数据。另外，在(16)处OMS将更新的ATP数据转发给前台办公系统130，在此网络商店更新它的ATP信息。

如上面所提到的，本发明的系统体系的集成本质提供了很多唯一并且新颖的优点，这在本发明描述的先有技术中是达不到的。例如本发明的一个优点涉及在客户放置订单后还可以进行修改的能力。如图5中所描述的，订单可以由客户在该订单的指定截止期限之前的任何时候进行修改，另外该客户也可以在交付的时候修改该订单。而且本发明的系统提供客户返还、信贷和/或调整的能力以在交付折时候进行处理。正是由于交付人与移动场装置和本发明的其它子系统的集成而使得后一部分特征成为可能。

本发明技术的另一个优点涉及客户收费的时间。如前面所述的，传统的在线商店一般地在发货的同时对客户进行收费。但是按照本发明的技术，是在订单传送给客户后才对其收费。而且本发明的系统体系的集成本质也使得可调整整个收费量以反映出在交付时或在规划的接货时所有的退货、订单修改、信贷和/或调整。而且通过在交付的时候提供一个修改的或“零余额”的收据给客户，该客户就可以接收到当前悬而未决的所有收费(对此要对客户进行收费)的立即确认，这就向客户提供一个保险，即在客户的信贷或记帐上不会出现附加的或隐藏的收费。

而且，本发明集成体系也提供了实时的错误修复(failover)能力。尤其是，该系统体系的异步设计允许系统连续操作而不管是否一个或多个子系统脱机。例如，在OMS处一个临时的子系统失效不会影响客户购物和由前台办公系统130执行的订单功能。另外，当脱机的系统重新恢复后备份数据进行排队和批处理以便于处理。

容量和ATP数据计算

本发明的集成系统体系的另一个优点涉及关于提供给客户的目录物品的可用立约(ATP)信息以及在各个子系统内的资源容量的保护和分配。按照本发明的至少一个实施例，根据所选子系统的可用容量在订货时管理订单流，与一个特定的物品相关的ATP信息可以用于调整针对该物品的订单流。

按照一个实施例，该网络商店跟踪可用物品的数量，并允许用户只选择在给定的时间隙确保可用的物品，其显示可基于进入该分发中央的期望到达的SKU。如果发货没有到达或延迟了，则该信息被传播给WS，由此该WS自动地更新关于被延迟的发货的物品的可用性信息。该WS利用在商店显示内的如“可用的”、“在库中”“到...时可用”以及“何时可用”的标签跟踪物品可用的时间隙。

按照一个特定的实施例，ATP值(例如许可使用的特定物品的数量)在OMS中进行计算并公开给该网络商店。该ATP数据可以例如基于SKU库存管理方法、ATP方法、物理库存数量和/或计划从销售商接收的数量进行计算。

而且，按照一个特定的实现方式，每个物品或SKU具有一个关于在各种子系统中保存的容量数量的相关的容量配置文件，以确保在规定的交付日期和时间进行物品的履行和交付。特定物品的容量配置文件可包括多个各个容量属性如库存类型属性、回收(pickup)类型属性、时间属性以及空间属性等。该库存类型属性涉及货架上是否有一个物品(在此记作停留的库存，例如一袋X商标的土豆片)或者该物品必须被履行以订货(FTO)，例如一块特定的肉。回收型属性涉及与该物品相关的存储条件，例如空间温度存储(室温)、冷冻或冷藏。时间属性涉及估计的履行和交付该订单所占用的人力资源时间量。时间属性也可包括多个子目录，例如包含一个回收人时间值以及一个交付人时间值。空间属性涉及与该物品相关的物理空间要求。

按照本发明一个特定的实施例，该网络商店132维护对应于所选子系统的当前可用和保留的容量资源的资源容量数据缓存。当用户选择一个特定的物品要购买时，该网络商店就接收针对所选物品的容量配置文件(profile)，并且利用该数据确定在所选的子系统中是否有足够的资源容量以确保所选的物品可以被履行并且规定的交付日期、位置和时间送到客户手中。如果在所有的所选子系统中没有足够的容量资源，该网络商店就不会将该物品显示为在规定的交付时间最佳时间是可用于销售的。

但是，如果该网络商店确定在每个所选的子系统中都有足够的容量资源以确保所选的物品可履行并且可以在规定的交付时间最佳时间送给客户，该网络商店就允许所选的物品加到客户的购物车中。另外，随着该网络商店将该物品加到客户的电子购物车，它通过更新包含在资源容量数据缓存中的数据还在每个所选的子系统中保留了特定量的资源容量。按照该特定的实施例，在每个所选的子系统中由网络商店保留的容量数量与所选物品的容量配置文件属性相关。以这种方式，网络商店子系统可连续地跟踪每个所选子系统内的可用资源容量以便计算关于该网络目录物品的ATP数据，并且可以进一步利用这些数据在订货时调整客户主要问题的流入。

下面的示例说明了这种构思。在本例中，假定客户希望将冰淇淋容器加到客户的电子购物车。当用户选择该容器冰淇淋以加到它的购物车时，该网络商店子系统就首先确定如所选物品的可用性(例如在规定的交付日期的可用数量)、该物品的存储温度、是否有足够的人力资源在规定的交付时间履行该物品订单，以及是否有足够的可用运输资源在规定的交付时间运送该物品，包括在交付车的冷冻区是否有足够的空间以容纳该物品。假定这些资源中每一样都是可用的，网络商店就将该物品加到客户的电子购物车。另外在将物品加到客户的电子购物车后，网络商店在所选的子系统中保留足够数量的容量以确保所订货的物品可以被成功地履行并在规定的交付日期和时间送给该客户。

如果客户随后修改了一个订单(在截止时间之前)或从他的电子购物车中删除了一个物品(在结帐之前)，该网络商店子系统就自动地释放针对所删除或取消物品的所有保留的容量，以便该容量可由其它的用户保留。如果客户放弃了他的购物计划和/或没有进行结帐，则也要释放容量。

按照一个实施例，该网络商店子系统负责计算当前的ATP以及维护对应于所选子系统的所保留的和的资源容量记录。但是按照不同的实施例，OMS可执行这些功能。

数据流

图6、7A、7B说明了在正常的商业运行期间本发明的各种子系统和部件交互的数据流框图的特定的实施例。

应明白，在图6，7A和7B中所示的各种数据流按照一个特定的按时间顺序排列方式提供的。如下面将详细讨论的，数据从一个子系统流到第二子系统是可以响应一个事件的发生触发的。在图6、7A、7B中的数据流的其它类型也可以在预定的时间间隔进行初始化。

参照图6，在(A)处OMS 150以周期性的间隔轮询该PUB子系统140以查找新或更新的物品数据，该间隔可以从分钟到几天不等。按照一个特定的实施例，OMS每隔大约30分钟轮询该PUB子系统以查找新或更新的物品数据。该物品数据包括例如新或更新的SKU数据、UPC数据以及销售商数据等。

在(B)处，OMS处理所接收的物品数据并以周期性的间隔如大约每隔2小时将SKU信息(例如UPC以及产品产商数据)传送给OFS。按照一个特定的实施例，该产品商数据包括在集成系统中所有分配的SKU的清单以及UPC和与每个SKU相关的描述性数据。

在(c)处，在OMS处创建或生成PO。作为响应，针对该PO的期望的收据被从OMS传送到OFS。在(D)处，接收该PO商品，入库并放好。一旦OFS处理完所接收的库存，该OFS就发送一个期望的接收确认给OMS，该OMS利用所接收的确认数据更新它的库存和ATP数据。在(E)处，以周期性的间隔ATP和价格数据从OMS发送给前台办公130。例如，ATP数据可以每小时发送，并且价格数据可以每个24小时进行发送。另外，按照特定的实施例，从OMS发送给前台的所有数据存储在前台办公数据库131内(如图1)，在此称为网络商店数据库。

在(F)处，在网络商店子系统处从该客户接收新或更新的客户信息。作为响应，该数据从网络商店转发给OMS。在(G)处，在前台完成一个订单结帐或订单更新动作。按照一个特定的实施例，当客户在在线商店上放置一个订单时，该网络商店子系统就创建一个销售订单或一个针对该客户物品的规划好的发货。该销售订单可包括代表这些物品一个或多个订单线(line)、数量以及被许诺在规定的交付最佳时间交付到客户处的已订购物品的价格。而且按照至少一个实施例，该规划的交付最佳时间在规划的发货内被捕获。而且对于每一个规划的发货，该运输子系统规划在特定的交付路线上的车辆着站点。

按照一个特定的实施例，该OMS周期性的轮询该网络商店数据以查找新的订单、订单更新以及订单取消，随后在OMS中处理所接收的数据。

在(H)产生截止时间。按照一个特定的实施例，用于特定的客户订单的截止时间是基于与该客户订单相关的交付最佳时间时间。在任意给定的时间周期(例如每天中几个不同的截止时间)可以有几个截止时间，其中每个不同的截止时间对应于与特写的交付最佳时间时间相关的客户订单的一个特定部分。例如，在某一天要在上午9:00到下午1:00交付的客户订单可将截止时间设置在同一天的上午12:01，而要在下午1:01到下午6:00交付的客户订单可将截止时间设置在同一天的下午4:01。

在订单截止时，前台办公对准备截止的订单执行截止处理，这是基于这样的一个时间值，即履行并将该订单发货出分发中央以及时地交付到客户交付地址所需要的时间。在一个实施例中，该运输子系统截止处理优化准备进行截止的所有车辆的路线。网络商店截止处理可以订单线上执行对被卖空的SKU的补充。按照一个特定的实施例，已完成WS和XPS截止处理的订单被OMS删除。作为响应，OMS可以轮询该网络商店数据库以查找有关该截止订单(包括履行到订单或FTO数据)的附加信息。该OMS随后对截止订单和FTO数据执行截止处理并产生(I)订单和FTO下载文件，它们随后被传送到OFS子系统进行履行和发货。

OFS处理从OMS传送的订单下载文件，并且将截止订单信息存储进OFS数据库(161，图1)。OFS包括一个将库存分配给截止订单的订单分配部件，用纸盒装这些订单线(line)(例如分配一个或多个集装箱给每个订单线)，以及生成一个拾取任务。OFS子系统的自动材料处理部件读取该回收任务，并将数据传送给转盘和传送带服务器(172，178，图1)以便操作该转盘和传送带，以及指导分发中央人员提取哪一个物品及其数量。

在针对一个特定的订单处理完FTO后，在(J)处FTO确认数据被从OFS发送到OMS。而且，在已履行且处理完规定数量的订单以发货到客户或站后，在(K)处OFS执行一个发货确认(发货确认)，它生成一个要发送到OMS的发货确认上载文件。如前面所述的，该发货确认数据可以包括例如在每个订单发货中已被回收并发货的物品的库存数据，集装箱ID数据，运输/交付数据等。

一旦该OMS接收并处理该发货确认数据并更新了它的库存数据记录后，在(L)处发货确认数据被转发给前台办公系统进行处理。按照一个特定的实施例，当针对某一交付车路线的所有订单都进行发货确认后，运输子系统就为该路线生成MFD数据，包括关于发货和站点的信息。而且，运输子系统可以生成货车路线总汇、交付清单、行驶方向等。在(M)处前台办公系统传送客户订单历史数据和运输/交付数据给MFD子系统512。按照一个特定的实施例，MFD子系统包括一个MFD服务器和至少一个MFD客户(例如MFD手持设备)。如前面所述的，该MFD服务器将针对一个特定交付路线的客户订单历史数据以及路线/交付数据装载进与分配给该路线的交付人相关的MFD，此后就可以派遣该交付人将订货送给客户。

在交付时，交付人可以使用MFD客户机(client)以处理客户退货、订单修改和/或调整。MFD可以随后重新计算客户的帐单数据以便考虑到所有的退货、信贷或其它调整。在(N)处，交付人退货到站并且将修改的客户帐单数据以及退货数据从MFD客户机上载进MFD服务器。MFD服务器随后转发该帐单数据以及退货数据给前台办公130。在(O)处，利用从MFD服务器接收的修改的帐单数据对客户收费。在对客户针对一个订单进行收费后就关闭该订单。按照一个特定的实施例，OMS周期性地论询该网络商店子系统关闭的订单并将所接收的数据邮寄给OMS金融部门。另外，在(Q)处，在前台办公系统处接收退货数据，在此进行处理并转发给OMS。

应明白，在至少一个实施例中，退货、费用和/或客户帐户的信贷可在交付期间或之后在网络商店子系统内产生或捕获。费用的例子包括交付费用，返还的集装箱存放，取消费用等。信贷的例子包括迟交付信贷，集装箱存放信贷等。按照一个特定的实施例，OMS周期性地轮询该网络商店数据库RMA、费用以及信贷以便精确地更新它的库存和金融数据。

另外，按照一个特定的实施例，网络商店可根据接收的退货数据自动地更新ATP数据以及库存数据以便允许退货的物品可立即用于客户购买。但是按照另一个实施例，网络商店将使得只有在分发中央接收到退货的物品的确认数据后才可进行购买。

在(R)处，OMS接收并处理退货的数据并发布一个期望的退货收据(RMA)给OFS。可以响应例如物品退货、物品短缺以及物品损坏等生成一个退货货物授权。在(S)处分发中央(DC)接收该退货的物品。在DC处已检查并处理过退货的物品(例如登记并放好)后，RMA确认就会从OFS发送到OMS。RMA确认可包括例如涉及退货库存的实际物品(在分发中央重新入库)的SKU数据。

周期性地，OFS可检测到库存的变化，例如由于过期的货物、损坏的货物等。在(T)处OFS周期性地发送库存调整数据给OMS进行处理。该库存调整数据将最终传送到网络商店子系统进行处理。

在(U)处由CRM应客户的请求起动一个帐单调整动作，该帐单调整数据随后从CRM子系统传送到OMS进行处理。

在(V)处，在OMS起动一个退货到销售商(RTV)动作。作为响应，规划的RTV发货数据从OMS发送到OFS进行处理。在规定的货物已被送到销售商后，在(W)处，OFS发送一个RTV发货确认给OMS。OMS随后根据RTV发货确认数据更新它的库存记录。

如在(X)处所示的，OFS周期性地传送库存同步数据给OMS以进行订货来断言在每个子系统中库存数据都进行了同步。例如OFS可每隔24小时发送库存同步数据给OMS。

如在(Y)处所示的，卡车路线计划数据周期性地从前台办公发送到OFS，这可以在每天、每周等的基础上完成。按照一个特定的实施例，卡车路线计划数据是手动地从前台传送给OFS的。按照另一个实施例，卡车路线计划数据也可以自动地从运输子系统传送给OFS。

图7A和7B描述了在正常的商业操作期间各种子系统和部件交互的详细数据流图，用于实现按照一个实施例的电子商务。

参照图7A，在(1)处以周期性的间隔目录数据从PUB子系统140下载到网络商店数据库/目录缓存631，其间隔范围可从几小时到几周。按照一个特定的实现，目录数据每隔24小时从PUB发送到网络商店。再者，按照一个特定实施例，从公布子系统中接收的目录数据存储在网络数据库中。为了最小化访问目录数据时的延迟，在网络商店子系统的工作内存中利用存储在网络商店数据库上的目录数据来缓存该目录的独立实例。还存在有在网络商店存储器缓存的其它的商店目录的其它附加实例。

在(3)处，ATP数据和价格数据从OMS发送到网络商店数据库，其范围从几小时到几周。按照一特定的实施例，ATP数据每小时从OMS发送到网络商店，并且价格数据每24小时从OMS发送到网络商店。

在(4)处，运输子系统的区最佳时间生成器部件以周期性的间隔创建新的交付最佳时间。例如，按照一个特定的实施例，该区最佳时间生成器每隔24小时起动以为将来的一天或几天创建一个新的交付最佳时间。

在(6)处，客户通过因特网访问网络商店132，客户可将客户数据(如注册数据)传送到该网络商店(在(8)处接收)。另外，网络商店也可以从客户机上检索客户数据，这些数据可以存储在一个饼(cookie)文件中。按照一个特定的实施例，客户可以注册它们自己并在网络商店上维护自己的帐户信息。当在网络商店子系统上接收到客户数据时，WS可以数据库中检索个性化的客户参数以便向客户提供定制且喜爱的数据。周期性地，OMS轮询商店数据库新的或更新的客户信息。

在(10)处，客户访问网络商店的交付最佳时间规划部分，这是由运输子系统管理的，在网络商店上购物前，客户并不是必须地保留一个交付最佳时间时隙。但是，按照一个特定的实施例，该客户在被允许进行结帐前必须规划一个交付宣传品时隙。

而且，按照一个特定的实施例，当客户首先在网络商店处注册时，就会请求客户提供一个交付地址，该地址随后由XPS子系统的地理编码器(Geocoder)部件转换成一个纬度/经度对，它会咨询每区的街道地图以便执行这种转换，随后由XPS的时区解析器部件确定该纬度/经度对是在区内或区外。如果该地址是在区内，该时区解析器还确定该特定的区以及与该交付地址相关的子区。该区及子区信息随后作为该客户记录的一部分存储起来，并用确定该客户的特定的交付路线。最初地址是用于该客户放置随后订单的缺省地址。但对于所有的交付来说，客户可以每次更改交付地址，也可更改任何时候的交付缺省地址。

当在运输子系统(XPS)处接收(12)一个交付最佳时间请求时，它就可访问该网络商店数据库以检索交付规划数据，并且运输子系统的交付最佳时间估计器部件产生一个可用和不可用的交付最佳时间时隙(slot)的估计清单，并在(14)处显示给客户。在(16)处客户选择可用的交付最佳时间时隙，随后该交付最佳时间选择数据发送给XPS，该XPS处理(18)该交付最佳时间选择数据，并从网络商店数据库中检索客户地址数据，该交付最佳时间数据及客户地址数据随后转发给运输子系统的路线规划器部件(618)，该路线规划器部件处理该交付最佳时间和地址数据，并且或者确定或取消该交付最佳时间请求。按照一个特定的实施例，该路线规划器使用运输规划和优化软件(SOS)来确定一个特定的交付最佳时间请求是否被确认或取消了。

当验证一个特定的最佳时间请求时，路线规划器可以考虑多个因素，例如在确认一个特定的交付最佳时间请求时运输子系统内必须有足够可用的资源容量。而且，客户地址或发货地址必须与一个预定的可交付地址映射起来。

例如，按照一个特定的实施例，订单交付只能规划成落在预定的可交付区域内的地址。图12描述了按照一个特定的实施例的落在“映射”区的区域1202、“区内”区的区域1204以及“可交付”区的区域1206的客户地址之间的关系。一般地，客户地址是一个货物可送达的物理位置的表述，一个映射的地址是在运输子系统的数据库内具有相应的记录的地址，而一个区内地址由系统分发中央之一所服务地理区域内的地址，一个可交付地址对应于允许与该运输子系统相关的交付人交付发货的地址。一个附加的地址类型对应于通常的运载工具可交付地址，对于该地址来说，可用通常的运载工具如UPS或U.S.邮政服务发货的地址，一个地址既可以是可交付地址，也可以是通常运载工具可交付的。

按照一个特定的实施例，一个可交付地址是区内的。但是，也有部分的区内地址是不可交付的地址子集。例如一个特定的地理区域可以分类为区内，但却是不可交付的。

假定该客户地址对应于一个可交付地址，并且交付最佳时间请求是可行的，于是一个交付最佳时间确认从该路线规划器发布(20)给运输子系统，在此被转发(22)给客户。另外，在确认该交付最佳时间请求后，路线规划器将要保留给所确认的交付最佳时间请求的容量数据转发给网络商店数据库。

在用户与网络商店交互的某些点，该客户可选择开始搜索一个特定的物品或产品。在(24)处，客户提交搜索数据给网络商店子系统。在接收到该搜索数据后，网络商店子系统访问(25)该网络商店数据库，以便检索该搜索结果。一旦检索到，在(26)处该搜索结果随后显示给客户。

在(28)，客户提交一个用于查看与特定物品或产品相关的信息的请求。当在网络商店子系统上接收(29)到该请求时，WS就访问网络商店数据库以便检索关于所选物品或产品的信息，包括价格与可用性。所检索的信息随后显示给客户(30)。

在(32)，客户选择要加到客户的电子购物车的特定物品，或者用于立即购买。当在网络商店子系统上接收到(34)物品选择数据时，该网络商店处理该选择的物品请求。在处理期间，网络商店子系统访问存储在网络商店数据库内(或在一工作存储器缓存)的子系统资源容量信息以验证在所选的子系统内有足够的容量以确保所选的物品可被履行并在规定的交付最佳时间交付给客户。一旦网络商店子系统验证所选物品可被加到客户的电子购物车，WS通过在每个所选的子系统内保留一个足够量的容量来更新网络商店数据库内的容量信息，以确保所选的物品可被履行并在规定的交付时间最佳时间送给客户。在网络商店将所选的物品加到客户的电子购物车后，网络商店报告或显示该信息给客户。

当客户完成购物后，它就可以起动一个结帐程序以购买其电子购物车内的物品。当网络商店子系统接收到该客户的结帐请求时，WS将订单信息转发(40)给下一个税收服务器114(图1)以便针对该订单计算相应的税收。税收服务器(114)根据订单信息计算相应的税收并将计算的税收数据传送回(42)网络商店。另外，在结帐时，WS也检索关于该订单的容量信息(例如，涉及履行该订单所需要的集装箱数量的信息)。一旦接收到税收数据和容量信息，WS处理(43)销售订单。该销售订单数据也存储在网络商店数据库中。

在(44)网络商店子系统的资金捕获部件(CC，116)检测网络商店数据库631上的新销售订单数据，并针对销售订单的总量起动一个信贷(借记)卡授权。当接收到该授权后，授权信息存储在网络商店数据库上。但是如果在获取针对该客户的信贷(借记)卡授权时存在问题，该CC部件就可以发布一个故障通知(故障通知)给帮助桌面144以进行特殊的处理。假定获取了针对一个特定销售订单的信贷(借记)卡授授权，WS就将销售订单数据从数据库631转发给OMS进行处理(46)。

在客户在网络商店上放置某一订单后，在与该订单相关的截止时间之前客户可以在任何时候修改该订单。当客户希望修改某上订单时，例如他可提交(48)订单修改请求给网络商店。在接收到该订单修改数据后，WS处理(50)这些数据，并更新存储在网络商店数据库上的销售订单数据。订单修改信息的处理包括例如重新计算税收、容量以及其它与订单有关的信息。所更新的销售订单数据也可以发送给OMS进行处理。

如在(52)处所示的，客户也可通过CRM子系统126获取订单的修改或取消。例如，该客户可电话通知客户服务代表(CSR)，请求CSR修改或取消某一订单。CSR可通过CRM子系统126实现订单的修改，CRM处理(54)该订单修改数据并更新网络商店数据库上的销售订单数据。

在(56)订单截止时间发生。在此点，客户不能再修改订单。在截止时间之后发生的多个事件在图7B中进行描述。

图7B的数据流图可以认为是图7A的数据流停止处的延续。但是为了清楚及避免混乱，图7A的几个子系统及其部件在图7B中略去以便进行更简化的描述。

如图7B所示，在(56)订单截止时间发生。在针对某一订单的截止时间发生之后，OMS将涉及截止订单的销售订单数据转发给OFS。当OFS接收到该销售订单后，它就处理(例如履行)该订单，传送该处理的给一个区域交付站以交付给客户。在订单已处理并发货给交付站后，在(60)OFS发送发货确认数据给OMS。OMS随后处理(62)由OFS接收的发货确认数据，并将至少一部分发货确认数据给网络商店数据库。

在从网络商店数据库检测并检索到发货确认数据后，该运输子系统产生MFD数据，包括例如客户订单历史信息，交付车辆路线信息以及发货数据等。在(64)MFD数据被发送给MFD子系统，在此被下载进相应的MFD。按照一个特定的实施例，每个MFD被分配一个不同的交付人，该MFD服务器使用该交付人相关信息来确定要下载进每个MFD的特定的MFD数据集。按照一个特定的实现，交付人负责在MFD与MFD服务器之间下载与上载。

在相应的MFD数据下载进MFD后，一个下载确认消息从MFD子系统512发送到(65)运输子系统。在接收到该MFD数据下载确认消息后，MFD设备(包括下载的MFD数据)被传送到(66)分配给特定交付路线的相应的交付人那里。在(68)在MFD数据已被下载到他的MFD后派遣交付人，并且要交付的客户发货已人分发中央到达。

在(70)客户订货被送达客户。按照一个特定的实施例，与该客户订单相关的所有集装箱都从交付车上卸下并留在客户区。对于由客户保留的每个集装箱对客户收取一定的存管费用，该事件可由MFD(交付人携带的)通过扫描交付给该客户的每个集装箱的授权平板ID来处理，例如该集装箱可以在给客户的下一次交付时拾取，或者有计划地拾取。而且，退货的集装箱也可以由MFD处理，并将一个信贷发布给客户。

尽管交付人在客户区，该客户可以起动(72)一个或多个客户业务请求(例如退货、调整、信贷、退货款等)。例如，客户可以通过退货不想要的物品而选择修改已交付的订单。退货的物品可以由交付人立即接收并利用MFD进行处理。客户也可以退货先前订单上的物品。例如，在特定的实施例中，MFD将包含客户在过去30天内的订单历史。在本例中，该客户将被允许退货在过去30天内购买的物品给交付人。

交付人可利用MFD处理(74)该客户服务请求，假定MFD已被配置成可编程为处理这些请求。在处理完客户服务请求后，MFD重新计算客户的余额，并产生一个表示调整后的余额的修改收据。该修改的数据也包括一个所有收费物品、退货物品、调整及信贷等的清单。该收据随后由交付人提供给客户。

另外，按照一个特定的实施例，交付人可在客户区内打开每个集装箱，并利用MFD扫描交付给客户的每个物品。以这种方式，所有的订单调整(例如由于短缺或损坏造成的)可以立即进行处理，并且仅对客户实际接收的物品进行收费。

在(79)交付人退货到交付或对销坞站并且将其MFD上的数据上载进MFD服务器，MFD服务器随后通过运输子系统将客户退货数据以及修改帐单数据转发给网络商店数据库。另外，也由资金捕获部件116检测并检索修改的客户帐单数据。利用修改的帐单数据，资金捕获部件从客户的金融帐户起动(80)一个资金捕获。如果该资金捕获是不成功的，就会发布一个故障通知单给帮助桌面144进行特殊处理。但是，假定资金捕获是成功的，就把付款确认信息存储在网络商店数据库上。按照一个特定的实施例，也可以由CRM子系统实现对客户帐户的收费调整。在图7B所示的示例中，客户通过CRM请求(82)一个要起动的收费调整。在接收到该收费调整请求后，CRM产生收费调整数据给网络商店进行处理并存储在网络商店数据库上。

在(85)OMS周期性轮询该网络商店数据库以检索客户退货数据、客户收费数据以及客户费收费调整数据。按照一个特定的实施例，OMS可每隔2小时轮询网络商店数据以检索完成的订货数据。

如在(86)所示的，CRM也可由客户使用来规划一个交付回收，而不必放置一个新订单。例如，客户可以在规定的时间利用CSR规划一个交付回收，该CSR将回收数据转发(88)给CRM，随后将回收数据转发给运输子系统进行规划。

目录结构

图11表示一个按照本发明的一个特定的实施例说明目录、商店商标目录、商店目录、物品清单以及商店物品之间关系的方框图。在图11中说明的每个目录可以由PUB子系统140产生。另外，至少一部分目录可以由网络商店子系统132产生。如图11所示，主(master)目录1102包括存储在PUB子系统内的所有SKU信息，商店商标目录1104是主目录的子集，商店目录1106是相关的商店商标目录的子集。

按照一个特定的实施例，由本发明的系统表示的每个商店或商店类型可具有特定的“视觉和感觉”，例如便利店，通用部门商店、杂货店、专卖店等。商店商标可以认为是商标单元，它表示一组商店的通用标识。例如，“Webvan Market”是商店“Webvan Market-BayArea”和“Webvan Market-Atlanta”的商标。

商店商标可包括多个商店，每个商店可与一个或多个分发中央关联。但是按照至少一个实施例，一个分发中央仅与每个商标下的至多一个商店关联。因此，例如，没有属于同一商店商标的商店重叠一个给定的服务区。而且，根据客户的送货地址，一个客户可自动地路由到一个合适的商店。

以与目录层次结构类似的方式，由区域分发中央处理的物品可以从在主目录中标识的SKU的一个子集导出。例如，如图11所示，一个地区物品清单1110是它的区域DC物品清单1108的子集。可以根据一个特定的商店目录和特定的DC物品清单构造商店物品。商店物品代表要在某个在线商店或网络商店上显示给客户的东西。

本发明的一个重要的部分涉及可升级性及数据集成性。按照一个特定的实施例，信息由本发明的每个子系统所使用的所有的SKU是基于从公布子系统的主目录中导出的的SKU数据。因此，例如，驻留在每个区域DC内的所有货物将具有同样的SKU关联，这是基于由中央化PUB子系统定义的主目录。

分发中央

图13表示按照本发明一个特定的实施例的分发中央(DC)运行的方框图。在图13的实施例中，1300配置成一个区域DC来履行客户的订单。但是按照另外一个实施例，DC 1300还可配置成一个区域性的DC，对多个地区的DC提供服务，而且DC 1300也可管理所选订单的通常的运载发货。

如图13所示，DC 1300将库存物组织成不同的“拾取”目录，这取决于所推荐的存储温度。因此，例如平时存储在室温的物品将被保存在DC的一个室温库存部分(1302)，冷藏的物品将被保存在冷藏库存部分(1304)，冷冻的物品将被保存在冷冻库存部分(1306)。该DC还可包括至少一个食物产品部分1308，用于准备预先包装的肉或其它食物，另外该DC还可包括一个或多个履行订单(FTO)部分(例如1310A)，用于处理客户的特定订单，例如特殊的食物订单、产品订单、肉食订单等。按照一个特定的实施例，DC的每个库存部分(1302，1304，1306)可包括各自的FTO部分(例如1310A，1310B1310C)。而且，DC 1300包括一个通用的运载包装和发货部分1312，它可以用于例如将物品发货到客户(通过通常的运载工具)，其中该客户驻留在本发明的送货人不能服务的不能交付的地方。

如前面参照图1描述的，分发中央包括由传送带、转盘、扫描仪以及用于自动化订单履行和库存运入处理的手持计算设备构成的系统，它通常由主要问题履行子系统160来管理。

图14示出了按照本发明的一个实施例的OFS出站处理1400的流程图。OFS出站处理一般地扫描了在履行一个客户订单期间发生的事件。在1402，OFS从OMS那里接收客户订单，该OFS随后分配该订单，其中确定每个订单物品的物理仓库位置。利用该订单分配随后确定(1406)足够地履行该订单所需要的集装箱的数量，以及每个集装箱的优化路径。在1408，将集装箱引导进DC转盘/传送事系统。每个集装箱自动地来回移动(1410)一个预定的指定的储装箱路径。如果在DC操作的任何部分检测到问题，该集装箱的路径可动态地且自动地变更。当集装箱在指定路径来回移动时，它会在DC内指定的位置停止，其中该位置是有关该客户的订单所涉及的物品的存储位置。一个人操作员或“拾取器”将规定的订单物品放置该集装箱，并通过利用一个手持计算设备(如RF枪)扫描放置进该集装箱的每个物品以及集装笨的许可平板ID来验证该订单物品的履行。在拾取器确认规定的物品放置进指定的集装箱后，该集装箱随后被引导到自动集装箱运输系统，在此继续沿着指定的集装箱路径行进。

在针对一个特定的储装箱的所有物品都被拾取并确认后，该集装箱被路由到一个发货给(spur)，在此它被加固(1412)到一个合适的移动车上，它可能包含用于一个特定的送货路线的其它集装箱，该移动车和集装箱随后被装载(1414)一个卡车或其它的车上用于发货到一个对销(cross)坞站(地区送货)。在该对销坞站，这些集装箱被装载到送货上以便交付给客户。按照另外一个实施例，客户集装箱的至少一部分可以直接地从地区DC发货给客户，由此消除了对销坞站的转送。一旦对应于一个特定客户订单的集装箱已被发货给对销坞站(或直接地给客户)，就通知OMS(1416)发货确认。按照一个特定的实施例，从OFS发送给OMS的发货确认数据可包括例如订单ID、每个发货物品的订单线号(SKU)(及其数量)、与订单相关的ID、移动车ID以及送货车ID等。

与出站程序类似，利用一个自动材料处理和运输系统，可以在分发中央接收和再储存物品，如图1的方块170所示。

图15示出了按照本发明一个实施例的OFS入站处理1500的流程图，该库存再存储处理开始于OMS处为特定的库存物品产生一个购买订单。在1502，在OFS处从OMS接收关于所购买订单的一个期望的收据，该期望的收据数据可包括例如销售商名称、期望的收据ID号、估计的发货到达时间以及所订购物品的数量等。一旦在分发中央处接收到(1504)期望的发货，所接收的商品被托运进一个合适的盘，一个盘代表可用于运输所接收的商品物品以便进行再存储的容器。与集装箱一样，每个盘包括一个唯一、可扫描的许可平板ID。当将商品托运进一个盘后，利用一个RF枪对商品及盘进行扫描，随后利用自动传送带系统自动地将盘路由(1508)到合适的位置，一旦盘到达了指定位置，该盘上的物品就由拾取器存储(1510)并确认(例如通过一个RF枪)。按照一个特定的实施例，对于所完成的每个盘货物的再存储，就OFS产生(1512)一个期望的收据确认并发送给OMS。该期望的收据确认数据可包括例如期望的收据ID、再存储的物品的SKU以及各自的数量。

其它实施例

图2表示本发明的集成系统200的另一个实施例的方框图，图2的实施例尤其适用于允许不同的网络商店展示关于同一产品的不同信息给驻留在不同地理区域的不同客户。因此，例如客户A(202A)可驻留在圣-弗朗西斯科，而客户B(202B)驻留在亚特兰大。如在本部分中所用的，术语“网络商店”可代表一个在线商店，通过各自的网络商店子系统实现的。

利用图2中所示的本发明的技术，第一个网络商店(204A)可以专门定制为用于客户A(也就是驻留在圣弗朗西斯科)，以及第二个网络商店(204B)可以专门定制为用于客户B(也就是驻留在亚特兰大)。不同的网络商店定制可包括例如不同的语言、对同一物品的不同的描述以及不同的定价等。每个网络商店204A和204B可由一个或多个服务器206A和206B服务，而且如图2所示，每具网络商店的实现包括一个前台办公系统和后台办公系统，以及中央化发布、数据仓库以及CSS系统。例如，地区A网络商店204A主要由地区A商业单元230A管理，它包括一个前台办公系统210A，后台办公系统220A。类似地，地区B网络商店204B主要由地区B商业单元230B管理，它包括一个前台办公系统210B，后台办公系统220B。各地区商业单元230A和230B的各子系统(例如WS，XPS，CRM，OMS，OFS，DWS，MFG，CSS)在功能上类似于先前参照图1描述的对应的子系统部件。

图1与图2实施例的主要差别在于包含一个中央化管理系统280(图2)，总(HQ)商业单元279。如图2所示，该中央化的管理系统280可包括多个商业目录部件250，它用于管理显示在每个网络商店204A、204B上的目录信息。另外，该中央化管理系统280包括多个主子系统277，它用于管理每个地区商业单元内的对应的从属子系统。例如CSS 264可配置成从CSS-A232和CSS-B 232B接收数据，OMS-HQ可配置成管理和存储来自OMS-A 222A和OMS-B222B等的数据。

总商业单元279管理所有的商业单元的操作，包括多个HQ子系统(例如DWS-HQ 272，CSS-HQ 274，OMS-HQ 276)，用于管理HQ商业单元的每天的操作。例如DWS-HQ 272可配置成作为已在HQ 279上运行的报告的仓库，CSS-HQ 274管理与HQ相关的人类资源信息，OMS-HQ 276主要管理与HQ商业操作相关的金融功能。

与图2的实施例相关的一个重要的特征是与每个地区特定网络商店204A、204相关的目录信息和内容由中央管理系统280管理，而不是由地区单元230A、230B中的任何一个管理。下面参照图2A详细地描述这些特征。

图2A的方框图描述了在图2所示的至少一部分子系统之间交互。在图2A的实施例中，中央PUB子系统256为每个地区单元230A、230B(以及为每个地区特定的网络商店)管理和控制所有的SKU和目录内容。PUB子系统256的功能类似于图1的PUB子系统140的功能。

因此，例如以类似于图9的方式，该PUB子系统256(图2A)发布相应的SKU信息给每个从属OMS子系统224A、224B。这些数据最终传送到各个OFS子系统224A、224B。另外，PUB子系统256发布它的数据给每个从属PREP子系统217A，217B，其中这些数据最终传送到各个WS子系统212A，212B。

该PUB子系统256也将其目录数据发布给内容管理子系统(CRM)252。CMS 252的功能就是为网络商店204A和204B创建并维护该内容页。每个网络商店的目录内容信息随后输出给商店目录块250，它包括一个数据库或其它用于存储不同的网络商店目录的存储器结构。网络商店服务器206A，206B访问存储在目录数据库250内的相应的商店目录信息，并将检索到的信息显示给各自的客户202A和202B。

目录块250可包括多个商店目录，包括一个主目录，商店商标目录和商店目录。主目录包括来自该发布子系统256的所有的SKU信息，一个商店商标目录包括对于与给定的商店商标相关的商店来说是可用的一组SKU。按照一个特定的实施例，每个商店商标具有一个商店商标目录，一个商店目录可包括对于给定商店的所有商店SKU的清单。另外，可以理解，SKU对于特定的商店目录是可用的，但可能不被选择为显示给客户。

图2A的实施例的另一个特征涉及中央化客户支持中央。例如如图2A所示，客户业务代表可由客户202A和202B通过一个中央化帮助桌面子系统254来访问。该帮助桌面子系统254配置成允许从不同的地理区域对客户进行访问。因此，按照一个特定的实施例，有一个中央化客户服务操作服务于给定区域的所有客户例如美国。

图3给出本发明另外实施例的方框图。图3中很多的部件和子系统在功能上类似于先前参照图2和2A描述的各部件和子系统，因此在此不进行详细描述。另外，订单子系统312A、312B在功能上类似于先前参照图1描述的网络商店子系统132，其区别在订单子系统不负责于管理客户注册和帐户信息。

但是，图3的实施例包括图1和图2的实施例中没有描述的特征和优点。例如，按照图3的实施例，来自不同地理区域的客户302可通过因特网或其它数据网络访问一个或多个不同的网络商店304。针对每个网络商店的客户注册和签名处理由中央客户数据中央351处理。另外，客户数据中央351管理客户的帐户和记帐信息。用于每个商店的目录展示和内容是以类似于图2A的方式进行管理的。发布子系统356将其目录数据发布给内容管理子系统352。在此处理数据并产生商店目录。所产生的商店目录存储在商店目录数据库350内，该数据库可由网络服务器306访问。网络商店服务器利用来自每个商店目录的信息显示对应于每个网络商店的合适的内容。

另外，图3的实施例使得会员384能通过因特网API 382引导它们自己的在线店面。按照一种实现方式，会员是通过一个在线商店304将其商品卖给客户302的第三方，它由图3的系统300进行管理。该会员可控制会员商店目录的内容，但是，购物、订货、履行以及交付由地区商业单元(例如320A，320B)来处理的。

客户的购物和订货是由地区商业单元(例如320A，320B等)处理的，根据客户的交付地址或其它的涉及客户物理位置的信息，一个客户可被路由到最近的地区商业单元。因此，例如，来自亚特兰大的客户将被路由到亚特兰大商业单元，而来自圣弗朗西斯科的客户将被路由到圣弗朗西斯科商业单元，进行购物、订货、履行和交付的处理。当然来自不同地区的客户也可被路由一个单一配置成购物、订货、履行和交付处理的办公系统。

尽管参照附图详细地描述本发明的几个优选实施例，但应明白，本发明并不限于这些特定的实施例，本技术领域内人员从中可做各种变化和修改而不会脱离所附的权利要求书定义的本发明的精神和范围。

Claims (114)

1、一种集成系统，用于通过数据网络实现电子商务，该系统包括：

含有存储器的库存子系统，该库存子系统包括一个配置或设计成维护多项商品的库存记录的库存数据库；

与该库存子系统通信的用户接口子系统，该用户接口子系统被配置或设计成存储来自库存子系统的可用的库存数据，以及进一步配置或设计成展示有关该库存商品的可选物品信息给至少一个用户，该用户接口子系统还配置或设计成便于用户的商品交易以及存储用户的订单信息；

与该库存子系统进行通信的订单履行子系统，该订单履行子系统配置或设计成接收用户订单信息，该订单信息包括针对至少一项物品的至少一个用户订单，该订单履行子系统还配置或设计成便于履行用户订单，其中履行用户订单包括获取有关该订单的至少一部分物品，以及准备将所获取的物品以发货给用户；以及

与该用户接口子系统和库存子系统进行通信的送货子系统，该送货子系统配置或设计成接收有关至少一个已履行的用户订单的物品，并且也配置或设计成便于将所接收的物品送货给该用户。

2、如权利要求1所述的系统，进一步包括一个数据仓库子系统，用于接收和分析从其它的子系统中产生的数据。

3、如权利要求1或2所述的系统，其中所述的库存子系统进一步配置或设计成管理从客户接口子系统接收的客户订单，以及管理与客户订单有关的客户记帐数据。

4、如权利要求1-3中任一个所述的系统，其中所述的库存子系统包括：

订单管理子系统，配置或设计成管理从客户接口子系统接收的客户订单；

金融计算子系统，用于管理与购买和销售交易有关的金融信息；以及

库存补充子系统，配置或设计成管理库存数量，以及产生用于获取增加的库存的销售商购买订单。

5、如权利要求1-4中任一个所述的系统，进一步包括与所述库存子系统和所述的客户接口子系统进行通信的发布子系统，用于管理与每一项商品相关的目录数据。

6、如权利要求1-5中任一个所述的系统，其中所述发布子系统进一步配置或设计成管理由客户接口子系统展示给至少一个客户的信息内容。

7、如权利要求5-6中任一个所述的系统，其中所述的目录数据包括关于每项物品的描述信息。

8、如权利要求1-7中任一个所述的系统，其中所述的描述性信息包括每项物品的SKU标识符和UPC标识符。

9、如权利要求5-8中任一个所述的系统，其中所述的发布子系统包括用于允许商人将目录数据输入到发布系统的接口。

10、如权利要求5-9中任一个所述的系统，其中所述发布子系统进一步配置或设计成利用至少一部分所述的目录数据产生至少一个商店目录以输出到客户接口子系统。

11、如权利要求5-10中任一个所述的系统，其中所述的客户接口子系统包括至少一个商店目录的表述，包括与所述多项商品物品中至少一部分有关的信息，所述的系统进一步配置或设计成使得至少一个商店目录在预定的时间间隔利用来自所述发布子系统的目录数据被自动地更新。

12、如权利要求5-11中任一个所述的系统，其中所述的库存子系统包括每项商品物品的一个主物品数据库，所述的系统进一步配置可设计成使所述的主物品数据库在预定地间隔利用来自所述发布子系统的目录数据自动地更新。

13、如权利要求10所述的系统，其中所述客户接口子系统包括至少一个客户目录的表述，代表要显示给客户的所选的商品物品，其中所述的系统进一步配置或设计成根据可用的库存数据自动地修改客户目录数据。

14、如权利要求5-13中任一个所述的系统，其中所述的库存子系统进一步配置或设计成为包含在所述库存记录内的至少一个物品产生一个新的购买订单(PO)，根据来自所述购买订单的数据为至少一项物品确定新的定价信息，以及自动地发布一个与该购买订单有关的期望的收据给订单发行子系统。

15、如权利要求14所述的系统，其中所述的库存子系统进一步配置或设计成自动地通知至少一个销售商该产生的购买订单。

16、如权利要求13所述的系统，其中，

所述的库存子系统进一步配置或设计成为包含在所述库存记录内的至少一个物品产生一个新的购买订单(PO)，根据来自所述购买订单的数据自动地为至少一项物品确定新的定价信息，以及自动地通知至少一个销售商该产生的购买订单；以及其中所述的系统进一步配置或设计成自动地利用来自所述产生的购买订单的数据更新存储在客户接口子系统内的可用的库存数据。

17、如权利要求16所述的系统，其中所述的客户接口子系统进一步配置或设计成自动地修改该客户目录以包括与所产生的购买订单有关的所有新物品。

18、如权利要求1-17所述的系统，其中所述的客户接口子系统进一步包括一个用于存储物品库存数据的店面库存数据库，所述的物品库存数据包括物品可用性数据和价格数据。

19、如权利要求18所述的系统，其中所述的店面库存数据库包括对应于库存物品的可用立约(ATP)库存数据，其中这些物品可以在规定的交付日期交付给客户。

20、如权利要求19所述的系统，其中所述的客户接口子系统进一步配置或设计成根据存储在店面库存数据库内的数据计算ATP库存数据。

21、如权利要求20所述的系统，其中所述的客户接口子系统进一步配置或设计成响应客户选择购买的物品自动地重新计算所述ATP数据的至少一部分。

22、如权利要求18-21所述的系统，其中所述的系统进一步配置或设计成利用来自所述库存子系统的数据以预定的间隔自动地更新所述的店面库存数据库。

23、如权利要求18-21所述的系统，其中所述客户接口子系统进一步配置或设计成响应客户选择购买的物品修改所述物品库存数据。

24、如权利要求18-21所述的系统，其中所述的客户接口子系统进一步配置或设计成利用物品库存数据管理客户订单和订单修改。

25、如权利要求18-21所述的系统，其中所述的客户接口子系统进一步配置或设计成允许客户在一个预定的截止时间之前修改所接收的订单。

26、如权利要求25所述的系统，其中所述的系统进一步配置或设计成在预定的截止时间之后自动地输出来自所述客户接口子系统的客户订单数据给所述的库存子系统。

27、如权利要求26所述的系统，其中所述的系统进一步配置或设计成在预定的截止时间之后自动地输出来自所述库存子系统的订单数据给所述的订单履行子系统。

28、如权利要求18-27所述的系统，其中所述的系统进一步配置或设计成响应从订单履行子系统正在接收的订单发货确认信息自动地更新所述库存子系统内的库存记录。

29、如权利要求1-28所述的系统，其中每项物品具有与其相关的容量属性集，这些容量属性对应于响应客户选择购买的物品而保留在每个子系统内的容量数量。

30、如权利要求29所述的系统，其中每个容量属性集包括：

至少一个库存容量属性；

至少一个交付容量属性；以及

至少一个订单履行容量属性。

31、如权利要求29-30中作任一个所述的系统，其中该客户接口子系统进一步包括一个容量数据库，用于管理与这些子系统相关的容量数据，所述的容量数据包括每个子系统可用的容量数据以及为每个子系统保留的容量数据，该客户接口子系统进一步配置或设计成在利用该容量数据订货时管理客户订单的流入。

32、如权利要求31所述的系统，其中用于选定物品的所述的容量数据包括：

有关所选物品的库存类型信息；

有关所选物品的运输信息；以及

有关所选物品的履行信息。

33、如权利要求31-32之一所述的系统，其中所述的系统进一步地配置或设计成利用每一个子系统的数据分别以预定的间隔自动地更新所述的容量数据。

34、如权利要求31-33之一所述的系统，其中所述的客户接口子系统进一步地配置或设计成响应用户购买所选择的物品在所述的容量数据库中针对所选的子系统保留一定的容量，以便所选系统所保留的容量数是和所选物品相关的容量属性的设置相关。

35、如权利要求34所述系统，其中所述的客户接口子系统进一步地配置或设计成响应客户修改至少一个物品的期望数量自动地修改与至少一个订货的物品的相关的保留的容量。

36、如权利要求35所述的系统，其中所述的客户接口子系统进一步地配置或设计成当客户针对至少一个订购的物品取消一个相关的订单时，释放与一个订购的物品相关的保留的容量。

37、如权利要求31-36所述的系统，其中该客户接口子系统进一步地配置或设计成利用该容量数据指示至少一个客户哪一个库存物品可用于购买的，以及何时所述的可用物品是可交付的。

38、如权利要求1-37之一所述的系统，其中所述的交付子系统包括：

运输子系统，包含多个送货车和送货路线管理子系统；

至少一个送货人；以及

至少一个移动场设备(MFD)，所述的MFD包括配置或设计成存储交付路线信息和对应所选择的客户的订单历史数据的存储器。

39、如权利要求38所述的系统，其中所述送货子系统进一步地包括一人客户送货映射子系统，该映射子系统进一步地配置或设计成根据客户的送货地址确定送货业务对于所选的客户是否是可行的。

40、如权利要求39所述的系统，其中确定送货业务可行性的步骤不是基于与该客户的送货地址相关的地区码。

41、如权利要求38-40之一所述的系统，所述的系统进一步地配置或设计成允许客户在订单交付给客户时修改订单。

42、如权利要求38-41之一所述的系统，其中MFD进一步地配置或设计成在将订货交给客户期间远程地处理客户对订单的修改。

43、如权利要求42所述的系统，其中MFD进一步地配置或设计成在送货人处于客户的送货地址区时允许送货人处理至少一个客户的业务请求。

44、如权利要求43所述的系统，其中该客户的业务请求包括要求退货先订购的物品。

45、如权利要求43-44之一所述的系统，其中该客户业务请求包括请求修改正在送往客户的订单。

46、如权利要求38-44之一所述的系统，其中该系统进一步地配置或设计成使得至少一个送货人接收客户的至少一个退货物品，并且进一步地配置或设计成使至少一个送货人利用MFD立即处理至少一个退货的物品。

47、如权利要求38-44之一所述的系统，其中该系统进一步地配置或设计成使至少一个送货人在送货给客户期间利用MFD处理客户业务请求，以及提供一个经过修改的收据给客户，该修改的收据具有自动地对与处理过的客户业务请求相关的所有记帐调整进行收费的总额。

48、如权利要求1-47之一所述的系统，其中该系统进一步地配置或设计成对已被确认为客户接收的订购物品向客户收费。

49、如权利要求47所述的系统，其中该系统进一步地配置或设计成仅在订单已交付给客户后对订单向客户收费，其中要向客户收费的金额对应于要收费的总额。

50、如权利要求1-49之一所述的系统，其中所述的订购交易包括针对要交付给至少一客户的所选物品规划一个送货时间最佳时间。

51、如权利要求1-50之一所述的系统，其中所述的订购交易包括针对要交付给至少一客户的所选物品规划一个送货时间最佳时间。

52、如权利要求1-51之一所述的系统，其中所述的送货子系统进一步包括一个用于产生送货最佳时间数据的送货最佳时间规划子系统，以及其中所述的客户接口子系统配置或设计成利用所述的送货最佳时间数据针对要送货给所述的至少一个客户的所选物品规划一个送货时间最佳时间。

53、如权利要求1-52之一所述的系统，其中该订单履行子系统进一步配置或设计成对已成功地履行并发货给客户的库存物品，发送发货确认数据给涉及订单的库存子系统。

54、如权利要求1-53之一所述的系统，其中所述的订单履行子系统进一步地包括：

用于存储至少一部分所述的库存物品的存储中央；

至少一个集合容器，用于容纳与各客户订单相关的至少一部分物品；以及

一个自动操作容器运输系统，用于将所述至少一个容器运输到所述存储中央内的各个位置以履行订单。

55、一种用于通过数据网络实现电子商务的集成系统，包括：

第一商业单元，用于服务与第一地理区域相关的第一多个客户，该单元包括：

包含有存储器的第一库存子系统，该子系统包括一个配置或设计成维护多个商品物品的库存记录的库存数据库；

与第一库存子系统通信的第一客户接口子系统，所述的每客户接口子系统配置或设计成提供有关库存物品的所选物品信息给至少一个客户，所述的第一客户接口子系统进一步配置或设计成便于客户购物交易以及存储客户订单信息；

与第一库存子系统进行通信的第一订单履行子系统，所述的第一订单履行子系统配置或设计成接收客户订单信息，所述的订单信息包括针对至少一个物品的至少一个客户订单，所述的第一订单履行子系统进一步配置或设计成便于客户订单的履行；以及

与第一客户接口子系统和第一库存子系统进行通信的第一送货子系统，所述的第一送货子系统配置或设计成接收有关至少一个已履行的客户订单的物品，并且还配置或设计成便于将所接收的物品送货给至少一个客户；

第二商业单元，用于服务与第二地理区域相关的第二多个客户，该单元包括：

包含有存储器的第二库存子系统，该子系统包括一个配置或设计成维护多个商品物品的库存记录的库存数据库；

与第二库存子系统通信的第二客户接口子系统，所述的第二客户接口子系统配置或设计成提供有关库存物品的所选物品信息给至少一个客户，所述的第二客户接口子系统进一步配置或设计成便于客户购物交易以及存储客户订单信息；

与第二库存子系统进行通信的第二订单履行子系统，所述的第二订单履行子系统配置或设计成接收客户订单信息，所述的订单信息包括针对至少一个物品的至少一个客户订单，所述的第二订单履行子系统进一步配置或设计成便于客户订单的履行；以及

与第二客户接口子系统和第二库存子系统进行通信的第二送货子系统，所述的第二送货子系统配置或设计成接收有关至少一个已履行的客户订单的物品，并且还配置或设计成便于将所接收的物品送货给至少一个客户；以及

中央管理单元，用于管理由每个商业单元提供给它的各自客户的信息内容。

56、如权利要求1-55中任一个所述的系统，其中所述的中央管理单元包括与每个库存子系统和每个客户接口子系统进行通信的发布子系统，所述的发布子系统配置或设计成管理对每个商业单元来说是可用的商品物品相关的目录数据。

57、如权利要求1-56之一所述的系统，其中：

第一商业单元与服务于所述第一多个客户的第一在线商店相关联；

第二商业单元与服务于所述第二多个客户的第二在线商店相关联；

所述的中央管理子系统还包括一个与每个在线商店进行通信的目录数据库，所述的目录数据库包括商店目录信息，包括与第一在线商店相关的商品物品的第一商店目录，以及与第二在线商店相关的商品物品的第二商店目录。

58、如权利要求55-57之一所述的系统，进一步包括一个总商业单元，用于管理中央管理单元以及用于管理与每个商业单元有关的商业操作。

59、如权利要求57所述的系统，其中所述的中央管理单元进一步包括一个中央客户数据中央，用于存储与多个客户相关的客户帐户信息，包括第一和第二多个客户。

60、如权利要求59所述的系统，其中每个在线商店配置成从客户数据中央访问客户帐户数据。

61、如权利要求59或60所述的系统，进一步包括：

与每个商业单元和中央管理单元进行通信的多个服务器，用于通过该数据网络管理每个在线商店；

所述的多个服务器包括用于使会员能管理会员在线商店的至少一个接口；

所述的系统进一步配置或设计成使至少一个所选的商业单元服务于所述会员在线商店处的客户购物行动。

62、如权利要求61所述的系统，其中该系统进一步配置或设计成根据与特定客户相关的地理区域将一个特定的客户路由到相应的商业单元。

63、一种用于通过数据网络实现电子商务的集成体系系统，包括：

客户接口子系统，用于通过数据网络提供所选的一些产品的表述给客户，以及使该客户能通过数据网络产生用于所选产品的子集的订单；

与客户接口子系统进行通信的库存子系统，用于维护和控制与提供给客户的产品相关的库存数据；

与库存子系统进行通信的订单履行子系统，用于通过数据网络处理订单；

与客户接口子系统和订单履行子系统进行通信的运输子系统，用于通过数据网络规划送货和管理运输资源；

其中集中体系系统的每个子系统通过与至少一个另外的子系统交互而通过该数据网络实现它的各种功能。

64、一种通过数据网络实现电子商务方法，该数据网络包括一个便于由至少一个客户选择的物品的订货交易的客户接口子系统，用于管理客户订单的该订单管理子系统，用于管理库存和库存数据；一个订单履行子系统，便于客户订单的履行；用于便于送货客户订单给客户的送货子系统，所述的方法包括：

在客户接口子系统处接收客户订单，该客户订单包括与至少一个订购物品相关的信息，以及包括与规定的送货最佳时间时间相关的信息；

在预定的截止时间之后，发送有关该客户订单的信息给该订单履行子系统；

在订单履行子系统履行至少一部分客户订单，所述的履行包括验证已被成功地履行并处理以发货给客户的每个库存物品；

交付该履行的订单给客户；以及

产生有关送货给客户期间处理的该客户业务交易的更新的记帐数据。

65、如权利要求64所述的方法，进一步包括允许该客户在所述的预定截止时间之前的任何时间修改该客户订单。

66、如权利要求64或65所述的方法，进一步包括允许客户在交付订单给客户期间修改客户订单。

67、如权利要求64-66之一所述的方法，进一步包括利用一个移动场设备(MFD)在交付订单给客户时处理客户业务交易，所述的MFD配置或设计成存储所述的更新的记帐数据。

68、如权利要求67所述的方法，其中所述的处理客户业务交易包括处理客户区处的客户退货。

69、如权利要求67-68之一所述的方法，其中处理客户业务交易包括处理客户区处的订单调整。

70、如权利要求67-69之一所述的方法，其中所述的处理客户业务交易包括生成由客户接收的每个订购物品的记录。

71、如权利要求67-70之一所述的方法，进一步包括在将订货送给客户后针对有关更新的记帐数据对客户收费。

72、如权利要求64-71之一所述的方法，进一步包括：

为至少一个商品物品产生一个销售商购买订单；

响应该销售商购买订单的生成自动地发布给一个期望的收据给订单履行子系统，所述的期望的收据包括关于购买订单的信息；以及

针对与该购买订单相关的物品更新可用性及价格信息。

73、如权利要求72所述的方法，其中所述的更新包括：

针对与该购买订单相关的物品计算更新的可用性和价格信息；以及

根据所计算的更新的可用性和价格信息自动地更新客户接口子系统内的可用性和价格信息。

74、如权利要求72或73所述的方法，进一步包括：

接收与该销售商购买订单相关的销售商发货；

处理来自销售商发货的接收的物品；

响应正在处理的至少一个接收的物品产生期望的收据确认信息；以及

利用期望的收据确认信息更新有关接收的物品的可用性信息。

75、如权利要求72-74之一的方法，进一步包括自动地通知至少一个销售商所产生的购买订单。

76、如权利要求65-75之一的方法，进一步包括在所述的预定截止时间之后发送最终的客户订单信息给所述的订单履行子系统。

77、如权利要求64-76所述的方法，进一步包括提供一个中央化发布子系统，用于管理与每项商品相关的目录数据。

78、如权利要求77所述的方法，进一步包括利用公布子系统管理由客户接口子系统提供给至少一个客户的信息内容。

79、如权利要求77或78所述的方法，进一步包括在发布子系统处接收SKU信息；

自动地处理所接收的SKU信息以由此生成目录数据和处理的SKU数据；

发布目录数据给客户接口子系统；以及

发布经处理的SKU数据给库存子系统。

80、如权利要求79所述的方法，其中所接收的SKU信息从一个内容提供商处获得。

81、如权利要求79或80所述的方法，其中所接收的SKU信息从一个商人处获得。

82、如权利要求79-81所述的方法，进一步包括利用发布的目录数据自动地更新与客户接口子系统相关的商店目录。

83、如权利要求79-82之一所述的方法，进一步包括利用至少一部分目录数据显示信息内容给至少一个客户。

84、如权利要求83所述的方法，进一步包括根据库存可用性数据，调整显示给该至少一个客户的信息内容。

85、如权利要求64-84所述的方法，其中该接口子系统进一步包括一个店面库存数据库，并且其中该方法进一步包括存储目录数据、物品可用性数据以及在所述店面数据库上的物品价格数据。

86、如权利要求85所述的方法，进一步包括利用所述的物品可用性数据对一个物品产生可用立约(ATP)库存数据，所述的ATP数据对应于要在规定的送货时期送达客户的立约可用的库存物品。

87、如权利要求86所述的系统，进一步包括响应客户选择购买的物品自动地重新计算至少一部分所述的ATP数据。

88、如权利要求85-87之一所述的方法，进一步包括以预定的时间间隔利用来自库存子系统导出的物品可用性数据自动地更新所述的店面库存数据。

89、如权利要求85-88之一所述的方法，进一步包括在利用来自所述店面数据库的数据订货时管理客户订单的流入。

90、如权利要求64-89之一所述的方法，其中该客户接口子系统进一步包括一个用于管理与该多个子系统相关的资源容量数据的资源数据库，所述的资源容量数据包括对每个子系统来说可用的资源容量数据以及用于每个子系统的保留资源容量数据，该方法进一步包括利用所述的资源容量数据在订货时管理客户订单的流入。

91、如权利要求90所述的方法，其中所述的方法进一步包括利用来自每个所述子系统的数据分别以预定的间隔自动地更新所述的资源容量数据。

92、如权利要求90或91所述的方法，进一步包括响应由客户选择购买的物品针对所选择的子系统在所述的资源容量数据中保留一定量的资源容量。

93、如权利要求92所述的方法，进一步包括响应客户修改至少一个物品的期望数量自动地修改与至少一个订货的物品的相关的保留的资源容量。

94、如权利要求92-93所述的方法，进一步包括响应客户修改与至少一个物品相关的送货日期自动地修改与至少一个订购的物品相关的保留的资源容量。

95、如权利要求93所述的方法，进一步包括当客户针对至少一个已订货的物品取消一个相关的订单时释放与所订购的物品相关的保留的资源容量。

96、如权利要求85-95之一所述的方法，进一步包括利用可用性数据向该至少一个客户指示哪个库存物品是可用于购买的，以及何时每个可用物品可送货到该至少一个客户。

97、如权利要求64-96之一所述的方法，进一步包括根据该客户的送货地址确定该送货业务对一个所选的客户是否是可行的。

98、如权利要求97所述的方法，其中该送货业务对所选的客户是否是可用的步骤不是基于与该客户的送货地址相关的地区码。

99、如权利要求67-98之一所述的方法，进一步包括：

在客户区从一个客户接收至少一个退货的物品；以及

利用MFD立即处理与该至少一个退货物品相关的退货交易。

100、如权利要求99所述的方法，其中退货的物品由送货人接收的。

101、如权利要求67-100之一所述的方法，进一步包括提供一个修改的收据给客户，该修改的收据具有自动地对与所处理的客户业务交易相关的所有收费调整进行记帐的收费总额。

102、如权利要求64-101所述的方法，进一步包括仅对已被确认为客户接收的订购物品向客户收费。

103、如权利要求1-101之一所述的方法，进一步包括仅在订单已送到客户后对该订单向客户收费，其中要向客户收费的金额对应于要收费的总额。

104、如权利要求64-102之一所述的方法，进一步包括：

在订单履行子系统接收有关至少一个客户订单的最终客户订单信息；

履行该至少一个客户订单；

处理所述的已履行的客户订单以便发货给客户；以及

在所履行的订单已发货给该客户后产生客户订单确认数据。

105、如权利要求64-103之一所述的方法，进一步包括：

在订单履行子系统处接收有关所处理的客户退货交易的期望的退货数据；

在订单履行子系统处接收至少一个退货的物品；

在订单履行子系统处处理该至少一个退货的物品；

在该至少一个退货的物品已在订单履行子系统处经过处理后产生所退货的物品确认数据。

106、如权利要求105所述的方法，进一步包括利用所退货的物品确认数据更新有关该至少一个退货物品的物品可用性数据。

107、一种利用权利要求1所述的系统实现电子商务的方法，所述的方法包括：

在客户接口子系统处接收一个客户订单，该客户订单包括有关该至少一个订购物品的订货信息，以及包括有关规定的送货最佳时间时间的信息；

在预定的截止时间之后发送有关该客户订单的信息给订单履行子系统；

在订单履行子系统处履行至少一个部分客户订单，所述的履行包括验证已被成功地履行和处理以发货给客户的每个库存物品；

将所履行的订单交付给该客户；

在交付订单期间产生有关客户业务交易的更新的记帐数据；以及

在订单交付之后对该客户记帐有关更新的收费数据的金额。

108、如权利要求107所述的方法，进一步包括允许客户在所述的预定截止时间之前的任何时候修改该客户订单。

109、如权利要求107-108之一所述的方法，进一步包括在将订单交付给客户期间允许客户修改客户订单。

110、如权利要求107-109之一所述的方法，进一步包括利用移动场设备(MFD)在将订单交付给客户时处理客户业务交易，所述的MFD配置或设计成存储所述更新的收费数据。

111、如权利要求110所述的方法，其中所述对客户业务交易的处理包括在客户区处理客户退货。

112、如权利要求110-111之一所述方法，其中所述对客户业务交易的处理包括在客户区处理订单调整。

113、如权利要求110-112之一所述方法，其中所述的对客户业务交易的处理包括生成客户所接收的每个订购物品的记录。

114、如权利要求110-113之一所述的方法，进一步包括在将订单交付给客户后针对有关更新的收费数据的金额向客户收费。

Images