JP2016218983A - 商品販売支援システムおよび商品販売支援プログラム - Google Patents

Abstract

【課題】予め単価を設定しておくことができない第一次産業による生産品等の販売を支援する。
【解決手段】商品の販売業務を支援する商品販売支援システム１であって、顧客３からの注文内容についての販売者２からの入力を受け付ける店舗端末１０を有し、店舗端末１０は、入力装置としてのテンキーパッド２０と、販売者２によるテンキーパッド２０の操作を介して、顧客３の注文に係る１つ以上の商品４のそれぞれについて、各商品４を特定する１つ以上の数字からなる商品コード、および量と単価の数値の入力を受け付けて記録し、商品コードに対応する商品名および量と単価とから算出した販売金額の情報を店舗端末１０の画面上に表示する販売集計部１１と、を有する。
【選択図】図１

Description

本発明は、商品販売における販売者の業務を支援する技術に関し、特に、水産物や農産物など販売単価が不定である物品の販売を支援する商品販売支援システムおよび商品販売支援プログラムに適用して有効な技術に関するものである。

例えば、場外市場において鮮魚等を販売する店舗などでは、一般消費者に加えて法人等（例えば飲食店など）に対しても商品を販売している。このような販売を行う店舗には、近年提唱されているいわゆる第六次産業における事業者（第一次産業における生産者）なども含まれており、その活性化や高度化を図るためにも販売業務を支援する仕組みが望まれている。

このような店舗で販売される生鮮食料品等の商品は、通常、予め決められた一定の小売価格や定価などがなく、価格（単価）は、商品の品質や等級などによって異なる上に、同じ品質や等級であっても日毎、時間帯毎で変動する場合がある。

単価が変動する商品の販売を支援する仕組みとして、例えば、特開２０１０−４８５７４号公報（特許文献１）には、入力した単価と計量部で計量した重量データにより値段を算出する料金秤において、複数の単価プリセットキーのうち、置数により入力した単価と同一単価を持つ単価プリセットキーが存在するかを検索し、存在しない場合、最終利用が一番古い単価プリセットキーの単価に、入力した単価を上書きして記憶することで、自動的に単価プリセットキーの利用頻度を反映した単価プリセットキーを設定することが記載されている。

特開２０１０−４８５７４号公報

単価が変動する生鮮食料品などの販売において、例えば、特許文献１に記載されたような従来技術を用いることで、商品毎の単価の入力、設定の負荷を低減させることが可能である。

しかしながら、例えば、場外市場の店舗における鮮魚等の販売では、単に単価が変動するだけではなく、時間帯によって単価が変わったり、販売先が得意先であるか否かによって値引きがされるような商慣習があったりなど、個別の取引毎に販売者の意思決定によって任意に単価が設定・調整される場合もあり、特許文献１のようにプリセットキー等に予め単価を設定しておくこと自体が困難であるという特性を有する。

また、販売対象がこのような第一次産業による生産品である場合、販売現場は、土・泥や水・海水など、機械や機器にとって悪影響を及ぼす可能性が高い環境であることが多い。また、ピーク時間帯には販売者も多忙となる。したがって、販売業務を支援する仕組みは、過酷な使用環境にも対応可能であり、かつ操作が簡易であることが必要となる。

そこで本発明の目的は、予め単価を設定しておくことができない第一次産業による生産品等の販売を支援する商品販売支援システムおよび商品販売支援プログラムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による商品販売支援システムは、商品の販売業務を支援する商品販売支援システムであって、顧客からの注文内容についての販売者からの入力を受け付ける情報処理端末を有し、前記情報処理端末は、入力装置としてのテンキーパッドと、前記販売者による前記テンキーパッドの操作を介して、前記顧客の注文に係る１つ以上の商品のそれぞれについて、前記各商品を特定する１つ以上の数字からなる商品コード、および量と単価の数値の入力を受け付けて記録し、前記商品コードに対応する商品名および前記量と前記単価とから算出した販売金額の情報を前記情報処理端末の画面上に表示する販売集計部と、を有するものである。

また、本発明は、上記の商品販売支援システムとして機能するよう、コンピュータに処理を実行させる商品販売支援プログラムにも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、予め単価を設定しておくことができない第一次産業による生産品等の販売を、簡易な操作により支援することが可能となる。

