JP2022131477A - 物流管理装置、物流管理方法、及び物流管理プログラム - Google Patents

Abstract

【課題】貨物リリースを迅速に行って総合的な物流費を抑制すること。【解決手段】本実施の形態の物流管理装置は、各種業務の終了条件やリリース判定の条件を登録した判定条件マスタと、入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理手段と、前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会手段と、を備えている。【選択図】図１

Description

本発明は、物流管理装置、物流管理方法、及び物流管理プログラムに関する。

例えば、貨物利用運送事業者（ＮＶＯＣＣ）の輸入管理業務において、ヤードに搬入された貨物のリリース（搬出指示）を迅速に行う事が求められる。例えば、ＮＶＯＣＣに関するシステムとして、例えば、特許文献１がある。

特開２００４－３０２７２３号公報

しかしながら、特許文献１では、貨物リリースを迅速に行って、総合的な物流費を抑制することに関して何等記載されていない。

本発明は、上記に鑑みてなされたものであり、貨物リリースを迅速に行って、総合的な物流費を抑制することが可能な物流管理装置、物流管理方法、及び物流管理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、制御部を備えた物流管理装置であって、前記制御部は、各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理手段と、前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会手段と、を備えたことを特徴とする。

また、本発明の一態様によれば、前記各種業務は、ＢＬ回収業務、支払業務、請求業務、回収業務を含むことにしてもよい。

また、本発明の一態様によれば、前記ＢＬ回収業務の終了条件は、ＢＬが元地回収された、ＢＬが回収された、請求先と包括ＬＧの取り決めがある、及びＳＩＮＧＬＥ ＬＧを回収した、のうちのいずれか１つの条件を満たすことにしてもよい。

また、本発明の一態様によれば、前記支払業務の終了条件は、支払先の支払条件が締支払又は支払処理がされたことにしてもよい。

また、本発明の一態様によれば、前記請求業務の終了条件は、請求書が発行されたことにしてもよい。

また、本発明の一態様によれば、前記回収業務の終了条件は、請求先より振込処理の通知を受けた、請求先より入金され債権との確認（引当）がとれた、及び自社通関部にて輸入海上番号を使用して輸入指図情報が作成された、のうちいずれか１つの条件を満たすことにしてもよい。

また、上述した課題を解決し、目的を達成するために、本発明は、前記リリース判定は、前記ＢＬ回収業務、前記支払業務、前記請求業務、前記回収業務が全て終わっていることを条件とすることにしてもよい。

また、上述した課題を解決し、目的を達成するために、本発明は、制御部を備えた情報処理装置で実行される物流管理方法であって、前記制御部は、各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、前記制御部において実行される、入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理工程と、前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会工程と、を含むことを特徴とする。

また、上述した課題を解決し、目的を達成するために、本発明は、制御部を備えた情報処理装置で実行される物流管理プログラムであって、前記制御部は、各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、前記制御部において、入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理工程と、前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会工程と、を実行させるための物流管理プログラムであることを特徴とする。

本発明によれば、貨物リリースを迅速に行って、総合的な物流費を抑制することが可能になるという効果を奏する。

図１は、本実施の形態に係る物流管理システムの構成の一例を示すブロック図である。 図２は、本実施の形態に係る物流管理システムのＥＲ図の一例を示す図である。 図３は、判定条件情報の一例を示す図である。 図４は、判定条件マスタの構成例を示す図である。 図５は、本実施の形態に係る物流管理システムの制御部の全体の動作の概略を説明するためのフローを示す図である。 図６は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。 図７は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。 図８は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。 図９は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。 図１０は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。 図１１は、本実施の形態に係る物流管理システムの制御部の処理の具体例を説明するためのサンプルデータを示す図である。

本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。

［１．概要］
例えば、貨物利用運送事業者（ＮＶＯＣＣ）の輸入管理業務において、ヤードに搬入された貨物のリリース（搬出指示）を迅速に行う事が求められる。貨物リリースに当たり、各書類の状況や作業進捗、回収状況、支払状況の把握が必要になる。

しかしながら、従来、作業進捗と回収状況、支払状況を包括的に管理できるシステムがないため、未回収・未支払に起因する作業の遅延（入金確認ができなければヤードからのリリースができない、など）や回収・支払の遅延、漏れが発生する要因となっている。

そこで、本実施の形態では、案件毎に債権及び債務情報を管理する基幹システムの特徴に着目し、貨物リリースに必要な作業や入出金進捗をシステムに登録し、各業務の終了判定やリリース判定を自動で行い、照会画面で、案件毎の情報（作業・入出金進捗）やリリース判定の確認が随時（リアルタイム）可能なシステムを構築した。

