JP4638992B2 - 機器管理システム及びその制御方法及びコンピュータプログラム - Google Patents

機器管理システム及びその制御方法及びコンピュータプログラム Download PDF

Info

Publication number
JP4638992B2
JP4638992B2 JP2001072557A JP2001072557A JP4638992B2 JP 4638992 B2 JP4638992 B2 JP 4638992B2 JP 2001072557 A JP2001072557 A JP 2001072557A JP 2001072557 A JP2001072557 A JP 2001072557A JP 4638992 B2 JP4638992 B2 JP 4638992B2
Authority
JP
Japan
Prior art keywords
maintenance
date
information
store
service store
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2001072557A
Other languages
English (en)
Other versions
JP2002269460A5 (ja
JP2002269460A (ja
Inventor
渉 三島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Canon Marketing Japan Inc
Original Assignee
Canon Inc
Canon Marketing Japan Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc, Canon Marketing Japan Inc filed Critical Canon Inc
Priority to JP2001072557A priority Critical patent/JP4638992B2/ja
Publication of JP2002269460A publication Critical patent/JP2002269460A/ja
Publication of JP2002269460A5 publication Critical patent/JP2002269460A5/ja
Application granted granted Critical
Publication of JP4638992B2 publication Critical patent/JP4638992B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Control Or Security For Electrophotography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

【0001】
【発明の属する技術分野】
本発明は機器管理システム及びその制御方法及びンピュータプログラムに関するものである。
【0002】
【従来の技術】
OA製品、特に、複写機を例にして説明する。
【0003】
一般に、メーカの工場で複写機が製造されると、先ず、中継倉庫に搬送されそこで管理される。また、この中継倉庫から、地方にある各中継倉庫に搬送されることもある。販売店に顧客がついた場合、その販売店は所定の手続きを行い、最寄りの倉庫から顧客まで搬送及び設置作業を行い、メンテナンス等についての契約を交わす。以後、この契約に従い、定期的なメンテナンス(保守点検)、及び、複写枚数のチェックを行うことになる。
【0004】
メンテナンス及び複写枚数のチェックは、その顧客にとって最寄りのサービス店員又は販売店員が行うことになり、その課金による請求書も販売店単位に行うことになる。
【0005】
しかしながら、例えば国内全域の販売店の数は膨大であり、且つ、メンテナンス及び複写枚数のチェックのスケジュールの管理、及び、請求書の発行の管理は相当の時間と労力を必要とする。従って、かかる管理を各販売店毎に独立して行うようにすると、国内全体の販売店のそれに費やす時間及び労力は、販売店の数に比例したものとなり、膨大なものとなる。
【0006】
そこで、中枢となるセンタを設け、ここで全ての製品を管理するシステムが考えられる。かかるシステムにすると、販売店とセンタとは回線を介してデータ授受を行い、販売店側としては専ら簡単なデータ入力を行うだけとなり、メンテナンス及び複写枚数のチェックのスケジュールもセンタ側で行い、販売店側はこれを閲覧するだけで済むことになる。また、請求書にしても、センタが発送元となって、顧客に請求書を郵送する等で対処すれば良いので、販売店の負担も軽減でき、しかも、全ての販売店で共通した仕事環境を提供できることにより、作業の効率化も進むことになる。
【0007】
【発明が解決しようとする課題】
ところで、一般に複写機と言っても、単独で使用するよりは、その周辺機器、例えば、オートフィーダ、ソータ(ステイプル機能の有/無も含む)、ネットワークプリンタとして機能するネットワーク接続装置等と共に使用することが多い。また、1つの顧客が複数の複写機を備えることも当然にあり得る。
【0008】
従って、保守点検を行う場合であっても、その顧客の使用環境に適した準備をしてから行うことが望まれる。
【0009】
かかる作業は、全国のサービス店の数だけ存在することになり、それに費やす時間のトータルは、もはや無視できないものである。
【0010】
そこで、本発明は、各サービス店(販売店兼用の場合も当然にあり得る)が管理する機器を一元管理すると共に、複写機等の主機器とその周辺機器の使用状況を含めた、スケジュール管理を行い、その情報をサービス店に提供することを可能ならしめる機器管理システム及びその制御方法及びンピュータプログラムを提供しようとするものである。
【0011】
【課題を解決するための手段】
この課題を解決するため、例えば機器管理システムは以下の構成を備える。すなわち、
各保守サービス店が保守点検をする対象の主機器及びその周辺機器の前記保守点検のスケジュールを、一元管理する機器管理システムであって、
前記各保守サービス店の端末と通信する通信手段と、
前記主機器に対してユニークに付与された機番情報と、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報と、前回保守点検を行った保守点検実施日とを保持するデータベースと、
主機器に接続する周辺機器情報を受け付ける受付手段と、
前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段と、
前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段と、
前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段と、
前記検索手段検索した該当する機器に、前記算出手段が算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理手段が管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段とを備える。
【0012】
【発明の実施の形態】
以下、添付図面に従って本発明にかかる実施形態を詳細に説明する。
【0013】
実施形態では、メンテナンス(保守点検)を必要とする製品の中の代表的な複写機及びそれに付随可能な周辺機器(ソータ、ネットワークプリンタとして機能する装置等)を例にして説明する。
【0014】
<全体の構成とその流れ>
先ず、複写機の製造に始まる一連の製品の流れ及び実施形態におけるシステムの全体の動作を説明する。
【0015】
複写機及びそれに接続可能な周辺機器が製造されると、それぞれユニークな機番(モデル名も判別可能な文字列)が付加され、中央倉庫に一旦に搬送される。中央倉庫では、搬送されてきた機番、及びその搬入日(もしくは製造日)をサブセンタのDB(データベース)に登録する。サブセンターに登録されたデータベース中の新規に登録された製品情報は、例えば一日に一回という頻度で、センタに設けられたサーバに通知される。センタはこれを受け、製品一つ一つに対する基礎フォームに、その製品のデータを登録する。これ以降、各製品に関する流通にかかる情報は、この基礎フォームを更新することで一元管理されることになる。すなわち、全ての国内販売店で販売される複写機の管理が開始する。
【0016】
尚、上記例では、中央倉庫に搬入されることをトリガにして、サブセンタ→センタへとデータの登録がなされるものとしたが、製造工場から出荷する際にサブセンタもしくはセンタに登録するようにしても構わない。
【0017】
また、一旦、サブセンタにデータをストアしてからセンタサーバにまとめて転送するのは、1つ1つの製品に搬入される度に送信するようにしてしまうと、回線使用回数が増えることによる通信費増大するためである。
【0018】
また、センタには、各製品を管理する上で、機番とモデル名との対応を示すDB、顧客や販売店を管理するDB等、複数のDBが稼動している。ここで言う、センタにおけるDBとは、DBシステムがそれぞれ独立した分散型システムでも良いし、1つのDBシステム内に複数のDBを構築しても良い。要は互いに関連する環境で全体のシステムを構築するものであればよい。
【0019】
さて、中央倉庫から、更に、地方の主だった倉庫に搬送される。各地方への搬送する台数は、各倉庫の規模や各地方の顧客数等を勘案されて行われる。配送手続きを行う者は、例えばハンディターミナルを用いて、製品に付加された機番と配送先の倉庫のコードを入力し(一般にバーコードを読み取る等して入力)、そのハンディターミナルに格納されたデータを所定の端末に転送することで、最終的にセンターに通知する。センタDBはこの通知を受け、各製品の所在位置を更新する。
【0020】
一方、販売店側には、センタと通信する端末が設置してあって、その動きは次のようになる。
【0021】
先ず、顧客から要望があった場合、その機種が最寄りの地方倉庫或いは中央倉庫に存在するか否かをセンタに対して問い合わせをする。センタは、全ての複写機並びにその周辺機器(以下、単に特に断りがない限り、複写機という)を管理しており、指示された倉庫の該当する機種の保管状況(台数)を販売店端末に通知する。販売店側では、在庫が確認できると、顧客向けの発送手続きをセンタに対して行う。また、在庫がない場合には、センタに対し、中央倉庫からの発送手続き申請する。この場合、センタは中央倉庫に対して、配送を指示することになる。尚、かかる配送業務にかかる処理内容の詳細については後述する。
【0022】
上記のようにして、顧客の所へ複写機が搬送されることになるが、販売店員は、複写機の到着時(或いはそれより前でも後でも構わない)に、ユーザーと保守契約書を作成する。
【0023】
保守契約書には、顧客の名称、住所、更には購入機種モデル、複写枚数等のカウンタチェックの期間間隔(何ヶ月単位にするか等)の情報を記述することになる。また、このとき、保守点検サービスの予定日、及び、期間間隔、そして保守点検を行う店名も記述する(販売店と保守点検サービスを行う店が同じでも構わない)。そして、この契約書を販売店に持ち帰り、端末を操作することで該当する機番(複写機)に対する情報と、その販売店のID及び保守点検サービスを行う店のIDも併せて登録し、その情報をセンタに通知する。センタは、この情報を受け、該当する機番の所在として顧客IDを割り当てる。尚、顧客はDB内でIDコードとして管理されており(IDコードと顧客との関係については別途DBが設けられている)、センタでは機番の基礎フォームの該当する領域を受け取ったデータで埋めていく。これ以降、その機番(複写機等)に対する保守点検のスケジュール管理、カウンタチェック日のスケジュール管理が開始される。
【0024】
保守点検を受け持つ店では、例えばメンテナンスする必要がある顧客を調べたい場合には、端末を操作して自身の店のIDを入力し、センタに接続する。そして、メンテナンスの状況を表示する指示を与える。センタは、接続依頼元の店のIDを既に取得しているわけであるから、その保守点検対象となっている保守サービス店の項目に、その店IDを持つデータを検索し、例えば顧客名を第1ソート、メンテナンス予定日を第2ソートのキーにしてその一覧をその店の持つ端末に転送する。これにより、保守サービス店側は、メンテナンスのスケジュールを行うことが可能になる。つまり、同じ顧客に対して幾つものメンテナンス対象の製品があれば、それらをまとめてメンテナンスを行う等に活用できるようになる。
【0025】
尚、実際にメンテナンスを行った場合には、その旨を機番毎にセンタに通知する。センタはこれを受けて、次回のメンテナンスの予定日を更新することになる。
【0026】
上記は、カウンタチェックについても同様である。ただし、カウンタチェックを行って、センタにそれを通知すると、センタは前回に受けたカウンタとの差分に1未満の所定比率を乗算した結果に基づいて請求書の作成を行う。尚、所定比率を乗算する理由は、顧客において或る頻度でジャム等のエラーがあったものとするためである。そのため、この比率に含まれるジャムエラー率は、実際のそれより多めにしてある。尚、カウンタチェック及びメンテナンスについてシステムの動作の詳細については後述する。
【0027】
請求書発行は、顧客の要望する様式が様々であるので、予め多数の請求書フォームを容易しておき、その顧客の要望に沿ったフォームを用いて印刷することになる。請求書には、取り引き金融機関(銀行名と口座番号)を付して印刷する。
【0028】
さて、上記は通常の使用における動作であるが、場合によっては、顧客は新しいモデルに替える、或いは追加することもあり得るし、単に従前に使用していた機種の引き取り、廃棄依頼を行うことも当然にあり得る。
【0029】
新機種への切り換え若しくは新規導入する場合の、その新機種の設置にかかる手続きについては上記の通りであるので、ここでは従前に使用していた機種の引き取りについて説明する。
【0030】
販売店が顧客より引き取りの依頼を受けると、所定の引き上げ業者に依頼を発行し、最寄りの処分所に配送を行うと共に該当する機番についての所有者情報として処分所のIDで置き換える。処分所に配送されてきた装置は、処分所において再利用できるかどうか(多くの場合には使用している部品に依存する)を判断され、廃棄所と再生所の2つのルートに分別され、それぞれに配送が行われる。廃棄書に搬送された装置について、処分所でその機番抹消手続きを行い、それをセンタに通知する。センタは、指示された機番に該当するデータをDBから削除する等の処理を行う。一方、再生所に配送された装置については、最寄りの地方倉庫又は中央倉庫へと配送され、それが再生作業がお粉割る。このとき、新たな機番(ただし、再生された製品化どうかを区別可能になっている)が付されるので、従前の機番に関する情報はDBより抹消する手続きを行う。再生処理は行われると、最寄りの地方倉庫又は中央倉庫へと配送される。倉庫側の端末では、再生所から配送されてきた機種について、その機番を新規にセンタに登録する依頼する。
【0031】
以上のようにして、製造されてから廃棄処理、更には再登録処理が繰り返され、全ての製品についてその所在を管理し、且つ、顧客に対するメンテナンス等の管理を一元管理することが可能になる。
【0032】
<センタの構成>
次に、実施形態におけるセンタにおけるDBシステムについて以下に詳述する。
【0033】
図2は、実施形態におけるセンタのDBシステムを構成する装置のブロック構成図である。
【0034】
図中、1は装置全体の制御を司るCPUであり、2はブートプログラムやBIOS等を記憶しているROM、3はCPU1の処理するプログラムを展開したり、ワークエリアとして使用されるRAMである。4はハードディスク装置であり、内部にはOS、DBシステムとして動作するサーバアプリケーションを格納する。また、図示に示すように、実施形態の中枢となる機番やその機種を管理する機番管理マスタDBを始め、それをサポートする顧客に関する顧客DB、販売店に関する販売店DB、請求書に関する請求書DB、請求先の振込時の振込人名称を管理する名寄せDBで構成される。
【0035】
ここで、顧客DBは、顧客ID、その顧客の住所、正式名称、電話、ファクシミリ等の顧客固有の情報を管理する。販売店DBは、その販売店或いはメンテナンスサービスを行う店のID、住所等を管理する。請求書DBは、請求先に対する多数の請求書フォームと、実際の請求書を構成する請求書データ等を管理するものである。名寄せDBは、請求書に対する請求先からの入金処理を効率的に実行するために、1つの請求先に対して使用された複数種類の振込人名称を請求先毎に逐次登録し管理するものである。
【0036】
これらのDBは全て機番管理マスタDBの補助するために存在する。
【0037】
5は各販売店、サービス店や倉庫等に設置された端末との通信接続するための通信インターフェースであり、6はキーボード、7は表示装置、8はセンタ内に設置されたネットワークに接続するためのネットワークインターフェースである。請求書の印刷を行うプリンタも、このネットワークに接続されている。
【0038】
上記構成において、実施形態における機番管理マスタDBのデータフォーマットは図3に示す構造を成している。図示は、1つの機番、つまり、1製品に関するデータフォーマットである。
【0039】
図示の項目の意味は以下の通りである。
【0040】
機番:文字とおり製品をユニークに識別する「機番ID」を格納する領域、
機種:機番からモデル名を特定するモデルコードを格納する領域(機番からだけでも機種が判別できるが、分かり易くするために設けた)、
作成日:該当する機番のデータを作成した日を格納する領域、
リンク情報:該当する機番が複写機である場合には、周辺機器があるか否かを示す情報が格納され、周辺機器である場合には接続する複写機の機番が格納される。
【0041】
顧客:顧客IDを格納する領域、
販売店:その製品を販売した店IDを格納する領域、
サービス店:製品の保守点検を行う店IDを格納する領域、
契約開始日:最新の契約日を格納する領域、
初回契約日:その機種の一番最初の契約日を格納する領域(「契約開始日」が何度も更新された中の最新の契約日であるのに対し、この「初回契約日」は最初の契約開始日となる)、
契約終了日:契約が満了する日を格納する領域、
契約期間:契約開始日からの月数が格納される領域、
締め予定日:その機番に対する請求書を発行する際の締め日を格納する領域、
締め予定サイクル:締めを行う月数を格納する領域、
保守予定日:保守点検を行う日を格納する領域、
保守サイクル:保守点検を行う間隔である月数を格納する領域、
前回保守日:前回保守点検した日を格納する領域、
前回締め日:コピー枚数をチェックした最新日を格納する領域、
前回値A,B,C…:前回チェックした際の累積コピー枚数(複写機が有するカウンタ値)を格納する領域、
今回値A,B,C…:今回チェックした際の累積コピー枚数を格納する領域である。
【0042】
ここで、カウンタを複数分確保したのは、以下の理由による。
【0043】
これまでのモノクロ複写機における課金の仕方は、1つのカウンタによるものであった。また、一般に知られているように、モノクロ複写機はA4,A3、B5,B4等複数の記録紙に複写できるものが多い。従って、課金の算定は、これら異なる用紙サイズを予め設定した比率で消費されることを見越し、コピー枚数から課金額を算定していた。しかしながら、専ら一方でサイズの小さい用紙しか消費しない顧客もあり得るので、上記課金は正しく算定できない。また、昨今の様に、カラー複写機が普及しつつあることで、モノクロ、カラーの切り分けも正しくさせないと、更に問題が発生するし、複写機をスタンドアロン装置として設置するのではなく、ネットワークプリンタとして機能させる周辺機器を導入してパーソナルコンピュータ(以下、PC)等のプリンタとして活用する場合、そのPCによる印刷枚数による課金は、複写時より低くしなければならない。
【0044】
そこで、本システムでは、用紙サイズについてはA4サイズ以下(B5を含む)、それより大きいサイズ(B4,A3等)サイズのいずれであるか、モノクロかカラーか、更には、複写によるものかPCよりの印刷かの3つの条件に見合うカウンタ値を格納する領域を確保した。3つの条件による組み合わせは、2の3乗=8通りの組み合わせが存在するから、上記の前回値の領域は8つ、今回値の領域も8つ備える。注意したいのは、全ての複写機にカウンタが8つ備えられていることを意味するものではない。つまり、カラー複写機単独で使用した場合には、PCによる印刷はできないわけであるから、使用する領域は前回値及び今回値とも4つになる。そして、そのカラー複写機が、ネットワークプリンタとして機能する周辺装置を接続可能で、実際にその周辺機器を接続して活用するようになると、上記カウンタが機能することになる。
【0045】
尚、複写機の周辺装置(ソータ(これにもステイプル機能付き等の様々なものがある)、ネットワーク接続装置等)には、カウンタに関する情報はない、もしくはその領域はあってもダミー扱いになる。
【0046】
上記構成において、製品が製造され、中央倉庫に搬入されセンタに通知を受けると、その機番に基づいて図3の新規レコードを作成することになる。この時に埋められるデータ項目は、機番、機種、作成日であり、顧客の欄には、その倉庫を示す店IDが格納されることになり、顧客に納品されると、顧客の欄にはその顧客のIDが埋められることになる。
【0047】
図4は、機番管理マスタDBについて或る機番(図示では機番「LGH06935」)をアクセスした際に表示される一例を示している。図示において、各矩形枠内にあるコロン“:”の右側が編集可能な領域であり、枠外に表示される文字列は、枠内にあるIDやコードに基づいて別DBを参照することで得られた結果を示している。
【0048】
図示によれば、機番“LGH06935”で示される機種は“6022”であり、顧客は顧客ID“L9-1111”の“ABC株式会社”である。その他については説明するまでもないであろう。尚、カウンタ値で今回のカウンタ値から前回のカウンタ値を差し引くことで、その間のコピー枚数を算出し、請求書の発行を行うことになる。入金が確認処理を行うことで、今回のカウンタ値が前回カウンタ値に置き換えられることになる。従って、図示では、前回の締め日が2000年2月15日であるので、その日に締めを行ってから入金がない状態を示していることになる。因に、この機番の顧客は、締め予定日は20日で、締めサイクルは2ヶ月であるので、次回の締め処理は2000年4月20日までに行うことになる。つまり、カウンタチェックはそれ以前に完了していることが必要になる。
【0049】
<納品処理の説明>
顧客から機種導入の要望を受けると、販売店員は、自身の店IDを入力し、センタにログインし、初期メニュー(不図示)中の「配送手続き」を選択して配送に係る操作を行う。具体的には、要望のあった1セット単位に機種番号(この段階では店員には機番は不明)とその台数を入力し、センタに通知する。尚、ここで言う1セットとは、例えば複写機A、それに付加するソータ及びネットワークプリンタとして機能する装置等がある場合には、それらのまとまりを言う。
【0050】
センタは、上記機種番号(複数でも良い)を受け付けるとそれをキーにして、機番管理マスタDBを検索する。検索された結果は、要請の合った販売店に近い倉庫を優先してソートし、その結果を販売店の端末に返す。このとき、各機種の機番が判明するので、機番も併せて販売店端末に通知し、その結果を表示させる。
【0051】
販売店は、これを受けて、配送指示を行うと、センタは該当する機番のうち、複写機の周辺機器である機番データ中のリンク情報に、複写機の機番を書き込み、複写機と周辺機器とのリンクを図る。そして、配送日として、所定日数後(例えば翌日)になることを販売店端末に通知すると共に、該当する倉庫の端末に発呼し、該当する機番の装置を顧客宛に上記の配送日に配送するよう要求する。
【0052】
尚、既に顧客で使用されている複写機に対する周辺機器を配送手続きを行う場合もある。この場合には、例えばその複写機の機種番号ではなく、機番を入力し、それに接続する周辺機器の機種番号を上記のようにして入力する。
【0053】
センタは、複写機の機番が指定されることで、該当する機番と、新規導入する周辺機器の機番とのリンクを張ることになる。
【0054】
図5は、最終的にセンタから販売店に通知される配送処理結果の画面の一例を示している。図示において、「新」とは、新規導入機器であることを示しており、図示の場合には3つの製品とも同じ倉庫に在庫があって、2000年4月20日に配送手続きを行うことを示している。顧客が現に使用している複写機に対して周辺機器を導入する場合には、その複写機については「新」は表示されない。いずれにしても、複写機と周辺機器とのリンクが確立することに変わりはない。
【0055】
センタのDBシステムにおけるCPU1の動作処理としては、図6に示すフローチャートになろう。尚、以下は、販売店からのログインが完了して、「配送手続き」が指示され、販売店より機種番号の通知を行った場合の処理である。
【0056】
先ず、ステップS1において、販売店よりの情報を入力する。次いで、ステップS2に進み、該当する機種を機番管理マスタDBから検索し、その販売店に最寄りの機番データを抽出する。そして、ステップS3に進み、配送可能日(ログイン日+所定日数)を設定し、ステップS4で、検索結果得られた機番と共に販売店端末に通知し、ステップS5で販売店端末よりの返答を待つ。
【0057】
OKの指示があった場合には、ステップS6に進み、配送依頼のあった各機番のリンクを張る処理を行う。勿論、1台の複写機のみの場合には、この処理は行わない。
【0058】
そして、ステップS7に進み、該当する機番を管理している倉庫に対して機番と、配送予定日を通知する。
【0059】
尚、上記例では、配送を行うときに、複写機とその周辺機器とのリンクを行ったが、配送が完了した後に、各販売店は顧客に設置処理する際の接続状態から選択にセットの機番を列挙し入力することで、リンクの確立を図っても構わない。
【0060】
<保守点検の説明>
次に、サービス店における保守点検に関して説明する。
【0061】
保守点検は、1セット単位に行われる。つまり、1つの複写機に、1乃至複数の周辺機器が接続された状態で使用されている場合には、それらをまとめて保守点検対象とする。実施形態では、上記の通り、複写機とその周辺機器とは、機番管理マスタDB内ではリンクされた状態で管理されているから、都合が良い。
【0062】
さて、保守サービスを行う店(以下、サービス店)では、毎月、自店が管轄する複写機及びその周辺機器について保守点検を行うスケジュールを立てる必要がある。
【0063】
このため、サービス店側では端末からセンタへ、自店IDを用いてログインし、初期メニュー(不図示)中の「保守サービス」を選択する。
【0064】
この結果、センタ側のシステムは、その店IDをサービス店IDとして格納されているデータを検索する。そして、得られた機番データ中の、前回保守日にその保守サイクル(月数)を加算した月の、「保守日」の欄に格納されている月日を算出し、それをソートしてサービス店の端末に通知する。このとき、周辺機器が接続されている複写機については、その周辺機器も含めて通知する。サービス店では、受信したデータを表示もしくは印刷することになる。
【0065】
図7はその出力例を示している。図示の場合、機番LGH06931に対しては、周辺機器である機番XY112334及びPQ243310(例えばソータやネットワーク接続装置)が接続されていることを示している。
【0066】
サービス店側では、この出力結果を受け、実際に行う保守点検日のスケジュールや、準備する器材の準備を行うことになる。
【0067】
センタのCPU1は、上記処理を行う場合には、図8に示すフローチャートに従って動作することになる。
【0068】
先ず、ステップS11で、ログインに使用したIDに合致するサービス店IDを持つデータを機番管理マスタDBから検索する。次いで、ステップS12において、得られたデータにある前回保守日に、保守サイクル(月)を加算した結果の年月を求め、残りの日については機番データ中の「保守日」を使用し、次回の保守点検予定日を算出する。そして、ステップS13に進み、複写機本体とセットになる複写機とのリンク処理を行い(複写機の機番+周辺機器の機番の文字列を作成する)、ステップS14でその結果を要求元のサービス店の端末に通知する。
【0069】
尚、ログインした日以降に保守点検予定日があるものと、それより前に予定日があるもの(保守点検が未完のデータ)を識別可能(例えば色を替えるとか、別々にして表示する等)にして表示するようにしてもよい。
【0070】
また、保守点検が完了した場合には、センタにログインし、保守点検の完了手続きを行う。ここでは、機番と、保守点検を行った日を入力し、センタに通知する作業であるので、説明するまでもないであろう。センタは、通知を受けた機番データ内の「前回保守日」の欄を更新する。
【0071】
<カウンタチェックの説明>
販売店員は、顧客との契約で設定した時期になると、その顧客が有する複写機内のカウンタをチェックし、それをセンタに通知する。センタはこれを受けて、前回のカウンタとの差分から課金額を算定し、顧客に対して請求書を発行することになる。ここでは、このカウンタチェックにおけるスケジュールについて説明する。
【0072】
販売店では、毎月、自店が管轄する複写機についてカウンタチェックの作業のスケジュールを立てる必要がある。
【0073】
このため、販売店側の端末からセンタへ、自店IDを用いてログインし、初期メニュー(不図示)中の「カウンタチェック」を選択する。これにより、入力画面が表示されるので、ここにデータを埋め込み、最後に送信キー(図示せず)を押下する。
【0074】
センタ側のシステムは、上記内容を受信すると、その店IDを販売店IDとして格納されている機番データを検索する。そして、得られた機番データ中の、前回締め日の年月に、締めサイクルで示される月数を加算する。そして、その加算結果の年月に「締め日」の欄に格納されている日数を追加することで、最終的に年月日を算出し、それを通知する。販売店側では、受信したデータを表示もしくは印刷し、締め日に間に合うよう各顧客の複写機内のカウンタチェックを行う。
【0075】
尚、上記の販売店側における出力形態は、先に示した図7と同様であり、それを出力するセンタ側の処理も、上記の「保守点検の説明」からすれば容易に理解できるであろうから、その説明は省略する。
【0076】
また、販売店が実際にカウンタチェックを行った場合には、その機番と計数値を入力し、センタに通知するだけでよい。
【0077】
図9は、この通知処理における画面の例を示している。図示の如く、入力する項目は、機番、チェック日、各カウンタの値で構成される。
【0078】
尚、先に説明したように、機番によりその複写機がモノクロ複写機かどうか、及び、その複写機に周辺装置としてパーソナルコンピュータのプリンタとして機能するネットワーク接続装置が接続されているかはセンタ側で把握できているので、例えばモノクロ複写機である場合に、カラーのカウンタ値を入力しても無視される。
【0079】
また、この表示画面はセンタからの情報に基づいて表示されるので、機番を先ず入力し、その後に設定画面を送信するようにすれば、その機番に適したカウンタの入力画面を送信することもできる。つまり、カウンタ値を入力する個数も、その機番及び周辺機器の接続形態に依存したものとすることができる。
【0080】
いずれにせよ、入力した内容をセンタに通知すると、センタ側のシステムは該当する機番データ内の今回値の中に、受信した値を書き込む処理を行う。
【0081】
この後、センタ側では、毎日、機番管理マスタDB内の今回値の内容を調べ、それが格納されている機番データを探し出す。そして、その機番データから顧客IDを抽出し、顧客に対して請求書を発行することになる。
【0082】
尚、請求書に対して、振り込みの通知が提携金融機関よりあった場合、その今回のカウンタ値を前回カウンタ値に書き込み、今回のカウンタ値をリセットし、次回に備える。
【0083】
<センタ側の管理の説明>
以上のように、全販売店或いはサービス店からの情報により、各機番(製品)のデータはその都度更新され、次回の業務に必要な情報が構築することが可能であるが、各販売店やサービス店の業務の効率化を図るための指針情報を構築し、各店に通知することも可能になる。
【0084】
例えば、カウンタチェックを行うことで、その顧客に対して請求書を発行する処理に移行することができるものの、逆に、カウンタチェックを行わないと業務上の収入がないことになる。
【0085】
上記のシステムにすることで、締め予定日を過ぎても該当する機番(複写機)のカウンタの入力がないものを検索することは容易である。また、各機番データには、販売店のIDも含まれているので、販売店毎の締め作業がどの程度進行しているのかを把握することも容易にできるようになる。
【0086】
そこで、センタでは、毎月、各販売店の締め率(例えば前月に締めがあった顧客数を分母にし、締めを行った顧客数を分子にした割合)を算出し、全ての販売店或いは地域に含まれる店の締め率を閲覧可能にして作成する。
【0087】
販売店は、センタにログインした際に、その閲覧を指示することで、例えば図10に示すようなデータがセンタから受信し、表示する。これにより、他の販売店の業務の遂行と比較して自店の業務内容を把握できることが可能になり、業務遂行の1つの指標を与えることもできるようになる。
【0088】
<請求書発行処理>
次に、請求書発行処理について、以下に詳述する。
【0089】
上述したように、顧客は、受領する請求書のレイアウトに様々な要望があるので、請求書DBには、予め多数の請求書フォームを用意し管理しておく。その一例を、以下の図11に示す。
【0090】
図11(a)に示すように、請求書は、請求先に対し、機番単位で請求書を出力する。つまり、請求先が抱えている複写機やその周辺機器の各機番の数だけ、請求書が発行される。
【0091】
また、請求先によっては、自身が抱えている複写機やその周辺機器に対する請求を一括して受領したい場合もある。そこで、図11(b)に示すように、請求先が抱えている複写機やその周辺機器に対する請求をまとめ、それを1枚の請求書にして発行する。
【0092】
更に、複数の部署を有する企業等では、各部署が抱えている複写機やその周辺機器に対する請求を一括して受領し、尚かつ、各部署の請求内訳を把握したい場合もある。そこで、図11(c)に示すように、請求先の各部署が抱えている複写機やその周辺機器に対する請求を、各部署毎にまとめ、更に、それらを1枚の請求書にして発行する。
【0093】
これ以外にも、支店や支所毎の請求を1枚の請求書にして発行したり、複写機1台毎、複数台毎、部署や支店、支所、課、人(担当者)等の所定単位毎に、それぞれの請求書にして発行したりすることが可能である。もちろん、この場合は、請求書DBに必要な請求書フォームが用意されていることは言うまでもない。また、顧客によっては、請求書に用いる印刷用紙のサイズや、印刷枚数、向き(A4縦、A4横等)等を要望する場合があるので、請求書フォームに、印刷用紙のサイズ、印刷枚数、向き等を指定する印刷情報を付加し、この印刷情報に基づく印刷が可能なプリンタから請求書を印刷するようにすることもできる。
【0094】
尚、これらの請求書フォームは、各フォーム毎に請求書フォーム番号が付加されており、この請求書フォーム番号は、顧客IDに対応する顧客情報として、顧客DBに管理されている。
【0095】
請求書の発行は、基本的には、販売店が行い、各販売店に用意されている端末を用いて行う。請求書を発行する場合、販売店は、まず、請求書を発行するための専用画面(請求書発行画面)を端末上で表示する。請求書発行画面には、顧客名、管轄のサービス店名、販売店名、請求先名、顧客が抱えている複写機やその周辺機器の機番、機種番号、請求書フォーム番号等を表示/入力する領域を有している。その画面例を、図12に示す。但し、この画面例は、あくまでも一例であり、必要に応じて各種情報を表示/入力するための領域を構成できることは言うまでもない。
【0096】
この図12を用いて、請求書発行画面を構成する各領域について説明する。
【0097】
図12において、1200は顧客IDを入力する領域であり、ここに、顧客IDを入力すると、顧客IDに対応づけて顧客DBで管理されている顧客情報(例えば、顧客名、請求書フォーム番号、機番、機種番号等)が検索され、顧客名が領域1201、請求書フォーム番号が領域1203、機番、機種番号が領域1205にそれぞれ呼び出される。また、ボタン1204は、請求書フォーム番号を変更する場合に使用し、このボタン1204を操作すると、現在使用可能な請求書フォーム番号のリストが表示され、所望の請求書フォーム番号を選択して入力することができる。1202は販売店員が所属している販売店、サービス店等を表示する領域である。
【0098】
同様に、領域1205の各請求項目の欄には、ボタン1204と同等の機能を果たすボタンが用意されており、販売店員は、これらのボタンを操作すると、頻繁に使用する請求項目のリストが表示され、所望の請求項目を選択して入力することができる。もちろん、直接手入力で、所望の請求項目を入力することも可能である。また、選択されたあるいは入力された請求項目が、特に、複写機の複写枚数を示すカウンタ値の場合は、上述の機番管理マスタDBで管理されている機番IDに対応する請求対象のカウンタ値と複写機のコピー単価と上述したジャムエラー率等を考慮した所定比率を参照して、今回請求する請求代金を自動計算して請求代の欄に表示する。それ以外にも、自動計算が可能な請求項目に関しては、同様に、自動計算して請求代の欄に表示し、そうでない請求項目に関しては、販売店員が直接請求代の欄に請求代金を入力する。
【0099】
1206は請求書作成ボタンであり、領域1205に必要な各請求項目毎の請求代金を入力した後に、この請求書作成ボタン1206を操作すると、指定された請求書フォーム番号に対応する請求書フォームを請求書DBから取得し、また、請求書番号や請求代の入金を行うための請求先コード、入金確定/未確定を示す入金確定/未確定フラグ等の請求書管理情報をセンタから取得して、取得した請求書フォーム、請求書管理情報、請求書発行画面で入力された請求書データ(請求項目、請求代等)に基づいて請求書を作成し印刷する。同時に、請求書データ及び請求書管理情報は、請求書DBに顧客毎に管理される。また、請求書を作成した旨をセンタに通知し、この通知に基づく処理をセンタは実行する。
【0100】
以上の請求書発行処理のフローチャートを示すと、図13のようになる。以下同フロー参照して、図1及び図2に示すセンタのシステムの作動を説明する。
【0101】
まず、ステップS1301で、販売店員は請求書発行画面を販売店の端末上に表示させる。ステップS1302で、端末より入力された情報をセンタCC側に請求先の顧客IDを入力する。ステップS1303で、入力された顧客IDに基づいて、センタCCのCPUは請求書発行画面に表示された請求対象の機番に対し、それぞれ請求項目、請求代を入力あるいは自動計算し、端末側の請求書作成ボタンを操作する。ステップS1304で、指定された請求書フォームに対応する請求書フォームを請求書DBから取得し、取得した請求書フォームと請求書発行画面で入力された請求書データ、更にセンタCCが生成する請求書管理情報に基づいて請求書を作成し、端末のプリンタで印刷する。一方で、センタCC側では、処理対象の請求書に対する請求書管理情報(請求書番号、請求先コード、入金確定/未確定フラグ等)を生成しており、処理対象の請求書のデータと対応づけて請求書DBに記憶して登録する。
【0102】
<自動入金処理>
次に、自動入金処理について説明する。これは、発行した請求書に対する請求先からの入金を確認し、確定する処理である。
【0103】
請求先からの入金には、様々な入金形態があり、例えば、自動振替、銀行振込、集金等がある。特に、入金が銀行振込の場合には、請求先の振込時の振込人名称には、その振込処理を行う人間によって異なる場合が多々ある。例えば、カタカナ株式会社の振込人名称としては、その振込人によって「カタカナ(カブ)」であったり、「カタカナカブシキカイシャ」であったりする。
【0104】
そのため、請求先からの入金を確認する販売店では、確認用の請求先の振込人名称(基本振込人名称)が1つだけしか存在しないと、処理対象の入金の振込人名称が1字でも違ってしまうと、正しい請求先からの入金であっても、それを正しいと認識することができない。そこで、請求先の振込人名称が複数種類存在することがあることを考慮して、基本振込人名称以外に、それと同じものとみなせる振込人名称が発生する毎に、その基本振込人名称に対応する振込人名称として逐次登録し管理する上述の名寄せDBを構成する。つまり、この名寄せDBを参照し、処理対象の入金の振込人名称と一致する振込人名称が存在すれば、正しい請求先からの入金であるものとして、以降の処理を進めることができる。
【0105】
ここで、名寄せDBのデータフォーマットについて、図14に示す。
【0106】
図14に示すように、各顧客ID毎に、基本振込人名称が対応づけてられており、更に、基本振込人名称以外で振込人名称として用いられる可能性がある振込人名称のグループとして名寄せ項目に登録されている。この名寄せ項目に登録される振込人名称は、事前に顧客から通知を受けた振込人名称であったり、販売店員が顧客に対して確認した振込人名称であったりする。
【0107】
次に、自動入金処理処理の詳細について、以下、説明する。
【0108】
センタあるいは販売店は、定期的に提携金融機関に対して入金確認を行い、なにかしらの入金があった場合には、その入金に関する入金データ(請求コード、それに付随する振込人名、入金日、入金額)を取得することができる。但し、請求コードの入力は、請求先に依存してしまうので、必ず入金データに対して存在するものではない。
【0109】
次に、自動入金処理の詳細について、以下、説明していく。
【0110】
上述の自動入金処理を実行する場合、販売店は、まず、処理対象の入金を確認するための専用画面(自動入金確認画面)を端末上で表示する。自動入金確認画面には、請求先を示す請求先コード、振込人名、入金日、入金額、管轄のサービス店名、販売店名等を表示/入力する領域を有している。その画面例を図15に示す。但し、この画面例は、あくまでも一例であり、必要に応じて各種情報を表示/入力するための領域を構成できることは言うまでもない。
【0111】
この図15を用いて、自動入金確認画面を構成する各領域について説明する。
【0112】
図15において、入金データを取得すると、その入力データから得られる各種データが指定の領域に呼び出される。1501は請求先コードを表示する領域であり、1502は振込人名を表示する領域1502、1503が入金日を表示する領域1503、1504が入金額を表示する領域1504である。但し、上述したように、入金データ中には請求コードは必ずしも存在しないので、そのような場合は、販売店員が適宜、必要な情報を各領域に入力する。もちろん、集金等で現金で請求代を領収した場合には、販売店員が必要な情報を各領域に入力する。1505は販売店員が所属している販売店、サービス店等を表示する領域である。
【0113】
1506は入金チェックボタンであり、上記の各領域に必要な情報が入力された後に、この入金チェックボタン1506を操作すると、処理対象の入金が正しい請求先からのものであるか否かをチェックし、そのチェック結果に応じて処理を実行する。
【0114】
以下、この入金チェックを含む自動入金処理のフローチャートを図16に示す。以下同フロー及び図1、2を参照して、動作を説明する。
【0115】
ます、ステップS1601で、販売店員は、販売店の端末上に表示させた自動入金確認画面に対し、端末からの入金処理対象の入金データをセンタCCのシステムに入力する。ステップS1602で、端末から自動入金確認画面内の入金チェックボタンが操作されたかをチェックする。ステップS1602で、自動入金確認画面に請求コードが入力されているか否かを端末、センタCCがチェックする。請求コードがある場合、ステップS1605に進む。一方、請求コードがない場合、ステップS1603に進む。
【0116】
ステップS1603で、センタCCのCPUは振込人名称が名寄せDBに存在するか否かを判定する。存在する場合、ステップS1605に進む。一方、存在しない場合、ステップS1604に進み、センタCCのCPで新規振込人名称に対応する基本振込人名称を決定し、名寄せDBに記憶して登録する。
【0117】
ステップS1605で、入金額をチェックする。このチェックは、ステップS1605に到達するまでの上記ステップ群の経路によって、処理内容が異なっている。
【0118】
まず、ステップS1602からステップS1605に到達した場合、つまり、請求先コードが存在する場合には、センタCCのCPUで請求コードに対応する請求先の未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップS1607に進み、正しい入金が行われたものとして、その入金を確定し、センタCCのCPUで、その入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを確定状態にする。一方、一致しない場合、ステップS1606に進み、その入金は未処理とし、また、センタCCのCPUで入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを未確定状態にする(但し、入金確定/未確定フラグは、初期状態で、未確定状態になっているので、実際には、この未確定状態にするための処理は行われない)。その後、後述する未処理入金一覧を出力する。
【0119】
また、ステップS1603からステップS1605に到達した場合、つまり、請求先コードが存在せず、名寄せDBに登録されている振込人名称である場合には、センタCCのCPUでその振込人名称に対応する基本振込人名称の請求先で、未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップS1607に進み、正しい入金が行われたものとして、その入金を確定し、センタCCのCPUでその入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを確定状態にする。一方、一致しない場合、ステップS1606に進み、その入金は未処理とし、また、センタCCのCPUで入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを未確定状態にする(但し、入金確定/未確定フラグは、初期状態で、未確定状態になっているので、実際には、この未確定状態にするための処理は行われない)。
その後、後述する未処理入金一覧を出力する。
【0120】
また、ステップS1604からステップS1605に到達した場合、つまり、請求先コードが存在せず、名寄せDBに新規な振込人名称が登録された場合には、その振込人名称に対応する基本振込人名称の請求先で、未処理の請求代と入金額を比較する。この比較の結果、請求代と入金額が一致する場合、ステップS1607に進み、正しい入金が行われたものとして、その入金を確定し、その入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを確定状態にする。一方、一致しない場合、ステップS1606に進み、その入金は未処理とし、また、センタCCのCPUで入金に対する請求書に対応する請求書管理情報の入金確定/未確定フラグを未確定状態にする。その後、後述する未処理入金一覧を表示装置あるいはプリンタに出力する。
【0121】
上述したように、ステップS1606で、処理対象の入金が未確定となると、未確定の入金群を一覧にした未処理入金一覧を生成し出力する。この未処理入金一覧は、未確定の入金群が所定数以上発生した後に出力するようにしても構わないし、未確定の入金が発生する毎に逐次その未処理入金一覧に出力するようにしても構わない。ここでいう出力とは、端末上の表示装置への出力、端末に接続されるプリンタへの出力、端末に接続されるネットワークへの出力等を含む。
【0122】
図16における自動入金処理における請求先を特定するための各種判定は(例えば、ステップS1602、ステップS1603等)は、これに限定されるものではない。より精度を高めるために、例えば、振込人である請求先の振込銀行や、電話番号、住所等の振込人である請求先を特定できる情報に関する判定を適宜追加することができる。
【0123】
<変形例>
上述した請求書発行処理は、販売店側が印刷した請求書を請求先である顧客に送付する構成としたが、この請求書を電子データ(電子請求書)として、例えば、インターネット等のネットワークを介して顧客に送信するような構成にすることもできる。但し、電子請求書の正当性及び秘匿性を維持し、証明するために、例えば、電子請求書は既存の電子署名技術を用いて販売店と顧客間で送受信する。また、汎用性及び利便性を高めるため、電子請求書(例えば、図17)には販売店の公開鍵を管理する認証局(例えば、日本ベリサイン社等の第三者認証機関)のネットワーク上のアドレス(例えば、URL)を記述しておき、顧客は受信した電子請求書に記述されている認証局へアクセスして販売店の公開鍵を取得させるように構成する。
【0124】
以下、その具体例を図18を用いて説明する。
【0125】
販売店は、認証局から顧客の公開鍵を受信し、その公開鍵を用いて電子請求書を暗号化し、生成される暗号文を顧客へ送信する。同時に、電子請求書をハッシュ関数を用いて回復不能文を作成し、これを販売店自身の秘密鍵を用いて回復不能文を暗号化し、生成される回復不能暗号文を顧客へ送信する。
【0126】
一方、顧客は、受信した電子請求書の暗号文を顧客自身の秘密鍵を用いて復号化し、電子請求書を取得する。また、この電子請求書は、ハッシュ関数を用いて回復不能文を作成する。次に、取得した電子請求書に記述されている認証局へアクセスし、販売店の公開鍵を取得し、別途販売店から受信した回復不能文をその公開鍵を用いて復号化し、回復不能文を復元する。そして、この回復不能文と既にハッシュ関数を用いて作成した回復不能文とを比較し、一致していれば、改善されていない正規の請求書として判断することができる。
【0127】
尚、図18では、ネットワークを介して販売店から顧客へ電子請求書を送信するような構成としたが、上述したセンタに各販売店からの電子請求書を一旦を収集し、センタから各顧客へ送信するようにすることもできる。このようにすることで、各販売店で発行される電子請求書をセンタで一元管理することができ、より効率的に処理を行うことができる。
【0128】
尚、上記実施形態における各倉庫や販売店等に設置される端末、及び、センタに設置されるサーバは、基本的に汎用の情報処理装置やワークステーション等で構成することが可能である。
【0129】
つまり、本発明は、上記実施形態を実現するための装置及び方法及び実施の形態で説明した方法を組み合わせて行う方法のみに限定されるものではなく、上記システム又は装置内のコンピュータ(CPUあるいはMPU)に、上記実施の形態を実現するためのソフトウエアのプログラムコードを供給し、このプログラムコードに従って上記システムあるいは装置のコンピュータが上記各種デバイスを動作させることにより上記実施の形態を実現する場合も本発明の範疇に含まれる。
【0130】
また、この場合、前記ソフトウエアのプログラムコード自体が上記実施の形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、具体的には上記プログラムコードを格納した記憶媒体は本発明の範疇に含まれる。
【0131】
この様なプログラムコードを格納する記憶媒体としては、例えばフロッピーディスク,ハードディスク,光ディスク,光磁気ディスク,CD−ROM,磁気テープ,不揮発性のメモリカード,ROM等を用いることができる。
【0132】
また、上記コンピュータが、供給されたプログラムコードのみに従って各種デバイスを制御することにより、上記実施の形態の機能が実現される場合だけではなく、上記プログラムコードがコンピュータ上で稼働しているOS(オペレーティングシステム)、あるいは他のアプリケーションソフト等と共同して上記実施の形態が実現される場合にもかかるプログラムコードは本発明の範疇に含まれる。
【0133】
更に、この供給されたプログラムコードが、コンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能格納ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって上記実施の形態が実現される場合も本発明の範疇に含まれる。
【0134】
【発明の効果】
以上説明したように本発明によれば、各サービス店(販売店兼用の場合も当然にあり得る)が管理する機器を一元管理すると共に、複写機等の主機器とその周辺機器の使用状況を含めた、スケジュール管理を行い、その情報をサービス店に提供することが可能になる。
【図面の簡単な説明】
【図1】実施形態における製品管理システムにおける全体構成と製品及び情報の流れを模式的に示す図である。
【図2】実施形態におけるセンタにおける装置のブロック構成図である。
【図3】実施形態における機番管理マスタデータベースにおけるデータフォーマットを示す図である。
【図4】機番管理マスタデータベースにおける機番データの表示画面の一例を示す図である。
【図5】配送手続きの通知画面の例を示す図である。
【図6】センタ側における配送手続き処理手順を示すフローチャートである。
【図7】保守点検予定一覧の表示例を示す図である。
【図8】センタ側における保守点検予定一覧を作成する処理手順を示すフローチャートである。
【図9】実施形態におけるカウンタ入力画面の一例を示す図である。
【図10】実施形態における各点の締め率一覧の出力例を示す図である。
【図11】実施形態における請求書フォームの構成例を示す図である。
【図12】実施形態における請求書発行画面の一例を示す図である。
【図13】販売店側における請求書発行手順を示すフローチャートである。
【図14】実施形態における名寄せDBのデータフォーマットを示す図である。
【図15】実施形態における自動入金確認画面の一例を示す図である。
【図16】販売店側における自動入金手順を示すフローチャートである。
【図17】実施形態における電子請求書の一例を示す図である。
【図18】実施形態における電子署名技術を用いた電子請求書の発行例を示す図である。

Claims (5)

  1. 各保守サービス店が保守点検をする対象の主機器及びその周辺機器の前記保守点検のスケジュールを、一元管理する機器管理システムであって、
    前記各保守サービス店の端末と通信する通信手段と、
    前記主機器に対してユニークに付与された機番情報と、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報と、前回保守点検を行った保守点検実施日とを保持するデータベースと、
    主機器に接続する周辺機器情報を受け付ける受付手段と、
    前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段と、
    前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段と、
    前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段と、
    前記検索手段検索した該当する機器に、前記算出手段が算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理手段が管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段と
    を備えることを特徴とする機器管理システム。
  2. 更に、前記サービス店の端末より保守点検の完了通知を前記通信手段より受けた場合、該当する機器の前回保守点検実施日を更新する手段を備えることを特徴とする請求項第1項に記載の機器管理システム。
  3. 前記主機器は複合機であることを特徴とする請求項1又は請求項2のいずれか1項に記載の機器管理システム。
  4. 各保守サービス店の端末と通信する通信手段と、主機器に対してユニークに付与された機番情報、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報、並びに、前回保守点検を行った保守点検実施日保持するデータベースとを有し、前記各保守サービス店が保守点検する対象の主機器及びその周辺機器を、一元管理する機器管理システムの制御方法であって、
    受付手段が、主機器に接続する周辺機器情報を受け付ける受付工程と、
    管理手段が、前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理工程と、
    検索手段が、前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索工程と、
    算出手段が、前記検索工程により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出工程と、
    通知手段が、前記検索工程で検索した該当する機器に、前記算出工程で算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理工程で管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知工程と
    を有することを特徴とする機器管理システムの制御方法。
  5. 各保守サービス店の端末と通信する通信手段と、主機器に対してユニークに付与された機番情報、前記主機器に対して保守サービスを行う保守サービス店を特定する保守サービス店情報、並びに、前回保守点検を行った保守点検実施日保持するデータベースとを有するコンピュータに読み込ませ実行させることで、前記コンピュータを、前記各保守サービス店が保守点検する対象の主機器及びその周辺機器を、一元管理する機器管理システムとして機能させるコンピュータプログラムであって、
    前記コンピュータを、
    主機器に接続する周辺機器情報を受け付ける受付手段、
    前記受け付けた周辺機器情報を前記主機器の機番情報とリンクさせて管理する管理手段、
    前記保守サービス店の端末から、保守サービス店情報を含む次回の保守点検予定日の問い合わせがあったとき、当該保守サービス店の保守サービス店情報をキーにして前記データベースを検索する検索手段
    前記検索手段により得られた機番情報の前回の保守点検実施日に保守サイクルを加算し、次回の保守点検予定日を算出する算出手段、
    前記検索手段で検索した該当する機器に、前記算出手段で算出した次回の保守点検予定日と、保守点検対象となる主機器の機番情報及び前記管理工程で管理する当該主機器に接続される周辺機器情報とをセットにしたリストを次回の保守点検予定日でソートし、前記通信手段を介して、問い合わせ元の保守サービス店の端末に通知する通知手段、
    として機能させることを特徴とするコンピュータプログラム。
JP2001072557A 2001-03-14 2001-03-14 機器管理システム及びその制御方法及びコンピュータプログラム Expired - Fee Related JP4638992B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001072557A JP4638992B2 (ja) 2001-03-14 2001-03-14 機器管理システム及びその制御方法及びコンピュータプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2001072557A JP4638992B2 (ja) 2001-03-14 2001-03-14 機器管理システム及びその制御方法及びコンピュータプログラム

Publications (3)

Publication Number Publication Date
JP2002269460A JP2002269460A (ja) 2002-09-20
JP2002269460A5 JP2002269460A5 (ja) 2008-04-24
JP4638992B2 true JP4638992B2 (ja) 2011-02-23

Family

ID=18930123

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001072557A Expired - Fee Related JP4638992B2 (ja) 2001-03-14 2001-03-14 機器管理システム及びその制御方法及びコンピュータプログラム

Country Status (1)

Country Link
JP (1) JP4638992B2 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004355134A (ja) * 2003-05-27 2004-12-16 Manabu Mizoguchi 作業者選定システムおよび作業者選定プログラム
JP2009015704A (ja) * 2007-07-06 2009-01-22 Ishikawajima Transport Machinery Co Ltd 駐車装置の保守点検システム
JP6024385B2 (ja) * 2012-10-24 2016-11-16 大日本印刷株式会社 メンテナンス情報編集装置、メンテナンス提案装置、メンテナンス情報編集方法及びメンテナンス情報編集プログラム
JP6055792B2 (ja) * 2014-05-30 2016-12-27 京セラドキュメントソリューションズ株式会社 営業支援システムおよび営業支援プログラム
JP6055791B2 (ja) * 2014-05-30 2016-12-27 京セラドキュメントソリューションズ株式会社 営業支援システムおよび営業支援プログラム
JP6068421B2 (ja) 2014-11-21 2017-01-25 京セラドキュメントソリューションズ株式会社 保守サーバー、保守方法およびライセンス・保守管理サーバー
JP6028048B2 (ja) * 2015-01-23 2016-11-16 京セラドキュメントソリューションズ株式会社 デバイス管理システム
JP6464948B2 (ja) * 2015-07-13 2019-02-06 京セラドキュメントソリューションズ株式会社 ライセンス管理システムおよびライセンス管理方法
JP6304153B2 (ja) * 2015-07-13 2018-04-04 京セラドキュメントソリューションズ株式会社 ライセンス管理システムおよびライセンス管理方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161400A (ja) * 1994-12-07 1996-06-21 Hitachi Building Syst Eng & Service Co Ltd 携帯工器具指示装置
JP2000305886A (ja) * 1999-04-26 2000-11-02 Ricoh Co Ltd 遠隔画像形成装置保守支援システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08161400A (ja) * 1994-12-07 1996-06-21 Hitachi Building Syst Eng & Service Co Ltd 携帯工器具指示装置
JP2000305886A (ja) * 1999-04-26 2000-11-02 Ricoh Co Ltd 遠隔画像形成装置保守支援システム

Also Published As

Publication number Publication date
JP2002269460A (ja) 2002-09-20

Similar Documents

Publication Publication Date Title
US5319544A (en) Computerized inventory monitoring and verification system and method
US8239296B2 (en) System and method of assisting goods collection and recording medium
JP3766022B2 (ja) 商品回収支援コンピュータシステム
JP4638992B2 (ja) 機器管理システム及びその制御方法及びコンピュータプログラム
JP4675760B2 (ja) 古紙回収管理装置、及び古紙回収管理方法
JP6528432B2 (ja) 課金管理システム、第1管理装置、第2管理装置、及びプログラム
JP2002269482A (ja) 機器管理システム及びその制御方法及び記憶媒体、プログラム
JP2014232416A (ja) ジョブ管理サーバー及び広告配布システム
JP2002183833A (ja) 画像出力システム
JP4630470B2 (ja) 情報処理装置及び方法及びプログラム記憶媒体並びにプログラム
US20060070071A1 (en) Instruction file execution device, instruction file execution method and job flow system
JP2005346067A (ja) 画像出力方法、画像出力装置及び画像出力プログラム
JP2002269269A (ja) 機器管理システム及びその制御方法及び記憶媒体及びコンピュータプログラム
JP2002269268A (ja) 機器管理システム及びその制御方法及び記憶媒体、プログラム
JP2002245346A (ja) 画像出力装置及び画像出力方法
JP2001209696A (ja) 情報管理方法及びそのシステム
JP2002269476A (ja) 請求書発行装置及びその制御方法及び記憶媒体、プログラム
JP2002269179A (ja) 機器管理システム及びその制御方法
JP2003085454A (ja) 複写システムおよび課金方法
JP2003108356A (ja) ユーザ端末装置、サービス情報提供装置、サービス情報提供システム、サービス情報受信方法、サービス情報提供方法、プログラム、及び記憶媒体
JP2004086429A (ja) 商品代金決済システムおよびその端末装置と管理サーバのプログラム
JP2004213182A (ja) 広告配信システム、サーバ、複写機、及びプログラム
JP2002354178A (ja) 請求書印刷代行システム、請求書配信サーバ、コピー機、請求書印刷代行方法、文書印刷代行システム、及び文書印刷代行方法
JP2003016178A (ja) 画像形成装置の消耗部品の回収を管理するためのサーバ及び方法
JP4870600B2 (ja) 情報管理システム及び情報管理方法

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080312

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080312

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100726

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100813

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101012

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101122

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101129

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131203

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4638992

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees