JP2019040518A - 管理サーバ、制御方法、およびプログラム。 - Google Patents

Abstract

【課題】 入荷計画で発注され、在庫管理していく場合、生産者の都合で、データと実際に納入された数量で差異が発生する場合でも正しく在庫状況を管理すること【解決手段】対象在庫品の入荷予定数を記憶する記憶手段を有する管理サーバであって、前記対象在庫品の発注数が、前記記憶手段に記憶された入荷予定数に達しなかった場合、入荷予定数に達しなかった数を算出する算出手段と、前記算出手段で算出された入荷予定数に達しなかった数の内、発注がキャンセルされた数を記憶するキャンセル倉庫記憶手段と前記算出手段で算出された入荷予定数に達しなかった数から前記キャンセル倉庫記憶手段に記憶された発注がキャンセルされた数を入荷残として記憶する入荷残記憶手段とを有することを特徴とする【選択図】図１

Description

本発明は、ＳＣＭ（サプライ・チェーン・マネジメント）における発注業務に関わる管理サーバ、制御方法、およびプログラムに関する。

企業活動において、ＳＣＭの在庫管理を行う技術は、余剰在庫を減らし、欠品を防ぐ意味で重要である。

例えば、商品の販売者は、販売する予定数（販売予測数）を算出し、販売計画として、需要予測数をその商品の生産者に提供する。

情報を提供された生産者は、需要予測数から商品の生産可能な予定を立て、販売者に供給可能数として提供する。

販売者は供給可能数から入荷計画を立て、生産者に発注を行う。入荷計画に沿って商品を入荷することで、余剰在庫や欠品を減らす在庫管理が可能となる。

特許文献１には、在庫管理に関する評価指標を可視化するとともに、ＳＣＭ改善施策が
必要な対象在庫品を選定することによってシミュレーションにかかる時間を短縮する技術が開示されている。

特開２００７−２６３３５号公報

生産者が販売者の入荷計画に沿って生産可能な場合には、在庫計画に変更は生じない。しかしながら、生産者が生産可能な商品数を超えて出荷する計画の場合、生産者はこれ以上生産できない。そのため、生産者の都合で販売者からの生産できない注文をキャンセルすることがある。一方、販売者は注文済みの商品が計画数に達していない場合、入荷残として次回の入荷数に上乗せする。

以上のように生産者と販売者とで在庫計画にギャップが生じることがある。

特許文献１に記載の技術では、発注して届かなかった商品も、最終的には発注数分を倉庫に納入する事が出来る仕様のため、在庫計画は正しい数になる。しかし、入荷予定数（入荷計画）で発注し、在庫管理していく場合、生産者の都合で、データと実際に納入された数量で差異が発生した場合、正しく在庫計画を立てることが出来ない。

本発明は、上記課題を解決するためになされた発明であり、入荷計画で発注され、在庫管理していく場合、生産者の都合で、データと実際に納入された数量で差異が発生する場合でも正しく在庫状況を管理することを課題とする。

対象在庫品の入荷予定数を記憶する記憶手段を有する管理サーバであって、前記対象在庫品の発注数が、前記記憶手段に記憶された入荷予定数に達しなかった場合、入荷予定数に達しなかった数を算出する算出手段と、前記算出手段で算出された入荷予定数に達しなかった数の内、発注がキャンセルされた数を記憶するキャンセル倉庫記憶手段と前記算出手段で算出された入荷予定数に達しなかった数から前記キャンセル倉庫記憶手段に記憶された発注がキャンセルされた数を入荷残として記憶する入荷残記憶手段とを有することを特徴とする

本発明によれば、入荷計画で発注され、在庫管理していく場合、生産者の都合で、データと実際に納入された数量で差異が発生する場合でも正しく在庫状況を管理することができる。

