JP2004511402A

JP2004511402A - 輸送計画、実行および運送料支払管理プログラムならびに関連する方法

Info

Publication number: JP2004511402A
Application number: JP2002503775A
Authority: JP
Inventors: アルナプラム、スンダララジャン; ラジャゴパル、スリニヴァス; マルクィーン、マイケル
Original assignee: マニュギスティックス・インコーポレイテッド
Priority date: 2000-06-16
Filing date: 2001-06-18
Publication date: 2004-04-15
Also published as: US20020019759A1; EP1297472A2; PE20020360A1; WO2001099006A2; CA2413065A1; AU2001269887A1; WO2001099006A8

Abstract

要約書なし。

Description

【０００１】
【発明の属する技術分野】
本発明は、予想される輸送コストに基づいて、最適で、コストを最小限に抑える一群の製品輸送の判断を下すための輸送管理プログラムおよび関連する方法に関する。さらに、本発明は、最適化された輸送計画にしたがって製品の配送および／または集荷を追跡および管理し、かつ製品の輸送に対する代金を支払い、かつ送り状を送付するための電子輸送計画、実行および運送料支払管理プログラムおよび関連する方法にも関する。
【０００２】
本特許出願は２０００年６月１６日に出願の米国仮特許出願第６０／２１２，１２４号からの優先権を主張し、その米国特許出願の開示はその全体を参照して本明細書に援用される。
【０００３】
【従来の技術】
現代の経済活動においては、ある組織を成功に導くために、商品および製品の輸送が重要度を増してきている。たとえば、インターネット上で経営するビジネスは典型的には注文に応じて顧客に商品を輸送しなければならない。これらのインターネットビジネスでは、輸送は単なる管理されるべき単純なビジネス機能ではなく、収益を生み出し、顧客を満足させることに影響を及ぼす戦略的機能である。より具体的には、比較的輸送コストが高く、かつ／または比較的商品の配送が遅い、すなわち商品の配送の信頼性が低いビジネスは、深刻な競争力の低下を招く場合がある。したがって、多くの組織はハイレベルな物流資源を商品および製品の輸送を管理することに向けており、産業分野によっては、輸送サービスの管理が、組織の物流コスト全体の最大で半分までを占める場合がある。
【０００４】
商品およびサービスの輸送に関する判断を下すために、組織はこれまで、これ以降、輸送計画管理者と呼ばれる１人あるいは複数人の従業員に依存してきた。輸送計画管理者は典型的には、商品および製品を輸送するタイミング、場所および方法を判断する。たとえば、輸送計画管理者は、輸送のためのビジネス要求およびコストに基づいて、輸送方法あるいは輸送方法の組み合わせ、すなわち航空機、貨物列車、トラック、貨物船等を決定する場合がある。この決定の一部として、輸送計画管理者は、輸送のためのルートおよび時間を判断することが必要な場合もある。輸送計画管理者はさらに、最適な包装形態（たとえば、数個の大きな包装と多数の小さな包装）を決定する場合もある。これらの判断は、コスト検討と、輸送の信頼性および利便性のような他のビジネス関連事項とに基づく。輸送の判断を下す際のこれらの要因および他の要因が以下にさらに詳細に記載される。
【０００５】
図１は、企業が輸送計画要求を解決しようとする際に遭遇する全ての問題点を概略的に示す。図から明らかなように、輸送計画管理者１００がこれらの判断を下そうとするときに、３つの釣り合いをとるべき影響力が作用するようになる。第１の影響力は、商品を出荷するために依頼主１０４あるいは企業の販売部門１０５の要望を詳述する注文情報１０１によって表される。典型的には、この情報は、送り元および送り先、出荷のための時間枠、要望あるいは要求される輸送のタイプ、ならびに商品のサイズおよび重量を含む。第２の影響力は、公共輸送手段および／または自己保有輸送手段のような輸送手段１０６によって利用できるようになる出荷あるいは運送サービスのタイプ１０２によって表される。輸送手段１０６によって利用できるようになる輸送サービスのタイプは、輸送のタイプ（たとえば、冷蔵トラック便、無蓋鉄道貨車等）、輸送手段によってサービスを提供される地理的地域（出荷経路）、および各経路内の各タイプに対して請求される料金に応じて変化する。最後の影響力は、実在のビジネス要因１０３によって課せられ、その経営に関するビジネスのノウハウおよび限界１０７によって決定される、不可能であるとして、あるいはビジネスには意味のないものとしてある特定の輸送問題解決手法を除外する場合がある制約によって表される。これらの制約は、時間帯、出荷物流センターの能力の限界、共同出荷の場合の種々の注文からの製品の好ましい輸送手段および相対的な適合性を含むことができる。最適な計画問題解決手法を達成するために、輸送計画管理者１００は、これら３つの勢力のバランスをとり、輸送ルート（経路）１０９、輸送手段選択１１０、設備選択１１２、クロスドックあるいは物流センターでの中継場所１０８、日程１１１、予想コスト１１３を指定する最適な輸送計画１１４を決定しなければならない。
【０００６】
輸送の判断を下す際に、現在の技術によれば、輸送計画管理者は、輸送コストを自動的に決定できるようになり、それにより輸送計画管理者は、より多くの情報に基づいて輸送の判断を下すことができるようになる。たとえば、２００１年５月１５日にカラ（Ｋａｒａ）に付与された米国特許第６，２３３，５６８号（‘５６８特許）は、出荷／輸送料金を自動的に与えるためのシステムおよび方法を提供する。詳細には、’５６８特許は、任意の数の郵便物あるいは他の品目に適用されることができる、予め認められた最大額の郵便料を含むポータブルプロセッサを用いることにより、郵便料あるいは他の許可情報を電子的に分配するためのシステムおよび方法を開示する。複数の運送業者がポータブルプロセッサを利用して、種々の出荷サービスの許可を得るためのクレジット値を格納および分配する場合がある。したがって、輸送計画管理者は、輸送計画管理者によって望まれる特定の出荷／配送タイプに関連付けられる、種々の出荷サービス提供業者の料金および／またはサービスに関する情報を提供される。これにより、輸送計画管理者は、出荷の最も好ましい方法に関して、より多くの情報に基づいて選択できるようになる。
【０００７】
また現在の技術によれば、輸送計画管理者は輸送中の商品の状態をリアルタイムに追跡できるようになる。フェデラル・エクスプレス（商標）、ユナイテッド・パーセル・サービス（ＵＰＳ）（商標）あるいはＤＨＬ（商標）のような小口貨物および通運会社は典型的には、各配送に対して、航空貨物証券番号として知られる固有の小口貨物識別番号を割り当てる。各小口貨物に対するこの固有の指示は、２部の用紙を輸送計画管理者に提供することによって行なわれ、それぞれ航空貨物証券番号に対応する予め印刷された固有のバーコードを含む。この用紙の一部は小口貨物に添付され、一方、輸送計画管理者はその用紙の他の部分を所有する。その後、小口貨物上の小口貨物識別バーコードは、その小口貨物に対する進捗状況を追跡するために、配送の各段階で走査される。バーコードスキャナはホストコンピュータと通信し、ホストコンピュータに小口貨物ＩＤを送信する。その後、小口貨物ＩＤおよびその位置情報は、ホストコンピュータによって、それぞれ各位置において走査された小口貨物ＩＤの記録を格納するためのデータベースを含む、１つあるいは複数のウエブサーバに送信される。輸送計画管理者は、ウエブブラウザを起動し、ＵＲＬ（一般的にウエブページのアドレスとして知られている「ユニバーサル・リソース・ロケータ」）を指定することにより、インターネットを経由して、サービスプロバイダウエブサーバのうちの１つに、それゆえ小口貨物状態データベーステーブルに接続することができる。ＵＲＬは一般に輸送計画管理者に送信されるＨＴＭＬファイルを示し、輸送計画管理者はその後、固有小口貨物ＩＤを入力するように指示される。小口貨物ＩＤは、サービスプロバイダウエブサーバに送信され、サービスプロバイダによってサーチ判定基準として用いられ、サービスプロバイダは、輸送計画管理者のウエブブラウザ上に表示するための小口貨物の現在の位置を返送する。しかしながら、航空貨物証券を用いるとき、輸送計画管理者は、後に特定の荷物の状態を探索するために用いるための追跡番号を手作業で記録し、保持しなければならない。さらに、従来技術のシステムは、輸送計画管理者が荷動きの状態に関する更新情報を受信するために、ＵＲＬに繰返しアクセスし直さなければならないという問題を抱える。
【０００８】
商品の輸送を管理する際に輸送計画管理者をさらに支援するために、１つあるいは複数の運送業者が出荷サービスのための料金を自動的に請求することがさらに知られている。たとえば、２００１年１月１６日にＦｒｕｅｃｈｔｅｌに付与された米国特許第６，１７５，８２５号（「‘８２５特許」）は、運送業者の個々の輸送サービス料金予定表に基づいてデビット決済し、種々の運送業者のサービスの業務を中央で会計し、輸送サービスを個別にあるいは合算してデビット決済するために方法を提供する。‘８２５特許では、ユーザプログラムが、プリンタおよび通信ユニットを備える修正された郵便料金計算機にロードされ、そこから１つの運送業者の少なくとも１つのサービス料金テーブルが選択可能である。ある出荷品の重量あるいはいくつかの他の物理量が修正郵便料金計算機に入力され、選択された出荷パラメータとともにその中でサービス値が計算される。修正郵便料金計算機のプリンタ装置は、少なくともその出荷品のための出荷料金を含む、出荷パラメータを含む識別票が印刷される。その出荷品を特定する情報は修正郵便料金計算機に格納され、その出荷品の実施された値識別情報は、個別にあるいは合算して、電気通信接続を経由してリモートデータセンターに送信される。データセンターにおいて受信されたデータは収集され、編集されて、会計プログラムを用いて各運送業者に対して個別に会計され、データセンターにおいて送り状が準備され、その送り状は支払いのために輸送計画管理者に送られる。
【０００９】
【発明が解決しようとする課題】
商品の輸送管理を支援するために、これらのツールあるいは他のツールが現時点において利用可能であるにもかかわらず、現代の輸送計画および管理が複雑であるために、輸送計画管理者は誤りを犯し、結果として最適でない輸送の判断を下す危険性を抱えている。輸送計画管理者を支援するために、多くの組織が自動化された製品輸送管理システムに益々依存するようになっている。しかしながら、既知の自動化された製品輸送管理システムは一般に、複雑な荷動きを正確かつ効率的に計画し、管理することができないことを含む、多くの弱みを抱えている。
【００１０】
より理想的な製品輸送管理システムは、特に収益を拡大し、営業経費を削減し、さらに顧客満足度を向上させるであろう。これらの目標および他の目標を達成するために、より理想的な製品輸送管理システムおよび方法は、国内および国際輸送の両方において、出荷プロセスの実行を概ね自動化しなければならない。具体的には、より理想的な製品輸送管理システムは、その組織全体にわたる組織の全出荷要件を考慮し、かつ最適化しなければならない。さらに、そのような製品輸送管理システムは、輸送コストを削減し、かつ顧客満足度を向上させるために、入国、出国および施設間の荷動きを同時に最適化するための自由度を持たなければならない。具体的には、製品輸送管理システムによって、組織は、そのベンダーを直に協力し、サプライチェーン全体にわたって輸送を最適化できるようになる。またこの機能によって、組織は、その組織のビジネス要件およびコストに基づいて、クロスドックおよび集配場所（すなわち、輸送の拠点および経由地）を動的に選択できるようになるであろう。さらに、理想的な製品輸送管理システムは、注文を送り元から送り先までの数多くの多様な注文の小口の出荷品にまとめる（ｐｏｏｌ．．．ｉｎｔｏ）ことを考慮し、個々の小口の出荷を最適化して規模の経済（ｅｃｏｎｏｍｉｅｓｏｆｓｃａｌｅ）を利用し、それにより多数の注文の出荷を同時に最適化しなければならない。そのような理想的な製品輸送管理システムは、仕掛け中の出荷品を自動的に較正し直し、最善のサービスおよびコストの判断を自動的に下すために各経由地を考慮できなければならない。
【００１１】
さらに、理想的な製品輸送管理システムによれば、組織は、インターネット、イントラネットあるいは別形態の電子媒体通信（たとえば、標準型電子データ交換、すなわち「ＥＤＩ」）を通して輸送業者とより直に連絡を取り合うことができるようになる。このようにして、組織は輸送業務を自動化し、電子情報を介して輸送業者と協動し、リアルタイムに顧客サービスを改善し、かつ輸送要件全体をより最適化することができる。たとえば、公共輸送手段との統合を改善することにより、連続して移動させる機会を促進し、その場合には、輸送業者は第１の場所において配送を完了し、第１の場所への途中に、引き続き第２の場所に移動するように連絡を受け、第２の場所から輸送貨物を集荷し、それを第３の場所に配送する。
【００１２】
さらに、輸送業者と電子媒体を介して通信することができる理想的な製品輸送管理システムによって、組織はリアルタイムに出荷品の位置を特定し、それ応じて、後続の電子課金システムを更新し、起動できるようになる。この機能によってさらに、製品輸送管理システムは、出荷品の状態を監視し、予期せぬ遅延あるいは出荷品の紛失のような、あらゆる不測の事態を組織に警告できるようになる。このようにして、組織はできる限り迅速に対応措置をとることができる。輸送業者の遂行状況を自動的に監視することにより、製品輸送管理システムは、ある特定のルートあるいは輸送業者に関連する不測のコストあるいは遅延のような、実績輸送データに基づいて、これから先の輸送判断を動的に調整することもできる。その後、製品輸送管理システムは、それ以降には改善された輸送判断を行うことができる。輸送業者と直に連絡を取り合うことにより、製品輸送管理システムはさらに、輸送請求書を受け取り、その料金を支払い、適当な依頼主に、荷動きのコストに対して、適当に割り振られた額を請求することもできる。輸送の支払いおよび課金を自動化することにより、さらに支払いが正確に行われ、輸送コスト全体が削減される。
【００１３】
【課題を解決するための手段】
上記の要求および他の要求に対応して、本発明は、組織および依頼主が利用できるサービスを増加するとともに、出荷サイクル時間およびコストを低減するために有用な、電子出荷および輸送計画、実行ならびに運送料支払管理プログラムおよび関連する方法を提供する。本発明の第１の実施形態によれば、組織は、非常に細かい注文要求およびビジネス規則のモデル化および管理を容易にし、それらの注文要求およびビジネス規則にしたがって最もコストの低い輸送問題解決手法を特定することにより、輸送業務を完全に最適化できるようになる。さらに、本発明の第２の実施形態によれば、組織は、選択された輸送問題解決手法の実施および管理を容易にすることにより、輸送業務を完全に最適化できるようになる。さらに、本発明の第３の実施形態によれば、組織は、輸送業者のコストを特定し、その輸送業者コストに対して適当に割り振られた額を適当な依頼主に請求することによって、荷動きコストの管理を容易にすることにより輸送業務を完全に最適化できるようになる。最後に、本発明の好ましい実施形態によれば、組織は、最適化された荷動きの計画、計画された荷動きの実行、および完了した荷動きに対する料金の支払および回収の管理を統合することにより、輸送業務を完全に最適化できるようになる。
【００１４】
第１の実施形態によれば、本発明による電子出荷および輸送計画管理プログラムおよび関連する方法は、３つの主な領域に関連する大きな一群の情報、すなわち、商品を出荷するための依頼主の希望を詳述する注文情報（発り元および送り先、時間帯、所望の輸送のタイプ等）と、輸送サービス提供業者が、提供する意志があり、提供することが可能なサービスを詳述する輸送業者情報（輸送のタイプ、価格等）と、実現不可能な解決手法を記述する制約情報（時間帯、能力、ビジネス目標等）とを自動的に処理する。このデータ処理は各注文に対して１つあるいは複数の出荷問題解決手段を生み出し、これらの解決手法は、依頼主の出荷業務を実行するために、特定の輸送業者および設備を含む、代替の荷動きを提案する。これらの提案された各荷動きに対するコストが、各注文のための最もコストの低い解決手法を特定し、かつ選択するために計算される（あるいは「見積もられる」）。
【００１５】
第２の実施形態によれば、本発明の電子出荷および輸送実行管理プログラムおよび関連する方法は出荷要求を輸送業者に自動的に提出し、同様に電子媒体を介して送信されることが好ましい、それらの輸送業者からの受諾の監視を自動化する。さらに本発明の好ましい実施形態では、電子実行管理プログラムは、出荷品の状態および位置に関する、電子情報による更新情報を受信し、これらの更新情報を中央実行データベースに格納する。これらの状態および位置情報はその後、計画された荷動き、実行済みの荷動きあるいは途中の荷動きに関して、顧客、物流センター等に送信されることができる。さらに、そのような好ましい実施形態では、このデータベースに格納される情報は、外部の輸送業者の遂行状況、自己保有の輸送手段の遂行状況および設備を追跡し、これから先の輸送問題解決手法を改善するために用いられることができる。
【００１６】
第３の実施形態によれば、本発明の電子出荷および輸送実行管理プログラムおよび関連する方法は、完了した荷動きに対する料金の支払および回収を自動的に許可する。
【００１７】
本発明の好ましい実施形態は、サプライチェーン内の商品の輸送の計画および管理を容易にするコンピュータネットワークおよび関連する方法である。本発明のさらに好ましい実施形態は、上記のように３つの重要なビジネス活動、すなわち最初の集荷場所と最後の配送場所との間の荷動きの計画と、自己保有輸送手段および公共輸送手段の両方による、その計画された荷動きの管理および実行と、出荷に要した全てのコストの発生、勘定報告およびその後の支払いとを概ね自動化し、統合する。
【００１８】
本発明の電子輸送管理プログラムのそのような好ましい実施形態では、ネットワーク化されたモジュールの形態をとる、３つの個別ではあるが、統合される電子管理プログラムが、上記のビジネス活動のそれぞれ１つを実行する。問題解決プログラムモジュールの形態をとるルート計画管理プログラムは、本明細書に記載されるような複雑な積荷構成アルゴリズムを用いて、種々の可能性のあるルートおよび中継場所の流れ、輸送方式、および輸送業者からの実現可能性のある代替の荷動きを特定し、比較する。未決の輸送注文に関してオプションの判断を下すために問題解決プログラムが用いる判断規則および情報は、そのシステムのために輸送計画管理者が確立するビジネスパラメータと、外部あるいは自己保有の輸送手段によって提供される輸送手段の利用可能性および料金表情報とから導出される。輸送管理者によって提供される情報は、たとえば、その管理あるいは特定の企業が従う方針および業務要件を含む場合がある。この情報を全て用いて、問題解決プログラムは、種々の計画判断を実行し、その後、最適な輸送計画に達する。問題解決プログラムは、種々の注文および出荷を輸送荷物に統合する場合がある。その際、最良の出荷方式（輸送手段、輸送手段のタイプ、ルート等）と、配送時間要件を満たすルートとに関して、各荷物に対して判定がなされ、他のビジネス制約が構成される。その後、計画された荷動きを実施するために、最もコストが低い代替形態が特定される。上記の機能全体を通して、問題解決プログラムは、最も効率的な荷物の統合を生成し、注文および輸送管理プログラムに課せられる制約の中で、最もコストの低い輸送業者および自己保有の輸送手段を割り当てる。
【００１９】
さらに、問題解決プログラムの計画問題解決手法が生成された後に、輸送管理者は、必要に応じて、あるいは所望により、特定の荷動きを手動で検討し直し、修正することができるか、あるいは別法では、その特定の荷動きから構成される問題解決プログラムの出力を電子輸送問題解決実行手段に転送することができる。
【００２０】
電子実行管理プログラムは、輸送業者への出荷要求の提出を自動化し、それらの輸送業者からの、同様に好ましくは電子媒体を介して送信される受諾の監視を自動化する。さらに、本発明の好ましい実施形態では、電子実行管理プログラムは、出荷品の状態および位置に関する電子更新情報を受信し、それを中央実行データベースに格納する。その後、この状態および位置情報は、計画された荷動き、実行済みの荷動きあるいは途中の荷動きに関して、顧客、物流センター等に送信されることができる。さらに、好ましい実施形態では、このデータベースに格納される情報は、それ以降の輸送問題解決手法の計画を改善するために、外部輸送業者の遂行状況、自己保有輸送手段の遂行状況、および設備を追跡するために用いることができる。
【００２１】
運送料支払管理プログラムは自動的に、輸送業者に要したコストを会計し、そのコストを適当な注文に割り振り、全ての実行済みの荷動きに対する支払いあるいは送り状を許可する。
【００２２】
本発明の実施形態のうちの任意の一実施形態では、フロントエンド・ユーザ・インターフェースによって、輸送計画管理者は１つあるいは複数のデータベースと対話し、複数の意思決定アルゴリズムを定義して、電子管理プログラムをカスタマイズし、組織に関する輸送計画管理者の専門知識を活用できるようになることが好ましい。さらに、フロントエンド・ユーザ・インターフェースによって、輸送計画管理者は、各出荷注文のためのファイルを検討し直し、修正できるようになる。
【００２３】
本発明の輸送計画能力は企業全体に拡張することができるか、あるいは別法では、一企業の特定の地理的地域に対して局所的に用いられることができることは当業者には容易に理解されよう。たとえば、輸送計画は依頼主の物流チェーンの全ての場所に対して中央で行われることができるか、あるいは別法では、各工場または物流センターにおいて局所的に行われることができる。当然、本発明は、計画が最初に中央の場所で実行されるが、その後（中央の輸送管理者ではなく）各地の計画者がその輸送計画全体を最終的に検討し直し、承認するように融合して処理されるように用いることができる。
【００２４】
本発明のさらに多くの特徴および利点は以下の説明に記載されており、一部はその説明から明らかであるか、あるいは本発明を実施することにより習得される場合がある。本発明の目的および他の利点は、特に書面による説明およびその特許請求の範囲、ならびに添付の図面において指摘される構造によって理解され、獲得される。
【００２５】
上記の全般的な説明および以下に記載される詳細な説明は典型的なものであり、かつ説明を目的としており、特許請求の範囲に記載される本発明を補足して説明することが意図されていることは理解されたい。
【００２６】
【発明の実施の形態】
添付の図面は、本発明の理解を深めるために添付され、本明細書に援用され、かつ本発明の一部を構成しており、本発明の実施形態を図示し、その説明とともに本発明の原理を説明するための役割を果たす。図面においては、類似の参照番号は全体を通して対応する部品を表している。
【００２７】
ここで本発明の好ましい実施形態が詳細に参照され、その例が添付の図面に示される。
【００２８】
図面に示されるような本発明の電子輸送管理プログラムの好ましい実施形態では、３つの個別ではあるが、統合される電子管理プログラムが、図２の流れ図によって示されるようにして上記の輸送活動を実行する。この好ましい実施形態の各管理プログラムは図３〜図５に示されるようなネットワーク化された管理プログラムモジュールの形で具現される。具体的には、図２を参照すると、出荷注文が受信された後（２０１）に、ステップ２０２において、第１の管理プログラムモジュール、すなわち図３の問題解決プログラム（「ＰＳ」）モジュール３００が、最初の集荷場所と最後の配送場所との間の最適な荷動きを計画する。次にステップ２０３では、ステップ２０２において計画された最適な荷動きが、自己保有輸送手段あるいは公共輸送手段のいずれか、または両方を用いて実行されるように、第２の管理プログラムモジュール、すなわち図４の実行（「ＥＸ」）モジュール４００によって実行される。最後に、ステップ２０４では、第３の管理プログラムモジュール、すなわち図５の運送料支払（「ＦＰ」）モジュール５００が、実行済みの荷動きのために要したコストを会計し、ステップ２０１において受信された注文にコストを割り振り、会計され、割り振られた、全ての荷動きに要したコストのための支払いあるいは送り状の送付を許可する。
【００２９】
図２は、計画された最適な荷動きが何らかの理由によって実行できなかった場合に（このような理由の例は後述する）、オプションで、その実行されなかった注文が第１のモジュールに戻され（２０３ａ）、新たに受信された注文と組み合わされ、ステップ２０２において新しい最適な荷動きの計画に組み込まれるようになることを示す。図２のステップ２０３ａおよび接続用矢印は、この流れがオプションであることを表すために破線で示される。
【００３０】
図３、図４および図５の組み合わせによって示されるように、ＰＳモジュール３００、ＥＸモジュール４００およびＦＰモジュール５００は、特定の出荷のためのルートおよび輸送手段を計画することから、その出荷の配送を管理し、出荷が完了した後に顧客にその注文に対する出荷コストを請求することまでの様々な輸送注文を取り扱うために、電子媒体により接続され、協動することが好ましい。これらの機能を最適に実行するために、これら３つのモジュールは全て、図３〜図５に開示されるような種々のインターフェースおよび情報フローを必要とする。その情報フローおよび関連するインターフェースがここで詳細に説明されるであろう。
【００３１】
図３は、本発明の実施形態による輸送問題解決プログラムモジュール３００の情報フローおよびインターフェースを概略的に示す。図に示されるように、ＰＳモジュール３００は、公共輸送手段３２２、顧客３２０、営業所あるいは関連会社３１８、倉庫３１６、クロスドック３１４および物流センター３１２（これ以降、倉庫、クロスドックおよび物流センターはまとめて「場所」と呼ばれる）からの情報入力を受信する。輸送手段インターフェース３０５は、その輸送手段によって提供される輸送サービスのタイプおよびそれらの輸送サービスに対して請求される料金に関連する、公共輸送手段からの情報を、好ましくはＥＤＩあるいはウエブを経由して電子情報として受信する。この情報は、移動経路、設備タイプ、ならびにこれらの経路および設備タイプのための料金を含み、実現可能性のある配送問題解決手法を算定し、その解決手法の各ルートに対して予想される輸送コストを計算して、最適化された解決手法を特定するのに用いるために、ＰＳデータベース３０２に格納される。
【００３２】
図３に示されるように、問題解決プログラムモジュール３００への主な入力は注文インターフェース３０６を介して、顧客３２０および／または営業所３１８から受信される注文である。輸送手段インターフェース３０５と同様に、注文インターフェース３０６は、たとえばウエブあるいはＥＤＩを通して、電子情報として注文情報を受信することが好ましい。注文インターフェース３０６を通して受信された注文は一対の送り元／送り先を有する。さらに、各注文は、集荷および配送に対してその注文をスケジューリングするために問題解決プログラムが必要とする全ての情報を含む。この情報は概念的に、ヘッダ情報、出荷単位情報およびルート指定情報を含む３つの部分に分割されることができる。ヘッダ情報は、たとえば、注文が受信された時刻および場所を特定する管理データを含む。出荷単位情報は、輸送されることになる製品のタイプ、その製品の物理的な寸法（長さ、幅、高さを含む）、単位数および各単位の重量を特定する。ルート指定情報は、詳細な送り元および送り先の場所、ならびに集荷および配送のための時間帯を提供する。
【００３３】
集配場所インターフェース３０７は、集配場所（３１２、３１４、３１６）に同様に電子媒体を経由して接続されることが好ましく、集配場所が新たな商品を在庫することができるか否か、および現在の在庫中の商品の量を含む、集配場所が注文を取り扱うための能力に関連する、新しい、かつ／または修正された情報を直に提出するための機構を、輸送ネットワークあるいはサプライチェーン上の遠隔地に提供する。問題解決プログラムロジック３０１は、全てのこれらの情報ストリームを取り込み、最適化バッチが実行されるときに後で用いるために、その情報ストリームを中央ＰＳデータベース３０２に格納する。さらに、管理者インターフェース３０４によって、中央の輸送管理者３０９あるいは管理責任者が、データベース３０２にさらに格納されるプロセスあるいは業務規則も設定できるようになる。問題解決プログラムモジュール３００において最適化バッチが実行される度に、ＰＳデータベース３０２に格納される輸送手段の注文場所および管理規則に関する現在の情報がアクセスされ、全ての注文がいくつかの編成された代替ルートを有するように（物理的に２つ以上のルートを取り得る場合）、実現可能性のある種々の輸送配送問題解決手法を編成するために利用される。その後、問題解決プログラムロジック３０１は、ＰＳデータベース３０２に格納される輸送業者料金表を用いて、各代替ルートのための予想されるコストを計算し、各注文の場合の最もコストの低いルートを、その提案される最適化された解決手法として選択する。これらの提案される最適化された解決手法は、「ルート指定注文」３１１として知られており、ルート指定注文インターフェース（「ＲＯＩ」）３０３を経由して、後続のシステム（あるいは別法では、輸送計画管理者が、提案される解決手法に手動で入力したい場合には、管理者インターフェース３０４を介してその管理者に直に）に送信される。問題解決モジュール３００の主な出力は、ルート指定注文インターフェース３０３である。本発明の好ましい実施形態による後続のシステムは、本明細書に開示されるような、図４の実行モジュール４００および図５の運送料支払モジュール５００を含む。
【００３４】
以下に記載されるように、問題解決プログラムロジック３０１は、注文を分割することができるアルゴリズムを用いて、まとめて出荷するために注文を組み合わせ、その後、最適化された輸送計画を構築し、問題を解決し、ＰＳデータベース３０２に格納して、輸送計画者が能動的に対話することなく、ルート指定注文インターフェース３０３を介してその提案される解決手法を提供する。問題解決プログラムモジュールの各バッチ実行処理は、自動的に実行されるように輸送計画管理者３０９によって構成されることができる。バッチは、予め設定された時刻、またはある特定の注文のダウンロードが完了した時点で実行されるように起動することができるか、あるいは特定の同一時刻表に対して予め設定されたスケジュールにしたがって実行されるように構成されることができる。大部分の問題解決プログラムロジック３０１のバッチ実行処理は、注文インターフェース３０６を介して、１つあるいは複数の新たな注文が到着することにより起動されることになることは当業者には容易に理解されよう。問題解決プログラムロジックのバッチ実行処理は、あるイベントの発生時に、あるいは指定された間隔で自動的に、あるいは輸送管理者によって手動で開始される場合にのみ、行われるようにスケジューリングすることができることにより、本発明の自由度がさらに大きくなる。
【００３５】
図３には示されないが、問題解決プログラムモジュール３００は距離インターフェースを設けられることもできる。輸送業者によって見積もられる料金は、その注文が輸送されなければならない距離に依存することは当業者には容易に理解されよう。それゆえ、この目的を果たすために、問題解決プログラムロジック３０１は、各注文の場合に見積もられる送り元と送り先との間の距離を判定するための方法を必要とするであろう。それゆえ、ＰＳモジュール３００は、ＭｉｌｅＭａｋｅｒあるいはＰＣ＊Ｍｉｌｅｒのような距離計算プログラムと電子媒体を介して通信するための距離インターフェースを用いることができる。
【００３６】
ルート指定注文インターフェース３０３は、１つあるいは複数の荷動きから構成され、問題解決プログラムロジック３０１によって構築される、提案される最適化された輸送計画を詳述する単層ファイルを出力することが好ましい。この最適化された輸送計画は、配送ルートの各区間において生じる、配車時間、予想される戻り時間および予想される待ち時間を含む、ルート（各注文に対して少なくとも１つのルート）の詳細なスケジュールを含む。さらに、その単層ファイルは、各出荷品に対して選択された輸送業者と、中継場所間の予想される移動距離および時間と、各輸送業者によって請求されることが予想されるコストとを含む。先に説明されたように、別の実施形態では、ルート指定注文インターフェース３０３によって提供される単層ファイルはオプションで、検討し直すために輸送管理者に直に（ハードコピー形式で、あるいはＲＯＩ３０３または管理者インターフェース３０４を介して、ＧＵＩに基づくコンピュータによるインターフェースで）提供されることもできる。
【００３７】
しかしながら、図３〜図５に示されるような本発明の好ましい実施形態によれば、ルート指定注文インターフェース３０３は、ルート指定注文３１１を含む最適化された輸送計画ファイルを、図４に示されるようなＥＸモジュールの未実行注文インターフェース４０３を経由して実行モジュール４００に直に提供する。ルート指定注文インターフェース（「ＲＯＩ」）３０３は、他のシステムによって用いるための荷動きに関する情報を出力する。ルート指定注文インターフェースによって提供される各荷動きは状態コードに関連付けられる。本特許出願の最後に添付される付属書１は、ＰＳデータベース３０２、ＥＸデータベース４０２、およびＦＰモジュール５００の運送料支払データベース５０２内の各注文および／または荷動きのデータベース記録に添付されることができる状態コードの表を含む。
【００３８】
実行ロジック４０１は実行管理データベース４０２にルート指定注文を格納する。図４から明らかなように、実行モジュール４００は、請負インターフェース４０７を介して輸送業者３２２に接続される。実行モジュール４００は請負インターフェース４０７を用いて、問題解決プログラムモジュール３００によって選択されたような、ルート指定注文インターフェース単層ファイルに掲載される輸送業者に請負提示（出荷サービスのための正規の要求）を送信する。問題解決プログラムモジュール３００によって用いられる各輸送業者は、請負インターフェース４０７を介して実行モジュール４００に電子媒体によって接続され、請負提示（および以下に記載されるような、その後の受諾あるいは辞退）が、ＥＤＩ、電子メールあるいはウエブを介して、補足説明を付けて電子情報として送信されることができるようになることが好ましい。別法では、当然、ファクシミリあるいは電話のような手段が用いられることができる。
【００３９】
一旦受信されたなら、輸送業者は請負申込書を検討し直し、その請負提示の受諾あるいは辞退を、応答インターフェース４１２を介して、実行モジュール４００に電子情報として提供することができる。その後、実行モジュール４００は、未実行荷動きインターフェース４１０を介して、未実行注文４１１として問題解決プログラムモジュール３００に戻される全ての辞退された注文のルートを指定し直し、ＰＳモジュールが異なる輸送業者あるいは輸送問題解決手法を選択できるようにする（この入力は図３には明示されない）。
【００４０】
さらに、実行モジュール４００は、輸送業者３２２（外部あるいは自己保有の両方）と、倉庫３１６と、クロスドック３１４と、物流センター３１２とによって用いられるための出荷品状態インターフェース４０６を含む。出荷品状態インターフェース４０６を経由して実行モジュール４００に転送される情報は、そのルートが出発することを輸送業者が予想する時刻、そのルートが物流センターを出発した時刻、ルートが特定のクロスドックあるいは倉庫に到達した時刻、および輸送業者端あるいは集配場所端のいずれかにおいて予想される遅れを含む、配送あるいはルートに対してスケジューリングされる出荷についての情報を伝達する。実行モジュール４００は、この出荷品状態情報を用いて、図に示されるように顧客状態インターフェース４０８を介して顧客３２０あるいは営業所３１８に更新情報を提供することができるか、あるいは図に示されるように運送料支払インターフェース４０５を介して運送料支払モジュール５００に実行済み注文情報４０９を送信することにより、運送料支払モジュール５００の会計および送り状発行機構を起動することができる。貸切トラック（「ＴＬ」）出荷品、積合せトラック（「ＬＴＬ」）出荷品、小口貨物出荷品、急行便出荷品および他の出荷品タイプ（これらの出荷品タイプは以下に詳細に説明される）が必ずしも、実行モジュール４００からの同じ機能を必要とするとは限らないことは容易に理解されよう。たとえば、小口貨物および至急便出荷品は多くの場合に、輸送業者の請負受諾／辞退取引を使用せず、それゆえ、図４のインターフェース４０７および４１２を用いないであろう。
【００４１】
ＥＸモジュール４００の請負インターフェース４０７は、未実行注文インターフェース４０３を介してＲＯＩ３０３からＥＸモジュール４００に提供される同じ情報の大部分を含む請負提示を出力するが、請負提示ファイルは電子商取引翻訳プログラム（たとえばＥＤＩ）によってさらに容易に取り扱うことができるように線形構造に編成される。請負提示メッセージは、輸送業者の請負を必要とするスケジューリングされていない新たな注文がＲＯＩ３０３から受信される度に、ＥＸ請負インターフェース４０７を介して各輸送業者に送信される（そのような注文は、電子請負提示を受諾する輸送業者によって遂行されることができるものと仮定する）。ある特定の選択された輸送業者が電子請負に参加しない場合には、ＥＸモジュール４００は、そのような輸送業者のための新たなルート指定注文が受信される度に、そのような輸送業者にファクシミリの請負提示を自動的に送信するか、あるいは輸送計画管理者３０９に通知するように構成されることができる。上記のように、そのような請負提示の受諾あるいは辞退は、応答インターフェース４１２を介して電子情報として受信されることができる。輸送業者が請負提示に電子情報による応答（受諾あるいは辞退）を送信しない場合には、そのような応答は従来どおりに（電話、郵便、ファクシミリ等）、輸送計画管理者に対して行われることができ、その後、輸送計画管理者によって手作業で管理者インターフェース４０４に入力されることができる。
【００４２】
図４に示されるようなＥＸ出荷品状態インターフェース４０６は、積荷あるいは出荷が途中である間に積荷あるいは出荷に関して、出荷品状態メッセージを、輸送業者３２２、物流センター３１２、倉庫３１６およびクロスドック３１４などからＥＸモジュール４００に配信する。これらの状態メッセージは、定刻に対する予期する到着の進みあるいは遅れ、出荷品の定刻通りの受取り、あるいは出荷品の完了および／または解約のような更新情報を含むことができる。そのようなメッセージが輸送業者からリアルタイムに送信されるとき、これらのメッセージは、ＥＸモジュール４００内の警告の発生を制御するために用いることができる。たとえば、そのような警告を用いて、管理者インターフェース４０４を介して輸送管理者３０９に、あるいは顧客状態インターフェース４０８を介して営業所３１８または顧客３２０に、出荷品状態通知を送信することができる。
【００４３】
実行管理（「ＥＸ」）モジュール４００は、請負提示の自動化された輸送業者３２２への通知、それらの請負提示の受諾に関する輸送業者からの応答の受信、輸送中の積荷の状態に関する顧客および集配場所への通知、輸送業者の遂行状態に関する追跡、荷動きの遅れに関する警告の発生、および運送料支払インターフェース４０５を経由する実行済み注文４０９の出力を含むいくつかの管理者用機能を実行する。ＲＯＩ３０３と同様に、運送料支払インターフェース（「ＦＰＩ」）は、実行済みの（すなわち、完了した）荷動きを特定する単層ファイルを出力する。ＦＰＩ出力はさらに、ＲＯＩ単層ファイルを介してＥＸモジュール４００に供給された情報の大部分に加えて、荷動きが完了した時刻のような情報を含む。ＲＯＩの場合と同じように、この好ましい実施形態の別の実施形態では、ＦＰＩ４０５から出力される単層ファイルはオプションで、検討し直すために輸送管理者に直に（ハードコピー形式で、あるいはＦＰＩ４０５または管理者インターフェース４０４を介してＥＸモジュール４００と通信するように構成される、ＧＵＩに基づくコンピュータによるインターフェースで）提供されることもできる。
【００４４】
図５に示されるような運送料支払モジュール５００は、特定の荷動きが完了される度に、実行済み荷動きインターフェース５０４を介してＥＸモジュール４００からこの実行済み注文４０９の単層ファイルを受信する。その後、運送料支払（「ＦＰ」）ロジック５０１が、輸送業者３２２から（輸送手段が賃借りする公共輸送機関であった場合）、輸送業者請求インターフェース５０５を介して好ましくは電子情報として受信される送り状を処理し、所与の注文がどこを起点にしたかに応じて、出荷コストを顧客３２０あるいは営業所３８１に割り振る。その後、処理された送り状は、問題解決プログラムモジュールによって予測されるコスト（これらのコストはＥＸデータベース４０２に格納され、荷動きの完了時にＦＰデータベース５０２に格納するためにＦＰモジュール５００に渡される）と比較され、この比較結果は、後に分析するために格納される。その後、最終的に集金するために、送り状は顧客３２０あるいは営業所３１８に渡されることができる（顧客送り状インターフェース５０８を介して電子情報で渡されることが好ましい）。
【００４５】
さらに、ＦＰモジュール５００は、支払勘定インターフェース５０７および受取勘定インターフェース５０６を含む。このようにして、送り状が処理され、コストが割り振られるとき、輸送管理者の企業の支払勘定および受取勘定が運送料支払モジュール５００によって自動的に更新される。
【００４６】
図５に示されるように輸送業者に電子媒体を介して（たとえば、ＥＤＩを介して）接続されるとき、運送料支払モジュール５００は、完了した荷動きに対して、輸送業者への支払いを自動的に許可する。ＦＰモジュールは、予想される出荷コスト（ＰＳモジュールによって輸送業者の料金表から決定される）、輸送業者の送り状、あるいは配送通知のいずれかに基づいて支払伝票を生成する。その後、これらの伝票は、図５に示されるような支払勘定インターフェース５０７を介して支払勘定システム（図示せず）に送信される。当然、ＦＰモジュールは、ＦＰデータベース５０２内の記録を更新するために、支払勘定および受取勘定システム（図示せず）から戻される支払済み情報を受信するように容易に構成されることもできる。さらに、割り振られた荷動きコストのための送り状は、顧客送り状インターフェース５０８を介して顧客３２０および営業所３１８に送信されることができ（輸送業者によって請求される料金の支払いを要求するため）、一方、支払勘定記録が、受取勘定インターフェース５０６を介して会計システムに自動的に送信されることができる。
【００４７】
ここで、問題解決プログラムロジック３０１、実行ロジック４０１および運送料支払ロジック５０１が、図６〜図８の流れ図に関して詳細に説明されるであろう。図６は、本発明の１つの好ましい実施形態にしたがって実行される処理ステップ全体を示す流れ図であり、問題解決プログラムモジュール３００、実行モジュール４００および運送料支払モジュール５００が、輸送業者から料金表情報を収集し、かつ顧客から注文を受信する段階から、注文が果たされた場合にその依頼主に送り状を発行する段階まで様々に、輸送管理を完全に取り扱うことができる統合ネットワークを形成するように編成される。以下に記載される説明から明らかになるように、図６のステップは、ＰＳモジュールがステップ６０１〜６０３によって必要とされる動作を実行し、ＥＸモジュールがステップ６０４〜６０８によって必要とされる動作を実行し、ＦＰモジュールがステップ６０９によって必要とされる動作を実行するように協動して、３つの上記のモジュールによって実行される。
【００４８】
先に全般的に記載されたように、ＰＳロジック３０１は、所与の時点でルートを指定し、その際の種々の出荷のためのコスト見積額を提供するために、種々の入力を考慮に入れる。この好ましい実施形態の問題解決プログラムロジック３０１は、特定の注文のための解決手法としてネットワークを通して全ての実現可能なルートを逐次的に検討するのではなく、ユーザの輸送ネットワークの知識を活用するように構成される。図６を参照すると、問題解決プログラムロジックが未決の輸送注文に関して最適な判断を行うために使用する、判断を下す規則および情報が、問題解決プログラムロジックによってバッチプロセスが実行される前に（すなわち、任意の注文がステップ６０２において絶え間なく受信される前に）、まずステップ６０１において定義される。問題解決プログラムロジックによって用いられる規則および情報は、システムおよび輸送業者のサービスの利用可能性と、外部あるいは自己保有の輸送手段によって提供される料金表情報（以下に説明される）との場合に輸送計画管理者が確立するテンプレートおよびビジネスパラメータの組み合わせである。たとえば、輸送計画管理者は、管理者インターフェース４０４を用いることにより、ルート計画規則を定義するか、多区間ルートおよび多形態ルートのための区間を定義するテンプレートを作成するか（そのようなテンプレートの入力は、バッチ実行処理の前にステップ６０１において行われるが、図７のステップ６０３に関して、具体的には多区間ルートに関して以下に詳細に説明されるであろう）、あるいはその特定の企業が従う方針あるいは業務要件を強制するための制約を入力することができる。一旦、問題解決プログラムが最適な輸送計画を編成し始めたなら、この情報が全て考慮に入れられる。
【００４９】
本発明の好ましい実施形態によるＰＳロジックは、輸送計画管理者によって設定される規則の中で輸送注文を遂行することができる全ての適当な荷動きのルートを指定する。本発明の特に有利な特徴は、最もコストが低いことが最重要の考慮すべき事柄ではないときに、ＰＳデータベースにおいて、輸送計画管理者が積荷および荷動きの作成を支配できるようにする優先ルート指定規則を用いることを含む。典型的には、各注文のための全ての実現可能性がある適当な荷動きを特定した後、ＰＳロジックは最もコストが低い輸送解決手法を特定する。しかしながら、この解決手法は、１組の顧客サービス要件と、実現可能性がある輸送解決手法の領域を制限する優先ルート指定規則とによって縛られる。これらのルート指定規則は、集荷および配送に利用することができる、その日のうちの時間を指示する時間帯と、輸送業者によって期待される遂行能力のレベルを指示する輸送業者の格付けと、多区間ルートの場合の注文の集荷および配送の流れと、特定の場所にサービスを提供するために適合する設備タイプと、ある特定の物質タイプ（たとえば、危険物）の輸送を規制する連邦および／または州規定などを含むことができる。
【００５０】
さらに、ステップ６０１では、ＰＳロジックは、各輸送業者タイプの場合の料金と、各輸送業者タイプ内の各輸送業者とを受信する。これらの料金は、バッチ実行中に用いるためのＰＳデータベース４０２に格納される複数の料金表において規定される。そのような料金表は、貸切トラック（「ＴＬ」）、積合せトラック（「ＬＴＬ」）、小口貨物および小包輸送業者（両者を「小包輸送業者」と呼ぶ）、鉄道、航空機、および海上輸送業者を含む、各輸送業者タイプに対してＰＳデータベースに格納される。ＰＳモジュールの見積りの態様に関して以下に提供される開示（図７のサブステップ７０４）は、先に掲載された輸送業者タイプのいくつかの場合のサンプルの出荷コスト見積り表を説明するであろう。
【００５１】
ＰＳモジュールによって用いられるようなバッチアプリケーションは、それらが、多数の利用可能性のある輸送業者を通して出荷されることができる大きな一群の注文のような、複雑な問題の全体を見ることができ、１回限りの低コストの解決手法を作成することができるという意味で有力である。しかしながら、ある時点で、輸送計画管理者は、ＰＳロジック３０１が荷動きの計画を作成するためのバッチプロセス（図６のステップ６０３）を開始することになるタイミングを判断しなければならない。典型的には、ＰＳモジュールは、一旦、ある一定量の注文が受信された場合に（６０２）、バッチプロセスが実行され始めるように構成されるであろう。別法では、当然、輸送計画管理者が手動でステップ６０３を開始することを選択することもできる。
【００５２】
ＰＳロジックがステップ６０３においてそのバッチ実行処理を開始し、最適な荷動き計画（直前のバッチ実行以降に受信された全ての注文に対して）を作成するとき、ＰＳロジックは個別の流れ図として図７に詳細に示されるいくつかのサブステップを実行する。図７は、図６のステップ６０３が４つのサブステップとしてより具体的に記述できることを示す。ここで、本発明の好ましい実施形態によるＰＳロジックのバッチ実行を含むサブステップが図７に関して説明されるであろう。図６の残りのステップのさらに詳細な説明は、図７を全て説明した後に、戻って説明されるであろう。
【００５３】
バッチ実行中に、問題解決プログラムロジック３０１は最初に、サブステップ７０１において、種々の注文および出荷品を輸送積荷に統合する。その後、サブステップ７０２において、その積荷を輸送するための最良の出荷形態（輸送業者、設備タイプ、ルート等）に関して、各積荷の場合に判定が行われる。上記の計画サブステップを達成するために、そのシステムは、必要とされる荷動きを詳述するデータ、資源の利用可能性およびコストを項目別の列挙する表、その業界の業務要件、および企業の輸送計画管理者によって入力される全般的な企業規則および方針を含む種々のタイプの情報を用いる。出荷形態が選択された後に、ステップ７０３において、配送時間要件および他のビジネス制約を満たす多数の代替の荷動きが各積荷に対して構成される。その後、ステップ７０４において、最適な輸送計画に包含するために、各積荷を出荷するために最もコストの低い荷動きが特定され、選択される。上記の機能全体を通して、問題解決プログラムは最も効率の高い積荷の統合方法を生成し、注文および輸送計画管理者によって課せられる制約の中で、最もコストが低い輸送業者および自己保有輸送手段を割り当てる。
【００５４】
図７の全てのサブステップにおいて、本発明の問題解決プログラムモジュールは、ネットワーク内の全ての実現可能性のあるルートを考慮するのではなく、ユーザの輸送ネットワークの知識を活用するように構成される。輸送計画管理者は、区間に基づく会計のプロファイルを定義することにより（バッチ実行前の図６のステップ６０１において）、計画規則を設定し、多区間ルートおよび多形態ルートの場合の区間を指定する。たとえば、輸送管理者は、特定のバッチの流れが３区間のルートとして構成され、中間の区間が特定の鉄道輸送業者を用いて鉄道を介して実行されることを指定することにより、その企業の物流ネットワークに関する自分の知識を活用することができる。
【００５５】
実現可能な場合には必ず、ステップ７０３において、ＰＳロジックは各積荷について、特定の経路上の多区間ルートにしたがってルートを構成し、その後、計画規則によって設定される任意の経由地を通る２区間ルートを構成し、最後に、直接出荷を構成することを試みるであろう。多区間の移動を指定することに加えて、経由地が、適切な経路における任意の注文が最初に、可能ならその場所を通過するルートを指定されるように定義されることができる。経由地および多区間ルートの両方の場合に、ステップ７０３において示されるＰＳロジックプロセスによるこれらの計画規則の適用は、経路毎にのみ実行される（すなわち、１つあるいは複数の適用可能な経路に対して、１つの経由地あるいは多区間ルートだけが当てはまる）。
【００５６】
より具体的には、上記のような本発明の実施形態によれば、サブステップ７０１においてＰＳロジックは、共通の出荷および／または配送場所を有する注文に起因する配送の場合に、１つの所与のバッチにおいて種々の個別の注文を組み合わせることを考慮する。ＰＳデータベース内のある特定の出荷場所が、出荷集合体に属するものとして指定されることができる。これは典型的には、大企業が多数の物流センターあるいは工場所在地を有するが、価格および注文を統合するために、１つの所在地に注文を配送したい場合に相当する。こうして、そのような企業のある特定の工場所在地に向かうように指定される全ての注文は、その企業に属する任意の他の場所に向かうように指定される任意の他の注文と組み合わせられるであろう。このようにして、統合するのに適した注文がより容易に特定され、規模の経済が有利に利用される。
【００５７】
同様に、ＰＳモジュールは、大量の注文が一緒に出荷されるには大きすぎるときに（たとえば、その注文が１回のＴＬあるいはＬＴＬ出荷の１台のトレーラに詰め込むには大きすぎるため）、その大量の注文を１つあるいは複数の少量の注文に自動的に分割する。注文が分割されることから生じる全ての荷動きは、それらがＲＯＩを通してＥＸのような後続のシステムに送信されるときに、分割された注文としてタグを付けられるであろう。それゆえ、ＥＸはその際、運送料支払モジュールが荷動きに対して料金を割り振り、送り状を送付することができるように、２つの荷動きを組み合わせて、追跡および探索するために１つの注文記録にすることができる。
【００５８】
輸送業界において、数多くの輸送手段タイプが利用可能である。サブステップ７０２では、ＰＳロジック３０１は、ある所与の注文に対して最良の出荷形態を判定する。この判定は、商品の種類、積荷のサイズ／重量、および所望の配送スケジュールを含む多数の要因に依存する。典型的には、比較的遠方への配送スケジュールを有する大きく、かつ／または重い荷物は、商用あるいは自己保有の貸切トラック（「ＴＬ」）のいずれかにおいて輸送されることができ、一方、中間サイズあるいは中間重量の荷動きは、積合せトラック（「ＬＴＬ」）のスケジュールに合わせて、商用あるいは自己保有のトラック輸送手段を用いて達成されることができる。大中の重量あるいはサイズの荷動きは、鉄道による陸上輸送、場合によっては航空輸送によって行われることもできる。大中のサイズおよび重量の荷動きは、特に大陸横断出荷の場合には、運搬船を用いて行うこともできる。
【００５９】
より小さいサイズおよび重量の荷物は典型的には、標準的な小口貨物サービス（たとえば、米国郵便業務、ＵＰＳ等）か、あるいは急行便または終夜便サービス（たとえば、フェデラル・エクスプレス）かのいずれかを用いて出荷される。一般的に言うと、小口貨物、急行便および終夜便サービスの荷物の輸送料金は、配達の速さ（３日に対して翌日）、ならびに荷物のサイズおよび／または重量に応じて高くなる。ある注文を配送するためのタイムラインは、小包輸送業者を利用するか否かを考える際に、サブステップ７０２においてＰＳロジックによって考慮される主な要因の１つである。
【００６０】
さらに、一貫輸送手段のルートを形成するために、多くの場合に１つあるいは複数の輸送手段タイプが組み合わせて用いられる。典型的な例は、大きくて重い出荷品がＴＬ輸送業者を用いて物流センターから海港まで搬送され、その後、その海港から大西洋横断運搬船を用いて海上をグレートブリテンまで移動するようにスケジューリングされる場合であろう。
【００６１】
ＰＳロジックの見積りの態様（図７のサブステップ７０４）に関する以下の開示は、上記の輸送手段間の差をさらに示し、それゆえ、特定のカテゴリの注文要求の場合に、ある輸送手段タイプが別の輸送手段タイプよりも有利に用いることができるタイミングを指示できるようにするために、上記の輸送手段タイプのいくつかの場合のサンプル出荷コスト見積り表を開示するであろう。
【００６２】
各注文が特定のＰＳバッチにおいて処理される場合、サブステップ７０３においてＰＳモジュールは、特定の注文に対して、どの輸送手段（サブステップ７０２において選択された１つあるいは複数の形態）がサービスを提供することができるかを判定する第１の段階（ｃｕｔ）を実行する。サブステップ７０３は基本的に、サブステップ７０２において特定された資源を取得し、関連する経路の中で一致するものがあるか、輸送手段によって提供されるサービスを探索する。たとえば、ニューヨークからロサンゼルスまでトラック便で移動させる必要がある大きな積荷の注文は、米国南東部においてのみ営業されているＴＬ輸送業者を用いることはできないであろう。この第１の段階を実行する際に、ＰＳモジュールは、輸送業者が集配送のために利用することができる時間帯（たとえば、１週間にわたる１日の時間単位）と、注文、集荷および配送の時間帯と、注文の集荷および配送の流れ（多区間ルートの場合に、ある輸送業者が利用されている場所）と、その輸送業者がある特定の注文あるいは場所に対してサービスを提供するのに適した設備を有するか否か（その輸送業者が、傷みやすい食べ物を輸送するために冷蔵車を必要とする場合）と、地理的サービスエリアと提案される輸送ルートとの重なりと、適合性および／または不適合性の目的のための注文のグループ化とを考慮する。
【００６３】
さらに、サブステップ７０２では、ＰＳロジックは、ＬＴＬおよび小包出荷品をトレーラサイズ（すなわち、ＴＬ）の積荷に組み合わせ、倉庫におけるトレーラへの荷積みの効率を高めることを考慮する。出荷品は、経路に関連する場所である、ブレークバルク単位で輸送業者によってグループ化される。典型的には、ＰＳモジュールが標準的な輸送手段（ＴＬ、ＬＴＬ、小包等）に対する注文の初期の割当てを完了した後、トレーラ構成ＰＳロジックが適用される。その後、これらの標準的な輸送手段を用いて問題解決プログラムによって作成された外国向け出荷品が、このトレーラ構成ＰＳロジックに導入される。これらの事例では、出荷品は既に提案された輸送手段を有する。ＬＴＬおよび小包輸送業者に割り当てられる出荷品は、輸送業者、起点およびブレークバルクによってグループ化される。利用可能な適合するトレーラタイプが存在する場合には、同じ輸送業者、起点およびブレークバルクを有する出荷品は、それらがブレークバルクの最小量を超える場合には、そのトレーラに積まれることになる。さらに、トレーラ構成ＰＳロジックによって組み合わせられる出荷品のすべては、時間帯が重なり合わなければならないことは理解されたい。さらに、組み合わせられたトレーラに積まれる出荷のための商品は、互いに適合し、かつトレーラタイプと適合しなければならない。
【００６４】
そのように構成されたトレーラ積荷を含む荷動きの場合に、そのトレーラのための早い出発時刻が、その出荷品のための早い出発時刻のうちの最も遅い時刻に設定され、そのトレーラのための遅い出発時刻が、そのトレーラにおいて出荷するための遅い時刻のうちの最も早い時刻に設定される。その後、このプロセスを通して構成され、組み合わせられたトレーラは、ＰＳモジュールの見積りアルゴリズムに対して提案される１つの解決手法として提出される。組み合わせられた出荷が個々の出荷よりも優れたコスト削減を提供する場合には、その組み合わせられた出荷がＰＯＩを通して送信され、個々の出荷が破棄されか、あるいは逆もまた同様である。
【００６５】
先に全般的に記載されたように、ＰＳモジュールが一群の特定の注文の場合にサブステップ７０３においてある行程を構成する場合には常に、ＰＳモジュールは、その終点に直に移動する場合、１つの経由地を通って移動する場合（たとえばクロスドックあるいは物流センター）、および多数の経由地を経由して移動する場合（これ以降、多区間ルート、あるいは「ＭＬＲ」と呼ばれる）のそれぞれにおいて少なくとも一度だけその注文のルートを指定しようと試みる。その後、サブステップ７０４において、ＰＳは各行程に対するコスト見積りを作成し、どのルート指定方法が最もコストの問題を解決する手法を生成するかを判定する。
【００６６】
ＰＳモジュールにおいて受信される各注文は、出荷中の商品あるいは製品を格納するために用いられる方法を指示する梱包タイプを含むことが好ましい。これらの梱包タイプは、パレット、伝票用紙あるいは床積み（すなわち、ばらの箱）を含むことができる。この梱包タイプ情報は、適用可能な荷積み方法を決定する際にサブステップ７０３において問題解決プログラムによって後に用いられることができる。梱包タイプは、ある特定の荷積み方法が、中継場所において特定の運搬手段を荷積みあるいは荷降ろしするために用いられることができるか否かを必ず決定する必要があることは当業者には容易に理解されよう。たとえば、フォークリフトを用いてパレットを動かし、それにより荷積みおよび荷降ろし時間を削減することができるが、床積みはフォークリフトでは容易に動かすことができない。それゆえ、ＰＳモジュールは特定の出荷の場合に床積み梱包タイプに直面する度に、中継場所においてその特定の注文を荷積みおよび荷降ろしするのに長い時間を要し、それゆえそれに応じて、サブステップ７０３中にルート指定スケジュールを作成することを認識している。
【００６７】
多区間ルート（「ＭＬＲ」）の区間の提案はＰＳによって出荷経路に関連付けられ、輸送計画管理者が自分の組織の出荷要件の場合に特に効率的であると予想する経路内の、全ての注文に対するある特定のルートを表す。多区間ルートの荷動き（あるいはその一部）は、ある特定の荷動きが流れなければならない一連の経由地（クロスドック）を指定する。輸送計画管理者は、必要な場合には、会計プロファイルを各区間に関連付ける（たとえば、図６のステップ６０１において）。輸送計画のための従来技術のシステムおよび方法によれば、ある注文は、起点から終点までの途中に１つの経由地しか通過することができない。本発明は、そのサプライチェーンに関する組織内部の知識を用いることにより、この制約を克服する。
【００６８】
ＭＬＲを効率的に処理するために、全ての積荷の場合の全ての実現可能性のある多経由地ルートを考慮するのとは対照的に、ＰＳロジックは、ＰＳデータベースに格納されるそのように提案されたＭＬＲルートのみを用いる。これらの提案されたＭＬＲルートは、ある特定のＰＳモジュールバッチを実行する前に、輸送計画管理者によって入力され、輸送計画管理者の特定のサプライチェーンに関する知識を基にする。それゆえ、ＰＳモジュールが実行される度に、全ての実現可能性のある荷動きに対して、ルートに関する選択肢、すなわち、ある特定の注文の経路内の提案されるＭＬＲ区間の実現可能性のある各組み合わせの場合のＭＬＲと、その注文の経路において設定される、ＰＳによって規定される通常の経由地のうちの任意の経由地を通る、中継場所が１つのルートと、起点から終点までの直接ルートとが考慮されるであろう。
【００６９】
マレーシア内の３つの異なる起点から出発する３つの注文があり、その注文が米国内の２つの異なる終点に向かうことになっているものと仮定する。マレーシアからの第１および第２の注文はアリゾナ州チャンドラーに向かっており、マレーシアからの第３の注文はオレゴン州ヒルスボーロに向けられる。各経路に対応するＭＬＲ区間は、構成中に輸送計画管理者によって設定される。この特定の構成では、３つのクロスドックＰＥＮ（マレーシアの空港）、ＬＡＸ（ロサンゼルスにある、米国への入口の港）およびＰＤＸ（オレゴン州ポートランドの空港）を含む１つのＭＬＲ提案ルートは、ＰＳバッチが、マレーシアの第３の起点からオレゴン州のヒルスボーロまでの経路上で実行される前に設定される。
【００７０】
第２のＭＬＲ提案ルートが入力され、アリゾナ州チャンドラーの１つの場所に配送されることになる、第１および第２のマレーシアの起点を含む経路を指定する。この第２のＭＬＲ提案ルートは、中間の経由地としてＰＥＮ、ＬＡＸおよびＰＨＸ（フェニックスの空港）を含む。
【００７１】
上記の注文が、あるバッチ中に問題解決プログラムモジュールにおいて考慮されるとき、ＰＳによって、各注文の場合にどのルートが最適であるかに関する最初の判断が行われる。輸送計画管理者によって提案される全ての適切なＭＬＲが、任意の実現可能性のある経由地を通る行程（１つの中継場所を含む）と、起点から終点までの各注文のための直接的なルートとともに、あるバッチ実行のこのサブステップ中にＰＳロジックによって編成される。各ルートの場合に予想されるコストを用いて、全ての実現可能性のある荷動きの進路が特定された後に、判断が下される。１つあるいは複数の注文を一緒にまとめることにより、いくつかの節約が実現されるが、多数の中継場所を通る行程の完全な影響および付帯的な料金の結果が予測できないため、ＰＳモジュールによるＭＬＲ（およびＴＬ、ＬＴＬ、航空機、鉄道および海上の荷動き）のためのコスト計算は基本的には推定値であることは理解されたい。最適なルートについての初期の判定が行われるとき、ＰＳモジュールは、後続のＭＬＲの全ての区間をまとめる。この逐次的な区間構成手順は、計上されることになる全ての一括輸送の機会を考慮に入れる。たとえば、上記のシナリオでは、３つの全注文がＰＥＮおよびＬＡＸに及ぶ区間において同じ行程上で構成されるであろう。いずれもアリゾナ州の場所に向かっている、マレーシア内の第１および第２の場所から出発する２つの行程はいずれも、ＬＡＸからＰＨＸまで、およびＰＨＸからその最終的な目的地まで、同じトラック積荷を用いてまとめてルートを指定されることができる。このようにして、荷動きをまとめる結果として、典型的には、規模の経済からの利点に起因してコストが削減される。
【００７２】
上記のように、ＰＳモジュールの管理者インターフェースは、ＰＳバッチが実行される前に、輸送計画管理者が実現可能性のあるＭＬＲ区間を定義できるように構成される。好ましい実施形態によれば、これは、ＭＬＲテンプレートを用いて行われることができる。ＭＬＲテンプレートは基本的に、輸送計画管理者が、所与の輸送経路に関連付けられる一連の経由地（たとえば、一般に中間にある積荷を混載する場所として定義されることができる「クロスドック」）を提案できるようにする（したがって、その組織の知識および経験を活用する）入力機構（たとえば、コンピュータ形式あるいはチェックリストの形をとる）を含む。ＭＬＲテンプレートはＰＳデータベースに格納され、バッチ実行中にＰＳロジックによって合わせて考慮されるときに、ＰＳロジックがその経路内の任意の荷動きに対してＭＬＲを構成しようと試みるための一連の基本構成要素（ｂｕｉｌｄｉｎｇｂｌｏｃｋｓ）として機能する。言い換えると、１つのＭＬＲテンプレートがＰＳデータベースに入力されるとき、それは、その経路を通ることができる注文を出荷するための取り得るルートとしてＰＳモジュールによって考慮される。それゆえ、ＭＬＲの全ての取り得る組み合わせを考慮する代わりに、ＰＳロジックは単に、最初に現在のバッチのための注文をＭＬＲテンプレートによって提案されるような区間に組み込むことを試み、その後、後の時点でその出荷の区間の残りを統合することを試みる（自動的に行われるか、あるいは輸送計画管理者の支援の下に手動で行われる）。
【００７３】
提案されるＭＬＲのための能力の制限が、輸送計画管理者によってＭＬＲテンプレート内で定義されることもできる。能力の制限がＭＬＲテンプレートに設けられるとき、それらは、そのテンプレートにおいて用いられるクロスドックの場所に対して定義されている場合がある他の制限に優先する（しかしながら、ＭＬＲ行程の一部でない注文が同じクロスドックの場所を通ってルートを指定されるとき、もしあるなら、そのクロスドックが持つ能力の制限が当てはまる）。
【００７４】
ＭＬＲの能力の制限は、ＰＳロジックが、ある特定のＭＬＲ行程を経由して注文のルートを如何に指定しようするかを左右する強力な機構として機能することができる。本発明の好ましい実施形態では、各ＭＬＲテンプレート内で、３つの異なる能力閾値、すなわち、それ未満では全ての注文がＭＬＲの経由地を通ってルートを指定される下側能力ＭＬＲ閾値と、それ以上ではＭＬＲの経由地を通って出荷される注文が全くない上側能力ＭＬＲ閾値と、上側能力ＭＬＲ閾値と下側能力ＭＬＲ閾値との間の領域を上側中間領域と下側中間領域とに分割する中間能力ＭＬＲ閾値とを設定することができる（したがって、４つの領域が画定される）。これらの４つの領域はそれぞれ、特定の経路上のＭＬＲを考慮する特定のバッチプロセスの任意の実行中にＰＳロジックによって異なる処理を指定する。
【００７５】
所与のＭＬＲテンプレートによってサービスを提供される、１つの経路に指定される注文が下側能力ＭＬＲ閾値未満に入る能力を有する場合には、これらの注文は、いわば、ＰＳロジックの行程構成プロセス中にこのＭＬＲによって要求されるであろう。しかしながら、同じ注文は、同様に他の定義されたＭＬＲの場合に（およびクロスドックのような他のタイプの経由地の場合に）もこの制限未満になる場合があり、それゆえ、多数のＭＬＲおよび経由地によって要求される場合がある。これらの注文のルートを指定するために、ＰＳロジックは結局、それらの全てのルートを指定し、その後、以下に説明されるように、サブステップ７０４においてその一群の注文を要求するＭＬＲと他の経由地との間でコストに基づく判断が下される。
【００７６】
最も低い領域におけるこの動きは規則に基づいており、それは、注文がこの能力制限未満になり、１つのＭＬＲ（あるいは１つの経由地）によって要求されるとき、問題解決プログラムロジック３０１は、行程のコストが低くなる場合であっても、これらの注文の場合に直接的なルート指定のオプションを除外することを意味する。したがって、直接ルートは編成されず、コスト計算および比較のためにサブステップ７０４には送信されないであろう。
【００７７】
中間能力制限は、上側能力制限と下側能力制限との間の領域を、２つの中間能力範囲、すなわち上側中間範囲と下側中間範囲とに分離する。問題解決プログラムロジックは、注文の能力がこの制限の上側に入るか、下側に入るかに応じて、その注文を個別に取り扱う。注文能力が下側中間範囲内に入る場合には、問題解決プログラムは、これらの注文のルートを指定する方法について、完全にコストに基づいて判断を下すであろう。したがって、ＭＬＲの経路内に入る（そして、下側中間範囲内の能力を有する）注文は、行程がその注文のための最適なコストの行程を表す場合にのみ、所与のＭＬＲテンプレートから作成される行程においてルートを指定されるであろう。コストに基づく意思決定を促すために、輸送計画管理者によって、この範囲が最も広くなるように能力制限が設定される。この純粋にコストに基づく動きは、所与のＭＬＲテンプレートの場合に能力制限が設定されない場合にはデフォルトになるであろう。
【００７８】
注文能力が上側中間範囲に入る場合には、問題解決プログラムロジックは、所与のＭＬＲテンプレートから作成された行程上で注文のルートを指定しないように、初期判断を下すであろう。この初期の動きは規則に基づいており、このＭＬＲがある特定の注文の場合に最適なコストの行程を表す場合であっても、それらの注文の能力がこの制限より上側に入る場合には、その行程を通るルートを指定されないことを意味する。しかしながら、問題解決プログラムの行程構成プロセスにおいて後に、この能力範囲に入る注文のためのルート指定オプションが評価し直される。輸送計画管理者によってそのように構成される場合には、ＰＳロジックはその後、そのような注文の場合に、別のルート指定オプションがさらにコストが低い行程を生成することができるか否かを考慮することができる。この時点で、最初の時点から存在し続けてきた他の行程およびＭＬＲが考慮されることができることに留意することが重要である。最後のルート指定判断は結局、コストに基づく。中間能力制限の全体的な効果は、その値が下側制限に近づくにつれて、注文がこのＭＬＲを通ってルートを指定されることになる可能性が小さくなることである。
【００７９】
所与のＭＬＲテンプレートによってサービスを提供される、１つの経路に指定される注文が上側能力ＭＬＲ閾値未満に入る能力を有する場合には、そのＭＬＲテンプレート（およびそれが定義する経由地）は、この注文の場合にオプションを考慮されないであろう。下側能力制限に入る注文の場合と同様に、上側能力制限より上側の領域内の動きは厳密に規則に基づいている。それは実質的に、このＭＬＲテンプレートから作成される行程がある特定の注文の場合に最適なコストの行程を生成する場合であっても、それらの能力がここで設定された制限よりも高い場合には、それらはＭＬＲを通ってルートを指定されないことを要求する。しかしながら、ＰＳロジックは依然として、他のＭＬＲテンプレート、他の経由地および直接ルート指定オプションを考慮するであろう。
【００８０】
ある場合に、能力制限を設定することにより、ＰＳが一群の注文をスケジューリングするのに要する時間を削減することができる。たとえば、あるＭＬＲを通って配送される注文が５０，０００ポンドより重くなるのを避けることがビジネス上で意味のあることである場合には、あるＭＬＲの場合に上側能力制限を設定することにより、５０，０００ポンドに設定されることになる。問題解決プログラムがそのように大きな注文を考慮するときでも、そのＭＬＲにおいて注文をスケジューリングすることを試みるのに全く時間を費やさないであろう。
【００８１】
さらに強力なのは、特定の属性を有するＭＬＲテンプレートをＰＳロジックが選択するのを支援するために、能力制限が提供する能力である。たとえば、ある所与の経路において、その最も長い区間の場合に航空輸送を利用するテンプレートと、陸上輸送のみを利用する他のテンプレートとを設定するものとしよう。輸送計画管理者が能力制限を用いて、比較的少ない注文のみが航空輸送区間を有するＭＬＲを介してルートを指定されるようにできることは当業者には容易に理解されよう。
【００８２】
たとえば、輸送計画管理者が、あるＭＬＲが１５０ポンド未満の能力を有する注文の場合の行程を作成する場合にのみ用いられることになるように、ＭＬＲテンプレートのための能力制限を利用したいと考えた場合には、５０ポンドの下側制限と、１００ポンドの中間制限と、１５０ポンドの上側制限とを簡単に設定することができる。ＭＬＲ能力制限のこの態様によって、ＰＳロジックは同じ経路における異なるＭＬＲ間と、あるＭＬＲと他のルート指定オプションとの間とを選択できるようになる。
【００８３】
ＰＳモジュール３００が複数の経由地あるいはクロスドックを設けられるものと仮定すると、その起点からその終点までの出荷を行うために、クロスドックの全ての利用可能な組み合わせを考慮することにより、各バッチ中にＰＳモジュールによって１つのＭＬＲが動的に構成されることができるであろう。注文バッチがより複雑になるとき（より多くの場所に向かう、より多くの出荷品を伴う）、ＰＳモジュールに全ての取り得る組み合わせを試行させることにより、非常に複雑で高価なハードウエアを用いる場合であっても、許容できないほどの実行時間を要することになる。本発明は、ユーザによって提供されるＭＬＲ区間の提案を用いることにより、上記の計算上の問題を軽減する。これらの提案された区間は、その企業が所有するビジネス知識を活用して、ＰＳロジックが多区間行程を如何に構成するかを左右する。それゆえ、新たな一群の注文が問題解決プログラムにルーティングされる度に、白紙の状態からＭＬＲ出荷の計画を策定する手順を開始するのではなく、問題解決プログラムはそのルートに関して提案された区間を用いて、実現可能で、かつ費用対効果の高いＭＬＲ行程を編成できるようになる。
【００８４】
さらに、サブステップ７０３では、連続移動ＰＳロジックによって、ＰＳモジュールは、輸送業界において「連続移動運送（ｃｏｎｔｉｎｕｏｕｓｍｏｖｅｔｏｕｒ）」と呼ばれるものを作成できるようになる。連続移動運送は、同じトラックを用いて１つの連続したルート（あるいは連続移動）を形成するために結合される１組のトラック積荷行程（あるいは複数の積荷）を定義する。２つ以上の行程が空き区間によって結合されることができるが、その場合にはトラックが利益に繋がる貨物を搭載しないため、空き区間の数および長さは最小限に抑えられる必要があることは理解されたい。ＴＬおよびＬＴＬ輸送業者は多くの場合に、出荷品が連続移動運送に統合される度に、高い車両および運転手の稼働率を達成できることに起因して値引きを行う。
【００８５】
ＰＳロジックは、既存の行程あるいは運送の行程の最後に、新たな行程を追加することができるか（ＰＳロジックは１つの荷動きが終了する時間、および別の荷動きが開始する場所を認識している）、あるいは新たな連続移動運送を形成するために、初期段階のＰＳモジュールの実行中に作成されたトラック積荷を介して２つの荷動きの行程を組み合わせることができる。ＰＳモジュールによって作成される２つの行程は、連続移動が両方の行程を個別に、かつ異なる輸送業者を用いて送り出すよりもコストがかからない場合には、またその連続運送を都合よく完了することができる場合には、連続移動運送を形成するために組み合わせられることが好ましい。
【００８６】
輸送管理に関する別の長年にわたる課題は、輸送管理者あるいは従来技術のシステムおよび方法が、輸送管理者の企業の外部に存在する場所の制限あるいは運送業者の料金を考慮に入れることができないことである。そのような場所の制限の典型的な例は、物流センターが限られた数のトラック進入口しか持たないか、あるいは週末の業務スケジュールが制限されることにより生じる他の関連する処理能力の制約を有する場合であろう。その場合に、輸送管理のための従来技術のシステムおよび方法は、その最も早い段階の最適な出発時刻における出荷の荷動きに偏るようになる。すなわち、多数のＴＬ行程の出発時刻が、１つの行程の場合に同じコストを生じるとき、各荷動きのための出発時刻として、典型的にはこれらのうちの最も早い時刻が選択される。この規則の結果として、多くの場合に、多数の荷動きが、ある１つの場所（たとえば、物流センター）において同じサービス時間をスケジューリングされるようになる。これらの場所は典型的には、それらが同時に取り扱うことができる貨物車両の数に関して、かつそれらが所与の時間内に成し遂げることができる荷積みおよび荷降ろしの数（たとえば、週末の制約に起因する）に関して制約があるので、多くの場合に、ある場所における複数の行程のためのサービス時間はずらされることが望ましい。さらに、自己保有の輸送手段のための中継場所である配送拠点あるいはクロスドックの場合に、トラック運転手の出発時刻および交替勤務を綿密に追跡するために、行程の出発時刻をずらすことが望ましい場合が多い。それゆえ、本発明は、それによりそのような問題を解決するために、場所の制約を組み入れ、場所のサービス時間をずらすことができるようにする。
【００８７】
本発明によれば、各クロスドックおよび／または倉庫に関して、１組の時間帯が定義され、ＰＳデータベースに格納される。これらの場所制約（「ＬＣ」）時間帯はそれぞれ、関連する活動制約を有するであろう。活動制約は、所与の時間内にサービスを提供されることができるトラックの数、所与の時間内に取り扱われることができる注文量の大きさ（すなわち、重量、体積、個数、パレット等）、および／または取り扱われることができるトラック注文当たりの最大重量サイズを含む、種々の方法において表すことができる。さらに、本発明によって、そのＬＣ時間帯は、活動制約が厳しく強制されることになるか、あるいは問題解決プログラムロジック内のコストペナルティになるかをそれぞれ指示するために、厳密なものか、柔軟なものかのいずれかとして指定できるようになる。その制約が柔軟である場合には、超過使用量あるいは単位当たりのコストにおいてコストペナルティが規定され、バッチ実行サブステップ中にＰＳロジックによってルートおよび／または解決手法の選択に組み入れられるであろう。
【００８８】
本発明の実施形態によれば、輸送計画管理者は、クロスドック、経由地、物流センター等に関して存在する制約を考慮に入れるＬＣテンプレート（上記のようなＭＬＲテンプレートに効果および動作において類似）を用いて、場所の制約を定義することができる。これらの制約は、センターの物理的な制約（利用可能なフォークリフトの数）あるいはその特定の場所における作業者の作業スケジュールを含むことができる。これらのＬＣはその後、ＰＳデータベースに格納され、ＰＳロジックのサブステップ７０３においてバッチ実行中にＰＳモジュールによって用いられる。
【００８９】
上記のように、ＬＣ時間帯内では、制約は、その活動制約がＰＳモジュールによって厳しく強制されることになるか、ＰＳロジックが取り得るルートの相対的な、場所制約を見込んだ料金の計算を開始する際に、コストペナルティになるかを指示するために、厳密なものか、柔軟なものかのいずれかとして指定されることができる。制約が柔軟なものであるものと指定される場合には、超過単位当たりのコストにおいてコストペナルティが指定されるであろう。特に、場所制約は、ＴＬおよびＬＴＬ輸送業者に対してＰＳロジックによって用いられる。場所制約を見込んだ資源の場合に２つ以上の提案されたルートが完了しつつあるときに、ＰＳロジックによって用いられる判定アルゴリズムの説明が以下の付属書Ｂに提供される。
【００９０】
サブステップ７０３において、ＰＳロジックは、当業界において複数交替業務として知られるものも考慮する。ＰＳロジックによって用いられる全ての資源は、ＰＳデータベースにおいて、輸送手段、経路および設備タイプによって特定される。たとえば、ある特定の資源（トラック）は、ＸＹＺトラック運送会社に属し、４８フィート平床トラックであり、ペンシルバニアからメリーランドまでの経路内を運行するように規定される。数多くの従来技術の輸送管理システムでは、一旦、ある特定の資源がある行程に指定されたなら、その資源は計画範囲の残りの部分（たとえば、その日の残りの部分）の場合には使い尽くされており、輸送管理システムの後の方で実行される別の行程に対して再利用されることはできない。結果として、ある特定の資源が、終日かかることのない短時間の行程を受ける場合には、その資源は計画範囲の残りの部分に対して空いたままであろう。
【００９１】
この少ない稼働率を解消するために、ＰＳロジックは、資源が別の用途に利用することができなくなる全時間を表す時間帯を、計算される各行程に割り当てる。このようにして、同じ４８フィートトラックが、午前６時３０分から午前１１時３０分までかかる配送を行い、午後１時から午後８時までかかる第２の配送を行うことができる。時間帯が適切に設定できるようにするために、輸送計画管理者および輸送業者は、所与の経路内の行程間の一定の休止時間を指定することができ、ＰＳはＴＬおよびＬＴＬ荷動きの場合に推定されるルート時間を計算する。
【００９２】
そのようにＰＳモジュールによって用いられるバッチアプリケーションは、多数の利用可能な輸送業者を通して出荷されることができる大きな一群の注文のような、複雑な問題全体を見て、１回限りの低コストの解決手法を作成することができるという意味で強力である。しかしながら、バッチアプリケーションは本質的に、時間にわたって継続的な最適化を提供するための能力において制限される。ある時点において、バッチアプリケーションのユーザは、バッチアプリケーションが特定の地点および時刻において有する全ての情報を最適化するプロセスを開始する必要がある。ただし、最適化エンジンを用いる企業は多くの場合に、最適化されたばかりの問題要素（注文あるいは輸送業者の利用可能性としても知られる）に対する変更を依然として可能にしているという問題がある。輸送管理の分野では、これらの変更は、注文の取消し、変更および追加を含み、それらが最適化の時点でわかっていたなら、著しく異なる解決手法が生み出されていたであろう。企業は、注文変更および締切時間についての厳密なビジネス取引（ｐｒｏｃｅｓｓ）規則を強要することにより変更および取消しからの損害を抑えることはできるが、そのような厳密なビジネス取引規則は多くの場合に、総合的な顧客満足度を目標とする動きと相反する。したがって、バッチプロセス、すなわち上記のようなＰＳモジュール最適化バッチが実行された後に、注文情報を更新し、かつ／または補正するための能力を備えることが望ましい。
【００９３】
一般に、現在のＰＳバッチ内（その状態は「Ｎ」であり、新しいルート指定されていない注文を示す）の注文のうちのいくつかが、ＥＸによって提出されている既存の荷動き（状態「Ｔ」を有する）のうちのいくつかと同じ経由地あるいは起点から同じ終点に向かっている状況が生じるであろう。（本発明の好ましい実施形態において用いられるデータベース状態コードは、付属書Ａに列挙される。）ＰＳモジュールがバッチを実行する度に、請け負われる積荷は、「新しい」注文ではないので、バッチの一部として考慮されるとは限らないため、輸送計画管理者によって規則が設定される場合があり、その場合に、ＰＳモジュールは、任意のそのような重複する新しい注文を、任意の適合する請け負われた既存の行程に「追加」しようとする。このようにして、新しい積荷の請負提示は、ＥＸモジュールを介して適当な輸送業者に送信されなければならないであろう。
【００９４】
さらに、本発明の好ましい実施形態よれば、サブステップ７０３において、ＰＳロジックは、既に最適化されたルートに追加を行うことができるようになる（言い換えると、ＰＳロジックは、その注文が、ルート指定済み注文インターフェースによって提供された場所と同様の場所から出発した場合、および同様の場所に向かっていた場合には、既に最適化されたルートを「同行」することになる注文を追加する）。図４に示されるように、ＥＸモジュールは、それらのルートにまだ資源の割当てが行われていなければ、ルートを指定されたか、請負提示がなされたか、請負提示後に輸送業者によって受諾されたかのいずれかである未実行の荷動きの注文４１１のルートを指定し直すことができるであろう。この場合に、問題解決プログラムは、この既存の荷動きを利用し、新たな注文をそれに追加して、ルート指定済み注文インターフェースを通してＥＸモジュールにその荷動きを返送するであろう。その際、ＥＸモジュールはその注文（それは、データベースにおいてルート指定済み請負あるいは受諾状態を有する古い注文に関連付けられる新たな注文として、ＥＸデータベースにおいて特定される）を請負提示し、その後、輸送業者は、その更新された注文を取り扱うことができるか否かを決定するであろう。更新された注文が取り扱われることができる場合には、その実行によって、ＥＸデータベース内の新たな注文記録が更新される。その輸送業者によって、更新された荷動きが取り扱われない場合には、ＥＸモジュールは、問題解決プログラムに更新された注文を返送し、その行程への変更が現時点では許されないように、ＰＳデータベースから元の注文を取り除く。別法では、その際、ＰＳは更新された注文を新しい輸送業者に請負提示し直すことを試み、受諾された場合には、元の注文を取り消すことができる。
【００９５】
図７を参照すると、サブステップ７０４では、ＰＳデータベース３０２に格納される料金表を用いて、サブステップ７０３からそれぞれ提案されたルートのための料金が計算される。ＴＬ料金表は、設備クラスによって各輸送業者にための出荷料金を指定する。その後、料金は、１マイル当たりのドル額、最低料金および／または均一料金に関して各表において指定される。
【００９６】
ＬＴＬ料金は、最低料金およびウエートブレークに関して、各クラスの場合の輸送業者によって規定される。ある特定のゾーン内に輸送するための輸送業者のウエートブレークおよび料金の場合に、パッケージ料金が規定される（そのゾーンは特定の輸送業者によって規定される）。鉄道料金、航空料金およびパッケージ料金は、上記の任意のものの組み合わせとして規定することができる。一貫した荷動きは、その行程の各区間の場合の特定輸送業者タイプ料金表を用いて輸送料金を決定される。
【００９７】
ＴＬおよびＬＴＬの料金決定に関して、ＰＳモジュールは、出荷品が起点から終点まで移動することになる距離を計算できなければならない。ＰＳモジュールが、ＰＣ＊ＭｉｌｅｒおよびＭｉｌｅＭａｋｅｒのような容易に入手することができる市販の距離計算ソフトウエアへの入力として、緯度および経度、郵便番号および住所から得られる計算距離を用いるように容易に構成できることは当業者には容易に理解されよう。
【００９８】
各輸送業者タイプのための料金表も典型的には、２つの変数、すなわち起点から終点までの距離と、積荷の重量とのうちの１つ（あるいは場合によって両方）に依存する。移動する距離に関して、ＰＳシステムは、ＴＬ行程の場合に５つのタイプの料金決定方法に対応する。それらは、均一料金、メートル距離料金、固定プラス変動料金、マイル距離料金およびラジアル距離料金である。ラジアル距離料金は、荷動きの種々の区間上の各端点間の直線距離の和を距離変数として用いて、荷動きのコストが決定される、積荷料金決定およびルート指定方法である。
【００９９】
各料金表において用いられる重量変数に関して、ＰＳモジュールは標準的な重量（すなわち、ポンドあるいはキログラム）あるいは寸法重量の使用に対応する。輸送業界では、寸法重量は、その実際の重量に加えてその体積測定標準規格に基づく出荷品の重量の計算値である。基本的に、それは、輸送業者の収容能力の大きな部分を消費する、大きくて、かさばるが、軽量の物体が、高密度で小さな物体と比較して同等にコストがかかるようにするための均一化手段として機能する。寸法重量は、各パッケージおよび／または物体の長さ×幅×高さを計算し、その体積を適当な寸法重量除数で割ることにより計算される。寸法重量除数は、その提供される各輸送業者タイプサービスに対して各輸送業者によって具体的に規定される。さらに、寸法重量除数は、輸送のための経路（たとえば、米国内輸出出荷品）に応じて変更されることができる。たとえば、米国内の典型的な国内出荷品寸法重量除数（インチ単位で掲載されるパッケージ寸法の場合）は１９４であるが、ＵＳ輸出出荷品の場合には、その除数は１６６である。
【０１００】
輸送業者は典型的には、請求する価格を決定するために、その料金が出荷品の寸法重量および実際の重量の２つの重量のうちの大きい方の重量を用いて決定されることを求める。寸法重量による料金決定は、ハイテク産業のような複数の業界に特に適用することができ、そのような業界では、それぞれかなり軽い重量を有する多数の箱が出荷される。多数パッケージの出荷の場合、寸法重量は単に、各パッケージのための個々の寸法重量を合算することにより決定される。
【０１０１】
ＴＬおよびＬＴＬ輸送業者はいずれも、多くの場合に、往復行程となる輸送に対して値引きを実施する。これは、輸送業者による空の区間を制限するための役割を果たし、それゆえ輸送業者は多くの場合に、往復予約を促進するために、その経費節減分を顧客に渡す。
【０１０２】
付帯的な料金は、輸送中の取扱い料金、燃料追加料金、および輸入／輸出手数料のような予想される料金である。輸送業者および／または経路および／または場所の各タイプの場合に、付帯料金はＰＳデータベースにおいて定義されることができる。輸送業者、輸送手段タイプ、ならびに往復料金、ラジアル距離料金、寸法重量等によって必要とされる任意の適切な変更に基づいて、その出荷品のための適切な料金が計算された後に、適用される付帯料金が最後に加算され、最終的な「予想される」コストが生成される。
【０１０３】
ＰＳモジュールは、小口貨物および急行便輸送業者（これ以降、両者をまとめて「小荷物輸送業者」と呼ぶ）を通して、小さなパッケージあるいは小さな注文の出荷をスケジューリングすることができる。典型的には、小荷物輸送業者は、サービスを提供するエリアを複数のゾーンに分割する料金予定表を用いる。各ゾーンは１組のウエートブレークおよび関連する料金を有する。小口貨物輸送業者は典型的には、全米をいくつかのゾーンに分割し、一方、急行便輸送業者は全米に対して１つのゾーンを有し、１組のウエートブレークと関連する料金とを有する。
【０１０４】
小荷物輸送業者は一般に、当日配送、翌日配送、標準的な陸上輸送（ｎｏｒｍａｌｇｒｏｕｎｄ）などのようないくつかのサービスレベルを提供する。注文バッチプロセスの最適化中にＰＳモジュールは、特定の注文の要件を満たすために、関連する特定の輸送業者のための全てのサービスレベルを考慮するであろう。いくつかの小荷物輸送業者は、商業地域および居住地域への配送に対して異なる料金を請求する。これらの料金は再び、料金表に反映されるであろう。
【０１０５】
鉄道輸送業者は、多くの場合に週７日間運行し、その見積もられる料金（ＰＳデータベースの料金表に格納される）は典型的には、ＴＬ（単に、トレーラおよび／または鉄道貨車１台に対する移動距離に基づく料金）に対してと同じように規定されるという点で、ＴＬタイプ輸送業者に非常によく似ている。鉄道輸送業者を利用する場合には、必然的に、距離および運転速度ではなく、公示された鉄道の時刻表が特定の荷動きのタイミングを決定することは当業者には容易に理解されよう。さらに、鉄道を利用する場合には、多数の中継地あるいは迂回も不可能になる。論理的には、鉄道とＴＬ輸送業者とを組み合わせる一貫輸送業者は必然的に、ＴＬおよび鉄道輸送業者に関連する全ての制限を組み入れる。海上輸送業者は上記の点に関して鉄道輸送業者と同様である。
【０１０６】
再び図６を参照すると、ＥＸモジュールの実行ロジック４０１が、ＰＳモジュールがステップ６０３において荷動きの計画を作成した後に、いくつかのステップを実行することが示される。最初に、ステップ６０４では、ＥＸロジックは、ステップ６０３においてＰＳロジックによって選択される輸送業者に請負依頼（出荷サービスのための正式な要求）を送信する。ＰＳロジックによって用いられる各輸送業者は、請負インターフェース４０７を介して実行モジュール４００に電子媒体によって接続され、請負依頼（および以下に記載されるような、その後の受諾あるいは辞退）が、ＥＤＩ、電子メールあるいはウエブを介して、補足説明を付けて電子情報として送信されることができるようになることが好ましい。別法では、当然、ファクシミリあるいは電話のような従来からの手段が用いられることができる。
【０１０７】
一旦受信されたなら、輸送業者は請負依頼を検討し直し、その請負依頼の受諾あるいは辞退（ＥＸモジュールは、ステップ６０６においてこの受諾／辞退の通信を監視する）を、応答インターフェース４１２を介して、実行モジュール４００に電子情報として提供することができる。その後、ＥＸロジックは、未実行荷動きインターフェース４１０を介して、未実行注文４１１として問題解決プログラムモジュール３００に戻される全ての辞退された注文のルートを指定し直し、異なる輸送業者あるいは輸送問題解決手法を選択できるようにする。６０７において図面に示されるように、ＥＸロジックは、ルート指定し直すために６０７に注文を戻すか（所定の時間後に応答がない場合、あるいは請負が辞退された場合）、あるいはその輸送業者に請負依頼を再送しようするか（たとえば、輸送業者に、その請負依頼に応答するための第２の機会を与えるために）を判断する。
【０１０８】
再び図６を参照すると、ＥＸモジュール４０１が、ステップ６０８においてある荷動きが完了したことの確認を受信した後（好ましくは、図４に関して先に記載されたように出荷品状態インターフェース４０６を介して電子情報として）、ＦＰモジュール５００は、ＦＰＩ４０５から実行済み注文４０９を受信し、運送料支払ロジック５０１が、運送料支払送り状と、支払勘定および受取勘定記録とを作成する。運送料支払ロジックの動作は図６のステップ６０９にまとめて示される。
【０１０９】
先に説明されたように、運送料支払（「ＦＰ」）ロジック５００は以下の機能を実行する。ＦＰロジックは、支払い前に出荷の送り状を認証し、出荷および注文に請求された料金を割り振り、荷動きのための予想された料金と請求された料金とを比較し、運送料を顧客に請求し、完了した荷動きに対する輸送業者への支払いを許可し、運送料を記録し、そのデータを接続される会計システムに送信し、運送料を報告および解析する。
【０１１０】
運送料支払ロジック５０１によって実行されるステップは、図６においてステップ６０９としてまとめて示されており、実際には、一連のサブステップとして動作する。図８は、図６のステップ６０９を形成する、ＰＦモジュールによって実行されるサブステップの概要を与える流れ図である。
【０１１１】
ＥＸモジュール（あるいは他の上流の電子実行管理システム）からの注文および出荷情報は、サブステップ８０１において、定期的にＦＰモジュール５００にロードされ、ＦＰデータベース５０２に格納される。これらの自動的にロードされる出荷および注文記録は、任意の時点で、管理者インターフェース５０４を通して輸送計画管理者３０９によって視認されることができる。これらの注文記録は、荷動きのためのコスト推定値を準備する際にＰＳモジュール３００によって利用された全ての関連するデータ（たとえば、輸送業者識別、設備タイプ、経路、起点、終点、商品の量等）と、その荷動きが開始された時刻および完了した時刻に関するデータとを含む。
【０１１２】
図８の料金見直しステップ８０２は、一旦注文記録がＦＰモジュールのＦＰデータベース５０２に良好にロードされたなら、荷動きのコストを計算し直す。ＦＰモジュールの料金見直しサブプロセスは、輸送業者、料金、移動したマイル数、付帯料金のような変数を検討し、あるコストを提示する（実質的には、ＰＳモジュールによって行なわれた、図７のサブステップ７０４に関して先に記載された方法と同じである）。ＦＰモジュールは、この計算を実行するためにＰＳモジュール内に常駐するデータおよびロジックを利用するように設計されることができるか、あるいは別法では、自らが所有するデータベースおよびロジック内の必要なデータおよびロジックを基本的に複製することができることは当業者には容易に理解されよう。最適な輸送計画を編成する際にＰＳモジュールによって計算された推定コストは典型的には、ＥＸモジュールからＦＰモジュールに渡されるが（関連する荷動きが実行された後に）、ＦＰモジュールは、いくつかの理由により、サブステップ８０２において、予想される出荷コストを計算し直す。
【０１１３】
ＰＳデータベースの料金表において表される輸送業者の予想される料金および付帯料が、その出荷品がルートを指定された（それゆえ、当初に料金を決められた）時点と、実際に荷動きが実行された時点との間の介在期間に変更された場合があるので、最初に、推定された輸送業者コストがＦＰモジュールによって計算し直される。第２に、上記のＦＰモジュールは、ＰＳおよびＥＸモジュールを備える３モジュール式システムの一部として説明されてきたが、ここに記載されるＦＰモジュールは、そのいずれか一方あるいは両方と無関係に用いられることができる。そのように、ＦＰモジュールがスタンドアローンの（すなわち、上記のようなＰＳモジュールおよび／またはＥＸモジュールと組み合わせられない）運送料支払管理システムとして用いられる状況では、ＰＳモジュールに関連して先に記載された料金表およびコスト算出プロセスは必然的に、ＦＰモジュール内に組み入れられなければならないであろう。さらに、当然、ＰＳモジュールからルーティングされる際に、データが破損する可能性が常に存在する。
【０１１４】
輸送サービス業界では、輸送業者は典型的には、完了した荷動きに対して送り状を送付する、すなわち料金を請求する。従来では、送り状は輸送業者から契約者に郵送される単なる紙の請求書であった。本発明の好ましい実施形態によれば、送り状は、ＥＤＩ、ウエブあるいは電子メール等を介して電子情報として輸送業者から転送され、図５に示されるような送り状インターフェース５０８を介してサブステップ８０３においてＦＰモジュールにロードされる。さらに、送り状を電子情報で送付しない輸送業者に対応するために、送り状データは、管理者インターフェース５０４を介して、輸送計画管理者３０９によって手動でＦＰモジュールに入力されることもできる。
【０１１５】
別法では、当然、輸送計画管理者によっては、輸送業者の支払いが許可される判定基準として、輸送業者からの出荷品状態メッセージあるいは配送通知を用いることを好む場合もある。
【０１１６】
一旦、注文記録がサブステップ８０２において料金を見直され、輸送業者の送り状が受信されたなら、ＦＰモジュールは、サブステップ８０４において、料金を見直された注文記録と、関連する送り状とを照合する。それらが厳密に一致しない場合には（たとえば、記録および送り状の参照番号が一致しない場合、あるいは送り状で請求されるコストと予想されるコストとの間に著しい差が見られる場合）、その注文および送り状の対は手作業で再検討するためにタグを付けられる場合があるか、あるいは一致しないまま残される場合がある。一致する送り状を見つけることができない場合には、ＦＰモジュールは、それが輸送業者から受信されておらず、所定の回数だけ再試行するか、あるいは手作業による見直しのためのメッセージを生成する前に所定の時間だけ待機することを想定するであろう。
【０１１７】
運送料支払モジュール５００は、サブステップ７０８において、輸送業者への支払いのための伝票を作成する前に、料金の見直しが行われた出荷品と確認された送り状とを照合しようとする。照合に成功するためには、送り状と、注文記録との間で、積荷証券（受取証、ＢＯＬ）、ＳＣＡＣ、出荷日、重量、起点および終点のような所定量の種々の鍵となるフィールドが一致しなければならない。
【０１１８】
一旦、サブステップ８０４において、実行済みの荷動き記録が送り状との照合に成功したなら、ＦＰシステムは、サブステップ８０５において、予想される出荷コスト（図７のサブステップ７０４においてＰＳモジュールによって当初に料金が決定されるか、あるいは図８のサブステップ８０２において料金が見直される）と、実際の送り状のコストとを比較し、その後、ステップ８０６において、もしあるなら、予想されるコストと送り状のコストとの間の差異を詳述する、輸送業者コスト差データベース記録を作成する。この輸送業者コスト差データベース記録は、たとえば、付帯料金表を更新する、あるいは輸送業者のプリファレンスの料金決定を変更することにより（たとえば、輸送業者の実際の請求されるコストが典型的には、計算された予想コストを大きく超えていた場合）、輸送計画管理者によって後に用いられることができる。
【０１１９】
さらに、企業の経理部は典型的には、輸送業者への支払いを行うために小切手を切ることができるように、送り状の受信および照合に関する証明通知書を必要とする。一旦、照合サブステップ８０７において送り状が特定され、照合されたなら、ＦＰモジュールは、完了した出荷のために輸送業者によってかかった支払いコストを含む単層ファイルを作成し、このファイルは、支払勘定インターフェース５０７を通して、サブステップ８０７において（電子情報形式か、ハードコピー形式かのいずれかで）支払勘定システムに出力される。サブステップ８０７においてその送り状が証明された出荷は、ＦＰモジュール５００内のデータベース５０２において「証明済み」の状態を得る。
【０１２０】
サブステップ８０８では、ＦＰモジュールは、特定の荷動きを含む注文に対して、輸送業者によってかかった（そして、輸送業者の送り状に列挙された）実際のコストの適切な部分を割り振る。請求されたコストの割り振りは、ある荷動きの全コストを、その荷動きにおける出荷品、注文および／または品目名に分配するプロセスであることは当業者には容易に理解されよう。上記のように、異なる依頼主からの１つあるいは複数の注文が、１つの輸送業者によって１つの荷動きに結合されるのは珍しくはない。さらに、輸送業者は多くの場合に、そのコストのための合計額を請求する。したがって、荷動きを構成する注文の間で１つの荷動きの全コストを公平に分割する必要がある。ＦＰモジュールは、能力割当ておよびターミナル間貨物輸送利用率を算出し、コストを公平に分割する。
【０１２１】
ターミナル間貨物輸送利用率は、重量、体積、パレット、距離、重量および距離、体積および距離、パレットおよび距離、重量体積係数、およびコスト削減方法を含む、種々のグループ分けにしたがって、ある行程の区間によって全運送料を割るためにＦＰモジュールによって用いられる。たとえば、ある荷動きが第１の区間（出荷１）の場合に２４０の重量を運んでおり、第２の区間（出荷２）の場合に１６０の重量を運んでいる場合には、そのコストは、以下に記載されるように、ターミナル間貨物輸送利用率として重量を用いて分割される。
行程上の全重量（「ＴＷＴ」）＝２４０＋１６＝４００
第１の区間上で運送されるＴＷＴの割合＝２４０／４００＝０．６
第２の区間上で運送されるＴＷＴの割合＝１６０／４００＝０．４
上記の割当て計算によって、第１の区間はその荷動きの６０％を請求され、一方、第２の区間は４０％を請求されるであろう。体積およびパレットは、同じ区間／全体比の方法を用いて計算される。
【０１２２】
距離は重量のような別の利用率と結合される場合がある。重量および距離を用いるターミナル間貨物輸送割当ての場合、距離は、行程マイル数（実際に移動した距離）あるいはラジアルマイル数（起点と各中継場所との間の個々の直線距離の和）によって計算される。たとえば、行程マイル数方法を用いる、距離および重量によるターミナル間貨物輸送割当ての場合、１０００の全コストを有する行程が２つの区間（１つの注文は各区間後に荷降ろしされる）から構成されるものと仮定する。点Ｓ１で終了する第１の区間は２００の距離と５００の重量とを有し、一方、点Ｓ２で終了する第２の区間は４００の距離と９００の重量とを有する。行程マイル数方法を用いるとき、各端点までの距離が移動する全距離であり、以下のようになる。
Ｓ１への距離＝２００
Ｓ２への距離＝６００（Ｓ１への２００＋Ｓ２への４００）
その際、各注文に対する重量距離（「ＷＤ」）は、以下のように、各端点への上記の距離と、その端点において降ろされる重量とを掛け合わせることにより計算される。
Ｓ１のＷＤ＝（５００重量）×（２００距離）＝１００，０００
Ｓ２のＷＤ＝（９００重量）×（６００距離）＝５４０，０００
したがって、全重量距離は６４０，０００である。その際、割当ての比率は、重量を例にして先に記載されたように計算され、以下のようになる。
Ｓ１のための割当て率＝１００，０００／６４０，０００＝０．１５６
Ｓ２のための割当て率＝５４０，０００／６４０，０００＝０．８４３
したがって、Ｓ１において降ろされる注文は荷動きコストのうちの１６％を課せられ、Ｓ２は８４％を課せられる。体積あるいはパレットと距離とが結合される場合のターミナル間貨物輸送は同様に計算される。
【０１２３】
重量体積係数はＦＰモジュールにおいてターミナル間貨物輸送割当てのために利用可能であり、以下の比率を決定する。
重量％＝注文重量／全重量
体積％＝注文体積／全体積
次に、重量／体積感度係数（Ｆ）が適用される。この利用率は、輸送計画管理者によってＦＰ上に入力され、０から１の範囲をとることができる。スコア０は重量のみを考慮し、一方スコア１は体積のみを考慮する。その間の比率は、２つの混合を反映するであろう。割当てパーセンテージは以下のように計算される。
割当て％＝Ｗ％＋（（Ｃ％−Ｗ％）×Ｆ）
その後、割り当てられた出荷当たりのコストが、計算された割当てパーセンテージと全荷動きコストとを掛け合わせることにより、上記のように計算される。
【０１２４】
コスト削減ターミナル間貨物輸送利用率が用いられるとき、ＦＰモジュールは、全ての配送が同じ起点からの個別の行程であったかのように、多中継地行程上の全ての配送の最適な（標準的な）直接コストを計算できるようになる。このコストは、最適直接コスト（ｂｅｓｔ−ｄｉｒｅｃｔｃｏｓｔ）にしたがって（すなわち、個別に出荷された個々の注文が得ることができる最も良い料率に基づいて）計算される。これらの行程の場合の全ての標準的な直接コストの総和に対する個々の行程のコストの比が、その行程のための割当てを決定する。たとえば、起点がＯであり、それぞれがＡ、Ｂ、Ｃの荷降ろし点に向けられる３つの積荷が存在する場合がある。トラックはＯからＡ、ＡからＢ、ＢからＣのルートに従うことになった場合には、全行程距離は以下のように表すことができる。
全距離＝（Ｏ→Ａ）＋（Ａ→Ｂ）＋（Ｂ→Ｃ）
ただし、表記法「ｘ→ｙ」は点ｘからｙへの距離を表す。それぞれの場合の割当て比率は以下のようになるであろう。
Ｏ→Ａ比率＝（Ｏ→Ａ）／［（Ｏ→Ａ）＋（Ａ→Ｂ）＋（Ｂ→Ｃ）］
Ｏ→Ｂ比率＝（Ｏ→Ｂ）／［（Ｏ→Ａ）＋（Ａ→Ｂ）＋（Ｂ→Ｃ）］
Ｏ→Ｃ比率＝（Ｏ→Ｃ）／［（Ｏ→Ａ）＋（Ａ→Ｂ）＋（Ｂ→Ｃ）］
再び、その荷動きの中で各注文に対して割り当てられるコストは、各割当て比率から先に詳述したように計算されることができる。
【０１２５】
能力割当ては、所与の出荷の場合に、注文および品目名によって運送料を細分する。ＦＰモジュールは、重量、体積、個数、パレット、重量／体積係数、総売上値の比率にしたがって能力割当てを実行することができる。たとえば、出荷品Ｘが１３００の重量を有し、２つの注文、すなわち注文Ａおよび注文Ｂのみを含む場合がある。注文Ａは５００の重量を有し、一方注文Ｂが８００の重量を有する場合には、注文当たりの重量に基づく能力割当ては以下のようになる。
注文Ａ＝５００／１３００＝０．３８５
注文Ｂ＝８００／１３００＝０．６１５
注文Ａはコストのうちの３９％を割り当てられ、注文Ｂはコストのうちの６１％を割り当てられるであろう。さらに、５００の重量を有する注文Ａが２つの品目名（細分される注文）、すなわち品目名１（重量＝４００）と品目名２（重量＝１００）とを有する場合には、品目名１のための能力重量割当ては、注文Ａのための割当ての８０％（４００／５００）になり、一方品目名２は残りの２０％を割り当てられるであろう。
【０１２６】
重量体積利用率が、能力割当ての場合に輸送計画管理者によって指定される場合には、以下の比率を用いる。
Ｗｔ％＝注文重量／全出荷品重量
体積％＝注文体積／全出荷品体積
割当てパーセンテージは以下のように計算される。
割当て％＝Ｗｔ％＋（（体積％−Ｗｔ％）×Ｆ）
ただしＦは０と１との間で変化する現在重量（ｐｒｅｓｅｎｔｗｅｉｇｈｔ）／体積感度係数である。その際、注文当たりの割り振られたコストは上記のように計算される。
【０１２７】
最後に、再び図８を参照すると、サブステップ８０９において、ＦＰモジュール５００は、割り振られた請求コストを反映する請求記録を作成し、受取勘定インターフェース５０６を介して受け取ることができる勘定に対する通知を、受取勘定インターフェース５０６を介して（電子情報形式か、ハードコピー形式かのいずれかで）受取勘定システムに送信する。オプションでは、このステップにおいて、顧客送り状インターフェース５０８を用いて、請求書として、あるバージョンの注文請求記録を顧客３２０に送信することができる（電子情報として、ファクシミリで、郵送するための印刷媒体としてなど）。輸送計画管理者がある荷動きの一部の請求を内部に（たとえば、図５に示されるような営業所３１８あるいは下位部門に対して）行う必要がある場合には、送り状送付ステップが同様に実行される。
【０１２８】
上記の最適化、実行および支払処理アルゴリズムは、特定の業界あるいは状況において直面する特定の要件および／または問題を考慮に入れるために変更される場合があることは当業者には理解されよう。したがって、例示したアルゴリズムは、請求の範囲に記載されるような本発明を限定するものと解釈されるべきではない。
【０１２９】
本発明はソフトウエアにおいて実施されることが好ましいが、これは本発明を限定するものではなく、当業者であれば、本発明の範囲から逸脱することなく、本発明がハードウエアにおいて、あるいはハードウエアおよびソフトウエアの種々の組み合わせにおいて実装できることは理解されよう。当業者による変更形態および代替形態は本発明の範囲内にあるものとみなされ、本発明は添付の特許請求の範囲による場合を除いて、限定されるべきではない。
【０１３０】
本発明の好ましい実施形態の上記の説明は、図示および説明する目的を果たすために提示されてきた。本発明を包括することや、本発明を開示されるものと全く同じ形態に限定することは意図されていない。本発明の精神あるいは範囲から逸脱することなく、本発明の開示される実施形態および概念に対して、種々の変更および改変がなされることができることは当業者には明らかであろう。したがって、本発明は、本発明の変更および改変が任意の特許請求の範囲およびその等価物の範囲内に入る場合には、それらを網羅することが意図されている。
【０１３１】
付属書Ａ
組み合わせてあるいは単独で用いられるとき、種々のモジュールによって、種々の状態が、注文記録に関連するデータベースエントリにおいて定義され、種々の態様で用いられることができる。輸送計画管理者（システム管理責任者）は、管理者インターフェースを用いて、状態名を変更し、それらがシステムによって如何に用いられるかを管理することができる。
【０１３２】
以下の表は、本発明の１つの好ましい実施形態による注文および出荷品状態名およびその推奨される使用法を示す。表Ａ１において以下に開示される状態コードおよび関連する説明は数多くの方法で変更されることができ、本発明の上記の実施形態でそのようなコードを利用する１つの有用な方法を例示するためにのみ以下に開示される。
【０１３３】
【表１】