本発明の一実施の形態である商品販売支援システムの構成例について概要を示した図である。 本発明の一実施の形態における注文内容の入力受付画面の例について概要を示した図である。 本発明の一実施の形態における注文内容の入力受付画面の例について概要を示した図である。 本発明の一実施の形態における決済状況の一覧画面の例について概要を示した図である。 本発明の一実施の形態における顧客マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における商品マスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における取引管理ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における決済管理ＤＢのデータ構成の例について概要を示した図である。 一般消費者や法人等に対して店頭で鮮魚等の商品を販売する際の従来の手法の例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。一方で、ある図において符号を付して説明した部位について、他の図の説明の際に再度の図示はしないが同一の符号を付して言及する場合がある。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
図９は、一般消費者や法人等に対して店頭で鮮魚等の商品を販売する際の従来の手法の例について概要を示した図である。店頭には、鮮魚や水産加工品等の商品４が陳列され、複数の顧客３がそれぞれ購入する商品４を選択・決定する。なお、商品４は、上述したように、通常、予め決められた一定の小売価格や定価などがなく、商品４の品質や等級などによって価格（単価）が異なり、同じ品質や等級であっても日毎、時間帯毎で変動する場合があるという特性を有する。

各顧客３は、それぞれが独自のタイミングで購入意思を決定し、店舗の販売者２に対して注文を行う（１）。販売者２は、注文を受けると、注文に係る商品４に対して引渡しのための準備（例えば、対象の魚を取り分けて分離したり包装・梱包したり等）を行うとともに、当該商品４の種類や数量・重量、販売者２自身が判断・決定した単価等の情報をレジ担当者５に対して伝達する（２）。伝達を受けたレジ担当者５は、これを紙のメモなどに記録しておく（３）。顧客３が複数の商品４を購入する予定の場合は、この時点で支払・清算は行われず、顧客３は他の商品４の選択・決定を継続する。

また、複数の顧客３が同時並行的に注文を行うため、販売者２からレジ担当者５への伝達はその都度行われ、レジ担当者５は、顧客３毎に注文内容をメモに記録しておく。ある顧客３について購入対象の全ての商品４の選択・決定が終了した旨の意思表示がなされると、販売者２は、その旨をレジ担当者５に伝達する。伝達を受けたレジ担当者５は、メモに記録された対象の顧客３の注文内容に基づいて代金を集計し、結果をレジ７０に入力する（４）。そして、対象の顧客３が集計結果の代金を支払い、取引が完了する。

このような従来の手法では、レジ７０から出力されるレシートには取引全体の合算のみが記載され、その中の商品４の内訳や明細が不明となって把握できない場合が生じるという課題があった。また、顧客３に対する対応で負荷が高くなる販売者２が注文内容の記録まで行うことが困難であり、注文内容の記録や集計等を行うレジ担当者５を別途配置せざるを得ないという非効率な状況であった。

これに対し、このような販売に係る業務を情報処理システムにより支援することが望まれるが、上述したように、販売現場の店舗は、土・泥や水・海水など、機械や機器にとって悪影響を及ぼす可能性が高い環境であることが多いため、過酷な使用環境にも対応可能な仕組みであることが必要である。また、販売者２は、複数の顧客３に同時並行的に対応する必要があり、負荷が高くなることから、操作が簡易であることが必要である。この点、例えば、商品４の種類を入力・設定するために、各商品４の商品コードに対応付けられたバーコードの一覧表をバーコードリーダーによって読み取るというような仕組みが考えられるが、読取り作業の煩雑さや汚れ等による読取り精度等の観点から課題が残る。

さらに、このような鮮魚等の販売では、例えば、顧客３が得意先であるか否かによって値引きの有無や値引率が随時決定されたり、得意先には掛払い・ツケ払いを許容したりなどの商慣習を有している場合が多く、このような得意先を考慮した取引についても支援できることが求められる。

そこで、本発明の一実施の形態である商品販売支援システムは、可搬性を有して販売現場で柔軟に使用することができるタブレット型端末を用いるとともに、商品４の種類や単価等の情報を入力するインタフェースとして、外付けのテンキーパッドを用いることで、テンキー操作のみでの簡易な入力を可能とする。また、顧客３毎に属性情報や各取引の決済・清算の状況を管理し、得意先としての特殊な取扱いを行えるように支援する。

