(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2023-11-10
(45)【発行日】2023-11-20
(54)【発明の名称】市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法
(51)【国際特許分類】
G06Q 30/0601 20230101AFI20231113BHJP
【FI】
G06Q30/0601 312
(21)【出願番号】P 2023553515
(86)(22)【出願日】2022-03-22
(86)【国際出願番号】 JP2022013325
【審査請求日】2023-09-06
【早期審査対象出願】
(73)【特許権者】
【識別番号】522334966
【氏名又は名称】株式会社藤海産
(74)【代理人】
【識別番号】100166279
【氏名又は名称】前渋 正治
(72)【発明者】
【氏名】藤原 邦仁
【審査官】牧 裕子
(56)【参考文献】
【文献】国際公開第2014/020711(WO,A1)
【文献】特開2021-096569(JP,A)
【文献】特開2009-245160(JP,A)
【文献】特開2020-170324(JP,A)
【文献】特開2012-178147(JP,A)
【文献】特表2020-525869(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00 - 99/00
(57)【特許請求の範囲】
【請求項1】
市場における商品の取引に関する情報を管理する市場取引管理システムであって、
商品の取引に関する情報を記憶する取引情報記憶部と、
前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部と、
前記商品の仕入れ量とその商品の販売量とを表示する取引量表示画面を表示するための情報を生成する取引量表示画面生成部とを含み、
前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶しており、
前記取引量表示画面生成部は、
前記取引量表示画面を表示するための情報の生成に際して、ユーザを識別するユーザ識別子を取得し、
前記取引情報記憶部に記憶されている情報のうち、取得した前記ユーザ識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出することを特徴とする市場取引管理システム。
【請求項2】
抽出された前記仕入れ量および前記販売量の情報に基づき、商品の仕入れ量に対する販売量の割合である歩留まり率を算出する歩留まり率算出部を含むことを特徴とする請求項1に記載の市場取引管理システム。
【請求項3】
算出された前記歩留まり率を、前記取引内容に含まれる商品を示す情報ごとに集計して平均値を記憶する平均歩留まり率記憶部を含むことを特徴とする請求項2に記載の市場取引管理システム。
【請求項4】
前記取引量表示画面生成部は、
算出された前記歩留まり率と、前記歩留まり率の算出対象である商品に関して前記平均歩留まり率記憶部に記憶されている前記歩留まり率の平均値とを比較表示するように前記取引量表示画面を表示するための情報を生成することを特徴とする請求項3に記載の市場取引管理システム。
【請求項5】
市場における商品の取引に関する情報を管理する市場取引管理システムであって、
商品の取引に関する情報を記憶する取引情報記憶部と、
前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部とを含み、
前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶しており、
前記入力画面情報提供部は、
前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から商品を示す情報を抽出し、
抽出した前記商品を示す情報が、前記情報入力画面において取引の対象とする商品の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする市場取引管理システム。
【請求項6】
前記入力画面情報提供部は、
前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容において販売を終了したことを示す識別子が付されている情報を抽出対象から除外することを特徴とする請求項5に記載の市場取引管理システム。
【請求項7】
前記入力画面情報提供部は、
前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出し、
前記仕入れ量と前記販売量との比較結果に基づいて抽出対象から除外することを特徴とする請求項5に記載の市場取引管理システム。
【請求項8】
市場における商品の取引に関する情報を管理する市場取引管理システムであって、
商品の取引に関する情報を記憶する取引情報記憶部と、
前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部と、
前記市場に属する店舗に利用者が入店したことを認識する入店認識部と、
前記入店認識部による認識結果として、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子とを関連付けて記憶する入店管理情報記憶部とを含み、
前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶しており、
前記入力画面情報提供部は、
前記入店管理情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記店舗識別子に関連付けられている前記入店者識別子を抽出し、
抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする市場取引管理システム。
【請求項9】
前記入店管理情報記憶部は、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子に加えて、日時を関連付けて記憶し、
前記入力画面情報提供部は、
抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢として前記日時の降順でソートされてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする請求項8に記載の市場取引管理システム。
【請求項10】
市場における商品の取引に関する情報を管理する市場取引管理システムであって、
商品の取引に関する情報を記憶する取引情報記憶部と、
前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部と、
商品を売る側において仕入れの確定していない商品について、商品を買う側から商品の販売希望を受け付ける注文受け付け処理部とを含み、
前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶しており、
前記取引情報記憶処理部は、
前記販売希望に基づき、前記親取引識別子が空欄の状態で前記取引情報記憶部に新たに取引の情報を注文情報として記憶させ、
前記注文情報に対する在庫の引き当てとして、前記取引情報記憶部に記憶されている情報のうち前記注文情報に対応する情報が指定された場合に、指定された前記取引情報記憶部に記憶されている情報を識別する識別子を、前記注文情報における親取引識別子として記録することを特徴とする市場取引管理システム。
【請求項11】
市場における商品の取引に関する情報を管理する市場取引管理プログラムであって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供処理と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理と、
前記商品の仕入れ量とその商品の販売量とを表示する取引量表示画面を表示するための情報を生成する取引量表示画面生成処理とを電子機器に実行させるものであり、
前記取引情報記憶処理は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて前記取引情報記憶部に記憶させる処理であり、
前記取引量表示画面生成処理は、
前記取引量表示画面を表示するための情報の生成に際して、ユーザを識別するユーザ識別子を取得し、
前記取引情報記憶部に記憶されている情報のうち、取得した前記ユーザ識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出する処理であることを特徴とする市場取引管理プログラム。
【請求項12】
市場における商品の取引に関する情報を管理する市場取引管理プログラムであって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供処理と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理とを電子機器に実行させるものであり、
前記取引情報記憶処理は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて前記取引情報記憶部に記憶させる処理であり、
前記入力画面情報提供処理は、
前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から商品を示す情報を抽出し、
抽出した前記商品を示す情報が、前記情報入力画面において取引の対象とする商品の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成する処理であることを特徴とする市場取引管理プログラム。
【請求項13】
市場における商品の取引に関する情報を管理する市場取引管理プログラムであって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供処理と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理と、
前記市場に属する店舗に利用者が入店したことを認識する入店認識処理と、
前記入店認識
処理による認識結果として、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子とを関連付けて入店管理情報記憶部に記憶させる入店管理情報記憶処理とを電子機器に実行させるものであり、
前記取引情報記憶処理は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて前記取引情報記憶部に記憶させる処理であり、
前記入力画面情報提供処理は、
前記入店管理情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記店舗識別子に関連付けられている前記入店者識別子を抽出し、
抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成する処理であることを特徴とする市場取引管理プログラム
【請求項14】
市場における商品の取引に関する情報を管理する市場取引管理プログラムであって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供処理と、
前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理と、
商品を売る側において仕入れの確定していない商品について、商品を買う側から商品の販売希望を受け付ける注文受け付け処理とを電子機器に実行させるものであり、
前記取引情報記憶処理は、
それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて前記取引情報記憶部に記憶させ、
前記販売希望に基づき、前記親取引識別子が空欄の状態で前記取引情報記憶部に新たに取引の情報を注文情報として記憶させ、
前記注文情報に対する在庫の引き当てとして、前記取引情報記憶部に記憶されている情報のうち前記注文情報に対応する情報が指定された場合に、指定された前記取引情報記憶部に記憶されている情報を識別する識別子を、前記注文情報における親取引識別子として記録する処理であることを特徴とする市場取引管理プログラム。
【請求項15】
市場における商品の取引に関する情報を
情報処理システムによって管理する市場取引管理方法であって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供し
、
前記情報入力画面において入力された情報に基づき、
前記情報処理システムが前記取引情報記憶部に新たに取引の情報を記憶させ、その際に、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶させ、
前記情報処理システムが前記商品の仕入れ量とその商品の販売量とを表示する取引量表示画面を表示するための情報を生成する際に、
ユーザを識別するユーザ識別子を取得し、
前記取引情報記憶部に記憶されている情報のうち、取得した前記ユーザ識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出することを特徴とする市場取引管理方法。
【請求項16】
市場における商品の取引に関する情報を
情報処理システムによって管理する市場取引管理方法であって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供し、
前記情報入力画面において入力された情報に基づき、
前記情報処理システムが前記取引情報記憶部に新たに取引の情報を記憶させ、その際に、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶させ、
前記
情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供する際に、
前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から商品を示す情報を抽出し、
抽出した前記商品を示す情報が、前記情報入力画面において取引の対象とする商品の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする市場取引管理方法。
【請求項17】
市場における商品の取引に関する情報を
情報処理システムによって管理する市場取引管理方法であって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供し
、
前記情報入力画面において入力された情報に基づき、
前記情報処理システムが前記取引情報記憶部に新たに取引の情報を記憶させ、その際に、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶させ、
前記情報処理システムが前記市場に属する店舗に利用者が入店したことを認識し、その認識結果として、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子とを関連付けて、入店管理情報記憶部に記憶させ、
前記情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供する際、前記入店管理情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記店舗識別子に関連付けられている前記入店者識別子を抽出し、抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする市場取引管理方法。
【請求項18】
市場における商品の取引に関する情報を
情報処理システムによって管理する市場取引管理方法であって、
商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を電子機器に表示するための情報を
前記情報処理システムが提供し
、
前記情報入力画面において入力された情報に基づき、
前記情報処理システムが前記取引情報記憶部に新たに取引の情報を記憶させ、その際に、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶させ、
商品を売る側において仕入れの確定していない商品について、商品を買う側から商品の販売希望を
前記情報処理システムが受け付けた場合、前記親取引識別子が空欄の状態で前記取引情報記憶部に新たに取引の情報を注文情報として記憶させ、
前記注文情報に対する在庫の引き当てとして、前記取引情報記憶部に記憶されている情報のうち前記注文情報に対応する情報が指定された場合に、
前記情報処理システムが指定された前記取引情報記憶部に記憶されている情報を識別する識別子を、前記注文情報における親取引識別子として記録することを特徴とする市場取引管理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法に関する。
【背景技術】
【0002】
生鮮卸売市場においては、日々膨大な量の取引が行われるが、その取引の管理は未だアナログな手作業で行われているのが実情である。生鮮卸売市場における取引を自動化する方法として、卸売業者に入庫した商品を情報管理し、仲買、仲卸等のそれぞれの段階でそれぞれの商品の所有者の情報を更新し、出庫により在庫を更新するシステムが提案されている(例えば、特許文献1参照)。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
特許文献1に記載のシステムによれば、市場に入荷した商品についての所有者が書き換えられることにより、取引の結果としてそれぞれの商品を所有することとなった者を把握することが可能となる。しかしながら、所有者が書き換えられる結果、取引の過程を事後的に把握することはできない。
【0005】
本発明は、上記実情を考慮してなされたものであり、商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握することを目的とする。
【課題を解決するための手段】
【0006】
上記課題を解決するために、本発明の一態様は、市場における商品の取引に関する情報を管理する市場取引管理システムであって、商品の取引に関する情報を記憶する取引情報記憶部と、前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部とを含み、前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする。
【発明の効果】
【0007】
本発明によれば、商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握することができる。
【図面の簡単な説明】
【0008】
【
図1】本発明の実施形態に係るシステムの全体構成を示す図である。
【
図2】本発明の実施形態に係るシステムに含まれる情報機器のハードウェア構成を示す図である。
【
図3】本発明の実施形態に係るサービスサーバの機能構成を示すブロック図である。
【
図4】本発明の実施形態に係るユーザ情報および企業情報の例を示す図である。
【
図5】本発明の実施形態に係る取引情報の例を示す図である。
【
図6】本発明の実施形態に係るユーザ端末の機能構成を示すブロック図である。
【
図7】本発明の実施形態に係るシステムにおける情報登録動作を示すシーケンス図である、
【
図8】本発明の実施形態に係る情報登録画面の例を示す図である。
【
図9】本発明の実施形態にかかる商品名の選択肢リストを生成する動作を示すフローチャートである。
【
図10】本発明の実施形態にかかる商品名の選択肢リストを生成する際の情報の抽出態様を示す図である。
【
図11】本発明の実施形態に係る情報登録画面における商品名の選択肢の態様を示す図である。
【
図12】本発明の実施形態に係る取引情報が新たに登録される際の親取引との情報の関係を示す図である。
【
図13】本発明の実施形態に係る複数単位のレコードが登録される場合の登録情報の例を示す図である。
【
図14】本発明の実施形態に係る売りデータ一覧表示画面の例を示す図である。
【
図15】本発明の実施形態に係る買いデータ一覧表示画面の例を示す図である。
【
図16】本発明の実施形態に係る取引一覧表示画面の例を示す図である。
【
図17】本発明の実施形態に係る取引一覧表示画面の生成動作を示すフローチャートである。
【
図18】本発明の実施形態に係る買いデータ一覧表示画面の例を示す図である。
【
図19】本発明の実施形態に係る取引一覧表示画面の例を示す図である。
【
図20】本発明の実施形態に係る買い額事後指定画面の例を示す図である。
【
図21】本発明の実施形態に係る取引一覧表示画面の例を示す図である。
【
図22】本発明の実施形態に係る取引一覧表示画面における買い量および売り量の表示形式のルールを示す図である。
【
図23】本発明の実施形態に係る平均歩留まり率情報の例を示す図である。
【
図24】本発明の実施形態に係る歩留まり率時系列表示画面の例を示す図である。
【
図25】本発明の実施形態に係る商品リストの生成動作を示すフローチャートである。
【
図26】本発明の実施形態に係る入店管理機能の概観を示す図である。
【
図27】本発明の実施形態に係るユーザ端末の機能構成を示すブロック図である。
【
図28】本発明の実施形態に係るユーザ情報および企業情報の例を示す図である。
【
図29】本発明の実施形態に係る入店情報の例を示す図である。
【
図30】本発明の実施形態に係る入店管理動作を示すシーケンス図である。
【
図31】本発明の実施形態に係る買い手欄の選択肢リストの生成動作を示すフローチャートである。
【
図32】本発明の実施形態に係る買い手欄の選択肢リスト生成のためのクエリの実行結果を示す図である。
【
図33】本発明の実施形態に係る買い手欄の選択肢の表示例を示す図である。
【
図34】本発明の実施形態に係る取引情報の例を示す図である。
【
図35】本発明の実施形態に係る本発明の実施形態に係る注文処理の動作を示すシーケンス図である。
【
図36】本発明の実施形態に係る注文データ登録画面の例を示す図である。
【
図37】本発明の実施形態に係る注文データ一覧表示画面の例を示す図である。
【
図38】本発明の実施形態に係る注文情報である取引情報が登録される際の注文元の取引情報との情報の関係を示す図である。
【
図39】本発明の実施形態に係る在庫引当画面の例を示す図である。
【
図40】本発明の実施形態に係る在庫引当情報の例を示す図である。
【発明を実施するための形態】
【0009】
実施の形態1.
以下、図面を参照して、本発明の実施形態を説明する。本実施形態では、生鮮食品の取引市場にて商品の売買情報を管理する市場取引管理システムについて説明する。そのような、上流側から下流側に複数の業者間を商品が転々と流通していく取引形態を管理するシステムにおいて、取引の流れを事後的に把握可能な機能を提供することが本実施形態に係る要旨である。
【0010】
図1は、本実施形態に係るシステムの全体構成を示す図である。
図1に示すように、本実施形態に係る市場売買管理システムは、システムにおいてサービスを提供するサービスサーバ1と、システムを利用するそれぞれのユーザが利用する複数のユーザ端末2a~2d(以降、総じて「ユーザ端末2」とする)とを含む。
【0011】
図1に示すように、本システムを利用するユーザは、卸売市場において商品を売買する業者であり、
図1においては取引の上流側から下流側に向かって生産・仕入れ業者、大卸業者、仲買業者および飲食店や小売店等である。この形態は卸売市場における代表的な形態であり、
図1に示すそれぞれの業者の間に輸送業者が入る場合や、それぞれの業者が複数の階層に別れている場合などもある。サービスサーバ1およびユーザ端末2a~2dはインターネット等のネットワークAに接続されており、互いに通信可能である。
【0012】
サービスサーバ1は、本システムの運営主体が管理するサーバであり、ユーザ端末2から本システムを利用する際のGUI(Graphical User Interface)の提供機能や、各ユーザ端末2において入力される売買の情報を受け付けて記録する機能を提供する。ユーザ端末2は、スマートフォン、タブレット、ノートPC、デスクトップPC等の情報処理端末であり、本システムを利用するユーザが使用する電子機器である。
【0013】
図2は、本実施形態に係るシステムに含まれるサービスサーバ1、ユーザ端末2等の情報機器のハードウェア構成を示す図である。本実施形態に係るシステムは一般的な情報処理機器のハードウェア構成によって実現可能であり、
図2に示すように、CPU(Central Processing Unit)10、RAM(Random Access Memory)20、ROM(Read Only Memory)30、HDD(Hard Disk Drive)40およびI/F50がバス80を介して接続されている。また、I/F50にはLCD(Liquid Crystal Display)60および操作部70が接続されている。
【0014】
CPU10は演算手段であり、情報機器全体の動作を制御する。RAM20は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、CPU10が情報を処理する際の作業領域として用いられる。ROM30は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。HDD40は、情報の読み書きが可能な不揮発性の記憶媒体であり、OS(Operating System)や各種の制御プログラム、アプリケーション・プログラム等が格納される。
【0015】
I/F50は、バス80と各種のハードウェアやネットワーク等を接続し制御する。LCD60は視覚的ユーザインタフェースである。操作部70は、キーボード、マウス、各種のハードボタン、タッチパネル等、ユーザが情報機器に情報を入力するためのユーザインタフェースである。尚、サービスサーバ1は、サーバとして運用されるため、LCD60や操作部70等のユーザインタフェースは省略可能である。
【0016】
このようなハードウェア構成において、ROM30やHDD40若しくは図示しない他の記憶媒体に格納されたプログラムがRAM20に読み出され、CPU10がそれらのプログラムに従って演算を行うことによりソフトウェアの機能が構成される。このようにして構成されたソフトウェアの機能と、ハードウェアとの組み合わせによって、本実施形態に係る市場売買管理システムを構成する各機器の機能を実現する機能ブロックが構成される。
【0017】
次に、本実施形態に係るサービスサーバ1の機能構成について
図3を参照して説明する。
図3に示すように、本実施形態に係るサービスサーバ1は、要求処理部101、業者情報処理部102、業者情報記憶部103,取引情報処理部104および取引情報記憶部105を含む。
図2で説明したハードウェア構成を前提として、
図3に示すような機能構成を実現するためのソフトウェア・プログラムが、市場取引管理プログラムとして用いられる。
【0018】
要求処理部101は、ユーザ端末2において動作するアプリケーションの要求に応じて様々な処理を行い要求に応答する。業者情報処理部102は、要求処理部101の制御に従って業者情報記憶部103への情報の登録や情報の検索、抽出等の処理を行う。業者情報記憶部103は、本システムのユーザである業者企業の情報やその担当者の情報を記憶している。
【0019】
取引情報処理部104は、要求処理部101の制御に従って取引情報記憶部105への情報の登録や情報の検索、抽出等の処理を行う。取引情報記憶部105は、本システムのユーザによって行われる取引の内容や取引の主体に加えて、それぞれの取引の関係性を示す情報を記憶している。
【0020】
図4(a)、(b)は、業者情報記憶部103が記憶している情報の1レコード分の内容を示す図であり、
図4(a)がユーザ情報、
図4(b)が企業情報をそれぞれ示す。
図4(a)に示すように本実施形態にかかるユーザ情報は"ユーザID"、"パスワード"、"担当者名"、"所属企業ID"、"連絡先"、"受領場所"の情報を含む。"ユーザID"は、本システムを利用するユーザを識別するユーザ識別子である。"パスワード"は、そのユーザが本シスステムにログインするための認証情報である。
【0021】
"担当者名"は、本システムを利用するユーザの名称を示す文字情報である。"所属企業ID"は、そのユーザが所属する企業を示す識別子であるが、個人としてシステムを利用するユーザの場合には空欄となる。"連絡先"は、住所、電話番号、メールアドレス等、本システムのユーザの連絡先である。"受領場所"は、そのユーザが市場で物を買った場合に、その物を市場内で届ける先を示す情報であり、例えばそのユーザが市場において割り当てられている荷物の集荷場所や運搬車の駐車場所である。
【0022】
また、
図4(b)に示すように、本実施形態に係る企業情報は、"企業ID"、"パスワード"、"企業名"、"連絡先"の情報を含む。"企業ID"は、本システムを利用するユーザを識別する識別子であり、
図4(a)の"所属企業ID"に対応する。"パスワード"は、そのレコードの"企業ID"を用いて本システムにログインするための認証情報である。"企業名"は、そのレコードの企業の名称、屋号を示す文字情報である。"連絡先"は、住所、電話番号、メールアドレス等、その企業の連絡先の情報である。なお、企業情報もユーザ情報と同様に"受領場所"が指定されても良い。
【0023】
図5は、取引情報記憶部105が記憶している取引情報の1レコード分の内容を示す図である。
図5に示すように、本実施形態にかかる取引情報記憶部は、"取引ID"、"買い手ID"、"売り手ID"、"担当者名"、"商品コード"、"商品名"、"規格"、"産地"、"個数"、"重量"、"単価"、"消費税率"、"取引日時"、"親取引ID"、"受領確認"、"備考"および"販売終了"の情報を含む。
【0024】
"取引ID"は、それぞれの取引情報のレコードを識別する取引識別子である。"買い手ID"は、その取引において商品を販売した側の業者を識別する買い手識別子であり、
図4の"ユーザID"に対応する。"売り手ID"は、その取引において商品を購入した側の業者を識別する売り手識別子であり、
図4の"ユーザID"に対応する。
【0025】
"担当者名"は、その取引において商品を購入した側の業者の担当者名である。"商品コード"は、その取引において売買された商品に付与されるコード番号であり、同種で規格の異なる魚の識別などに用いられる。"商品名"は、その取引において売買された商品の名称である。
【0026】
"規格"は、その取引において売買された商品の規格を示す情報であり、例えばイワシのような魚であれば「**kg/**尾」というように所定の尾数あたりの重量で示される。その他、マグロであれば、「1番」~「4番」といった部位を示す番号であり、海老であれば「16-20」「21-25」「26-30」といったように所定の重量あたりの尾数で示される。
【0027】
"産地"は、その取引において売買された商品の産地を示す情報である。"個数"はその取引において売買された商品の個数(尾数)を示す情報である。"重量"は、その取引において売買された商品の重量を示す情報である。"単価"は、その取引において売買された商品の所定の重量あたりの価格を示す情報である。"消費税率"は、その取引において適用される消費税の税率を示す情報である。"商品名"、"規格"、"産地"、"個数"、"重量"、"単価"等の情報が取引内容の情報として用いられる。
【0028】
"取引日時"は、その取引が行われた日時を示す情報である。"親取引ID"は、その取引において売買された商品の仕入れ取引、即ち親取引を示す親取引識別子であり、"取引ID"に対応する。"受領確認"は、その取引において売買された商品が買い手の受領場所において荷受け確認されたか否かを示すチェック情報である。"備考"は、取引において自由に入力される文字情報である。"販売終了"は、その取引によって仕入れられた商品の販売が終了したことを示すチェック情報である。
【0029】
次に、
図6を参照して本実施形態にかかるユーザ端末2の機能構成について説明する。
図6に示すように、本実施形態にかかるユーザ端末2においては、市場販売管理アプリ200が動作することによって本システムに対応する機能が提供される。
【0030】
市場販売管理アプリ200は、
図2において説明したように、市場販売管理アプリ200を構成するためのソフトウェア・プログラムがRAM20に読み出され、CPU10がそれらのプログラムに従って演算を行うことにより構成される。本実施形態にかかる市場販売管理アプリ200はウェブアプリケーションである。すなわち、ユーザ端末2にインストールされているウェブブラウザを介してユーザ端末2がサービスサーバ1にアクセスすることによりウェブサイトの情報として市場販売管理アプリ200を構成するためのプログラムがユーザ端末2にダウンロードされ、そのプログラムに従ってユーザ端末2において市場販売管理アプリ200が構成される。
【0031】
図6に示すように、市場販売管理アプリ200は操作受付部201、表示処理部202および情報通信部203を含む。操作受付部201は、ユーザ端末2の操作部70に対するユーザの操作をI/F50を介して受け付ける。表示処理部202は、操作受付部201が取得したユーザの操作内容や、サービスサーバ1から取得した情報に基づいて市場販売管理アプリ200のGUIの表示を制御する。情報通信部203は、市場販売管理アプリ200の動作状態に応じてサービスサーバ1との間で情報をやり取りする。
【0032】
次に、本実施形態にかかるシステムにおいて、サービスサーバ1の取引情報記憶部105に新たに取引情報が登録される動作について
図7を参照して説明する。
図7は、本システムにおいて新たに取引情報が登録される動作を示すシーケンス図である。
【0033】
図7に示すように、まずは売り手側のユーザ端末2aがウェブブラウザの機能を介してサービスサーバ1にアクセスすることにより、市場販売管理アプリ200のGUIがLCD60に表示される(S701)。S701においては、"ユーザID"若しくは"連絡先"の情報に含まれるメールアドレス等のユーザの識別子と、"パスワード"による認証によりログイン処理が行われる。
【0034】
そして、ユーザによる操作部70に対する操作内容を操作受付部201が受け付け、それに応じて情報通信部203がサービスサーバ1から情報を取得し、その情報に基づいて表示処理部202が市場販売管理アプリ200のGUIを制御することにより、取引情報の登録画面が表示される。
【0035】
図8(a)、(b)は、市場販売管理アプリ200のGUIのうち、売りデータを登録するための画面(以降、「売りデータ登録画面」とする)を示す図である。
図8(a)に示すように、本システムにおける売りデータ登録画面は、
図5において説明した各情報を入力するための入力欄を含む。また、本システムにおける売りデータ登録画面には、それぞれの入力欄における情報の入力を補助するための機能が含まれる。
図8(a)、(b)に示す画面が、取引情報記憶部105に記憶させるための情報の入力を受け付ける情報入力画面として用いられる。
【0036】
例えば、
図8(a)において"企業"と表示されている入力欄は、取引において商品を購入する側の業者を指定する入力欄である。この入力欄は自由入力の他、表示される選択肢から選択することも可能であり、サービスサーバ1の業者情報記憶部103に記憶されているレコードの"企業名"が選択肢として表示される。それぞれの企業名の選択肢には、
図4に示す"ユーザID"が関連付けられており、企業名が選択されると自動的にそれに関連付けられた"ユーザID"も入力対象の情報として選択される。
【0037】
また、
図8(a)において"商品名"と表示されている入力欄は、取引において売買される商品を指定する入力欄である。この入力欄も選択式であり、売り手側が既に購入している商品の商品名が選択肢として表示される。この商品名の選択肢の表示機能について説明する。
【0038】
図8(a)の"商品名"の選択肢は、取引情報記憶部105に記憶されている取引情報の"商品名"に基づいて生成されたリストが用いられる。このリストは、
図7のS701における画面情報の生成処理において生成される。
図9を参照して、
図7のS701における画面情報の生成処理の詳細について説明する。
【0039】
図9に示すように、まずはサービスサーバ1の要求処理部101が、画面表示を要求するユーザ端末2からユーザIDおよびパスワードを含む認証要求を受信する(S901)。すると業者情報処理部102は、受信されたユーザIDおよびパスワードに基づいて業者情報記憶部103を参照し、ユーザIDおよびパスワードの一致を確認して認証処理を行う(S902)。
【0040】
S902の結果、指定されたユーザIDが業者情報記憶部103に存在しない、若しくは指定されたユーザIDに関連付けられたパスワードが指定されたパスワードと一致しない等、認証に失敗した場合(S902/NO)、要求処理部101は認証要求を行ったユーザ端末2に対してエラーを通知して(S906)処理を終了する。
【0041】
他方、認証が正常に行われた場合(S902/YES)、取引情報処理部104は、要求処理部101の制御に従い、認証されたユーザIDが"買い手ID"であるレコードを取引情報記憶部105から抽出する(S903)。
図10は、取引情報記憶部105において"買い手ID"をキーとして情報を抽出する処理を概念的に示す図である。
図10の例においては、"商品コード"、"商品名"、"規格"がそれぞれ「***、イワシ、**kg/**尾」、「***、マグロ、1番」、「***、海老、16-20」であるレコードが抽出されている。
【0042】
このようにレコードが抽出されると、要求処理部101は、抽出されたレコードのうち"取引ID"、"商品コード"、"商品名"、"産地"、"規格"の情報を抽出し、
図8(a)に示す"商品名"の選択肢のためのリストとして生成する(S904)。そして、要求処理部101は、ユーザ端末2における市場販売管理アプリ200のGUIの情報およびS904において生成したリストの情報を、認証要求に対する応答としてユーザ端末2に送信し(S905)、処理を終了する。即ち、ここでは要求処理部101が、
図8(a)、(b)に示す画面を表示するための情報を提供する入力画面情報提供部として機能する。
【0043】
このような処理により、
図8(a)に示す"商品名"の入力欄の選択肢の情報が生成され、ユーザ端末2において表示されたGUIにおいては、ログインしたユーザが既に仕入れている商品が選択肢として表示される事となる。
図11は、
図8(a)に示す"商品名"の入力欄の選択肢の表示態様を示す図である。
図11に示すように、
図9の処理により生成されたリストが選択肢として表示される。
【0044】
図9においてはログイン処理および"商品名"の入力欄の選択肢リストの生成処理を一連の処理として説明したが、S902とS903との間は必ずしも連続した処理ではなく、タイムラグがあっても良い。その場合、ユーザ端末2においては、既にログイン操作が行われた状態で、売りデータ登録画面を表示するための操作が行われ、ユーザ端末2がサービスサーバ1に対して画面情報を要求する。その際にログイン済みのユーザIDが通知され、サービスサーバ1においてS903以降の処理が実行される。
【0045】
このような機能により、商品を売るユーザは、既に仕入れている商品の中から販売対象の商品を容易に選択して入力することができる。尚、
図10に示すように、選択肢リストの生成に際しては、"取引ID"の情報も抽出され、リストの情報として含まれているが、
図11に示すようにユーザに提示する情報には含まれない。
【0046】
このような選択肢に対してユーザが選択操作を行うと操作受付部201がその操作内容を受け付け、表示処理部202の処理により、選択された情報が
図8(a)に示す"商品名"、"産地"、"規格"に自動的に入力される。なお、
図8(a)および
図11の例においては、"商品名"、"産地"、"規格"の情報を"商品名"の入力欄で一括して選択する態様を例として説明したが、それぞれの入力欄で個別に選択する態様も可能であり、上記と同様の処理により選択肢を生成する事ができる。
【0047】
図8(a)の画面の説明に戻る。
図8(a)に示すように、売りデータ登録画面には「単位」を「追加」若しくは「削除」するためのボタンが表示されている。「追加」と表示されたボタンをタップやクリック等で操作すると、
図8(b)に示すように"個数"および"重量"の入力欄が追加され、複数の"個数"および"重量"を入力することが可能となる。
【0048】
この単位の追加機能は卸売市場の現場における実情に即したものである。例えば、「イワシ」、「サンマ」等の商品が箱詰めにされて箱単位で売られている場合において、それぞれの箱の重量が異なる場合がある。そのような場合において複数の箱を一度に取引する場合に、
図8(a)の画面では複数の箱の重量を計算して入力する必要があるが、
図8(b)の画面とすることにより、複数の箱の情報をそれぞれ個別に入力することができる。
【0049】
図7のシステムの動作の説明に戻る。このようにして
図8(a)に示す画面で情報が入力され、「起票」ボタンに対してタップ、クリック等の操作が行われると、情報通信部203がサービスサーバ1に対して取引情報の登録要求と供に画面上で入力された情報を送信する(S702)。なお、
図8(a)、(b)に示す売りデータ登録画面における入力項目は一例であり、"備考"等、
図8(a)、(b)に示す以外の入力欄を設けても良い。
【0050】
S702において送信される情報には、上述した通り
図8(a)に示す画面において入力された情報が含まれるが、"商品名"の欄の選択により含まれる情報は
図11に示す"商品コード"、"商品名"の他、
図10に示すように"取引ID"の情報も含まれる。また、S701のログイン処理において認証されたユーザID、すなわちログイン済ユーザIDも含まれる。
【0051】
取引情報の登録要求を受けたサービスサーバ1においては、要求処理部101が情報を受信し、取引情報処理部104が要求処理部101の制御に従って取引情報記憶部105に情報を登録し、要求処理部101がユーザ端末2に対して応答処理を行う(S703)。S703の情報登録処理においては、
図8(a)に示す画面において入力されたそれぞれの情報の他、ログイン認証されたユーザIDが"売り手ID"として登録される。即ち、ここでは取引情報処理部104が、取引情報記憶処理部として機能する。
【0052】
また、企業の選択肢において選択された企業名に関連付けられたユーザIDが、"買い手ID"として登録される。更に、商品名の選択において選択されたリストに含まれる取引IDが、"親取引ID"として登録される。そして、情報登録が要求された時の日時が"取引日時"として登録される。
図12は、S703の処理において新たに登録されるレコードと、親取引に該当するレコードとの関係を示す図である。
【0053】
図12に示すように、親取引のレコードにおける"取引ID"が、新規に登録されるレコードの"親取引ID"として登録される。また、親取引のレコードにおける"買い手ID"は、新規に登録されるレコードの"売り手ID"と共通する。その他、"商品コード"、"商品名"、"産地"も同一となる。"規格"も基本的には同一となるが、仕入れたものを切り分けて販売する場合等、仕入れ時と販売時で規格の情報が異なる場合もある。
【0054】
なお、
図8(b)において説明したように、一度の売りデータの登録において複数の"個数"、"重量"を登録した場合、それぞれの情報は
図13に示すように個別のレコードとして登録されるが、"取引ID"には同一のIDが付される。この同一の取引IDが付される理由については後述する。
【0055】
S703においてユーザ端末2に送信される応答の情報には、取引情報記憶部105に情報が登録された後に、そのユーザIDが"売り手ID"であり、かつ"取引日時"のうち日付の情報が当日であるレコードを抽出した結果のリストが含まれる。その結果、応答を受信したユーザ端末2においては、情報登録が完了された事を示す処理結果の画面として、当日に登録された売りデータの一覧を示す画面が表示される(S704)。
【0056】
図14は、S704の処理において表示される売りデータの一覧画面の例を示す図である。
図14に示すように、売りデータの一覧画面においては、それぞれのレコードに含まれる情報のうち、"商品"、"産地"、"個数"、"重量"、"単価"、"場所"、"配送状況"の情報が、それぞれの買い手IDに対応する企業名ごとにまとめて表示される。なお、"場所"の情報は、
図4において説明した"受領場所"の情報である。
【0057】
このような処理により本システムにおける新規データの登録処理が完了する。これにより、商品を買った側、仕入れた側のユーザは、システムにアクセスして買いデータの一覧画面を表示することにより、取引の結果を確認することができる(S705)。
図15は、S705において表示される買いデータ一覧画面の例を示す図である。
【0058】
ユーザ端末2からサービスサーバ1に対して買いデータ一覧画面の表示が要求されると、サービスサーバ1は、取引情報記憶部105に記憶されたデータのうち、要求と供に通知されたユーザIDが"買い手ID"であり、かつ"取引日時"のうち日付の情報が当日であるレコードを抽出したリストをユーザ端末2に送信する。その結果、サービスサーバ1からリストを受信したユーザ端末2においては、当日に登録された買いデータの一覧を示す画面が
図14のように表示される。
【0059】
図14、
図15に示す買いデータ一覧表示画面において、"配送状況"の項目はユーザによってチェックを追加することが可能なGUIとなっている。例えば、実際の市場において仕入れを行う側のユーザは、様々な場所、店舗で必要な商品を購入する。そして、定められた集荷場所にそれぞれの店舗から商品を届けてもらって車などに積み込む。その際、
図14、
図15に示す買いデータ一覧表示画面において"配送状況"の項目を確認することで、販売した商品をすべて届け終えたか、購入した商品がすべて届いているかを確認することができる。
【0060】
ユーザが
図15に示すような画面において"配送状況"の欄にチェックを付けるための操作を行うと、ユーザ端末2からサービスサーバ1に対して、"配送状況"にチェックが付されたことを示す識別子とともに、対象となるレコードを示す"取引ID"が通知される。その通知を受けたサービスサーバ1においては、要求処理部101から取引情報処理部104に情報が受け渡され、取引情報処理部104が、通知された"取引ID"のレコードを抽出して"配送状況"のチェック情報を更新する。
【0061】
なお、"配送状況"の項目については、商品を売った側が
図14において説明した売りデータ一覧表示画面において操作してチェックを付ける態様でも良いし、商品を売った側、買った側の双方がチェックを付ける態様でも良い。これにより、売った側が商品を届けたか否か、買った側が商品を受領したか否かをそれぞれ確認することが可能となる。
【0062】
なお、
図14、
図15において"配送状況"の項目はチェックデータとして示されているが、上記の通り買い手、売り手の双方がチェックを付けるデータとする場合、例えば2桁の2進数のデータとし、買い手がチェックした状態を「10」、売り手がチェックした状態を「01」、双方がチェックした状態を「11」とすることにより一項目として実現可能である。
【0063】
このように、本システムにおいては市場において成立した取引がすべて記憶されていくこととなる。その中で特徴となるのが"親取引ID"の存在である。生産者や漁業者から大卸業者へ、大卸業者から仲買業者へ、仲買業者から飲食店や小売店へと点々と取引されて流通していく仕組みのなかで、それぞれの取引の上流側の取引が記録されていることにより様々な機能を実現することが可能となる。
【0064】
図16は、本システムにおいて"親取引ID"を利用して可能となる画面のうち、取引一覧画面の例を示す図である。本システムにおける取引一覧画面においては、それぞれのユーザが仕入れた商品について仕入れ量と販売量とが比較して表示される。即ち、
図16に示す取引一覧画面が、取引量表示画面として用いられる。このような取引一覧表示画面を確認することにより、それぞれのユーザは仕入れた商品の売り漏れや、在庫以上の取引を誤って締結してしまうことを防ぐことができる。
【0065】
図17は、ユーザ端末2から取引一覧表示画面の要求を受けたサービスサーバ1の動作を示すフローチャートである。
図17に示す動作の前提として、要求元であるユーザのユーザ端末2からサービスサーバ1に対して、取引一覧表示画面の表示要求とともにユーザIDが通知される。
【0066】
取引一覧表示画面の表示要求およびユーザIDの通知を受けたサービスサーバ1においては、要求処理部101から取引情報処理部104に情報が受け渡され、取引情報処理部104が、通知された"ユーザID"に基づいて取引情報記憶部105から情報を抽出する(S1701)。
【0067】
S1701の処理において取引情報処理部104は、取引情報記憶部105が記憶しているデータのうち"買い手ID"が通知された"ユーザID"であり、且つ"取引日時"が当日であるデータを抽出する。S1701において抽出されるデータが、そのユーザがその日に商品を仕入れた取引のデータ、すなわち仕入れ取引データであり、S1701の処理が商品の仕入れ量を抽出する処理である。
【0068】
このようにして情報を抽出すると、取引情報処理部104は、抽出されたデータそれぞれを順番に選択し、
図15に示すような比較画面を生成するための処理(以降、「比較情報生成処理」とする)を繰り返し行う。そのため取引情報処理部104は、繰り返しを判断するための処理として、抽出されたデータのうち、比較情報生成処理の対象としてまだ選択していないデータが残っているか確認する(S1702)。
【0069】
未選択のデータがまだある場合(S1702/YES)、取引情報処理部104は、未選択データの1つを選択し、その"取引ID"を参照する(S1703)。そして、取引情報処理部104は、取引情報記憶部105が記憶しているデータのうち"親取引ID"がS1703において参照した"取引ID"であるレコードを抽出する(S1704)。S1704において抽出されるデータが、S1703において参照された"取引ID"が示す取引において仕入れられた商品を販売したデータ、すなわち販売取引データであり、S1704の処理が商品の販売量を抽出する処理である。
【0070】
選択中の仕入れ取引に対する販売取引データを抽出した取引情報処理部104は、抽出した販売取引データの"重量"、"単価"を参照し、"重量"の集計および"重量"に"単価"を乗じた販売額の集計を行う(S1705)。これにより、選択中の仕入れ商品を販売した合計量および合計の販売額が算出される。
【0071】
なお、
図8(b)および
図13において説明した態様により、S1703において参照した「取引ID」が付与されたレコードが複数ある場合、S1705において取引情報処理部104は、その複数のレコードの"重量"の集計および"重量"に"単価"を乗じた販売額の集計を行う。この集計結果が"買い額(円)"および"買い量(kg)"となる。
【0072】
そして取引情報処理部104は、選択中の仕入れ商品について
図15に示すように取引一覧表示画面に表示させる情報、すなわち"商品名""産地""買い額(円)""買い量(kg)""売り額(円)""売り量(kg)""販売終了"の情報を抽出して記憶する(S1706)。
【0073】
取引情報処理部104は、S1701の処理により抽出されたレコードがなくなるまでS1703~S1706の処理を繰り返し(S1702/YES)、未選択のレコードがなくなると(S1702/NO)、S1706の処理により記憶された情報に基づいて
図16に示す取引一覧表示画面を表示するための画面情報を生成して、要求元のユーザ端末2に対して送信し(S1707)、処理を終了する。このように、取引情報処理部104が、取引量表示画面生成部として機能する。
【0074】
このような処理により、本システムによる取引一覧表示画面の画面情報の生成処理が完了し、
図16に示すような画面がユーザ端末2において表示される。
図16に示すような表示により、仕入れ量と販売量とを客観的に確認することが可能となる。なお、"販売終了"の項目はユーザによってチェックを追加することが可能なGUIとなっている。このユーザが仕入れた商品をすべて販売し終えたと判断した場合にこの"販売終了"のチェックを更新することにより、
図9において説明した商品名リストの生成処理においてリストから除外することができる。
【0075】
上述した通りユーザ端末2において"販売終了"のチェックが操作されると、ユーザ端末2からサービスサーバ1に対して、"販売終了"のチェック状態を更新する旨の要求が対象レコードの"取引ID"(S1703において選択した取引ID)と供に通知される。この通知を受けたサービスサーバ1においては、取引情報処理部104が、通知された"取引ID"に基づいて取引情報記憶部105からレコードを抽出し、抽出したレコードの"販売終了"のチェックを更新する。
【0076】
次に、本システムの機能のうち卸売市場における特殊な取引形態に対応した機能について説明する。一般的な商品取引においては、買い手側が仕入れ対象の商品を選択して購入意思を売り手に伝え、売り手が販売に同意することで取引が成立する。これに対して卸売市場においては、取引の上流側から下流側に対して、特定の商品の販売を依頼する場合がある。そのような場合に対応した機能(以降、「販売依頼機能」とする)について説明する。
【0077】
上述したような販売依頼機能による取引においても、商品を売る側の業者が
図8(a)、(b)に示すような画面において販売対象の商品の情報を入力することは同一である。ただし、入力すべき情報のうち"単価"の情報は空欄で入力される。その結果、買いデータ一覧表示画面においては、
図17に示すように"単価"が未定として表示されると供に、図中に斜線を付して示しているように、その取引が売り手側からの販売依頼による取引であることが客観的にわかるように強調表示される。
【0078】
そのような販売依頼取引の商品について、販売を依頼されて仕入れを行った下流側の業者が取引を行うことにより、他の通常の商品と同様に
図16において説明した取引一覧表示画面に表示される。
図19は、販売依頼取引の商品が表示される場合の取引一覧表示画面の例を示す図である。
図19に示すように、販売依頼取引の商品が含まれる取引一覧表示画面において、販売依頼取引の商品は
図18と同様に強調表示される。
【0079】
図18、
図19に示すような強調表示は、ユーザ端末2の要求に応じてサービスサーバ1において取引情報処理部104が表示情報を生成する取引情報処理部104によって実現される。取引情報処理部104は買いデータ一覧表示画面や取引一覧表示画面の表示情報を生成する際、販売依頼取引に係るレコード、すなわち買い額が空欄状態のレコードについては、そのレコードが強調表示されるように表示情報を生成する。そのような表示は、例えば画面を構成するウェブソースのスタイルシートの設定により実現することが可能である。
【0080】
このような販売依頼取引については、買い側の業者と売り側の業者とが空欄となっている販売額(レコード上の"単価")を話し合い、事後的に情報を入力することにより未定状態の取引を完了させる必要がある。
図18や
図19に示す画面で強調表示された販売依頼取引のレコードをタップやクリックなどで操作することにより、
図20に示すような買い額を事後的に指定するための画面(以降、「買い額事後指定画面」とする)が表示される。
【0081】
図20に示すように、買い額時事後指定画面においては、"企業""商品""産地""買い量"等の対象の取引を示す情報と供に、"単価""合計金額""消費税率""税込金額"の入力欄が表示される。ユーザが
図20に示す画面において情報を入力した上で「決定」ボタンを操作することによりユーザ端末2の市場販売管理アプリ200における操作受付部201が操作を認識し、情報通信部203がサービスサーバ1に対して情報の登録要求と供に入力された情報を送信する。
【0082】
情報の登録要求を受けたサービスサーバ1においては、要求処理部101が要求を受け付け、要求に含まれる情報に基づいて取引情報処理部104が取引情報記憶部105に記憶されている対象のレコードを更新する。このような処理により、販売依頼取引が完了する。
【0083】
以上説明したように、本実施形態に係るシステムにおいては、上流側から下流側に複数の業者間を商品が転々と流通していく市場取引において、それぞれの取引を1つのレコードとして記録すると供に、それぞれのレコードにおいて取引対象となる商品の1つ上流側の取引、すなわちその商品の仕入れに係る取引を示す情報である「親取引ID」が記録される。
【0084】
これにより市場においてシステム上に取引が記録される商品の流通過程を把握することが可能となり、それを利用することにより、
図9~
図11において説明した商品リストの機能や、
図16において説明した取引一覧表示画面の機能等、現場の助けとなる機能を実現することが可能となる。
【0085】
このように"親取引ID"を介して商品の流通過程を把握する機能に鑑みて、上述した
図8(b)に示す画面において複数の個口で入力されてそれぞれ別のレコードとして取引情報に記録されるレコードには同一の取引ID"が指定される。仮に別々の"取引ID"を付与した場合、その商品を販売する際には、
図14に示す画面の集計のために、販売する商品がどの個口のものかを把握し、正しい"取引ID"を付与するように操作する必要がある。
【0086】
しかしながら、同一の"商品""産地""規格"の場合、後から見分けることは困難であるし、市場の現場において意識的に"取引ID"を理解して管理することも現実的ではない。従って、同一の"商品""産地""規格"の商品を複数個口仕入れた場合には、それらに同一の"取引ID"が付与されるように処理することで、
図14に示す画面の集計に際しては一括して集計され、データ上の不整合や混乱を防ぐことができる。
【0087】
尚、本システムの機能としては、上述した特徴的な機能の他、請求書や納品書の発行機能が含まれる。そのような機能は、
図5に示すように本システムにおいて記憶される情報に基づいて実現可能である。例えば取引を月ごとに集計して請求書を発行する場合であれば、"買い手ID"が請求先の企業に一致し、且つ"取引日時"の年月が請求対象の月に一致するレコードを抽出することにより容易に請求書を生成することが可能である。
【0088】
そのような請求書の生成については、ユーザ端末2においてユーザがGUIを操作して請求先の企業や年月を指定して請求書の生成操作を行うと、ユーザ端末2において操作受付部201が操作内容を受け付け、情報通信部203がサービスサーバ1に請求書の生成要求を送信する。ユーザ端末2からの要求を受けたサービスサーバ1においては要求処理部101が要求を受け付けて取引情報処理部104に情報を受け渡す。
【0089】
要求処理部101から情報を渡された取引情報処理部104は、指定された情報に基づいて取引情報記憶部105に記憶されている情報を抽出し、集計やリスト化を行って請求書を表示するための表示情報を生成する。取引情報処理部104によって請求書の表示情報が生成されると、要求処理部101がその情報を要求元のユーザ端末2に送信する。これにより、ユーザ端末2において請求書が表示され、買い手IDに基づいた請求先企業への送信や、プリントアウトによる紙としての出力が可能となる。
【0090】
また、本システムの動作においては、
図9のS903や、
図17のS1701など、ユーザIDをキーとしてレコードを抽出する処理がある。これは、本システムを利用するためにログインしているユーザの取引情報のみが参照されることを示している。他方、本システムを利用するためのログインについては、ユーザIDによるログインの他、
図4(b)に示す企業IDでのログインもある。
【0091】
そのような場合、それぞれの処理においては、その企業に所属しているすべてのユーザのユーザIDを対象としてレコードが抽出される。例えば、
図17のS1701においては、"買い手ID"がログイン中の"企業ID"であるレコードに加えて、
図4(a)において説明したユーザ情報のうち"所属企業ID"がログイン中の"企業ID"に一致するレコードの"ユーザID"をすべて取得し、取得した全ての"ユーザID"が"買い手ID"に一致するレコードをも抽出する。これにより、企業IDでログインしたユーザは、その企業に所属するすべてのユーザの取引を把握することが可能となる。このような企業IDでのログインによる所属ユーザの取引情報を参照する機能は、以降の実施形態に置いても同様である。
【0092】
実施の形態2.
本実施形態においては、
図16において説明した取引一覧表示画面について、更に現場の実情を考慮して実装される機能について説明する。実施の形態1においては、
図16に示すように、買い量(kg)と売り量(kg)とを比較表示することが可能な例について説明した。仕入れたものを小分けに売っていく以上、売る際にユーザが正確に重量を図って売り、且つその重量を正確にシステムに入力していけば、仕入れたものを売り切った際に取引一覧表示画面に表示される"買い量(kg)"と"売り量(kg)"とは一致するはずである。
【0093】
しかしながら、現場において実際に売った量とシステムに入力した"売り量(kg)"とに微差があり、その微差が積み重なることによって最終的な集計におけるずれが大きくなることがあり得る。また、取引の現場においては、重量で仕入れたものを尾数、匹数で売る場合や、大型の魚を仕入れて切り分けた上で売り物になる部分のみを売る場合等、買う際の単位と売る際の単位とが異なり、"買い量"と"売り量"とを単純に比較することができない場合もあり得る。
【0094】
このように、"買い量"と"売り量"とを単純に比較することができないという事情の中で、トータルとしてあり得る程度の微差を横流しする等の巧妙な不正が現場で行われる場合がある。本実施形態においては、そのような問題に対応するシステムの機能について説明する。
【0095】
図21は、本実施形態に係る取引一覧表示画面の例を示す図である。実施の形態1においては、
図16に示すように、買い量(kg)と売り量(kg)とを比較表示する態様を説明したが、本実施形態に係る取引一覧表示画面においては、
図21に示すように"売り量"の表示単位がそれぞれの商品の販売形態に応じた形式となっていると供に、それぞれの商品について、その取引において算出された歩留まり率と、その商品全体の歩留まり率の平均値を比較表示する"歩留率/平均"の項目が表示される。
図21に示す画面を表示するための情報は、
図16と同様に取引情報処理部104によって生成される。即ち、取引情報処理部104が歩留まり率算出部として機能する。
【0096】
図21の例においては、例えば「海老」の場合、"売り量"としては実際に販売されたデータの"個数"が集計されて「39(尾)」として表示されており、それに合わせて"買い量"としては"規格"の情報と"重量"の情報とから算出された想定の仕入れ尾数が「40(尾)」として表示されている。そして、その数値から算出された歩留まり率が計算され、平均の歩留まり率と供に「98(%)/100(%)」として表示されている。
【0097】
このような「海老」の表示は、実際の取引の現場における販売単位が(円/尾)であった結果である。そのような場合、
図17のS1704において抽出されたレコードの"重量"がすべて空欄であり、"個数"にのみ数値が入力されている状態となる。そのため、比較表示する"買い量"としても"個数"であることが求められるため、
図5において説明した"個数"のデータが選択される。
【0098】
ただし、商品によっては仕入れの際に"個数"が記録されない場合もありうる。例えば
図5において説明したように、海老は仕入れ取引において重量で取引され、"規格"として所定重量あたりの尾数が記憶される。そのため
図21の例においては、"規格"の情報と"重量"の情報とから算出された想定の仕入れ尾数が「40(尾)」として表示されている。
【0099】
また、「イワシ」の場合、"売り量"は「6(kg)+38(尾)」として"重量"と"個数"が集計されて表示されている。これは、実際の取引の現場において(円/尾)での販売と(円/kg)での販売とが混在する場合である。そのような場合、
図17のS1704において抽出されたレコードに"重量"が空欄であるものとそうでないものとが混在する。その場合、比較表示する"買い量"としては、"個数""重量"の両方が選択され、"個数"が空欄である場合に"規格"と"重量"から想定個数が算出されることも同様である。
【0100】
図22は、
図21に示すようなそれぞれの商品ごとの表示形式のルールを示す図である。
図22に示すルールは取引情報処理部104が記憶している。このようなそれぞれの商品ごとの表示の選択は、
図17において説明した処理のうちS1705において実行される。S1704において販売データを抽出した取引情報処理部104は、
図22に示すルールに従って取引一覧表示画面の"買い量""売り量"の表示形式を選択する。
【0101】
また、本実施形態に係る取引情報処理部104はS1705において歩留率を計算する。
図21に示す「海老」や「マグロ」のような商品の場合には、"売り量"を"買い量"で割ることにより単純に算出される。他方、
図21に示す「イワシ」のように、"個数"と"重量"とが混在した商品の場合、取引情報処理部104はそれぞれの歩留まり率を算出して合算する。
【0102】
なお、本実施形態に係る取引情報記憶部105は、各商品および規格ごとに平均歩留まり率の情報(以降、「平均歩留まり率情報」とする)を記憶している。
図23は、本実施形態に係る平均歩留まり率情報の例を示す図である。
図23に示すように本実施形態に係る平均歩留まり率情報は、"商品"、"規格"、"平均歩留まり率"、"サンプル数"の情報を含む。即ち、ここでは取引情報記憶部105が平均歩留まり率記憶部として機能する。
【0103】
図23に示す情報のうち、"平均歩留まり率"は、それまでにシステムにおいて算出された歩留まり率の平均値を示す情報である。これにより、本システムを介して取引される商品の歩留まり率の平均値が把握される。また、"サンプル数"は、その時点での"平均歩留まり率"の算出に用いられたデータ数を示す値である。
【0104】
本実施形態に係る取引情報処理部104はS1705において、処理中のレコード、即ちS1703において選択したレコードの"商品"および"規格"に一致するレコードを平均歩留まり率情報から抽出し、"平均歩留まり率"を取得する。そして、S1706において
図21に示すような内容を表示するための情報を記憶する。このような処理により、
図21に示すような取引一覧表示画面を表示するための画面情報が生成される。
【0105】
また、実施の形態1において説明したように、それぞれの商品をすべて販売し終えたユーザは、
図21に示す画面において"販売終了"のチェックを操作する。すると、実施の形態1において説明した取引情報記憶部105の"販売終了"の更新と供に、歩留まり率情報の更新が行われる。
【0106】
そのため、ユーザ端末2において"販売終了"のチェックが操作されると、ユーザ端末2からサービスサーバ1に対して、上述した情報と供に、S1705において算出された歩留まり率が通知される。この通知を受けたサービスサーバ1においては、取引情報処理部104は、上述した"販売終了"のチェック更新処理に加えて、歩留まり率情報の更新処理を行う。
【0107】
歩留まり率情報の更新処理において、取引情報処理部104は、まず通知された"取引ID"のレコードを取引情報記憶部105から抽出し、通知された歩留まり率を関連付けて記憶する。そのため、本実施形態に係る取引情報記憶部105は、
図5に示す情報に加えて、歩留まり率の情報を含む。
【0108】
また、取引情報処理部104は、
図23に示す平均歩留まり率情報の更新処理を行う。平均歩留まり率情報の更新処理において取引情報処理部104は、通知された"取引ID"のレコードから"商品"および"規格"を取得し、それぞれが一致するレコードを
図23に示す平均歩留まり率情報から抽出する。そして、抽出したレコードの"サンプル数"をnとして、以下の式(1)を用いて更新後の歩留まり率を算出して"平均歩留まり率"を更新すると供に"サンプル数"をインクリメントする。
【0109】
【0110】
このような処理により、取引情報記憶部105が記憶しているそれぞれの取引情報の歩留まり率、および
図23に示す平均歩留まり率の情報が更新される。ユーザは、
図21に示すような画面により、それぞれの商品についての歩留まり率と平均歩留まり率とを比較して確認することが可能となる。
【0111】
また、本実施形態に係るシステムにおいては、上述したようにそれぞれの取引について歩留まり率が記憶されるため、歩留まり率を時系列に確認することが可能となる。
図24は、本実施形態に係る歩留まり率の時系列表示画面(以降、「歩留まり率時系列表示画面」とする)の例を示す図である。
【0112】
図24に示すように、歩留まり率時系列表示画面においては、縦軸を歩留まり率(%)、横軸を取引日時とした折れ線グラフにより、特定の"商品"および"規格"の組み合わせに合致するレコードの"歩留まり率"が時系列に表示される。また、
図23に示すように記憶されている平均歩留まり率が破線で表示される。
【0113】
図24に示す画面は、サービスサーバ1によって生成された画面表示情報に基づいてユーザ端末2において表示される。サービスサーバ1は、ユーザ端末2からの要求に応じて
図24に示す画面を表示するための画面表示情報を生成する。ユーザ端末2からサービスサーバ1への要求には、
図24に示す歩留まり率時系列表示画面の表示情報の生成要求であることを示す情報の他、要求者であるユーザの"ユーザID"、"商品名"、"規格"の情報が含まれる。即ち、歩留まり率時系列表示画面の表示情報の要求に際し、ユーザは少なくとも"商品名"および"規格"を指定して要求の操作を行う。
【0114】
上記要求を受け付けたサービスサーバ1においては、取引情報処理部104が、通知された"ユーザID"が"買い手ID"に一致し、且つ通知された"商品名"、"規格"が一致するレコードを取引情報記憶部105から抽出する。取引情報処理部104は、そのようにして抽出されたレコードの"取引日時"および"歩留まり率"を参照し、
図24に示すようなグラフを表示するための情報を生成する。
【0115】
また、取引情報処理部104は、通知された"商品"および"規格"に基づいて平均歩留まり率情報を参照して一致するレコードを抽出し、対応する"商品"および"規格"の"平均歩留まり率"を取得する。これにより、
図24に示す破線を表示するための情報を生成する。
【0116】
図24に示す画面により、ユーザは自身が仕入れた商品についての"歩留まり率"を"商品"および"規格"ごとに時系列に把握することが可能となる。
図24の例の場合、タイミングt
1辺りを境に歩留まり率が低下しているのがわかる。これは一概に現場の不正が原因であるということはできないが、このような状況の把握により現場の管理に役立てることができる。
【0117】
以上説明したように、本実施形態に係るシステムによれば、商品を仕入れる際の単位と販売する際の単位とが異なる場合であっても、取引一覧表示画面において買い量と売り量とを比較表示することが可能となる。また、商品を仕入れる際の単位と販売する際の単位とが異なる場合における商品の取引結果を歩留まり率として管理することにより、現場で不正が行われた場合にそれを把握することが可能となる。
【0118】
実施の形態3
本実施形態においては、
図9~
図11において説明した売りデータ登録画面における商品リストのリアルタイムな情報反映機能や
図8(a)、(b)における取引情報の登録に関する追加機能について説明する。通常の小売りの場合には店先に陳列されている商品を販売し、売買が成立したら商品を引き渡すため、買い手に対して確実に商品が引き渡される。対して、卸売市場の取引においては、売買契約のみを先に行って商品の受け渡しを事後的に行う場合がある。そのため、取引が成立した直後は現場に商品が残っている状態であり、売買契約ごとに確実に商品を引き当てておかなければ、仕入れ量以上に商品を販売してしまう可能性がある。
【0119】
そのような弊害を回避するため、本実施形態に係るシステムにおいては、
図9において説明した商品リストの生成動作において商品の過販売を防止するための処理が行われる。
図25を参照して、本実施形態に係る商品リスト生成機能の詳細に付いて説明する。
図25は、
図9のS904の処理の詳細を示すフローチャートである。
【0120】
実施の形態1においては、S903の処理により抽出されたレコードのすべてから情報を抽出し、S904においてリストを生成する場合を例として説明した。本実施形態に係るシステムにおいては、S903の処理により抽出されたレコードのうちリストに含めるものを取捨選択する。
【0121】
取引情報処理部104は、S903において抽出したレコードを順番に参照して処理を行う。そのため、まずは抽出されたデータのうち、まだ選択していないデータが残っているか確認する(S2501)。未選択データのまだある場合(S2501/YES)、取引情報処理部104は、未選択のデータのうち1つを選択し(S2502)、"販売終了"がチェック済みか否かを確認する(S2503)。
【0122】
S2503の確認の結果"販売終了"がチェック済みの場合(S2503/YES)、取引情報処理部104は選択中のレコードをリストから除外し(S2504)、S2501の処理を繰り返す。他方"販売終了"が未チェックの場合(S2503/NO)、次に取引情報処理部104は、選択中のレコードの"取引ID"を参照し、取引情報記憶部105が記憶しているデータのうち"親取引ID"が一致するレコードを抽出する(S2505)。
【0123】
S2505において抽出されたレコードは、S2502において選択したレコードの取引によって仕入れられた商品が販売された取引を示すレコードである。取引情報処理部104は、抽出したレコードの"個数"や"重量"を参照して集計することにより、販売量を集計する(S2506)。
【0124】
S2506の処理は、基本的には"重量"を合計する処理であるが、実施の形態2において説明したように、販売取引においては"重量"の情報が入力されない場合がある。従って、取引情報処理部104はS2506において、
図22において説明したようなルールに従って販売量の集計方式を適宜選択する。
【0125】
販売量を集計した取引情報処理部104は、S2502において選択したレコードに基づいて仕入れ量を確認し、S2506の集計結果と比較する(S2507)。仕入れ量の確認に際して取引情報処理部104は、基本的には"重量"を参照するが、S2507の集計結果に応じて"個数"を参照する場合や、"規格"と"重量"から算出される想定の個数を用いる。
【0126】
S2507の処理の結果、仕入れ量が販売量よりも多い場合(2507/YES)、対象レコードの商品はまだ在庫がある状態であり、リストに含めても問題ないものとしてS2501の処理を繰り返す。他方、販売量が仕入れ量に達している場合(2507/NO)、対象レコードの商品には販売可能な在庫がない状態であるため、取引情報処理部104は選択中レコードをリストから除外し(S2504)、S2501の処理を繰り返す。
【0127】
このように処理が繰り返された後、未選択レコードがなくなると(S2501/NO)、取引情報処理部104は、リストから除外したレコード以外のレコード、即ちまだ在庫があると判断したレコードのみで
図9のS904と同様に商品リストを生成し(S2508)、処理を終了する。このような処理により、仕入れた商品の販売状況に応じて
図8(a)、(b)に示す商品の選択リストがタイムリーに生成されることとなり、すでに売り切った商品が誤って取引されてしまうことを防ぐことができる。
【0128】
なお、S2506の集計において"重量"が空欄のデータがある場合に
図22に示すようなルールに従って適宜集計を行う場合を例としているが、仕入れ時の単位と販売時の単位とが異なり、仕入れ量と販売量とを正確に比較することが難しいレコードについては、S2506、S2507の処理を省略し、無条件でリストに含めるようにしても良い。これにより、まだわずかでも在庫が残っているにも関わらずリストから除外されてしまうような事態を回避することができるとともに、S2503の処理により、"販売終了"がチェックされた場合にはリストから除外することが可能となる。
【0129】
次に、
図8(a)、(b)に示す画面において「起票」が操作され、ユーザ端末2からサービスサーバ1に対して取引情報の登録が要求された場合のチェック機能について説明する。
図25において説明したS2506およびS2507の処理により、データ上で対象の商品の在庫量を算出することが可能である。即ち、S2506において集計したー販売量を、仕入れ量から差し引いた値である。
図8(a)、(b)に示す画面の表示情報と供に、その値(以降、「在庫量情報」とする)をユーザ端末2に通知しておくことにより、
図8(a)、(b)に示す画面において入力される"重量"や"個数"に対してチェック機能を実現する事が可能となる。
【0130】
図9においては、商品リストの情報として"取引ID"、"商品コード"、"商品名"、"産地"、"規格"の情報が含まれる場合を例として説明したが、本実施形態に係るシステムにおいてはさらに上述した"在庫量情報"が含まれる。そして
図8に示す画面で"商品名"が選択されると、その商品名に関連付けられている"在庫量情報"が参照され、"重量"に入力される情報と比較される。
【0131】
その結果、"重量"に入力された値が"在庫量情報"よりも大きければ、既に登録されている取引情報から集計される在庫量を超えている旨のアラートがユーザ端末2のGUI上に表示される。これにより、在庫量以上の取引を行おうとしていないかの確認をユーザに促すことができる。このような、入力された"重量"と"在庫量情報"との比較機能や、アラートの機能は、ユーザ端末2において動作する市場販売管理アプリ200の操作受付部および表示処理部202によって実現される。
【0132】
以上説明したように、本実施形態によれば、
図8(a)、(b)に示す取引情報の入力画面において、誤った入力が行われないようにユーザを補助することができる。
【0133】
実施の形態4.
本実施形態においては、
図8(a)、(b)に示す売りデータ登録画面における"買い手"欄の入力を補助する機能について説明する。本システムにおいては、
図12等において説明したように、取引情報の記録において買い手及び売り手がIDによって特定されることが特徴の一つである。従って、
図8(a)、(b)に示す売りデータ登録画面における情報登録に際しては"買い手"欄により商品を買う側のユーザが正確に指定される必要がある。
【0134】
そのため、"買い手"欄の入力はユーザの自由な入力を禁止し、サービスサーバ1の業者情報記憶部103において
図4(a)、(b)に示すように既にユーザ情報および企業情報に登録されている情報を選択肢として、選択式とすることが好ましい。しかしながら、ユーザ情報および企業情報の登録数の増加に伴って選択肢も増加することとなる。選択肢が膨大な数になるとユーザは膨大な数の選択肢から買い手を探す必要があり不便である。
【0135】
本実施形態はそのような問題に対応するものであり、市場において取引を行っている業者それぞれの店舗に買い手が来店したことを検知し、それぞれの店舗が売り手として取引情報を起票する際の"買い手"の選択肢として、来店が検知されたユーザを優先的に表示することにより"買い手"の選択を補助するものである。
【0136】
図26は、本実施形態に係る来店検知機能を示す図である。各店舗には買い手であるユーザの端末を検知するための構成として、店舗通信機3が設置されている。即ち、店舗通信機3が入店認識部として機能する。
図26に示すように、本実施形態に係る店舗通信機3は、Bluetooth機能およびネットワーク通信機能を有する小型の情報処理端末であり、
図2において説明した構成に準ずるハードウェア構成を有する。また、店舗側のユーザが使用するユーザ端末2にソフトウェアをインストールすることによってユーザ端末2を店舗通信機3として機能させることもできる。
【0137】
店舗に来店するユーザのユーザ端末2は、
図27に示すように近距離通信アンテナ90を有する以外は既に説明した実施形態と同様の構成であり、近距離通信アンテナ90により店舗通信機3とBluetooth通信を行う。店舗通信機3はユーザ端末2とのBluetooth機能による近距離通信によりユーザ端末2が店舗に入店したことを認識し、ネットワークAを介してサービスサーバ1に入店情報を送信する。
【0138】
図28(a)、(b)は、本実施形態に係るサービスサーバ1の業者情報記憶部103が記憶しているユーザ情報および企業情報の例を示す図である。
図28(a)、(b)に示すように、本実施形態に係るユーザ情報および企業情報は、
図4(a)、(b)において説明した内容に加えて、"端末識別子"の情報を含む。この"端末識別子"は、ユーザ端末2を一意に識別可能な情報であり、且つ店舗通信機3がBluetooth通信を介してユーザ端末2から取得可能な情報であって、典型的にはMAC(Media Access Control)アドレスが用いられる。
【0139】
本システムを利用するユーザが最初にシステムにサインアップする際、ユーザはウェブブラウザを介して
図4(a)、(b)に示すような情報をフォームに入力および送信することにより、サービスサーバ1において業者情報処理部102が業者情報記憶部103にその情報を登録するが、その情報のやり取りの過程でユーザが使用している端末のMACアドレスを取得することにより、
図28に示すように"端末識別子"が登録される。
【0140】
また、業者情報処理部102は、ユーザが本システムにログインを行うたびにその過程でユーザが使用している端末のMACアドレスを取得し、ログインしたユーザIDに関連付けられている"端末識別子"と比較する。その結果、両者が異なるものであれば、業者情報処理部102は、取得したMACアドレスを"端末識別子"として追加でログインしたユーザのユーザ情報または企業情報に関連付けて記憶させる。これにより、ユーザが複数の端末を使い分ける場合であっても、"端末識別子"に基づいてそのユーザを識別することが可能となる。
【0141】
また、1つの端末を複数のユーザが使う場合もあり得る。そのような場合、上述したようにログイン処理に際してログインされたユーザIDとログインに用いられた端末のMACアドレスとを関連付けることにより、異なる複数のユーザIDに対して同一の"端末識別子"が関連付けられる。
【0142】
図29(a)、(b)は、本実施形態に係る入店情報の例を示す図であり、
図29(a)は、店舗通信機3がサービスサーバ1に送信する情報、
図29(b)は、サービスサーバ1において業者情報記憶部103が記憶している入店情報テーブルの1レコード分の内容を示す図である。即ち、ここでは業者情報記憶部103が入店管理情報記憶部として機能する。
図29(a)、(b)に示す情報の処理について、
図30を参照して説明する。
図30は、本実施形態に係る入店検知処理を示すシーケンス図である。
【0143】
本システムが導入された市場において買い回るユーザは
図27において説明した機能を有するユーザ端末2を携帯し、且つ
図28(a)、(b)において説明したように、そのユーザ端末2のMACアドレスが"端末識別子"としてサービスサーバ1の業者情報記憶部103に登録されている。市場に含まれるそれぞれの店舗に設置された店舗通信機3は常時Bluetooth機能により端末の検知を行っており、ユーザ端末2が通信範囲内に入ると、Bluetooth機能を介してユーザ端末2を検知すると供に、そのユーザ端末2のMACアドレスを端末識別子として取得する(S3001)。
【0144】
なお、Bluetooth機能の仕様によっては、S3001の処理のために予め店舗通信機3とユーザ端末2との間でペアリングが必要となる場合がある。その場合、それぞれのユーザは頻繁に利用する店舗において店舗通信機3と自身のユーザ端末2とで予めペアリングしておくことにより、次回以降は特にペアリング操作を行うことなく、そのユーザ端末2を携帯して店舗を訪れるだけで自動的にS3001の処理が実行される。
【0145】
ユーザ端末2から端末識別子を取得した店舗通信機3は、予め設定されているその店舗のユーザID若しくは企業IDを"入店先ID"とし、取得した端末識別子を"入店者識別子"として、現在時刻と供にサービスサーバ1に送信する(S3002)。この"入店先ID"が店舗識別子として用いられる。これにより
図29(a)の情報がサービスサーバ1に送信される。
【0146】
図29(a)に示す情報を受信したサービスサーバ1においては、業者情報処理部102が、受信した"入店者識別子"に基づいて業者情報記憶部103に記憶されているユーザ情報および企業情報の"端末識別子"を検索する。そして、検索の結果抽出されたユーザ情報のユーザIDまたは企業情報の企業IDを"入店者ID"として取得し、S3002において受信した"入店先ID"および"入店日時"と供に入店情報テーブルとして業者情報記憶部103に記憶させる(S3003)。これにより、
図29(b)に示す情報がサービスサーバ1において記録される。
【0147】
図29(b)に示す情報により、誰が("入店者ID")、どこに("入店先ID")、いつ("入店日時")入店したかが明らかになる。このような情に基づいて、
図8(a)、(b)に示す売りデータ登録画面における情報登録に際して、「買い手」欄の選択肢リストを調整することが本実施形態に係る要旨である。
【0148】
そのため、本実施形態に係る業者情報処理部102は、
図8(a)、(b)に示す売りデータ登録画面が売り手側のユーザ端末2から要求された際に、売り手のユーザIDおよび入店情報テーブルに基づいて「買い手」欄の選択肢リストを生成する。
図31は、その処理を示すフローチャートである。
【0149】
実施の形態1の
図9において説明したように、「売りデータ登録画面」の表示に際してはログイン処理が伴う。
図31においては既にログイン処理が行われた状態でユーザ端末2からサービスサーバ1に対して「売りデータ登録画面」の画面情報が要求された場合を示す。サービスサーバ1において要求処理部101が「売りデータ登録画面」の画面情報の要求をユーザ端末2から受信すると(S3101)、業者情報処理部102が、業者情報記憶部103に対して、「買い手」欄の選択肢リストを生成するためのクエリを実行する(S3102)。
【0150】
S3102において実行されるクエリは、まずユーザ情報から"ユーザID"および"担当者名"を抽出し、企業情報から"企業ID"および"企業名"を抽出し、"ユーザID"と"企業ID"、"担当者名"と"企業名"を連結して"ユーザ名/企業名"、"ユーザID/企業ID"を内容とするテーブル(以降、「ユーザ/企業連結テーブル」とする)を生成する。
【0151】
それとは別に、要求に際して通知されたユーザIDに基づき、入店情報テーブルの"入店先ID"を検索する。これにより、"入店先ID"が「売りデータ登録画面」要求元の店舗であるレコードが抽出される。そのようにして抽出されたレコードの"入店者ID"が"ユーザID/企業ID"に一致するユーザ/企業連結テーブルのレコードに対して、その"入店者ID"に関連付けられている"入店日時"を関連付ける。これにより、
図32に示すようなテーブル構成となる。
【0152】
そして、"入店日時"を対象として、
図32に示すように空欄は後回しとなるように降順で並び替える。これにより、「売りデータ登録画面」の要求元の店舗に新しく入店した順にユーザ/企業が並び替えられ、入店情報がないユーザ/企業は後回しとなる。業者情報処理部102は、このようなクエリの実行結果を「買い手」欄の選択肢リストとして生成し(S3103)、処理を終了する。なお、
図31に示す動作は「売りデータ登録画面」の画面情報の要求に際して実行される処理であり、「売りデータ登録画面」の画面情報の生成に際しては、実施の形態1において説明したように
図9の処理も実行される。
【0153】
このようにして生成されたリストが選択肢として用いられることにより、
図33に示すように、「売りデータ登録画面」の「買い手」の選択肢は、対象の店舗に対して新しく入店した順に並び替えられて表示されることとなる。そのため、取引情報を登録する売り手側のユーザは、膨大な登録済みのユーザ/企業の中から対象の買い手を探すことなく、優先的に表示された入店中の買い手を簡単に選択することが可能となる。
【0154】
なお、上記実施形態においては、入店を検知するための仕組みとしてBluetooth機能を用いる場合を例として説明した。これは、一般的なスマートフォン等の携帯端末であれば当然に実装されている機能であり、容易に実現および普及させることができる点で有効であるが、これに限らず、例えばNFC(Near Field Communication)機能を用いても良い。これはBluetooth機能がNFC機能に置き換わるのみで、仕組みとして上記と大きな違いはなく実現可能である。
【0155】
その他、買い手であるユーザが市場の店舗に入店したことが検知され、その検知に応じて
図29(b)に示すような情報がサービスサーバ1に記録される態様であれば、上記と同様の効果を得ることが可能である。例えば、端末に設けられたカメラでバーコードやQRコード(登録商標)等の画像コードを読み取る態様を用いることができる。
【0156】
この場合、それぞれの店舗にはその店舗のIDおよび入店通知のためのウェブアクセスを提供するURL(Uniform Resource Locator)が符号化された画像コードが印刷されたステッカーや看板等が提示されている。店舗を訪れたユーザは自身のユーザ端末2に搭載されたカメラでそのコードを読み取ることにより、符号化されたURLにウェブアクセスする。このウェブアクセスは、その店舗への入店をサービスサーバ1に対して通知するためのウェブアクセス(以降、「入店通知ウェブアクセス」とする)であり、それぞれの店舗のユーザIDまたは企業IDが供に通知される。典型的には、URLの末尾においてそれぞれの店舗のユーザIDが「/?=user***」という形でクエリパラメータとして指定された形式が用いられる。
【0157】
ユーザ端末2からの入店通知ウェブアクセスを受け付けたサービスサーバ1は、ユーザ端末2に対してログインを求めるために、ログイン画面をユーザ端末2に返す。そのログイン画面においてユーザがログイン操作を行うことによりサービスサーバ1に買い手であるユーザのユーザIDまたは企業IDが通知され、
図29(b)に示すような情報がサービスサーバ1に記録される。なお、ウェブブラウザのcookieによりすでにユーザ端末2において本システムにログイン済みの場合には、この最後のログイン処理を省略してユーザ端末2からサービスサーバ1にログイン済みのユーザIDまたは企業IDを通知することができる。
【0158】
また、画像コードを提示するのが買い手であるユーザのユーザ端末2側で、店舗側に設置された端末(以降、「入店管理端末」とする)に搭載されたカメラでそれを読み取る態様でも同様の効果を得ることが可能である。この場合、買い手であるユーザのユーザ端末2が提示する画像コードには、そのユーザのユーザIDまたは企業IDが符号化されている。
【0159】
店舗に入店したユーザは、本システムのGUI機能として、ログイン済みである自身のユーザIDまたは企業IDが符号化されたコードを画面に表示させる。このような機能は、ユーザ端末2からの要求に応じてサービスサーバ1の要求処理部101が画面情報を生成してユーザ端末2に返信することにより実現可能である。その他、サービスサーバ1との間での通信を伴うことなく、ユーザ端末2側にダウンロードされて動作するJavaScript等のプログラムの機能により実現することもできる。
【0160】
そのようにしてユーザ端末2に表示されたコードが入店管理端末に読み取られると、入店管理端末は読み取ったコードを復号して得られるユーザIDまたは企業IDを、予め登録されているその店舗のユーザIDまたは企業IDと供にサービスサーバ1に入店情報として通知する。これにより、
図29(b)に示すような情報がサービスサーバ1に記録され、上記と同様の効果を得ることができる。
【0161】
実施の形態5.
実施の形態1~4においては、上流側の業者において既に仕入れが確定している商品の中から売るものが選択されて取引情報が入力される場合を例として説明した。他方、取引の実情として、上流側の業者において未だ仕入れが確定していない商品について下流側の業者から前もって取引の予約や販売希望を伝える、即ち注文する場合がある。
【0162】
このような場合、上流側の業者において仕入れが確定しない商品については取引情報記憶部105に取引情報が記憶されていないため、注文の内容を取引情報として記録したとしても、その商品の上流側における仕入れの取引を指定する"親取引ID"を指定することができない。本実施形態においてはそのような態様について説明する。
【0163】
図34は、本実施形態に係る取引情報記憶部105に記憶されている取引情報の1レコード分の内容を示す図である。
図34に示すように、本実施形態に係る取引情報は、
図5において説明した内容に加えて、"注文フラグ"および"注文元ID"の情報を含む。"注文フラグ"はその取引情報レコードが、注文情報であること、即ち下流側の業者から上流側の業者に対する商品のリクエストであることを示す識別子である。
【0164】
"注文元ID"は、実施の形態1において説明した"親取引ID"の逆であり、その取引情報レコードが注文情報である場合であり、且つ下流側の業者から受けた注文に基づいて更に上流側の業者に対して注文を出す注文情報である場合に、下流側の業者から受けた注文情報の取引情報レコードを指定する情報である。下流側の複数の業者から受けた同種および同規格の商品をまとめて上流側の業者に対して注文を出すことが多いため、
図34に示すように"注文元ID"は複数指定されることが一般的である。
【0165】
図35は、本実施形態に係る注文情報の処理動作を示すシーケンス図である。
図35の例においては、小売店から仲買に商品が注文され、その注文に基づいて仲買から大卸に注文が出される場合について説明する。
図35に示すように、まずは小売店がユーザ端末2dを操作して注文情報を登録する。
図36は、本実施形態に係る注文データ登録画面の例を示す図である。
【0166】
図36に示すように、注文データ登録画面は
図8(a)、(b)において説明した売りデータ登録画面と概ね同様の取引情報を入力するための入力欄を含むが、買い手側から売り手側に対しての販売要求であるという点で、買い手ではなく売り手を指定する点が大きく異なる。ユーザ端末2dに表示された
図36に示す画面において必要な情報が入力され、「起票」ボタンが操作されることにより、ユーザ端末2dからサービスサーバ1に対して注文情報の登録要求が送信される(S3501)。
【0167】
S3501の処理の結果、サービスサーバ1において取引情報処理部104により取引情報記憶部105に取引情報が記録される。即ち、取引情報処理部104が注文受付処理部として機能する。この際、
図36の画面の表示に際してログインしたユーザID若しくは企業IDが"買い手ID"として登録されるとともに、"注文フラグ"がオンの状態で登録される。このような注文情報が取引情報記憶部105に記憶される際には、注文先の業者においてまだ在庫の引き当てがされていない状態であり、"親取引ID"は未定であるため、空欄のまま登録される。
【0168】
このように小売店による注文の情報が登録されると、その注文情報において注文先として指定された業者の注文データ一覧表示画面において、その注文情報が確認可能となる。
図37は、本実施形態に係る注文データ一覧表示画面を示す図である。
図37に示す画面は、注文情報において注文先として指定された業者である仲買業者のユーザ端末2cが、ユーザの操作に従ってサービスサーバ1に画面情報の要求およびログイン済みのユーザID若しくは企業IDを送信することにより表示される(S3502)。
【0169】
注文データ一覧表示画面の要求を受け付けたサービスサーバ1においては、取引情報処理部104が、要求とともに通知されたユーザIDが"買い手ID"に一致し、且つ"注文フラグ"がオンであるデータを抽出し、
図37に示すようにそれぞれの"売り手ID"ごとにまとめて表示する画面情報を生成する。そのようにして生成された画面情報を要求処理部101が要求元のユーザ端末2cに送信する。
【0170】
このように注文を確認した仲買業者は、受注した注文に基づいて更に上流側の業者へ在庫確保のための注文を行う。その際、異なる複数の業者から同一の産地、規格で且つ同一の商品についての注文がある場合、まとめて注文を行うことができる。そのため、ユーザは
図37に示す画面において、更に上流側の業者へ出す注文の元となる注文のレコードをタップやクリック操作により選択する。選択されたレコードは色が反転表示されるなど、GUI上で明示されるが、選択用のチェックボックスなどを設けても良い。
【0171】
このように元となる注文レコードが選択された状態で、
図37に示す「注文」ボタンがタップ等で操作されると、選択された注文レコードの"取引ID"が一次的に記録された状態で
図36に示す注文データ登録画面が表示される。この際、
図37に示す画面で選択された注文レコードの"商品名"、"産地"、"規格"が自動的にそれぞれの欄に入力されることにより、ユーザの利便性を向上することができる。
【0172】
このようにして表示された注文データ登録画面において、S3501と同様にユーザが情報を入力し「起票」ボタンをタップすることにより、ユーザ端末2cからサービスサーバ1に対して注文情報の登録要求が送信される(S3503)。S3503においては、ログインに用いられたユーザID若しくは企業IDと供に、
図37に示す画面で選択された注文レコードの取引IDがサービスサーバ1に通知される。
【0173】
S3503の処理の結果、サービスサーバ1において取引情報処理部104により取引情報記憶部105に取引情報が記録される。この際、
図36の画面の表示に際してログインしたユーザID若しくは企業IDが"買い手ID"として登録されるとともに、"注文フラグ"がオンの状態で登録され、更にユーザ端末2cから通知された注文の元となる注文レコードの取引IDが"注文元ID"として記録される。
【0174】
このようにして"注文元ID"が記録された場合、取引情報処理部104は、その"注文元ID"と一致する"取引ID"のレコードを抽出する。そのレコードは注文元のレコードであり、上述した通り"親取引ID"が空欄の状態である。取引情報処理部104は、そのようにして抽出したレコードの"親取引ID"に、新たに追加したレコードに付与された"取引ID"を書き込み、親取引IDを更新する(S3504)。
【0175】
図38は、S3501において登録された小売店から仲買への注文の取引情報(以降、「一次注文」とする)と、S3503において登録された仲買から大卸への注文の取引情報(以降、「二次注文」とする)との対応関係を示す図である。
図38に示すように、一次注文の「売り手ID」が二次注文の「買い手ID」と共通し、一次注文の「取引ID」が二次注文の「注文元ID」として指定される。また、一次注文の「注文元ID」は空欄である。
【0176】
そして、S3504の処理においては、二次注文が起票されて採番された「取引ID」が、一次注文の「親取引ID」として書き込まれる。これにより、下流側の業者から上流側の業者への注文による取引情報の入力機能においても、本システムの要旨の1つである取引情報の連結関係の記録を実現することができる。なお、「親取引ID」が登録されることにより、その取引情報は注文として処理されたとみなし、「注文フラグ」をオフとしても良い。これにより、
図37に示す画面には表示されなくなる。
【0177】
このように仲買業者による注文の情報が登録されると、その注文情報において注文先として指定された大卸業者の注文データ一覧表示画面において、その注文情報が確認可能となる。S3502と同様、注文情報において注文先として指定された業者である大卸業者のユーザ端末2bが、ユーザの操作に従ってサービスサーバ1に画面情報の要求およびログイン済みのユーザID若しくは企業IDを送信することにより、
図37と同様に大卸業者のユーザ端末2bにおいて注文データ一覧表示画面が表示される(S3505)。
【0178】
本実施形態に係る注文機能は、小売店や飲食店が翌日以降に必要となる商品を前もって確保するために注文を行うことが前提である。これに対して、生産・仕入れ業者から大卸業者に入荷する商品の取引情報は前日に起票されていることが一般的である。従って、仲買から大卸業者に注文が行われたタイミングでは、生産・仕入れ業者から大卸業者への売りが確定し、取引情報記憶部105に取引情報が記憶されていることが一般的であり、原則として大卸業者において在庫の引当処理が可能である。
【0179】
大卸業者が
図37に示す注文データ一覧表示画面において在庫を引き当てる対象の注文を選択し、図中に示す「在庫引当」ボタンを操作すると、ユーザ端末2bからサービスサーバ1に対して在庫引当画面の要求が送信される。サービスサーバ1はその要求に応じて在庫引当画面を表示するための画面情報をユーザ端末2bに対して送信する。これにより、ユーザ端末2bにおいて在庫引当画面が表示され、大卸業者において在庫確認が行われる(S3506)。
【0180】
図39は、本実施形態に係る在庫引当画面の例を示す図である。
図39に示すように、在庫引当画面においては、在庫引当画面の要求に際して
図37に示す画面で選択された注文情報が抽出されて表示されている。そして、その注文情報に対応する商品の一覧であって、自身(ここでは大卸業者)のユーザID若しくは企業IDが"買い手ID"となっている取引情報の一覧が表示されている。
【0181】
図39に示すような画面は、S3506においてサービスサーバ1がユーザ端末2bから受けた要求に応じて取引情報記憶部105から情報を抽出することにより実現される。このような画面において、大卸業者はユーザ端末2bを操作し、表示されている注文情報に対して引き当てる在庫を「対応在庫」として表示されている取引情報から選択し、「確定」ボタンをタップする。これにより、ユーザ端末2bからサービスサーバ1に対して在庫引当登録が要求される(S3507)。
【0182】
図40は、S3507の在庫引当登録の要求においてユーザ端末2bからサービスサーバ1に対して送信される情報(以降、「在庫引当情報」とする)の例を示す図である。
図40に示すように、在庫引当情報には、
図39において「注文情報」の一覧に含まれる注文情報としての取引情報の取引IDである"対象注文情報取引ID"と、その注文に対して在庫を引き当てる対象の取引情報の取引IDである"在庫引当対象取引ID"とを含む。
【0183】
図40に示す在庫引当情報を受信したサービスサーバ1においては、取引情報処理部104が、対象注文情報取引IDによって指定される取引IDの取引情報の「親取引ID」に、在庫引当対象取引IDを書き込むことで親取引IDを更新する(S3508)。これにより、注文機能において、小売店、仲買、大卸というように下流側から順に発信された注文に対して実際の在庫が引き当てられることとなり、注文処理が完結する。
【0184】
以上説明したように、本実施形態においては、
図1に示すような生産・仕入れ、大卸、仲買、小売店・飲食店といった形で上流側から下流側に順々に取引が行われる市場を前提として"親取引ID"によって下流側の取引情報から上流側の取引IDを指定する形で取引の流れが記録されるシステムにおいて、下流側から上流側の業者に対して注文を行う場合であっても、"親取引ID"による取引の流れの記録に対応することが可能となる。
【0185】
なお、上記実施形態においては、取引情報の成立タイミングの実情に鑑み、下流側からの注文に対して大卸業者の段階で在庫の引き当てが行われる場合を例として説明した。これは一例であり、在庫の引き当て処理は、在庫の確定と注文の日程との関係で可能なタイミングで行われるものであって、例えば仲買業者の段階で可能であれば、上述した在庫引当処理を仲買業者が行っても良い。
【0186】
また、
図39においては、対応在庫の一覧の抽出条件として、在庫を引き当てる業者(上記においては大卸業者)のユーザID若しくは企業IDが"買い手ID"となっている取引情報であって、注文情報として選択された取引情報と"商品"が一致するものが抽出される場合を例として説明した。これは一例であり、実際には注文において指定された産地や規格に従って在庫を引き当てることとなるため、"産地"や"規格"も抽出条件としても良い。また、注文の日時に対して"取引日時"を条件としても良いし、"販売終了"のフラグが付されているレコードを除外するようにしても良い。
【0187】
また、上記実施形態においては、注文者によって入力された希望の金額がそのまま取引情報として確定する場合を例として説明したが、取引現場の実情として金額の確定には様々な場合がある。従って、上述した態様の他、注文を受けた側が金額を修正して確定する態様や、注文を受けた側によって修正された金額に対して注文を出した側の合意を必要とする態様などを採用しても良い。また、注文を出す側が金額に幅を持たせて注文情報を起票し、注文を受けた側がその範囲内で金額を決定する態様でも良い。
【符号の説明】
【0188】
1 サービスサーバ
2、2a、2b、2c、2d ユーザ端末
3 店舗通信機
10 CPU
20 RAM
30 ROM
40 HDD
50 I/F
60 LCD
70 操作部
80 バス
90 近距離通信アンテナ
101 要求処理部
102 業者情報処理部
103 業者情報記憶部
104 取引情報処理部
105 取引情報記憶部
200 市場販売管理アプリ
201 操作受付部
202 表示処理部
203 情報通信部
【要約】
【課題】商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握すること
【解決手段】市場における商品の取引に関する情報を管理する市場取引管理システムであって、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする。
【選択図】
図1