【０１３４】
以下の表Ａ２は、示唆される注文状態コード、名前およびその推奨される使用法を示す。
【０１３５】
【表２】

【０１３６】
以下の表Ａ３は、標準的な導入時に状態変化を引き起こすイベントおよび条件を記載する。システム管理責任者は、状態名を変更し、それらが如何に用いられるかを管理するために、構成ユーザビューにおいて注文状態および荷動き状態タブを用いることができる。状態が自分のシステムと異なるように用いられているかを確認するために、自分のサイトにおいてシステム管理者に問い合わせなければならない。
【０１３７】
【表３】

【０１３８】
付属書Ｂ
この付属書は、場所制約（「ＬＣ」）によって達成される最適化バッチ実行において柔軟な制約を決定する際に、ＰＳモジュールによって用いられるマルチインテジャプログラミング（「ＭＩＰ」）アルゴリズム定式化を記載する。次に記載される表記法は、以下のＭＩＰ式において用いられる。
ｃ_ｉｔ：開始時刻ｔにおいて行程ｉをスケジューリングするコスト（ＭＩＰへの入力）。
ｕ_ｉｔ：０あるいは１、時刻ｔにおいて行程ｉが開始していることを指示する。
ｖ_ｉｔｋ：時刻ｔにおいて開始している行程ｉが場所制約期間ｋに適用する単位量。場所制約期間ｋは、特定の場所における特定の停止活動タイプ（たとえば、集荷、配送、準備、作業停止、全ての組み合わせ）のための時間内のある最大制約（たとえば、重量、体積、個数、パレット数あるいは行程）を固有に特定する（ＭＩＰへの入力）。
ｐ_ｋ：場所制約期間ｋの場合の単位超過当たりのペナルティ（ＭＩＰへの入力）。
ｑ_ｉ：行程ｉを未スケジューリングにしておく場合のペナルティ（ＭＩＰへの入力）。
ｒ_ｉ：行程ｉが未スケジューリングのままであるか否かを指示するスラック変数。ｕ_ｉｔがバイナリ変数であるので、強制的に０か１になるであろう。値０は、行程ｉがある開始時刻ｔにおいてスケジューリングされることを意味する。値１は、行程ｉが開始時刻においてスケジューリングされないことを意味する。
ｓ_ｋ：場所制約期間ｋのための単位超過を表すスラック変数。
ｎ_ｊ：以下を参照。
ｌ_ｊ：ｊによって表される隣接する場所制約期間の間の柔軟な最大違反変化の各単位のためのペナルティ。
ＳＭＱ_ｋ：（ＳｏｆｔＭａｘＱｕａｎｔｉｔｙ）ペナルティが開始する前の場所制約期間ｋの場合に許容される最大量が適用される（ＭＩＰへの入力）。
ＨＭＱ_ｋ：（ＨａｒｄＭａｘＱｕａｎｔｉｔｙ）場所制約期間ｋの場合に許容される絶対最大量（ＭＩＰへの入力）。
ＬＣ問題の場合、ｕ_ｉｔ、ｒ_ｉ、ｓ_ｋおよびｎ_ｊは解かれようとしている変数であり、他の全てはＭＩＰへの入力である。その公式化は以下の式を最小にすることを試みる。
【０１３９】
【数１】