本実施の形態によれば、貨物リリースを迅速に行うことが可能になり、総合的な物流費を抑制することが可能となる（例えば、保管料・延滞料の抑制）。また、誤ったリリース指示を抑制し、債権の回収漏れを防止することが可能となる。さらに、案件にかかる処理を１担当が全て行うのではなく、各処理を複数担当が同時に処理可能となり、業務効率を改善することが可能となる。

本実施の形態の物流費管理システムは、ＮＶＯＣＣ等の業種に好適に使用することができる。

［２．構成］
本実施形態に係る物流管理装置１００の構成の一例について、図１を参照して説明する。図１は、物流管理装置１００の構成の一例を示すブロック図である。

物流管理装置１００は、市販のデスクトップ型パーソナルコンピュータである。なお、物流管理装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。

物流管理装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。物流管理装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、物流管理装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、物流管理装置１００と、端末４００・・・やサーバ２００等とを通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。端末４００・・・は、例えば、国際物流部門、通関部門、経理部門等で使用される端末である。端末４００・・・は、物流管理装置１００にアクセス可能に構成されており、物流管理装置１００が提供する各種画面（例えば、入力画面や照会画面）を操作して、物流管理装置１００に各種処理を実行させたり、情報の登録が可能となっている。

入出力インターフェース部１０８には、入力装置１１２および出力装置１１４が接続されている。出力装置１１４には、モニタ（タッチパネルを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、およびマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４またはプリンタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。また、「出力」とは、出力装置１１４で出力すること等をいい、例えば、モニタ１１４への表示出力やプリンタ１１４での印刷出力することの他、外部にデータを送信することを含む。

記憶部１０６には、各種のデータベース、テーブル、およびファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。また、記憶部１０６は、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃ、判定条件マスタ１０６ｄ、データテーブル１０６ｅを備えている。図２は、ＥＲ図を示している。図３は、データテーブル１０６ｅに格納される判定条件情報の一例を示す図である。図４は、判定条件マスタ１０６ｄの一例を示す図である。

請求先マスタ１０６ａは、請求先（荷主）の情報を管理するためのマスタであり、図２に示すように、請求先コード、請求先名、ＬＧ有無のデータを関連づけて登録したテーブル等で構成することができる。

請求先ＬＧ情報マスタ１０６ｂは、図２に示すように、請求先コード、行、ＬＧ種別、取扱開始、取扱終了のデータを関連づけて登録したテーブル等で構成することができる。

支払先マスタ１０６ｃは、支払先（船社）の情報を管理するためのマスタであり、支払条件等の情報を保持する。支払先マスタ１０６ｃは、図２に示すように、支払先コード、支払先名、支払条件のデータを関連づけて登録したテーブル等で構成することができる。

データテーブル１０６ｅは、判定条件情報、海上輸入情報、原価情報、請求情報、回収予定情報、入金引当情報、入金情報、輸入指図情報、支払依頼情報、支払決済情報等の各種データを格納するためのテーブルである。海上輸入情報、原価情報、請求情報、回収予定情報、入金引当情報、入金情報、輸入指図情報、支払依頼情報、支払決済情報を業務情報と称する。

海上輸入情報は、図２に示すように、海上輸入番号、請求先コード、請求先名（荷主）、入港日、ＨＢＬＮＯ、元地回収区分、ＢＬ回収区分、ＢＬ回収日、ＳＩＮＧＬＥ ＬＧ回収日、振込連絡日、リリース日のデータを含んでいてもよい。

原価情報は、図２に示すように、海上輸入番号、行、支払先コード、支払先名、支払項目名、支払金額等のデータを含んでいてもよい。

請求情報は、図２に示すように、海上輸入番号、行、請求項目コード、請求項目名、請求金額を含んでいてもよい。

回収予定情報は、図２に示すように、回収予定番号、海上輸入番号、請求先コード、請求先名、計上日、回収予定日、回収予定金額、振込番号を含んでいてもよい。

支払依頼情報は、図２に示すように、支払依頼ヘッダ情報と支払依頼明細情報で構成してもよい。支払依頼ヘッダ情報は、支払依頼番号、支払先コード、支払先名、計上日、支払予定日のデータを含んでいてもよい。支払依頼明細情報は、支払依頼番号、行、海上輸入番号、支払金額のデータを含んでいてもよい。

支払決済情報は、支払決済ヘッダ情報と支払決済明細情報で構成されてもよい。支払決済ヘッダ情報は、図２に示すように、支払決済番号、支払先コード、支払先名、支払日、支払金額のデータを含んでいてもよい。支払決済明細情報は、図２に示すように、支払決済番号、行、支払依頼番号、支払金額のデータを含んでいてもよい。