本発明の実施形態における、情報処理システムの構成の一例を示すシステム構成図である。 本発明の実施形態における、クライアント端末１００、発注管理サーバ２００などの各種端末のハードウエア構成を示す図である。 従来の発注管理システムにおける、課題を説明するためのデータ構成図および画面イメージである。 本発明の実施形態における、発注管理サーバ２００がクライアント端末１００に発注データ入力画面を送信した後の処理の流れを説明するフローチャートである。 本発明の実施形態における、発注データ入力画面の一例を示す模式図である。 本発明の実施形態における、発注管理サーバが有するデータベースの例である。 本発明の実施形態における、発注データ入力画面の一例を示す模式図である。

以下、本発明の好ましい実施の形態について図面を参照しながら詳細に説明する。

図１は、本発明に係る情報処理システムの構成の一例を示すシステム構成図である。

図１において、情報処理システムは、商品の発注数を管理する発注管理サーバ２００と発注管理サーバにネットワーク１１０を介してデータを送信する複数のクライアント端末１００とを有している。

発注管理サーバ２００は、クライアント端末１００から、商品の発注数の入力や入荷数の変更などを受け付け、受け付けた結果をクライアント端末１００に戻す。

なお、図１では、複数のクライアント端末で構成されたシステムにおける発注管理の構成で説明しているが、クライアント端末を含め、一つの機器からなる装置に適用しても良いし、複数の発注管理サーバから構成されるシステムに適用しても良い。また、発注管理サーバもしくはクライアントが在庫予測を行い、在庫管理を行うソフトウェアを有していても良い。

図２は、本発明の実施形態のクライアント端末１００、サーバ２００などの各種端末のハードウエア構成を示す図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。

また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。

ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。また、印刷装置等では、タッチパネル、ボタン、スイッチ等が挙げられる。

出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、たとえば、ＣＲＴや液晶ディスプレイ等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザーファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。

通信Ｉ／Ｆコントローラ２０８は、ネットワークを介して外部機器との通信制御処理を実行する。

本発明を実現するためのプログラムは外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。

次に、図３を参照して、本発明の発注管理システムの課題を説明する。

図３は、従来の発注管理システムにおける課題を説明するためのデータ構成図および画面イメージである。

図３の３０１〜３０５は、在庫を管理しているデータベースの例であり、予め需要予測数や入荷予定数が指定されているデータの一例である。なお、このデータリストはクライアント端末１００に表示することができ、発注ボタン８１２によって、発注データを確定させることができる。

３０１〜３０５の「入荷予定」とは、生産者から入荷する予定の数及び入荷残の数であり、「需要実績・予測」とは、過去のデータは需要の実績、未来のデータは需要の予測値を示している。また、「発注済」とは、当日に到着する商品の数であり、この数だけ実際の商品が入荷される。「安全在庫」とは、需要の変動の際に欠品を極力さけるために持つ在庫である。「在庫実績・予定」とは、過去のデータは在庫の実績、未来のデータは在庫の予定値を示している。

３０１において、たとえば生産者と販売者（発注側）との協議で５月１０日当日の入荷予定数を１３０個と設定すると、５月１０日の「入荷予定」欄に発注者側が『１３０』という値を入力（３１１）後、発注ボタン３１２が押下する。その後、予定通り１３０個の入荷があると、入荷を受け付けるユーザが「発注済」に『１３０』と入力し（３２１）、再び発注ボタンが押下される。なお、以後の説明図において、発注データ入力画面に斜字（イタリック）で記載されている数字部分はユーザからの入力値とする。

一方、当初協議した数である１３０個が５月１０日に全数届かなかった場合を考える。たとえば５月１０に１００個だけが入荷された場合、３０３のデータのように、「発注済」の欄に入荷された数である『１００』が入荷を受け付けるユーザにより入力され（３３１）、入荷残である残り３０個は、翌日の「入荷予定」欄３３２に反映される。３０６〜３１０の生産者側データとしては、「出荷残数」として、３３３のように出荷残の数を記憶しておいて、翌日以降に残りの３０個の出荷を行う。