＜システム構成＞
図１は、本発明の一実施の形態である商品販売支援システムの構成例について概要を示した図である。商品販売支援システム１は、例えば、鮮魚等の商品４を販売する店舗等で販売者２により使用されるタブレット型端末などからなる店舗端末１０からなる。店舗端末１０には、無線ＬＡＮやＢｌｕｅｔｏｏｔｈ（登録商標、以下同じ）等の近距離無線通信を介して店舗端末１０から利用可能となっているテンキーパッド２０、およびレシートプリンタ３０、納品書プリンタ４０の各プリンタが接続されている。

店舗端末１０は、後述する各機能やデータをローカルに保持してスタンドアロン環境で稼働するように構成してもよいし、各機能やデータの一部もしくは全部をサーバシステム５０上に保持してサービスとして提供し、インターネット等のネットワーク６０を介してこれらの機能の利用やデータへのアクセスを行う構成としてもよい。この場合、販売者２や他の担当者等が、図示しないＰＣ（Personal Computer）等の情報処理端末を用いてサーバシステム５０にアクセスし、取引状況や決済状況の集計、閲覧、管理などを行える構成としてもよい。

テンキーパッド２０は、数字入力のためのテンキーおよびエンターキーなどの少数のキーのみを有する数字入力に特化した入力デバイスであり、例えば、Ｂｌｕｅｔｏｏｔｈにより店舗端末１０と無線接続し、店舗端末１０の入力インタフェースとして機能する。比較的安価で入手が容易であり、店舗端末１０が標準で有するソフトウェアキーボードなどの入力インタフェースと比べて、ブラインドタッチも含めて打鍵が容易かつ打鍵感覚が明瞭であり、構造が単純で過酷な使用環境でもある程度の耐性を有するものが多いことから、本実施の形態における店舗での使用には好適である。一方で、店舗端末１０が有するソフトウェアキーボードの使用を排除するものではない。

レシートプリンタ３０および納品書プリンタ４０は、それぞれ、無線ＬＡＮやＢｌｕｅｔｏｏｔｈ等による通信を介して店舗端末１０と無線接続し、店舗端末１０から指示された印刷データに基づいて紙媒体を印刷出力する。レシートプリンタ３０は、商品４を購入した顧客３に提供するレシート３１を出力するプリンタであり、種類などは特に限定されないが、例えば、専用の感熱紙にレシート内容を印刷する一般的なサーマルプリンタを用いることができる。一方、納品書プリンタ４０は、例えば、掛払いや月末一括払い等、取引の際に決済が行われない場合に、顧客３に対して発行する納品書４１（請求書でもよい）などを出力するプリンタであり、種類などは特に限定されないが、例えば、普通紙に印刷する一般的なインクジェットプリンタを用いることができる。

店舗端末１０は、販売現場で販売者２が直感的な操作を行いやすいよう、本実施の形態では上述したようにタッチパネルを有するタブレット型端末等により実装されるものとしているが、ノート型やデスクトップ型のＰＣにより実装することも機能上は可能である。店舗端末１０は、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）などのミドルウェア上で稼働するソフトウェアとして実装される販売集計部１１、販売チェック部１２、決済処理部１３、および清算管理部１４などの各部を有する。また、データベースやファイルテーブルなどにより実装される顧客マスタデータベース（ＤＢ）１５、商品マスタＤＢ１６、取引管理ＤＢ１７、および決済管理ＤＢ１８などの各データストアを有する。

販売集計部１１は、後述するような入力画面を店舗端末１０のディスプレイ上に表示させ、当該画面により、販売者２によるテンキーパッド２０の操作を介して顧客３からの商品４毎の注文内容の入力を受け付け、その情報を顧客３毎に保持する。また、顧客３の全ての注文が完了した場合に、当該顧客３の注文を全て集計して合計代金を計算して出力するというレジ機能を有する。成立した取引の内容は取引管理ＤＢ１７に記録して管理する。

販売チェック部１２は、販売集計部１１により入力された注文内容を随時チェックし、所定の条件に合致する場合や過去の取引内容の傾向から著しく外れるような場合にこれを通知・警告したり、単価や値引率等のデフォルト値を自動的に設定したり等のチェック機能を有する。チェックする条件には、例えば、対象の顧客３が顧客マスタＤＢ１５上に登録されているか否か、登録されている場合に対象の顧客３が得意先であるか否か、得意先である場合の区分などが含まれる。また、決済管理ＤＢ１８上で管理されている決済の状況において対象の顧客３に未決済の取引があるか否か、ある場合の総額なども含まれ得る。