入金情報は、図２に示すように、入金番号、入金日、入金金額、振込番号を含んでいてもよい。

入金引当情報は、入金引当情報（ヘッダ）と入金引当明細情報とで構成されてもよい。
入金引当情報（ヘッダ）は、図２に示すように、入金引当番号、引当日を含んでいてもよい。入金引当明細情報は、図２に示すように、入金引当番号、行、入金番号、入金引当金額、回収予定番号、回収引当金額を含んでいてもよい。

輸入指図（台帳）情報は、図２に示すように、輸入台帳番号、海上輸入番号、請求先（荷主）コードを含んでいてもよい。

判定条件情報は、各種業務の終了判定及びルート判定の種類を示すものである。判定条件マスタ１０６ｄを設定する場合に参照することができる。判定条件情報は、Ｎｏ、項目、分類、説明を含んでいる。例えば、Ｎｏ「４」は、項目「ＢＬ判定」、分類「ＢＬ情報」、説明「Ｎｏ．５、６、８の条件により〇もしくは×で状態を表現する。」となっている。Ｎｏ「１０」は、項目「支払判定」、分類「原価関連」、説明「Ｎｏ．１２、１５の条件により〇もしくは×で状態を表現する。」となっている。Ｎｏ「１６」は、項目「請求判定」、分類「請求関連」、説明「Ｎｏ．１８が済の場合に〇を表示する。」となっている。

Ｎｏ「１９」は、項目「入金判定」、分類「入金関連」、説明「Ｎｏ．２０、２１、２２の条件により〇もしくは×で状態を表現する。」となっている。Ｎｏ「２３」、項目「リリース判定」、分類「リリース」、説明「Ｎｏ．４：ＢＬ判定、Ｎｏ．１０：支払判定、Ｎｏ．１６：請求判定、Ｎｏ．１９：入金判定全て〇の場合に〇を表示。」となっている。

判定条件マスタ１０６ｄは、各種業務の終了判定及びルート判定の条件を設定したマスタである。照会画面の項目について関数を利用する場合に設定を登録する。照会で抽出するテーブル・項目を指定して関数の設定が可能となっている。判定条件マスタ１０６ｄは、図４に示すように、処理名、項目ＩＤ（判定条件情報のＮｏに対応）、項目名、行、設定関数を関連づけて登録したテーブル等で構成することができる。図に示す例では、１行目は、処理名「輸入海上照会」、項目ＩＤ「４」、項目名「ＢＬ判定」、行「１」、設定関数「ＣＡＳＥ ＷＨＥＮ （ｉｓｎｕｌｌ（［海上輸入情報］．［元地回収区分］，０） ＝ ２） ｏｒ （ＩＳＮＵＬＬ（［請求先ＬＧ情報］．［ＬＧ種別コード］，’’） ＝ １） ｏｒ （［海上輸入情報］．［ＳＩＮＧＬＥ ＬＧ回収日］ ｉｓ ｎｏｔ ｎｕｌｌ） ｏｒ （［海上輸入情報］．［ＢＬ回収日］ ｉｓ ｎｏｔ ｎｕｌｌ） ＴＨＥＮ ’〇’ ＥＬＳＥ ’×’ ＥＮＤ」となっている。

制御部１０２は、物流管理装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、機能概念的に、業務情報入力処理部１０２ａと、照会処理部１０２ｂと、マスタメンテ部１０２ｃと、画面表示制御部１０２ｄと、を備えている。

制御部１０２は、記憶部１０６に格納されている請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃ、判定条件マスタ１０６ｄ、データテーブル１０６ｅにアクセス可能に構成されている。なお、これらのマスタ群やデータテーブル１０６ｅは、他の場所（例えば、サーバ２００）に設けられていてもよく、制御部１０２がアクセス可能な構成であればよい。

業務情報入力処理部１０２ａは、入出金や作業の各種業務の進捗を含む業務情報を入力して、データテーブル１０６ｅに格納する。各種業務は、ＢＬ回収業務、支払業務、請求業務、回収業務を含むことにしてもよい。

照会処理部１０２ｂは、判定条件マスタ１０６ｄを参照して、業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を照会画面に表示する。この場合、ＢＬ回収業務の終了条件は、ＢＬが元地回収された、ＢＬが回収された、請求先と包括ＬＧの取り決めがある、及びＳＩＮＧＬＥ ＬＧを回収した、のうちいずれか１つの条件を満たすことにしてもよい。支払業務の終了条件は、支払先の支払条件が締支払又は支払処理がされたことにしてもよい。請求業務の終了条件は請求書が発行されたことにしてもよい。