しかし、生産者側のデータ管理が出荷残数を管理する仕様になっていない場合や、３０９のデータのように生産者側では出荷残数を考慮していない（３４２）場合、３０４のように翌日の入荷残３０個分の「入荷予定」の『３０』（３４１）は当面は入荷せず、また、次の入荷の際に優先的にこの３０個分が割り当てられるため、生産者側の出荷数との間に食い違いが生じ得る。

これを防ぐためには、３０５のデータの３５１の入力欄にあるように、翌日の入荷予定数を『０』（３５１）と入力して発注ボタンを押下する必要が生じる。通常は入荷を受け付けるユーザは「発注済」の入力しかできず、「入荷予定」の欄は生産者と協議できるユーザが設定するものである。そのため、「入荷予定」の欄の入力のために入荷を受け付けるユーザは、より上位の「入荷予定」欄の入力権限を有するユーザに依頼をして、「入荷予定」の欄を入力（個数の削除）してもらわなければならず、煩わしい処理となる。

以上の課題を解決する為に、本発明では、入荷を受け付けるユーザでも入力が可能な入荷キャンセル欄を設けて、入荷数を制御でき、生産者と販売者のデータの齟齬をなくすことができる。図４以降で、本発明を詳細に説明する。

図４は、本発明の実施形態における、発注管理サーバ２００がクライアント端末１００に発注データ入力画面を送信した後の処理の流れを説明するフローチャートである。

まず図４のステップＳ４０１では、発注管理サーバ２００のＣＰＵ２０１は、クライアント端末１００に発注データ入力画面情報を送信する。送信されたクライアント端末１００は、クライアント端末１００のディスプレイ（出力部）２１０に発注データ入力画面を表示する。発注データ入力画面の表示例を図５を参照して説明する。

図５は、本発明の実施形態における、発注データ入力画面の一例を示す模式図である。

図５の５００は、発注データ入力画面の一例であり、この表の中の「入荷予定」欄５０１に将来の入荷予定数を入力する。この入荷予定数は、需要予測や在庫実績などを加味して安全在庫を極力満たすように、生産者と協議の上、入力される入荷予定の商品の数である。

「発注済」欄５０２は、当日入荷される商品の数を入荷受付ユーザが入力する欄であり、５０２に値が入ることにより、「入荷予定」欄５０１が減算される。図４のフローチャートの説明に戻る。

図４のステップＳ４０１において、図５のような発注データ入力画面を表示すると、次のステップＳ４０２において、発注管理サーバ２００のＣＰＵ２０１は、クライアント端末１００がユーザから受け付けた入力が「入荷予定」欄５０１の入力かどうかを判定する。

「入荷予定」欄５０１の入力であった場合は、ステップＳ４０３へと処理を遷移し、「入荷予定」欄５０１ではなかった場合は、ステップＳ４０４へと処理を遷移する。

ステップＳ４０３へと処理を遷移すると、発注管理サーバ２００のＣＰＵ２０１は、ユーザがクライアント端末１００から入力した値を図５の「入荷予定」欄５０１に反映する。図５の５０１の例では、入荷予定数として『１３０』が入力されている。また、入力された値は、入荷予定データベースの入荷予定テーブルに反映する。入荷予定テーブルの例を図６を参照して説明する。

図６は、本発明の実施形態における発注管理サーバが有するデータベースの例であり、６０１から６０４のそれぞれのデータベースの値から、図５の発注データ入力画面を生成している。

図６の６０１は、入荷予定テーブルの例であり、たとえば『２０１７／５／１０』の「入荷数」欄にステップＳ４０３で入力された値である『１３０』が反映される。図４のフローチャートの説明に戻る。

図４のフローチャートで、ステップＳ４０３へと処理を遷移すると、次にステップＳ４０１へと処理を戻し、異なる商品や異なる日付の入荷予定テーブルのメンテナンスを繰り返す。

一方、ステップＳ４０２において、クライアント端末１００がユーザから受け付けた入力が「入荷予定」欄５０１の入力ではない、即ち「発注済」欄５０２の入力である場合は、ステップＳ４０４へと処理を遷移する。