決済処理部１３は、顧客３との間で成立した取引（１つ以上の商品４の販売からなる）について販売集計部１１により顧客３に提示された代金に対する支払いの内容を決済管理ＤＢ１８に記録し、内容に応じてレシート３１もしくは納品書４１を印刷出力するというレジ機能を有する。支払いの内容には、例えば、全額の現金払い、一部金額のみ現金払いで残額は掛払い、全額の掛払いなどが含まれ得る。

清算管理部１４は、決済処理部１３により決済管理ＤＢ１８に記録された決済のうち、決済状況が掛払いでかつ未決済のものについて、状況の管理や支払いに伴う消し込み処理等を行う機能を有する。例えば、後述するような取引の決済状況の一覧画面を店舗端末１０のディスプレイ上に表示させて状況を把握できるようにしたり、支払いがあった特定の取引の選択を受け付けて消し込みを行えるようにしたりする。

＜画面例＞
図２、図３は、販売集計部１１により店舗端末１０に表示される注文内容の入力受付画面の例について概要を示した図である。図２は、販売者２が顧客３から商品４についての注文を受けた際にその内容を入力して記録するための画面である。

この画面において販売者２が値を入力可能なフィールドは、画面上部の「お客様」、「商品名」、「量」、「単価」欄であり、現時点では太枠となっている「単価」欄に入力のためのフォーカスがされている（カーソルが存在する）状態であることを示している。販売者２は、テンキーパッド２０のエンターキー（もしくはバックスペースキー等）を押下することで、入力のためのフォーカスをこれらのフィールド間で順次遷移させることができる。フォーカスの指定は、店舗端末１０において当該画面が表示されているタッチパネルを直接タップして指定してもよい。

「お客様」欄には、販売者２が把握している場合に顧客コードの数値をテンキーパッド２０により入力することができる。このとき、販売集計部１１は、例えば、フォーカスが「お客様」欄から外れたタイミングで顧客マスタＤＢ１５を参照し、顧客コードに対応する顧客名の情報（図２の例では“○×寿司”）を取得して自動的に変換して表示させることができる。顧客コードの入力は必須ではなく、入力されない場合は「お客様」欄はブランクのままである。

同様に、「商品名」欄には、販売者２が把握している商品コードの数値をテンキーパッド２０により入力することができる。このとき、販売集計部１１は、例えば、フォーカスが「商品名」欄から外れたタイミングで商品マスタＤＢ１６を参照し、商品コードに対応する商品名の情報（図２の例では“ワカシ”）を取得して自動的に変換して表示させることができる。販売者２が意図した商品名に対応する商品コードが入力されたか否かを容易に確認できるようにするため、表示に併せて商品名を音声出力するようにしてもよい。

このように商品名の検索などを行わせずに直接商品コードの数値を入力させるようなインタフェースの場合、販売者２としては、当初は商品コードの数値と商品との対応表などを用意しておき、対象の商品４に対応する商品コードを確認しつつ入力する必要があるなど入力効率が悪くなる場合がある。しかしながら、例えば鮮魚等を扱う店舗では、一般に商品４の種類は概ね数十程度であるため、慣れてくると、頻繁に注文される商品４についてはそのような確認や検索等を要さずに直接数値を入力することができるようになり、都度検索等を行って商品名を入力するインタフェースよりもかえって圧倒的に入力効率が向上する場合が多い。

「量」欄には、注文内容にかかる商品４の量の値（図２の例では“０．８”Ｋｇ）を入力する。また、「単価」欄には、注文内容にかかる商品４の単価（図２の例ではＫｇあたりの単価）を入力する。この単価は、上述したように、商品４の品質や等級などによって異なり、同じ品質や等級であっても日毎、時間帯毎で変動する場合があることから、予めシステムに固定値を設定しておくことができない。従って販売者２が自身の判断により都度指定することになる。このとき、例えば、対象の商品４と同種のものの市場価格（浜値）の情報をネットワーク６０を介して外部から定期的に取得しておき、当該価格をデフォルト値として表示するようにしてもよい。「量」および「単価」が入力されると、これらを乗算した小計を自動的に表示する。

