(57)【要約】【課題】商品の重量を考慮して、商品出荷の予実差異日数に応じた値引きを行うことの可能な仕組みを提供すること。【解決手段】商品の出荷予定日と当該商品が出荷された日との差異日数と当該商品の重量とに応じて値引き率を決定するための値引き情報を記憶しておく。そして商品の出荷予定日を少なくとも含む、商品の注文を受け付けて、受注した商品の出荷予定日と、受注した商品が出荷された日との差異日数を算出する。記憶された値引き情報を用いて、算出された差異日数と、受注した商品の重量とに応じて値引き率を決定する。【選択図】図６
2018018434.tif 000002
【特許請求の範囲】
【請求項１】
商品の出荷予定日と当該商品が出荷された日との差異日数と当該商品の重量とに応じて値引き率を決定するための値引き情報を記憶する記憶手段と、
商品の出荷予定日を少なくとも含む、当該商品の注文を受け付ける受注手段と、
前記受注手段で受注した商品の出荷予定日と、前記受注手段で受注した商品が出荷された日との差異日数を算出する差異算出手段と、
前記記憶手段に記憶された値引き情報を用いて、前記差異算出手段で算出された差異日数と、前記受注手段で受注した商品の重量とに応じて値引き率を決定する決定手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受注手段で受注した商品の請求額を、前記決定手段で決定された値引き率を用いて算出する請求額算出手段
を更に備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記決定手段は、前記差異算出手段で用いた出荷予定日が登録された日と現在の日との差に応じて決定される係数を更に用いて、値引き率を決定することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記決定手段は、前記差異算出手段で用いた出荷予定日が登録された日が複数存在する場合には、それぞれの日に対応する係数を用いて値引き率を算出し、高い値引き率を最終的な値引き率として決定することを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記決定手段は、前記差異算出手段で用いた出荷予定日が登録された日が複数存在し、かつ前記差異算出手段でそれぞれの出荷予定日を用いて算出された差異日数が、出荷された日に当該登録された日が近づくにつれて大きくなってしまった場合には、当該差異日数が大きくなる前の出荷予定日を用いて決定された値引き率は採用しないことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
【請求項６】
前記値引き情報は、前記差異日数が大きい場合よりも小さい場合の方が、値引き率が高くなる情報であり、かつ前記重量が軽い場合よりも重い場合の方が、値引き率が高くなる情報であることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
【請求項７】
商品の出荷予定日と当該商品が出荷された日との差異日数と当該商品の重量とに応じて値引き率を決定するための値引き情報を記憶する記憶手段を備える情報処理装置の制御方法であって、
前記情報処理装置の受注手段が、商品の出荷予定日を少なくとも含む、当該商品の注文を受け付ける受注ステップと、
前記情報処理装置の差異算出手段が、前記受注ステップで受注した商品の出荷予定日と、前記受注ステップで受注した商品が出荷された日との差異日数を算出する差異算出ステップと、
前記情報処理装置の決定手段が、前記記憶手段に記憶された値引き情報を用いて、前記差異算出ステップで算出された差異日数と、前記受注ステップで受注した商品の重量とに応じて値引き率を決定する決定ステップと
を備えることを特徴とする情報処理装置の制御方法。
【請求項８】
商品の出荷予定日と当該商品が出荷された日との差異日数と当該商品の重量とに応じて値引き率を決定するための値引き情報を記憶する記憶手段を備える情報処理装置の制御方法を実行可能なプログラムであって、
前記情報処理装置を、
商品の出荷予定日を少なくとも含む、当該商品の注文を受け付ける受注手段と、
前記受注手段で受注した商品の出荷予定日と、前記受注手段で受注した商品が出荷された日との差異日数を算出する差異算出手段と、
前記記憶手段に記憶された値引き情報を用いて、前記差異算出手段で算出された差異日数と、前記受注手段で受注した商品の重量とに応じて値引き率を決定する決定手段
として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
商品の重量を考慮して、商品出荷の予実差異日数に応じた値引きを行うことの可能な情報処理装置、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
商品を販売するにあたり予定していた出荷予定の日（以下、出荷予定日という。）と、実際に出荷される日（以下、出荷日という。）には様々な理由により差が発生する。この差が大きくなれば生産計画へ悪影響を及ぼす。また、出荷日が遅くなると在庫数が増えるので、それによって商品の置場所を確保するための経費が掛かるなどの問題が発生する。
【０００３】
そこで、特許文献１には、購入予約時の購入予定日と実際に商品を受け取りに来た日との差によって値引き額の設定を行う仕組みが開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−２８１４２１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
特許文献１では、適正な在庫管理を行うために購入予約時の購入予定の日と実際に商品を受け取りに来た日の差に着目し、その日数の差が大きくなれば購入予約した時点の商品の価格の割引率を自動的に引き下げていく仕組みである。
【０００６】
つまり、一般消費者が行う商品の購入予約と予約した商品を実際に店に受け取りに行くという事と在庫の適正管理に着目して、この日の差に則って割引率の変更を行うものです。
【０００７】
しかしながら、製造業の場合は、出荷予定日と実際に在庫が出る出荷日という関係は、在庫の適正管理という点だけではなく、生産計画や輸送するトラック手配などに影響する。特に、製造業が扱う商品は重量が大きいものが多く、倉庫内での移動やトラックへの積み込みに大変な労力と時間がかかる。よって、予定通りに出荷されないと販売側の作業現場が混乱してしまう可能性がある。
【０００８】
本発明の目的は、商品の重量を考慮して、商品出荷の予実差異日数に応じた値引きを行うことの可能な仕組みを提供することである。
【課題を解決するための手段】
【０００９】
上記の目的を達成するために本発明の情報処理装置は、商品の出荷予定日と当該商品が出荷された日との差異日数と当該商品の重量とに応じて値引き率または値引き額を決定するための値引き情報を記憶する記憶手段と、商品の出荷予定日を少なくとも含む、当該商品の注文を受け付ける受注手段と、前記受注手段で受注した商品の出荷予定日と、前記受注手段で受注した商品が出荷された日との差異日数を算出する差異算出手段と、前記記憶手段に記憶された値引き情報を用いて、前記差異算出手段で算出された差異日数と、前記受注手段で受注した商品の重量とに応じて値引き率または値引き額を決定する決定手段と、前記受注手段で受注した商品の請求額を、前記決定手段で決定された値引き率または値引き額を用いて算出する請求額算出手段とを備えることを特徴とする。
【発明の効果】
【００１０】
本発明によれば、商品の重量を考慮して、商品出荷の予実差異日数に応じた値引きを行うことが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態におけるシステム構成、及び機能構成の一例を示す図である。
【図２】サーバ１及び端末２のハードウェア構成の一例を示す図である。
【図３】商品の受注処理の流れの一例を示すフローチャートである。
【図４】出荷予定日を変更する処理の流れの一例を示すフローチャートである。
【図５】商品の出荷処理の流れの一例を示すフローチャートである。
【図６】値引き率を反映した単価を計算する処理の流れの一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１３】
図１は、本実施形態におけるシステム構成及び機能構成の一例を示す図である。本実施形態おける情報処理システムは、１又は複数の端末２に入力された各種内容を基に、ネットワーク３を介してサーバ１の受注管理部４、出荷予定日管理部５、出荷管理部６を呼び出し、ＤＢ７のデータの参照、追加、更新を行うものである。そのため、サーバ１と端末２とは、ＬＡＮやインターネット等のネットワーク３を介して、相互にデータ通信可能に接続されている。
【００１４】
サーバ１（情報処理装置）は、受注管理部４、出荷予定日管理部５、出荷管理部６、ＤＢ７を備える装置である。ＤＢ７は更に、商品ＤＢ８、受注内容ＤＢ９、出荷予定日変更履歴ＤＢ１０、値引き率選択用ＤＢ１１（値引き情報）、値引き係数ＤＢ１２を備える。尚、これらの機能部の構成はあくまで一例であり、これに限られるものではない。また、各ＤＢ（データベース）の説明は後述する。
【００１５】
受注管理部４は、端末２に表示された受注入力画面より入力された情報と商品ＤＢ８を参照し得た情報で受注内容ＤＢ９へデータを追加すると共に、出荷予定日変更履歴ＤＢ１０にデータ追加する機能部である。
【００１６】
出荷予定日管理部５は、端末２から入力された情報を基に受注内容ＤＢ９を参照して出荷予定日変更画面を表示し、その画面に入力された変更後の出荷予定日で受注内容ＤＢ９のデータ更新を行うと共に、出荷予定日変更履歴ＤＢ１０にデータを追加する。何度も出荷予定日を変更した場合には、この出荷予定日変更履歴ＤＢ１０にはデータが複数存在することになる。
【００１７】
出荷管理部６は、端末２から入力された情報を基に、受注内容ＤＢ９を参照し出荷画面を表示し、登録ボタンが押された場合に実際の出荷日と出荷予定日変更履歴ＤＢ１０、値引き率選択用ＤＢ１１、値引き係数ＤＢ１２などを用いて最終単価を算出する。そして、その内容を受注内容ＤＢ９に更新する。
【００１８】
端末２は、汎用コンピュータであり、サーバ１に対する指示を行うための装置である。そのため、パーソナルコンピュータであってもよいし、携帯端末であってもよい。
【００１９】
図２は、サーバ１及び端末２のハードウェア構成の一例を示す図である。
【００２０】
ＣＰＵ２１は、システムバス２４に接続される各デバイスやコントローラを統括的に制御する。
【００２１】
また、ＲＯＭ２２あるいは外部メモリ３１には、ＣＰＵ２１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳという。）が記憶されている。また外部メモリ３１には、各種装置の実行する機能を実現するために必要な各種プログラム等が記憶されている。ＲＡＭ２３は、ＣＰＵ２１の主メモリ、ワークエリア等として機能する。
【００２２】
ＣＰＵ２１は、処理の実行に際して必要なプログラム等をＲＡＭ２３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２３】
また、入力コントローラ２５は、キーボードやマウス等のポインティングデバイスといった入力デバイス２９からの入力を制御する。
【００２４】
ビデオコントローラ２６は、ディスプレイ３０等の表示器への表示を制御する。表示器はＣＲＴや液晶ディスプレイでも構わない。
【００２５】
メモリコントローラ２７は、ハードディスクやフレキシブルディスク或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ３１へのアクセスを制御する。外部メモリ３１（記憶手段）は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶する。
【００２６】
通信Ｉ／Ｆコントローラ２８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００２７】
尚、ＣＰＵ２１は、例えばＲＡＭ２３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ３０上での表示を可能としている。また、ＣＰＵ２１は、ディスプレイ３０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００２８】
本発明の各種装置が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ３１に記録されており、必要に応じてＲＡＭ２３にロードされることによりＣＰＵ２１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ３１に格納されている。
【００２９】
次に、フローチャートを用いて上記実施形態の各処理について説明する。図３は、商品の受注処理の流れの一例を示すフローチャートである。
【００３０】
ステップＳ１０１では、サーバ１の受注管理部４は、受注入力を行うための受注入力画面を生成し、端末２に送信する。そして端末２は、受信した受注入力画面をディスプレイ３０に表示する。受注入力画面は、図３の１０２に示すような画面である。
【００３１】
ステップＳ１０２では、端末２は、表示された受注入力画面に顧客コード、注文番号、商品コード、出荷予定日、個数等の情報の入力を受け付ける。そして、入力を受け付けた商品コードをサーバ１に送信しておく。
【００３２】
ステップＳ１０３では、サーバ１の受注管理部４は、端末２での受注入力画面に入力された商品コードから商品ＤＢ８を読み込み、その商品コードに対応する商品名と単価と単重（１商品あたりの重量）とを取得する。商品ＤＢ８の構成は１０１に示す。商品ごとにレコードが設けられ、各商品の商品コード、商品名、単価、単重が格納されている。そして、これらを端末２に送信する。
【００３３】
ステップＳ１０４では、端末２は、サーバ１から受信した商品名、単価を受注入力画面に表示すると共に、ステップＳ１０２で入力された個数とサーバ１から受信した単重とを乗算し、重量（総重量）を表示する。
【００３４】
ステップＳ１０５では、端末２は、受注入力画面が備える登録ボタンが押下されたか否かを判定し、登録ボタンが押下されたと判定した場合には、ステップＳ１０６に処理を進める。そうでない場合には、登録ボタンが押下されるまで待機する。
【００３５】
ステップＳ１０６では、端末２は、受注入力画面に入力された内容をサーバ１に送信する。そして、これを受信したサーバ１の受注管理部４は、受注内容ＤＢ９に新たにレコードを作成し、ここに受注入力画面に入力された各種内容を登録する（受注手段）。こうしてできあがった受注内容ＤＢ９の一例が１０３である。一例として、受注登録時の出荷予定日が“２０１６年８月１２日”としている。また、受注管理部４は、出荷予定日変更履歴ＤＢ１０にレコードを作成し、現在の年月日を記録日に格納すると共に、受注のあった注文番号、出荷予定日をそれぞれ格納する。こうしてできあがった出荷予定日変更履歴ＤＢ１０の一例が１０４である。このように受け付けた出荷予定日の履歴を管理していく。
【００３６】
図４は、出荷予定日を変更する処理の流れの一例を示すフローチャートである。以下の説明では一例として、出荷予定日を２回変更する場合について説明する。まずは、図４の２００１に示すような１回目の変更を例に説明する。
【００３７】
ステップＳ２０１では、サーバ１の出荷予定日管理部５は、出荷予定日変更画面を生成し、これを端末２に送信する。端末２は出荷予定日変更画面を受信するとこれをディスプレイ３０に表示する。出荷予定日変更画面は、図４の２０２に示すような画面である。
【００３８】
ステップＳ２０２では、端末２は、出荷予定日変更画面に対する入力を受け付ける。ここで入力される内容は、受注入力画面に表示されていた注文番号である。端末２は、注文番号の入力を受け付けると、これをサーバ１に送信する。
【００３９】
ステップＳ２０３では、サーバ１の出荷予定日管理部５は、受信した注文番号で受注内容ＤＢ９を読み込み、当該注文番号を含むレコードを読み込む。図４の２０１は、注文を受け付けた際の受注内容である。まずはこれを読み込む。そして、読み込んだ受注内容を端末２に送信する。
【００４０】
ステップＳ２０４では、端末２は、サーバ１から送信された受注内容を受信し、これを出荷予定日変更画面に表示する。こうして表示された結果が２０２である。
【００４１】
ステップＳ２０５では、端末２は、ステップＳ２０４で表示された出荷予定日変更画面に対する、変更後の出荷予定日の入力を受け付ける。１回目の変更で、注文を受け付けた際の出荷予定日である“２０１６年８月１２日”から“２０１６年８月１９日”に変更されたとすると、出荷予定日変更画面は図４の２０３に示すような画面となる。
【００４２】
ステップＳ２０６では、端末２は、出荷予定日変更画面で登録ボタンが押下されたか否かを判定する。登録ボタンが押下されたと判定した場合には、ステップＳ２０７に処理を進める。そうでない場合には、登録ボタンが押下されるまで待機する。
【００４３】
ステップＳ２０７では、端末２は、出荷予定日変更画面に入力された、変更後の出荷予定日をサーバ１に送信する。サーバ１の出荷予定日管理部５はこれを受信すると、ステップＳ２０２で入力を受け付けた注文番号に対応する受注内容ＤＢ９の出荷予定日を、受信した変更後の出荷予定日で更新する。また、出荷予定日変更履歴ＤＢ１０に新たなレコードを作成し、処理当日の年月日を記録日とし、更にステップＳ２０２で入力を受け付けた注文番号と、変更後の出荷予定日を格納する。このようにして更新された受注内容ＤＢ９が２０４、出荷予定日変更履歴ＤＢ１０が２０５である。
【００４４】
次に２回目の出荷予定日の変更が行われた場合について説明する。出荷予定日の変更は何度も行うことが可能であるので、その都度、図４のフローチャートに示す一連の処理が実行される。そのため、処理の内容は前述した通りであるので、詳細な説明は省略する。
【００４５】
図４の２００２が２回目の変更で用いられるＤＢや画面例である。１回目の変更で出荷予定日が“２０１６年８月１９日”に変更された。これを更に変更する場合には、受注内容ＤＢ９（図４の２１１）を参照して出荷予定日変更画面（図４の２１２）を再度生成する。そして、これを端末２に表示して、変更後の出荷予定日（“２０１６年８月１０日”）の入力を受け付ける。入力を受け付けて（図４の２１３）、登録ボタンが押下されると、入力された出荷予定日を端末２からサーバ１に送信する。そしてサーバ１の出荷予定日管理部５は、受信した出荷予定日で受注内容ＤＢ９を更新し（図４の２１４）、更に出荷予定日変更履歴ＤＢ１０の新たなレコードに出荷予定日の変更履歴を残す（図４の２１５）。
【００４６】
このようにして、受注したときから出荷予定日に変更があった場合には、都度、その変更後の出荷予定日を登録していくと共に、その変更履歴を登録する。
【００４７】
図５は、商品の出荷処理の流れの一例を示すフローチャートである。
【００４８】
ステップＳ３０１では、サーバ１の出荷管理部６は、出荷画面を生成し端末２に送信する。端末２は、サーバ１から出荷画面を受信するとこれをディスプレイ３０に表示する。出荷画面は、図４の３０２に示すような画面である。
【００４９】
ステップＳ３０２では、端末２は、ステップＳ３０１で表示された出荷画面に対する注文番号の入力を受け付ける。ここでユーザは、出荷を行う対象の注文番号の入力を行う。
【００５０】
ステップＳ３０３では、端末２は、入力を受け付けた注文番号をサーバ１に送信する。そして、サーバ１は受信した注文番号で受注内容ＤＢ９を読み込み、対象の受注内容を読み込む。図５でいう３０１が読み込む対象の受注内容である。最終的には、出荷予定日が“２０１６年８月１０日”になっている。
【００５１】
ステップＳ３０４では、サーバ１は、出荷する商品の単価を算出する処理を実行する。この処理の詳細を図６に示す。
【００５２】
図６は、値引き率を反映した単価を計算する処理の流れの一例を示すフローチャートである。この一連の処理により、出荷される量と実際の出荷日がいつ決定されたかによって値引き率を決定する。
【００５３】
ステップＳ４００では、サーバ１の出荷管理部６は、前差異日数と最終値引き率という２つのパラメータを初期化（クリア）する。これら２つのパラメータが存在しない場合には、新たに生成する。
【００５４】
ステップＳ４０１では、サーバ１の出荷管理部６は、現在の年月日を実出荷日として取得すると共に、出荷画面に表示した注文番号と重量とを受注内容ＤＢ９から取得する。
【００５５】
ステップＳ４０２では、サーバ１の出荷管理部６は、値引き係数ＤＢ１２を読み込む。値引き係数ＤＢ１２は、何日前に出荷日が決まったかによってその前日数と値引き率を保持しているＤＢである。図６の４０１に、値引き係数ＤＢ１２の一例を示す。例えば、実出荷日の“１０日前”であれば係数として“０．２”を採用し、“２０日前”であれば係数として“０．５”を採用することを示している。このように、前日数が大きければ大きいほど、係数が大きくなるように設定することが望ましい。
【００５６】
ステップＳ４０３では、サーバ１の出荷管理部６は、値引き係数ＤＢ１２の実出荷日の前日数が大きい値から順に参照対象とし（以下、参照対象の前日数という。）、ステップＳ４０３乃至ステップＳ４１３の処理を実行する。また、繰り返しの間、該当する値引き率係数を保持するものとする。図６に示す例の場合、前日数が最も大きいものは“５０日”であるので、“５０日”を参照対象として処理を始め、降順で参照対象とする。
【００５７】
ステップＳ４０４では、サーバ１の出荷管理部６は、Ｓ４０１で取得した注文番号を有し、かつＳ４０１で取得した実出荷日から、参照対象の前日数を減算した年月日以前で、直近の記録日を保持するレコードを出荷予定日変更履歴ＤＢから読み込む。例えば、実出荷日が“２０１６年８月１４日”であり、参照対象の前日数が“５０日”だった場合、「実出荷日−５０日＝２０１６年６月２５日」となる。つまり、Ｓ４０１で取得した注文番号を有し、この年月日以前で直近の記録日を保持するレコードを出荷予定日変更履歴ＤＢから読み込む。
【００５８】
ステップＳ４０５では、サーバ１の出荷管理部６は、ステップＳ４０４でレコードの読み込みに成功したか否かを判定する。すなわち、読み込み対象となる条件を満たすレコードが存在するか否かを判定する。存在すると判定した場合には、ステップＳ４０６に処理を進める。存在しないと判定した場合には、ステップＳ４０３に処理を戻して、次の実出荷日の前日数を参照対象とする。
【００５９】
ステップＳ４０４で用いた例では、Ｓ４０１で取得した注文番号を有し、かつ記録日が“２０１６年６月２５日”より以前で直近の記録日を有するものは、図６の４０２には存在しない。そのため、ステップＳ４０５ではこうしたものは存在しないと判定される。一方、参照対象の前日数が“３０日”の場合には、実出荷日の“２０１６年８月１４日”の３０日前が“２０１６年７月１５日”となるので、記録日にちょうど“２０１６年７月１５日”というデータを有するレコードが存在する。よって、存在すると判定される。
【００６０】
ステップＳ４０６では、サーバ１の出荷管理部６は、ステップＳ４０４で読み込んだ履歴の出荷予定日から実出荷日を減算し、その差異日数を算出する（差異算出手段）。参照対象の前日数が“３０日”の場合には、ステップＳ４０４で読み込んだレコードの出荷予定日は“２０１６年８月１２日”である。ここから実出荷日である“２０１６年８月１４日”であるので、減算すると“−２”という差異日数が取得できる。つまり、“２０１６年７月１５日”における出荷予定日よりも２日早く出荷したということがわかる。図６の４０３は、こうして算出した差異日数の結果を一覧形式にまとめたものである。
【００６１】
ステップＳ４０７では、サーバ１の出荷管理部６は、ステップＳ４０６で算出した差異日数の絶対値が、１つ前の繰り返し処理において算出された差異日数（後述するＳ４０８またはＳ４１２で保持する前差異日数）の絶対値よりも小さいか否かを判定する。小さいと判定された場合には、ステップＳ４０８に処理を進め、大きいと判定された場合には、ステップＳ４１２に処理を進める。
【００６２】
例えば、現在、参照対象の前日数が“２０日”の場合、４０３の一覧に従うと、差異日数は“５”であるので、この絶対値は“５”となる。一方、前日数が“２０日”の１つ前である“３０日”が参照対象の前日数だったときの差異日数は、４０３の一覧に従うと、“−２”である。よって絶対値は“２”となる。この２つを比較すると、ステップＳ４０６で算出した差異日数の絶対値が、１つ前の繰り返し処理において算出された差異日数の絶対値よりも大きいので、ステップＳ４１２に処理を進めることになる。
【００６３】
ステップＳ４０８では、サーバ１の出荷管理部６は、ステップＳ４０６で算出した差異日数を、次の繰り返し処理のために前差異日数として保持する。
【００６４】
ステップＳ４０９では、サーバ１の出荷管理部６は、値引き率選択用ＤＢ１１を読み込み、算出した差異日数を示す出荷予実差異日数とステップＳ４０１で取得した重量とに対応する値引き率を取得する（決定手段）。また、参照対象の前日数に対応する係数を値引き係数ＤＢ１２から取得する。そして、取得した値引き率と係数とを乗算し、値引き率を決定する。値引き係数ＤＢ１２は、出荷予実差異が小さければ小さいほど、値引き率が高くなるように設定することが望ましい。更に、重量が重ければ重いほど、値引き率が高くなるように設定することが望ましい。すなわち、出荷予実差異が大きい場合よりも小さい場合の方が、値引き率が高くなり、かつ重量が軽い場合よりも重い場合の方が、値引き率が高くなるということである。
【００６５】
例えば、参照対象の前日数が“２０日”の場合、差異日数が“５日”である。また、注文を受けた商品の重量が“１０００ｋｇ”であった場合には、値引き率選択用ＤＢ１１から“８％”という値が取得できる。更に、この“８％”に“２０日”の係数である“０．５”を乗算すると、“４％”となる。よって、この“４％”を値引き率とする。このように、出荷予定日と出荷日との差異日数と、出荷する商品の重量とを用いて値引き率が決定できるので、なるべく出荷予定日通りに出荷指示をするよう、顧客を促すことが可能となる上、出荷側の作業負担を軽減することが可能となる。また、何日も前から正確な出荷予定日を申請している顧客については、高い係数を採用することができるので、高い値引き率とすることができ、計画的な注文を促すことが可能となる。
【００６６】
尚、本実施形態では値引き率を値引き率選択用ＤＢ１１から取得したが、値引き率選択用ＤＢ１１を値引き額選択用ＤＢとして、値引き額を取得するような形態であってもよい。この場合、取得した値引き額と係数とを乗算して、最終的な値引き額を算出する。また、「１００％−値引き率」を求めた割合を格納しておいてもよい。この場合には、後述する値引き単価は、単価にこの割合を乗算したものとなる。
【００６７】
ステップＳ４１０では、サーバ１の出荷管理部６は、現在保持している最終値引き率よりも、今回算出した値引き率の方が大きいか否かを判定する。大きいと判定された場合には、ステップＳ４１１に処理を進める。そうでない場合には、ステップＳ４０３に処理を戻し、ステップＳ４０３に処理を戻して、次の実出荷日の前日数を参照対象とする。
【００６８】
ステップＳ４１１では、サーバ１の出荷管理部６は、ステップＳ４０９で算出した値引き率を最終値引き率として保持する。
【００６９】
一方、ステップＳ４１２では、サーバ１の出荷管理部６は、ステップＳ４０６で算出した差異日数を、次の繰り返し処理のために前差異日数として保持する。そして、ステップＳ４１３では、サーバ１の出荷管理部６は、保持している最終値引き率を初期化（クリア）する。ステップＳ４０７で、算出した差異日数の絶対値が、前差異日数の絶対値よりも大きいと判定されたということは、出荷予定日を変更した日が出荷予定日に近づいているにも関わらず、実出荷日との差異が広がってしまったということである。こうした計画性のない顧客に対しては、ペナルティとして最終値引き率を初期化する。このようにして、正確な出荷予定日を申請するよう促す。
【００７０】
以上のような各処理を前日数ごとに繰り返し実行し、最後に保持していた最終値引き率を今回出荷する商品の値引き率として決定する。
【００７１】
図５に説明を戻す。ステップＳ３０４で値引き率が決定したら、ステップＳ３０５では、サーバ１の出荷管理部６は、端末２に決定した値引き率を送信する。これを受信した端末２は、出荷画面に受注内容を表示する。更に、受注内容に含まれる単価に対して値引き率を乗算し、この結果を単価から差し引くことで算出された値引き単価を表示する。値引き単価はサーバ１であらかじめ計算したものを端末２に送信してもよいし、端末２で計算してもよい（請求額算出手段）。このようにして表示された出荷画面が図５の３０２である。
【００７２】
ステップＳ３０６では、端末２は、出荷画面の登録ボタンが押下されたか否かを判定する。登録ボタンが押下されたと判定した場合には、ステップＳ３０７に処理を進める。そうでない場合には、登録ボタンが押下されるまで待機する。
【００７３】
ステップＳ３０７では、端末２は、出荷画面に表示された出荷内容で確定する旨の通知をサーバ１に送信する。サーバ１はこれを受信すると、受注内容ＤＢ９の単価を値引き単価に変更し、出荷区分を“出荷済み”に変更する。そして、この受注内容ＤＢ９に格納された情報を基に、商品の出荷先の顧客に対して料金の請求を行う。すなわち、受注内容ＤＢ９の受注内容として格納されている単価と個数を乗算した料金を請求する。
【００７４】
尚、本実施形態では値引き単価を算出したが、単価と個数を乗算した料金に対して値引き率を乗算し、当該料金から、乗算した結果を差し引くことで請求額を算出してもよい。
【００７５】
以上説明したように、本実施形態によれば、商品の重量を考慮して、商品出荷の予実差異日数に応じた値引きを行うことが可能となる。
【００７６】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【００７７】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【００７８】
したがって、本発明の機能処理をコンピュータで実現（実行可能と）するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００７９】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【００８０】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【００８１】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【００８２】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００８３】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００８４】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【００８５】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【００８６】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００８７】
１  サーバ
２  端末
【図１】
2018018434.tif 000003
【図２】
2018018434.tif 000004
【図３】
2018018434.tif 000005
【図４】
2018018434.tif 000006
【図５】
2018018434.tif 000007
【図６】
2018018434.tif 000008