回収業務の終了条件は、請求先より振込処理の通知をうけた、請求先より入金され債権との確認（引当）がとれた、及び自社通関部にて輸入海上番号を使用して輸入指図情報が作成された、のうちいずれか１つの条件を満たすことにしてもよい。リリース判定は、ＢＬ回収業務、支払業務、請求業務、回収業務が全て終わっていることを条件としてもよい。

マスタメンテ部１０２ｃは、例えば、不図示のマスタメンテ画面上でのオペレータの操作に応じて、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃ、判定条件マスタ１０６ｄに対して、データの登録・追加・変更・削除等の編集を行うためのものである。

画面表示制御部１０２ｄは、モニタ１１４に表示したり、端末４００・・・に提供する各種画面（例えば、入力画面、照会画面等）の表示及びその入力を制御する。

［３．具体例］
図１～図１０を参照して、本実施の形態における物流管理装置１００の制御部１０２の処理の具体例を説明する。図５は、本実施の形態における物流管理装置１００の制御部１０２の全体の処理の概略を説明するためのフローを示す図である。

（全体の処理）
図５を参照して、本実施の形態における物流管理装置１００の制御部１０２の全体の処理の概略を説明する。図５において、業務情報入力処理部１０２ａは、海上輸入入力処理（Ｓ１）を実行する。海上輸入入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、当該端末４００の入力画面での入力操作に応じて、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃを参照して、海上輸入情報、請求情報、原価情報を入力して、データテーブル１０６ｅに登録する。海上輸入入力処理では、案件単位で情報を管理し、海上輸入番号を採番し、海上輸入情報、原価情報、及び請求情報を入力する。海上輸入情報、原価情報、及び請求情報は、海上輸入番号で紐付けする。

業務情報入力処理部１０２ａは、請求書発行処理（Ｓ２）を実行する。請求書発行処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、当該端末の入力画面での入力操作に応じて、請求情報を確定させて、回収予定情報を作成してデータテーブル１０６ｅに登録するとともに、回収予定情報に基づいた請求書を発行する。

業務情報入力処理部１０２ａは、支払依頼入力処理（Ｓ３）を実行する。支払依頼入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、当該端末の入力画面での入力操作に応じて、原価情報を確定させて、原価情報に基づいて支払依頼情報を作成してデータテーブル１０６ｅに登録すると共に、支払依頼情報に基づいた支払依頼書を発行する。

業務情報入力処理部１０２ａは、支払決済入力処理（Ｓ４）を実行する。支払決済入力処理では、業務情報入力処理部１０２ａは、例えば、経理部門の端末４００からのアクセスに応じて、当該端末の入力画面での入力操作に応じて、支払依頼情報を基づいて支払決済情報を作成してデータテーブル１０６ｅに登録する。

業務情報入力処理部１０２ａは、ＢＬ／ＬＧ回収入力処理（Ｓ５）を実行する。ＢＬ／ＬＧ回収入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、当該端末の入力画面での入力操作に応じて、ＢＬ又はＬＧを回収したタイミングで海上輸入情報のＢＬ回収日又はＳＩＮＧＬＥ ＢＬ回収日を更新する。

業務情報入力処理部１０２ａは、振込確認入力処理（Ｓ６）を実行する。振込確認入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、当該端末の入力画面での入力操作に応じて、請求書発行にて発行された請求額に対し、荷主から振込処理の連絡を受けた場合に、海上輸入情報の振込連絡日を更新（登録）する。振込証書を元に入金・引当未処理でもリリース可能の判断をする。

業務情報入力処理部１０２ａは、入金入力処理（Ｓ７）を実行する。入金入力処理では、業務情報入力処理部１０２ａは、例えば、経理部門の端末４００からのアクセスに応じて、入金の実績として入金情報をデータテーブル１０６ｅに登録する。

業務情報入力処理部１０２ａは、入金引当入力処理（Ｓ８）を実行する。入金引当入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、入金情報と回収予定情報を紐付けるための入金引当情報を生成して、データテーブル１０６ｅに登録する。

業務情報入力処理部１０２ａは、輸入指図入力処理（Ｓ９）を実行する。輸入指図入力処理では、業務情報入力処理部１０２ａは、例えば、通関部門の端末４００からのアクセスに応じて、貨物リリース後も自社で通関を請け負う際に前段の海上輸入情報から情報を取得し、輸入指図情報（台帳）を作成して、データテーブル１０６ｅに登録する。自社で通関を請け負う場合には請求の回収は通関処理後の通関請求と合算して請求するため、未回収状態でもリリース可能と判断する。