販売者２により「追加」ボタンが押下されると、当該商品４に係る注文が明細として追加され、画面下部に表示されるとともに、取引全体の「合計金額」欄も更新される。また、「商品名」、「量」、「単価」欄の内容がクリアされ、他の商品４について追加の注文内容の入力を受け付けることが可能な状態となる。「追加」ボタンの押下は、店舗端末１０上で当該画面が表示されているタッチパネルを直接タップして操作してもよいし、テンキーパッド２０の所定のキーにショートカットとして機能を割り当てる等によりテンキーパッド２０のみで操作できるようにしてもよい。

「追加」ボタンが押下されて注文の明細を追加する際に、販売チェック部１２が注文内容のチェックを行うようにしてもよい。例えば、予め取得しておいた対象の商品４の市場価格（浜値）と、指定された「単価」との乖離が所定の閾値以上の場合には警告メッセージを表示するなどして、妥当性を確保できるようにしてもよい。

また、「お客様」が指定されている場合に、対象の顧客３の属性や過去の取引の傾向などに基づいて、著しく外れた注文内容であると判断される場合に警告メッセージを表示するなどのチェックを行うことができる。例えば、対象の顧客３が飲食店であり、対象の魚を通常は生食で提供する業態であるのに関わらず、同種の魚で加熱処理を要するタイプのものを注文している場合や、毎回ほぼ同じ種類の魚を購入していた顧客３が全く異なる種類の魚を大量に注文している場合などに警告することができる。これらのチェックの条件は、例えば、販売者２等が経験上有しているものや、取引管理ＤＢ１７等の過去の実績データの自動・手動での分析等により得られたものなどを、予めシステム上に設定・保持しておくことができる。

販売者２により「確認」ボタンが押下されると、販売集計部１１が取引管理ＤＢ１７に取引内容、注文内容を登録するとともに、図３に示すような取引内容の確認と決済を行う画面に遷移する。なお、「確認」ボタンの押下についても同様に、店舗端末１０上で当該画面が表示されているタッチパネルを直接タップして操作してもよいし、テンキーパッド２０の所定のキーにショートカットとして機能を割り当てる等によりテンキーパッド２０のみで操作できるようにしてもよい。

図３の画面において販売者２が値を入力可能なフィールドは、「値引率」、「支払方法」、「お預り金額」、「お客様」欄であり、図２の画面と同様に、販売者２は、テンキーパッド２０のエンターキー（もしくはバックスペースキー等）を押下することで、入力のためのフォーカスをこれらのフィールド間で順次遷移させることができる。フォーカスの指定は、店舗端末１０において当該画面が表示されているタッチパネルを直接タップして指定してもよい。

「値引率」欄には、販売者２が自身の判断により当該取引についての値引率を％で指定することができる。「お客様」が既に指定されており、当該顧客３が得意先である場合には、顧客マスタＤＢ１５に登録されている値引率をデフォルト値として表示するようにしてもよい。「値引率」が入力されると（もしくは入力されずにゼロのままとされると）、販売集計部１１は、図２に示した「合計金額」に「値引率」を反映させた「お支払金額」を自動的に計算して表示する。また、「明細」欄には各商品４の注文明細の内容を表示する。

「支払方法」欄には、顧客３により指定された支払方法の区分を入力することができる。図３の例では、現金払いを“０”、掛払いを“１”として入力することができる。また、「お預り金額」欄には、顧客３により指定された支払方法が現金払いである場合に、受領した金額の値を入力することができる。これにより釣銭を自動的に計算して「おつり」欄に表示する。

「お客様」欄には、図２の「お客様」欄と同様に、販売者２が把握している場合に顧客コードの数値をテンキーパッド２０により入力することができる。図２の画面で既に入力されている場合にはその内容が引き継がれる。図２の画面で注文を受け付けている状況では顧客３の顧客コードが不明で「お客様」欄への入力ができなかった場合でも、図３の画面から改めて入力することができる。これにより、顧客３に対する取引の妥当性のチェックを行うことができるとともに、レシート３１に顧客名を印字することも可能となる。

支払いが完了し、販売者２により「領収書出力」ボタンが押下されると、決済処理部１３が決済管理ＤＢ１８に決済内容を登録するとともに、「支払方法」の内容に応じて、注文された商品４の明細を含むレシート３１もしくは納品書４１を印刷出力する。なお、支払いに伴う現金の授受等の実際の決済処理については、専用のレジ端末を用いることができる。店舗端末１０が当該レジ端末と通信可能で連携することができる構成であってもよい。