ステップＳ４０４において、発注管理サーバ２００のＣＰＵ２０１は、ユーザがクライアント端末１００から入力された値を受け付け、「発注済」欄５０２に反映する。図５の５０２欄に反映したイメージ図を図７を参照して説明する。

図７は、本発明の実施形態における、発注データ入力画面の一例を示す模式図である。

図７の７００は、発注データ入力画面の「発注済」７０１にユーザによりデータが入力された例である。図７の場合は、「発注済」の個数として『１００』が入力されている。

ステップＳ４０４において、入力された発注済入力値が発注テーブルに反映されると、次のステップＳ４０５において、発注管理サーバ２００のＣＰＵ２０１は、ステップＳ４０４で入力を受け付けた値（「発注済」の個数）が、入荷当日の「入荷予定」の数と同じか異なるかを判断する。

「入荷予定」の数が「発注済」と同じ場合は、ステップＳ４１０へと処理を遷移し、ステップＳ４１０において、発注管理サーバ２００のＣＰＵ２０１は、「発注済」欄５０２に入力された数は、発注済データベースの発注テーブルに登録される。図６の発注テーブルを参照して説明する。

図６の６０２は、発注テーブルの例であり、たとえば『２０１７／５／１０』の「入荷数」欄にステップＳ４０４で入力された値である『１００』が反映される。

一方、ステップＳ４０５において、入荷予定数と発注済数とが異なる場合は、ステップＳ４０６へと処理を遷移する。

ステップＳ４０６において、発注管理サーバ２００のＣＰＵ２０１は、ステップＳ４０４で入力された値が「入荷予定」の数より少ないかどうかにより処理を分ける。

発注済数が入荷予定数より多い場合は、ステップＳ４０７へと処理を遷移し、発注済数が入荷予定数より少ない場合は、ステップＳ４０８へと処理を遷移する。

ステップＳ４０７へと処理を遷移すると、発注管理サーバ２００のＣＰＵ２０１は、ステップＳ４０４で入力された値（入荷予定より多い数）を図６の６０２の発注テーブルの当日欄（たとえば『２０１７／５／１０』の「入荷数」欄）に入力する。入荷予定より多い数を入荷するパターンとしては、たとえば複数個をパッキングしている時に、端数を入荷する場合である。

一方、ステップＳ４０８へと処理を遷移すると、発注管理サーバ２００のＣＰＵ２０１は、入荷予定数よりも発注済数の方が少ないため、残りの発注が翌日以降に届くのか届かないのかを入力させるための画面を入荷を受け付けるユーザに表示する。図７を参照して、発注のキャンセル処理を説明する。

図７の７００において、当初「入荷予定」７０３には『１３０』が設定されていたが、「発注済」欄７０１には『１００』しか入っておらず、残り３０個が生産者側でキャンセルされたものか、翌日以降に入荷するものなのか不明である。そのため、入荷を受け付けるユーザは、生産者に確認し残りの入荷はキャンセルされるのか入荷残なのかを確認後、データとして、残すために「キャンセル倉庫」７０２の入力をさせる。

たとえば、入荷されるはずだった残り３０個が全てキャンセルされる場合は、キャンセル倉庫欄７０３には『３０』が入力され、発注管理サーバ２００は、残り３０個はキャンセル数として設定する。なお、キャンセル倉庫入力欄は、入荷予定数よりも発注済数が少ない場合のみアクティブにして、発注済数が入荷予定数以上の場合は非アクティブにしても良い。図４のフローチャートの説明に戻る。

次のステップＳ４０９において、発注管理サーバ２００のＣＰＵ２０１は、当日もしくは翌日の入荷残の値として設定する処理を行う。具体的には、（入荷予定数−発注済数−キャンセル倉庫数）を算出し、算出した値を当日もしくは翌日以降の「入荷予定」に設定する。図７を参照して、翌日の「入荷予定」の数を設定する例を説明する。