業務情報入力処理部１０２ａは、貨物リリース入力処理（Ｓ１０）を実行する。貨物リリース入力処理では、業務情報入力処理部１０２ａは、例えば、国際物流部門の端末４００からのアクセスに応じて、貨物リリースしたタイミングで輸入海上情報のリリース日を更新する。なお、貨物リリース可能な海上輸入番号のみ登録可能である。また、リリース不可の場合はエラー表示（例えば、×）される。

照会処理部１０２ｂは、輸入海上照会処理（Ｓ１１）を実行する。輸入海上照会処理では、照会処理部１０２ｂは、例えば、各部門の端末４００からのアクセスに応じて、指定される抽出条件に従って、判定条件マスタ１０６ｄを参照して、業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を含む海上輸入情報を照会画面に表示する。すなわち、抽出条件を指定し、一覧形式で海上輸入情報の参照が可能となっていている。また、照会したタイミングで各種データ登録状況に応じたリリース判定がリアルタイムに表示される。

ＢＬ回収業務の終了条件は、ＢＬが元地回収された（Ｓ１：海上輸入入力にて登録）、ＢＬが回収された（Ｓ５：ＢＬ／ＬＧ回収入力にて登録）、請求先と包括ＬＧの取り決めがある（請求先マスタのＬＧ情報に登録）、ＳＩＮＧＬＥ ＬＧを回収した（Ｓ５：ＢＬ／ＬＧ回収入力にて登録）のいずれか１つを満たすことである。

支払業務の終了条件は、支払先の支払条件が締支払又は支払処理がされた（Ｓ３：支払依頼を経て、Ｓ４：支払決済入力が処理された）を満たすことである。

請求業務の終了条件は請求書が発行された（Ｓ２：請求書発行処理をしている）時である。

回収業務の終了条件は、請求先より振込処理の通知をうけた（Ｓ６：振込確認入力を入力）、請求先より入金され債権との確認（引当）がとれた（Ｓ９：入金引当入力で処理）、自社通関部にて輸入海上番号を使用して輸入指図情報が作成された（Ｓ１０：輸入指図入力で処理）のいずれか１つを満たすことである。

（サンプルデータ）
図６～図１１は、本実施の形態における物流管理装置１００の制御部１０２の処理の具体例を説明するためのサンプルデータを示す図である。図６～図１１を参照して、本実施の形態における物流管理装置１００の制御部１０２の処理の具体例を説明する。以下の例では、図４に示す判定条件マスタ１０６ｄのデータ例を使用して、輸入海上照会を行う場合を説明する。

マスタメンテ部１０２ｃは、不図示のマスタメンテ画面上でのオペレータの操作に応じて、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃのデータを設定する。図６は、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃのデータ設定例を示す図である。

図６に示す請求先マスタの例では、１行目は、請求先コード「ＳＥＩ００１」、請求先名「ＡＡＡ貿易（株）」、ＬＧ有無「あり」、２行目は、請求先コード「ＳＥＩ００２」、請求先名「ＢＢＢ商事（株）」、ＬＧ有無「なし」、請求先コード「ＳＥＩ００３」、請求先名「Ｂ（株）ＣＣＣトレーディング」、ＬＧ有無「あり」となっている。

図６に示す請求先ＬＧ情報マスタの例では、１行目は、請求先コード「ＳＥＩ００１」、行「１」、ＬＧ種別「ＳＩＮＧＬＥ ＬＧ」、取扱開始「２０１９／１０／０１」、取扱終了「２０２０／０３／３１」、２行目は、請求先コード「ＳＥＩ００１」、行「２」、ＬＧ種別「包括ＬＧ」、取扱開始「２０２０／０４／０１」、取扱終了「２０２１／０３／３１」、３行目は、請求先コード「ＳＥＩ００３」、行「１」、ＬＧ種別「包括ＬＧ」、取扱開始「２０２０／０４／０１」、取扱終了「２０２０／０９／３０」となっている。

図６に示す支払先マスタの例では、１行目は、支払先コード「ＰＡＹ００１」、支払先名「ＤＤＤ海運（株）」、支払条件「支払条件都度」、２行目は、支払先コード「ＰＡＹ００２」、支払先名「（（株）ＥＥＥロジ」、支払条件「諸掛締払」となっている。

（Ｓ１：海上輸入入力処理）
図７は、海上輸入情報、原価情報、請求情報の入力例を示している。海上輸入入力処理では、請求先マスタ１０６ａ、請求先ＬＧ情報マスタ１０６ｂ、支払先マスタ１０６ｃを参照して、海上輸入情報、請求情報、原価情報を入力して、データテーブル１０６ｅに登録する。