【０１４０】
ただし以下の条件を前提とする。各行程ｉの場合に以下の式が成り立つ。
【０１４１】
【数２】

【０１４２】
また各ＬＣ期間ｋの場合に以下の式が成り立つ。
【０１４３】
【数３】

【０１４４】
隣接する場所制約期間ａおよびｂの各方向の対ｊの場合に以下の式が成り立つ。
ｓ_ａ−ｓ_ｂ＋ｎ_ｊ？０　（４）
【０１４５】
各ＬＣ期間ｋの場合に以下の式が成り立つ。
ｓ_ｋ？０　（５）
【０１４６】
各ＬＣ期間ｋの場合に以下の式が成り立つ。
ｓ_ｋ？ＨＭＱ_ｋ−ＳＭＱ_ｋ　（６）
【０１４７】
各行程ｉの場合に以下の式が成り立つ。
ｒ_ｉ？０　（７）
【０１４８】
隣接するＬＣ期間の各方向の対ｊの場合に以下の式が成り立つ。
ｎ_ｊ？０　（８）
【０１４９】
各行程ｉおよび各開始時刻ｔの場合に以下の式が成り立つ。
ｕ_ｉｔ＝０あるいは１　（９）
【０１５０】
上記の式に関して、
１．場所制約違反に関連するコストを最小限に抑えながら、全てのスケジューリングされた行程の累積コストを最小限に抑える。ある特定の時刻（ｃ_ｉｔ）においてある行程ｉを開始するためのコストは、実際にかかったコストを表す。ある行程を未スケジューリングにしておく場合のペナルティはｑ_ｉによって表されるであろう。ｃ_ｉｔがｑ_ｉより大きい場合には、ＭＩＰは、その開始時刻にその行程をスケジューリングしないことにより利益を得るであろう。それゆえ、その実際のコストが、その行程を未スケジューリングにしておく場合のペナルティより小さい行程の場合に開始時刻が存在しない場合には、ＭＩＰはその行程をさらにスケジューリングしようとはしないであろう。その式の最後の部分は、場所制約違反のためのコストを表す。注記：場所制約違反のためのペナルティは、ある行程を未スケジューリングにしておく場合のペナルティと適切に釣り合わせる必要がある。
２．２つ以上の開始時刻の場合に、行程はスケジューリングされることができない。ｕ_ｉｔはバイナリ変数であるので、ｕの合計の値は０か１かのいずれかになるであろう。値０は、その行程が開始時刻を割り当てられていなかったこと、およびｒの値を強制的に１にすることを指示する。値１は、その行程が１つの開始時刻を厳密に割り当てられていること、ｒの値を強制的に０にすることを指示する。
３．ｓ_ｋの値が、場所制約期間ｋの場合の柔軟な最大値が超過されている単位量を表すように強制される。
４．上記を参照。
５．場所制約ペナルティが、その制約のための柔軟な最大値に達する前に適用されるのを防ぐ。
６．場所制約違反が厳密な最大値を超えるのを防ぐ。
７．１つの行程ｉに対して２つ以上の開始時刻ｔが割り当てられるのを防ぐ。
８．上記を参照。
９．ある開始時刻に対して１つの行程が部分的に割り当てられることはない。行程ｉは、時刻ｔで開始するように割り当てられるか否かである。
【図面の簡単な説明】
【図１】未決の出荷注文を満たすために荷動きを選択し、スケジューリングする際に輸送計画管理者によって考慮されなければならない種々の影響力を示す概略図である。
【図２】本発明の１つの好ましい実施形態にしたがって実行される処理ステップ全体を示す流れ図である。
【図３】本発明の好ましい実施形態による、最適な荷動きを選択するための電子問題解決プログラムモジュールの動作態様および相互動作を示すブロック図である。
【図４】本発明の好ましい実施形態による、計画された荷動きをスケジューリングし、監視するための電子実行モジュールの動作態様および相互動作を示すブロック図である。
【図５】本発明の好ましい実施形態による、実行済みの荷動きに対する支払いを行い、送り状を送付するための電子運送料支払モジュールおよび関連する方法の動作態様および相互動作を示すブロック図である。
【図６】本発明の１つの好ましい実施形態にしたがって実行される処理ステップ全体を示す流れ図である。
【図７】本発明の１つの好ましい実施形態にしたがって実行される処理ステップ全体を示す流れ図である。
【図８】本発明の１つの好ましい実施形態にしたがって実行される処理ステップ全体を示す流れ図である。

