(57)【要約】【課題】複数の店舗にまたがる商品管理、在庫管理、顧客管理、受注管理等を効率化できる多店舗管理システム、多店舗管理装置、多店舗管理方法及びプログラムを提供する。【解決手段】多店舗管理システム１０は、複数のモール２００と、多店舗管理装置１００と、を含む。多店舗管理装置１００は、モール２００から商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得する情報更新部１１７、１２７、１３７、１４７又は１５７と、モール２００から取得された情報を所定の変換ルールに従って変換する情報変換部１１５、１２５、１３５、１４５又は１５５と、変換後の情報を格納する情報記憶部１１１、１２１、１３１、１４１又は１５１と、を有することを特徴とする。【選択図】図１
2019101827.tif 000002
【特許請求の範囲】
【請求項１】
複数のモールと、多店舗管理装置と、を含む多店舗管理システムであって、
前記多店舗管理装置は、
前記モールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得する情報更新部と、
前記モールから取得された前記情報を所定の変換ルールに従って変換する情報変換部と、
変換後の前記情報を格納する情報記憶部と、を有することを特徴とする
多店舗管理システム。
【請求項２】
前記情報更新部は、前記モールにおける前記情報の変動を検知して、前記モールから前記情報を取得することを特徴とする
請求項１記載の多店舗管理システム。
【請求項３】
前記情報更新部は更に、前記情報記憶部から前記情報を取得し、
前記情報変換部は更に、前記情報記憶部から取得された前記情報を所定の変換ルールに従って変換し、
変換後の前記情報が前記モールに送信されることを特徴とする
請求項１記載の多店舗管理システム。
【請求項４】
前記情報更新部は、前記情報記憶部における前記情報の変動を検知して、前記情報記憶部から前記情報を取得することを特徴とする
請求項３記載の多店舗管理システム。
【請求項５】
前記情報記憶部は、商品が在庫する１以上の倉庫の所在地に関する情報を含む前記商品情報を保有することを特徴とする
請求項１記載の多店舗管理システム。
【請求項６】
前記情報記憶部は、商品を発注した顧客の所在地に関する情報を含む前記顧客情報を保有し、
前記顧客の所在地と、前記倉庫の所在地と、の関係に基づいて前記発注にかかる前記商品を引当てる前記倉庫を選択する在庫引当部を更に有することを特徴とする
請求項５記載の多店舗管理システム。
【請求項７】
前記情報記憶部は、複数の前記モールを利用する同一顧客に関する前記顧客情報を統合して管理することを特徴とする
請求項１記載の多店舗管理システム。
【請求項８】
複数のモールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得する情報更新部と、
前記モールから取得された前記情報を所定の変換ルールに従って変換する情報変換部と、
変換後の前記情報を格納する情報記憶部と、を有することを特徴とする
多店舗管理装置。
【請求項９】
情報更新部が、複数のモールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得するステップと、
情報変換部が、前記モールから取得された前記情報を所定の変換ルールに従って変換するステップと、
情報記憶部が、変換後の前記情報を格納するステップと、を有することを特徴とする
多店舗管理方法。
【請求項１０】
請求項９記載の多店舗管理方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は多店舗管理システム、多店舗管理装置、多店舗管理方法及びプログラムに関し、特に複数の店舗にまたがる商品管理、在庫管理、顧客管理、受注管理等を効率化する技術に関する。
【背景技術】
【０００２】
近年、インターネット等のコンピュータネットワーク上に開設された店舗（以下、ネットショップと称する）で、物やサービスが販売されるようになった。ネットショップは、例えばモール運営者が提供するＥＣ（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｅｒｃｅ）プラットフォームに出店者として参加したり、ソフトウェアベンダーが供給するＥＣフレームワークを利用して独自のサイトを構築したり、オークションサイトに出品者として参加したりする等、様々な形態で実現することができる。これらのプラットフォーム、フレームワーク及びサイト等（以下、単にモールと称する）は、商品管理、受注管理、受注管理、入金管理、配送管理又は顧客管理等を行うための機能を提供していることが一般的である。しかし、それらの機能の仕様はモール毎に異なる。そのため、従来、複数のモールで販売を行う事業者は、たとえ複数のモールで同一の商品を販売するような場合であっても、モール毎に異なる方法で出品や受注等の処理を行う必要があった。これは非常に煩雑な作業であり、複数のネットショップを運営する際のコストを増大させる要因となっていた。
【０００３】
この点、特許文献１には、複数のモールに商品を出品したり、複数のモールで発生した注文情報を処理したりするためのシステムが開示されている。具体的には、仲介役となるモールが、自己が有する商品データを、他のモールが受入可能な形式に変換して、上記他のモールに送信する。また、仲介役となるモールは、他のモールが保有する注文データを取得し、注文データの処理装置が受入可能な形式に変換して、上記注文データの処理装置に転送する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許第４２２５０８５号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、特許文献１記載のシステムでは、商品情報は常に仲介役のモールから他のモールへの一方向で同期される。したがって、例えば他のモールに既に登録されている商品を仲介役のモールにも登録するといった動作は行えないため、利便性に限界がある。
【０００６】
また、特許文献１記載のシステムでは、複数のモールから受注した商品の配送等の処理を１つの拠点で一元的に実施する。ところが現在では、複数の倉庫（モール側が運営する倉庫も含む）に商品をストックしておき、受注内容に応じて最適な倉庫から発送を行うといった、より複雑な配送条件が適用されることが多い。特許文献１記載のシステムは、このような複雑化する配送条件に対応できない。
【０００７】
また、特許文献１記載のシステムでは、複数のモールを横断して顧客の購買履歴等を管理することが困難である。ネットショップは、複数のモールで同時に販促等を実施することがある。例えば顧客１人あたりの購入点数に上限を設けたり、顧客のロイヤリティに応じて優遇を行ったりすることがあるが、特許文献１記載のシステムは、店舗側のこうした行動を十分にサポートする機能を提供していない。
【０００８】
本発明は、このような問題点を解決するためになされたものであり、複数の店舗にまたがる商品管理、在庫管理、顧客管理、受注管理等を効率化できる多店舗管理システム、多店舗管理装置、多店舗管理方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明にかかる多店舗管理システムは、複数のモールと、多店舗管理装置と、を含む多店舗管理システムであって、前記多店舗管理装置は、前記モールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得する情報更新部と、前記モールから取得された前記情報を所定の変換ルールに従って変換する情報変換部と、変換後の前記情報を格納する情報記憶部と、を有することを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報更新部は、前記モールにおける前記情報の変動を検知して、前記モールから前記情報を取得することを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報更新部は更に、前記情報記憶部から前記情報を取得し、前記情報変換部は更に、前記情報記憶部から取得された前記情報を所定の変換ルールに従って変換し、変換後の前記情報が前記モールに送信されることを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報更新部は、前記情報記憶部における前記情報の変動を検知して、前記情報記憶部から前記情報を取得することを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報記憶部は、商品が在庫する１以上の倉庫の所在地に関する情報を含む前記商品情報を保有することを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報記憶部は、商品を発注した顧客の所在地に関する情報を含む前記顧客情報を保有し、前記顧客の所在地と、前記倉庫の所在地と、の関係に基づいて前記発注にかかる前記商品を引当てる前記倉庫を選択する在庫引当部を更に有することを特徴とする。
本発明にかかる他の多店舗管理システムにおいては、前記情報記憶部は、複数の前記モールを利用する同一顧客に関する前記顧客情報を統合して管理することを特徴とする。
請求項１記載の多店舗管理システム。
本発明にかかる多店舗管理装置は、複数のモールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得する情報更新部と、前記モールから取得された前記情報を所定の変換ルールに従って変換する情報変換部と、変換後の前記情報を格納する情報記憶部と、を有することを特徴とする。
本発明にかかる多店舗管理方法は、情報更新部が、複数のモールから商品情報、顧客情報、受注情報、入金情報又は配送情報のうち少なくともいずれか１つの情報を取得するステップと、情報変換部が、前記モールから取得された前記情報を所定の変換ルールに従って変換するステップと、情報記憶部が、変換後の前記情報を格納するステップと、を有することを特徴とする。
本発明にかかるプログラムは、上記多店舗管理方法をコンピュータに実行させるためのプログラムである。
【発明の効果】
【００１０】
本発明により、複数の店舗にまたがる商品管理、在庫管理、顧客管理、受注管理等を効率化できる多店舗管理システム、多店舗管理装置、多店舗管理方法及びプログラムを提供することができる。
【図面の簡単な説明】
【００１１】
【図１】多店舗管理システム１０の構成例を示すブロック図である。
【図２】商品情報記憶部１１１の一例を示す図である。
【図３】商品情報入力部１１３の一例を示す図である。
【図４】顧客情報記憶部１２１の一例を示す図である。
【図５】顧客情報入力部１２３の一例を示す図である。
【図６】受注情報記憶部１３１の一例を示す図である。
【図７】受注情報入力部１３３の一例を示す図である。
【図８】入金情報記憶部１４１の一例を示す図である。
【図９】入金情報入力部１４３の一例を示す図である。
【図１０】配送情報記憶部１５１の一例を示す図である。
【図１１】配送情報入力部１５３の一例を示す図である。
【図１２】商品情報の展開処理例を示すフローチャートである。
【図１３】出荷元倉庫の最適化処理例を示すフローチャートである。
【図１４】顧客の一元管理処理例を示すフローチャートである。
【図１５】受注情報の更新処理例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。まず、図１を用いて、本発明の実施の形態にかかる多店舗管理システム１０の構成について説明する。
【００１３】
多店舗管理システム１０は、多店舗管理装置１００、複数のモール２００、必要に応じ金融機関３００を含む。多店舗管理装置１００、モール２００、金融機関３００は、ネットワーク４００を介して通信可能に接続される。多店舗管理装置１００、モール２００、金融機関３００はそれぞれ、典型的には中央処理装置（ＣＰＵ）、記憶装置及び入出力装置等を有するコンピュータであり、記憶装置に格納されたプログラムをＣＰＵが読み出して実行することにより所定の機能を実現する。多店舗管理装置１００、モール２００、金融機関３００は必ずしも単一のコンピュータである必要はなく、複数のコンピュータにより構成されても良い。例えば多店舗管理装置１００、モール２００の各処理部は、分散した情報処理環境においてその機能が実現されても良い。
【００１４】
複数のモール２００はそれぞれネットショップの商品の販売等を行う。各モール２００は、商品ＤＢ２１０、顧客ＤＢ２２０、受注ＤＢ２３０を有する。加えて、決済機能を有するモール２００は入金ＤＢ２４０を有しても良い。発送機能を有するモール２００は配送ＤＢ２５０を有しても良い。
【００１５】
モール２００は、商品ＤＢ２１０にモール２００で販売する商品の商品情報や在庫情報（以下、商品情報等）を記憶する。商品ＤＢ２１０は、商品情報として商品のＩＤ、名称、写真、価格、説明文、属性情報（例えば商品のカテゴリ）等を記憶する。また在庫情報として、商品ＩＤそれぞれについて、モール２００における商品の在庫数を記憶する。在庫情報として各商品の在庫が保管されている１以上の倉庫の名称、所在地等をさらに記憶しても良い。
【００１６】
モール２００は、顧客ＤＢ２２０にモール２００における顧客の顧客情報や履歴情報（以下、顧客情報等）を記憶する。顧客ＤＢ２２０は、顧客情報として顧客のＩＤ、氏名、住所、連絡先（例えば電話番号やメールアドレス）等を記憶する。また履歴情報として、顧客ＩＤそれぞれについて、顧客の購買履歴、要望・クレーム対応履歴等を記憶する。
【００１７】
モール２００は、受注ＤＢ２３０にモール２００において発生した受注の内容を記憶する。受注ＤＢ２３０は、受注情報として受注ＩＤ、受注日時、受注商品の商品ＩＤ、受注数、発注者の顧客ＩＤ等を記憶する。
【００１８】
モール２００は、入金ＤＢ２４０に受注に対応する入金の状況を記憶する。入金ＤＢ２４０は、受注ＩＤ、入金額、入金日時等を記憶する。
【００１９】
モール２００は、配送ＤＢ２５０に商品の配送の状況を記憶する。配送ＤＢ２５０は、受注ＩＤ、出荷日時等を記憶する。
【００２０】
多店舗管理装置１００は、複数のモール２００について横断的な情報管理を行う装置である。多店舗管理装置１００は、商品管理部１１０、顧客管理部１２０、受注管理部１３０、入金管理部１４０、配送管理部１５０を有する。
【００２１】
商品管理部１１０は販売商品の管理を行う。商品管理部１１０は、商品情報記憶部１１１、商品情報入力部１１３、商品情報変換部１１５、商品情報更新部１１７を有する。
【００２２】
商品情報記憶部１１１は、ネットショップが複数のモール２００で取扱う商品の商品情報や在庫情報を一元的に管理するデータベースである。図２に、商品情報記憶部１１１の一例を示す。商品情報記憶部１１１は、商品情報として、例えば商品のＩＤ、名称、写真、価格、説明文、属性情報（例えば商品のカテゴリ）等を記憶する。また在庫情報として、商品ＩＤそれぞれについて、在庫数、複数のモール２００への在庫の按分比率、在庫が保管されている倉庫名、倉庫所在地等を記憶する。ここで在庫の按分比率とは、在庫数を各モール２００にどのような割合で割当てるかを示す数値である。
【００２３】
なお、在庫を複数の倉庫に保管している場合、１つの商品ＩＤに対し、複数の在庫情報を紐付けることができる。例えば図２に示すように、同一の商品ＩＤを含む在庫情報のレコードを複数作成しても良い。
【００２４】
商品情報入力部１１３は、商品情報記憶部１１１に商品情報や在庫情報（以下、商品情報等）を登録したり、商品情報等を編集及び検索したりするための機能を提供する。商品情報入力部１１３は、図３に示すようなユーザインタフェースを介して、商品情報等の登録又は編集を受け付けることができる。あるいは、商品情報等が記載された外部ファイル等を読み込み、記載内容を商品情報記憶部１１１に記録することで、登録又は編集を行っても良い。
【００２５】
商品情報変換部１１５は、商品情報記憶部１１１が記憶する商品情報等を各モール２００が扱える形式へ、又は各モール２００の商品ＤＢ２１０が保有する商品情報等を商品情報記憶部１１１が扱える形式へと変換する。商品情報記憶部１１１と商品ＤＢ２１０とでは、保持するデータの型、サイズ、名称等が相違するためである。商品情報変換部１１５は、所定の変換ルールに従って商品情報等を変換することで、これらの相違を解消する。
【００２６】
なお、商品情報記憶部１１１において各モール２００に対する在庫の按分比率が設定されている場合は、在庫数に各モール２００の按分比率を乗じた数を、各モール２００の商品ＤＢ２１０における在庫数として設定する。
【００２７】
商品情報更新部１１７は、商品情報記憶部１１１と、モール２００の商品ＤＢ２１０との間で、商品情報等の一部又は全部を、一方向又は双方向に同期する処理を行う。例えば商品情報更新部１１７は、商品情報記憶部１１１又は商品ＤＢ２１０の一方における商品情報等の変動（典型的には商品情報等の新規登録、更新、削除等）を検知して、他方への同期処理を開始する。あるいはユーザによる要求など任意のイベントをトリガとして同期処理を開始しても良い。
【００２８】
同期処理が開始されると、商品情報更新部１１７は、同期元（商品情報記憶部１１１又は商品ＤＢ２１０）が保持している商品情報等を読み出し、商品情報変換部１１５により同期先が扱える形式に変換する。同期元が商品ＤＢ２１０である場合の商品情報等の取得、及び同期先が商品ＤＢ２１０である場合の商品情報等の送信には、モール２００が用意する種々のインタフェースを利用できる。例えば、商品情報更新部１１７は、モール２００のログイン用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を呼び出し、モール２００から予め与えられたＩＤ等を使用してログイン認証を行う。ログイン後、商品ＤＢ２１０の商品情報等取得用ＡＰＩ又は更新用ＡＰＩを利用して商品情報等を取得又は更新する。なお、ＡＰＩを備えないモール２００に対しては、スクレイピング等の他の公知技術を利用し、モール２００が提供するユーザインタフェースを利用して、ログイン及び商品情報等の取得又は更新を実施しても良い。
【００２９】
これにより、１つのモール２００で取り扱っていた商品の商品情報等を、多店舗管理装置１００がハブとなり、他のモール２００にも展開することができるようになる。
【００３０】
顧客管理部１２０は、顧客情報や購買履歴の管理等を行う。顧客管理部１２０は、顧客情報記憶部１２１、顧客情報入力部１２３、顧客情報変換部１２５、顧客情報更新部１２７、顧客情報統合部１２９を有する。
【００３１】
顧客情報記憶部１２１は、ネットショップの顧客情報を記憶するデータベースである。図４に、顧客情報記憶部１２１の一例を示す。顧客情報記憶部１２１は、顧客情報として、顧客のＩＤ、名前、住所、連絡先（例えば電話番号やメールアドレス）等を記憶する。また履歴情報として、顧客ＩＤそれぞれについて、顧客の購買履歴、要望・クレーム対応履歴、顧客ランク等を記憶する。顧客ランクは、顧客情報記憶部１２１が様々な公知の手法を用いてを算出、設定できる。例えば顧客の購買の累計回数や累計金額等に基づき顧客ランクを算出することができる。又は、ユーザにより任意の顧客ランクが設定されても良い。
【００３２】
顧客情報入力部１２３は、顧客情報記憶部１２１に顧客情報や履歴情報（以下、顧客情報等）を登録したり、商品情報等を編集及び検索したりするための機能を提供する。顧客情報入力部１２３は、図５に示すようなユーザインタフェースを介して、顧客情報等の登録又は編集を受け付けることができる。あるいは、顧客情報等が記載された外部ファイル等を読み込み、記載内容を顧客情報記憶部１２１に記録することで、登録又は編集を行っても良い。
【００３３】
顧客情報変換部１２５は、顧客情報記憶部１２１が記憶する顧客情報等を各モール２００が扱える形式へ、又は各モール２００の顧客ＤＢ２２０が保有する顧客情報等を顧客情報記憶部１２１が扱える形式へと変換する。顧客情報記憶部１２１と顧客ＤＢ２２０とでは、保持するデータの型、サイズ、名称等が相違するためである。顧客情報変換部１２５は、所定の変換ルールに従って顧客情報等を変換することで、これらの相違を解消する。
なお本実施の形態では、顧客ランクは多店舗管理装置１００側のみが保有するデータであるため、変換及び同期を行う必要がない。
【００３４】
顧客情報更新部１２７は、顧客情報記憶部１２１と、モール２００の顧客ＤＢ２２０との間で、顧客情報等の一部又は全部を、一方向又は双方向に同期する処理を行う。例えば顧客情報更新部１２７は、顧客情報記憶部１２１又は顧客ＤＢ２２０の一方における顧客情報等の変動（典型的には顧客情報等の新規登録、更新、削除等）を検知して、他方への同期処理を開始する。あるいはユーザによる要求など任意のイベントをトリガとして同期処理を開始しても良い。
【００３５】
同期処理が開始されると、顧客情報更新部１２７は、同期元（顧客情報記憶部１２１又は顧客ＤＢ２２０）が保持している顧客情報等を読み出し、顧客情報変換部１２５により同期先が扱える形式に変換する。同期元が顧客ＤＢ２２０である場合の顧客情報等の取得、及び同期先が顧客ＤＢ２２０である場合の顧客情報等の送信には、モール２００が用意する種々のインタフェースを利用できる。例えば、商品情報更新部１１７は、モール２００のログイン用ＡＰＩを呼び出し、モール２００から予め与えられたＩＤ等を使用してログイン認証を行う。ログイン後、顧客ＤＢ２２０の顧客情報等取得用ＡＰＩ又は更新用ＡＰＩを利用して顧客情報等を取得又は更新する。なお、ＡＰＩを備えないモール２００に対しては、スクレイピング等の他の公知技術を利用し、モール２００が提供するユーザインタフェースを利用して、ログイン及び顧客情報等の取得又は更新を実施しても良い。
【００３６】
顧客情報統合部１２９は、顧客情報記憶部１２１に含まれる複数の顧客情報等（レコード）を、１つの顧客情報等（レコード）に統合する処理を行う。顧客情報統合部１２９は、例えば顧客ＩＤにより複数の顧客情報等が指定されると、いずれか一方の顧客情報等（以下、統合先情報）に、他方の顧客情報等（以下、統合元情報）の内容を追加し、統合元情報を削除する。なお統合先情報においては、統合先情報の顧客ＩＤが使用される。名前、住所、連絡先等が統合先情報と統合元情報とで異なる場合は、所定のルールに従っていずれか一方のみを統合先情報に残すことができる。
【００３７】
これにより、複数のモール２００に散在する顧客の顧客情報等を、多店舗管理装置１００において一元的に管理することができるようになる。
【００３８】
受注管理部１３０は、受注の管理、在庫の引当て等を行う。受注管理部１３０は、受注情報記憶部１３１、受注情報入力部１３３、受注情報変換部１３５、受注情報更新部１３７、在庫引当部１３９を有する。
【００３９】
受注情報記憶部１３１は、ネットショップの受注情報を記憶するデータベースである。図６に、受注情報記憶部１３１の一例を示す。受注情報記憶部１３１は、受注情報として、受注ＩＤ、受注モール名、受注日時、受注商品の商品ＩＤ、受注数、発注者の顧客ＩＤ等を記憶する。また引当情報として、受注ＩＤそれぞれについて、引当数、倉庫名を記憶する。
【００４０】
受注情報入力部１３３は、受注情報記憶部１３１に受注情報を登録したり、受注情報を編集及び検索したりするための機能を提供する。受注情報入力部１３３は、図７に示すようなユーザインタフェースを介して、受注情報の登録又は編集を受け付けることができる。あるいは、受注情報が記載された外部ファイル等を読み込み、記載内容を受注情報入力部１３３に記録することで、登録又は編集を行っても良い。
【００４１】
受注情報変換部１３５は、受注情報記憶部１３１が記憶する受注情報を各モール２００が扱える形式へ、又は各モール２００の受注ＤＢ２３０が保有する受注情報を受注情報変換部１３５が扱える形式へと変換する。受注情報変換部１３５と受注ＤＢ２３０とでは、保持するデータの型、サイズ、名称等が相違するためである。受注情報変換部１３５は、所定の変換ルールに従って受注情報を変換することで、これらの相違を解消する。
【００４２】
受注情報更新部１３７は、受注情報記憶部１３１と、モール２００の受注ＤＢ２３０との間で、受注情報の一部又は全部を、一方向又は双方向に同期する処理を行う。例えば受注情報更新部１３７は、受注情報記憶部１３１又は受注ＤＢ２３０の一方における受注情報の変動（典型的には受注情報の新規登録、更新、削除等）を検知して、他方への同期処理を開始する。あるいはユーザによる要求など任意のイベントをトリガとして同期処理を開始しても良い。
【００４３】
同期処理が開始されると、受注情報更新部１３７は、同期元（受注情報記憶部１３１又は受注ＤＢ２３０）が保持している受注情報を読み出し、受注情報変換部１３５により同期先が扱える形式に変換する。同期元が受注ＤＢ２３０である場合の受注情報の取得、及び同期先が受注ＤＢ２３０である場合の受注情報の送信には、モール２００が用意する種々のインタフェースを利用できる。例えば、受注情報更新部１３７は、モール２００のログイン用ＡＰＩを呼び出し、モール２００から予め与えられたＩＤ等を使用してログイン認証を行う。ログイン後、受注ＤＢ２３０の受注情報取得用ＡＰＩ又は更新用ＡＰＩを利用して受注情報を取得又は更新する。なお、ＡＰＩを備えないモール２００に対しては、スクレイピング等の他の公知技術を利用し、モール２００が提供するユーザインタフェースを利用して、ログイン及び受注情報の取得又は更新を実施しても良い。
【００４４】
在庫引当部１３９は、受注情報記憶部１３１の受注情報が変動（新規登録、更新又は削除された）したとき、商品在庫を引当てる処理を行う。在庫引当部１３９は、登録又は更新された受注情報の商品ＩＤをキーとして、商品情報記憶部１１１の在庫情報を検索する。該当する在庫情報の在庫数が受注情報の受注数以上であれば、在庫数から受注数を減じ、引当情報の引当数に受注数を計上する。また、引当情報の倉庫名に上記在庫情報に含まれる倉庫名を記録する。
【００４５】
なお在庫情報において按分比率が設定されている場合、在庫引当部１３９は、上記在庫数を、在庫数に受注情報のモール名に対する按分比率を乗じた数と読み替えて、同様の処理を行う。一方、在庫情報の在庫数が受注情報の受注数未満であれば、エラーを出力する。受注情報が削除された場合は、在庫引当部１３９は、その受注数を在庫数に加算し、関連する引当情報を削除する。
【００４６】
なお在庫情報が複数存在する場合、すなわち複数の倉庫に在庫が存在する場合、在庫引当部１３９は、発注者に最も近い倉庫から商品を引き当てることができる。在庫引当部１３９は、受注情報の顧客ＩＤをキーとして、顧客情報記憶部１２１から顧客の住所を取得する。また受注情報の商品ＩＤをキーとして、商品情報記憶部１１１から複数の在庫情報を取得する。在庫引当部１３９は、顧客の住所と、複数の在庫情報に含まれる倉庫の所在地と、の距離を公知技術を利用してそれぞれ比較し、最も顧客の住所に近い倉庫にかかる在庫情報を特定する。在庫引当部１３９は、特定した在庫情報に基づいて上述の引当処理を実行する。なお、特定した在庫情報に含まれる在庫数が受注数に不足する場合は、次に顧客の住所に近い倉庫から引当処理を行っても良い。あるいは単にエラーを出力することとしても良い。
【００４７】
加えて在庫引当部１３９は、顧客情報記憶部１２１に履歴情報を登録しても良い。履歴情報には、顧客ＩＤのほか、受注情報に含まれる任意の項目を含めることができる。
【００４８】
これにより、１つのモール２００で生じた受注による在庫変動を、多店舗管理装置１００がハブとなり、他のモール２００にも反映することができるようになる。
【００４９】
入金管理部１４０は、受注に対する入金の管理等を行う。入金管理部１４０は、入金情報記憶部１４１、入金情報入力部１４３、入金情報変換部１４５、入金情報更新部１４７、消込部１４９を有する。
【００５０】
入金情報記憶部１４１は、受注情報に対応する入金情報を一元的に管理するデータベースである。図８に、入金情報記憶部１４１の一例を示す。入金情報記憶部１４１は、入金情報として、例えば受注ＩＤ、入金額、入金日時等を記憶する。
【００５１】
消込部１４９は、金融機関３００から入金履歴を取得し、入金履歴と受注情報とを突合し、突合結果を入金情報記憶部１４１に記録する。なおモール２００が決済機能を有している場合は、モール２００から入金履歴を取得しても良い。消込部１４９は、典型的には取得した入金履歴に含まれる入金額及び入金者と、受注情報の商品ＩＤ及び受注数から計算される受注金額及び発注者の顧客ＩＤに紐付く氏名と、を照合し、一致する場合、入金情報記憶部１４１に入金情報として当該受注ＩＤ、入金額、入金日時を登録する。
【００５２】
入金情報入力部１４３は、入金情報記憶部１４１に入金情報を手動で登録したり、入金情報を編集及び検索したりするための機能を提供する。入金情報入力部１４３は、図９に示すようなユーザインタフェースを介して、入金情報の登録又は編集を受け付けることができる。あるいは、入金情報が記載された外部ファイル等を読み込み、記載内容を入金情報記憶部１４１に記録することで、登録又は編集を行っても良い。
【００５３】
入金情報変換部１４５は、入金情報記憶部１４１が記憶する入金情報を各モール２００が扱える形式へ、各モール２００の入金ＤＢ２４０が保有する入金情報を入金情報記憶部１４１が扱える形式へと変換する。入金情報記憶部１４１と入金ＤＢ２４０とでは、保持するデータの型、サイズ、名称等が相違するためである。入金情報変換部１４５は、所定の変換ルールに従って入金情報を変換することで、これらの相違を解消する。
【００５４】
入金情報更新部１４７は、入金情報記憶部１４１と、モール２００の入金ＤＢ２４０との間で、入金情報の一部又は全部を、一方向又は双方向に同期する処理を行う。例えば入金情報更新部１４７は、入金情報記憶部１４１又は入金ＤＢ２４０の一方における入金情報の変動（典型的には入金情報の新規登録、更新、削除等）を検知して、他方への同期処理を開始する。あるいはユーザによる要求など任意のイベントをトリガとして同期処理を開始しても良い。
【００５５】
同期処理が開始されると、入金情報更新部１４７は、同期元（入金情報記憶部１４１又は入金ＤＢ２４０）が保持している入金情報を読み出し、入金情報変換部１４５により同期先が扱える形式に変換する。同期元が入金ＤＢ２４０である場合の入金情報の取得、及び同期先が入金ＤＢ２４０である場合の入金情報の送信には、モール２００が用意する種々のインタフェースを利用できる。例えば、入金情報更新部１４７は、モール２００のログイン用ＡＰＩを呼び出し、モール２００から予め与えられたＩＤ等を使用してログイン認証を行う。ログイン後、入金ＤＢ２４０の入金情報取得用ＡＰＩ又は更新用ＡＰＩを利用して入金情報を取得又は更新する。なお、ＡＰＩを備えないモール２００に対しては、スクレイピング等の他の公知技術を利用し、モール２００が提供するユーザインタフェースを利用して、ログイン及び入金情報の取得又は更新を実施しても良い。
【００５６】
これにより、複数のモール２００における入金の管理を、多店舗管理装置１００において一元的に実施できるようになる。
【００５７】
配送管理部１５０は、商品の配送の管理等を行う。配送管理部１５０は、配送情報記憶部１５１、配送情報入力部１５３、配送情報変換部１５５、配送情報更新部１５７、出荷処理部１５９を有する。
【００５８】
配送情報記憶部１５１は、配送情報を一元的に管理するデータベースである。図１０に、配送情報記憶部１５１の一例を示す。配送情報記憶部１５１は、配送情報として、例えば受注ＩＤ、出荷日時等を記憶する。
【００５９】
出荷処理部１５９は、入金情報記憶部１４１を参照し、入金情報が記録されている受注ＩＤを取得し、配送情報記憶部１５１に記録する（入金後に発送を行う場合）。あるいは出荷処理部１５９は、受注情報記憶部１３１を参照し、引当情報が記録されている受注ＩＤを取得し、配送情報記憶部１５１に記録する（入金を待たずに発送を行う場合）。次いで出荷処理部１５９は、配送情報記憶部１５１に記録された受注ＩＤについて出荷指示を出力し、出荷日時を登録する。出荷指示の態様は、例えば出荷指示票の出力、倉庫管理システムや配送業者への出荷指示電文の送信等、任意の公知の技術を用いたものであって良い。
【００６０】
配送情報入力部１５３は、配送情報記憶部１５１に配送情報を手動で登録したり、配送情報を編集及び検索したりするための機能を提供する。配送情報入力部１５３は、図１１に示すようなユーザインタフェースを介して、配送情報の登録又は編集を受け付けることができる。あるいは、配送情報が記載された外部ファイル等を読み込み、記載内容を配送情報記憶部１５１に記録することで、登録又は編集を行っても良い。
【００６１】
配送情報変換部１５５は、配送情報記憶部１５１が記憶する配送情報を各モール２００が扱える形式へ、又は各モール２００の配送ＤＢ２５０が保有する配送情報を配送情報記憶部１５１が扱える形式へと変換する。配送情報記憶部１５１と配送ＤＢ２５０とでは、保持するデータの型、サイズ、名称等が相違するためである。配送情報変換部１５５は、所定の変換ルールに従って配送情報を変換することで、これらの相違を解消する。
【００６２】
配送情報更新部１５７は、配送情報記憶部１５１と、モール２００の配送ＤＢ２５０との間で、配送情報の一部又は全部を、一方向又は双方向に同期する処理を行う。例えば配送情報更新部１５７は、配送情報記憶部１５１又は配送ＤＢ２５０の一方における配送情報の変動（典型的には配送情報の新規登録、更新、削除等）を検知して、他方への同期処理を開始する。あるいはユーザによる要求など任意のイベントをトリガとして同期処理を開始しても良い。
【００６３】
同期処理が開始されると、配送情報更新部１５７は、同期元（配送情報記憶部１５１又は配送ＤＢ２５０）が保持している配送情報を読み出し、配送情報変換部１５５により同期先が扱える形式に変換する。同期元が配送ＤＢ２５０である場合の配送情報の取得、及び同期先が配送ＤＢ２５０である場合の配送情報の送信には、モール２００が用意する種々のインタフェースを利用できる。例えば、配送情報更新部１５７は、モール２００のログイン用ＡＰＩを呼び出し、モール２００から予め与えられたＩＤ等を使用してログイン認証を行う。ログイン後、配送ＤＢ２５０の配送情報取得用ＡＰＩ又は更新用ＡＰＩを利用して配送情報を取得又は更新する。なお、ＡＰＩを備えないモール２００に対しては、スクレイピング等の他の公知技術を利用し、モール２００が提供するユーザインタフェースを利用して、ログイン及び配送情報の取得又は更新を実施しても良い。
【００６４】
これにより、複数のモール２００における配送の管理を、多店舗管理装置１００において一元的に実施できるようになる。
【００６５】
続いて、実施例として、多店舗管理システム１０の幾つかの特徴的な動作について説明する。
＜実施例１：商品情報の展開＞
実施例１は、１つのモール２００（以下、展開元）が保有する商品情報を、他のモール２００（以下、展開先）に展開する処理に関するものである。図１２のフローチャートを用いて、多店舗管理システム１０の動作の一例について説明する。
Ｓ１０１：展開元のモール２００から多店舗管理装置１００への商品情報等の同期処理が開始される。多店舗管理装置１００の商品情報更新部１１７が、ユーザによる要求に応じ、展開元のモール２００が定める方式で、展開元のモール２００の商品ＤＢ２１０から商品情報等を取得する。
Ｓ１０２：商品情報変換部１１５が、Ｓ１０１において取得された商品情報等を、多店舗管理装置１００の商品情報記憶部１１１が扱える形式に変換する。
Ｓ１０３：商品情報更新部１１７が、Ｓ１０２において変換された商品情報等を、商品情報記憶部１１１に格納する。
Ｓ１０４：多店舗管理装置１００から展開先のモール２００への商品情報等の同期処理が開始される。商品情報更新部１１７が、Ｓ１０３における商品情報等の変動を検知して、商品情報記憶部１１１から商品情報等を取得する。
Ｓ１０５：商品情報変換部１１５が、Ｓ１０４において取得された商品情報等を、展開先のモール２００の商品ＤＢ２１０が扱える形式に変換する。
Ｓ１０６：商品情報更新部１１７が、Ｓ１０５において変換された商品情報等を、展開先のモール２００が定める方式で、展開先のモール２００に送信する。
【００６６】
本実施例によれば、展開元のモール２００が既に保有している商品情報等を利用して、多店舗管理装置１００に商品情報等をセットできる。また、多店舗管理装置１００がハブとなり、展開元のモール２００と、展開先のモール２００との間で商品情報等を同期することができる。換言すれば、モール２００がそれぞれ専用形式で保有している商品情報等を、簡便かつ自動的に、多店舗管理装置１００において汎用的な形式に変換して保有することができる。
【００６７】
なお多店舗管理装置１００は、モール２００が保有する商品情報等のうち一部のみを、商品情報記憶部１１１と同期することとしても良い。例えばモール２００に特有の（汎用性の低い）情報は、同期の対象から除外することができる。これにより、汎用性の高い商品情報のみを多店舗管理装置１００において保有し、複数のモール２００間で共有することが可能である。
【００６８】
＜実施例２：出荷元倉庫の最適化＞
実施例２は、複数の倉庫に商品が在庫している場合に、最適な倉庫から出荷を行う処理に関するものである。図１３のフローチャートを用いて、多店舗管理システム１０の動作の一例について説明する。
Ｓ２０１：モール２００において顧客により商品が注文される。モール２００の受注ＤＢ２３０に、この注文に関する新しい受注情報が登録される。
Ｓ２０２：モール２００から多店舗管理装置１００への受注情報の同期処理が開始される。多店舗管理装置１００の受注情報更新部１３７が、受注ＤＢ２３０の変動を検知し、Ｓ２０１において新たに登録された受注情報を、モール２００が定める方式で取得する。
Ｓ２０３：受注情報変換部１３５が、Ｓ２０２において取得された受注情報を、多店舗管理装置１００の受注情報記憶部１３１が扱える形式に変換する。
Ｓ２０４：受注情報更新部１３７が、Ｓ２０３において変換された受注情報を、受注情報記憶部１３１に格納する。
Ｓ２０５：在庫引当部１３９が、受注情報記憶部１３１の変動を検知し、Ｓ２０４において登録された受注情報の商品ＩＤをキーとして、商品情報記憶部１１１の在庫情報を検索する。
ここで複数の在庫情報が取得されたならば、在庫引当部１３９は、受注情報の顧客ＩＤをキーとして、顧客情報記憶部１２１から顧客の住所を取得する。次いで在庫引当部１３９は、顧客の住所と、複数の在庫情報に含まれる倉庫の所在地と、の距離をそれぞれ比較し、最も距離の短い倉庫に関する在庫情報を特定する。
在庫引当部１３９は、特定した在庫情報の在庫数が受注情報の受注数以上であれば、当該在庫情報の在庫数から受注数を減じる処理を行う。また、受注情報記憶部１３１に引当情報を作成し、受注ＩＤ、引当数、倉庫名として、受注情報の受注ＩＤ、受注情報の受注数、在庫情報の倉庫名を記録する。
Ｓ２０６：出荷処理部１５９は、受注情報記憶部１３１を参照し、Ｓ２０５において作成された引当情報の受注ＩＤを取得し、配送情報記憶部１５１に配送情報を作成して、取得した受注ＩＤを登録する（本実施例では入金を待たずに発送を行うものとする）。
出荷処理部１５９は、配送情報記憶部１５１に登録された配送情報に基づいて出荷指示を出力し、配送情報に出荷日時を登録する。これにより、典型的にはＳ２０５で特定された倉庫に対して出荷指示電文が送信され、出荷が実行される。
【００６９】
本実施例によれば、多店舗管理装置１００は商品の在庫情報として倉庫に関する情報を保持し、かつ１つの商品に複数の在庫情報を紐付けることができる。これにより複数の倉庫に分散する商品在庫を容易に管理でき、かつ顧客に最も近い在庫から自動的に出荷を行うことができるので、配送費を最適化することができる。
【００７０】
＜実施例３：顧客の一元管理＞
実施例３は、同一の顧客が複数のモール２００を利用している場合において、当該顧客の購買履歴等を一元管理する処理に関するものである。図１４のフローチャートを用いて、多店舗管理システム１０の動作の一例について説明する。
Ｓ３０１：複数のモール２００から多店舗管理装置１００への商品情報等の同期処理を行う。多店舗管理装置１００の顧客情報更新部１２７が、ユーザによる要求に応じ又は顧客ＤＢ２２０の変動を検知して、複数のモール２００の顧客ＤＢ２２０からそれぞれ顧客情報等を取得する。
Ｓ３０２：顧客情報変換部１２５が、Ｓ３０１において取得された顧客情報等を、多店舗管理装置１００の顧客情報記憶部１２１が扱える形式に変換する。
Ｓ３０３：顧客情報更新部１２７が、Ｓ３０２において変換された顧客情報等を、顧客情報記憶部１２１に格納する。
Ｓ３０４：顧客情報入力部１２３が、ユーザの指示に応じ、顧客情報記憶部１２１から同一の顧客を抽出する。例えばユーザは、顧客情報入力部１２３の検索機能に対し、同一の氏名及び住所等を有する顧客情報等を取得するよう指示を行う。
Ｓ３０５：顧客情報統合部１２９が、ユーザの指示に応じ、Ｓ３０４で抽出された複数の顧客情報等を１つに統合する。以後、この顧客に関する情報は統合後の顧客情報等に集約される。
【００７１】
なお、ステップＳ３０４及びＳ３０５にかかる処理は、ユーザの指示及び操作に依ることなく、多店舗管理装置１００が主体的に実行することが可能である。すなわち多店舗管理装置１００は、所定のトリガに応じて、顧客情報記憶部１２１から所定の基準に従って同一の顧客を抽出し、抽出した顧客情報等を統合することができる。
【００７２】
本実施例によれば、複数のモール２００に存在する顧客が、多店舗管理システム１０においては１つの顧客ＩＤにより管理されるようになる。すなわち複数のモール２００における同一顧客の購買履歴、要望・クレーム対応履歴は、多店舗管理システム１０において横断的に収集され、一元的に蓄積される。したがって、例えば顧客ランクは、複数のモール２００における購買履歴に応じて算出されるので、顧客ランクに応じた販売施策等をより適切に実施できるようになる。また「お一人様１点限り」の商品を、同一顧客が複数のモール２００でそれぞれ購入したような場合においても、ネットショップがそのことを探知して適切な対応を取ることができるようになる。
【００７３】
＜実施例４：受注情報の更新＞
実施例４は、受注情報が一旦モール２００から多店舗管理システム１０に取り込まれた後に、モール２００において受注のキャンセルや変更が生じた場合の処理に関するものである。図１５のフローチャートを用いて、多店舗管理システム１０の動作の一例について説明する。
Ｓ４０１：モール２００において顧客により商品が注文される。モール２００の受注ＤＢ２３０に、この注文に関する新しい受注情報が登録される。
Ｓ４０２：モール２００から多店舗管理装置１００への受注情報の同期処理が開始される。多店舗管理装置１００の受注情報更新部１３７が、受注ＤＢ２３０の変動を検知し、Ｓ４０１において新たに登録された受注情報を、モール２００が定める方式で取得する。
Ｓ４０３：受注情報変換部１３５が、Ｓ４０２において取得された受注情報を、多店舗管理装置１００の受注情報記憶部１３１が扱える形式に変換する。
Ｓ４０４：受注情報更新部１３７が、Ｓ４０３において変換された受注情報を、受注情報記憶部１３１に格納する。
【００７４】
モール２００において顧客により受注がキャンセルされた場合、ステップＳ４０５乃至Ｓ４０７の処理が実行される。
Ｓ４０５：モール２００において顧客により受注がキャンセルされる。モール２００の受注ＤＢ２３０から、この注文に関する受注情報が削除される。
Ｓ４０６：モール２００から多店舗管理装置１００への受注情報の同期処理が開始される。多店舗管理装置１００の受注情報更新部１３７が、受注ＤＢ２３０の変動を検知し、Ｓ４０５において削除された受注情報を特定する情報（典型的には受注ＩＤ）を、モール２００が定める方式で取得する。
Ｓ４０７：受注情報更新部１３７が、Ｓ４０６において特定された受注情報を、受注情報記憶部１３１から削除する。
【００７５】
モール２００において顧客により内容が変更された場合、ステップＳ４０８乃至Ｓ４１１の処理が実行される。
Ｓ４０８：モール２００において顧客により受注内容が変更される。例えば受注数の変更等である。モール２００の受注ＤＢ２３０において受注情報が更新される。
Ｓ４０９：モール２００から多店舗管理装置１００への受注情報の同期処理が開始される。多店舗管理装置１００の受注情報更新部１３７が、受注ＤＢ２３０の変動を検知し、Ｓ４０８において更新された受注情報を、モール２００が定める方式で取得する。
Ｓ４１０：受注情報変換部１３５が、Ｓ４０９において取得された受注情報を、多店舗管理装置１００の受注情報記憶部１３１が扱える形式に変換する。
Ｓ４１１：受注情報更新部１３７が、Ｓ４１０において変換された受注情報で、受注情報記憶部１３１の内容を更新する。
【００７６】
本実施例によれば、受注後に顧客により受注内容が変更されるような場合においても、多店舗管理装置１００は遅滞なくかつ簡便に変更を把握することができる。
【００７７】
なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、本発明はハードウェアにより実現されても良く、ＣＰＵがコンピュータプログラムを実行することにより実現されても良い。この場合、コンピュータプログラムは、様々なタイプの一時的又は非一時的なコンピュータ可読媒体に格納され、コンピュータに供給され得る。
【符号の説明】
【００７８】
１０  多店舗管理システム
１００  多店舗管理装置
１１０  商品管理部
１１１  商品情報記憶部
１１３  商品情報入力部
１１５  商品情報変換部
１１７  商品情報更新部
１２０  顧客管理部
１２１  顧客情報記憶部
１２３  顧客情報入力部
１２５  顧客情報変換部
１２７  顧客情報更新部
１２９  顧客情報統合部
１３０  受注管理部
１３１  受注情報記憶部
１３３  受注情報入力部
１３５  受注情報変換部
１３７  受注情報更新部
１３９  在庫引当部
１４０  入金管理部
１４１  入金情報記憶部
１４３  入金情報入力部
１４５  入金情報変換部
１４７  入金情報更新部
１４９  消込部
１５０  配送管理部
１５１  配送情報記憶部
１５３  配送情報入力部
１５５  配送情報変換部
１５７  配送情報更新部
１５９  出荷処理部
２００  モール
２１０  商品ＤＢ
２２０  顧客ＤＢ
２３０  受注ＤＢ
２４０  入金ＤＢ
２５０  配送ＤＢ
３００  金融機関
４００  ネットワーク
【図１】
2019101827.tif 000003
【図２】
2019101827.tif 000004
【図３】
2019101827.tif 000005
【図４】
2019101827.tif 000006
【図５】
2019101827.tif 000007
【図６】
2019101827.tif 000008
【図７】
2019101827.tif 000009
【図８】
2019101827.tif 000010
【図９】
2019101827.tif 000011
【図１０】
2019101827.tif 000012
【図１１】
2019101827.tif 000013
【図１２】
2019101827.tif 000014
【図１３】
2019101827.tif 000015
【図１４】
2019101827.tif 000016
【図１５】
2019101827.tif 000017