図７に示す海上輸入情報の例では、１行目は、海上輸入番号「ＩＤＯ００１」、請求先（荷主）「ＳＥＩ００１：ＡＡＡ貿易（株）」、入港日「２０２０／１２／０１」、ＨＢＬＮＯ「ＯＢＨＢＬ１２０１１」、元地回収区分「通常」、２行目は、海上輸入番号「ＩＤＯ００２」、請求先（荷主）「ＳＥＩ００２：ＢＢＢ商事（株）」、入港日「２０２０／１２／０１」、ＨＢＬＮＯ「ＯＢＨＢＬ１２０１２」、元地回収区分「通常」３行目は、海上輸入番号「ＩＤＯ００３」、請求先（荷主）「ＳＥＩ００１：ＡＡＡ貿易（株）」、入港日「２０２０／１２／０１」、ＨＢＬＮＯ「ＯＢＨＢＬ１２０１３」、元地回収区分「元地回収」となっている。

図７に示す原価情報の例では、１行目は、海上輸入番号「ＩＤＯ００１」、行「１」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、支払項目「ＯＣＥＡＮ ＦＲＥＩＧＨＴ」、支払金額「￥５，０００」、２行目は、海上輸入番号「ＩＤＯ００１」、行「２」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、支払項目「ＤＯＣ ＦＥＥ」、支払金額「”￥４，０００」、３行目は、海上輸入番号「ＩＤＯ００１」、行「３」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、支払項目「ＴＨＣ」、支払金額「￥２，０００」となっていている。

図７に示す請求情報の例では、１行目は、海上輸入番号「ＩＤＯ００１」、行「１」、請求項目「Ｄ／Ｏ ＦＥＥ」、請求金額「￥１，０００」、海上輸入番号「ＩＤＯ００１」、行「２」、２行目は、請求項目「ＯＣＥＡＮ ＦＲＥＩＧＨＴ」、請求金額「￥６，０００」、３行目は、海上輸入番号「ＩＤＯ００１」、行「３」、請求項目「ＤＯＣ ＦＥＥ」、請求金額「￥４，０００」となっている。海上輸入番号「ＩＤＯ００３」、海上輸入番号「ＩＤＯ００４」の請求情報は未入力の状態である。

図８は、回収予定情報、支払依頼情報、支払決済情報の入力例を示す図である。

（Ｓ２：請求書発行処理）
請求書発行処理では、請求情報を確定させて、回収予定情報を作成してデータテーブル１０６ｅに登録すると共に、回収予定情報に基づいた請求書を発行する。

図８に示す回収予定情報の例では、１行目は、回収予定番号「ＫＡＩ００１」、海上輸入番号「ＩＤＯ００１」、請求先「ＳＥＩ００１：ＡＡＡ貿易（株）」、計上日「２０２０／１２／０１」、回収予定日「２０２０／１２／０８」、回収予定金額「￥１３，０００」、振込番号「１１１１２」、２行目は、回収予定番号「ＫＡＩ００２」、海上輸入番号「ＩＤＯ００２ 請求先「ＳＥＩ００２：ＢＢＢ商事（株）」、計上日「２０２０／１２／０１」、回収予定日「２０２０／１２／０８」、回収予定金額「￥２７，０００」、振込番号「１１１１３」となっている。

（Ｓ３：支払依頼入力処理）
支払依頼入力処理では、原価情報を確定させて、原価情報に基づいて支払依頼情報を作成してデータテーブル１０６ｅに登録すると共に、支払依頼情報に基づいた支払依頼書を発行する。

図８に示す支払依頼情報の支払依頼ヘッダ情報は、１行目は、支払依頼番号「ＰＹＩ００１」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、計上日「２０２０／１２／０１」、支払予定日「２０２０／１２／０１」、２行目は、支払依頼番号「ＰＹＩ００２」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、計上日「２０２０／１２／０１」、支払予定日「２０２０／１２／０１」となっている。

図８に示す支払依頼情報の支払依頼明細情報は、１行目は、支払依頼番号「ＰＹＩ００１」、行「１」、海上輸入番号「ＩＤＯ００１」、支払金額「￥１１，０００」、２行目は、支払依頼番号「ＰＹＩ００１」、行「２」、海上輸入番号「ＩＤＯ００２」、支払金額「￥２１，０００」、３行目は、支払依頼番号「ＰＹＩ００２」、行「１」、海上輸入番号「ＩＤＯ００１」、支払金額「￥７，０００」となっている。

（Ｓ４：支払決済入力処理）
支払決済入力処理では、支払依頼情報を基づいて支払決済情報を作成してデータテーブル１０６ｅに登録する。

