(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0015】
本発明の実施形態の内容を列記して説明する。本発明は、以下のような構成を備える。
[項目1]
第一ユーザの在庫情報を記憶する在庫情報記憶部と、
少なくとも荷物の識別情報及び出荷情報から入荷予定データを生成する入荷予定データ生成部と、
前記荷物の第一の重量データを取得する第一重量データ取得部と、
前記第一の重量データが所定の条件を満たしているか否かを判定する判定部と、
前記判定部が前記第一の重量データが所定の条件を満たしていると判定した場合に、前記入荷予定データを入荷済データに変換する入荷済データ生成部と、
前記入荷済データに基づいて、前記在庫情報記憶部を更新するための在庫情報に変換する在庫情報生成部、
とを備えることを特徴とする、在庫管理システム。
[項目2]
前記入荷予定データには、前記荷物について出荷前に第二の重量データ取得部によって取得された第二の重量データが含まれており、
前記判定部は、前記第一の重量データと、前記第二の重量データとの差を比較することによって前記判定を行うことを特徴とする、項目1に記載の在庫管理システム。
[項目3]
前記判定部は、前記出荷情報に基づいて、荷物の推定重量を算出し、
前記第一の重量データと前記推定重量とを比較することによって前記判定を行うことを特徴とする、項目1または2に記載の在庫管理システム。
[項目4]
前記荷物を出荷する第二ユーザが使用する商品情報と、前記第一ユーザが使用する物品情報とを対応付ける商品物品対応部をさらに備えること、
を特徴とする、項目1〜3のいずれかに記載の在庫管理システム。
[項目5]
前記荷物を出荷する第二ユーザが使用する商品情報と、前記第一ユーザが使用する物品情報との対応関係を記憶する対応情報記憶部をさらに備え、
前記商品物品対応部は、前記対応情報記憶部に記憶された情報に基づいて、前記商品情報と前記物品情報とを対応付けること、
を特徴とする、項目4に記載の在庫管理システム。
[項目6]
前記出荷情報には商品の画像データが含まれ、
前記商品物品対応部は、前記画像を分析することによって、前記出荷情報に含まれる商品情報と前記在庫情報記憶部に含まれる物品情報とを対応付けることを特徴とする、項目5に記載の在庫管理システム。
[項目7]
前記商品物品対応部は、少なくとも名称、取扱い数量の増減、及び他の取扱い商品・物品の種類・属性のうち一つ以上の類似度を計算することによって、
前記商品情報と前記物品情報とを対応付けることを特徴とする、
項目4に記載の在庫管理システム。
[項目8]
さらに、前記入荷済データに基づいて会計情報を生成する会計情報生成部を備えることを特徴とする、項目1〜7のいずれかに記載の在庫管理システム。
[項目9]
前記在庫情報記憶部は、少なくとも物品ごとの在庫数量及び発注条件を記憶しており、
前記発注条件を満たした物品について所定の注意喚起情報を生成する注意喚起情報生成部をさらに有することを特徴とする、項目1〜8のいずれかに記載の在庫管理システム。
[項目10]
前記注意喚起情報は、前記物品の仕入先に提供することを特徴とする、項目9に記載の在庫管理システム。
[項目11]
前記注意喚起情報に基づいて、前記発注条件を満たした物品に係る受注済データを生成する受注済データ生成部をさらに備えることを特徴とする、項目11に記載の在庫管理システム。
【0016】
<実施の形態の詳細>
以下、本発明の実施の形態について、図面を参照しながら説明する。
【0017】
図1に示されるように、本発明の在庫管理システム1は、第一ユーザ端末2及び第二ユーザ端末3と通信を介して情報処理を実行する。在庫管理システム1は、例えばワークステーションやパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。在庫管理システム1は、いわゆるWebアプリケーションとしてこれらの機能を実行することを想定する。
【0018】
第一ユーザ端末2、第二ユーザ端末3は、在庫管理システム1と通信を介して情報処理を実行することにより、サービスを利用する。第一ユーザ端末2、第二ユーザ端末3は、例えばワークステーションやパーソナルコンピュータのような汎用コンピュータであってもよいし、スマートフォン等の携帯通信機器等であってもよい。
【0019】
図2は、在庫管理システム1のハードウェア構成例を示す図である。在庫管理システム1は、少なくとも、制御部10、メモリ11、ストレージ12、送受信部13、入出力部14等を備え、これらはバス15を通じて相互に電気的に接続される。
【0020】
制御部10は、在庫管理システム1全体の動作を制御し、各要素間におけるデータの送受信の制御、及びアプリケーションの実行に必要な情報処理等を行う演算装置である。例えば制御部10はCPU(Central Processing Unit)であり、ストレージ12に格納されメモリ11に展開されたプログラム等を実行して各情報処理を実施する。
【0021】
メモリ11は、DRAM(Dynamic Random Access Memory)等の揮発性記憶装置で構成される主記憶と、フラッシュメモリやHDD(Hard Disc Drive)等の不揮発性記憶装置で構成される補助記憶と、を含む。メモリ11は、プロセッサ10のワークエリア等として使用され、また、在庫管理システム1の起動時に実行されるBIOS(Basic Input / Output System)、及び各種設定情報等を格納する。
【0022】
ストレージ12は、アプリケーション・プログラム等の各種プログラムを格納する。各処理に用いられるデータを格納したデータベースがストレージ12に構築されていてもよい。
【0023】
送受信部13は、在庫管理システム1をネットワーク3に接続する。なお、送受信部13は、Bluetooth(登録商標)及びBLE(Bluetooth Low Energy)の近距離通信インタフェースを備えていてもよい。
【0024】
入出力部14は、必要に応じて使用するキーボード・マウス類等の情報入力機器、及びディスプレイ等の出力機器である。
【0025】
バス15は、上記各要素に共通に接続され、例えば、アドレス信号、データ信号及び各種制御信号を伝達する。
【0026】
図3は、在庫管理システム1のソフトウェア構成例を示す図である。在庫管理システム1は、受注済データ生成部101、出荷済データ生成部102、入荷予定データ生成部103、判定部104、入荷済データ生成部105、商品物品対応部106、在庫情報生成部107、入荷情報更新部108、会計情報生成部109、注意喚起情報生成部110、第一重量データ取得部111、第二重量データ取得部112、在庫情報記憶部130、入荷情報記憶部140、物品情報記憶部150、出荷情報記憶部160、商品情報記憶部170とを備える。
【0027】
なお、受注済データ生成部101、出荷済データ生成部102、入荷予定データ生成部103、判定部104、入荷済データ生成部105、商品物品対応部106、在庫情報生成部107、入荷情報更新部108、会計情報生成部109、注意喚起情報生成部110、第一重量データ取得部111、第二重量データ取得部112は、在庫管理システム1が備える制御部10がストレージ12に記憶されているプログラムをメモリ11に読み出して実行することにより実現され、在庫情報記憶部130、入荷情報記憶部140、物品情報記憶部150、出荷情報記憶部160、商品情報記憶部170は、メモリ11およびストレージ12の少なくともいずれかにより提供される記憶領域の一部として実現される。
【0028】
本明細書においては、商品等の物品を発注し入荷する側を第一ユーザ、物品を出荷する側を第二ユーザとして記載する。
【0029】
在庫情報記憶部130は、第一ユーザが保有する在庫データを記憶する。
図4は、在庫情報記憶部130に記憶される情報の一例である。在庫情報には、物品ごとに、例えば物品名、カテゴリ、保管場所、数量、発注点、更新日、物品ID等の項目が記録される。ほかに、物品の写真や、データ作成日、棚卸日等を記録してもよく、適宜選択することが可能である。また、これらの物品に関する情報を読み出すQRコードやバーコードの情報も含んでよい。ここで、発注点とは、物品ごとに任意で設定されるものであり、次の発注を行う条件である。発注点には少なくとも次の発注を行うタイミングに係る条件が含まれ、さらに1回の発注における発注数量の設定を含むこともできる。例えば水の2Lペットボトルの在庫について、在庫が残り3本になったときに、5本発注を行うといったルールを発注条件として設定することができる。
【0030】
入荷情報記憶部140は、第一ユーザの発注前データ、発注済データ、入荷予定データ、及び入荷済データ等を記憶する。
図5は、入荷情報記憶部140に記憶される情報の一例である。入荷情報には、物品ごとに入荷ID、入荷ステータス、物品名、物品ID、数量、合計金額、仕入先、登録日等が記録される。これらの項目は適宜選択可能であり、画像データ等他の項目を追加することもできる。ここで、入荷ステータスとは、物品の発注から入荷完了までの間で、例えば「発注前」、「発注済」、「入荷予定」、「入荷済」のいずれの状態であるかを示す情報である。例えば、発注前は、担当者等が発注データを入力したもので、まだ社内決済が下りていないもの等を指す。発注済は、発注完了から入荷予定データの入力前のものを指す。入荷予定は、仕入先から出荷情報が届いたものを指す。入荷済は、入荷したことが検品等により確認できたものを指す。入荷ステータスとしてはこれら以外にも、発注中止や返品等他のステータスを追加することもできるし、必要に応じて発注前、発注済、入荷予定のステータスを全て「入荷予定」に一元化する等、ユーザが運用に合わせて適宜設定することができる。
【0031】
出荷情報記憶部160は、第二ユーザの受注済データ、出荷予定データ、出荷済データ等を記憶する。
図6は、出荷情報記憶部160に記憶される情報の一例である。出荷情報には、出荷ID、出荷ステータス、商品名、商品ID、数量、金額合計、取引先、出荷日等が記録される。これらの項目は適宜選択可能であり、画像データ等ほかの項目を追加することもできる。ここで、出荷ステータスとは、物品の受注から出荷完了までの間で、例えば「受注済」、「出荷予定」、「出荷済」のいずれの状態であるかを示す情報である。受注済は、取引先からの受注を受けたものを指す。出荷予定は、出荷日が確定したものを指す。出荷済は、梱包等の準備が完了したものを指す。出荷ステータスとしてはこれら3つ以外にも、受注取消、返品等他のステータスを追加することもできるし、必要に応じて受注済、出荷予定のステータスを「出荷予定」に一元化する等、ユーザが運用に合わせて適宜設定することができる。
【0032】
物品情報記憶部150は、第一ユーザが保有する物品に関する情報が記憶される。
図7は、物品情報記憶部150に記憶される情報の一例である。物品情報には、第一ユーザが管理に使用する物品名とともに、物品ID、仕入先、発注名称、発注ID、単位当たり重量、仕入単価、画像データ、バーコードデータ等の情報が記憶される。これらの項目は適宜選択可能である。新規で注文する物品については、適宜物品情報記憶部150に情報を登録する。
【0033】
受注済データ生成部101は、第一ユーザからの発注情報に基づいて受注済データを生成する。発注情報の取得は、例えば、CSVファイル形式等の任意の形式の発注済データファイルを読み込むことによって行ってもよいし、第一ユーザが発行した発注済データをクラウドサービスを介して受信してもよい。受注済データ生成部101は、受け取った発注情報を受注済データに変換することができる。また、電話や口頭等で発注を受けた場合は、第二ユーザが受注済データ生成部101に直接入力することによって、受注済データを生成してもよい。また、生成された受注済データに基づいて出荷情報記憶部160が更新される。新たに受注した物品については、出荷ステータスを「受注済」として登録される。
【0034】
さらに、出荷予定データ生成部を設けてもよい。出荷予定データは、受注済の物品のうち、出荷準備ができ出荷日が確定したものについて生成することができる。一つ以上の受注データをまとめてひとつの出荷予定データとすることもできるし、一つの受注データを複数の出荷予定データに分割することもできる
【0035】
出荷済データ生成部102は、出荷済データを生成する。出荷済データは、荷物ごとに、荷物IDと、梱包される物品の情報を含む。さらに、荷物の重量データ(第二の重量データ)も含むと好ましい。第二ユーザがこれらの情報を出荷済データ取得部に入力してもよい。
【0036】
入荷予定データ生成部103は、第一ユーザが受け取る予定の物品の入荷予定データを生成する。入荷予定データは、第二ユーザが発行した出荷済データにおける荷物ID及び物品の出荷情報を含む。従って、入荷予定データは、第二ユーザが発行した出荷済データに実質的に対応したものである。出荷済データの取得は、CSVファイル等の所定の形式の出荷済データファイルを読み込むことによって実施してもよい。CSVファイル等の出荷済みデータファイルは、第二ユーザ又は仲介業者などの第三者が作成したものを受け取ってもよいし、第一ユーザ自らが作成してもよい。また、第二ユーザが発行した出荷済データをクラウドサービスを介して受信してもよい。さらに、第一ユーザに届いた荷物に添付される、荷物情報等の出荷済データを含むQRコード等を第一ユーザが読み取り機器で読み取ることによって、出荷済データを取得してもよい。生成された入荷予定データに基づいて、入荷情報記憶部140の情報を更新することができる。入荷予定データを取得した時点での物品の入荷ステータスは、「入荷予定」である。
【0037】
第一の重量データ取得部は、第一ユーザ側において荷物の重量を測定する手段である。第一の重量データ取得部は、荷物の重量を測定できればよく、既知の手段を採用することができる。
【0038】
第二の重量データ取得部は、第二ユーザ側において荷物の重量を測定する手段である。第二の重量データ取得部は、荷物の重量を測定できればよく、既知の手段を採用することができる。
【0039】
判定部104は、第一ユーザ側において、受け取った荷物の検品を簡易的に行うためのものである。まず判定部104は、同じ荷物IDの荷物について、入荷予定データに含まれる荷物の重量(第二の重量データ取得部で計測された)と、第一ユーザ側で第一の重量データ取得部により取得した、第一の重量データとを比較する。第一の重量データと第二の重量データとが所定の条件を満たしたときに、入荷予定データに登録された物品が数量通り梱包されていると判定し、検品を完了する。一方で、第一の重量データと第二重量データとが所定の条件を満たさない場合には、入荷予定データに登録された物品が届いていないと判定し、その旨の警告を発する。所定の条件とは、例えば2つの重量データの差が、所定値以下であること、若しくは所定割合以下であること、などと設定することができる。
【0040】
また、判定部104は、入荷予定データに第二の重量データが含まれていない場合は、次のような方法により簡易検品を行う。まず判定部104は、入荷予定データに含まれる物品のリストから、荷物全体の推定重量を算出する。判定部104は、入荷予定データに含まれる物品について、物品情報記憶部150を検索し、当該物品の単位当たり重量を参照する。次に、入荷予定データに含まれる物品の数量と、当該物品の単位当たり重量を乗じて、当該物品の数量分の重量を推定する。これを、物品ごとにすべて行い合計することによって、荷物の推定重量を算出することができる。さらに、第一の重量データ取得部によって受け取った荷物の実際の重量データを取得し、推定重量と比較し、第一の重量データと推定重量とが所定の条件を満たしたときに、入荷予定データに登録された物品が数量通り梱包されていると判定し、検品を完了する。一方で、第一の重量データと推定重量とが所定の条件を満たさない場合には、入荷予定データに登録された物品が届いていないと判定し、その旨の警告を発する。所定の条件とは、例えば第一の重量データと推定重量との差が、所定値以下であること、若しくは所定割合以下であること、などと設定することができる。このとき、判定部104は、段ボール等の梱包容器等の物品以外の付属物の重量を加味して判定することができる。例えば、推定重量において、あらかじめ登録された付属物の平均重量を加算する、または、判定条件を、付属物による重量差を吸収できるように設定することができる。
【0041】
入荷済データ生成部105は、入荷予定データに含まれる出荷情報のうち、判定部104による検品が完了したものについて、入荷済データに変換する。判定部104による判定の結果、荷物の重量が所定の条件を満たした場合は、当該荷物の入荷予定データをそのまま入荷済データに変換する。また、判定の結果一部の物品が含まれていないことが明らかとなった場合等は、入荷予定データを修正して入荷済データを生成する。
【0042】
在庫情報生成部107は、検品が終了した物品について、在庫情報記憶部130を更新するために、入荷済データに含まれる出荷情報を在庫データに変換する。判定部104によって簡易検品を実施し、入荷予定データに登録された物品が数量通りパッキングされていると判定がなされた場合に、第一ユーザ端末には、在庫情報を更新してもよいかを確認するメッセージが表示され、第一ユーザが更新してもよい旨の情報を入力すると、在庫情報生成部107は入荷済データから在庫データを生成する。または、上記確認するメッセージを表示することなく、自動的に在庫データを生成することとしてもよい。例えば、牛乳が3本入荷した場合は、牛乳の在庫を3個増加させる情報を生成する。生成された在庫データにより、在庫情報記憶部130は更新される。
【0043】
入荷情報更新部108は、入荷済データに基づいて、入荷情報記憶部140を更新する。入荷情報記憶部140に登録されている物品において、ステータスが「発注済」、「入荷予定」である物品について、検品が完了したものは、ステータスを「入荷済」に更新する。
【0044】
会計情報生成部109は、入荷済データに基づいて、会計情報を生成する。ここでいう会計情報とは、第一ユーザが使用する会計システムに今般の入荷に係る会計処理を実行させるための元となる情報を含む。例えば、入荷済データから、「仕入」や「買掛金」の仕訳データ及び日付の情報等を生成する。仕入、買掛金の金額は、物品情報記憶部150に物品ごとの仕入単価が記憶されている場合、入荷済データに含まれる物品について物品情報記憶部150から仕入単価を参照し、当該仕入単価に物品の入荷数量を乗じて仕入額や買掛金の額としてもよい。会計情報生成部109は、第一ユーザ端末に、会計システムと連動してもよいか確認するメッセージを表示することができる。第一ユーザが連動してもよい旨の入力を行うことによって、会計情報生成部109は会計情報を生成し、会計システムと連動させる。会計システムは特に制限はなく、上記会計情報の形式は、使用している会計システムに合わせて生成することができる。
【0045】
ここで、本発明のシステムにおいては、入荷済データを生成することなく、検品が終了した入荷予定データに含まれる出荷情報から直接在庫情報の生成、入荷情報の更新、会計情報の生成を行うこととしてもよい。
【0046】
商品物品対応部106は、第二ユーザが使用する商品情報と第一ユーザが使用する物品情報との間で名称やIDが異なる場合に、対応付けを行う。商品物品対応部106は、商品情報と物品情報の対応関係を記憶する対応情報記憶部を参照し、前記商品情報と前記物品情報とを対応付ける。参照する対応情報記憶部は、上述した物品情報記憶部150や商品情報記憶部170であってもよく、別途専用のデータベースを備えてもよい。対応付けの方法は、後述する。
【0047】
注意喚起情報生成部110は、発注条件を満たした物品について所定の注意喚起情報を生成する。在庫情報記憶部130は、物品ごとに発注条件を記憶している場合がある。発注条件とは、物品ごとに、残りの在庫数量が一定数以下になったら、次の発注を行う、という設定であり、さらに次に発注する際の発注数量の設定も含まれることもある。例えば消耗品などの場合は、発注条件を設定しておくことで在庫を切らさないように管理することができる。注意喚起情報生成部110は、在庫情報記憶部130に記憶された物品において、発注条件を満たした物品を検出する。注意喚起情報は、第一ユーザ及び第二ユーザのいずれかに対して通知される。注意喚起情報が第一ユーザに対して通知される場合は、例えば、第一ユーザ端末に対してメール等の通知をする、または、在庫管理画面においてメッセージ表示したり、当該物品情報の色を変える等、何らかのフラグを立てることなどによって通知を行う。第一ユーザは、在庫が少なくなっていることを認知することができるため、必要に応じて次の発注作業を行う。
【0048】
また、注意喚起情報が仕入先である第二ユーザに対して通知される場合、第二ユーザは、得意先の在庫が少なくなっていることを認知することができるため、必要に応じて出荷作業を行う。注意喚起情報は、発注条件を満たした物品の仕入先(第二ユーザ)を特定し、当該第二ユーザに対して通知を行うことができる。物品の仕入先は、例えば前回の仕入先を選択することとしてもよい。
【0049】
さらに、第一ユーザと第二ユーザとの間で、発注条件を満たした物品について自動的に発注−出荷手続を行うこととしている場合、受注済データ生成部101は、当該発注条件を満たした物品について、所定の受注済データを生成することができる。例えば水の2Lペットボトルについての発注条件が、「在庫が残り3本となった場合に、5本注文すること」であった場合、注意喚起情報生成部110は、水の在庫が残り3本になった時点で、水の仕入先である第二ユーザを特定し、当該第二ユーザに水の在庫が発注条件を満たした旨の通知を行う。さらに、当該第二ユーザの受注済データ生成部101は、発注条件に基づいて、第一のユーザから2Lペットボトルの水を5本注文する旨の受注済データを生成する。
【0050】
次に、本発明の在庫管理システム1の動作について
図8及び
図9により説明する。各ステップは、特段の記載がない場合、順番は適宜変更することができる。
【0051】
まず、第一ユーザが第二ユーザに対して物品を発注する(S1)。発注は、電話、FAX、メール等各種の手段を用いることができる。第一ユーザ側では、必要に応じて発注済データを生成し、入荷情報記憶部140には、当該物品について入荷ステータスが「発注済」として発注データが記録される。
図9(a)は、発注済データの一例である。発注済データには、物品名、物品ID、発注数量、仕入先、及び発注日等の情報を含むことができる。
【0052】
第二ユーザは、各種の手段によって受け取った第一ユーザからの発注データに基づいて、受注済データを生成する(S2)。
図9(b)は、発注済データを変換した受注済データの一例である。受注済データには、発注済データに対応する物品名、物品ID、発注数量が含まれる。また、第二ユーザ側で管理に使用する商品名や商品IDがある場合は、物品名に対応する商品名及び商品IDに書き換えるか若しくは追加してもよい。また、納品先情報を新たに追加する。さらに、第二ユーザの出荷情報記憶部160には、受注済データに基づいて、各物品について出荷ステータスを「受注済」として受注データが記録される。
【0053】
次に、出荷日が確定した物品について、出荷予定データを生成する。さらに、第二ユーザが出荷準備を完了した物品について、出荷済データ生成部102が出荷済データを生成する(S3)。出荷済データには、一つの梱包容器にパッキングされた物品の情報と、当該一つの梱包容器の重量データ(第二の重量データ)とが、梱包容器ごとに付与された荷物IDに紐づけられて登録される。第二ユーザは、出荷前に梱包容器ごとに第二の重量データ取得部によって第二の重量データを取得し、出荷済データに登録する。
図9(c)は、出荷済データの一例である。また、第二ユーザの出荷情報記憶部160において、出荷準備が完了した物品について出荷ステータスを「出荷済」に更新する。
【0054】
第一ユーザの入荷予定データ生成部103は、第二ユーザから出荷済データを取得し、入荷予定データを生成する(S4)。入荷予定データは、荷物ID、第二の重量データ、及び出荷情報を含む。
図9(d)は、入荷予定データの一例である。また、入荷情報記憶部140の物品の入荷ステータスを「入荷予定」に更新する。
【0055】
ここで、入荷予定データ生成部103は、荷物の発送前又は発送直後に入荷予定データを取得し、入荷予定データを発注済データと照らし合わせるステップを設けてもよい(S5)。入荷予定データに含まれる物品およびその数量が、発注済データと合致していない場合は、第一ユーザ端末においてその旨のメッセージを表示するとともに、第二ユーザ端末に対して通知する(S6)。第二ユーザは必要に応じて、出荷予定の荷物を確認し、内容を修正する。
【0056】
入荷予定データの生成は、実際に荷物が第一ユーザの手元に届いた後に、当該荷物の梱包容器等に付与されているバーコード等を読み取ることによって行ってもよい。第一ユーザは、バーコード等読み取り手段によってバーコード等を読み取り、荷物IDとともに中の物品の情報及び、荷物の重量データ(第二の重量データ)を取得する。
【0057】
第一ユーザは、受け取った荷物について、第一の重量データ取得部によって第一の重量データを取得する(S7)。
【0058】
判定部104は、当該取得した第一の重量データが所定の条件を満たすか否かを判定する(S8)。例えば、入荷予定データに第二の重量データが含まれている場合は、第一の重量データと第二の重量データとの差が所定の条件を満たすかどうかを判断する。一方で、第二の重量データが含まれていない場合は、入荷予定データに基づいて荷物の推定重量を算出する。推定重量の算出は、まず、入荷予定データに含まれる物品ごとに、物品情報記憶部150を検索して単位当たり重量を参照する。次に、単位当たり重量を入荷数量に乗じて物品ごとの重量を推定する。物品ごとの重量を入荷予定データに含まれるすべての物品について合計したものが、荷物の推定重量である。判定部104は、第一の重量データと推定重量とが所定の条件を満たすかどうかを判断する。ここで、推定重量には、あらかじめ荷物の梱包容器自体の推定重量を加算しておいてもよいし、所定の条件において梱包容器自体の重量による差異を加味しておいてもよい。
【0059】
第一の重量データが所定の条件を満たした場合、荷物には入荷予定データに含まれるすべての物品が、数量通り届いたと判断することができる。第一のユーザは、従来荷物に含まれる物品の数を数えるなどして、検品の作業を行う必要があったが、本発明によれば第一の重量データを取得するだけで簡易的な検品を実施したこととすることができ、検品作業に係る労力を削減することができる。
【0060】
判定部104が第一の重量データが所定の条件を満たしたと判断した場合、第一ユーザ端末には、入荷予定データに係る物品を入荷済としてもよいか確認する旨のメッセージ等が表示されてもよい。第一ユーザは入荷済処理を許可する旨の入力を行う。入荷済データ生成部105は、入荷予定データを入荷済データに変換する(S9)。
【0061】
続いて、在庫情報生成部107は、入荷済データに含まれる出荷情報に基づいて在庫情報を生成し、在庫情報記憶部130を更新する(S10)。
【0062】
また、入荷情報更新部108は、入荷済データに含まれる出荷情報に基づいて入荷情報記憶部140を更新する(S11)。入荷情報記憶部140に登録された物品について、入荷ステータスを「入荷予定」から「入荷済」に変更する。
【0063】
さらに、会計情報生成部109は、入荷済データに基づいて会計情報を生成する(S12)。会計情報は、会計システムを更新するための元となる情報を含む。入荷済データに含まれる物品について、物品情報記憶部150から仕入単価を参照し、入荷数量と仕入単価とを乗じることによって、当該入荷についての「仕入」、「買掛金」等の会計情報を生成する。生成された会計情報は、所定の会計システムに連携される。
【0064】
次に、第一ユーザと第二ユーザとの間で物品に対する使用名やIDが異なる場合の処理について説明する。このような場合、商品物品対応部106は、第一ユーザが使用する物品情報と、第二ユーザが使用する商品情報との対応付けを実施する。まず、第一ユーザが第二ユーザの使用名に合わせるケースにおいては、第一ユーザが発注済データを第二ユーザに提供する際に、発注済データに第二ユーザにおける商品名や商品IDを掲載する必要がある。また、第二ユーザから提供された出荷済データを入荷予定データに変換する際にも、第二ユーザの商品名及び商品IDから対応する自身の使用物品名を当てはめる必要がある。一例として、第一ユーザが管理上、物品名「牛乳 200mL」、物品ID「002」としている物品が、仕入先である第二ユーザ側では、商品名「北海道すっきり牛乳200mL」、商品ID「GY0020」に対応するケースを例にとって説明する。
【0065】
まず、第一ユーザが物品名「牛乳 200mL」、物品ID「002」について発注済データを生成する際に、商品物品対応部106は、当該選択された物品について、物品情報記憶部150から当該物品に対応する仕入先での商品名及び商品IDを参照する。物品情報記憶部150には、物品名及び物品IDに紐づけて、当該物品の仕入先における商品名及び商品ID等の商品情報が記憶されている。発注済データには、商品名「北海道すっきり牛乳200mL」、商品ID「GY0020」という第二ユーザにおける商品名、商品IDを含ませることができる(
図10(a))。
【0066】
第二ユーザは、受け取った発注済データに、商品名「北海道すっきり牛乳200mL」、及び商品ID「GY0020」が含まれているため、そのまま受注済データに変換(
図10(b))することができる。また、出荷済データにおいても同様の商品情報を含ませる。
【0067】
続いて第一ユーザが、第二ユーザから取得した出荷済データから入荷予定データに変換する際は、商品物品対応部106は、出荷済データに含まれる商品名及び商品IDから、第一ユーザが自社で使用する物品名及び物品IDとの対応づけを行う。商品物品対応部106は、出荷済データに含まれる商品名及び商品IDに基づいて、物品情報記憶部150から物品名及び物品IDを参照して、入荷予定データに入力することができる。入荷予定データにおいて物品名及び物品IDが明らかになることによって、発注済みデータとの間での照合が可能となる。さらに、入荷情報記憶部140及び在庫情報記憶部130を更新する際にも、物品名及び物品IDにより情報を更新する。
【0068】
次に、第一ユーザと第二ユーザとの間で物品に対する使用名が異なる場合であって、第二ユーザが第一ユーザの使用名に合わせるケースを説明する。このケースにおいては、第一ユーザから受け取った発注済データを受注済データに変換する際に、発注済データに記載される物品名及び物品IDから、自社で使用する商品名及び商品IDを特定して受注済データに変換する必要がある。また、第一ユーザへ提供する出荷済データに物品名及び物品IDを含ませる必要がある。
【0069】
ここで、第二ユーザが取り扱う商品情報を格納する商品情報記憶部170には、商品ごとに、取引先(納品先)における物品名及び物品ID等の情報が紐づけて記憶される。まず、第一ユーザからの発注情報に基づいて受注済データを生成する際に、商品物品対応部106は、発注情報に含まれる物品名及び物品IDに基づいて第二ユーザの商品情報記憶部170から対応する商品名及び商品IDを参照する。また、出荷済データにも発注情報に含まれる物品名及び物品IDを記載しておくことができる。第一ユーザは、出荷済データに物品名及び物品IDが記載されているので、そのまま入荷予定データに変換することができる。
【0070】
以上述べた方法の他に、画像認識を利用して商品の対応付けを行う方法を採用することもできる。まず、第一ユーザは発注済データとして物品名等と一緒に物品の画像データを添付する。第二ユーザが発注済データを入手すると、商品物品対応部106は、発注済データに含まれる物品の画像データを分析することによって、自社で使用する商品名及び商品IDを特定し、受注済データに反映する。同様に、第二ユーザは、出荷済データにおける出荷情報に、商品名等とともに商品の画像データを添付する。第一ユーザが出荷済データを入手すると、商品物品対応部106が出荷情報に含まれる商品の画像データを解析することによって、自社で使用する物品名及び物品IDを特定して入荷予定データに変換することができる。
【0071】
画像データから商品・物品を特定する手段は、機械学習等の既知の画像認識方法を用いることができる。機械学習を利用する場合は、あらかじめ、取り扱う商品・物品ごとに複数の画像データを読み込み、物品情報記憶部150や商品情報記憶部170若しくは他のデータベースに記憶しておく。そして、受発注データに含まれる画像から文字や形状、色、模様などの特徴量を抽出し、商品・物品を特定する。
【0072】
また、バーコードを利用して商品の対応付けを行う方法を採用することもできる。バーコードは、商品やそのパッケージに一般的に印字されているJANコード等のバーコードである。バーコードは商品に固有の番号として付与されているので、第一ユーザと第二ユーザとの間で共通して認識することができる。バーコードデータは、物品情報記憶部150や商品情報記憶部170若しくは他のデータベースに記憶しておく。この場合、第一ユーザは、発注済データとして物品名等と一緒に物品のバーコードデータを添付する。第二ユーザが発注済データを入手すると、商品物品対応部106は発注済みデータに含まれるバーコードデータから自社の商品名及び商品IDを特定して受注済データに反映する。同様に、第二ユーザは、出荷済データにおける出荷情報に、商品名等とともに商品のバーコードデータを添付する。第一ユーザが出荷済データを入手すると、商品物品対応部106が出荷情報に含まれるバーコードデータから、自社で使用する物品名及び物品IDを特定して入荷予定データに反映させることができる。
【0073】
さらに、商品物品対応部106は、機械学習を使って第一ユーザが使用する物品名と第二ユーザが使用する商品名とを対応付けることもできる。以下に簡単な例を示す。例えば、第二ユーザが出荷時の商品名を「タピオカ」としており、第一ユーザが誤って物品名を「タピオヤ」として登録していた場合、形式的に名称は異なるのでそのままでは対応付けをすることができない。しかし、「タピオカ」という商品名について、「タピオヤ」は4文字中3文字が一致している、最近の取扱数量の増加ペースが類似している、入荷側のそれ以外の取扱い在庫がジュースなどの飲料を扱っている、等の情報を総合的に判断して、「タピオヤ」が商品名「タピオカ」と対応している可能性が高いことを判断することができる。一方で、商品名「タピオン」という工業製品が入荷された場合であっても、同じ企業内の他のデータを分析し、「タピオン」を出荷した企業が他に出荷している商品が主に工業製品であった場合「タピオン」はタピオカではないと判断することができる。
このように、クラウドデータ内の複数の第一ユーザ、第二ユーザの在庫データを参照することによって、少なくとも名称、取扱い数量の増減、及び他の取扱い商品・物品の種類・属性のうち一つ以上の類似度を計算することによって、ある物品名と商品名とが同じものを指していることを推測することができる。当該機能を使うと、例えば第一ユーザが出荷情報を受け取って入荷予定データを生成する際に、出荷情報に含まれる商品名は、第一ユーザの在庫情報の中のどの物品に対応していかを推測し、リコメンドすることなどが可能となる。
【0074】
以上の例では、第一ユーザ側について物品名及び物品ID、第二ユーザ側について商品名及び商品IDを両方使用したが、それぞれ名称及びIDのどちらかだけであってもよい。上述したように、第一ユーザと第二ユーザとで物品名及び商品名が一致しない場合に、商品物品対応部106が物品情報記憶部150又は商品情報記憶部170を参照することによって対応付けることが可能であるため、互いの受発注データをスムーズに利用することができる。
【0075】
上述した実施の形態は、本発明の理解を容易にするための例示に過ぎず、本発明を限定して解釈するためのものではない。本発明は、その趣旨を逸脱することなく、変更、改良することができると共に、本発明にはその均等物が含まれることは言うまでもない。
【解決手段】本発明は、入出荷の手間を削減できる在庫管理システムを提供することを一つの目的とする。本発明は、第一ユーザの在庫情報を記憶する在庫情報記憶部と、少なくとも荷物の識別情報及び出荷情報から入荷予定データを生成する入荷予定データ生成部と、前記荷物の第一の重量データを取得する第一重量データ取得部と、前記第一の重量データが所定の条件を満たしているか否かを判定する判定部と、前記判定部が前記第一の重量データが所定の条件を満たしていると判定した場合に、前記入荷予定データを入荷済データに変換する入荷済データ生成部と、前記入荷済データに基づいて、前記在庫情報記憶部を更新するための在庫情報に変換する在庫情報生成部、とを備えることを特徴とする、在庫管理システムが提供される。