JP5902340B1 - 物流・支払代行管理システム - Google Patents

Abstract

【課題】製品メーカーと複数の部品供給ベンダーとの間の請求・支払を代行する。【解決手段】本発明の物流・支払代行管理システムは、製品メーカーから部品供給ベンダーに対して発行されるＰ／Ｏ情報を製品メーカーから受信し、部品供給ベンダーから物流倉庫に入庫する入庫予定情報を管理するとともに、物流倉庫に構成部品が入庫した時点で、Ｐ／Ｏ情報に対して製品メーカーから各部品供給ベンダーへの支払金額（検収金額）を製品メーカーに代わって検収して、製品メーカー及び部品供給ベンダー間のＰ／Ｏ情報に対する請求・支払管理を代行する。分納が行われた際には、Ｐ／Ｏ情報に対して部分検収を行い、部分検収毎に製品メーカー及び部品供給ベンダー間のＰ／Ｏ情報に対する請求・支払を管理する。【選択図】図１

Description

本発明は、製品メーカーと、製品メーカーに構成部品を供給する複数の部品供給ベンダーとの間を仲介し、製品メーカーから部品供給ベンダーへの構成部品の代金支払代行を行う物流・支払代行管理技術に関する。

製品メーカーは、製品を構成する各部品を複数の部品供給ベンダーから調達する。製品メーカーは、部品供給ベンダーに対する部品の発注業務及び部品供給ベンダーから調達（購買）した部品の代金支払業務を行うが、部品供給ベンダーの数が増えれば増えるほど、これらの業務負担が拡大し、人件費などのコストが増える。

また、製品メーカー側では、発注した部品の納期が遅れると、例えば、製品を製造することができないため、各部品供給ベンダーに発注した部品、すなわち、部品在庫の管理が重要である。しかしながら、製品メーカーは、複数の部品供給ベンダー毎に発注に対する構成部品の検収を行って各構成部品の在庫を管理する必要があり、煩雑かつ手間が掛かるものであった。

特開２０１２−２３８３０１号公報

本発明の目的は、複数の部品供給ベンダーそれぞれから出荷された構成部品が入庫し、製品メーカーの納品先に構成部品を出庫する物流倉庫を介した構成部品の入出庫管理を行いつつ、製品メーカーと部品供給ベンダーとの間の請求・支払を代行する物流・支払代行管理システムを提供することにある。

（１）本発明の物流・支払代行管理システムは、製品の構成部品を発注する製品メーカーと、発注された前記構成部品を前記製品メーカーに供給する複数の部品供給ベンダーと、前記部品供給ベンダーから出荷された前記構成部品が入庫し、前記製品メーカーの納品先に前記構成部品が出庫される物流倉庫を介した入出庫を管理する物流業者とが連携し、発注された前記構成部品の前記製品メーカーから前記部品供給ベンダーへの代金支払処理を行う。

前記物流・支払代行管理システムは、前記製品メーカーから前記部品供給ベンダーそれぞれに対して発行される前記構成部品のＰ／Ｏ情報を、前記部品供給ベンダーへの発行に伴って前記製品メーカーのメーカー側装置から受信するＰ／Ｏ受付部と、受信した前記Ｐ／Ｏ情報を、前記部品供給ベンダーそれぞれから前記物流倉庫に入庫される前記構成部品の入庫予定情報として記憶する記憶部と、前記物流倉庫に入庫する前記構成部品を検収する作業員によって操作される倉庫側装置を介して入力され、前記Ｐ／Ｏ情報に基づいて前記作業員が検収した前記構成部品の検収入庫数を、前記入庫予定情報の入庫実績として登録する入出庫管理部と、前記検収入庫数と予め取得された前記構成部品の単価情報とに基づいて前記Ｐ／Ｏ情報毎に検収金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額の入金先が前記物流業者を窓口として集約された入金依頼を前記メーカー側装置に送信する入金処理と、複数の前記部品供給ベンダー毎に、前記物流業者から前記部品供給ベンダーに前記検収金額を送金するための送金処理と、を行う支払代行制御部と、を有する。

そして、前記入出庫管理部は、前記検収入庫数が前記Ｐ／Ｏ情報の発注数よりも少ないか否かを判別し、前記検収入庫数が前記発注数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注数と部分検収入庫数との差から未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を発注数とする分納用のＰ／Ｏ情報を生成し、前記支払代行制御部は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報の部分検収金額に対する前記入金処理及び前記送金処理を行う。

本発明は、複数の部品供給ベンダーそれぞれから出荷された構成部品が入庫し、製品メーカーの納品先に構成部品を出庫する物流倉庫を介した構成部品の入出庫を管理する物流業者が、製品メーカーと部品供給ベンダーとの間のＰ／Ｏ情報に対する代金の請求・支払を代行する。

すなわち、製品メーカーから部品供給ベンダーに対して発行されるＰ／Ｏ情報を製品メーカーから受信し、部品供給ベンダーから物流倉庫に入庫する入庫予定情報を管理する。部品供給ベンダーから物流倉庫に実際に入庫した現物の構成部品の個数をカウントして、入庫予定情報（Ｐ／Ｏ情報）に入庫実績として反映する。このため、入庫実績、言い換えれば、物流倉庫に入庫した時点で、複数の部品供給ベンダーから供給される構成部品の在庫が、物流業者を窓口として一元化（集約）されるとともに、複数の部品供給ベンダーから供給される構成部品を、物流業者が物流倉庫への入庫実績に基づいて一括して検収することができる。

従来、製品メーカーは、Ｐ／Ｏ（Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒ）の発行後、納品先においてＰ／Ｏ毎に部品供給ベンダーから出荷された構成部品の検収を行い、納品後の構成部品の在庫確定に基づいて部品供給ベンダーへの支払金額を確定し、その後、確定された支払金額（検収金額）の支払いを部品供給ベンダーに対して行っていた。つまり、製品メーカーは、納品先での検収の度に、発行した複数のＰ／Ｏ情報それぞれに対する支払金額を確定し、その都度部品供給ベンダーへの支払いを行う必要があった。このため、製品メーカーの取引相手となる部品供給ベンダーの数が、数十社、数百社と多くなると、Ｐ／Ｏ情報に対する支払処理も多数の部品供給ベンダーそれぞれに行う必要があり、非常に手間が掛かり、人件費などのコストが増大していた。

しかしながら、本発明では、物流倉庫で検収された構成部品は、物流倉庫から製品メーカーへの納品が確定したＰ／Ｏ情報に対する在庫であり、入庫実績が反映された入庫予定情報は、製品メーカーの在庫情報となる。したがって、物流倉庫に構成部品が入庫した時点で、Ｐ／Ｏ情報に対して製品メーカーから各部品供給ベンダーへの支払金額（検収金額）を、製品メーカーに代わって物流業者が確定することができる。

このように、物流業者が代行して、物流倉庫に入庫した時点（入庫実績）で、Ｐ／Ｏ情報に対して製品メーカーから各部品供給ベンダーへの支払金額（検収金額）を確定（算出）し、かつＰ／Ｏ情報に対して各部品供給ベンダーに支払うべき検収金額の入金先が物流業者を窓口として集約された入金依頼及び複数の部品供給ベンダー毎に、物流業者から送金するための送金処理を行うので、Ｐ／Ｏ情報に対する請求・支払管理を、物流業者を介して一元的に管理することができ、人件費などのコストを低減することができる。

一方、部品供給ベンダーは、Ｐ／Ｏ情報に基づいて発注数分の構成部品を製品メーカーに供給するが、例えば、構成部品の生産管理上、Ｐ／Ｏ情報の発注数に対する構成部品の出荷を複数に分けて行う分納が行われることがある。分納は、製品メーカーにとっては、例えば、発注数に満たなくても部品供給ベンダーから供給可能な供給数を在庫として早期に確定することができ、製品の製造管理を柔軟に行うことができる。しかしながら、分納によって先行して構成部品を早期に納品しても、Ｐ／Ｏ情報の発注数を満たすまでＰ／Ｏ情報全体の検収を行うことができず、残りの納品が完了するまでＰ／Ｏ情報に対する検収、すなわち、部品供給ベンダーへの検収金額の支払いが行われない。

そこで、本発明では、検収入庫数がＰ／Ｏ情報の発注数よりも少ないか否かを判別し、検収入庫数が発注数よりも少ないと判別されたとき、検収入庫数を部分検収とする部分入庫実績を登録し、部分検収されたＰ／Ｏ情報の部分検収金額に対する上記入金処理及び上記送金処理を行う。このように構成することで、分納毎にその都度、部分検収分の検収金額の支払いを部品供給ベンダーに対して行うことができる。

また、発注数と部分検収入庫数との差から未検収入庫数を算出し、部分検収入庫数が登録されたＰ／Ｏ情報に紐付き、算出された未検収入庫数を発注数とする分納用のＰ／Ｏ情報を生成するので、Ｐ／Ｏ情報全体の発注数を満たすまで入庫予定情報として管理しつつ、未検収入庫数に対して構成部品の入庫があったとき、先行して部分検収されたＰ／Ｏ情報と関連させつつ、個別に入庫の検収及び検収金額の確定を行い、上記入金処理及び上記送金処理を行うことができる。

（２）上記（１）の物流・支払代行管理システムにおいて、前記入出庫管理部は、前記Ｐ／Ｏ情報の発注数を前記物流倉庫への入庫予定である発注残数として、前記検収入庫数が前記発注残数よりも少ないか否かを判別し、前記検収入庫数が前記発注残数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注残数から前記検収入庫数を差し引いた前記未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を新たな発注残数とする前記分納用のＰ／Ｏ情報を生成することができ、前記部分検収入庫数が登録された後に同じ前記Ｐ／Ｏ情報に対して入力された検収入庫数を、前記分納用のＰ／Ｏ情報に対する入庫実績として登録することができる。そして、前記支払代行制御部は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報と前記分納用のＰ／Ｏ情報の各部分検収金額に対する前記入金処理及び前記送金処理を、個別に行うことができる。

（３）上記（１）又は（２）の物流・支払代行管理システムにおいて、前記支払代行制御部は、複数の前記部品供給ベンダーの前記Ｐ／Ｏ情報それぞれの検収金額を合計した合計金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額を集約した前記合計金額の前記入金依頼を生成して、前記メーカー側装置に送信することができる。