図８に示す支払決済情報の支払決済ヘッダ情報の例では、支払決済番号「ＰＹＰ００１」、支払先「ＰＡＹ００１：ＤＤＤ海運（株）」、支払日「２０２０／１２／０１」、支払金額「￥３９，０００」となっている。

また、図８に示す支払決済情報の支払決済明細情報の例では、１行目は、支払決済番号「ＰＹＰ００１」、行「１」、支払依頼番号「ＰＹＩ００１」、支払金額「￥３２，０００」、２行目は、支払決済番号「ＰＹＰ００２」、行「１」、支払依頼番号「ＰＹＩ００２」、支払金額「￥７，０００」となっている。

（Ｓ５：ＢＬ／ＬＧ回収入力処理）
ＢＬ／ＬＧ回収入力処理では、ＢＬ又はＬＧを回収したタイミングで海上輸入情報のＢＬ回収日又はＳＩＮＧＬＥ ＢＬ回収日を更新する。図９に示す例では、海上輸入情報の２行目の海上輸入番号「ＩＤＯ００２」のＢＬ回収日「２０２０／１２／０２」が更新される。

（Ｓ６：振込確認入力処理）
振込確認入力処理では、請求書発行にて発行された請求額に対し、荷主から振込処理の連絡を受けた場合に、海上輸入情報の振込連絡日を更新する。振込証書を元に入金・引当未処理でもリリース可能の判断をする。図９に示す例では、海上輸入情報の１行目の海上輸入番号「ＩＤＯ００１」の振込連絡日「２０２０／１２／０２」が更新される。

（Ｓ７：入金入力処理）
入金入力処理では、入金の実績として入金情報をデータテーブル１０６ｅに登録する。
図９に示す入金情報の例では、１行目は、入金番号「ＮＹＫ００１」、入金日「２０２０／１２／０２」、入金金額「￥１３，０００」、２行目は、入金番号「ＮＹＫ００２」、入金日「２０２０／１２／０２」、入金金額「￥２７，０００」、振込番号「１１１１３」となっている。

（Ｓ８：入金引当入力処理）
入金引当入力処理では、入金情報と回収予定情報を紐付けるための入金引当情報を生成して、データテーブル１０６ｅに登録する。

図１０に示す入金引当情報のヘッダの例では、１行目は、入金引当番号「ＮＫＨ００１」、引当日「２０２０／１２／０２」、２行目は、入金引当番号「ＮＫＨ００２」、引当日「２０２０／１２／０２」となっている。図９に示す入金引当情報の入金引当明細情報の例では、１行目は、入金引当番号「ＮＫＨ００１」、行「１」、入金番号「ＮＹＫ００１」、入金引当金額「￥１３，０００」、回収予定番号「ＫＡＩ００１」、回収引当金額「￥１３，０００」、２行目は、入金引当番号「ＮＫＨ００２」、行「１」、入金番号「ＮＹＫ００２」、入金引当金額「￥２７，０００」、回収予定番号「ＫＡＩ００２」、回収引当金額「￥２７，０００」となっている。

（Ｓ９：輸入指図入力処理）
輸入指図入力処理では、貨物リリース後も自社で通関を請け負う際に前段の海上輸入情報から情報を取得し、輸入指図情報（台帳）を作成して、データテーブル１０６ｅに登録する。自社で通関を請け負う場合には請求の回収は通関処理後の通関請求と合算して請求する為、未回収状態でもリリース可能と判断する。

図１０に示す輸入指図情報の例では、輸入台帳番号「ＩＩＩ００１」、海上輸入番号「ＩＤＯ００３」、請求先（荷主）「ＳＥＩ００１：ＡＡＡ貿易（株）」となっている。

（Ｓ１０：貨物リリース入力処理）
貨物リリース入力処理では、貨物リリースしたタイミングで輸入海上情報のリリース日を更新する。なお、貨物リリース可能な海上輸入番号のみ登録可能である。また、リリース不可の場合は照会画面でエラー表示（例えば、×）される。

図１０に示す例では、海上輸入情報の海上輸入番号「ＩＤＯ００１」のリリース日を「２０２０／１２／０３」に更新し、海上輸入番号「ＩＤＯ００２」のリリース日を「２０２０／１２／０３」に更新する。

（Ｓ１１：輸入海上照会処理）
輸入海上照会処理では、指定される抽出条件に従って、判定条件マスタ１０６ｄを参照して、業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を含む海上輸入情報を照会画面に表示する。すなわち、輸入海上照会処理では、抽出条件を指定し、一覧形式で海上輸入情報の参照が可能となっている。また、照会したタイミングで各種データ登録状況に応じたリリース判定がリアルタイムに表示される。

