JP4306455B2 - 注文受付装置、及び注文受付方法 - Google Patents

Description

本発明は、注文に関する情報である注文情報を受け付ける注文受付装置等に関する。

従来、通信回線を介した商品の受注を行う場合において、受注処理の前に注文元の与信限度額（例えば、売掛債権限度額）に関する確認を行い、与信超過である場合（例えば、売掛債権額が売掛債権限度額を超えている場合）には、受注処理を行わないシステムが開発されている（例えば、特許文献１参照）。
特開２００２−７８１６号公報（第７頁−第１１頁、第１図等）

しかしながら、このような従来のシステムでは、売掛債権の債権額や、売掛金の状態を、例えば、所定のしきい値と売掛金とを比較することによって一律に判断し、その判断結果に基づいて一律に受注処理を行わないこととなり、注文元（例えば、販売店等）の心証を著しく害する場合もあり得る。例えば、信用のある大口の注文元が通信回線を介して直接、注文を行っている場合（オペレータを介さないで注文を行っている場合）に、売掛債権の状態が適切ではないので注文することができない旨を受け取ったとすると、注文元によっては、気分を害した結果、その後の取引を行わないようになる場合も考えられる。このように、従来のシステムでは、注文元との良好な関係を保つことができなくなる恐れがあった。

また、売掛債権等の状態は時系列的に変化し得るものであり、注文の受付時には売掛債権等の状態が良好であったとしても、実際に出荷する時点では、売掛債権等の状態が悪化している場合もあり得る。しかしながら、従来のシステムでは、そのような時系列的に変化し得る債権の状態に対応することができず、場合によっては、出荷時点で売掛債権の状態が悪化しているにもかかわらず、出荷がなされてしまう可能性があった。

本発明は、上記問題点を解決するためになされたものであり、その１つの目的は、注文元の心証を害することなく、債権の状態に応じた受注処理を行う注文受付装置等を提供することである。
また、他の目的は、時系列的に変化し得る債権等の状態にも対応可能な注文受付装置等を提供することである。

上記目的を達成するため、本発明による注文受付装置は、ネットワークを介して接続された注文元端末及び受注センター端末とを識別する端末識別子と、前記注文元を識別する注文元識別子と、商品の品番と、数量とを含む注文情報を前記注文元端末及び前記受注センター端末から受信する注文受付部と、前記注文受付部が前記注文情報を、前記注文元端末から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記注文情報に含まれる前記端末識別子に基づき判断する注文受付判断部と、１以上の注文元の債権状態が良好であるか否かを区分した情報である債権状態区分と前記注文元識別子とを対応付けた債権情報を記憶している債権情報記憶部と、前記注文情報と前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権状態区分を特定し、当該注文元の債権状態について判断する第１の債権状態判断部と、前記注文情報と当該注文情報に関する出荷予定日とを対応付けた受注データを記憶する受注データ記憶部と、在庫数及び入出庫予定を含む在庫情報を商品ごとに保持する在庫情報記憶部と、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、当該注文情報に関する注文元の債権状態が良好であると前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、当該注文情報に含まれる前記品番に対応する前記在庫情報に基づき前記出荷予定日を算出する処理である受注処理を行い、当該受注処理を行った受注データを前記受注データ記憶部に記憶させる受注処理部と、を備え、前記受注処理部は、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、前記注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、前記受注処理を行わずに当該注文情報を前記受注データ記憶部に記憶させるものである。

このような構成により、注文元から注文情報を直接的に受け付けたのかどうかに関する判断結果と、注文元の債権状態に関する判断結果とに基づいて、受注処理を行うことができ、例えば、注文元から注文情報を直接的に受け付けた場合には、債権状態にかかわらず、受注処理を行う、とりわけ、注文元の債権状態が良好でない場合には、受注処理として注文情報の蓄積のみを行うことで、例えば、その後に、その蓄積された注文情報と注文元の債権状態を所定のオペレータがチェックし、それぞれの注文に対して適切に対応する（場合によっては、オペレータが電話を掛けるなどにより、注文を断る）ことができ得るので、注文元の気分、心証を害することなく、注文情報の受け付けを行うことができ得る。

また、本発明による注文受付装置では、前記注文情報を前記受注センター端末から受信したと前記注文受付判断部によって判断され、当該注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断部によって判断された場合に、当該注文元に関する債権状態を示す情報である債権状態情報を前記受注センター端末に送信する債権状態出力部をさらに備えてもよい。

このような構成により、オペレータを介して注文情報を受け付けた場合に、注文元の債権状態が良好でなければ、その旨をオペレータに知らせることができ得る。その結果、例えば、注文元に対して、オペレータが債権状態に関する質問等をすることもでき得る。

また、本発明による注文受付装置では、債権状態が良好でないことを示す前記債権状態区分には注意と不良とが含まれ、前記注文受付装置は、前記注文情報に関する前記受注処理を行う旨の命令である受注処理命令を受け付ける受注命令受付部をさらに備え、前記債権状態出力部は、前記注文情報に関する注文元の前記債権状態区分が注意であると前記第１の債権状態判断部によって判断された場合にはその旨及び当該注文情報に関する前記受注処理を行うか否かを問い合わせる情報を、前記注文情報に関する注文元の前記債権区分が不良であると前記第１の債権状態判断部によって判断された場合にはその旨を前記受注センター端末に送信し、前記受注処理部は、前記情報への応答として前記受注センター端末から送信された前記受注処理命令を前記受注命令受付部が受け付けた場合に、前記受注処理を行い、当該注文情報に関する受注データを前記受注データ記憶部に記憶させるようにしてもよい。

このような構成により、オペレータに対して出力された注文元の債権状態が注意である場合には、オペレータからの受注処理命令の有無によって、受注処理を行うかどうかを決めることができ、また、オペレータに対して出力された注文元の債権状態が不良である場合には、受注処理を行わないようにすることで、債権状態の悪化している注文元からの注文情報に対する受注処理を行うことを防止することができる。また、この場合には、オペレータを介しての注文がなされているため、オペレータが注文元に対して受注処理を行うことができない旨を丁寧に説明することによって、注文元の心証を害さないようにすることができ、注文元との関係が悪化するような事態を回避でき得る。

また、本発明による注文受付装置では、物流センターに設置された物流センターサーバとネットワークを介して接続され、前記注文受付装置は、送信元の識別子である送信元識別子を含み、前記受注処理部により前記受注処理が行われた前記受注データについて出荷処理を行う旨の指示である出荷指示を送信する出荷指示部と、前記出荷指示部及び前記受注センター端末から送信された出荷指示を受け付ける出荷指示受付部と、前記出荷指示受付部が前記出荷指示を、前記出荷指示部から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記出荷指示に含まれる送信元識別子に基づき判断する指示受付判断部と、前記出荷指示受付部が前記出荷指示を受け付けた時に、当該出荷指示に関する前記受注データと前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権区分を特定し、当該注文元の債権状態について判断する第２の債権状態判断部と、前記出荷指示が前記出荷指示部から受信したものであると前記指示受付判断部によって判断され、当該出荷指示に関する注文元の債権状態が良好であると前記第２の債権状態判断部によって判断された場合は、当該出荷指示に関する前記受注データを前記物流センターサーバに送信する処理である出荷処理を行う出荷処理部とをさらに備えてもよい。
このような構成により、注文情報を受け付けた時点と、出荷処理を行う時点の２回にわたって債権状態等の判断を行うこととなり、時系列的に変化しうる債権状態にも対応することができ得る。

また、本発明による注文受付装置では、前記出荷処理部が、前記出荷指示を前記出荷指示部から受信したものであると前記指示受付判断部によって判断され、前記出荷指示の受付時に、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、当該出荷指示に関する前記出荷処理を行わなくてもよい。
このような構成により、出荷指示をオペレータから受け付けていない場合に、注文元の債権状態が良好でないにもかかわらず出荷処理を行う事態を防止することができ、売掛金等の回収が困難になる事態を回避することができ得る。

また、本発明による注文受付装置では、前記債権状態出力部は、前記出荷指示を前記受注センター端末から受信したものであると前記指示受付判断部によって判断され、前記出荷指示の受付時に、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、当該注文元に関する債権状態を示す情報である債権状態情報を前記受注センター端末に送信してもよい。

このような構成により、オペレータを介して出荷指示を受け付けた場合に、注文元の債権状態が良好でなければ、その旨をオペレータに知らせることができ得る。その結果、例えば、注文元に対して、オペレータが債権状態に関する質問等をすることもでき得る。

また、本発明による注文受付装置では、前記出荷指示に関する前記出荷処理を行う旨の命令である出荷処理命令を受け付ける出荷命令受付部をさらに備え、前記債権状態出力部は、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、さらに、当該出荷指示に関する前記出荷処理を行うか否かを問い合わせる情報を前記受注センター端末に送信し、前記出荷処理部は、前記情報への応答として前記受注センター端末から送信された前記出荷処理命令を前記出荷命令受付部が受け付けた場合に、当該出荷指示に関する前記出荷処理を行ってもよい。

このような構成により、オペレータに対して出力された注文元の債権状態が良好でない場合には、オペレータからの出荷処理命令の有無によって、出荷処理を行うかどうかを決めることができ、債権状態の悪化している注文元からの注文情報に対する出荷処理を行うことを防止することができる。

また、本発明による注文受付装置では、前記出荷処理部が、注文元の債権状態が良好であると前記第２の債権状態判断部によって判断された場合に、前記出荷指示に関する前記出荷処理を行ってもよい。
このような構成により、注文元の債権状態が良好であれば、受け付けた出荷指示に関する出荷処理を行うことができる。また、注文元の債権状態が良好であるため、その注文に関する注文元からの売掛金等の回収をスムーズに行うことができ得る。

本発明による注文受付装置等によれば、注文に関する情報である注文情報を注文元から直接的に受け付けたのかどうかに関する判断結果と、注文元の債権状態に関する判断結果とに基づいて受注処理を行うことで、注文元の心証を害することなく、債権状態に基づいた受注処理を行うことができ得る。
また、注文情報の受付時と、出荷時との２回にわたって注文元の債権状態に関する判断を行うことによって、時系列的に変化し得る債権状態にも対応することができ得る。