（４）上記（３）の物流・支払代行管理システムにおいて、前記記憶部は、前記部品供給ベンダー毎に、前記検収金額の支払期日が設定された部品供給ベンダー情報を記憶することができる。このとき、前記支払代行制御部は、前記物流倉庫から出庫された前記構成部品が前記製品メーカーの納品先で検収された納品先検収日を前記メーカー側装置から受信し、前記納品先検収日に属する計上月と前記支払期日とに基づいて前記送金処理における複数の前記部品供給ベンダーへの送金期日を算出し、前記送金期日が同一の前記Ｐ／Ｏ情報を抽出して前記合計金額を算出して前記入金処理を行うとともに、前記送金期日に、抽出された前記Ｐ／Ｏ情報に該当する前記部品供給ベンダーそれぞれに対して前記送金処理を行うことができる。

（５）上記（４）の物流・支払代行管理システムにおいて、前記入庫実績が登録された前記入庫予定情報に基づいて納品予定情報を生成して前記メーカー側装置に提供する納品予定情報提供部をさらに備えることができる。前記支払代行制御部は、前記Ｐ／Ｏ情報毎に前記納品先検収日が入力された前記納品予定情報を前記メーカー側装置から受信することができる。

（６）上記（１）〜（４）の物流・支払代行管理システムにおいて、前記メーカー側装置から前記構成部品毎の納品先を含む商品マスタ情報を受信して前記記憶部に記憶する商品マスタ管理部を、さらに有することができる。前記商品マスタ管理部は、前記製品メーカーまたは前記納品先から予め提供される前記構成部品の保税管理情報を前記構成部品に関連付けた前記商品マスタ情報を、前記倉庫側装置に送信することができる。前記倉庫側装置は、前記物流倉庫に入庫された前記構成部品のうち同一納品先の前記構成部品を含む前記Ｐ／Ｏ情報それぞれを１つのグループとして前記納品先に納品するための梱包明細情報であって、前記グループ内の前記構成部品に対応する前記保税管理情報を含む梱包明細リストを生成するとともに、前記梱包明細リストに含まれる前記構成部品それぞれに貼られ、前記グループに属する前記構成部品を識別するための出荷ラベル情報を生成する出荷管理部と、所定の印刷装置を通じて前記梱包明細リスト及び前記出荷ラベル情報を出力させる印刷制御部と、を備えることができる。

第１実施形態の物流・支払代行管理システムを説明するための模式図である。 第１実施形態の物流・支払代行管理システムの物流業者を仲介した製品メーカーと複数の部品供給ベンダーとの間の物流管理及び支払代行管理を説明するための模式図である。 第１実施形態の物流・支払代行管理システムのネットワーク構成及び各装置の構成ブロック図である。 第１実施形態のＰ／Ｏデータの一例（ａ）、商品マスタ情報の一例（ｂ）、及び保税管理情報を含む商品マスタ情報の一例（ｃ）を示す図である。 第１実施形態の物流・支払代行管理システムの商品マスタ情報及び保税管理情報の処理フローを示す図である。 第１実施形態の物流・支払代行管理システムのＰ／Ｏデータに基づく入出庫管理の処理フローを示す図である。 第１実施形態の入庫予定情報（ａ）、入出庫登録情報（ｂ）、部品供給ベンダー向け支払明細情報（ｃ）、及び製品メーカー向け請求明細情報（ｄ）の一例を示す図である。 第１実施形態の同一納品先に納品される複数の構成部品のパッキングリスト及び出荷ラベル情報の一例を示す図である。 図６に示した入庫実績登録処理の詳細処理及び分納処理を説明するための処理フローを示す図である。 第１実施形態の物流・支払代行管理システムの支払代行処理フローを示す図である。 第１実施形態の部品供給ベンダー情報の一例を示す図である。 第１実施形態の部品供給ベンダーへの各支払期日に応じた支払代行処理を説明するための図である。

以下、実施形態につき、図面を参照して説明する。

（第１実施形態）
図１から図１２は、第１実施形態を示す図である。図１は、本実施形態の物流・支払代行管理システムを説明するための模式図である。

製品メーカーは、Ｐ／Ｏ（Ｐｕｒｃｈａｓｅ Ｏｒｄｅｒ）を複数の部品供給ベンダーに発行し、部品供給ベンダーは、Ｐ／Ｏによる発注（購入注文）に基づく商品、例えば、製品メーカーが製造・販売する製品を構成する構成部品を、製品メーカーに供給する。

このような製品メーカーと複数の部品供給ベンダーとの間には、部品供給ベンダーから製品メーカーの納品先までの現物の構成部品の物流と、製品メーカーに納品される構成部品に対する代金の請求・支払とが発生する。本実施形態の物流・支払代行管理システムは、図１に示すように、複数の部品供給ベンダーそれぞれから出荷された構成部品が入庫し、製品メーカーの納品先に構成部品を出庫する物流倉庫を介した構成部品の入出庫を管理する物流業者が、製品メーカーと部品供給ベンダーとの間を仲介して、Ｐ／Ｏに対する代金の請求・支払を代行する。

まず、図１を参照して、本実施形態の物流・支払代行管理システムの全体フローについて説明する。物流業者は、製品メーカーから部品供給ベンダーに発行されるＰ／Ｏを、部品供給ベンダーへの発行に伴って事前に受け付ける。受け付けたＰ／Ｏは、部品供給ベンダーから物流業者の物流倉庫に入庫される入庫予定情報として登録される。

部品供給ベンダーは、Ｐ／Ｏに基づく数量の構成部品を、ベンダーの出荷拠点から物流業者（物流倉庫）に出荷する。物流業者は、入庫予定情報として、部品供給ベンダーから物流倉庫に入庫される構成部品のＰ／Ｏが予め登録されているので、物流倉庫の作業員は、部品供給ベンダーから物流倉庫に実際に入庫した現物の構成部品をＰ／Ｏを用いてマッチングし、構成部品の入庫数をカウントして、入庫予定情報（Ｐ／Ｏデータ）に入庫実績として登録する。

物流業者は、入庫した構成部品を製品メーカーの納品先に出庫するとともに、入庫実績、言い換えれば、物流倉庫に構成部品が入庫した時点で、Ｐ／Ｏデータに対して製品メーカーから部品供給ベンダーへの支払金額（検収金額）を、製品メーカーに代わって確定する。物流業者は、製品メーカーに代わって部品供給ベンダーとの間で、確定した支払金額の確認を行う。

一方、物流業者は、運輸業として物流倉庫からＰ／Ｏに対する構成部品を出庫し、製品メーカーの納品先まで送り届ける物流業務を行う。製品メーカーは、納品先でＰ／Ｏに対する構成部品の検収を行う。納品先での検収後、物流業者は部品供給ベンダーとの間で確認した支払金額に対する代金を、部品供給ベンダーに代わって製品メーカーに確認し、入金依頼を行う。製品メーカーは、物流業者の口座に部品供給ベンダーに対して支払うべき代金を入金する。物流業者は、Ｐ／Ｏに対する支払金額を、部品供給ベンダーの口座に送金する。

従来、製品メーカーは、Ｐ／Ｏの発行後、納品先においてＰ／Ｏ毎に部品供給ベンダーから出荷された構成部品の検収を行い、部品供給ベンダーへの支払金額を確定し、その後、確定された支払金額（検収金額）の支払いを部品供給ベンダーに対して行っていた。つまり、製品メーカーは、納品先での検収の度に、発行した複数のＰ／Ｏそれぞれに対する支払金額を確定し、その都度部品供給ベンダーへの支払いを行う必要があった。このため、製品メーカーの取引相手となる部品供給ベンダーの数が、数十社、数百社と多くなると、Ｐ／Ｏに対する支払処理も多数の部品供給ベンダーそれぞれに行う必要があり、非常に手間が掛かり、人件費などのコストが増大していた。

しかしながら、本実施形態では、物流倉庫で検収された構成部品は、物流倉庫から製品メーカーへの納品が確定したＰ／Ｏに対する在庫となり、入庫実績が反映された入庫予定情報は、製品メーカーの在庫情報となる。すなわち、製品メーカーから部品供給ベンダーに対して発行されるＰ／Ｏを製品メーカーから受信し、部品供給ベンダーから物流倉庫に入庫する入庫予定情報を管理する。部品供給ベンダーから物流倉庫に実際に入庫した現物の構成部品を、入庫予定情報（Ｐ／Ｏ）に入庫実績として反映する。このため、入庫実績、言い換えれば、物流倉庫に入庫した時点で、複数の部品供給ベンダーから供給される構成部品の在庫が、物流業者を窓口として一元化（集約）されるとともに、複数の部品供給ベンダーから供給される構成部品を、物流業者が物流倉庫への入庫実績に基づいて一括して検収することができる。

このため、物流倉庫に構成部品が入庫した時点で、Ｐ／Ｏに対して製品メーカーから各部品供給ベンダーに支払うべき金額（検収金額）を、製品メーカーに代わって物流業者が確定することができる。

図２に示すように、本実施形態の物流・支払代行管理システムは、複数の部品供給ベンダーそれぞれから出荷された構成部品が入庫し、物流倉庫に入庫した時点で、複数の部品供給ベンダーから供給される構成部品の在庫が、物流業者を窓口として集約される。そして、物流業者が、物流倉庫への入庫実績に基づいて複数の部品供給ベンダーから供給される構成部品を一括して検収し、物流業者が代行して、Ｐ／Ｏに対して製品メーカーから各部品供給ベンダーへの支払金額を確定する。

製品メーカーは、Ｐ／Ｏに対して部品供給ベンダーそれぞれに支払うべき検収金額の窓口が物流業者に集約される。物流業者は、複数の部品供給ベンダーそれぞれに代わって、各検収金額を合計した代金の入金依頼を製品メーカーに対して行うとともに、製品メーカーから集約して入金された代金を、Ｐ／Ｏに基づいて物流業者から部品供給ベンダー毎に送金する。

このように、物流業者が、製品メーカーから受け付けたＰ／Ｏに基づく構成部品の入庫予定に対して入庫実績を登録して、複数の部品供給ベンダーから供給される構成部品を製品メーカーへの納品が確定した在庫として一括して管理するとともに、物流業者を介して集約される各部品供給ベンダーと製品メーカーとの間の物流に則して、製品メーカーと複数の部品供給ベンダーとの間のＰ／Ｏに対する請求・支払管理を、一元的に管理することができる。このため、製品メーカーは、取引する部品供給ベンダーの数が多くても、物流業者が代行（仲介）してＰ／Ｏに基づく発注部品の在庫管理及び請求・支払管理が一括して行われるため、人件費などのコストを低減することができる。