なお、図２、図３では、ある顧客３についての注文を受け付けて取引の決済を行う場合の画面例を示しているが、上述したように、販売者２は、同時並行的に複数の顧客３からの注文を受け付けることが求められる。この場合、例えば、全体をタブ画面として、ある顧客３についての図２、図３に示した画面を１つのタブ上に表示することで、顧客３毎にタブを切り替えて同時並行的に入力、処理を行うことができる。

図４は、清算管理部１４により店舗端末１０もしくは他の情報処理端末に表示される決済状況の一覧画面の例について概要を示した図である。決済管理ＤＢ１８などのデータをサーバシステム５０上に保持するような構成の場合は、店舗端末１０以外の他の情報処理端末からネットワーク６０を介してサーバシステム５０にアクセスして当該画面を表示する構成とすることも可能である。

図４の例では、販売者２等の店舗の担当者により指定された顧客コードに基づいて、決済管理ＤＢ１８から対象の顧客３に係る過去の取引の決済状況の情報を取得して一覧表示した場合を示している。例えば、各行の「商品」欄の“詳細”というハイパーリンクを指定することで、対象の取引について取引管理ＤＢ１７から注文内容の情報を取得して、図示しない詳細画面に別途表示させることができる。また、「決済」欄の“未”というハイパーリンクを指定することで、掛払いである対象の取引についての支払がなされた際にこれを支払済みとするよう消し込むことができる。「決済」が未了の取引について、「販売金額」欄の額の一部のみの支払いを受けた場合に、その額を決済管理ＤＢ１８に登録し、「支払金額」欄に表示する一方で、「決済」は未了のままとして管理することも可能である。

なお、図４では、対象の顧客３について決済状況を絞り込んで表示する画面の例を示しているが、絞り込みの切り口はこれに限られない。例えば、図４の画面例に代えて、もしくはこれに加えて、顧客３の単位ではなく全ての顧客３を対象に決済が未了の取引を絞り込んで表示するような画面を設けてもよい。

＜データ構成＞
図５は、顧客マスタＤＢ１５のデータ構成の例について概要を示した図である。顧客マスタＤＢ１５は、対象の販売者２と取引がある顧客３の属性等のマスタ情報を保持するテーブルであり、例えば、顧客コード、顧客名、顧客店舗名、連絡先、掛払い可否、得意先区分、および値引率などの各項目を有する。

顧客コードの項目は、対象の販売者２の店舗等において各顧客３を一意に特定することができるＩＤやコード値などの識別情報を保持する。顧客名、顧客店舗名、および連絡先の各項目は、それぞれ、対象の顧客３の氏名や店舗の名称等の情報、および電話番号や電子メールアドレス等の連絡先の情報を保持する。掛払い可否の項目は、対象の顧客３の支払方法として掛払いを許可しているか否かの区分を示すコード値等の情報を保持する。得意先区分の項目は、対象の顧客３の得意先としての区分を示すコード値等の情報を保持する。得意先の種類（業種・業態など）により区分けしてもよいし、得意先のレベル（もしくは等級やグレード等）により区分けしてもよい。値引率の項目は、対象の顧客３に適用することができる値引率のデフォルト値の情報を保持する。

なお、顧客マスタＤＢ１５に登録される顧客３は、対象の販売者２と取引がある全ての顧客３である必要はなく、継続的な取引がある一定の顧客３のみを対象としてもよい。商品販売支援システム１は、顧客マスタＤＢ１５および後述する商品マスタＤＢ１６へのデータの登録や参照、更新のための図示しないユーザインタフェースを別途有していてもよい。

図６は、商品マスタＤＢ１６のデータ構成の例について概要を示した図である。商品マスタＤＢ１６は、対象の販売者２が店舗等で販売する商品４のマスタ情報を保持するテーブルであり、例えば、商品コード、商品名、標準品名コード、および標準単価などの各項目を有する。

商品コードの項目は、対象の販売者２の店舗等において各商品４を一意に特定することができるＩＤやコード値などの識別情報を保持する。この値は、販売者２が店頭において瞬時に想起し、テンキーパッド２０を介して入力することができるよう、３桁以下程度の数値により構成する。商品名の項目は、対象の商品４の表示名の情報を保持する。標準品名コードの項目は、対象の商品４に対応する標準品名コード（農林水産省により生鮮品のＥＤＩ（Electronic Data Interchange）取引用の標準コードとして定義されているコード）の値を保持する。これにより、販売者２は、商品コードさえ知っていれば、規格化された正規の標準品名コードの値を知らなくても商品４を特定することができる。