（実施の形態１）
本発明の実施の形態１による注文受付装置について、図面を参照しながら説明する。
図１は、本実施の形態による注文受付装置の構成を示すブロック図である。図１において、本実施の形態による注文受付装置は、注文受付部１と、注文受付判断部２と、債権情報記憶部３と、債権状態判断部４と、受注処理部５と、受注命令受付部６と、債権状態出力部７と、受注データ記憶部８と、出荷処理部９と、出荷データ記憶部１０と、債権情報更新部１１とを備える。

注文受付部１は、注文情報を受け付ける。ここで、注文情報とは、注文に関する情報である。注文情報には、例えば、注文対象である商品の品番や、その数量、注文元を識別する情報等が含まれる。注文受付部１は、例えば、入力デバイス（例えば、キーボードやマウス、タッチパネルなど）から入力された注文情報を受け付けてもよく、有線もしくは無線の通信回線を介して送信された注文情報を受け付けてもよく、所定の記録媒体（例えば、半導体メモリや磁気ディスク、光ディスクなど）から読み出された注文情報を受け付けてもよい。

注文受付判断部２は、注文受付部１が注文情報を注文元から直接的に受け付けたのか、あるいは、注文元から間接的に受け付けたのかを判断する。ここで、注文情報の受け付けが直接的であるのか、間接的であるのかについては、注文元と注文受付部１との間にオペレータを介しているかどうかに対応する。具体的には、注文情報を注文元から直接的に受け付けるとは、例えば、注文元の店等から有線または無線の通信回線（例えば、インターネットなど）を介して直接、注文受付部１に送信された注文情報を受け付ける場合である。また、注文情報を注文元から間接的に受け付けるとは、例えば、注文元の店等から、電
話やＦＡＸによって、注文を受け付けるオペレータに対して注文内容が伝えられ、そのオペレータによって入力された注文情報を受け付ける場合である。その判断方法の具体例としては、例えば、オペレータが社内のＬＡＮを介して注文情報を注文受付部１に送信する場合には、注文情報のヘッダに含まれるＩＰアドレスが、オペレータが操作する端末装置のＩＰアドレスと一致すれば、間接的に受け付けられたと判断し、注文情報のヘッダに含まれるＩＰアドレスがその他のＩＰアドレスであれば、直接的に受け付けられたと判断してもよい。また、オペレータが注文情報を、入力デバイスを用いて注文受付部１に入力する場合には、入力デバイスから入力された注文情報については、間接的に受け付けられたと判断し、通信回線を介して送信された注文情報については、直接的に受け付けられたと判断してもよい。あるいは、直接的であるのか、間接的であるのかを示すフラグが注文情報のヘッダに含まれる場合には、そのフラグによって判断してもよい。

債権情報記憶部３は、債権情報を記憶している。ここで、債権情報とは、１以上の注文元の債権状態に関する情報である。債権情報では、例えば、注文元を識別する情報と、債権状態を示す情報とが対応付けられている。ここで、債権状態とは、売掛債権等に関する状態である。この債権状態によって、注文元に対して掛売り等の信用取引を行ってよいかどうかを判断することができる。この債権状態は、例えば、売掛金や売掛債権が所定のしきい値に対してどれぐらいの割合であるのかに基づいて設定されてもよく、売掛金等が所定のしきい値を超えてからどれぐらいの期間が経過しているのか等に基づいて設定されてもよい。また、その他の注文元に関する情報（例えば、倒産する確率が高いなど）に基づいて債権状態が設定されてもよい。債権状態は、例えば、「良好」、「注意」、「不良」などによって示される。債権情報記憶部３は、所定の記録媒体（例えば、半導体メモリや磁気ディスク、光ディスクなど）によって実現され得る。また、債権情報記憶部３での記憶は、外部のストレージデバイス、サーバ等から読み出された債権情報のＲＡＭ等における一時的な記憶でもよく、あるいは、磁気ディスク等における長期的な記憶でもよい。

債権状態判断部４は、注文元の債権状態について、債権情報記憶部３が記憶している債権情報に基づいて判断する。例えば、債権状態判断部４は、債権情報に基づいて、所定の注文元の債権状態が、所定の債権状態（例えば、「良好」や、「不良」など）であるかどうか判断する。

受注処理部５は、注文受付判断部２による判断結果と、債権状態判断部４による判断結果とに基づいて、注文受付部１が受け付けた注文情報に関する受注処理を行う。ここで、受注処理とは、注文の受け付けを確定するための処理であり、例えば、注文受付部１が受け付けた注文情報を蓄積あるいは送信したり、注文に関する出荷年月日の通知を行ったりすることである。本実施の形態では、注文情報を受注データ記憶部８に蓄積するものとする。また、本実施の形態による受注処理部５は、在庫情報を保持しており、その在庫情報に基づいて、注文情報における注文対象の商品に関する出荷年月日の算出も行う。ここで、在庫情報とは、商品の在庫状況（すなわち、各商品にどれだけの在庫があるか）や、商品の在庫スケジュール（すなわち、どの商品が、いつ、どれだけ入庫する（あるいは出荷可能な状態となる）のか）に関する情報である。この在庫情報は、実際の在庫状況等に応じて、更新されるものとする。

受注処理部５は、注文受付判断部２による判断結果と、債権状態判断部４による判断結果とに基づいて、具体的には、以下のように受注処理を行う。まず、注文受付判断部２によって間接的に注文情報を受け付けたと判断され、注文元の債権状態が注意であると債権状態判断部４によって判断された場合に、受注命令受付部６が後述する受注処理命令を受け付けたときは注文情報に関する受注処理を行い、受注命令受付部６が受注処理命令を受け付けなかったときには、受注処理を行わない。また、注文受付判断部２によって間接的に注文情報を受け付けたと判断され、注文元の債権状態が不良であると債権状態判断部４
によって判断された場合にも、受注処理を行わない。また、受注処理部５は、注文情報を注文元から直接的に受け付けたと注文受付判断部２によって判断され、その注文情報に関する注文元の債権状態が良好でないと債権状態判断部４によって判断された場合には、注文情報に関する受注処理を行う。また、受注処理部５は、注文元の債権状態が良好であると債権状態判断部４によって判断された場合には、注文受付判断部２による判断結果に関わらず、注文情報に関する受注処理を行う。

受注命令受付部６は、受注処理命令を受け付ける。ここで、受注処理命令とは、注文情報に関する受注処理を行う旨の命令である。受注命令受付部６は、例えば、入力デバイス（例えば、キーボードやマウス、タッチパネルなど）から入力された受注処理命令を受け付けてもよく、有線もしくは無線の通信回線を介して送信された受注処理命令を受け付けてもよい。受注命令受付部６は、受注処理命令を受け付けると、その旨を受注処理部５に伝える。その結果、受注処理部５によって受注処理が行われる。

債権状態出力部７は、債権状態情報を出力する。ここで、債権状態情報とは、注文元の債権状態を示す情報である。債権状態出力部７は、受注処理部５からの指示によって、債権情報記憶部３で記憶されている債権情報を参照することによって債権状態情報を出力する。なお、債権状態情報は、債権情報記憶部３で記憶されている債権情報の示す債権状態をそのまま含むものであってもよく、あるいは、債権情報の示す債権状態に基づいて構成されたものであってもよい。前者としては、例えば、債権情報に含まれる債権状態が「良好」などの場合である。後者としては、例えば、債権情報に含まれる債権状態は「０」、「１」等であり、それに基づいて「良好」や「注意」等の債権状態情報が構成される場合である。また、この出力は、オペレータに対して債権状態を知らせるために行われるものであり、例えば、表示デバイス（例えば、ＣＲＴや液晶ディスプレイなど）への表示でもよく、通信回線を介した所定の機器に対する送信であってもよく、プリンタによる印刷でもよく、スピーカによる音声による出力でもよい。また、債権状態出力部７は、出力を行うデバイス（例えば、表示デバイスやプリンタなど）を含んでもよく、あるいは含まなくてもよい。また、債権状態出力部７は、ハードウェアによって実現されてもよく、あるいは、それらのデバイスを駆動するドライバ等のソフトウェアによって実現されてもよい。

受注データ記憶部８は、受注データを記憶している。ここで、受注データとは、受注に関するデータであり、受注処理部５によって蓄積される。この受注データは、注文情報と同一の情報であってもよく、注文情報に対して他の情報（例えば、注文情報の受け付けられた注文年月日を示す情報や、出荷の行われる出荷年月日を示す情報など）が付加されていてもよく、注文情報に基づいて新たに生成されたものであってもよい。受注データ記憶部８は、所定の記録媒体（例えば、半導体メモリや磁気ディスク、光ディスクなど）によって実現され得る。

出荷処理部９は、受注処理部５によって受注処理の行われた注文情報に対する出荷処理を行う。具体的には、受注処理部５が蓄積した受注データに基づいて、出荷処理を行う。ここで、出荷処理とは、注文された商品を出荷するためのトリガーとなる処理であり、例えば、出荷の対象となる商品を識別する情報と、その商品の数量とを所定の記録媒体に蓄積したり、それらの情報を所定のサーバ等に送信したり、それらの情報を所定の表示デバイス等に表示したりすることである。そして、その蓄積された情報を参照することや、送信された情報を受信すること、あるいは、表示された情報に基づいて所定の操作をオペレータが行うことによって、実際の商品が、例えば物流センター等から注文元に出荷（発送）されることとなる。その出荷処理の後に、実際に商品が注文元に対して出荷されることとなる。本実施の形態では、出荷の対象となる商品を識別する情報と、その商品の数量とを商品の出荷を管理している物流センターのサーバに送信するものとする。また、出荷処理部９は、出荷データを出荷データ記憶部１０に蓄積する。ここで、出荷データとは、出
荷に関するデータであり、少なくとも、出荷処理によって出荷される商品に関する合計金額（例えば、複数の商品が出荷される場合には、商品の単価に数量を掛けたもの）を含んでいる。

出荷データ記憶部１０は、出荷データを記憶している。出荷データ記憶部１０は、所定の記録媒体（例えば、半導体メモリや磁気ディスク、光ディスクなど）によって実現され得る。なお、出荷データ記憶部１０が記憶しているのは、代金が未収である商品に関するデータのみであり、商品代金が支払われた場合には、対応する情報が削除されるものとする。ここで、商品代金が支払われたとは、例えば、売掛金に対する手形が渡されたことでもよく、その手形の満期日に、その手形に対する支払いがなされたことでもよく、あるいは、その他の手続きがなされたことであってもよい。