次に、図３を参照して、本実施形態の物流・支払代行管理システムのネットワーク構成及び各装置の機能について説明する。物流・支払代行管理システムは、物流倉庫を介した構成部品の入出庫を管理する物流業者側管理装置（物流・支払代行管理装置に相当する）３００と、物流業者側管理装置とネットワークを介して接続され、物流倉庫で部品供給ベンダーから入庫した構成部品を検収する作業員によって操作される倉庫側管理装置（倉庫側装置に相当する）４００と、を含んで構成されている。

また、物流・支払代行管理システムは、製品メーカー側管理装置（メーカー側装置に相当する）１００及び複数のベンダー側管理装置（ベンダー側装置に相当する）２００とネットワークを介して接続することができる。

製品メーカー側管理装置１００は、通信部１１０、制御部１２０及び記憶部１３０を含んで構成されている。通信部１１０は、各装置間でのネットワークを介した通信制御を行う。制御部１２０は、Ｐ／Ｏ制御部１２１、商品マスタ管理部１２２及び入金処理部１２３を備えている。

Ｐ／Ｏ制御部１２１は、部品供給ベンダーに発行するＰ／Ｏデータを生成し、ベンダー側管理装置２００及び物流業者側管理装置３００の双方に送信するＰ／Ｏ発行処理を行う。図４（ａ）は、Ｐ／Ｏデータの一例を示す図である。Ｐ／Ｏデータは、区分（新規注文／変更／取消）、部品供給ベンダーの識別情報である仕入先ＩＤ、ベンダー名、購買担当者、納期、発注する構成部品の品目ＩＤ及び品目名（品名１：日本語、品名２：英語）、Ｐ／Ｏ番号、注文数量、数量単位（発注単位数量）、単価、通貨などが含まれる。製品メーカーは、製品の製造プランに応じて、適宜Ｐ／Ｏデータを発行して、部品供給ベンダーから構成部品を調達する。

商品マスタ管理部１２２は、Ｐ／Ｏデータに含まれる構成部品を商品マスタとして管理する。図４（ｂ）は、商品マスタ情報の一例であり、品目ＩＤ毎に、品名（品名１，２）、仕入先ＩＤ、仕入先名、数量単位、単価、単重（所定単位（重量、面積、長さ、容積、数量）当たりの重量）、通貨、仕向け地を含んでいる。仕向け地は、部品供給ベンダーから供給される構成部品の納品先（納品場所）である。製品メーカーは、事前に部品供給ベンダーと購買契約しており、部品供給ベンダーに発注する各品目をマスタ管理するとともに、納品先である仕向け地を品目毎に予め登録することができる。

入金処理部１２３は、Ｐ／Ｏデータに対して複数の部品供給ベンダーに支払う支払金額の入金依頼を物流業者側管理装置３００から受け付け、物流業者の口座に入金するための処理を行う。

ベンダー側管理装置２００は、通信部２１０、制御部２２０及び記憶部２３０を含んで構成されている。通信部２１０は、各装置間でのネットワークを介した通信制御を行う。制御部２２０は、Ｐ／Ｏ受付部２２１、発送管理部２２２及び請求処理部２２３を備えている。

Ｐ／Ｏ受付部２２１は、製品メーカー側管理装置１００から送信されるＰ／Ｏデータを受信する。部品供給ベンダーは、製品メーカーから受信したＰ／Ｏデータに基づいて、発注された構成部品を物流業者の物流倉庫に向けて出荷する出荷管理を行う。部品供給ベンダーは、出荷拠点や出荷倉庫からＰ／Ｏデータの発注数分の構成部品を、出荷伝票と共に物流倉庫に向けて発送する。発送管理部２２２は、Ｐ／Ｏデータに基づいて物流倉庫に向けて出荷する構成部品のＰ／Ｏ番号、出荷数（発注数）及び仕入先ＩＤ（出荷元である部品供給ベンダー）を含む出荷伝票を、所定の印刷装置で印刷するように制御する。

請求処理部２２３は、物流業者側管理装置３００との間で、Ｐ／Ｏデータに対する支払代金の確認処理及び請求書発行処理を行う。また、発行された請求書に対して物流業者からの部品供給ベンダーの口座に送金された送金確認処理を行う。

物流業者側管理装置３００は、通信部３１０、制御部３２０及び記憶部３３０を含んで構成されている。通信部３１０は、各装置間でのネットワークを介した通信制御を行う。制御部３２０は、Ｐ／Ｏ受付部３２１、商品マスタ管理部３２２、入出庫情報制御部３２３及び支払代行制御部３２４を備えている。

製品メーカー側管理装置１００とベンダー側管理装置２００との間でやり取りされるＰ／Ｏデータは、ネットワークを介して物流業者側管理装置３００にも送信される。Ｐ／Ｏ受付部３２１は、製品メーカーから部品供給ベンダーそれぞれに対して発行される各Ｐ／Ｏデータを、当該部品供給ベンダーへの発行に伴って製品メーカー側管理装置１００から受信する。記憶部３３０は、受信したＰ／Ｏデータを記憶する。ここで、製品メーカーから受け付けるＰ／Ｏデータは、部品供給ベンダーそれぞれから物流倉庫に入庫される構成部品の入庫予定情報として記憶部３３０に記憶され、管理される。

商品マスタ管理部３２２は、製品メーカー側管理装置１００から提供される図４（ｂ）に示した商品マスタ情報を受信して記憶部３３０に記憶する。また、商品マスタ管理部３２２は、構成部品に対応する品目毎に保税管理情報を取得して、商品マスタ情報に登録する処理を行う。

例えば、日本から海外を仕向け地として、物流倉庫に入庫された構成部品を納品する場合、船舶や飛行機で輸入される輸入貨物は、一旦保税地域に搬入され、税関に対して輸入申告を行い、輸入申請が完了した後に、輸入貨物を保税地域外の納品場所まで輸送することができる。つまり、保税地域毎に輸入申告を行い、必要な許可を得なければ、保税地域から製品メーカーの納品先まで輸送して納品することができない。このため、事前に輸入申請を行って予め必要な許可（輸入ライセンス）を得ておくことで、保税地域を経由した製品メーカーへの納品を円滑に行うことができる。

そこで、製品メーカーは、納品先に対応する保税地域毎に各品目の輸入申告を事前に行い、輸入ライセンスとして保税管理情報を取得することができる。物流業者は、品目毎に輸入ライセンスを予め取得しておくことで、海外を仕向け地とする納品の場合に取得済の輸入ライセンスを含む各品目の輸入通関書類を作成し、作成した輸入通関書類と一緒にＰ／Ｏデータに対する構成部品を仕向け地に輸送することで、保税地域での通関許可がスムーズに行われ、納品までのリードタイムを短縮することができる。また、保税地域での通関許可がスムーズに行われることから、納品先での検収までのリードタイムを短くすることができ、納品先での検収に基づくＰ／Ｏに対する代金支払いの遅延が防止され、例えば、部品供給ベンダーへの代金支払いを期日通りに行うことができる。

図５は、物流・支払代行管理システムの商品マスタ情報及び保税管理情報の処理フローを示す図である。図５に示すように、製品メーカー側管理装置１００の商品マスタ管理部１２２は、商品マスタ情報を物流業者側管理装置３００に送信する（Ｓ１０１）。なお、製品メーカー側管理装置１００は、例えば、定期的にまたは商品マスタ情報に対する品目の新規登録、更新、削除などのタイミングで、適宜物流業者側管理装置３００に送信することができる。また、物流業者側管理装置３００が製品メーカー側管理装置１００に対して、商品マスタ情報の取得要求を送信し、取得要求に基づいて商品マスタ情報を物流業者側管理装置３００に提供するように構成することができる。

物流業者側管理装置３００の商品マスタ管理部３２２は、製品メーカー側管理装置１００から商品マスタ情報を受信すると、商品マスタの更新・登録処理を行う（Ｓ３０１）。商品マスタ管理部３２２は、例えば、受信した商品マスタ情報の品目ＩＤをキーに、記憶部３３０に記憶されている商品マスタ情報を検索する。検索でヒットしない場合、該当する品目ＩＤに対応する商品は、新規商品であると判別し（Ｓ３０２のＹＥＳ）、記憶部３３０の商品マスタ情報に新規登録（追加）する（Ｓ３０３）。

商品マスタ管理部３２２は、新規登録された品目ＩＤの構成部品に対し、保税管理情報を取得するために、製品メーカーの納品先端末に保税管理情報の照合要求を行う（Ｓ３０４）。納品先端末は、仕向け地の保税地域からＰ／Ｏデータに対する構成部品が輸送される納品先で操作されるコンピュータ装置である。納品先端末は、照合要求された品目ＩＤに対応する保税管理情報を、物流業者側管理装置３００に送信する（Ｓ３０４１）。商品マスタ管理部３２２は、図４（ｃ）に示すように、納品先端末から受信した保税管理情報を、対応する品目ＩＤに関連付けて商品マスタ情報に登録する（Ｓ３０５）。商品マスタ管理部３２２は、図４（ｃ）に示した商品マスタ情報を、倉庫側管理装置４００に提供することができる。

なお、保税管理情報は、製品メーカー側管理装置１００が、物流業者側管理装置３００に提供するように構成してもよい。製品メーカー側で予め取得する保税管理情報は、製品メーカー側管理装置１００と納品先端末と共有することができるからである。保税地域から構成部品が納品される納品先が、Ｐ／Ｏデータに対する輸入ライセンスを管理しているときは、上述のように納品先端末との間で、保税管理情報の照合及び登録を行えばよい。

また、日本国内の部品供給ベンダーから日本国内の仕向け地に、Ｐ／Ｏデータに対する構成部品を納品する場合などは、保税管理情報が必要ない。この場合、ステップＳ３０４からＳ３０５の処理が省略される。商品マスタ管理部３２２は、例えば、商品マスタ情報に含まれる仕向け地が、日本国内であるか否かを判別し、日本国内でなければ、ステップＳ３０４からＳ３０５を行い、日本国内であれば、ステップＳ３０４からＳ３０５の処理を省略するように制御することができる。