図７の７００において、７０２のキャンセル倉庫欄に『３０』が入力されると、発注済数として７０１に『１００』が入力されているので、入荷予定であった１３０個の内、翌日に引き当てられる入荷残は（１３０−１００−３０＝０）となり、５月１１日の入荷予定が元々０であったので、入荷残を足しても０（７０５）となる。このように、キャンセル倉庫の入力欄７０２を設けることにより、入荷を受け付けるユーザが不足した発注分をキャンセルされるべきなのか入荷残として残すべきなのかを判断して入力することができ、入荷予定を立てる上位権限者の手を煩わすことなく、入荷数をキャンセルすることができる効果を有する。図４のフローチャートの説明に戻る。

ステップＳ４０７、Ｓ４０９、Ｓ４１０の処理が終わると、フローチャートはステップＳ７０１へと処理を戻し、別の商品の入荷予定や発注済の入力を引き続き行う処理となる。

以上の処理により、入荷計画で発注され、在庫管理していく場合、生産者の都合で、データと実際に納入された数量で差異が発生する場合でも正しく在庫状況を管理することができる効果を有する。

なお、本実施形態では、上記のような構成で考えたが、データの構成や表示画面イメージおよびその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されることは言うまでもない。

以上、一実施形態について示したが、本発明は、たとえば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

なお、本実施形態中に示した各変形例を組み合わせた構成もすべて本発明に含まれるものである。

なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、たとえばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、たとえばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図４に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

プログラムコードを供給するための記録媒体としては、たとえば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウェアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのソフトウェアによって表されるプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

１００ クライアント端末
１１０ ネットワーク
２００ 発注管理サーバ

Claims (4)

1. 対象在庫品の入荷予定数を記憶する記憶手段を有する管理サーバであって、
   前記対象在庫品の発注数が、前記記憶手段に記憶された入荷予定数に達しなかった場合、入荷予定数に達しなかった数を算出する算出手段と、
   前記算出手段で算出された入荷予定数に達しなかった数の内、発注がキャンセルされた数を記憶するキャンセル倉庫記憶手段と
   前記算出手段で算出された入荷予定数に達しなかった数から前記キャンセル倉庫記憶手段に記憶された発注がキャンセルされた数を入荷残として記憶する入荷残記憶手段と
   を有することを特徴とする管理サーバ。
2. 前記キャンセル倉庫記憶手段への入力を制御するキャンセル倉庫入力制御手段と、
   前記キャンセル倉庫入力制御手段は、前記対象在庫品の発注数が前記記憶手段に記憶された入荷予定数に達しなかった場合のみアクティブとすることを特徴とする請求項１に記載の管理サーバ。
3. 対象在庫品の入荷予定数を記憶する記憶手段を有する管理サーバにおける制御方法であって、
   前記対象在庫品の発注数が、前記記憶手段に記憶された入荷予定数に達しなかった場合、入荷予定数に達しなかった数を算出する算出ステップと、
   前記算出ステップで算出された入荷予定数に達しなかった数の内、発注がキャンセルされた数を登録するキャンセル倉庫登録ステップと
   前記算出ステップで算出された入荷予定数に達しなかった数から前記キャンセル倉庫登録ステップで登録された発注がキャンセルされた数を入荷残として記憶する入荷残登録ステップと
   を有することを特徴とする制御方法。
4. 対象在庫品の入荷予定数を記憶する記憶手段を有する管理サーバを動作させるプログラムであって、
   前記管理サーバを
   前記対象在庫品の発注数が、前記記憶手段に記憶された入荷予定数に達しなかった場合、入荷予定数に達しなかった数を算出する算出手段と、
   前記算出手段で算出された入荷予定数に達しなかった数の内、発注がキャンセルされた数を登録するキャンセル倉庫登録手段と
   前記算出手段で算出された入荷予定数に達しなかった数から前記キャンセル倉庫登録手段で登録された発注がキャンセルされた数を入荷残として記憶する入荷残登録手段として動作させることを特徴とするプログラム。

Images