債権情報更新部１１は、出荷データ記憶部１０で記憶されている出荷データと、注文元ごとの債権限度額を示す情報である債権限度情報とに基づいて、債権情報を更新する。例えば、債権状態が「不良」である注文元が代金を支払ったことによって、未収代金が債権限度額よりも少なくなった場合に、その注文元に対する債権状態を「良好」に更新する。

次に、本実施の形態による注文受付装置の動作について、図２及び図３のフローチャートを用いて説明する。図２では、注文情報に対する受注処理に関係する処理を示しており、図３では、受注データに対する出荷処理に関係する処理を示している。

まず、図２のフローチャートについて説明する。
（ステップＳ１０１）注文受付部１は、注文情報を受け付けたかどうか判断する。そして、注文情報を受け付けた場合には、その注文情報を受注処理部５に渡してステップＳ１０２に進み、注文情報を受け付けていない場合には、注文情報を受け付けるまでステップＳ１０１の処理を繰り返す。

（ステップＳ１０２）注文受付判断部２は、注文受付部１が受け付けた注文情報が、直接的に受け付けられたのか、あるいは、間接的に受け付けられたのかに関する判断を行う。そして、その判断結果を保持しておく。

（ステップＳ１０３）受注処理部５は、注文情報に含まれる注文元を識別する情報と、その注文元の債権状態が「注意」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。すると、債権状態判断部４は、その注文元を識別する情報に対応する債権状態を、債権情報記憶部３が記憶している債権情報を参照することによって取得し、債権状態が「注意」であるかどうか判断する。そして、その判断結果を受注処理部５に渡す。注文元の債権状態が「注意」であれば、ステップＳ１０８に進み、そうでなければ、ステップＳ１０４に進む。

（ステップＳ１０４）受注処理部５は、注文情報に含まれる注文元を識別する情報と、その注文元の債権状態が「不良」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。すると、債権状態判断部４は、その注文元を識別する情報に対応する債権状態を、債権情報記憶部３が記憶している債権情報を参照することによって取得し、債権状態が「不良」であるかどうか判断する。そして、その判断結果を受注処理部５に渡す。注文元の債権状態が「不良」であれば、ステップＳ１０６に進み、そうでなければ、ステップＳ１０５に進む。

（ステップＳ１０５）受注処理部５は、受注処理を行う。例えば、受注処理部５は、受け付けられた注文情報に関する出荷年月日の算出を行い、その出荷年月日を含む受注データを受注データ記憶部８に蓄積する。そして、ステップＳ１０１に戻る。なお、受注処理
部５は、その算出した出荷年月日を、図示しない通信手段等を介してオペレータ、あるいは注文元に通知してもよい。

（ステップＳ１０６）受注処理部５は、ステップＳ１０２における判断で、注文情報が直接的に注文元から受け付けられたと判断されたのかどうかについて判断する。そして、直接的に受け付けられた場合にはステップＳ１０９に進み、間接的に受け付けられた場合には、ステップＳ１０７に進む。

（ステップＳ１０７）受注処理部５は、注文情報に含まれる注文元を識別する情報と、債権状態情報を出力する旨の指示とを債権状態出力部７に渡す。すると、債権状態出力部７は、その注文元を識別する情報に対応する債権状態を債権情報記憶部３から読み出し、その債権状態に対応する債権状態情報を出力する。そして、ステップＳ１０１に戻る。

（ステップＳ１０８）受注処理部５は、ステップＳ１０２における判断で、注文情報が直接的に注文元から受け付けられたと判断されたのかどうかについて判断する。そして、直接的に受け付けられた場合にはステップＳ１０９に進み、間接的に受け付けられた場合には、ステップＳ１１０に進む。

（ステップＳ１０９）受注処理部５は、受注処理を行う。例えば、受注処理部５は、注文データに基づいた受注データの蓄積を行う。そして、ステップＳ１０１に戻る。なお、このステップＳ１０９における受注処理は、ステップＳ１０５における受注処理と異なっていてもよい。例えば、ステップＳ１０５においては、出荷年月日の算出を行い、ステップＳ１０９においては、出荷年月日の算出を行わなくてもよい。

（ステップＳ１１０）受注処理部５は、注文情報に含まれる注文元を識別する情報と、債権状態情報を出力する旨の指示とを債権状態出力部７に渡す。すると、債権状態出力部７は、その注文元を識別する情報に対応する債権情報を債権情報記憶部３から読み出し、その債権情報が示す債権状態に対応する債権状態情報を出力する。

（ステップＳ１１１）受注処理部５は、受注命令受付部６が受注処理命令を受け付けたかどうか判断する。そして、受注処理命令を受け付けた場合にはステップＳ１０５に進み、所定の時間が経過しても受注処理命令を受け付けない場合には、ステップＳ１０１に戻る。
なお、図２のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、図３のフローチャートについて説明する。ここで、受注データ記憶部８が記憶している受注データは、図４で示されるものであるとする。すなわち、受注処理部５が出荷を行う予定の年月日である出荷年月日の算出も行う場合における受注データに対する出荷処理に関係する処理について説明する。図４において、受注データの各レコードには、注文を行った年月日である注文年月日と、出荷年月日と、注文元を識別する情報である店コードと、商品を識別する情報である商品の品番と、注文された商品の数量と、商品の単価とが含まれる。なお、ＩＮＤＥＸは、レコードを識別する情報であり、表管理上の要請のために存在している。また、出荷年月日が「−」であるレコードは、出荷年月日の算出がなされていないことを示す。

（ステップＳ２０１）出荷処理部９は、Ｉを「１」に設定する。
（ステップＳ２０２）出荷処理部９は、受注データのＩＮＤＥＸ＝Ｉのレコードにおいて、出荷年月日が現在の年月日（判断時の年月日）以後であるかどうか判断する。そして、出荷年月日が現在の年月日以後であればステップＳ２０３に進み、そうでなければステ
ップＳ２０６に進む。なお、図４のＩＮＤＥＸ＝２のレコードで示されるように、出荷年月日が「−」であれば、出荷処理部９は、この条件を充たすと判断し、ステップＳ２０３に進む。

（ステップＳ２０３）出荷処理部９は、ＩＮＤＥＸ＝Ｉのレコードにおける注文元を識別する情報（図４では、店コード）と、その注文元の債権状態が「良好」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。すると、債権状態判断部４は、その注文元を識別する情報に対応する債権状態を、債権情報記憶部３が記憶している債権情報を参照することによって取得し、債権状態が「良好」であるかどうか判断する。そして、その判断結果を出荷処理部９に渡す。注文元の債権状態が「良好」であれば、ステップＳ２０４に進み、そうでなければ、ステップＳ２０６に進む。

（ステップＳ２０４）出荷処理部９は、ＩＮＤＥＸ＝Ｉのレコードに関する出荷処理を行う。例えば、出荷処理部９は、受注データのＩＮＤＥＸ＝Ｉのレコードを商品の出荷を管理している物流センターのサーバに送信する。
（ステップＳ２０５）出荷処理部９は、ＩＮＤＥＸ＝Ｉのレコードに基づいて生成した出荷データを、出荷データ記憶部１０に蓄積する。そして、受注データ記憶部８が記憶しているＩＮＤＥＸ＝Ｉのレコードを削除する。

（ステップＳ２０６）出荷処理部９は、ＩＮＤＥＸ＝Ｉのレコードが受注データ記憶部８で記憶されている受注データの最後のレコードであるかどうか判断する。そして、最後のレコードである場合には、一連の処理が終了となり、そうでない場合には、ステップＳ２０７に進む。

（ステップＳ２０７）出荷処理部９は、Ｉを１だけインクリメントする。そして、ステップＳ２０２に戻る。
なお、このステップＳ２０１〜Ｓ２０７までの処理は、例えば、１日に１回実行されるものとする。

次に、本実施の形態による注文受付装置の動作について、具体例を用いて説明する。この具体例では、図５で示すように、注文受付装置１００と、受注センター端末装置２００と、複数の店端末装置３００と、物流センターサーバ４００とが、有線または無線の通信回線５００を介して接続されることによりシステムが構成される場合について説明する。ここで、受注センター端末装置２００は、オペレータが操作することにより、注文情報を注文受付装置１００に送信する端末装置である。具体的には、店６００の電話装置６０１からの電話を受注センターの電話装置２０１で受信することによってオペレータが注文内容を受注センター端末装置２００に入力する。店端末装置３００は、各販売店に設置されている端末装置であり、店の販売員などが操作することにより、注文情報を注文受付装置１００に送信する。物流センターサーバ４００は、物流センターにおける商品の出荷の管理等を行うサーバであり、注文受付装置１００からの出荷指示に応じて商品を出荷する。また、この具体例において、債権情報記憶部３が記憶している債権情報は図６で示すものであるとする。ここで、債権状態区分の「０」、「１」、「２」は、それぞれ債権状態の「良好」、「注意」、「不良」に対応するものとする。債権状態が良好であるとは、掛売り等の信用取引を行ってもなんら支障がない債権状態であることを示しており、債権状態が不良であるとは、信用取引を行うのは危険である債権状態（売掛金を回収できない可能性が高い状態）であることを示しており、債権状態が注意であるとは、債権状態が良好と不良の中間であることを示している。

まず、オペレータが電話によって注文を受け付け、注文受付装置１００に注文情報を送信する場合について説明する。オペレータが受注センター端末装置２００を操作して、注
文情報の入力、及び送信を行うソフトウェア・プログラムを起動したとする。すると、受注センター端末装置２００の表示画面に図７で示されるように、注文情報を入力する「注文」ウィンドウが表示される。

店６００の販売員は、所望の商品の注文を行うため、電話装置６０１によって、受注センターに電話をかけたとする。すると、その電話をオペレータが電話装置２０１によって受信し、店６００からの注文を聞く。そして、店６００の店コードや、注文対象の商品の品番、数量、その商品の単価を図７で示される「注文」ウィンドウにおいて、マウスやキーボードを操作することによって入力する。なお、商品の単価については、オペレータが価格表を参照することによって入力してもよく、あるいは、各商品の単価を示す情報を有するデータベースから自動的に取得するようにしてもよい。最後に、オペレータが「注文」ボタンをマウスでクリックすると、入力された情報が注文情報として注文受付装置１００に送信される。ここで、送信された注文情報には、「店コード：１１１１」、「品番：ＴＨ−３０」、「数量：１０」、「単価：１０，０００円」という情報が含まれていたとする。