入出庫情報制御部３２３は、製品メーカーから提供されたＰ／Ｏデータを入庫予定情報として倉庫側管理装置４００に送信し、倉庫側管理装置４００からＰ／Ｏデータに対する入出庫情報を受信して、部品供給ベンダーから物流倉庫に入庫された構成部品の入出庫管理を行う。

図６は、本実施形態のＰ／Ｏデータに基づく入出庫管理の処理フローを示す図である。まず、図６に示すように、製品メーカー側管理装置１００は、Ｐ／Ｏ発行処理を行い（Ｓ１１０）、部品供給ベンダー及び物流業者の双方に、同じＰ／Ｏデータを送信する。ベンダー側管理装置２００（Ｐ／Ｏ受付部２２１）は、製品メーカー側管理装置１００から送信されるＰ／Ｏデータを受信し（Ｓ２１０）、受信したＰ／Ｏデータに基づいて、発注された構成部品を物流業者の物流倉庫に向けて出荷する出荷処理を行う（Ｓ２１１）。

一方、物流業者側管理装置３００（Ｐ／Ｏ受付部３２１）は、製品メーカー側管理装置１００からＰ／Ｏデータを受信する（Ｓ３１０）。このとき、Ｐ／Ｏデータには、区分が含まれているので、区分「削除」であるか否かを判別する（Ｓ３１１）。物流業者側管理装置３００は、受信したＰ／Ｏデータの区分が「削除」であるときは（Ｓ３１１のＹＥＳ）、既に入庫予定情報として記憶部３３０に記憶されているＰ／Ｏデータの中からＰ／Ｏ番号をキーに検索して、該当するＰ／Ｏデータを削除する（Ｓ３１３）。受信したＰ／Ｏデータの区分が「削除」でないと判別されたときは（Ｓ３１１のＮＯ）、入庫予定情報として新規に登録したり、既に入庫予定情報としてＰ／Ｏ番号が同じＰ／Ｏデータが登録されていれば、上書きして更新したりする（Ｓ３１２）。

次に、物流倉庫には、部品供給ベンダーから出荷伝票とともに、構成部品が入庫される。物流倉庫の作業員は、入庫した現物の構成部品の個数と出荷伝票に記載された出荷数とをマッチングし、入庫検収を行う。

倉庫側管理装置４００は、入出庫管理部４２１、出荷管理部４２２及び印刷制御部４２３を備えている。入出庫管理部４２１は、物流業者側管理装置３００から入庫予定情報を受信し、記憶部４３０に記憶する（Ｓ３１４）。物流業者側管理装置３００の入出庫情報制御部３２３は、所定のタイミングで倉庫側管理装置４００に入庫予定情報を送信したり、入出庫管理部４２１が、入庫実績を登録するための所定の操作が行われたときに、物流業者側管理装置３００に入庫予定情報の取得要求を行い、物流業者側管理装置３００から入庫予定情報を取得したりすることができる。

入出庫管理部４２１は、記憶部４３０に記憶されている入力画面を表示装置に表示する。作業員は、入庫検収結果、すなわち、入庫予定情報の各Ｐ／Ｏデータに対する入庫実績を倉庫側管理装置４００に入力する。入力画面には、仕入先ＩＤやＰ／Ｏ番号を入力する入力欄を設けることができ、作業員は、部品供給ベンダーが発行した出荷伝票の仕入先ＩＤまたはＰ／Ｏ番号を入力する。

例えば、入力画面に仕入先ＩＤが入力されると、入力された仕入先ＩＤに該当するＰ／Ｏデータを記憶部４３０から抽出して入力画面に表示したり、Ｐ／Ｏ番号が入力されると、該当するＰ／Ｏ番号のＰ／Ｏデータを入力画面に表示したりする表示制御を行う。図７（ａ）は、入庫予定情報の一例を示す図であり、複数の部品供給ベンダーに発行された各Ｐ／Ｏデータを含む態様を示している。なお、入力された仕入先ＩＤやＰ／Ｏ番号に該当するＰ／Ｏデータが記憶部４３０で検索されないときは、エラー処理（登録不可通知）などを行うことができる。

Ｐ／Ｏデータが表示される入力画面には、検収した入庫数を入力するための入力欄が含まれ、作業員は、検収したＰ／Ｏ番号に対応するＰ／Ｏデータ毎に、検収日、検収入庫数を入力する。入力された検収日、検収入庫数は、入庫予定情報に紐付く入庫実績として、記憶部４３０に記憶される（Ｓ４１０）。

図７（ｂ）は、入庫予定情報に入庫実績情報が登録された入庫登録情報の一例を示す図である。入庫実績情報には、登録された検収入庫数とともに、検収日、検収金額が含まれている。入出庫管理部４２１は、検収入庫数が登録されると、予め取得される構成部品の単価（Ｐ／Ｏデータに含まれる構成部品の単価または、商品マスタ情報に記憶されている単価）を用いて、Ｐ／Ｏデータに対する検収金額を算出し、入庫実績に基づく検収金額として入庫予定情報に関連付けて記憶部４３０に記憶する。なお、検収日は、入庫実績情報が登録された日を自動的に入力したり、作業員によって入力されたりする。

次に、作業員は、物流倉庫に入庫して検収された構成部品を、納品先へ出庫する出荷処理を行う（Ｓ４１１）。まず、出荷管理部４２２は、入庫実績の登録が完了した後、未出庫の複数のＰ／Ｏデータを抽出し、抽出された複数のＰ／Ｏデータを仕向け地（納品先）毎にグループ化する。具体的には、出荷管理部４２２は、図４（ｃ）に示した保税管理情報を含む商品マスタ情報を、物流業者側管理装置３００から取得する。取得するタイミングは、出荷処理を行うタイミング又はそれ以前の任意のタイミングであってもよい。

出荷管理部４２２は、商品マスタ情報に基づいて、物流倉庫に入庫された複数の構成部品を納品先毎にグループ化し、同一納品先の複数のＰ／Ｏデータをグルーピングする。例えば、作業員が、倉庫側管理装置４００から出荷処理ボタンを入力すると、出荷管理部４２２は、未出庫、すなわち、出庫日が確定（入力）されていないＰ／Ｏデータを抽出し、出荷処理画面に表示する。

出荷管理部４２２は、未出庫のＰ／Ｏデータが表示された出荷処理画面において、商品マスタ情報に基づいて納品先を選択できるように制御し、作業員は、１つの納品先を選択する。出荷管理部４２２は、選択された納品先に紐付く未出庫のＰ／Ｏデータを抽出し、同一納品先の出荷リストを生成して表示する。作業員は、出荷リストが表示された画面から、出庫日、納品予定日を入力し、出庫登録を行う。出荷管理部４２２は、入力された出庫日及び納品予定日を、入庫実績が登録された入庫予定情報に関連付けてＰ／Ｏデータ毎に記憶する。

また、出荷管理部４２２は、同一納品先に納品される複数の構成物品がグループ化された出荷リストに対し、出荷ラベル情報を生成する。つまり、同一納品先の出荷リスト毎に各出荷グループ及び出荷グループに属する各構成部品を識別するための出荷ラベルを生成する。なお、出荷ラベルは、例えば、出荷リスト（同一納品先）毎に異なる親ラベルと、親ラベルに紐付き、出荷リスト内のＰ／Ｏデータ（構成部品）毎に異なる子ラベルと、を含むように構成することができる。

図８は、同一納品先に納品される複数の構成部品の出荷リスト及び出荷ラベル情報の一例を示す図である。図８の例において、例えば、同一の仕向け地「中国のＡ工場」に出荷される複数の構成部品がグループ化された出荷リストが生成され、仕向け地を識別する親ラベルとして出荷ラベル「Ｑ０００１」及び子ラベルとしてラベル枝番「０００１、０００２・・・」が関連付けられている。また、出荷リストは、図４（ｂ）又は図４（ｃ）に示した商品マスタ情報を基に生成することができ、Ｐ／Ｏ番号、品目ＩＤ、品名１、品名２、検収入庫数に対応する出荷数量、単価、単重、保税管理情報が含まれている。

また、図８に示す出荷リストでは、単重及び保税管理情報が含まれている。出荷リストは、同一の納品先に出荷される複数の構成部品を梱包したものと捉えることができ、パッキングリスト（梱包明細）として利用することができる。上述のように、納品先が海外である場合、保税地域での通関処理がある。このため、保税管理情報を含む出荷リスト（梱包明細情報に相当する）は、輸入通関書類（パッキングリストに相当する）として活用することができる。

印刷制御部４２３は、倉庫側管理装置４００に接続されるプリンタ等の印刷装置での、出荷リスト及び出荷ラベルの印刷制御を行う。作業員は、生成された出荷リスト及び出荷ラベル情報を印刷するための操作を行うと、出荷管理部４２２は、印刷制御部４２３に印刷装置を通じて出力するように指示し、印刷制御部４２３を介して印刷装置から出荷リスト及び出荷ラベルがプリントアウトされる。

作業員は、上述した出荷処理後に、入出庫報告書を作成し、物流業者側管理装置３００に提供する。ここで、入出庫報告書は、入庫実績、出庫日及び納品予定日が登録されたＰ／Ｏデータである。このため、出荷管理部４２２は、作業員から入出庫報告書作成のための操作に基づいて、入庫実績（入庫数量、発注残、検収日、検収完了数量、検収金額）、出庫日及び納品予定日が登録されたＰ／Ｏデータを記憶部４３０から抽出し、入出庫データを生成する（Ｓ４１２）。出荷管理部４２２は、生成した入出庫データを物流業者側管理装置３００に送信する。

入出庫情報制御部３２３は、入出庫データを受信し、入庫予定情報のＰ／Ｏデータ毎に、入庫実績（入庫数量、発注残、検収日、検収完了数量、検収金額）、出庫日及び納品予定日を関連付けて入出庫登録情報を生成し、記憶部３３０に記憶する（Ｓ３１５、図７（ｂ）参照）。

また、入出庫情報制御部３２３は、納品予定情報提供部として機能することができる。入出庫情報制御部３２３は、倉庫側管理装置４００から受信した入出庫データに基づいて、製品メーカー側に提供する納品予定情報を生成し（Ｓ３１６）、製品メーカー側管理装置１００及び納品先端末に送信する（Ｓ３１７）。納品予定情報は、製品メーカーの納品先に納品が確定した在庫情報であるとともに、納品先検収情報として利用される。例えば、図７（ｂ）の例において、入庫実績、出庫日及び納品予定日が登録された入庫予定情報に、納品先検収チェック用の入力欄を追加した納品予定情報を生成することができる。納品先検収チェック欄には製品メーカーの納品先での検収納品日や構成部品の検収納品数が入力され、検収納品日及び検収納品数を含む納品予定情報を、製品メーカー側（製品メーカー側管理装置１００又は納品先端末）から受信することで、納品先での検収状況を把握することができる。