Claims

輸送業務を管理するためのシステムであって、前記システムは、
商品の輸送に関連する情報を処理するための手段と、
前記処理された情報を用いて前記商品のための最適な輸送解決手法を決定するための手段と
を含む輸送業務を管理するためのシステム。
前記情報処理手段は、注文情報と、輸送業者情報と、制約情報とを処理する
請求項１に記載の輸送業務を管理するためのシステム。
前記注文情報は、その注文の送り元および送り先、前記商品の配送のための時間帯あるいは前記商品の場合に希望される輸送タイプを含む、前記注文を出荷するための依頼主の希望を詳述するデータを含む
請求項２に記載の輸送業務を管理するためのシステム。
前記輸送業者情報は、前記商品を輸送するための輸送タイプおよび価格を含む、輸送業者が前記商品を提供するための意思があり、かつ提供することができるサービスに関連するデータを含む
請求項２に記載の輸送業務を管理するためのシステム。
前記制約情報は、前記商品の輸送のための時間帯、最大あるいは最小処理能力、およびビジネス目標のような、実現不可能な輸送解決手段を記述するデータを含む
請求項２に記載の輸送業務を管理するためのシステム。
前記決定する手段は、前記商品のための多数の解決手段を生成し、前記解決手段はそれぞれ、前記商品のための別の荷動きを提案する
請求項１に記載の輸送業務を管理するためのシステム。
前記解決手段はそれぞれ、前記商品の輸送を実行するために必要とされる１つあるいは複数の輸送業者と設備とを特定する
請求項６に記載の輸送業務を管理するためのシステム。
前記処理する手段は、前記商品を輸送するための最も低コストの解決手段を特定する
請求項１に記載の輸送業務を管理するためのシステム。
前記決定する手段は、前記商品を輸送するための前記最も低コストの解決手段を選択する
請求項８に記載の輸送業務を管理するためのシステム。
前記出荷品の状態および場所に関する更新情報を受信するための手段をさらに含む
請求項１に記載の輸送業務を管理するためのシステム。
前記更新情報は、電子形式である
請求項１０に記載の輸送業務を管理するためのシステム。
前記更新情報を格納するための手段をさらに含む
請求項１０に記載の輸送業務を管理するためのシステム。
前記状態および前記場所に関する前記更新情報はその後、前記輸送の受取人に送信されることができる
請求項１２に記載の輸送業務を管理するためのシステム。
前記更新情報格納手段は、将来の輸送解決手段の決定を改善するために、外部輸送業者の遂行状況の追跡と、自己保有の輸送手段の遂行状況の追跡と、設備の追跡とに対して用いられる
請求項１２に記載の輸送業務を管理するためのシステム。
輸送業者に出荷要求を提出するために手段をさらに含む
請求項１に記載の輸送業務を管理するためのシステム。
前記提出手段は、前記輸送業者に対して電子情報を用いて請負依頼を送信する
請求項１５に記載の輸送業務を管理するためのシステム。
前記出荷要求の受諾を監視するための手段をさらに含む
請求項１５に記載の輸送業務を管理するためのシステム。
前記監視する手段は、前記輸送業者からの受諾を電子情報として受信する
請求項１７に記載の輸送業務を管理するためのシステム。
前記商品の前記輸送の実際のコストの勘定報告を輸送業者から受信するための手段をさらに含む
請求項１に記載の輸送業務を管理するためのシステム。
前記商品の前記輸送のための実際のコストを輸送業者に支払うために手段をさらに含む
請求項１に記載の輸送業務を管理するためのシステム。
前記商品の前記輸送の実際のコストに対する送り状を依頼主に送付するための手段をさらに含む
請求項１に記載の輸送業務を管理するためのシステム。
フロントエンドユーザインターフェースを形成するための手段をさらに含み、前記フロントエンドユーザインターフェースによって、輸送計画管理者は１つあるいは複数のデータベースと対話し、複数の意思決定規則を定義できるようになる
請求項１に記載の輸送業務を管理するためのシステム。
多数の輸送が存在し、前記フロンエンドユーザインターフェース手段によって、前記輸送計画管理者は、各輸送のためのファイルを検討し直し、修正できるようになる
請求項２２に記載の輸送業務を管理するためのシステム。
輸送業務を管理するための方法であって、前記方法は、
商品の輸送に関連する情報を処理するステップと、
前記処理された情報を用いて前記商品のための輸送解決手段を決定するステップと
を含む輸送業務を管理するための方法。
情報を処理する前記ステップは、注文情報と、輸送業者情報と、制約情報とを処理するステップを含む
請求項２４に記載の輸送業務を管理するための方法。
輸送解決手法を決定する前記ステップは、多数の輸送解決手法を生成するステップを含み、前記解決手法はそれぞれ、前記商品のための代替の荷動きを提案する
請求項２４に記載の輸送業務を管理するための方法。
前記解決手法はそれぞれ、前記商品の前記輸送を実行するために必要とされる１つあるいは複数の特定の輸送業者と設備とを特定する
請求項２６に記載の輸送業務を管理するための方法。
輸送解決手法を決定する前記ステップは、前記商品を輸送するための最も低コストの解決手法を選択する
請求項２６に記載の輸送業務を管理するための方法。
前記出荷品の状態および場所に関する更新情報を受信するステップをさらに含む
請求項２４に記載の輸送業務を管理するための方法。
前記更新情報は、電子形式である
請求項２９に記載の輸送業務を管理するための方法。
前記更新情報を格納するステップをさらに含む
請求項２９に記載の輸送業務を管理するための方法。
前記状態および前記場所に関する前記更新情報は、前記輸送の受取人に送信される
請求項２９に記載の輸送業務を管理するための方法。
将来の輸送解決手段の決定を改善するために、外部輸送業者の遂行状況の追跡と、自己保有の輸送手段の遂行状況の追跡と、設備の追跡とのための前記更新情報を用いることをさらに含む
請求項２９に記載の輸送業務を管理するための方法。
輸送業者に出荷要求を提出するステップをさらに含む
請求項２４に記載の輸送業務を管理するための方法。
出荷要求を提出する前記ステップは、前記輸送業者に電子情報を用いて請負依頼を送信するステップを含む
請求項３４に記載の輸送業務を管理するための方法。
前記出荷要求の１つあるいは複数の受諾に対して前記輸送業者を監視するステップをさらに含む
請求項３４に記載の輸送業務を管理するための方法。
前記商品の前記輸送の実際のコストの勘定報告を輸送業者から受信するステップをさらに含む
請求項２４に記載の輸送業務を管理するための方法。
前記商品の前記輸送のための実際のコストを輸送業者に支払うステップをさらに含む
請求項２４に記載の輸送業務を管理するための方法。
前記商品の前記輸送の実際のコストに対する送り状を依頼主に送付するステップをさらに含む
請求項２４に記載の輸送業務を管理するための方法。
フロントエンドユーザインターフェースを形成するステップをさらに含み、前記フロントエンドユーザインターフェースによって、輸送計画管理者は１つあるいは複数のデータベースと対話し、複数の意思決定アルゴリズムを定義できるようになる
請求項２４に記載の輸送業務を管理するためのシステム。
多数の輸送が存在し、前記フロンエンドユーザインターフェース手段によって、前記輸送計画管理者は、各輸送のためのファイルを検討し直し、修正できるようになる
請求項４０に記載の輸送業務を管理するためのシステム。
輸送業務を管理するための輸送業務管理ネットワークであって、前記ネットワークは、
初期の集荷場所と最終的な配送場所との間の荷動きを計画するための計画モジュールと、
自己保有の輸送手段および／または１つあるいは複数の公共輸送業者を用いて、前記計画された荷動きを管理し、かつ実行するための管理モジュールと、
出荷にかかった全てのコストの発生、勘定報告および後続の支払いのためのコストモジュールとを含む
輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、積荷構成アルゴリズムを用いて、種々の可能性のあるルートおよび中継場所の流れ、輸送の形態および輸送業者からの代替の荷動きを特定し、かつ比較する
請求項４２に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、意思決定規則を有し、前記計画モジュールによって用いられる前記意思決定規則および情報は、輸送計画管理者が、前記システムに対して確立するビジネスパラメータと、外部あるいは自己保有の輸送業者によって提供される輸送業者利用可能性および料金表情報とに由来する
請求項４２に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記輸送管理者によって提供される前記情報は、方針あるいは業務上の要件を含み、前記計画モジュールは、最適な輸送計画に達する前に、種々の計画判断を実行する
請求項４４に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、いくつかの荷動きを１つの輸送積荷に混載する
請求項４２に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、前記輸送積荷のための輸送業者、設備タイプあるいはルートを特定することを含む、前記輸送積荷に対する最良の出荷形態を決定する
請求項４６に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、配送時間要件および他のビジネス制約を満たすルートを決定する
請求項４６に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、前記計画された荷動きを行うための最も低コストの代替手段を特定する
請求項４６に記載の輸送業務を管理するための輸送業務管理ネットワーク。
前記計画モジュールは、効率的な積荷の混載を生成し、注文および輸送計画管理者によって課せられる制約の中で最も低コストの輸送業者および自己保有の輸送手段の割当てを特定する
請求項４９に記載の輸送業務を管理するための輸送業務管理ネットワーク。
フロントエンドインターフェースをさらに含み、前記フロントエンドユーザインターフェースによって、輸送計画管理者は１つあるいは複数のデータベースと対話し、複数の意思決定アルゴリズムを定義できるようになる
請求項４２に記載の輸送業務を管理するための輸送業務管理ネットワーク。
多数の荷動きが存在し、前記フロンエンドユーザインターフェース手段によって、前記輸送計画管理者は、各輸送のためのファイルを検討し直し、修正できるようになる
請求項５１に記載の輸送業務を管理するための輸送業務管理ネットワーク。
輸送業務を管理するためのコンピュータプログラム製品であって、前記コンピュータプログラムは、
初期の集荷場所と最終的な配送場所との間の荷動きを計画するために構成されるコンピュータ読取り可能プログラムコードと、
自己保有の輸送手段および／または１つあるいは複数の公共輸送業者を用いて、前記計画された荷動きを管理し、かつ実行するために構成されるコンピュータ読取り可能プログラムコードと、
輸送中にかかった全ての出荷コストの発生、勘定報告および後続の支払いのためのコンピュータ読取り可能プログラムコードと
を含む輸送業務を管理するためのコンピュータプログラム製品。
複数の注文のための輸送業務を管理するための方法ステップを実行するために機械によって実行可能な命令からなるプログラムを実際に具現する、機械によって読取り可能なプログラム記憶装置であって、
初期の集荷場所と最終的な配送場所との間の荷動きを計画するステップと、
輸送業者を用いて、前記計画された荷動きを実行するステップと、
前記計画された荷動きの実行中にかかった出荷コストを勘定するステップと
を含む機械によって読取り可能なプログラム記憶装置。
前記計画するステップは、各注文を満足するために複数の可能性のある荷動きを生成するサブステップと、前記複数の可能性のある荷動きから最も低コストの荷動きを特定するサブステップとを含む
請求項５４に記載の機械によって読取り可能なプログラム記憶装置。
前記複数の可能性のある荷動きは、起点から終点までの直接ルートと、前記注文がそこを通ってルートを指定される１つの経由地を含む間接ルートと、前記注文がそこを通ってルートを指定される２つ以上の経由地を含む多区間ルートとからなるグループから選択されるタイプを有する
請求項５５に記載の機械によって読取り可能なプログラム記憶装置。
前記経由地は、所与の輸送経路のための１組の予め定義された経由地から選択される
請求項５６に記載の機械によって読取り可能なプログラム記憶装置。
前記可能性のある荷動きは、各注文のための提案されたルートと提案された輸送業者とを特定する
請求項５５に記載の機械によって読取り可能なプログラム記憶装置。
前記実行するステップは、前記計画された荷動きによって指示される提案された輸送業者に請負依頼を送信するサブステップと、前記提案された輸送業者から受諾／辞退応答を受信するサブステップと、前記輸送業者からと、前記荷動きの実行中および実行後の場所から状態更新情報を受信するサブステップとを含む
請求項５４に記載の機械によって読取り可能なプログラム記憶装置。
前記請負依頼は、前記提案された輸送業者に電子情報で送信される
請求項５９に記載の機械によって読取り可能なプログラム記憶装置。
前記提案された輸送業者からの受諾／辞退応答は電子情報で受信される
請求項５９に記載の機械によって読取り可能なプログラム記憶装置。
前記状態更新情報は注文データベースに収容される記録を自動的に更新するために用いられ、前記データベースは、選択された注文の状態を検討し直すために、顧客、輸送業者および場所によってアクセス可能である
請求項５９に記載の機械によって読取り可能なプログラム記憶装置。
前記勘定するステップは、実行された荷動きのための送り状を輸送業者から受信するサブステップと、注文に対する前記送り状に詳述される実際のコストを割り振るサブステップと、輸送業者への支払伝票を作成するサブステップとを含む
請求項５４に記載の機械によって読取り可能なプログラム記憶装置。
前記支払伝票を作成するサブステップは、前記実際のコストと前記計画するステップにおいて計算された予想コストとを比較することと、送り状を注文と照合することと、前記実際のコストが前記予想コストを著しく超えない場合には、関連する輸送業者に前記送り状の金額の支払いを許可することとを含む
請求項６３に記載の機械によって読取り可能なプログラム記憶装置。
複数の注文によって必要とされる荷動きに対する計画、実行よび支払のための管理プログラムモジュールからなるネットワークであって、前記ネットワークは、
問題解決プログラムモジュールであって、可能性のある輸送業者から輸送業者サービス情報を、またネットワークユーザからビジネス優先情報を受け取るように構成され、さらに、前記注文を受け取り、前記輸送業者サービス情報および前記ビジネス優先情報に基づいて、前記注文から最適な荷動きを構成するようになされる、該問題解決プログラムモジュールと、
実行モジュールであって、前記問題解決プログラムモジュールによる前記最適な荷動きと関連付けられる輸送業者に請負依頼を送信し、前記最適な荷動きを実行するためにスケジューリングするように構成され、さらに実行中の荷動きの状態を追跡するように構成される、該実行モジュールと、
運送料支払モジュールであって、輸送業者から受け取った送り状のコストを適切な注文に割り振り、関連する輸送業者に前記送り状のコストの支払いを許可するように構成される、該運送料支払モジュールと
を含むネットワーク。
前記問題解決プログラムは、バッチ実行において前記最適な荷動きを構成し、前記バッチ実行は、各注文を満足するために複数の可能性のある荷動きを生成することと、その後、前記複数の可能性のある荷動きから最も低コストの荷動きを特定することとを含む
請求項６５に記載のネットワーク。
前記問題解決プログラムモジュール、前記実行モジュールおよび前記運送料支払モジュールはそれぞれ、前記可能性のある輸送業者との間でデータを転送するために、少なくとも１つの電子媒体のインターフェースを有する
請求項６６に記載のネットワーク。