送信された注文情報は、注文受付部１において受け付けられ（ステップＳ１０１）、受注処理部５に渡される。また、注文受付判断部２は、注文情報のヘッダに含まれるＩＰアドレスを参照し、それがあらかじめ保持している受注センター端末装置２００のＩＰアドレスと一致すると判断することにより、注文元から間接的に注文情報を受け付けた（すなわち、オペレータを介した注文である）と判断する（ステップＳ１０２）。

受注処理部５は、債権状態判断部４に店コード「１１１１」を渡し、債権状態が「注意」であるかどうか判断させる。債権情報記憶部３が記憶している債権情報は、図６で示されるものであるため、債権状態判断部４は、債権状態が「注意」であると判断する（ステップＳ１０３）。注文受付判断部２によって注文情報を間接的に受け付けたと判断されているため（ステップＳ１０８）、受注処理部５は、店コード「１１１１」を債権状態出力部７に渡し、その店コードに対応する債権状態情報を出力させる。この結果、債権状態出力部７から、通信回線５００を介して受注センター端末装置２００に債権状態情報が送信される（ステップＳ１１０）。そして、受注センター端末装置２００の表示画面に、図８で示される、注文を確定するかどうか、すなわち、受注処理を行うかどうかについて問い合わせる表示がなされる。オペレータは、この表示を見て、例えば、電話をしてきた店６００が信頼できる店だと知っていた場合には、「はい」をマウスでクリックすることによって注文を確定する。すると、受注センター端末装置２００から受注処理命令が送信され、その受注処理命令は、受注命令受付部６において受け付けられる。そして、受注処理部５は、受注処理命令が受け付けられたと判断し（ステップＳ１１１）、受注処理を行う（ステップＳ１０５）。具体的には、受注処理部５は、品番「ＴＨ−３０」の商品を１０個、いつ出荷できるのかを、保持している在庫情報を参照することにより算出する。そして、算出した出荷年月日「２００３年１１月２０日」を含む受注データを受注データ記憶部８に蓄積する。図４のＩＮＤＥＸ＝１のレコードは、そのようにして蓄積されたものである。また、受注処理部５は、その出荷年月日を受注センター端末装置２００に送信する。その結果、受注センター端末装置２００の表示画面に、図９で示される表示がなされ、オペレータは、店６００の販売員に対して２００３年１１月２０日に出荷される旨を伝える。なお、受注処理部５は、出荷年月日の算出と共に、注文情報に含まれる商品の在庫引き当て処理（あるいは、入庫予定の商品の引当て処理）を行ってもよい。この在庫引き当て処理等は、例えば、在庫引き当て処理を行う商品の数量を在庫情報から減算することなどである。

なお、オペレータが、電話をしてきた店６００の信用度が低いことを知っていた場合や、注文元に債権状態についての質問を行った結果、債権状態が悪い方向に向かっていると
わかった場合などには、電話によって、店６００の販売員に債権状態がよくない（例えば、売掛金の未納分が増加している）ために、注文を行うことができない旨と、債権状態が回復してから再度、注文を行うことによって注文をすることができる旨とを丁寧に（すなわち、注文元の気分を害さないように）説明し、図８の表示において「いいえ」をマウスでクリックすることによって、注文をキャンセルする。その結果、受注処理命令が受注命令受付部６で受け付けられず（ステップＳ１１１）、受注処理はなされない。

ここで、例えば、店６００の店コードが「１１１２」であり、債権状態が「不良」である場合にも（ステップＳ１０４、Ｓ１０６）、注文受付装置１００から受注センター端末装置２００に対して債権状態が不良であることを示す債権状態情報が送信され（ステップＳ１０７）、受注センター端末装置２００の表示画面に図１０で示す表示がなされる。この表示をオペレータが見ると、店６００の販売員に対して、上述のように、売掛金の未納分が増加しているため、注文を行うことができない旨等を注文元の気分を害することなく納得してもらうように丁寧に説明する。この場合にも、受注処理はなされない。

次に、オペレータを介さないで注文を行う場合について説明する。店コード「１１１２」の店の販売員が店端末装置３００を操作することにより、注文を行うソフトウェア・プログラムを起動し、所望の商品の品番等を入力したとする。図１１は、店端末装置３００と、入力された情報の一例を示す図である。図１１で示される表示において販売員が「注文」ボタンをクリックすると、注文情報が注文受付装置１００に送信される。そして、「店コード：１１１２」、「品番：ＴＨ−４０」、「数量：５」を含む注文情報が注文情報受付部１で受け付けられ（ステップＳ１０１）、受注処理部５に渡される。また、注文受付判断部２によって、注文元から直接的に、注文情報が送信されたと判断される（ステップＳ１０２）。図３で示される債権情報では、店コード「１１１２」に対応する債権状態は「不良」であるため、債権状態が「注意」でなく、「不良」であると債権状態判断部４によって判断される（ステップＳ１０３、Ｓ１０４）。また、注文情報は直接的に送信されているため（ステップＳ１０６）、受注処理部５は、受注処理を行う（ステップＳ１０９）。なお、この場合の受注処理では、出荷年月日の算出を行わず、単に、注文情報に基づいた受注データの蓄積のみを行う。図４のＩＮＤＥＸ＝２のレコードは、このようにして蓄積されたものである。なお、ＩＮＤＥＸ＝２のレコードでは、商品の単価が含まれているが、この単価は、受注処理部５が、各商品の単価を示す情報を有するデータベース（図示せず）を、品番をキーとして検索し、取得したものである。

次に、債権状態が良好である注文元に関する注文情報を受け付けた場合について、簡単に説明する。この場合には、債権状態が「注意」でもなく、「不良」でもないと判断され（ステップＳ１０３、Ｓ１０４）、注文情報が直接的に受け付けられたのか、あるいは間接的に受け付けられたのかに関わらず、受注処理がなされる（ステップＳ１０５）。その結果、受け付けられた注文情報に基づいて、出荷年月日を含む受注データが受注データ記憶部８に蓄積される。

次に、出荷処理部９による出荷処理について説明する。出荷処理部９は、毎日、午前９時になると、受注データ記憶部８が記憶している受注データに対して図３のフローチャートの処理を行うものとする。また、現在の年月日は２００３年１１月２０日であるとする。

まず、図４で示される受注データのＩＮＤＥＸ＝１のレコード（ステップＳ２０１）について、出荷処理部９は、出荷年月日が現在の年月日以後であると判断する（ステップＳ２０２）。また、債権状態判断部４に店コード「１１１１」を渡すことによって、債権状態判断部４に債権状態が「良好」であるかどうか判断させる。図６で示される債権情報が更新された結果、図１２で示される債権情報が債権情報記憶部３で記憶されている場合に
は、債権状態判断部４は、店コード「１１１１」に対応する債権状態は「良好」であると判断し（ステップＳ２０３）、その旨を出荷処理部９に渡す。その結果、出荷処理部９は出荷処理を行う（ステップＳ２０４）。具体的には、出荷処理部９は、店コード「１１１１」と、品番「ＴＨ−３０」と、数量「１０」を受注データから読み出し、それらの情報を、図示しない通信部を介して物流センターサーバ４００に送信する。その結果、物流センターから店コード「１１１１」に対応する店に対して、品番「ＴＨ−３０」の商品が１０個、出荷されることとなる。

また、出荷処理部９は、受注データにおけるＩＮＤＥＸ＝１のレコードに基づいて出荷データを構成し、その出荷データを出荷データ記憶部１０に蓄積する（ステップＳ２０５）。図１３は、そのようにして蓄積された出荷データの一例を示す図である。図１３のＩＮＤＥＸ＝１のレコードが、図４のＩＮＤＥＸ＝１のレコードに基づいて構成されたものである。図１３で示される各レコードでは、商品の単価に数量を掛けた「金額」が含まれている。なお、出荷処理部９は、出荷データの蓄積後に、受注データからＩＮＤＥＸ＝１のレコードを削除する。出荷処理部９は、受注データの最後のレコードまで同様の処理を繰り返す（ステップＳ２０６、Ｓ２０７）。

なお、図４のＩＮＤＥＸ＝２のレコードのように、出荷年月日が「−」である場合には、出荷処理部９が店コード等を物流センターサーバ４００に送信したとしても、引当てるべき在庫がないために物流センターから注文元への出荷を行うことができない場合も考えられる。その場合には、物流センターに引当て可能な商品の新たな入庫が行われた時点で、注文元への商品の出荷を行うものとする。

次に、出荷データに基づいて債権情報を更新する処理について説明する。債権情報更新部１１は、図１４で示す債権限度情報を保持している。ここで、債権限度情報では、図１４で示すように、店コードと、債権限度額とが対応付けられている。債権情報更新部１１は、ある店コードに対応する出荷データの合計金額が、債権限度情報の示す債権限度額以上であるときに、その店コードに対応する債権状態を「不良」であるとし、出荷データの合計金額が、債権限度額の９割以上であり、債権限度額未満である範囲の場合に、債権状態を「注意」であるとし、それ以外の場合に、債権状態を「良好」であるとする。したがって、例えば、債権情報が図６で示されるものであった場合に、出荷データに基づいて算出された店コード「１１１１」に対応する合計金額が８０万円である場合には、債権情報更新部１１は、店コード「１１１１」に対応する債権状態は「良好」であると判断し、債権情報記憶部３が記憶している債権情報を、図１２で示される債権情報に更新する。債権情報更新部１１は、例えば、このような処理を１日に１回、受注データに対する出荷処理のなされた後に、出荷データに含まれているすべての店コードに対して行うものとする。

なお、この具体例において、オペレータは電話によって注文を受け付ける場合について説明したが、電話以外にも、ＦＡＸ等によって注文を受け付け、その受け付けた注文に基づいて注文情報の入力、送信を行ってもよい。この場合に、注文元の債権状態が「不良」である場合には、オペレータが注文元に電話をする等によって、注文をできない旨を、注文元の気分を害さないように説明するものとする。
また、債権状態が「良好」、「注意」、「不良」の３つのパターンがある場合について説明したが、債権状態を「良好」、「不良」の２つのパターンで区別してもよい。

また、この具体例では、注文受付装置１００と、オペレータの操作する受注センター端末装置２００とが通信回線５００を介して接続されている場合について説明したが、注文受付装置１００と、受注センター端末装置とは、同一の装置、あるいは、通信回線を介さないで直接接続されている装置であってもよい。