ここで、倉庫側管理装置４００の入庫実績登録処理（図６のステップＳ４１０）の分納処理について説明する。上述のように、部品供給ベンダーは、Ｐ／Ｏに基づいて発注数分の構成部品を製品メーカーに供給するが、例えば、構成部品の生産管理上、Ｐ／Ｏの発注数に対する構成部品の出荷を複数回に分けて行う分納が行われることがある。

分納は、製品メーカーにとっては、例えば、発注数に満たなくても部品供給ベンダーから供給可能な供給数を在庫として早期に確定することができ、製品の製造管理を柔軟に行うことができる。しかしながら、分納によって先行して構成部品を納品しても、Ｐ／Ｏの発注数を満たすまでＰ／Ｏ情報全体の検収を行うことができず、残り（発注残）の納品が完了するまでＰ／Ｏに対する検収、すなわち、部品供給ベンダーへの検収金額の支払いが行われない。

そこで、本実施形態では、検収入庫数がＰ／Ｏの発注数よりも少ないときでも、発注数に満たない検収入庫数を部分検収して入庫実績を登録し、部分検収されたＰ／Ｏの部分検収金額を確定できるようにする。このように構成することで、分納毎にその都度、部分検収分の検収金額の支払いを部品供給ベンダーに対して行うことができる。

図９は、図６の入庫実績登録処理の詳細処理及び分納処理を説明するための処理フローを示す図である。まず、入出庫管理部４２１は、検収入庫数を入力する入力画面において、発注残が表示されるように制御することができる。例えば、発注数「１０００」に対して入力された検収入庫数が「８００」であるとき、発注残数として「２００」を表示する。つまり、発注数に対して同じ数の検収入庫数が入力されたときは、発注残数として「０」が表示され、検収入庫数が入力されていない状態では、発注残数として発注数が表示される。

図９に示すように、倉庫側管理装置４００の入出庫管理部４２１は、Ｐ／Ｏデータが表示される入力画面に検収入庫数が入力されると（Ｓ４１０１のＹＥＳ）、入力された検収入庫数と発注残数が同じであるか否かを判別する（Ｓ４１０２）。

検収入庫数と発注残数とが同じであれば、入出庫管理部４２１は、Ｐ／Ｏデータに対する検収金額を算出し、検収入庫数と共に入庫実績に基づく検収金額を入庫予定情報に関連付けて記憶部４３０に記憶する。

一方、検収入庫数と発注残数とが同じでないと判別されたとき、ステップＳ４１０３に進み、入出庫管理部４２１は、入力された検収入庫数が発注残数よりも少ないか否かを判別する。少ないと判別された場合（Ｓ４１０３のＹＥＳ）、入出庫管理部４２１は発注残数に満たない検収入庫数を部分検収し、検収入庫数と単価に基づいて部分検収金額を算出する（Ｓ４１０４）。

そして、入出庫管理部４２１は、部分検収に伴う分納処理を行う（Ｓ４１０５）。具体的には、入出庫管理部４２１は、発注残数から入力された検収入庫数を差し引いたＰ／Ｏデータに対する未入庫数を算出する。そして、部分入庫実績が登録されたＰ／Ｏデータに紐付き、算出された未入庫数を発注残数とする分納用のＰ／Ｏデータを生成する。

このとき、入出庫管理部４２１は、部分入庫実績が登録されたＰ／Ｏデータと分納用のＰ／Ｏデータとを紐付けるため、同じＰ／Ｏ番号に対して枝番を生成し、Ｐ／Ｏデータに付与することができる。つまり、発注残数がある（発注残数が０でない）Ｐ／Ｏデータに対して生成される同じＰ／Ｏ番号の分納用Ｐ／Ｏデータに、枝番を付与する。

枝番は、例えば、発注数「１０００」のＰ／Ｏデータ全体に対する分納番号（分納回数）を示す識別情報として生成することができる。図７（ｂ）に示すように、Ｐ／Ｏ番号「Ｐ０００２」は、発注数「１０００」に対して２回に分けて分納されている。最初の入庫数が「８００」であり、「８００」が部分検収入庫数、「２００」が発注残数として登録され、Ｐ／Ｏ番号「Ｐ０００２」に対して枝番「０００１」が付与される。最初の入庫数「８００」が部分検収されたとき、同じＰ／Ｏ番号「Ｐ０００２」に対して枝番「０００２」が付与された分納用Ｐ／Ｏデータが生成される。残りの「２００」が入庫したとき、分納用Ｐ／Ｏデータに対して検収入庫数「２００」が登録され、発注残数が「０」となり、Ｐ／Ｏ番号が「Ｐ０００２」のＰ／Ｏデータに対して部分検収が行われる。

このように本実施形態では、Ｐ／Ｏデータの発注数を物流倉庫への入庫予定である発注残数として管理し、入出庫管理部４２１は、入力された検収入庫数が発注残数よりも少ないか否かを判別する。検収入庫数が発注残数よりも少ないと判別されたとき、発注残数から検収入庫数を差し引いた未入庫数を算出する。入出庫管理部４２１は、入力された検収入庫数をＰ／Ｏデータに対する部分入庫実績として登録し、部分入庫実績が登録されたＰ／Ｏデータに紐付き、算出された未入庫数を発注残数とする分納用のＰ／Ｏデータを生成し、入庫予定情報として登録する。このため、Ｐ／Ｏデータに発注残数がある状態でも、部分入庫実績が登録されたＰ／Ｏデータを部分的に独立して検収することができる。

入出庫管理部４２１は、部分検収入庫数が登録された後に同じＰ／Ｏデータに対して入力された検収入庫数を、分納用のＰ／Ｏデータに対する入庫実績として登録する。そして、このときも入出庫管理部４２１は、入力された検収入庫数が新たな発注残数よりも少ないか否かを判別する。検収入庫数が発注残数よりも少ないと判別されたとき、分納用のＰ／Ｏデータの発注残数から検収入庫数を差し引いた未入庫数を算出する。入出庫管理部４２１は、入力された検収入庫数を分納用のＰ／Ｏデータに対する部分入庫実績として登録し、部分入庫実績が登録された分納用のＰ／Ｏデータに紐付き、算出された未入庫数を発注残数とする新たな分納用のＰ／Ｏデータ（Ｐ／Ｏ番号が「Ｐ０００２」で枝番が「０００３」の分納用のＰ／Ｏデータ）を生成し、入庫予定情報として登録する。

なお、図９のステップＳ４１０３で、入出庫管理部４２１は、入力された検収入庫数が発注残数よりも多いと判別されたとき（Ｓ４１０３のＮＯ）は、所定のアラート処理を行う（Ｓ４１０６）。アラート処理としては、例えば、検収入庫数がＰ／Ｏデータの発注数より多いため、Ｐ／Ｏデータの発注数の確認や修正を促すメッセージを出力することができる。また、検収入庫数を入力（登録）できない旨のメッセージを出力することもできる。入庫数が多い場合、後述する支払代行処理における検収金額が、Ｐ／Ｏデータの発注数に基づく金額よりも高くなるため、部品供給ベンダー側の出荷ミスなどを確認する必要があるからである。

次に、支払代行制御部３２４は、支払代行処理を遂行する。図１０は、本実施形態の支払代行処理フローを示す図である。図１０に示すように、物流業者側管理装置３００は、製品メーカーへの構成部品の納品（出庫）後、納品先端末から納品先検収情報を取得する（Ｓ３０４２）。ここで、納品先検収情報とは、例えば、図６のステップＳ３１７で製品メーカー側（納品先を含む）に提供された納品先検収チェック用の入力欄が追加された納品予定情報である。

支払代行制御部３２４は、納品先端末から納品先検収情報を受信すると、検収マッチング処理を行う（Ｓ３２０）。検収マッチング処理は、納品先から送信される納品先検収情報、記憶部３３０に記憶されている入出庫登録情報及び商品マスタ情報との間で、Ｐ／Ｏデータ毎に、少なくとも構成部品の数及び構成部品の単価が一致しているか否かを判別する。

納品先では、例えば、物流業者側管理装置３００から提供された納品予定情報に基づいて、Ｐ／Ｏデータ毎に、納品された現物の構成部品の検収納品数、納品先検収日を入力することができる。また、納品予定情報に含まれる構成部品の単価も製品メーカーから発行されたＰ／Ｏデータに基づいて照合することができる。例えば、部品供給ベンダーから物流倉庫への入庫後、又は物流倉庫から納品先へ構成部品が出荷された後、Ｐ／Ｏデータの内容に変更があったときは、納品先での検収時に、例えば、変更された（最新の）Ｐ／Ｏデータに基づいて単価を変更し、納品検収情報に反映することができる。

支払代行制御部３２４は、Ｐ／Ｏデータ毎に、納品先から送信される納品先検収情報の検収納品数及び単価と、入出庫登録情報の検収入庫数及び単価とをマッチングする。また、商品マスタ情報の単価も、これらの情報とマッチングすることもできる。支払代行制御部３２４は、少なくとも納品先検収情報と入出庫登録情報との間で、検収納品数や単価に不一致が生じている場合（Ｓ３２１のＹＥＳ）、検収納品数又は単価に不一致が生じているＰ／Ｏデータを抽出して不一致リストを生成する。そして、生成された不一致リストを、製品メーカー側管理装置１００及びベンダー側管理装置２００に提供し（Ｓ３２０１）、確認を行う。

不一致リストに含まれるＰ／Ｏデータの検収納品数や単価のミスマッチは、製品メーカーと部品供給ベンダーとの間で確認・協議され、正確な単価及び検収納品数の確認情報が、例えば、製品メーカーから提供される。支払代行制御部３２４は、不一致リストのＰ／Ｏデータ毎に、確認情報に含まれる単価及び検収納品数を、入出庫登録情報に反映する。また、単価が変更されていれば、該当する品目ＩＤ毎に、商品マスタ情報の単価を更新する（Ｓ３２０２）。