標準単価の項目は、対象の商品４に対して設定された標準の単価（デフォルト値）の情報を保持する。上述したように、本実施の形態では、商品４の注文を受けた際に、販売者２がその都度単価を指定するものとしているが、著しく不当な単価を設定してしまうことがないよう、市場価格や浜値などに基づいて設定されるデフォルト値を設けておき、図２に示した入力受付画面に表示するようにしてもよい。標準単価の値は、例えば、日毎に異なる値が設定されるようにしてもよい。

図７は、取引管理ＤＢ１７のデータ構成の例について概要を示した図である。取引管理ＤＢ１７は、対象の販売者２の店舗等において顧客３との間で成立した取引（注文）の内容に係る情報を保持するテーブルであり、例えば、取引番号、取引日時、顧客コード、取引金額、注文商品コード、注文商品単価、および注文商品数量などの各項目を有する。

取引番号の項目は、対象の取引を一意に特定することができるシーケンス番号などの情報を保持する。取引日時の項目は、取引が成立した日時を示すタイムスタンプの情報を保持する。例えば、図２の画面例の「確認」ボタンや、図３の画面例の「領収書出力」ボタンが押下された時点のタイムスタンプを自動的に設定することができる。顧客コードの項目は、対象の取引に係る顧客３を特定する顧客コードの値を保持する。この値は、図５に示した顧客マスタＤＢ１５に登録されている。取引金額の項目は、対象の取引における商品４の合計金額（すなわち販売者２と顧客３との間の決済金額）の情報を保持する。

注文商品コード、注文商品単価、および注文商品数量の各項目は、それぞれ、対象の取引において販売される商品４を特定する商品コード、対象の商品４に対して設定された単価、および販売される数量の情報を保持する。商品コードの値は、図６に示した商品マスタＤＢ１６に登録されている。なお、これらの各項目は、対象の取引において販売される商品４が複数ある場合は、商品４毎に複数レコードに渡って設定されるようにしてもよい。

図８は、決済管理ＤＢ１８のデータ構成の例について概要を示した図である。決済管理ＤＢ１８は、対象の販売者２の店舗等において顧客３との間で成立した取引（注文）についての決済状況に係る情報を保持するテーブルであり、例えば、取引番号、支払日時、支払金額、支払方法、および決済完了区分などの各項目を有する。

取引番号の項目は、対象の取引を特定する取引番号の情報を保持する。この値は、図７に示した取引管理ＤＢ１７に登録されている。支払日時、支払金額、および支払方法の各項目は、それぞれ、対象の取引について顧客３が支払いを行った日時を示すタイムスタンプの情報、顧客３が支払った金額の情報、および支払方法・支払手段の種別を示すコード値等の情報を保持する。これらの情報は、例えば、店舗端末１０と通信により連携することができる専用のレジ端末において入金処理が行われた際に、その時点のタイムスタンプや入金金額等を自動的に取得して設定することができる。店舗端末１０が表示する画面から販売者２が手動で入力してもよい。

決済完了区分の項目は、対象の取引について全ての決済が完了したか否かを示すコード値等の情報を保持する。購入時もしくは月末等の一括払いの場合は支払いがあった際に決済が完了となるが、掛払い・ツケ払いの場合には、一部の支払いがあった場合でも全額の支払いがあるまで決済は未了として管理する。

なお、上述の図５〜図８で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

以上に説明したように、本発明の一実施の形態である商品販売支援システム１によれば、販売者２が使用する店舗端末１０をタブレット型端末とし、注文内容を入力するインタフェースとして、外付けのテンキーパッド２０を用いることで、テンキー操作のみでの簡易な入力が可能である。これにより、水や泥などがある上に、複数の顧客３からの同時並行的な注文にも対応する必要がある過酷な使用環境においても、販売業務の効率化を支援することが可能である。また、鮮魚等のように、単価を予め定めておくことができない（もしくは妥当ではない）ような商品４の販売において、販売業務の効率化を支援することが可能である。