以上のように、本実施の形態による注文受付装置によれば、受注処理部５が、注文受付判断部２による判断結果と、債権状態判断部４による判断結果とに基づいて、注文情報に関する受注処理を行うことで、注文元の債権状態と、注文情報が直接的に受け付けられたのかどうかに応じて、受注処理を行うかどうか、また受注処理の内容を決定することができる。その結果、注文元の気分、心証を害することなく、債権状態に応じた受注処理を行うことができ得る。特に、注文情報を注文元から直接的に受け付け、注文元の債権状態が良好でない場合に、受注処理部５が、その注文情報に関する受注処理を行うことで、注文元の気分等を害することを防止することができる。また、そのような場合に、通常の受注処理を行うのではなく、単に注文情報を蓄積するだけの受注処理（出荷年月日を決めない受注処理）を行うことによって、在庫がある場合であっても、すぐに出荷される事態を防止することができ得る。

また、注文情報を注文元から間接的に受け付けたと判断され、注文元の債権状態が良好でないと判断された場合に、その注文元に関する債権状態情報をオペレータに対して出力する債権状態出力部７を備えたことにより、債権状態が良好でない場合に、その債権状態をオペレータに対して示すことができる。そして、債権状態が「不良」である場合には、オペレータが、その旨を注文元に対して説明することができる。また、債権状態が「注意」である場合には、注文情報に対する受注処理を行うかどうかを注文元との電話等に基づいてオペレータが判断することができる。そして、債権状態が「注意」であるが、受注処理を行うと判断した場合には、受注命令受付部６に対して受注処理命令を送信することにより、受注処理部５に受注処理を行わせるようにすることができる。

このように、本実施の形態による注文受付装置では、機械的な判断と、オペレータによる対応とを適切に組み合わせることによって、顧客との取引によって生じうる損害を抑えると共に、顧客との良好な関係を構築することができ得る。

なお、本実施の形態におけるステップＳ２０２において、出荷年月日が「−」である場合には、ステップＳ２０４における出荷処理において、出荷対象である商品を識別する情報等を物流センターサーバ４００に送信したとしても、在庫がないために、出荷を行うことができない場合も考えられる。そのような場合には、出荷処理を行わず、在庫情報を参照して出荷年月日の算出を行い、その算出した出荷年月日を受注データにおいて再設定してもよい。

また、債権状態出力部７による債権状態情報の出力において、債権情報記憶部３で記憶されている、注文元に関する債権状態を参照して、債権状態情報を出力する場合について説明したが、受注処理部５は債権状態出力部７に注文元の債権状態を示す情報を渡し、債権状態出力部７は、その受け取った情報に基づいて債権状態情報を出力してもよい。

また、本実施の形態では、債権情報を債権情報更新部１１が更新する場合について説明したが、これは一例であって、例えば、オペレータが出荷データに基づいて算出された注文元ごとの売掛金の額等を参照し、手作業で債権情報を変更してもよい。例えば、ある注文元に関する出荷データに含まれる金額の合計が債権限度額を超えている場合に、経営が破綻していると判断すれば、債権状態を「不良」に設定し、経営が破綻していないと判断すれば、債権状態を「注意」に設定してもよい。

また、本実施の形態では、受注処理において、注文元の債権状態が良好である場合などにおいては、オペレータや注文元に出荷年月日を通知する場合について説明したが、この出荷年月日の通知は、受注処理の一例であって、その通知を行わなくてもよい。

また、注文受付判断部２による判断結果と、債権状態判断部４による判断結果とに基づ
いて行われる、受注処理部５による受注処理は、本実施の形態での説明に限定されるものではない。例えば、オペレータを介して注文情報が受け付けられた場合に、債権状態が「注意」、「不良」である場合には、注文情報に関する受注処理を行わないようにしてもよい。

また、本実施の形態では、出荷処理を行う前に債権状態が良好かどうかを判断する場合について説明したが、この判断を行わずに、自動的に出荷処理を行ってもよい。但し、例えば、債権状態が良好でないのに受注処理を行った受注データのレコードについては、自動的な出荷処理の対象とせず、オペレータ等による判断を介してから、出荷処理を行うようにしてもよい。このようにすることで、債権状態が不良であるにもかかわらず、出荷処理を行う事態を回避することができる。

また、本実施の形態では、出荷処理を行う場合について説明したが、出荷処理部９を備えず、出荷処理については、例えば、オペレータが受注データ記憶部８によって記憶されている受注データを参照して、手動で物流センター等に対して商品の出荷に関する指示を出すようにしてもよい。

（実施の形態２）
本発明の実施の形態２による注文受付装置について、図面を参照しながら説明する。本実施の形態による注文受付装置は、受注処理前に債権状態に関する判断を行い、また、出荷処理を行う旨の指示である出荷指示をオペレータから受け付けたのかどうかに関する判断結果と、注文元の債権状態とに基づいて出荷処理を行うものである。

図１５は、本実施の形態による注文受付装置の構成を示すブロック図である。図１５において、本実施の形態による注文受付装置は、注文受付部１と、債権情報記憶部３と、債権状態判断部４と、受注データ記憶部８と、受注処理部２１と、出荷指示受付部２２と、指示受付判断部２３と、出荷処理部２４と、出荷命令受付部２５と、債権状態出力部２６と、出荷指示部２７とを備える。なお、注文受付部１、債権状態記憶部３，債権状態判断部４、受注データ記憶部８の構成及び動作は、実施の形態１と同様であり、その説明を省略する。

受注処理部２１は、注文受付部１による注文情報の受付時における債権状態判断部４による判断結果に基づいて、注文受付部１が受け付けた注文情報に関する受注処理を行う。受注処理部２１による受注処理では、受注処理部２１が保持している在庫情報に基づいて、出荷年月日を算出する。そして、その出荷年月日を含む受注データを、注文受付部１が受け付けた注文情報に基づいて構成し、その受注データを受注データ記憶部８に蓄積する。なお、具体的にどのような場合に受注処理を行うのかについては後述する。

出荷指示受付部２２は、出荷指示を受け付ける。ここで、出荷指示とは、受注処理部２１が受注処理を行った注文情報に関する出荷処理を行う旨の指示である。出荷指示受付部２２は、出荷指示部２７からの出荷指示と、入力デバイス（例えば、キーボードやマウス、タッチパネルなど）から入力された出荷指示、または有線もしくは無線の通信回線を介して送信された出荷指示とを受け付ける。

指示受付判断部２３は、出荷指示受付部２２が出荷指示をオペレータから受け付けたかどうかを判断する。具体的には、例えば、出荷指示受付部２２が出荷指示を入力デバイスや所定の通信回線を介して受け付けた場合には、オペレータから受け付けたと判断し、出荷指示部２７から受け付けた場合には、オペレータから受け付けなかったと判断する。なお、出荷指示のヘッダにオペレータからの出荷指示であるかどうかを示すフラグが含まれている場合には、そのフラグに基づいてその判断を行ってもよい。

出荷処理部２４は、指示受付判断部２３による判断結果と、出荷指示受付部２２による出荷指示の受付時における債権状態判断部４による判断結果とに基づいて、出荷指示に関する出荷処理を行う。なお、出荷処理部２４による出荷処理については、指示受付判断部２３による判断結果にも基づいて出荷処理を行う点と、出荷データの蓄積を行わない点以外、実施の形態１による出荷処理部９による出荷処理と同様であり、その説明を省略する。

出荷処理部２４は、指示受付判断部２３による判断結果と、出荷指示受付部２２による出荷指示の受付時における、債権状態判断部４による判断結果とに基づいて、具体的には、以下のように出荷処理を行う。まず、出荷処理部２４は、出荷指示をオペレータから受け付けなかったと指示受付判断部２３によって判断され、その出荷指示の受付時に、その出荷指示に関する注文元の債権状態が良好でないと債権状態判断部４によって判断された場合に、その出荷指示に関する出荷処理を行わない。また、出荷処理部２４は、注文元の債権状態が良好でないと債権状態判断部４によって判断され、出荷命令受付部２５が後述する出荷処理命令を受け付けたときには、出荷指示に関する出荷処理を行い、出荷命令受付部２５が出荷処理命令を受け付けないときには、出荷処理を行わない。また、出荷処理部２４は、注文元の債権状態が良好であると債権状態判断部４によって判断された場合に、出荷指示に関する出荷処理を行う。

出荷命令受付部２５は、出荷処理命令を受け付ける。ここで、出荷処理命令とは、出荷処理を行う旨の命令である。出荷命令受付部２５は、例えば、入力デバイス（例えば、キーボードやマウス、タッチパネルなど）から入力された出荷処理命令を受け付けてもよく、有線もしくは無線の通信回線を介して送信された出荷処理命令を受け付けてもよい。出荷命令受付部２５は、出荷処理命令を受け付けると、その旨を出荷処理部２４に伝える。その結果、出荷処理部２４によって出荷処理が行われる。

債権状態出力部２６は、債権状態情報を出力する。ここで、債権状態出力部２６は、受注処理部５に代えて出荷処理部２４からの指示によって債権状態情報を出力する以外、実施の形態１による債権状態出力部７と同様のものであり、その説明を省略する。
出荷指示部２７は、受注データ記憶部８が記憶している受注データを参照し、所定の条件を充たすレコードを示す情報を含む出荷指示を出荷指示受付部２２に渡す。

次に、本実施の形態による注文受付装置の動作について、図１６から図１８のフローチャートを用いて説明する。図１６は、注文情報を受け付けてから受注処理を行うまでの処理を示している。図１７は、出荷指示部２７の動作を示している。図１８は、出荷指示を受け付けてから出荷処理が行われるまでの処理を示している。

まず、図１６のフローチャートについて説明する。
（ステップＳ３０１）注文受付部１は、注文情報を受け付けたかどうか判断する。そして、注文情報を受け付けた場合には、その注文情報を受注処理部２１に渡してステップＳ３０２に進み、そうでない場合には、注文情報を受け付けるまでステップＳ３０１の処理を繰り返す。

（ステップＳ３０２）受注処理部２１は、注文情報に含まれる注文元を識別する情報と、その注文元の債権状態が「良好」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。すると、債権状態判断部４は、その注文元を識別する情報に対応する債権状態を、債権情報記憶部３が記憶している債権情報を参照することによって取得し、債権状態が「良好」であるかどうか判断する。そして、その判断結果を受注処理部２１に渡す。注文元の債権状態が「良好」であれば、ステップＳ３０３に進み、そうでなければ、ステ
ップＳ３０１に戻る。