支払代行制御部３２４は、確認情報に基づいて、入出庫登録情報及び商品マスタ情報のデータ修正処理後、再度、ステップＳ３２０の検収マッチング処理を行い、Ｐ／Ｏデータに対する物流倉庫への入庫実績と、納品先での検収納品数や単価とが一致するように処理する。なお、製品メーカーから提供される確認情報には、納品先検収情報が間違っている場合を含むことができ、この場合、再度、訂正された納品先検収情報を納品先端末や製品メーカー側管理装置１００から受信して、ステップＳ３２０の検収マッチング処理を行うことができる。

このように本実施形態では、Ｐ／Ｏデータに対する構成部品の検収金額を、物流倉庫へ入庫した時点で確定されるが、納品先での最終的な検収情報に基づいて、製品メーカーと複数の各部品供給ベンダーとの間を物流業者が仲介して一括して確認を行い、物流倉庫への入庫実績に基づく検収金額と納品先での検収金額との間のミスマッチを解消する。このため、製品メーカーは、複数の部品供給ベンダーとの間での納品先検収情報に基づく検収金額の確認を行う必要がなく、部品供給ベンダーへの支払金額を円滑に確定することができる。製品メーカーと複数の部品供給ベンダーとの間で個別に、納品先検収情報に対する一致／不一致を確認する必要がないため、製品メーカー側での納品先検収から検収金額確定までのリードタイムが短縮され、例えば、部品供給ベンダーに対して期日通りに代金の支払いを行うことができる。

また、納品先検収情報は、製品メーカー側に提供される納品先検収チェック用の入力欄が追加された納品予定情報であり、記憶部３３０に記憶されている入出庫登録情報のデータ構成（データ構造）に準じたものである。このため、納品先検収情報と入出庫登録情報とは、図７（ａ）、図７（ｂ）に示すように、入庫予定情報及び入庫実績情報の各データを共有（リンク）しており、ステップＳ３２０における検収マッチング処理におけるデータ同士の付き合わせ（更新等）を、共通するデータ構造に基づいて容易に行うことができる。例えば、納品先検収情報と入出庫登録情報とでデータ構造が異なる場合、どちらか一方のデータ構成に統一するなどのデータクレンジングが必要となるが、本実施形態では、データクレンジングが不要となり、スピーディな検収マッチング処理が可能になるともに、データクレンジングの際の人手を介した訂正作業が不要となるため、データ修正に伴う人為的なミスを抑制することができる。

支払代行制御部３２４は、物流倉庫への入庫実績に基づく検収金額と納品先での検収金額との間のミスマッチが解消された後に、納品先検収情報とマッチングされた入出庫登録情報に基づいて、Ｐ／Ｏデータ毎に検収金額を確定する（Ｓ３２２）。なお、ステップＳ３２１において、納品先検収情報の検収納品数及び単価と、入出庫登録情報の検収入庫数及び単価とがマッチングしたＰ／Ｏデータは（Ｓ３２１のＮＯ）、検収入庫数や単価を訂正することなく、検収金額が確定される。また、納品先検収情報の検収納品日や構成部品の検収納品数は、Ｐ／Ｏデータ毎に入出庫登録情報に反映することができる。

支払代行制御部３２４は、ステップＳ３２２でＰ／Ｏデータ毎に検収金額が確定されると、部品供給ベンダー毎に支払明細（送金明細）情報を生成する（Ｓ３２３）。図７（ｃ）は、部品供給ベンダー向けの支払明細情報の一例を示す図である。支払代行制御部３２４は、記憶部３３０に記憶されている入出庫登録情報に基づいて、例えば、図７（ｃ）に示す支払明細情報を、部品供給ベンダー別に抽出し、各部品供給ベンダー向けの支払明細情報を生成することができる。図７（ｃ）の例では、仕入先ＩＤ「Ｂ０００１」に対し、Ｐ／Ｏ番号が「Ｐ０００１」及び「Ｐ０００２」を含む支払明細情報を生成することができる。

支払代行制御部３２４は、生成された支払明細情報を各ベンダー側管理装置２００に提供する（Ｓ３２４）。部品供給ベンダー（ベンダー側管理装置２００の請求処理部２２３）は、物流業者側管理装置３００から受信した支払明細情報に基づいて、Ｐ／Ｏデータ毎に検収金額の確認（マッチング）を行う。請求処理部２２３は、支払明細情報に基づく請求書発行処理を行い（Ｓ２２０）、発行した請求書データを、物流業者側管理装置３００に送信する。つまり、ステップＳ３２４における支払明細情報を提供し、各部品供給ベンダーに対して支払明細に基づく請求書発行依頼を行う。

一方、支払代行制御部３２４は、ステップＳ３２３において、部品供給ベンダー毎の支払明細（送金明細）情報の生成に伴い、製品メーカー向け請求明細情報を生成する。図７（ｄ）は、製品メーカー向け請求明細情報の一例を示す図である。つまり、図７（ｃ）に示した各部品供給ベンダーへの支払明細情報が、製品メーカー向けに集約された情報となり、各部品供給ベンダーへの支払金額が製品メーカーへの請求金額となる。本実施形態の製品メーカー向け請求明細情報は、複数の部品供給ベンダーに支払うべき検収（請求）金額の入金先が物流業者を窓口として集約された入金依頼となる。

支払代行制御部３２４は、入金依頼である製品メーカー向け請求明細情報を製品メーカー側管理装置１００に送信する（Ｓ３２５）。製品メーカー側管理装置１００の入金処理部１２３は、製品メーカー向け請求明細情報を受信し、例えば、製品メーカー向け請求明細情報の各Ｐ／Ｏデータの各検収金額を、製品メーカーの口座から物流業者の口座に入金するための入金処理を行う（Ｓ１２０）。製品メーカー側管理装置１００には、事前に物流業者の口座情報が記憶されており、入金処理部１２３は、製品メーカー向け請求明細情報及び物流業者の口座情報に基づいて、入金処理を行うことができる。

支払代行制御部３２４は、製品メーカーから物流業者の口座への入金確認を行う（Ｓ３２６）。例えば、支払代行制御部３２４は、物流業者の口座への入金金額情報を所定の金融機関から取得することができる。支払代行制御部３２４は、製品メーカーからの入金が確認された後、複数の部品供給ベンダー毎に、物流業者から部品供給ベンダーの口座に、Ｐ／Ｏデータに対する検収金額の送金処理を行う（Ｓ３２７）。このとき、一の部品供給ベンダーに対して複数のＰ／Ｏデータに対する検収金額の送金を行う場合、これらの検収金額を合計した合計金額を、部品供給ベンダーの口座に送金することができる。また、本実施形態の送金処理には、例えば、物流業者の口座が開設されている金融機関に対し、各部品供給ベンダーの金融機関の口座に検収金額を振り込むための送金依頼処理が含まれる。支払代行制御部３２４は、各部品供給ベンダーの金融機関の口座情報、検収金額に相当する振込金額、後述する支払期日に相当する振込依頼日などを含む振込依頼データを生成し、インターネット等のネットワークを介して金融機関に送信したり、生成された振込依頼データをＦＡＸ等で金融機関に送信したりすることができる。

なお、支払代行制御部３２４は、ステップＳ３２２からステップＳ３２８までの支払代行処理において、図７（ｃ）及び図７（ｄ）に示すように、部分検収入庫数が登録されたＰ／Ｏデータ（Ｐ／Ｏ番号「Ｐ０００２」、枝番「０００１」）の部分検収金額に対しても入金処理及び送金処理を行う。

図１１は、部品供給ベンダー情報の一例を示す図である。部品供給ベンダー情報は、予め記憶しておくことができる。例えば、物流業者側管理装置３００は、部品供給ベンダーの登録画面を介して部品供給ベンダー情報を入力する機能を提供し、管理者等が登録画面を介して入力した部品供給ベンダー情報を記憶部３３０に記憶する。部品供給ベンダー情報としては、Ｐ／Ｏデータと関連する仕入先ＩＤ、仕入先名、住所、連絡先と共に、支払先銀行名、支払先銀行口座などを含むことができる。

支払代行制御部３２４は、入金処理及び送金処理後、製品メーカー向け請求明細情報に基づく入金依頼に対する入金履歴及び各部品供給ベンダーへの送金履歴を含む入金・送金情報を生成して、記憶部３３０に記憶する（Ｓ３２８）。入金履歴としては、例えば、入金対象の複数のＰ／Ｏ番号を含む入金依頼Ｎｏに基づく入金金額、入金日などがある。送金履歴としては、各Ｐ／Ｏ番号に紐付く部品供給ベンダーそれぞれに送金された送金金額及び送金日などがある。

図１２は、部品供給ベンダーへの各支払期日に応じた支払代行処理を説明するための図である。例えば、各部品供給ベンダーは、例えば、納品後３０日、６０日、１２０日などの支払期日を設定することができる。ここで、納品後３０日の起算日は、製品メーカー側での納品先検収日を適用することができる。

例えば、下請代金支払遅延等防止法に該当する部品供給ベンダーに対して、納品先検収日と締日とから算出される計上月から３０日以内に納品された構成部品に対する代金の支払いを行う必要がある。本実施形態では、このような法律に基づく支払期日や、製品メーカーと部品供給ベンダーとの間で予め設定された支払期日を管理（設定）し、部品供給ベンダーへの代金の支払いが期日通りに行われるように管理している。

なお、支払期日の設定は、例えば、部品供給ベンダー情報の登録画面において、支払期日欄に所定の支払期日を入力することで、設定することができる。また、下請代金支払遅延等防止法の対象となる部品供給ベンダーに対しては、例えば、「下請法」チェックボックスを登録画面に表示させ、「下請法」チェックボックスがチェックされた部品供給ベンダーには、支払期日「３０日」を自動的に設定するように構成することができる。

図１２に示すように、支払代行制御部３２４は、納品先から送信される納品先検収情報の納品先検収日を、Ｐ／Ｏデータ毎に記憶すると共に、納品先検収日に基づいて部品供給ベンダーへの代金支払月、言い換えれば、製品メーカーから代金支払いに対する検収金額の入金月を表す計上月を算出することができる。計上月の算出は、納品先検収日と締日とから算出することができる。例えば、締日が毎月２９日の場合、納品先検収日がその月の２９日以前であれば、計上月を当月として計算し、３０日以後であれば、計上月を来月として計算することができる。なお、締日及び計上月などの経理上の計算等は、適宜設定することができる。