さらに、顧客３毎に得意先としての各種属性情報を管理するとともに、各取引の決済・清算の状況を管理することで、取引・販売の状況を適切に管理することが可能である。これにより、鮮魚等の販売など、販売や決済の際に得意先に応じた属人的な個別の取扱いが必要となる領域においても販売業務を支援することが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

例えば、上述した本実施の形態では、鮮魚等の販売を行う場合を対象として説明したが、販売対象の商品４はこれに限らず、農産品や畜産品など他の第一次産業での生産品の販売などにも適用することができる。

本発明は、水産物や農産物など販売単価が不定である物品の販売を支援する商品販売支援システムおよび商品販売支援プログラムに利用可能である。

１…商品販売支援システム、２…販売者、３…顧客、４…商品、５…レジ担当者、
１０…店舗端末、１１…販売集計部、１２…販売チェック部、１３…決済処理部、１４…清算管理部、１５…顧客マスタＤＢ、１６…商品マスタＤＢ、１７…取引管理ＤＢ、１８…決済管理ＤＢ、
２０…テンキーパッド、
３０…レシートプリンタ、３１…レシート、
４０…納品書プリンタ、４１…納品書、
５０…サーバシステム、
６０…ネットワーク、
７０…レジ

Claims (9)

1. 商品の販売業務を支援する商品販売支援システムであって、
   顧客からの注文内容についての販売者からの入力を受け付ける情報処理端末を有し、
   前記情報処理端末は、
   入力装置としてのテンキーパッドと、
   前記販売者による前記テンキーパッドの操作を介して、前記顧客の注文に係る１つ以上の商品のそれぞれについて、前記各商品を特定する１つ以上の数字からなる商品コード、および量と単価の数値の入力を受け付けて記録し、前記商品コードに対応する商品名および前記量と前記単価とから算出した販売金額の情報を前記情報処理端末の画面上に表示する販売集計部と、を有する、商品販売支援システム。
2. 請求項１に記載の商品販売支援システムにおいて、
   前記販売集計部は、さらに前記顧客に適用される値引率の数値の入力を受け付けて記録し、前記量と前記単価と前記値引率とから前記販売金額を算出する、商品販売支援システム。
3. 請求項１に記載の商品販売支援システムにおいて、
   前記販売集計部は、複数の前記顧客からの注文に係る情報の入力を並行的に受け付けることができる、商品販売支援システム。
4. 請求項１に記載の商品販売支援システムにおいて、
   さらに、前記販売者による前記テンキーパッドの操作を介して、前記顧客からの１つ以上の注文からなる取引について、現金払いか掛払いかの支払方法の指定を受け付けて記録する決済処理部を有する、商品販売支援システム。
5. 請求項４に記載の商品販売支援システムにおいて、
   さらに、各取引についての決済状況を管理し、支払方法として掛払いが指定された取引について支払いがされた場合にその旨を記録する清算管理部を有する、商品販売支援システム。
6. 請求項１に記載の商品販売支援システムにおいて、
   さらに、前記販売者により入力された前記単価が市場価格から所定の値以上乖離している場合にその旨を前記販売者に対して通知する販売チェック部を有する、商品販売支援システム。
7. 請求項２に記載の商品販売支援システムにおいて、
   さらに、前記販売者により入力された前記値引率が対象の前記顧客に対して予め定められた所定の値から所定の値以上乖離している場合にその旨を前記販売者に対して通知する販売チェック部を有する、商品販売支援システム。
8. 請求項１に記載の商品販売支援システムにおいて、
   さらに、対象の前記顧客からの注文の内容が、対象の前記顧客の属性に基づいて想定される取引の内容、および／または対象の前記顧客の過去の取引の傾向と所定の程度以上乖離している場合にその旨を前記販売者に対して通知する販売チェック部を有する、商品販売支援システム。
9. 商品の販売業務を支援する商品販売支援システムとして機能するよう、顧客からの注文内容についての販売者からの入力を受け付ける情報処理端末に処理を実行させる商品販売支援プログラムであって、
   前記販売者による、前記情報処理端末が入力装置として有するテンキーパッドの操作を介して、前記顧客の注文に係る１つ以上の商品のそれぞれについて、前記各商品を特定する１つ以上の数字からなる商品コード、および量と単価の数値の入力を受け付けて記録し、前記商品コードに対応する商品名および前記量と前記単価とから算出した販売金額の情報を前記情報処理端末の画面上に表示する販売集計処理を実行させる、商品販売支援プログラム。