（ステップＳ３０３）受注処理部２１は、受注処理を行う。例えば、受注処理部２１は、保持している在庫情報に基づいて、注文情報に関する商品の出荷年月日を算出する。そして、注文情報とその出荷年月日とに基づいて受注データを構成し、その構成した受注データを受注データ記憶部８に蓄積する。そして、ステップＳ３０１に戻る。
なお、図１６のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、図１７のフローチャートについて説明する。ここで、受注データ記憶部８が記憶している受注データは、図１９で示されるものであるとする。
（ステップＳ４０１）出荷指示部２７は、Ｉを「１」に設定する。
（ステップＳ４０２）出荷指示部２７は、受注データのＩＮＤＥＸ＝Ｉのレコードにおいて、出荷年月日が現在の年月日であるかどうか判断する。そして、出荷年月日が現在の年月日であればステップＳ４０３に進み、そうでなければステップＳ４０４に進む。

（ステップＳ４０３）出荷指示部２７は、受注データのＩＮＤＥＸ＝Ｉのレコードに関する出荷処理を行う旨の出荷指示を出荷指示受付部２２に出力する。
（ステップＳ４０４）出荷指示部２７は、ＩＮＤＥＸ＝Ｉのレコードが、受注データの最後のレコードであるかどうか判断する。そして、最後のレコードである場合には、一連の処理が終了となり、そうでない場合には、ステップＳ４０５に進む。
（ステップＳ４０５）出荷指示部２７は、Ｉを１だけインクリメントする。そして、ステップＳ４０２に戻る。

次に、図１８のフローチャートについて説明する。
（ステップＳ５０１）出荷指示受付部２２は、出荷指示を受け付けたかどうか判断する。そして、出荷指示を受け付けた場合には、その出荷指示を出荷処理部２４に渡してステップＳ５０２に進み、そうでない場合には、出荷指示を受け付けるまでステップＳ５０１の処理を繰り返す。

（ステップＳ５０２）指示受付判断部２３は、出荷指示受付部２２が受け付けた出荷指示が、オペレータから受け付けたものであるかどうか判断する。そして、その判断結果を保持しておく。

（ステップＳ５０３）出荷処理部２４は、出荷指示で特定される受注データのレコードに関する注文元を識別する情報と、その注文元の債権状態が「良好」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。すると、債権状態判断部４は、その注文元を識別する情報に対応する債権状態を、債権情報記憶部３が記憶している債権情報を参照することによって取得し、債権状態が「良好」であるかどうか判断する。そして、その判断結果を出荷処理部２４に渡す。注文元の債権状態が「良好」であればステップＳ５０４に進み、そうでなければ、ステップＳ５０５に進む。

（ステップＳ５０４）出荷処理部２４は、出荷処理を行う。例えば、出荷処理を行う受注データのレコードを、商品の出荷を実際に行う物流センターのサーバに送信し、そのレコードを削除する。そして、ステップＳ５０１に戻る。なお、レコードの削除に代えて、そのレコードに、出荷処理が終了した旨のフラグを立てるなどの処理を行ってもよい。

（ステップＳ５０５）出荷処理部２４は、ステップＳ５０２における判断で、出荷指示がオペレータから受け付けたものであると判断されたかどうかについて判断する。そして、オペレータからである場合には、ステップＳ５０６に進み、そうでない場合には、出荷
処理を行わずにステップＳ５０１に戻る。

（ステップＳ５０６）出荷処理部２４は、出荷指示で特定される受注データのレコードに含まれる注文元を識別する情報と、債権状態情報を出力する旨の指示とを債権状態出力部２６に渡す。すると、債権状態出力部２６は、その注文元を識別する情報に対応する債権情報を債権情報記憶部３から読みだし、その債権情報が示す債権状態に対応する債権状態情報を出力する。

（ステップＳ５０７）出荷処理部２４は、出荷命令受付部２５が出荷処理命令を受け付けたかどうか判断する。そして、出荷処理命令が受け付けられた場合にはステップＳ５０４に進み、所定の時間が経過しても出荷処理命令が受け付けられない場合には、ステップＳ５０１に戻る。
なお、図１８のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

次に、本実施の形態による受注処理装置の動作について、具体例を用いて説明する。本実施の形態でも、図５で示すように、注文受付装置１００等によってシステムが構成されているとする。また、債権情報記憶部３が記憶している債権情報は、図６で示すものであるとする。

まず、受注処理について説明する。実施の形態１における具体例と同様に、店６００の販売員からの電話により、受注センター端末装置２００を操作しているオペレータが「店コード：１１１３」、「品番：ＴＨ−５０」、「数量：８」、「単価：１０，０００円」を含む注文情報を注文受付装置１００に送信したとする。すると、その注文情報が注文受付部１で受け付けられ（ステップＳ３０１）、受注処理部２１に渡される。受注処理部２１は、債権状態判断部４に店コード「１１１３」を渡し、債権状態が「良好」であるかどうか判断させる。債権情報記憶部３が記憶している債権情報は、図６で示されるものであるため、債権状態判断部４は、債権状態が「良好」であると判断する（ステップＳ３０２）。その結果、受注処理部２１は、保持している在庫情報に基づいて、品番「ＴＨ−５０」を８個出荷することができる出荷年月日「２００３年１１月２０日」を算出する。そして、その算出した出荷年月日を含む受注データを受注データ記憶部８に蓄積する（ステップＳ３０３）。このようにして蓄積された受注データが、図１９で示されるＩＮＤＥＸ＝２のレコードである。

なお、債権状態が「不良」及び「注意」でない限り、注文元から直接的に注文情報を受け付けた場合にも、間接的に注文情報を受け付けた場合にも受注処理を行う。ここで、受注処理を行う場合には、本実施の形態においても、実施の形態１と同様に、算出した出荷年月日を受注センター端末装置２００や、注文元の店端末装置３００に送信するようにしてもよい。一方、債権状態が「不良」及び「注意」である場合には、注文元から直接的に注文情報を受け付けたかどうかにかかわらず、受注処理を行わない。受注処理を行わない場合には、その旨を注文情報の入力元（例えば、注文元やオペレータなど）に通知してもよく、あるいは、その受注処理を行わない注文情報を蓄積しておき、後から、その蓄積された注文情報に基づいて、注文を受け付けることができなかった旨等を注文元に電子メールやＦＡＸ，電話等によって通知してもよい。

次に、出荷指示部２７が出荷指示を出荷指示受付部２２に渡す処理について説明する。まず、出荷指示部２７は、受注データ記憶部８が記憶している受注データにおけるＩＮＤＥＸ＝１のレコードの出荷年月日が現在の年月日（ここでは、２００３年１１月２０日であるとする）ではないと判断する（ステップＳ４０１，Ｓ４０２）。その結果、出荷指示部２７は、Ｉを１だけインクリメントして、ＩＮＤＥＸ＝２のレコードに関する処理に進
む。出荷指示部２７は、受注データにおけるＩＮＤＥＸ＝２のレコードの出荷年月日が現在の年月日であると判断する（ステップＳ４０１、Ｓ４０２）。その結果、出荷指示部２７は、ＩＮＤＥＸ＝２のレコードに関する出荷処理を行う旨の出荷指示を出荷指示受付部２２に渡す（ステップＳ４０３）。そして、出荷指示部２７は、次のＩＮＤＥＸ＝３のレコードに関する処理に進む。このようにして、受注データの最後のレコードまで、このような処理が行われる。なお、この処理は、１日に１回行われるものとする。

出荷指示受付部２２が受注データのＩＮＤＥＸ＝２に関する出荷指示を受け付けると（ステップＳ５０１）、その出荷指示は、出荷処理部２４に渡される。また、指示受付判断部２３は、その出荷指示が装置外部から送信されてきたものではないため、オペレータからの出荷指示ではないと判断する（ステップＳ５０２）。

出荷処理部２４は、受注データのＩＮＤＥＸ＝２における店コード「１１１３」と、債権状態が「良好」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。債権情報記憶部３が記憶している債権情報は、図６で示されるものであるため、債権状態判断部４は、債権状態が「良好」であると判断する（ステップＳ５０３）。その結果、出荷処理部２４は、受注データにおけるＩＮＤＥＸ＝２のレコードを物流センターサーバ４００に送信し、そのレコードを削除する出荷処理を行う。

なお、出荷指示部２７からの出荷指示が出荷処理部２４に渡されたとしても、注文元の債権状態が「良好」でない場合には（ステップＳ５０３）、出荷指示がオペレータからではないと判断され（ステップＳ５０５）、出荷処理は行われない。

次に、オペレータが手動によって出荷指示を出荷指示受付部２２に送信する場合について説明する。オペレータは、受注センター端末装置２００を操作し、図示しない経路によって受注データを注文受付装置１００から取得する。図２０は、そのようにして取得され、受注センター端末装置２００に表示された受注データを示す図である。現在の年月日が２００３年１１月２０日であるとすると、受注データのウィンドウにおける１番目のレコードは、出荷年月日を過ぎているため、出荷年月日（２００３年１１月１７日）において、そのレコードにおける店コードが「１１１５」である注文元の債権状態が「良好」でなかったことがわかる。オペレータがそのレコードに関する出荷処理を行うために、そのレコードの右側に表示されている「出荷」ボタンをマウスでクリックしたとする。すると、ＩＮＤＥＸ＝１のレコードに関する出荷処理を行う旨の出荷指示が受注センター端末装置２００から注文受付装置１００に送信され、出荷指示受付部２２で受け付けられる。

出荷指示受付部２２が受注データのＩＮＤＥＸ＝１に関する出荷指示を受け付けると（ステップＳ５０１）、その出荷指示は、出荷処理部２４に渡される。また、指示受付判断部２３は、その出荷指示が注文受付装置の外部から送信されてきたものであるため、オペレータからの出荷指示であると判断する（ステップＳ５０２）。