図１１は、図４の判定条件マスタ１０６ｄの設定例で判定した場合の抽出結果の表示例を示している。抽出結果は不図示の照会画面に表示される。同図に示す例では、１行目は、海上輸入番号「ＩＤＯ００１」、請求先「ＳＥＩ００１：ＡＡＡ貿易（株）」、入港日「２０２０／１２／０１」、ＢＬ判定「〇」、元地回収区分「通常」、ＬＧ有無「あり」、ＬＧ種別「包括ＬＧ」、支払判定「〇」、船社支払先「Ｙ００１：ＤＤＤ海運（（株）」、支払条件「都度」、支払金額「￥１１，０００」、支払依頼番号「ＰＹＩ００１」、支払決済番号「ＰＹＰ００１」、請求判定「〇」、回収予定金額「￥１３，０００」、請求書発行「済」、入金判定「〇」、振込連絡日「２０２０／１２／０２」、入金引当番号「ＮＫＨ００１」、リリース判定「〇」、リリース日「２０２０／１２／０３」となっている。この例では、上記サンプルデータの業務情報について、図４の判定条件マスタ１０６ｄを使用して終了判定すると、ＢＬ判定「〇」、支払判定「〇」、請求判定「〇」となるので、リリース判定「〇」となる。

以上説明したように、本実施の形態によれば、各種業務の終了条件やリリース判定の条件を登録した判定条件マスタ１０６ｄと、入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理部１０２ａと、判定条件マスタ１０６ｄを参照して、業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会処理部１０２ｂと、を備えているので、各業務の終了やリリース判定を迅速に行うことができ、これにより、貨物リリースを迅速に行って総合的な物流費を抑制することが可能となる。

［４．国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び９に貢献することが可能となる。

また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、１３及び１５に貢献することが可能となる。

また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。

［５．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、物流管理装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、物流管理装置１００が備える処理機能、特に制御部１０２にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて物流管理装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、物流管理装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、本実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部１０６に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。

また、物流管理装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、物流管理装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

１００ 物流管理装置
１０２ 制御部
１０２ａ 業務情報入力処理部
１０２ｂ 照会処理部
１０２ｃ マスタメンテ部
１０２ｄ 画面表示制御部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 請求先マスタ
１０６ｂ 請求先ＬＧ情報マスタ
１０６ｃ 支払先マスタ
１０６ｄ 判定条件マスタ
１０６ｅ データテーブル
２００ サーバ
３００ ネットワーク
４００ 端末

Claims (9)

1. 制御部を備えた物流管理装置であって、
   前記制御部は、
   各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、
   入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理手段と、
   前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会手段と、
   を備えたことを特徴とする物流管理装置。
2. 前記各種業務は、ＢＬ回収業務、支払業務、請求業務、回収業務を含むことであることを特徴とする請求項１に記載の物流管理装置。
3. 前記ＢＬ回収業務の終了条件は、ＢＬが元地回収された、ＢＬが回収された、請求先と包括ＬＧの取り決めがある、及びＳＩＮＧＬＥ ＬＧを回収した、のうちいずれか１つの条件を満たすことであることを特徴とする請求項２に記載の物流管理装置。
4. 前記支払業務の終了条件は、支払先の支払条件が締支払又は支払処理がされたことであることを特徴とする請求項２に記載の物流管理装置。
5. 前記請求業務の終了条件は、請求書が発行されたことであることを特徴とする請求項２に記載の物流管理装置。
6. 前記回収業務の終了条件は、請求先より振込処理の通知を受けた、請求先より入金され債権との確認（引当）がとれた、及び自社通関部にて輸入海上番号を使用して輸入指図情報が作成された、のうちいずれか１つの条件を満たすことであることを特徴とする請求項２に記載の物流管理装置。
7. 前記リリース判定は、前記ＢＬ回収業務、前記支払業務、前記請求業務、前記回収業務が全て終わっていることを条件とすることを特徴とする請求項２～６のいずれか１つに記載の物流管理装置。
8. 制御部を備えた情報処理装置で実行される物流管理方法であって、
   前記制御部は、
   各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、
   前記制御部において実行される、
   入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理工程と、
   前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会工程と、
   を含むことを特徴とする物流管理方法。
9. 制御部を備えた情報処理装置で実行される物流管理プログラムであって、
   前記制御部は、
   各種業務の終了条件やリリース判定の条件を登録した判定条件マスタにアクセス可能に構成されており、
   前記制御部において、
   入出金や作業の各種業務の進捗を含む業務情報を入力する業務情報入力処理工程と、
   前記判定条件マスタを参照して、前記業務情報に基づいて各業務の終了の判定やリリース判定を行い、その判定結果を表示部の照会画面に表示する照会工程と、
   を実行させるための物流管理プログラム。

Images