支払代行制御部３２４は、Ｐ／Ｏデータ毎に計算された計上月と、部品ベンダー情報に設定されている支払期日とに基づいて、送金日（送金期日）を算出することができる。例えば、計上月が５月で支払期日が３０日の部品供給ベンダーのＰ／Ｏデータに対し、翌月の６月末を送金日として算出することができる。支払代行制御部３２４は、入出庫登録情報に含まれるＰ／Ｏデータの内、納品先検収日が登録されているＰ／Ｏデータを対象に、納品先検収日及び締日から算出される計上月及び計上月と支払期日に基づいて算出される送金日を、設定する。計上月及び送金日の計算及び設定の処理は、適宜設定された所定のタイミングで行うことができる。

支払代行制御部３２４は、例えば、送金日（送金期日）に対して設定される製品メーカーの入金日に基づいて、図１０のステップＳ３２３〜Ｓ３２５を行うことができる。製品メーカーからの入金を前提として、部品供給ベンダーへの代金支払いを行う場合は、例えは、送金日よりも数日前を入金日として設定し、かつ入金日よりも前に製品メーカーに請求明細情報を提供することができる。

図１２の例において、支払代行制御部３２４は、６月末の送金日に対して、６月２５日を入金日として設定した製品メーカー向け請求情報を生成する。このとき、支払代行制御部３２４は、図１２に示すように、６月分として複数の部品供給ベンダーのＰ／Ｏデータそれぞれの検収金額を合計した入金合計金額を算出し、複数の部品供給ベンダーに支払うべき各検収金額を集約した入金合計金額の入金依頼を生成することができる。

このように、支払代行制御部３２４は、納品先検収日に属する計上月と各部品供給ベンダー毎に設定される異なる支払期日とに基づいて、送金処理における複数の部品供給ベンダーへの送金期日を算出し、送金期日が同一のＰ／Ｏデータを抽出して複数の部品供給ベンダーのＰ／Ｏデータそれぞれの検収金額を合計した入金合計金額を算出し、製品メーカー向け請求明細情報を生成して提供している。また、部品供給ベンダーに対しては、算出された送金期日に、部品供給ベンダーそれぞれに対して各Ｐ／Ｏデータに対する送金処理を行う。

したがって、製品メーカーは、Ｐ／Ｏデータに対して各部品供給ベンダーに支払うべき検収金額が物流業者を窓口として集約されて入金依頼を受け、物流業者が複数の部品供給ベンダー毎に送金するための送金処理を行うので、Ｐ／Ｏデータに対する請求・支払管理を、物流業者を介して一元的に管理することができ、人件費などのコストを低減することができる。

さらに、図１２の例に示すように、本実施形態では、分納によって部分検収Ｐ／Ｏデータが月跨ぎで入金処理及び送金処理が個別に行われている。具体的には、Ｐ／Ｏ番号「Ｐ０００２」、枝番「０００１」のＰ／Ｏデータが、５月末を送金日とした入金処理及び送金処理が行われ、同じＰ／Ｏ番号で枝番が「０００２」の分納用のＰ／Ｏデータが、翌月の６月末を送金日として入金処理及び送金処理が行われる。

つまり、本実施形態では、上述した分納処理により、部分検収されたＰ／Ｏデータに対して、分納用のＰ／Ｏデータを生成し、部分検収後に同じＰ／Ｏデータ（Ｐ／Ｏ番号）に対して入力された検収入庫数を、分納用のＰ／Ｏデータに対する入庫実績として登録するので、Ｐ／Ｏデータ全体の発注数を満たすまで入庫予定情報として管理しつつ、未検収入庫数に対して構成部品の入庫があったとき、先行して部分検収されたＰ／Ｏデータと関連させつつ、個別の入庫の検収及び検収金額の確定が確定される。

したがって、支払代行制御部３２４は、部分検収入庫数が登録されたＰ／Ｏデータ（枝番「０００１」）と分納用のＰ／Ｏデータ（枝番「０００２」）の各部分検収金額に対する入金処理及び送金処理を個別に行うことができる。

分納によって先行して構成部品を早期に納品しても、Ｐ／Ｏデータの発注数を満たすまでＰ／Ｏデータ全体の検収を行うことができず、残りの納品が完了するまでＰ／Ｏデータに対する検収、すなわち、部品供給ベンダーへの検収金額の支払いが行われない状況を解消することができ、分納毎にその都度、部分検収分の検収金額の支払いを部品供給ベンダーに対して行うことができる。

以上、上述した実施形態において、図６及び図９に示した入庫情報の登録処理（分納処理を含む）及び出庫情報の登録処理は、倉庫側管理装置４００で行われていたが、物流業者側管理装置３００で行うように構成することもできる。

例えば、物流業者側管理装置３００の入出庫情報制御部３２３が、入出庫管理部４２１及び出荷管理部４２２の機能を備えるように構成する。このとき、入出庫管理部４２１は、入力画面の表示制御及び作業員によって入力される入力情報の入力制御を行う。入出庫情報制御部３２３は、入力画面に、仕入先ＩＤやＰ／Ｏ番号が入力されると、入力された仕入先ＩＤやＰ／Ｏ番号に該当するＰ／Ｏデータを記憶部３３０から抽出して、倉庫側管理装置４００に送信する。入出庫管理部４２１は、受信したＰ／Ｏデータを、入力画面に表示する。

入出庫管理部４２１は、Ｐ／Ｏデータが表示された入力画面において、検収したＰ／Ｏ番号に対応するＰ／Ｏデータ毎に、検収日、検収入庫数が入力されると、物流業者側管理装置３００に送信し、入出庫情報制御部３２３が、倉庫側管理装置４００から受信した検収日、検収入庫数を、入庫予定情報に紐付く入庫実績として、記憶部３３０に記憶する。また、入出庫情報制御部３２３は、Ｐ／Ｏデータに含まれる構成部品の単価または、商品マスタ情報に記憶されている単価と、入力画面から入力された検収入庫数とを用いて、Ｐ／Ｏデータに対する検収金額を算出し、入庫実績に基づく検収金額として入庫予定情報に関連付けて記憶部３３０に記憶する。

さらに、入出庫情報制御部３２３は、倉庫側管理装置４００から出荷処理要求を受信すると、出庫日が確定（入力）されていないＰ／Ｏデータを記憶部３３０から抽出し、倉庫側管理装置４００は、出荷処理画面に表示する。入出庫管理部４２１は、未出庫のＰ／Ｏデータが表示された出荷処理画面において、１つの納品先が選択されると、物流業者側管理装置３００に選択された納品先を送信する。入出庫情報制御部３２３は、選択された納品先に紐付く未出庫のＰ／Ｏデータを抽出し、同一納品先の出荷リストを生成して倉庫側管理装置４００に送信する。入出庫管理部４２１は、出荷リストが表示された画面から、出庫日、納品予定日が入力されると、物流業者側管理装置３００に送信し、入出庫情報制御部３２３は、受信した出庫日、納品予定日を入庫実績が登録された入庫予定情報に関連付けてＰ／Ｏデータ毎に記憶する。

また、入出庫情報制御部３２３は、同様に、同一納品先に納品される複数の構成物品がグループ化された出荷リストに対し、出荷ラベル情報を生成したり、単重及び保税管理情報が含まれる出荷リストを生成したりして、倉庫側管理装置４００に送信することができる。倉庫側管理装置４００では、受信した出荷ラベル情報や単重及び保税管理情報が含まれる出荷リストを、印刷制御部４２３を介して印刷装置で印刷するように制御することができる。なお、この場合、入出庫データが上述のように物流業者側管理装置３００に記憶されるため、入出庫報告書作成処理を省略することができる。作業員は、例えば、入出庫報告書作成に対応する入出庫完了ボタンなどを選択し、倉庫側管理装置４００が入出庫完了要求を物流業者側管理装置３００に送信することで、入出庫報告書の作成を完了させることができる。

また、上記装置１００、２００、３００、４００は、画面や情報の表示制御を行うブラウザ機能を備えることができる。また、ハードウェア構成として上述以外にも、液晶ディスプレイなどの表示装置、装置全体（各部）の制御を司るＣＰＵ、メモリ（主記憶装置）、マウス、キーボード、タッチパネル、スキャナー等の操作入力手段、プリンタ、スピーカなどの出力手段、補助記憶装置（ハードディスク等）等を備えることができる。

また、本発明の各機能は、プログラムによって実現可能であり、各機能を実現するために予め用意されたコンピュータプログラムが補助記憶装置に格納され、ＣＰＵ等の制御部が補助記憶装置に格納されたプログラムを主記憶装置に読み出し、主記憶装置に読み出された該プログラムを制御部が実行することで、コンピュータ装置に、物流業者側管理装置３００、倉庫側管理装置４００の各部の機能を動作させることができる。他方、本発明の各機能は、各々個別の制御装置で構成することができ、複数の制御装置を直接に又はネットワークを介して接続して、例えば、物流業者側管理装置３００を構成することもできる。

また、上記プログラムは、コンピュータ読取可能な記録媒体に記録された状態で、コンピュータに提供することも可能である。コンピュータ読取可能な記録媒体としては、ＣＤ−ＲＯＭ等の光ディスク、ＤＶＤ−ＲＯＭ等の相変化型光ディスク、ＭＯ（Magnet Optical）やＭＤ(Mini Disk)などの光磁気ディスク、フロッピー（登録商標）ディスクやリムーバブルハードディスクなどの磁気ディスク、コンパクトフラッシュ（登録商標）、スマートメディア、SDメモリカード、メモリスティック等のメモリカードが挙げられる。また、本発明の目的のために特別に設計されて構成された集積回路（ICチップ等）等のハードウェア装置も記録媒体として含まれる。

１００ 製品メーカー側管理装置
１１０ 通信部
１２０ 制御部（ＣＰＵ）
１２１ Ｐ／Ｏ制御部
１２２ 商品マスタ管理部
１２３ 入金処理部
１３０ 記憶部
２００ ベンダー側管理装置
２１０ 通信部
２２０ 制御部（ＣＰＵ）
２２１ Ｐ／Ｏ受付部
２２２ 発送管理部
２２３ 請求処理部
２３０ 記憶部
３００ 物流業者側管理装置
３１０ 通信部
３２０ 制御部（ＣＰＵ）
３２１ Ｐ／Ｏ受付部
３２２ 商品マスタ管理部
３２３ 入出庫情報制御部
３２４ 支払代行制御部
３３０ 記憶部
４００ 倉庫側管理装置
４１０ 通信部
４２０ 制御部（ＣＰＵ）
４２１ 入出庫管理部
４２２ 出荷管理部
４２３ 印刷制御部
４３０ 記憶部