出荷処理部２４は、受注データのＩＮＤＥＸ＝１における店コード「１１１５」と、債権状態が「良好」であるかどうかを判断する旨の指示とを債権状態判断部４に渡す。債権情報記憶部３が記憶している債権情報は、図６で示されるものであるため、債権状態判断部４は、債権状態が「注意」であると判断する（ステップＳ５０３）。オペレータから出荷指示が送信されたと指示受付判断部２３によって判断されているため（ステップＳ５０５）、出荷処理部２４は、債権状態出力部２６に、店コード「１１１５」に関する債権状態情報を出力する旨の指示を渡す。すると、債権状態出力部２６が債権情報記憶部３から店コード「１１１５」に対応する債権状態を取得し、その債権状態を示す債権状態情報を受注センター端末装置２００に送信する（ステップＳ５０６）。そのようにして、受注センター端末装置２００に図２１で示される表示がなされる。オペレータが、店コード「１
１１５」の店は、債権状態が徐々に「良好」の方向に向かっており、出荷を行ってもよいと考え、図２１において「はい」をクリックしたとする。すると、受注センター端末装置２００から出荷処理命令が注文受付装置１００に送信され、出荷命令受付部２５で受け付けられる。そして、出荷処理部２４は、出荷処理命令の受け付けがあったと判断し（ステップＳ５０７）、出荷処理部２４は、受注データにおけるＩＮＤＥＸ＝１のレコードを物流センターサーバ４００に送信し、そのレコードを削除する出荷処理を行う。
なお、オペレータが出荷指示を行ったレコードに対応する注文元の債権状態が「良好」である場合にも（ステップＳ５０３）、出荷処理がなされる（ステップＳ５０４）。

以上のように、本実施の形態による注文受付装置によれば、注文受付部１による注文情報の受付時における、債権状態判断部４による判断結果に基づいて受注処理を行い、また、出荷指示受付部２２による出荷指示の受付時における、債権状態判断部４による判断結果に基づいて出荷処理を行うことで、注文情報の受付時と、出荷時の２回にわたって債権状態の判断を行うこととなる。その結果、注文情報の受付時には債権状態が良好であったが、その後、債権状態が悪くなった注文元に対する出荷を防止することができる。このように、時系列的に変化し得る債権状態にも対応することが可能となり得る。

また、指示受付判断部２３による判断結果と、出荷指示の受付時における、債権状態判断部４による判断結果とに基づいて出荷処理を行うことで、出荷指示を出荷指示部２７から受け付けた場合には、注文元の債権状態が「良好」でなければ、出荷処理を行わず、出荷指示をオペレータから受け付けた場合には、注文元の債権状態が「良好」でなくても、オペレータからの出荷処理命令を受け付けると、出荷処理を行うことによって、自動的に（すなわち、オペレータを介さずに）出荷指示が出される場合には、注文元の債権状態に応じて、出荷処理を行うかどうかが決定される一方、オペレータによって手動で出荷指示が出される場合には、オペレータの意思を尊重した出荷処理を行うことができ、きめの細かい出荷処理を行うことができ得る。

なお、本実施の形態では、注文元の債権状態にのみ基づいて受注処理を行う場合について説明したが、実施の形態１と同様に、注文元の債権状態と、注文情報を注文元から直接的に受け付けたのかどうかに関する判断結果とに基づいて受注処理を行ってもよい。
また、実施の形態１と同様に、出荷データの蓄積を行ってもよく、また、その蓄積された出荷データに基づいて債権情報の更新を行う債権情報更新部１１を備えてもよい。

また、債権状態出力部２６による債権状態情報の出力において、債権情報記憶部３で記憶されている、注文元に関する債権状態を参照して、債権状態情報を出力する場合について説明したが、出荷処理部２４は債権状態出力部２６に注文元の債権状態を示す情報を渡し、債権状態出力部２６は、その受け取った情報に基づいて債権状態情報を出力してもよい。

また、本実施の形態では、指示受付判断部２３による判断結果と、出荷指示の受付時における注文元の債権状態に関する判断結果とに基づいて出荷処理を行う場合について説明したが、出荷処理部２４による出荷処理は、指示受付判断部２３の判断結果に関わらず、注文元の債権状態の判断結果に基づいて行うようにしてもよい。その場合には、例えば、出荷処理部２４が、注文元の債権状態が良好でないと債権状態判断部４によって判断された場合に、その注文元に関する出荷処理を行わないようにしてもよい。

また、本実施の形態では出荷指示部２７を備えた構成について説明したが、注文受付装置は、出荷指示部２７を備えていなくてもよい。例えば、装置の外部にあるスケジューリングソフト等が起動されることにより、受注データ記憶部８で記憶されている受注データのうち、出荷処理を行うべきレコードを指定して、そのレコードの出荷処理を行う旨の出
荷指示を出荷指示受付部２２に送信してもよい。

また、指示受付判断部２３による判断結果と、債権状態判断部４による判断結果とに基づいて行われる、出荷処理部２４による出荷処理は、本実施の形態での説明に限定されるものではない。例えば、オペレータを介して出荷指示を受け付けたとしても、債権状態が「不良」であれば、出荷処理を行わないようにしてもよい。

なお、上記各実施の形態において、受注処理部５、２１が出荷年月日を算出する場合について説明したが、出荷年月日に代えて、商品を注文元に納品する納品年月日を算出するようにしてもよい。あるいは、出荷年月日と、納品年月日の両方を算出してもよい。

また、上記各実施の形態では、受注処理部５、２１が在庫情報を保持している場合について説明したが、受注処理部５等が在庫情報を保持しておらず、他の記録媒体で記憶されている在庫情報を参照するようにしてもよい。

また、上記各実施の形態では、債権状態判断部４が債権情報に基づいて、所定の注文元の債権状態が、所定の債権状態であるかどうかについてのみ判断する場合について説明したが、債権状態判断部４は、債権情報に基づいて、所定の演算等を行うことによって、所定の注文元の債権状態について判断を行ってもよい。例えば、債権状態判断部４は、債権情報に含まれる過去の数か月にわたる各注文元の債権状態等に基づいて、所定の演算等（例えば、ポイント化されている債権状態について、平均値を算出し、その平均値と所定のしきい値とを比較するなど）を行うことにより、所定の注文元の債権状態を算出し、その算出結果に基づいて、その注文元の債権状態が「良好」であるかどうかなどを判断してもよい。
また、上記各実施の形態では、注文元が店である場合について説明したが、注文元は、店でなくてもよく、例えば、一般消費者であってもよい。

また、上記各実施の形態では、債権状態区分によって債権状態が３つに区分される場合について説明したが、債権状態区分によって債権状態が２つ、あるいは４以上に区分されてもよい。

また、上記各実施の形態では、受注処理として、受注データを受注データ記憶部８に蓄積する場合について説明したが、これは一例であって、例えば、注文受付部１が受け付けた注文情報をすべて所定の記録媒体に蓄積し、受注処理において、その蓄積された注文情報のうち、受注処理を行うものに所定のフラグを立てる処理を行ってもよく、あるいは受注処理を行わない注文情報を削除する処理を行ってもよい。

また、上記各実施の形態において、各処理（各機能）は、単一の装置（システム）によって集中処理されることによって実現されてもよく、あるいは、複数の装置によって分散処理されることによって実現されてもよい。

また、上記各実施の形態において、各構成要素は専用のハードウェアにより構成してもよく、あるいは、ソフトウェアにより実現可能な構成要素については、プログラム制御によるソフトウェアにより構成してもよい。ソフトウェアにより構成される場合には、例えば、ハードディスクや半導体メモリ等の記録媒体に記録されたソフトウェア・プログラムをＣＰＵ等のプログラム実行部が読み出して実行することによって、各構成要素が実現され得る。なお、上記各実施の形態における情報処理装置を実現するソフトウェアは、以下のようなプログラムである。つまり、このプログラムは、コンピュータに、注文に関する情報である注文情報を受け付ける注文受付ステップと、前記注文受付ステップで前記注文情報を、注文元から直接的に受け付けたのか、あるいは、注文元から間接的に受け付けた
のかを判断する注文受付判断ステップと、１以上の注文元の債権状態に関する情報である債権情報に基づいて、注文元の債権状態について判断する債権状態判断ステップと、前記注文受付判断ステップによる判断結果と、前記債権状態判断ステップによる判断結果とに基づいて、前記注文受付ステップで受け付けた前記注文情報に関する受注処理を行う受注処理ステップと、を実行させるためのものである。

また、他のプログラムは、コンピュータに、注文に関する情報である注文情報を受け付ける注文受付ステップと、１以上の注文元の債権状態に関する情報である債権情報に基づいて、注文元の債権状態について判断する債権状態判断ステップと、前記注文受付ステップでの前記注文情報の受付時における、前記債権状態判断ステップによる判断結果に基づいて、前記注文受付ステップで受け付けた前記注文情報に関する受注処理を行う受注処理ステップと、前記受注処理ステップで受注処理を行った前記注文情報に対する出荷処理を行う旨の指示である出荷指示を受け付ける出荷指示受付ステップと、前記出荷指示受付ステップでの前記出荷指示の受付時における、前記債権状態判断ステップによる判断結果に基づいて、当該出荷指示に関する出荷処理を行う出荷処理ステップと、を実行させるためのものである。

なお、上記プログラムにおいて、情報を送信する送信ステップや、情報を受信する受信ステップなどでは、ハードウェアによって行われる処理、例えば、送信ステップにおけるモデムやインターフェースカードなどで行われる処理（ハードウェアでしか行われない処理）は含まれない。

また、このプログラムは、サーバなどからダウンロードされることによって流通してもよく、所定の記録媒体（例えば、ＣＤ−ＲＯＭなどの光ディスクや磁気ディスク、半導体メモリなど）に記録されることにより流通してもよい。
また、このプログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、あるいは分散処理を行ってもよい。

以上のように、本発明による注文受付装置等は、例えば、注文に関する情報である注文情報を注文元から直接的に受け付けたのかどうかに関する判断結果と、注文元の債権状態に関する判断結果とに基づいて受注処理を行うことで、注文元の心証を害することなく、債権状態に基づいた受注処理を行うことができるという効果を奏するものであり、注文元から、注文情報を直接的に、あるいは間接的に受け付ける装置等として有用である。

本発明の実施の形態１による注文受付装置の構成を示すブロック図 同実施の形態における注文受付装置の動作を示すフローチャート 同実施の形態における注文受付装置の動作を示すフローチャート 同実施の形態における受注データの一例を示す図 同実施の形態におけるシステムを示す図 同実施の形態における債権情報の一例を示す図 同実施の形態における受注センター端末装置の外観の一例を示す図 同実施の形態における表示の一例を示す図 同実施の形態における表示の一例を示す図 同実施の形態における表示の一例を示す図 同実施の形態における店端末装置の外観の一例を示す図 同実施の形態における債権情報の一例を示す図 同実施の形態における出荷データの一例を示す図 同実施の形態における債権限度情報の一例を示す図 本発明の実施の形態２による注文受付装置の構成を示すブロック図 同実施の形態における注文受付装置の動作を示すフローチャート 同実施の形態における注文受付装置の動作を示すフローチャート 同実施の形態における注文受付装置の動作を示すフローチャート 同実施の形態における受注データの一例を示す図 同実施の形態における表示の一例を示す図 同実施の形態における表示の一例を示す図

符号の説明

１ 注文受付部
２ 注文受付判断部
３ 債権情報記憶部
４ 債権状態判断部
５、２１ 受注処理部
６ 受注命令受付部
７、２６ 債権状態出力部
８ 受注データ記憶部
９、２４ 出荷処理部
１０ 出荷データ記憶部
１１ 債権情報更新部
２２ 出荷指示受付部
２３ 指示受付判断部
２５ 出荷命令受付部
２７ 出荷指示部
１００ 注文受付装置

Claims (11)

1. 注文元に設置された注文元端末及び受注センターに設置された受注センター端末とにネットワークを介して接続された注文受付装置であって、
   前記注文元端末及び前記受注センター端末を識別する端末識別子と、前記注文元を識別する注文元識別子と、商品の品番と、数量とを含む注文情報を前記注文元端末及び前記受注センター端末から受信する注文受付部と、
   前記注文受付部が前記注文情報を、前記注文元端末から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記注文情報に含まれる前記端末識別子に基づき判断する注文受付判断部と、
   １以上の注文元の債権状態が良好であるか否かを区分した情報である債権状態区分と前記注文元識別子とを対応付けた債権情報を記憶している債権情報記憶部と、
   前記注文情報と前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権状態区分を特定し、当該注文元の債権状態について判断する第１の債権状態判断部と、
   前記注文情報と当該注文情報に関する出荷予定日とを対応付けた受注データを記憶する受注データ記憶部と、
   在庫数及び入出庫予定を含む在庫情報を商品ごとに保持する在庫情報記憶部と、
   前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、当該注文情報に関する注文元の債権状態が良好であると前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、当該注文情報に含まれる前記品番に対応する前記在庫情報に基づき前記出荷予定日を算出する処理である受注処理を行い、当該受注処理を行った受注データを前記受注データ記憶部に記憶させる受注処理部と、を備え、
   前記受注処理部は、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、前記注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、前記受注処理を行わずに当該注文情報を前記受注データ記憶部に記憶させる注文受付装置。
2. 前記注文情報を前記受注センター端末から受信したと前記注文受付判断部によって判断され、当該注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断部によって判断された場合に、当該注文元に関する債権状態を示す情報である債権状態情報を前記受注センター端末に送信する債権状態出力部をさらに備えた、請求項１記載の注文受付装置。
3. 債権状態が良好でないことを示す前記債権状態区分には注意と不良とが含まれ、
   前記注文受付装置は、
   前記注文情報に関する前記受注処理を行う旨の命令である受注処理命令を受け付ける受注命令受付部をさらに備え、
   前記債権状態出力部は、前記注文情報に関する注文元の前記債権状態区分が注意であると前記第１の債権状態判断部によって判断された場合にはその旨及び当該注文情報に関する前記受注処理を行うか否かを問い合わせる情報を、前記注文情報に関する注文元の前記債権区分が不良であると前記第１の債権状態判断部によって判断された場合にはその旨を前記受注センター端末に送信し、
   前記受注処理部は、前記情報への応答として前記受注センター端末から送信された前記受注処理命令を前記受注命令受付部が受け付けた場合に、前記受注処理を行い、当該注文情報に関する受注データを前記受注データ記憶部に記憶させる請求項２記載の注文受付装置。
4. 前記受注処理部は、注文元の債権状態が良好であると前記第１の債権状態判断部によって判断された場合に、前記注文受付部が受け付けた前記注文情報について前記受注処理を行い、当該注文情報に関する受注データを前記受注データ記憶部に記憶させる請求項２から３のいずれか記載の注文受付装置。
5. 前記注文受付装置は、さらに、物流センターに設置された物流センターサーバとネットワークを介して接続され、
   前記注文受付装置は、
   送信元の識別子である送信元識別子を含み、前記受注処理部により前記受注処理が行われた前記受注データについて出荷処理を行う旨の指示である出荷指示を送信する出荷指示部と、
   前記出荷指示部及び前記受注センター端末から送信された出荷指示を受け付ける出荷指示受付部と、
   前記出荷指示受付部が前記出荷指示を、前記出荷指示部から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記出荷指示に含まれる送信元識別子に基づき判断する指示受付判断部と、
   前記出荷指示受付部が前記出荷指示を受け付けた時に、当該出荷指示に関する前記受注データと前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権区分を特定し、当該注文元の債権状態について判断する第２の債権状態判断部と、
   前記出荷指示が前記出荷指示部から受信したものであると前記指示受付判断部によって判断され、当該出荷指示に関する注文元の債権状態が良好であると前記第２の債権状態判断部によって判断された場合は、当該出荷指示に関する前記受注データを前記物流センターサーバに送信する処理である出荷処理を行う出荷処理部、とをさらに備えた請求項１記載の注文受付装置。
6. 前記出荷処理部は、前記出荷指示を前記出荷指示部から受信したものであると前記指示受付判断部によって判断され、前記出荷指示の受付時に、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、当該出荷指示に関する前記出荷処理を行わない、請求項５記載の注文受付装置。
7. 前記債権状態出力部は、前記出荷指示を前記受注センター端末から受信したものであると前記指示受付判断部によって判断され、前記出荷指示の受付時に、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、当該注文元に関する債権状態を示す情報である債権状態情報を前記受注センター端末に送信する請求項５または６記載の注文受付装置。
8. 前記注文受付装置は、
   前記出荷指示に関する前記出荷処理を行う旨の命令である出荷処理命令を受け付ける出荷命令受付部をさらに備え、
   前記債権状態出力部は、当該出荷指示に関する注文元の債権状態が良好でないと前記第２の債権状態判断部によって判断された場合に、さらに、当該出荷指示に関する前記出荷処理を行うか否かを問い合わせる情報を前記受注センター端末に送信し、
   前記出荷処理部は、前記情報への応答として前記受注センター端末から送信された前記出荷処理命令を前記出荷命令受付部が受け付けた場合に、当該出荷指示に関する前記出荷処理を行う、請求項７記載の注文受付装置。
9. 前記出荷処理部は、注文元の債権状態が良好であると前記第２の債権状態判断部によって判断された場合に、前記出荷指示に関する前記出荷処理を行う、請求項５から８のいずれか記載の注文受付装置。
10. 注文元に設置された注文元端末及び受注センターに設置された受注センター端末とにネットワークを介して接続された注文受付装置における注文受付方法であって、
    前記注文受付装置は、１以上の注文元が良好であるか否かを区分した情報である債権状態区分と前記注文元識別子とを対応付けた債権情報を記憶している債権情報記憶部と、在庫数及び入出庫予定を含む在庫情報を商品ごとに保持する在庫情報記憶部と、注文情報と当該注文情報に関する出荷予定日とを対応付けた受注データを記憶する受注データ記憶部とを備えており、
    前記注文受付装置が、前記注文元端末及び前記受注センター端末を識別する端末識別子と、前記注文元を識別する注文元識別子と、商品の品番と、数量とを含む前記注文情報を前記注文元端末及び前記受注センター端末から受信する注文受付ステップと、
    前記注文受付装置が、前記注文受付ステップで前記注文情報を、前記注文元端末から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記注文情報に含まれる前記端末識別子に基づき判断する注文受付判断ステップと、
    前記注文受付装置が、前記注文情報と前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権状態区分を特定し、当該注文元の債権状態について判断する第１の債権状態判断ステップと、
    前記注文受付装置が、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断ステップによって判断され、当該注文情報に関する注文元の債権状態が良好であると前記第１の債権状態判断ステップによって判断された場合は、前記注文受付ステップにおいて受信した前記注文情報に関して、当該注文情報に含まれる前記品番に対応する前記在庫情報に基づき当該注文情報についての出荷予定日を算出する処理である受注処理を行う受注処理ステップと、
    前記注文受付装置が、前記受注処理ステップにおいて受注処理を行った前記受注データを前記受注データ記憶部に記憶させる受注データ記憶ステップとを有し、
    前記受注処理ステップでは、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断ステップによって判断され、当該注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断ステップによって判断された場合は、前記注文受付ステップにおいて受信した前記注文情報に関して、前記受注処理を行わずに当該注文情報を前記受注データ記憶部に記憶させる注文受付方法。
11. 注文元に設置された注文元端末及び受注センターに設置された受注センター端末とにネットワークを介して接続されたコンピュータを、
    前記注文元端末及び前記受注センター端末を識別する端末識別子と、前記注文元を識別する注文元識別子と、商品の品番と、数量とを含む注文情報を前記注文元端末及び前記受注センター端末から受信する注文受付部と、
    前記注文受付部が前記注文情報を、前記注文元端末から受信したのか、あるいは、前記受注センター端末から受信したのかを、前記注文情報に含まれる前記端末識別子に基づき判断する注文受付判断部と、
    １以上の注文元の債権状態が良好であるか否かを区分した情報である債権状態区分と前記注文元識別子とを対応付けた債権情報を記憶している債権情報記憶部と、
    前記注文情報と前記債権情報とに含まれる前記注文元識別子によって前記注文元の債権状態区分を特定し、当該注文元の債権状態について判断する第１の債権状態判断部と、
    前記注文情報と当該注文情報に関する出荷予定日とを対応付けた受注データを記憶する受注データ記憶部と、
    在庫数及び入出庫予定を含む在庫情報を商品ごとに保持する在庫情報記憶部と、
    前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、当該注文情報に関する注文元の債権状態が良好であると前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、当該注文情報に含まれる前記品番に対応する前記在庫情報に基づき前記出荷予定日を算出する処理である受注処理を行い、当該受注処理を行った受注データを前記受注データ記憶部に記憶させる受注処理部と、
    前記受注処理部は、前記注文情報が前記注文元端末から受信したものであると前記注文受付判断部によって判断され、前記注文情報に関する注文元の債権状態が良好でないと前記第１の債権状態判断部によって判断された場合は、前記注文受付部が受信した前記注文情報に関して、前記受注処理を行わずに当該注文情報を前記受注データ記憶部に記憶させる注文受付装置として機能させるためのプログラム。

Images