Claims (8)

1. 製品の構成部品を発注する製品メーカーと、発注された前記構成部品を前記製品メーカーに供給する複数の部品供給ベンダーと、前記部品供給ベンダーから出荷された前記構成部品が入庫し、前記製品メーカーの納品先に前記構成部品が出庫される物流倉庫を介した入出庫を管理する物流業者とが連携し、発注された前記構成部品の前記製品メーカーから前記部品供給ベンダーへの代金支払処理を行う物流・支払代行管理システムであって、
   前記製品メーカーから前記部品供給ベンダーそれぞれに対して発行される前記構成部品のＰ／Ｏ情報を、前記部品供給ベンダーへの発行に伴って前記製品メーカーのメーカー側装置から受信するＰ／Ｏ受付部と、
   受信した前記Ｐ／Ｏ情報を、前記部品供給ベンダーそれぞれから前記物流倉庫に入庫される前記構成部品の入庫予定情報として記憶する記憶部と、
   前記物流倉庫に入庫する前記構成部品を検収する作業員によって操作される倉庫側装置を介して入力され、前記Ｐ／Ｏ情報に基づいて前記作業員が検収した前記構成部品の検収入庫数を、前記入庫予定情報の入庫実績として登録する入出庫管理部と、
   前記検収入庫数と予め取得された前記構成部品の単価情報とに基づいて前記Ｐ／Ｏ情報毎に検収金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額の入金先が前記物流業者を窓口として集約された入金依頼を前記メーカー側装置に送信する入金処理と、複数の前記部品供給ベンダー毎に、前記物流業者から前記部品供給ベンダーに前記検収金額を送金するための送金処理と、を行う支払代行制御部と、を有し、
   前記入出庫管理部は、前記検収入庫数が前記Ｐ／Ｏ情報の発注数よりも少ないか否かを判別し、前記検収入庫数が前記発注数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注数と部分検収入庫数との差から未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を発注数とする分納用のＰ／Ｏ情報を生成し、
   前記支払代行制御部は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報の部分検収金額に対する前記入金処理及び前記送金処理を行う、
   ことを特徴とする物流・支払代行管理システム。
2. 前記入出庫管理部は、前記Ｐ／Ｏ情報の発注数を前記物流倉庫への入庫予定である発注残数として、前記検収入庫数が前記発注残数よりも少ないか否かを判別し、前記検収入庫数が前記発注残数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注残数から前記検収入庫数を差し引いた前記未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を新たな発注残数とする前記分納用のＰ／Ｏ情報を生成し、
   さらに、前記入出庫管理部は、前記部分検収入庫数が登録された後に同じ前記Ｐ／Ｏ情報に対して入力された検収入庫数を、前記分納用のＰ／Ｏ情報に対する入庫実績として登録し、
   前記支払代行制御部は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報と前記分納用のＰ／Ｏ情報の各部分検収金額に対する前記入金処理及び前記送金処理を、個別に行うことを特徴とする請求項１に記載の物流・支払代行管理システム。
3. 前記支払代行制御部は、複数の前記部品供給ベンダーの前記Ｐ／Ｏ情報それぞれの検収金額を合計した合計金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額を集約した前記合計金額の前記入金依頼を生成して、前記メーカー側装置に送信することを特徴とする請求項１又は２に記載の物流・支払代行管理システム。
4. 前記記憶部は、前記部品供給ベンダー毎に、前記検収金額の支払期日が設定された部品供給ベンダー情報を記憶しており、
   前記支払代行制御部は、前記物流倉庫から出庫された前記構成部品が前記製品メーカーへの納品先で検収された納品先検収日を前記メーカー側装置から受信し、前記納品先検収日に属する計上月と前記支払期日とに基づいて前記送金処理における複数の前記部品供給ベンダーへの送金期日を算出し、前記送金期日が同一の前記Ｐ／Ｏ情報を抽出して前記合計金額を算出して前記入金処理を行うとともに、前記送金期日に、抽出された前記Ｐ／Ｏ情報に該当する前記部品供給ベンダーそれぞれに対して前記送金処理を行うことを特徴とする請求項３に記載の物流・支払代行管理システム。
5. 前記入庫実績が登録された前記入庫予定情報に基づいて納品予定情報を生成して前記メーカー側装置に提供する納品予定情報提供部をさらに備え、
   前記支払代行制御部は、前記Ｐ／Ｏ情報毎に前記納品先検収日が入力された前記納品予定情報を前記メーカー側装置から受信することを特徴とする請求項４に記載の物流・支払代行管理システム。
6. 前記メーカー側装置から前記構成部品毎の納品先を含む商品マスタ情報を受信して前記記憶部に記憶する商品マスタ管理部を、さらに有し、
   前記商品マスタ管理部は、前記製品メーカーまたは前記納品先から予め提供される前記構成部品の保税管理情報を前記構成部品に関連付けた前記商品マスタ情報を、前記倉庫側装置に送信し、
   前記倉庫側装置は、
   前記物流倉庫に入庫された前記構成部品のうち同一納品先の前記構成部品を含む前記Ｐ／Ｏ情報それぞれを１つのグループとして前記納品先に納品するための梱包明細情報であって、前記グループ内の前記構成部品に対応する前記保税管理情報を含む梱包明細リストを生成するとともに、前記梱包明細リストに含まれる前記構成部品それぞれに貼られ、前記グループに属する前記構成部品を識別するための出荷ラベル情報を生成する出荷管理部と、
   所定の印刷装置を通じて前記梱包明細リスト及び前記出荷ラベル情報を出力させる印刷制御部と、
   を備えることを特徴とする請求項１から５のいずれか１つに記載の物流・支払代行管理システム。
7. 製品の構成部品を発注する製品メーカーと、発注された前記構成部品を前記製品メーカーに供給する複数の部品供給ベンダーと、前記部品供給ベンダーから出荷された前記構成部品が入庫し、前記製品メーカーの納品先に前記構成部品が出庫される物流倉庫を介した入出庫を管理する物流業者とが連携し、発注された前記構成部品の前記製品メーカーから前記部品供給ベンダーへの代金支払処理を行う物流・支払代行管理装置であって、
   前記製品メーカーから前記部品供給ベンダーそれぞれに対して発行される前記構成部品のＰ／Ｏ情報を、前記部品供給ベンダーへの発行に伴って前記製品メーカーのメーカー側装置から受信するＰ／Ｏ受付部と、
   受信した前記Ｐ／Ｏ情報を、前記部品供給ベンダーそれぞれから前記物流倉庫に入庫される前記構成部品の入庫予定情報として記憶する記憶部と、
   前記物流倉庫に入庫する前記構成部品を検収する作業員によって操作される倉庫側装置を介して入力され、前記Ｐ／Ｏ情報に基づいて前記作業員が検収した前記構成部品の検収入庫数を、前記入庫予定情報の入庫実績として登録する入出庫管理部と、
   前記検収入庫数と予め取得された前記構成部品の単価情報とに基づいて前記Ｐ／Ｏ情報毎に検収金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額の入金先が前記物流業者を窓口として集約された入金依頼を前記メーカー側装置に送信する入金処理と、複数の前記部品供給ベンダー毎に、前記物流業者から前記部品供給ベンダーに前記検収金額を送金するための送金処理と、を行う支払代行制御部と、を有し、
   前記入出庫管理部は、前記検収入庫数が前記Ｐ／Ｏ情報の発注数よりも少ないか否かを判別し、前記検収入庫数が前記発注数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注数と部分検収入庫数との差から未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を発注数とする分納用のＰ／Ｏ情報を生成し、
   前記支払代行制御部は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報の部分検収金額に対する前記入金処理及び前記送金処理を行う、
   ことを特徴とする物流・支払代行管理装置。
8. 製品の構成部品を発注する製品メーカーと、発注された前記構成部品を前記製品メーカーに供給する複数の部品供給ベンダーと、前記部品供給ベンダーから出荷された前記構成部品が入庫し、前記製品メーカーの納品先に前記構成部品が出庫される物流倉庫を介した入出庫を管理する物流業者とが連携し、発注された前記構成部品の前記製品メーカーから前記部品供給ベンダーへの代金支払処理を行う物流・支払代行管理装置で実行されるプログラムであって、前記物流・支払代行管理装置に、
   前記製品メーカーから前記部品供給ベンダーそれぞれに対して発行される前記構成部品のＰ／Ｏ情報を、前記部品供給ベンダーへの発行に伴って前記製品メーカーのメーカー側装置から受信する第１機能と、
   受信した前記Ｐ／Ｏ情報を、前記部品供給ベンダーそれぞれから前記物流倉庫に入庫される前記構成部品の入庫予定情報として記憶する第２機能と、
   前記物流倉庫に入庫する前記構成部品を検収する作業員によって操作される倉庫側装置を介して入力され、前記Ｐ／Ｏ情報に基づいて前記作業員が検収した前記構成部品の検収入庫数を、前記入庫予定情報の入庫実績として登録する第３機能と、
   前記検収入庫数と予め取得された前記構成部品の単価情報とに基づいて前記Ｐ／Ｏ情報毎に検収金額を算出し、複数の前記部品供給ベンダーに支払うべき前記検収金額の入金先が前記物流業者を窓口として集約された入金依頼を前記メーカー側装置に送信する入金処理と、複数の前記部品供給ベンダー毎に、前記物流業者から前記部品供給ベンダーに前記検収金額を送金するための送金処理と、を行う第４機能と、を実現させ、
   前記第３機能は、前記検収入庫数が前記Ｐ／Ｏ情報の発注数よりも少ないか否かを判別し、前記検収入庫数が前記発注数よりも少ないと判別されたとき、前記検収入庫数を前記Ｐ／Ｏ情報に対する部分検収入庫数として登録するとともに、前記発注数と部分検収入庫数との差から未検収入庫数を算出し、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報に紐付き、算出された未検収入庫数を発注数とする分納用のＰ／Ｏ情報を生成し、
   前記第４機能は、前記部分検収入庫数が登録された前記Ｐ／Ｏ情報の部分検収金額に対する前記入金処理及び前記送金処理を行う、
   ことを特徴とするプログラム。