(57)【要約】【課題】受注票による運用であっても、ソフトウェアの在庫を適切に管理することの可能な仕組みを提供すること。【解決手段】ＦＡＸ受注処理サーバ１００が注文書を受け付けると、当該注文書から受注データを取得する。そして、受注データから受注票の発行指示があった場合には、当該受注データの商品種別９１３を特定する。特定された商品種別９１３がソフトウェアであった場合には、受注データが含まれるＤＡＴファイルを２つ生成し、そのうち１つを用いて赤伝の受注票を生成し、もう１つを用いて黒伝の受注票を生成する。生成された赤伝を用いて在庫を一時的に増やし、黒伝を用いて在庫を引き当てることで解決する。【選択図】図１９
2014092888.tif 000002
【特許請求の範囲】
【請求項１】
在庫管理を行う情報処理装置であって、
注文する製品の種別と、注文する製品の数量が含まれる注文票を受け付ける注文票受付手段と、
前記注文票受付手段で受け付けた注文票に含まれる製品の種別がソフトウェアであるか否かを判定する判定手段と、
前記判定手段で注文票に含まれる製品の種別がソフトウェアであると判定された場合に、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を増やすための赤伝票と、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を引き当てるための黒伝票を発行する伝票発行手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記情報処理装置は、
前記伝票発行手段で発行された赤伝票に基づいて、前記注文票に含まれる製品の在庫を増加させた後、前記伝票発行手段で発行された黒伝票に基づいて、前記注文票に含まれる製品の在庫を引き当てる在庫調整手段を更に備えることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記伝票発行手段は、前記注文票に基づいて取得した受注データを含む受注票元データを生成し、当該受注票元データと黒伝票用のフォームデータまたは赤伝票用のフォームデータとを結合させることにより、黒伝票または赤伝票を発行することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記情報処理装置は、
前記伝票発行手段で発行された黒伝票または赤伝票を前記情報処理装置の記憶手段に記憶するキャッシュ手段を更に備え、
前記伝票発行手段は、既に発行済みの黒伝票または赤伝票の発行を行う場合には、発行済みの黒伝票または赤伝票を前記記憶手段から取得し、新たに当該黒伝票または赤伝票を発行しないことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記情報処理装置は、
前記注文票に含まれる情報の編集を受け付ける編集受付手段と、
前記編集受付手段で編集を受け付けた注文票の黒伝票または赤伝票を前記記憶手段から削除する削除手段とを更に備えることを特徴とする請求項４に記載の情報処理装置。
【請求項６】
在庫管理を行う情報処理装置の制御方法であって、
注文する製品の種別と、注文する製品の数量が含まれる注文票を受け付ける注文票受付ステップと、
前記注文票受付ステップで受け付けた注文票に含まれる製品の種別がソフトウェアであるか否かを判定する判定ステップと、
前記判定ステップで注文票に含まれる製品の種別がソフトウェアであると判定された場合に、前記注文票受付ステップで受け付けた注文票に含まれる製品の数量分の在庫を増やすための赤伝票と、前記注文票受付ステップで受け付けた注文票に含まれる製品の数量分の在庫を引き当てるための黒伝票を発行する伝票発行ステップと
を備えることを特徴とする情報処理装置の制御方法。
【請求項７】
在庫管理を行う情報処理装置の制御方法をコンピュータに実行させるためのコンピュータに読み取り実行可能なプログラムであって、
前記情報処理装置を、
注文する製品の種別と、注文する製品の数量が含まれる注文票を受け付ける注文票受付手段と、
前記注文票受付手段で受け付けた注文票に含まれる製品の種別がソフトウェアであるか否かを判定する判定手段と、
前記判定手段で注文票に含まれる製品の種別がソフトウェアであると判定された場合に、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を増やすための赤伝票と、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を引き当てるための黒伝票を発行する伝票発行手段
として機能させることを特徴とするコンピュータに読み取り実行可能なプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、在庫の管理に関し、特に在庫が存在しないソフトウェアの在庫管理において、適切に在庫数量を管理することの可能な情報処理装置、その制御方法、及びプログラムに関する。
【背景技術】
【０００２】
従来、企業においては製品の在庫管理が行われている。在庫管理は、製品が入荷したり、お客様に出荷したりすることで在庫数量が日々変動しているので、実際に存在する在庫と、データ上の在庫の差異が出ないように管理している。
【０００３】
基本的に、在庫は入荷と出荷によって変動する。つまりシステム上は、製品が入荷した場合にその製品の在庫数量を増やし、製品が出荷した場合にはその製品の在庫数量を減らしている。こうして適切に管理することで、お客様に販売可能な製品の在庫はあるのかどうか、いくつ在庫を仕入れなければいけないのか等を検討することができるようになる。つまり、正しい在庫数量がわからないと、適切な検討ができず、企業にとって損失になってしまう。
【０００４】
下記の特許文献１には、決済時に商品の在庫不足に陥ることのない仕組みが開示されている。顧客から商品の購入指示を受け付けると、商品在庫の仮引当てを行い、在庫数量を更新する。そして、顧客から購入指示を受け付けた商品の決済がなされると、仮引当てしていた商品在庫に対して実引当てを行い、決済されなかった場合には仮引当てを解除して、在庫数量を元に戻す仕組みである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２９５２０２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、在庫管理が行えるのは有体物のみである。物として現実に存在するものに限られる。つまり、コンピュータで動作するソフトウェアなどは、ＣＤ−Ｒのような記録媒体に書き込まれないと有体物ではないので、在庫としてカウントされない。
【０００７】
在庫は、前述した通り、販売可能な在庫数量や仕入れるべき在庫数量等を確認するために管理するものであるので、ソフトウェアやデータのようにコンピュータ上で自由に複製が可能な無体物については、在庫を管理する必要がない。よって、在庫としてカウントしていないのが実情である。
【０００８】
一方、ソフトウェアと、コンピュータ機器のようなハードウェアを開発及び販売する企業にとっては、ソフトウェアだけを在庫管理の対象外としてしまうと、ソフトウェアは、ソフトウェア以外の製品とは異なる業務フローで運用せざるを得なくなってしまう問題がある。つまり、通常であれば、お客様から発注を受けると在庫を引当てて、お客様に在庫を出荷した後、その製品の料金を請求し、支払われると売上に計上する。しかし、ソフトウェアだけは、お客様から発注を受けるとお客様に在庫を出荷（ソフトウェアをデータ送信）し、その製品の料金を請求し、支払われると売上に計上する流れになり、在庫の引当てというステップがなくなる。
【０００９】
このように、企業にとっては統一的な業務フローで運用したいところを、ソフトウェアだけ例外的な処理が必要となってしまうので、システムを構築する上で非常に手間がかかってしまうし、運用上も煩雑になってしまう問題があった。
【００１０】
そこで、ソフトウェアの在庫は「０」だが、出荷があった場合に減算してしまう方法も考えられる。しかしながら、「０」から減算してしまうと在庫がマイナスになってしまう。在庫がマイナスということは、在庫が足りず発注の必要なステータスになってしまうため、本来意図する動作とは異なる動作をシステムが行ってしまう問題が出てきてしまう。
【００１１】
つまり、現状のシステムを有効に活用しつつ、ソフトウェアについても他の製品と同様の業務フローで運用可能な仕組みが求められている。
【００１２】
本発明は上記の課題を解決するためになされたもので、受注票による運用であっても、ソフトウェアの在庫を適切に管理することの可能な仕組みを提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記の目的を達成するために、本発明の情報処理装置は、在庫管理を行う情報処理装置であって、注文する製品の種別と、注文する製品の数量が含まれる注文票を受け付ける注文票受付手段と、前記注文票受付手段で受け付けた注文票に含まれる製品の種別がソフトウェアであるか否かを判定する判定手段と、前記判定手段で注文票に含まれる製品の種別がソフトウェアであると判定された場合に、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を増やすための赤伝票と、前記注文票受付手段で受け付けた注文票に含まれる製品の数量分の在庫を引き当てるための黒伝票を発行する伝票発行手段とを備えることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、ソフトウェアの発注があった場合には、発注された数量分の在庫を増やすための赤伝票と、発注された数量分の在庫を減らすための黒伝票を発行することが可能となるので、赤伝票によって必要な在庫を増やした後に、黒伝票によって在庫の引当てをすることで、ソフトウェアの在庫を「０」に保つことができ、従来のシステムであってもソフトウェアの在庫を適切に管理することの可能な効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】本実施形態におけるシステム構成を示す構成図である。
【図２】図１に示す各種装置のハードウェア構成を示す構成図である。
【図３】図１に示す複合機１０３のハードウェア構成を示す構成図である。
【図４】図１に示す各種装置のモジュール構成を示す構成図である。
【図５】本発明における注文書を受信する一連の流れを示すフローチャートである。
【図６】受信した注文書のＯＣＲ箇所を示す模式図である。
【図７】ＯＣＲ処理の実行結果として生成されるＯＣＲファイル７００の一例を示す構成図である。
【図８】注文書テーブル８００、受注データテーブル８１０のテーブル構成の一例を示す構成図である。
【図９】会社マスタテーブル９００、商品マスタテーブル９１０のテーブル構成の一例を示す構成図である。
【図１０Ａ】受信した注文書から受注票を編集し生成するための一連の流れを示すフローチャートである。
【図１０Ｂ】図１０Ａの続きであり、受信した注文書から受注票を編集し生成するための一連の流れを示すフローチャートである。
【図１１】注文書一覧画面１１００の画面構成の一例を示す構成図である。
【図１２】受信した注文書に納期回答を行った場合に生成される納期回答書の一例を示す模式図である。
【図１３Ａ】受注票編集処理の詳細を示すフローチャートである。
【図１３Ｂ】図１３Ａの続きであり、受注票編集処理の詳細を示すフローチャートである。
【図１４】受注データ一覧画面１４００の画面構成の一例を示す構成図である。
【図１５】受注票編集画面１５００の画面構成の一例を示す構成図である。
【図１６】赤伝の受注票を編集するための受注票編集画面１５００の画面構成の一例を示す構成図である。
【図１７】受注票プレビュー処理の詳細を示すフローチャートである。
【図１８】キャッシュテーブル１８００のテーブル構成の一例を示す構成図である。
【図１９】受注票生成処理の詳細を示すフローチャートである。
【図２０】印刷された黒伝の受注票の一例を示す模式図である。
【図２１】印刷された赤伝の受注票の一例を示す模式図である。
【図２２】受注票印刷処理の詳細を示すフローチャートである。
【図２３】生成された受注票に基づいて、在庫の更新を行うための一連の流れを示すフローチャートである。
【図２４】在庫情報テーブル２４００のテーブル構成の一例を示す構成図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照して、本発明の実施の形態の一例について説明する。
【００１７】
図１は、本発明のＦＡＸ受注処理システムのシステム構成の一例を示す図である。本発明のＦＡＸ受注処理システムは、ＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２、複合機１０３、ファクシミリ１０４、外部クライアント端末１０６、クライアント端末１０８が設置されており、それら装置はＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワーク１０９を介して相互にデータ通信可能に接続されている。図１のネットワーク１０９上に接続される各種端末あるいはサーバの構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００１８】
ＦＡＸ受注処理サーバ１００は、顧客から送信された注文書（注文票）を受信し、当該注文書を解析して受注票を作成するための装置である。注文書は、ファクシミリ１０４から複合機１０３に送信し、複合機１０３の自動転送機能によってＦＡＸ受注処理サーバ１００に送信されたものを受信してもよいし、複合機１０３でスキャンされた注文書を受信してもよいし、メールサーバ１０７から送信されたメールに添付された注文書を受信する形態でもよい。注文書が受信できればなんでもよい。尚、本実施形態では、ファクシミリ１０４から送信された場合を想定して説明を行う。
【００１９】
ＤＢサーバ１０２は、注文書から抽出したデータや受注票のデータを格納するためのデータベースサーバである。本実施形態では、在庫管理も同時に行っている。また、本実施形態ではＦＡＸ受注処理サーバ１００とＤＢサーバ１０２を別々の装置として説明を行うが、同一の筐体であってもよい（情報処理装置）。
【００２０】
複合機１０３は、印刷やファックス、メールといった様々な機能を実行可能なマルチファンクションプリンタである。ファクシミリ１０４とＦＡＸ通信が可能であり、ファクシミリ１０４から注文書を受信すると、ＦＡＸ受注処理サーバ１００に対して転送する。
【００２１】
ファクシミリ１０４は、ユーザからの操作に応じて指定された送信先にＦＡＸ送信を行う装置である。
【００２２】
外部クライアント端末１０６は、ＬＡＮのネットワーク１０９上にない外部のクライアント端末である。外部クライアント端末１０６からメールが送信されると、メールサーバ１０７に格納される。メールサーバ１０７は、外部クライアント端末１０６やクライアント端末１０８からのメールを受信するサーバであり、宛先がＦＡＸ受注処理サーバ１００であった場合には、当該ＦＡＸ受注処理サーバ１００に対してメールを転送する。
【００２３】
クライアント端末１０８は、ＦＡＸ受注処理サーバ１００に対して各種指示を送るための装置である。ユーザからの操作に応じて、当該各種指示を送るための画面を表示し、表示された画面を通じて、ＦＡＸ受注処理サーバ１００に対して指示を行う。
【００２４】
図２は、本発明の実施形態におけるＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２、外部クライアント端末１０６、メールサーバ１０７、クライアント端末１０８のハードウェア構成を示す図である。
【００２５】
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。
【００２６】
また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  ＯｕｔｐｕｔＳｙｓｔｅｍ)やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。
【００２７】
ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。
【００２８】
また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。
【００２９】
ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。
【００３０】
メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウエア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフロッピーディスク（登録商標  ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるカード型メモリ等の外部メモリ２１１へのアクセスを制御する。
【００３１】
通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。
【００３２】
尚、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００３３】
本発明の各種装置が後述する各種処理を実行するために用いられる各種プログラム等は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、本発明に係わるプログラムが用いる定義ファイルや各種情報テーブルは外部メモリ２１１（記憶手段）に格納されている。
【００３４】
次に、複合機１０３のハードウェア構成の一例について図３を用いて説明する。
【００３５】
コントローラユニット３１６は、画像入力デバイスとして機能するスキャナ部３１４や、画像出力デバイスとして機能するプリンタ部３１２と接続する一方、ＬＡＮやＷＡＮと接続することで、画像データやデバイス情報の入出力を行う。
【００３６】
ＣＰＵ３０１は、システム全体を制御するプロセッサである。ＲＡＭ３０２は、ＣＰＵ３０１が動作するためのシステムワークメモリであり、プログラムを記録するためのプログラムメモリや、画像データを一時記録するための画像メモリである。
【００３７】
ＲＯＭ３０３は、システムのブートプログラムや各種制御プログラムが格納されている。ハードディスクドライブ（ＨＤＤ）３０４は、システムを制御するための各種プログラム，画像データ等を格納する。
【００３８】
操作部インタフェース（操作部Ｉ／Ｆ）３０７は、操作部３０８とのインタフェース部であり、操作部３０８に表示する画像データを操作部３０８に対して出力する。また、操作部Ｉ／Ｆ３０７は、操作部３０８から本システム使用者が入力した情報（例えば、ユーザ情報等）をＣＰＵ３０１に伝える役割をする。なお、操作部３０８はタッチパネルを有する表示部を備え、該表示部に表示されたボタンを、ユーザが押下（指等でタッチ）することにより、各種指示を行うことができる。
【００３９】
ネットワークインタフェース（Ｎｅｔｗｏｒｋ  Ｉ／Ｆ）３０５は、ネットワーク（ＬＡＮ）に接続し、データの入出力を行う。モデム（ＭＯＤＥＭ）３０６は、公衆回線に接続し、ＦＡＸの送受信等のデータの入出力を行う。
【００４０】
外部インタフェース（外部Ｉ／Ｆ）３１８は、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）、ＩＥＥＥ１３９４（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃ  Ｅｎｇｉｎｅｅｒｓ  １３９４）、プリンタポート、ＲＳ−２３２Ｃ（Ｒｅｃｏｍｍｅｎｄｅｄ  Ｓｔａｎｄａｒｄ  ２３２  ｖｅｒｓｉｏｎ  Ｃ）等の外部入力を受け付けるＩ／Ｆ部であり、本実施形態においては認証で必要となるＩＣカードの読み取り用のカードリーダ１０１が外部Ｉ／Ｆ３１８に接続されている。
【００４１】
更に、ＣＰＵ３０１は、この外部Ｉ／Ｆ３１８を介してカードリーダ１０１によるＩＣカードからの情報読み取りを制御し、当該ＩＣカードから読み取られた情報を取得可能である。以上のデバイスがシステムバス３０９上に配置される。
【００４２】
イメージバスインタフェース（ＩＭＡＧＥ  ＢＵＳ  Ｉ／Ｆ）３２０は、システムバス３０９と画像データを高速で転送する画像バス３１５とを接続し、データ構造を変換するバスブリッジである。
【００４３】
画像バス３１５は、ＰＣＩバス（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔ  ｂｕｓ）またはＩＥＥＥ１３９４で構成される。画像バス３１５上には以下のデバイスが配置される。
【００４４】
ラスタイメージプロセッサ（ＲＩＰ）３１０は、ベクトルデータをビットマップイメージに展開する。
【００４５】
プリンタインタフェース（プリンタＩ／Ｆ）３１１は、プリンタ部３１２とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。
【００４６】
スキャナインタフェース（スキャナＩ／Ｆ）３１３は、スキャナ部３１４とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。
【００４７】
画像処理部３１７は、入力画像データに対し補正、加工及び編集やプリント出力画像データに対して、プリンタの補正、解像度変換等を行う。また、これに加えて、画像処理部３１７は、画像データの回転や、多値画像データに対してはＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）、２値画像データはＪＢＩＧ（Ｊｏｉｎｔ  Ｂｉ−ｌｅｖｅｌ  Ｉｍａｇｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）等の圧縮伸張処理を行う。
【００４８】
スキャナ部３１４は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサで走査することで、ラスタイメージデータとして電気信号に変換する。原稿用紙は原稿フィーダのトレイにセットし、装置使用者が操作部３０８から読み取り起動指示することにより、ＣＰＵ３０１がスキャナ部３１４に指示を与え、フィーダは原稿用紙を１枚ずつフィードし原稿画像の読み取り動作を行う。
【００４９】
プリンタ部３１２は、ラスタイメージデータを用紙上の画像に変換する部分であり、その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。プリント動作の起動は、ＣＰＵ３０１からの指示によって開始する。なお、プリンタ部３１２には、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセットを備える。
【００５０】
操作部３０８は、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）表示部を有し、ＬＣＤ上にタッチパネルシートが貼られており、システムの操作画面を表示するとともに、表示してあるキーが押されるとその位置情報を操作部Ｉ／Ｆ３０７を介してＣＰＵ３０１に伝える。また、操作部３０８は、各種操作キーとして、例えば、スタートキー、ストップキー、ＩＤキー、リセットキー等を備える。
【００５１】
ここで、操作部３０８のスタートキーは、原稿画像の読み取り動作を開始する時などに用いる。スタートキーの中央部には、緑と赤の２色ＬＥＤがあり、その色によってスタートキーが使える状態にあるかどうかを示す。また、操作部３０８のストップキーは、稼働中の動作を止める働きをする。また、操作部３０８のＩＤキーは、使用者のユーザＩＤを入力する時に用いる。リセットキーは、操作部からの設定を初期化する時に用いる。
【００５２】
以上のような構成によって、複合機１０３は、スキャナ部３１４から読み込んだ画像データをＮｅｔｗｏｒｋ  Ｉ／Ｆ３０５からＬＡＮに送信し、ＬＡＮから受信した印刷データをＮｅｔｗｏｒｋ  Ｉ／Ｆ３０５を経由してプリンタ部３１２より印刷出力することができる。
【００５３】
また、スキャナ部３１４から読み込んだ画像データをモデム３０６により、公衆回線上にＦＡＸ送信し、公衆回線からＦＡＸ受信した画像データをプリンタ部３１２により出力することできる。
【００５４】
次に、ＦＡＸ受注処理サーバ１００、クライアント端末１０８、ＤＢサーバ１０２のモジュール構成を示す機能構成図について、図４を用いて説明する。尚、図４の各種端末あるいはサーバのモジュール構成は一例であり、用途や目的に応じて様々な構成例があることは言うまでもない。
【００５５】
ＦＡＸ受注処理サーバ１００は、送受信制御モジュール４０１、判定制御モジュール４０２、ＯＣＲ処理モジュール４０３、ＰＤＦデータ生成モジュール４０４、キャッシュ保存モジュール４０５を備える。
【００５６】
送受信制御モジュール４０１は、クライアント端末１０８の送受信制御モジュール４１１やＤＢサーバ１０２の送受信制御モジュール４２１とデータの送受信を行うためのモジュールである。
【００５７】
判定制御モジュール４０２は、ＦＡＸ受注処理サーバ１００で実行される各種判定の制御を行うためのモジュールである。
【００５８】
ＯＣＲ処理モジュール４０３は、注文書の画像データに対して文字認識処理を実行するためのモジュールである。
【００５９】
ＰＤＦデータ生成モジュール４０４は、ユーザから入力された文字列と、受注票の画像データ（ＰＤＦデータ）とを重ね合わせて結合し、１つのＰＤＦデータを生成するためのモジュールである。
【００６０】
キャッシュ保存モジュール４０５は、ＰＤＦデータ生成モジュール４０４で生成されたＰＤＦデータをＦＡＸ受注処理サーバ１００の外部メモリ２１１等に保存しておき、必要に応じて取得するためのモジュールである。
【００６１】
クライアント端末１０８は、送受信制御モジュール４１１、表示制御モジュール４１２、判定制御モジュール４１３を備える。
【００６２】
送受信制御モジュール４１１は、ＦＡＸ受注処理サーバ１００の送受信制御モジュール４０１や、ＤＢサーバ１０２の送受信制御モジュール４２１とデータの送受信を行うためのモジュールである。
【００６３】
表示制御モジュール４１２は、クライアント端末１０８のＣＲＴ２１０等を制御し、各種情報や画面を表示するためのモジュールである。
【００６４】
判定制御モジュール４１３は、クライアント端末１０８で実行される各種判定の制御を行うためのモジュールである。
【００６５】
ＤＢサーバ１０２は、送受信制御モジュール４２１、注文書データ管理モジュール４２２、受注データ管理モジュール４２３を備える。
【００６６】
送受信制御モジュール４２１は、ＦＡＸ受注処理サーバ１００の送受信制御モジュール４０１や、クライアント端末１０８の送受信制御モジュール４１１とデータの送受信を行うためのモジュールである。
【００６７】
注文書データ管理モジュール４２２は、ＦＡＸ受注処理サーバ１００で取得した注文書に関するデータを記憶管理するためのモジュールである。必要に応じてこのデータを取得し、ＦＡＸ受注処理サーバ１００やクライアント端末１０８に送信する。
【００６８】
受注データ管理モジュール４２３は、ＦＡＸ受注処理サーバ１００で取得した受注に関するデータを記憶管理するためのモジュールである。必要に応じてこのデータを取得し、ＦＡＸ受注処理サーバ１００やクライアント端末１０８に送信する。
【００６９】
次に、本発明の実施形態におけるファクシミリ１０４、複合機１０３、ＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２によって行われる一連の処理について、図５に示すフローチャートを用いて説明する。尚、ステップＳ５０１のステップはファクシミリ１０４におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ５０２、ステップＳ５０３の各ステップは複合機１０３におけるＣＰＵ３０１の制御の下、処理が行われる。また、ステップＳ５０４乃至ステップＳ５０７、ステップＳ５１２の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ５０８乃至ステップＳ５１１の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００７０】
ステップＳ５０１では、ファクシミリ１０４は、ユーザからの指示に応じて紙の注文書のスキャンを受け付け、ＦＡＸ送信可能な画像データに変換し、送信先の複合機１０３に対して当該データを送信する。
【００７１】
ステップＳ５０２では、複合機１０３は、ファクシミリ１０４から送信された注文書の画像データを受信すると、ステップＳ５０３では、受信した注文書の画像データをＦＡＸ受注処理サーバ１００に対して転送する。転送先はＦＡＸ受注処理サーバ１００の所定の記憶領域（フォルダ）である。
【００７２】
ステップＳ５０４では、ＦＡＸ受注処理サーバ１００は、複合機１０３からの注文書の画像データを受信し、所定のフォルダに格納する（注文票受付手段）。ステップＳ５０５では、格納した注文書の画像データをＯＣＲ処理すべく、ＯＣＲ処理しやすいように前処理を実行する。例えば、傾きの補正であったり、解像度の向上であったり、画像処理を実行することでＯＣＲ処理の前処理を実行する。
【００７３】
ステップＳ５０６では、ＦＡＸ受注処理サーバ１００は、ステップＳ５０５で前処理を実行された注文書の画像データに対してＯＣＲ処理を実行する。ＯＣＲ処理の詳細な仕組みについては、従来技術であるので説明を省略する。ＯＣＲ処理を行うことによって、注文書に記載されたテキストデータが取得できる。例えば、図６に示すような注文書があった場合、ＯＣＲ処理領域６０１、６０２、６０３、６０４を設定しておくと、この領域に対してＯＣＲ処理を実行する。注文書を固定のフォームにしておくことが前提となる。こうして所定の領域からテキストデータを取得できたら、ＦＡＸ受注処理サーバ１００のＲＡＭ２０３等の記憶領域に保存する。例えば、取得したＯＣＲ結果ファイルは、図７に示すような形態で取得できる。
【００７４】
ＯＣＲ結果ファイル７００（図７参照）は、注文書の画像データにＯＣＲ処理を実行した結果、得られるテキストファイルである。ＯＣＲ結果ファイル７００は、注文書ＩＤ７０１、注文番号７０２、商品コード７０３、数量単位７０４、発注単位７０５、発注元会社名７０７、発注元会社住所７０８、発注元担当者７０９、請求先会社名７１０、請求先会社住所７１１、納品先会社名７１２、納品先会社住所７１３、納品先担当者７１４等から構成されている。ＯＣＲ結果ファイル７００は、注文書に記載された注文番号７０２ごとにレコード分けされて生成されている。つまり、このレコードは受注単位である。
【００７５】
ステップＳ５０７では、ＦＡＸ受注処理サーバ１００は、ステップＳ５０６で取得したＯＣＲ結果を取得し、ＤＢサーバ１０２に対して送信する。また、合わせて注文書の画像データの保存場所（ファイルパス）も送信する。
【００７６】
ステップＳ５０８では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信されたＯＣＲ結果を受信し、ステップＳ５０９では、受信したＯＣＲ結果を注文書テーブル８００に登録する。
【００７７】
注文書テーブル８００（図８参照）は、注文書ＩＤ８０１、注文会社コード８０２、注文書取得日８０３、注文書画像ファイルパス８０４から構成される。注文書ＩＤ８０１は、注文書テーブル８００において一意に識別可能なＩＤである。注文会社コード８０２は、注文を行った会社の会社コードを示す。注文書取得日８０３は、注文書を受信し、注文書テーブル８００に登録した日付を示す。受信日でもよい。注文書画像ファイルパス８０４は、ＦＡＸ受注処理サーバ１００に保存された注文書の画像データの保存場所を示す。ＯＣＲ結果ファイル７００を受信すると、新しく注文書ＩＤ８０１を発行し、ＯＣＲ結果ファイル７００の発注元会社名７０７と、会社マスタテーブル９００（図９参照）から会社コード９０１を特定し、当該会社コード９０１を注文会社コード８０２に格納する。注文書取得日８０３には、現在日時を格納し、注文書画像ファイルパス８０４には、受信したファイルパスを格納する。
【００７８】
会社マスタテーブル９００（図９参照）は、会社コード９０１、会社名９０２、納期回答要否９０３から構成されている。会社コード９０１は、会社ごとに一意に割り振られた識別コードである。会社名９０２は、会社の名称を示す。納期回答要否９０３は、注文を受けた後に納期を回答すべきか否かを示すフラグである。「１」が格納されていると、納期回答が必要な会社である。また、会社マスタテーブル９００は、ＦＡＸ受注処理サーバ１００やＤＢサーバ１０２に記憶されているものとする。
【００７９】
ステップＳ５１０では、ＤＢサーバ１０２は、注文書テーブル８００に格納が完了したら、受注データテーブル８１０にも登録を行う。受注データテーブル８１０は、注文に対して受注単位で登録を行う。１つの注文書に対して複数の製品が注文される場合がある。この場合には、注文番号ごとに受注単位を分割して管理する。例えば、図６に示す注文書を受信した場合、注文番号が３つあり、それぞれに対して製品が記載されている。よって図６の注文書では、３つの受注と見なす。ここでは、「マルチファンクションプリンタ」と、「プリンタ用ソフトウェア」と、「マルチファンクションプリンタ用交換トナー（黒）」の３つである。この３つをＯＣＲ結果ファイル７００に含めて、受注データテーブル８１０に格納すると、図８に示すような構成となる。尚、受注票種別８１３は、後述する処理で登録される項目であるので、現時点では空にしておく。
【００８０】
受注データテーブル８１０（図８参照）は、受注票ＩＤ８１１、注文書ＩＤ８１２、受注票種別８１３、注文番号８１４、商品コード８１５、数量単位８１６、発注単位８１７、発注金額８１８、請求先会社名８１９、請求先会社住所８２０、納品先会社名８２１、納品先会社住所８２２、納品先担当者８２３等から構成される。登録する際には、新しく一意な受注票ＩＤ８１１を発行し、注文番号８１４単位にレコードを登録しておく。
【００８１】
ステップＳ５１１は、ＤＢサーバ１０２は、各種処理の実行結果をＦＡＸ受注処理サーバ１００に送信する。ステップＳ５１２では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から送信された実行結果を受信したら、一連の処理を終了する。
【００８２】
次に、本発明の実施形態におけるクライアント端末１０８、ＦＡＸ受注処理サーバ１００，ＤＢサーバ１０２によって行われる一連の処理について、図１０Ａ及び図１０Ｂに示すフローチャートを用いて説明する。尚、ステップＳ１００１、ステップＳ１０１５乃至ステップＳ１０２６のステップはクライアント端末１０８におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１００２、Ｓ１００４、ステップＳ１００８乃至ステップＳ１０１４の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ３０１の制御の下、処理が行われる。また、ステップＳ１００５乃至ステップＳ１００７の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【００８３】
ステップＳ１００１では、クライアント端末１０８は、注文書に関する処理を行うため、ユーザからの指示に応じて、ＦＡＸ受注処理サーバ１００に対して注文書一覧画面の取得要求を送信する。
【００８４】
ステップＳ１００２では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から注文書一覧画面の取得要求を受信する。そして、注文書テーブル８００から注文書データ（注文書テーブル８００のレコード）を取得するために、ステップＳ１００３では、ＤＢサーバ１０２に対して注文書データの取得要求を送信する。
【００８５】
ステップＳ１００５では、ＤＢサーバ１０２は、注文書データの取得要求を受信する。ステップＳ１００６では、当該要求に応じて注文書テーブル８００に格納された注文書データを取得し、ステップＳ１００７で、ＦＡＸ受注処理サーバ１００に対して送信する。注文書テーブル８００自体をそのまま送信してしまってもよい。
【００８６】
ステップＳ１００８では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から受信した注文書データを受信し、注文書一覧画面１１００（図１１参照）の生成を行う。注文書一覧画面１１００は図１１に示すような形態となる。このうち、注文書データが配置される領域については、空欄にしておき、後述する処理でこの空欄部分を構築する。
【００８７】
ステップＳ１００９では、ＦＡＸ受注処理サーバ１００は、受信した注文書データのうち１つを参照し、ステップＳ１０１０では、当該注文書データは、納期回答が必要か否かを判定する。会社マスタテーブル９００は、ＦＡＸ受注処理サーバ１００にも記憶されており、受信した注文書データの注文会社コード８０２が示す会社の納期回答要否９０３に基づいて、納期回答が必要か否か判定するようにすればよい。納期回答が必要な会社であると判定された場合には、ステップＳ１０１１に処理を進め、納期回答が必要な会社でないと判定された場合には、ステップＳ１０１２に処理を進める。
【００８８】
ステップＳ１０１１では、ＦＡＸ受注処理サーバ１００は、生成された注文書一覧画面１１００の注文書データの表示領域に納期回答を行うボタンを配置する。例えば、図１１の１１０５に示すようなボタン群である。これらのボタンの押下を受け付けることで、納期回答を行う。
【００８９】
ステップＳ１０１２では、ＦＡＸ受注処理サーバ１００は、生成された注文書一覧画面１１００の注文書データの表示領域に受注票に対する操作を行うボタン群を配置する。例えば、受注票編集ボタン１１０２、受注票プレビューボタン１１０３、受注票印刷ボタン１１０４である。それぞれのレコードごとにボタンを表示させる。
【００９０】
ステップＳ１０１３では、ＦＡＸ受注処理サーバ１００は、受信したすべての注文書データに対してステップＳ１００９乃至ステップＳ１０１２の処理が完了したか否かを判定する。すべての注文書データに対する処理が完了したと判定された場合には、ステップＳ１０１４に処理を進め、そうでない場合には、ステップＳ１００９に処理を戻す。
【００９１】
ステップＳ１０１４では、完成した注文書一覧画面１１００をクライアント端末１０８に対して送信する。
【００９２】
ステップＳ１０１５では、クライアント端末１０８は、ＦＡＸ受注処理サーバ１００から送信された注文書一覧画面１１００を受信し、ステップＳ１０１６では、クライアント端末１０８のＣＲＴ２１０等に表示させ、ユーザからの操作を受け付ける。
説明を図１０Ｂに移す。
【００９３】
ステップＳ１０１７では、クライアント端末１０８は、ユーザからの操作によって表示された注文書一覧画面１１００の納期回答ボタン１１０１が押下されたか否かを判定する。納期回答ボタン１１０１は、ＦＡＸ送信を示すボタンである。納期回答ボタン１１０１が押下されたと判定された場合には、ステップＳ１０１８に処理を進め、そうでない場合には、ステップＳ１０１９に処理を進める。
【００９４】
ステップＳ１０１８では、クライアント端末１０８は、納期回答ボタン１１０１の押下に応じて表示された納期回答の画面で、納期の入力を受け付けて、当該入力された納期を注文書の画像データに重ね合わせて、ＰＤＦデータとして新たに生成する。生成されたＰＤＦデータは、図１２に示すような形態となる。１２０１に示すように納期が格納される。そして、当該納期回答を行う会社に対してＰＤＦデータを複合機１０３に送信し、送信先の会社にＦＡＸ送信する。当該処理は、従来技術であるので詳細な説明は省略する。
【００９５】
ステップＳ１０１９では、クライアント端末１０８は、受注票編集ボタン１１０２の押下を受け付けたか否かを判定する。受注票編集ボタン１１０２の押下を受け付けたと判定された場合には、ステップＳ１０２０に処理を進め、そうでない場合には、ステップＳ１０２１に処理を進める。
【００９６】
ステップＳ１０２０では、クライアント端末１０８は、受注票編集ボタン１１０２が押下された注文データの受注票の編集を行う（編集受付手段）。受注票編集処理の詳細は、後述する図１３Ａ及び図１３Ｂに示す。
【００９７】
ステップＳ１０２１では、クライアント端末１０８は、受注票プレビューボタン１１０３が押下されたか否かを判定する。受注票プレビューボタン１１０３が押下されたと判定された場合には、ステップＳ１０２２に処理を進め、そうでない場合には、ステップＳ１０２３に処理を進める。
【００９８】
ステップＳ１０２２では、クライアント端末１０８は、ステップＳ１０２０で編集された受注票の確認表示を行う処理を実行する。受注票プレビュー処理の詳細は、後述する図１７に示す。
【００９９】
ステップＳ１０２３では、クライアント端末１０８は、受注票印刷ボタン１１０４が押下されたか否かを判定する。受注票印刷ボタン１１０４が押下されたと判定された場合には、ステップＳ１０２４に処理を進め、そうでない場合には、ステップＳ１０２５に処理を進める。
【０１００】
ステップＳ１０２４では、クライアント端末１０８は、受注票を紙に印刷するべく、受注票の印刷処理を実行する。受注票印刷処理の詳細は、後述する図２２に示す。
【０１０１】
ステップＳ１０２５では、クライアント端末１０８は、注文書一覧画面１１００の終了指示があったか否かを判定する。閉じるボタン等が押下されたか否かを判定すればよい。注文書一覧画面１１００の終了が指示されたと判定された場合には、ステップＳ１０２６に処理を進め、そうでない場合には、ステップＳ１０１７に処理を戻す。
【０１０２】
ステップＳ１０２６では、クライアント端末１０８は、注文書一覧画面１１００を閉じて、本一連の処理を終了する。
【０１０３】
次に、本発明の実施形態におけるクライアント端末１０８、ＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２によって行われる受注票編集処理について、図１３Ａ及び図１３Ｂに示すフローチャートを用いて説明する。尚、ステップＳ１３０１、ステップＳ１３１０乃至ステップＳ１３１３、ステップＳ１３１８乃至ステップＳ１３２１、ステップＳ１３２５乃至ステップＳ１３３４の各ステップはクライアント端末１０８におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１３０２、ステップＳ１３０３、ステップＳ１３０７乃至ステップＳ１３０９、ステップＳ１３１４乃至ステップＳ１３１７、ステップＳ１３２２乃至ステップＳ１３２４、ステップＳ１３２９、ステップＳ１３３０の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ３０１の制御の下、処理が行われる。また、ステップＳ１３０４乃至ステップＳ１３０６、ステップＳ１３３１乃至ステップＳ１３３３の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１０４】
ステップＳ１３０１では、クライアント端末１０８では、受注データを一覧表示するための受注データ一覧画面の取得要求をＦＡＸ受注処理サーバ１００に対して送信する。
【０１０５】
ステップＳ１３０２では、ＦＡＸ受注処理サーバ１００では、クライアント端末１０８から送信された受注データ一覧画面の取得要求を受信し、ステップＳ１３０３では、受注データ一覧画面に表示する受注データの取得要求をＤＢサーバ１０２に送信する。
【０１０６】
ステップＳ１３０４では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された受注データの取得要求を受信し、受注データテーブル８１０から受注データを取得する。そして、ステップＳ１３０６では、取得した受注データをＦＡＸ受注処理サーバ１００に送信する。
【０１０７】
ステップＳ１３０７では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から送信された受注データを受信し、ステップＳ１３０８では、受信した受注データに基づいて、受注データ一覧画面１４００（図１４参照）を生成する。そして、ステップＳ１３０９では、生成した受注データ一覧画面１４００をクライアント端末１０８に対して送信する。
【０１０８】
ステップＳ１３１０では、クライアント端末１０８では、ＦＡＸ受注処理サーバ１００から送信された受注データ一覧画面１４００を受信し、ステップＳ１３１１では、受信した受注データ一覧画面１４００を表示させ、ユーザからの操作を受け付ける。
【０１０９】
ステップＳ１３１２では、クライアント端末１０８は、受注データ一覧画面１４００に備えられた受注票（黒伝）編集ボタン１４０１または受注票（赤伝）編集ボタン１４０２の押下を受け付けたか否かを判定する。どちらも受注票の編集を行うボタンであるが、売上を計上したり、在庫を減らすための黒伝（黒伝票）と、売上を取り消したり、在庫を増やす（元に戻す）ための赤伝（赤伝票）で編集ボタンを分けている。ボタン押下後は、同様の画面に遷移するが、後述する受注票プレビュー処理や受注票印刷処理で黒伝を発行するのか、赤伝を発行するのかは、ここで押下されたボタンによって変化する。つまり、クライアント端末１０８は、押下されたボタンの種別を受注データごとに管理しておく必要がある。受注票（黒伝）編集ボタン１４０１または受注票（赤伝）編集ボタン１４０２が押下されたと判定された場合には、ステップＳ１３１３に処理を進め、そうでない場合には待機する。
【０１１０】
ステップＳ１３１３では、クライアント端末１０８は、黒伝または赤伝を編集するための受注票編集画面の取得要求をＦＡＸ受注処理サーバ１００に送信する。
【０１１１】
ステップＳ１３１４では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から送信された受注票編集画面の取得要求を受信する。そして、ステップＳ１３１５では、クライアント端末１０８で編集の指示がなされた受注データの作成済みの受注票をＦＡＸ受注処理サーバ１００のキャッシュテーブル１８００から削除する（削除手段）。後述する処理において、受注票が受注票プレビュー処理において生成されると、図１８に示すようなキャッシュテーブル１８００に登録され、生成された受注票はＦＡＸ受注処理サーバ１００の所定の記憶領域に保存される。これを後述する受注票印刷処理で利用するのだが、編集がなされると受注データの内容が変わってしまうので、一旦ここで削除してしまう。こうすることで、古いキャッシュを印刷せずに済む。
【０１１２】
キャッシュテーブル１８００（図１８参照）は、受注票ＩＤ１８０１、受注票ファイルパス１８０２から構成される。受注票ＩＤ１８０１は、受注データテーブル８１０の受注票ＩＤ８１１に対応する。受注票ファイルパス１８０２は、ＦＡＸ受注処理サーバ１００に保存された受注票のファイルパスを示す。キャッシュテーブル１８００の更新方法については、後述する。
【０１１３】
ステップＳ１３１６では、ＦＡＸ受注処理サーバ１００は、ステップＳ１０７で受注データを受信しているので、ユーザから編集を指示された受注データを取得して、受注票編集画面１５００（図１５参照）を生成する。受注票編集画面１５００は、黒伝の場合の画面である。赤伝の場合には、図１６に示すような受注票編集画面１５００が生成される。
図１３Ｂに説明を移す。
【０１１４】
ステップＳ１３１７では、ＦＡＸ受注処理サーバ１００は、ステップＳ１３１６で生成された受注票編集画面１５００をクライアント端末１０８に送信する。
【０１１５】
ステップＳ１３１８では、クライアント端末１０８は、ＦＡＸ受注処理サーバ１００から送信された受注票編集画面１５００を受信し、ステップＳ１３１９では、受信した受注票編集画面１５００を表示し、ユーザからの操作を受け付ける。
【０１１６】
ステップＳ１３２０では、クライアント端末１０８は、受注票編集画面１５００に備えられた受注票更新ボタン１５０１が押下されたか否かを判定する。つまり、受注票編集画面１５００で受け付けた入力内容に受注データを更新する指示がなされたか否かを示す。受注票更新ボタン１５０１が押下されたと判定された場合には、ステップＳ１３２１に処理を進め、そうでない場合には待機する。
【０１１７】
ステップＳ１３２１では、クライアント端末１０８は、編集された受注データをＦＡＸ受注処理サーバ１００に送信する。
【０１１８】
ステップＳ１３２２では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から送信された編集された受注データを受信し、ステップＳ１３２３では、ＲＡＭ２０３等に一時的に格納されている受注データを更新する。まだこの時点では、ＤＢサーバ１０２にある受注データテーブル８１０に更新指示を送信しない。また、この更新では、編集された受注票の種別が黒伝の受注票なのか、赤伝の受注票なのかを合わせて記憶しておく。
【０１１９】
ステップＳ１３２４では、ＦＡＸ受注処理サーバ１００は、更新の処理結果をクライアント端末１０８に送信する。
【０１２０】
ステップＳ１３２５では、クライアント端末１０８は、更新の処理結果を受信し、ステップＳ１３２６では、再度、受注データ一覧画面１４００を表示し、ユーザからの操作を受け付ける。
【０１２１】
ステップＳ１３２７では、クライアント端末１０８は、編集終了の指示がなされたか否かを判定する。具体的には、受注票一覧更新ボタン１４０３が押下されたか否かを判定する。受注票一覧更新ボタン１４０３が押下されたと判定された場合には、ステップＳ１３２８に処理を進め、そうでない場合には、ステップＳ１３１２に処理を戻す。
【０１２２】
ステップＳ１３２８では、クライアント端末１０８は、ＦＡＸ受注処理サーバ１００に対して、受注データの確定命令を送信する。
【０１２３】
ステップＳ１３２９では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から送信された受注データ確定命令を受信し、ステップＳ１３３０では、ＲＡＭ２０３等に保存された受注データをＤＢサーバ１０２に送信する。合わせて、編集された受注票の種別が黒伝の受注票なのか、赤伝の受注票なのかも送信する。
【０１２４】
ステップＳ１３３１では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された受注データを受信し、ステップＳ１３３２では、受信した受注データに基づいて、受注データテーブル８１０を更新する。特に、受注票種別８１３に、編集された受注票の種別が黒伝の受注票なのか、赤伝の受注票なのかを格納しておく。更新が完了したら、ステップＳ１３３３では、クライアント端末１０８に対して、更新の実行結果を送信する。ＦＡＸ受注処理サーバ１００を介して送信してもよい。
【０１２５】
ステップＳ１３３４では、クライアント端末１０８は、受注データの更新結果を受信すると、受注票編集処理を終了する。このようにして、クライアント端末１０８を通じて受注票作成に必要なデータの編集を行う。
【０１２６】
次に、本発明の実施形態におけるクライアント端末１０８、ＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２によって行われる受注票プレビュー処理について、図１７に示すフローチャートを用いて説明する。尚、ステップＳ１７０１、ステップＳ１７１２乃至ステップＳ１７１４の各ステップはクライアント端末１０８におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１７０２、ステップＳ１７０３、ステップＳ１７０７乃至ステップＳ１７１１の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ３０１の制御の下、処理が行われる。また、ステップＳ１７０４乃至ステップＳ１７０６の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１２７】
ステップＳ１７０１では、クライアント端末１０８は、選択された注文書データの受注票作成要求を送信する。受注票プレビューボタン１１０３が押下されたレコードの注文書データを特定し、当該注文書データに対応する受注データから受注票の作成を行うことになる。
【０１２８】
ステップＳ１７０２では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から送信された受注票作成要求を受信し、ステップＳ１７０３では、受注票プレビューボタン１１０３が押下された注文書データの受注データの取得要求をＤＢサーバ１０２に送信する。
【０１２９】
ステップＳ１７０４では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された受注データの取得要求を受信し、受注票プレビューボタン１１０３が押下された注文データに対応する受注データを取得する。例えば、注文書ＩＤ７０１が「Ａ０００１」であれば、受注データテーブル８１０の注文書ＩＤ８１２が「Ａ０００１」となっているレコードを特定し、当該レコードを取得する。そして、ステップＳ１７０６では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００に対して、取得した受注データを送信する。
【０１３０】
ステップＳ１７０７では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から送信された受注データを取得し、ステップＳ１７０８では、取得した受注データに基づいて受注票を生成する処理を実行する。受注票生成処理の詳細は、後述する図１９に示す。尚、生成された受注票は、ＰＤＦデータである。
【０１３１】
ステップＳ１７０９では、ＦＡＸ受注処理サーバ１００は、生成された受注票をＦＡＸ受注処理サーバ１００に備えられた外部メモリ２１１等の所定の記憶領域に保存する（キャッシュ手段）。後述する受注票印刷処理においても受注票を生成することになる。つまり、事前にプレビューしていた場合には、プレビューと印刷で重複して受注票を生成することになる。なので、プレビューしていた場合には、このように記憶しておき、後述するステップＳ１７１０でキャッシュテーブル１８００に記憶管理させておくことで、無駄な生成を防ぐことができる。
【０１３２】
ステップＳ１７１０では、ＦＡＸ受注処理サーバ１００は、保存した受注票に関する情報をキャッシュテーブル１８００（図１８参照）に保存する。受注票ＩＤ１８０１には、当該受注データの受注票ＩＤ８１１を格納し、受注票ファイルパス１８０２には、ステップＳ１７０９で保存した保存先のファイルパスを格納する。絶対パスでも相対パスでもよい。
【０１３３】
ステップＳ１７１１では、ＦＡＸ受注処理サーバ１００は、生成した受注票をクライアント端末１０８に送信する。
【０１３４】
ステップＳ１７１２では、クライアント端末１０８は、ＦＡＸ受注処理サーバ１００から送信された受注票を受信し、ステップＳ１７１３では、クライアント端末１０８のＣＲＴ２１０等に表示させる。これにより、ユーザに対して正しい受注票が生成されたのか否かを確認させることができる。
【０１３５】
ステップＳ１７１４では、クライアント端末１０８は、ユーザからの操作により、プレビューの終了指示がなされたか否かを判定する。プレビューの終了指示がなされたと判定された場合には、受注票プレビュー処理を終了し、そうでない場合には待機する。
【０１３６】
次に、本発明の実施形態におけるＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２によって行われる受注票生成処理について、図１９に示すフローチャートを用いて説明する。尚、ステップＳ１９０１、ステップＳ１９０２、ステップＳ１９０６乃至ステップＳ１９２１の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ１９０３乃至ステップＳ１９０５の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１３７】
ステップＳ１９０１では、ＦＡＸ受注処理サーバ１００は、受注票を作成する受注データのうち、１つを参照する。
【０１３８】
ステップＳ１９０２では、ＦＡＸ受注処理サーバ１００は、参照した受注データの商品コード８１５に対応する商品種別の取得要求をＤＢサーバ１０２に対して送信する。
【０１３９】
ステップＳ１９０３では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された商品種別の取得要求を受信し、ステップＳ１９０４では、商品マスタテーブル９１０と参照した受注データの商品コード８１５から商品種別９１３を特定する。例えば、参照している受注データの商品コード８１５が「Ｓ００００１０１」であった場合、商品マスタテーブル９１０の商品コード９１１とマッチングをかけると、図９に示す商品マスタテーブルにおいては２行目のレコードであることがわかる。この２行目のレコードの商品種別９１３は「ソフトウェア」であることが特定できる。これにより商品種別が判断できる。
【０１４０】
ステップＳ１９０５では、ＤＢサーバ１０２は、特定した商品種別をＦＡＸ受注処理サーバ１００に対して送信する。
【０１４１】
ステップＳ１９０６では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から送信された商品種別を受信する。そして、ステップＳ１９０７では、ＦＡＸ受注処理サーバ１００は、受信した商品種別が「ソフトウェア」か否かを判定する（判定手段）。「ソフトウェア」であると判定された場合には、ステップＳ１９０８に処理を進め、そうでない場合には、ステップＳ１９１３に処理を進める。
【０１４２】
ステップＳ１９０８では、ＦＡＸ受注処理サーバ１００は、参照中の受注データに基づいて、受注票を作成するためのＤＡＴファイル（受注票元データ）を２つ生成する。ＤＡＴファイルは、後述する処理において受注票のフォームに表示させるテキストデータを格納したファイルである。１つのＤＡＴファイルとフォームを結合することで、１つの受注票が生成できる。ここで、ステップＳ１９０７において、参照中の受注データの商品種別が「ソフトウェア」であると判定されている。ソフトウェアは、在庫がなく、黒伝だけ発行しても在庫をマイナスすることができない。よって、ここでは、在庫を仮想的に赤伝の受注票と黒伝の受注票を発行する。そのために、ステップＳ１９０８では、赤伝用のＤＡＴファイルと、黒伝用のＤＡＴファイルの両方を生成しておく。
【０１４３】
ステップＳ１９０９では、ＦＡＸ受注処理サーバ１００は、黒伝の受注票を構成するためのフォームデータを取得する。フォームデータはあらかじめ作成され、ＦＡＸ受注処理サーバ１００に保存されているものとする。そして、ステップＳ１９１０では、黒伝用のＤＡＴデータと黒伝用のフォームデータとを重ね合わせて結合し、黒伝の受注票を生成する（伝票発行手段）。ファイル形式はなんでもよいが、ここではＰＤＦデータとする。
【０１４４】
ステップＳ１９１１では、ＦＡＸ受注処理サーバ１００は、更に赤伝の受注票を構成するためのフォームデータを取得する。そして、ステップＳ１９１２では、赤伝用のＤＡＴデータと、黒伝用のフォームデータとを重ね合わせて結合し、赤伝の受注票を生成する（伝票発行手段）。このように、商品種別が「ソフトウェア」の場合には、赤伝と黒伝の両方を発行し、仮想的に在庫を増やした後に在庫を減らせるようにしている。尚、黒伝の受注票は、図２０に示す通りとなる。参照中の受注データを黒伝用のフォームデータに表示させている様子がわかる。また、赤伝用の受注票は、図２１に示す通りである。
【０１４５】
一方、ステップＳ１９０７で商品種別が「ソフトウェア」でないと判定された場合には、ステップＳ１９１３では、ＦＡＸ受注処理サーバ１００は、参照中の受注データの受注票種別８１３が何かを判定する。黒伝であると判定された場合には、ステップＳ１９１４に処理を進め、赤伝であると判定された場合には、ステップＳ１９１７に処理を進める。こちらの処理は、従来技術と同様の処理になる。
【０１４６】
ステップＳ１９１４では、ＦＡＸ受注処理サーバ１００は、参照中の受注データに基づいて、受注票を作成するためのＤＡＴファイルを１つ生成する。こちらは、黒伝だけ生成すればよいので、１つだけ生成する。そして、ステップＳ１９１５では、黒伝の受注票を構成するためのフォームデータを取得し、ステップＳ１９１６では、生成されたＤＡＴファイルと黒伝用のフォームデータとを重ね合わせて結合し、黒伝の受注票を生成する。
【０１４７】
一方、受注票種別が赤伝であると判定された場合には、ステップＳ１９１７では、参照中の受注データに基づいて、受注票を作成するためのＤＡＴファイルを１つ生成する。こちらは、赤伝だけ生成すればよいので、１つだけ生成する。そして、ステップＳ１９１８では、赤伝の受注票を構成するためのフォームデータを取得し、ステップＳ１９１９では、生成されたＤＡＴファイルと赤伝用のフォームデータとを重ね合わせて結合し、赤伝の受注票を生成する。
【０１４８】
ステップＳ１９２０では、ＦＡＸ受注処理サーバ１００は、ＦＡＸ受注処理サーバ１００が受信したすべての受注データの受注票が生成されたか否かを判定する。受注票がすべて生成されたと判定された場合には、ステップＳ１９２１に処理を進め、そうでない場合には、ステップＳ１９０１に処理を戻し、未処理の受注データに対して受注票を生成する。
【０１４９】
ステップＳ１９２１では、ＦＡＸ受注処理サーバ１００は、生成されたすべての受注票を１つの受注票として結合する。つまり、最終的な受注票は、受注データごとに保存されるのではなく、注文書と１対１になるように１つの受注票として保存されることになる。こうすることで、後述する印刷処理で受注データごとに複数の印刷ジョブを生成せずとも、１つの印刷ジョブを生成するだけで済む。
【０１５０】
次に、本発明の実施形態におけるクライアント端末１０８、ＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２、複合機１０３によって行われる受注票印刷処理について、図２２に示すフローチャートを用いて説明する。尚、ステップＳ２２０１、ステップＳ２２１６の各ステップはクライアント端末１０８におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２２０２、ステップＳ２２０３、ステップＳ２２０７乃至ステップＳ２２１２の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２２０４乃至ステップＳ２２０６の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２２１３乃至ステップＳ２２１５の各ステップは複合機１０３におけるＣＰＵ３０１の制御の下、処理が行われる。
【０１５１】
ステップＳ２２０１では、クライアント端末１０８は、選択された注文書データの受注票作成要求を送信する。受注票印刷ボタン１１０４が押下されたレコードの注文書データを特定し、当該注文書データに対応する受注データから受注票の作成を行うことになる。
【０１５２】
ステップＳ２２０２では、ＦＡＸ受注処理サーバ１００は、クライアント端末１０８から送信された受注票作成要求を受信し、ステップＳ２２０３では、受注票印刷ボタン１１０４が押下された注文書データの受注データの取得要求をＤＢサーバ１０２に送信する。
【０１５３】
ステップＳ２２０４では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された受注データの取得要求を受信し、受注票印刷ボタン１１０４が押下された注文データに対応する受注データを取得する。例えば、注文書ＩＤ７０１が「Ａ０００１」であれば、受注データテーブル８１０の注文書ＩＤ８１２が「Ａ０００１」となっているレコードを特定し、当該レコードを取得する。そして、ステップＳ２２０６では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００に対して、取得した受注データを送信する。
【０１５４】
ステップＳ２２０７では、ＦＡＸ受注処理サーバ１００は、ＤＢサーバ１０２から送信された受注データを取得する。そして、ステップＳ２２０８では、ＦＡＸ受注処理サーバ１００は、当該受注データの受注票が既に生成済みで、ＦＡＸ受注処理サーバ１００の所定の記憶領域に保存されていないかどうかを判定する。つまり、キャッシュとして保存されていないかどうかを判定することになる。具体的には、当該受注データの受注票ＩＤ８１１と一致する、キャッシュテーブル１８００の受注票ＩＤ１８０１が存在するか否かを判定すればよい。キャッシュとして保存されていると判定された場合には、ステップＳ２２０９に処理を進め、そうでない場合には、ステップＳ２２１０に処理を進める。
【０１５５】
ステップＳ２２０９では、ＦＡＸ受注処理サーバ１００は、生成済みの受注票を取得するべく、受注票ＩＤ１８０１が一致するレコードの受注票ファイルパス１８０２が示す記憶領域から受注票を取得する。こうすることで、一度プレビューで受注票を生成しているのであれば、その生成した受注票を使用して印刷をかけることができる。
【０１５６】
一方、ステップＳ２２１０では、ＦＡＸ受注処理サーバ１００は、受注票生成処理を実行する。受注票生成処理の詳細は、図１９で前述した通りである。
【０１５７】
ステップＳ２２１１では、ＦＡＸ受注処理サーバ１００は、ステップＳ２２０９またはステップＳ２２１０で取得した受注票から印刷ジョブを生成する。ＦＡＸ受注処理サーバ１００にはプリンタドライバが備えられており、このプリンタドライバを介して印刷ジョブを生成する。そして、ステップＳ２２１２では、生成された印刷ジョブを複合機１０３に送信する。
【０１５８】
ステップＳ２２１３では、複合機１０３は、ＦＡＸ受注処理サーバ１００から送信された印刷ジョブを受信し、ステップＳ２２１４では、受信した印刷ジョブの印刷を実行する。そして、ステップＳ２２１５では、印刷の実行結果をクライアント端末１０８に送信する。ＦＡＸ受注処理サーバ１００を介してもよい。
【０１５９】
ステップＳ２２１６では、クライアント端末１０８は、印刷の実行結果を受信すると、受注票印刷処理を終了する。
【０１６０】
次に、本発明の実施形態におけるＦＡＸ受注処理サーバ１００、ＤＢサーバ１０２によって行われる在庫調整に関する処理について、図２３に示すフローチャートを用いて説明する。尚、ステップＳ２３０１、ステップＳ２３０８の各ステップはＦＡＸ受注処理サーバ１００におけるＣＰＵ２０１の制御の下、処理が行われる。また、ステップＳ２３０２乃至ステップＳ２３０７の各ステップはＤＢサーバ１０２におけるＣＰＵ２０１の制御の下、処理が行われる。
【０１６１】
ステップＳ２３０１では、ＦＡＸ受注処理サーバ１００は、前述した処理において生成された受注票をＤＢサーバ１０２に送信する。ここで送信しているのは、受注票の内容を在庫管理に反映するためである。この送信のタイミングはいつでもよい。時間帯が決まっていれば、特定の時間帯に毎日送信するようにしてもよいし、ユーザから指示があった場合に送信するようにしてもよい。
【０１６２】
ステップＳ２３０２では、ＤＢサーバ１０２は、ＦＡＸ受注処理サーバ１００から送信された受注票を受信する。そして、ステップＳ２３０３では、受信した受注票に赤伝が含まれているか否かを判定する。つまり、ソフトウェアの場合には、前述した処理において赤伝と黒伝の両方が生成されているので、ここで判定することにより、例外的な在庫調整を行える。赤伝が含まれていると判定された場合には、ステップＳ２３０４に処理を進め、そうでない場合には、ステップＳ２３０５に処理を進める。
【０１６３】
ステップＳ２３０４では、ＤＢサーバ１０２は、受注票に含まれる赤伝に基づいて、対象製品の在庫を一時的に増やす（在庫調整手段）。受注票にＯＣＲ処理を実行し、対象の製品と調整する在庫数を取得すればよい。例えば、商品コード８１５「Ｓ００００１０１」である「プリンタ用ソフトウェア」で数量単位８１６が「２」なら、当該商品コード８１５と一致する在庫情報テーブル２４００（図２４参照）の商品コード２４０１のレコードを特定し、当該レコードの在庫数２４０２に数量単位８１６だけ増やして、「０」から「２」に変更すればよい。これで一時的にソフトウェアであっても在庫が増加する。
【０１６４】
在庫情報テーブル２４００（図２４参照）は、商品コード２４０１と在庫数２４０２から構成される。商品コード２４０１は、商品コード９１１と対応するコードである。在庫数２４０２は、システム上で管理している製品の在庫数である。
【０１６５】
ステップＳ２３０５では、ＤＢサーバ１０２は、受注票に含まれる黒伝に基づいて、対象製品の在庫を一時的に減らす（在庫調整手段）。こちらも同様に、受注票にＯＣＲ処理を実行し、対象製品の数量単位８１６を使用して、在庫情報テーブル２４００の在庫量を減らす（引き当てる）。ソフトウェアであれば、ステップＳ２３０４で一時的に増やした在庫をこちらで減らすことになる。よって、プラスマイナスゼロになる。よって、ソフトウェアは在庫が０であるという前提と従来の業務フローを崩さずに、受注票から在庫管理を行うことができる。
【０１６６】
ステップＳ２３０６では、ＤＢサーバ１０２は、ステップＳ２３０２で受信したすべての受注票に対して処理が終了したか否かを判定する。すべての受注票に対して処理が終了したと判定された場合には、ステップＳ２３０７に処理を進め、そうでない場合には、ステップＳ２３０３に処理を戻して、すべての受注票が処理できるまで繰り返す。
【０１６７】
ステップＳ２３０７では、ＤＢサーバ１０２は、在庫調整の実行結果をＦＡＸ受注処理サーバ１００に送信する。
【０１６８】
ステップＳ２３０８では、ＦＡＸ受注処理サーバ１００から送信された実行結果を受信すると、本一連の処理を終了する。
【０１６９】
以上説明したように、本実施形態によれば、ソフトウェアの発注があった場合には、発注された数量分の在庫を増やすための赤伝票と、発注された数量分の在庫を減らすための黒伝票を発行することが可能となるので、赤伝票によって必要な在庫を増やした後に、黒伝票によって在庫の引当てをすることで、ソフトウェアの在庫を「０」に保つことができ、従来のシステムであってもソフトウェアの在庫を適切に管理することの可能な効果を奏する。
【０１７０】
本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、１つの機器からなる装置に適用してもよい。
【０１７１】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
【０１７２】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１７３】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１７４】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。
【０１７５】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１７６】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１７７】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１７８】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１７９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【０１８０】
なお、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【０１８１】
１００  ＦＡＸ受注処理サーバ
２００  ＤＢサーバ
３００  複合機
４００  ファクシミリ
６００  外部クライアント端末
７００  メールサーバ
８００  クライアント端末
９００  ネットワーク
２０１  ＣＰＵ
２０２  ＲＡＭ
２０３  ＲＯＭ
２０４  システムバス
２０５  入力コントローラ
２０６  ビデオコントローラ
２０７  メモリコントローラ
２０８  通信Ｉ／Ｆ（インターフェース）コントローラ
２０９  入力装置
２１０  ディスプレイ装置
２１１  外部メモリ
【図１】
2014092888.tif 000003
【図２】
2014092888.tif 000004
【図３】
2014092888.tif 000005
【図４】
2014092888.tif 000006
【図５】
2014092888.tif 000007
【図６】
2014092888.tif 000008
【図７】
2014092888.tif 000009
【図８】
2014092888.tif 000010
【図９】
2014092888.tif 000011
【図１０Ａ】
2014092888.tif 000012
【図１０Ｂ】
2014092888.tif 000013
【図１１】
2014092888.tif 000014
【図１２】
2014092888.tif 000015
【図１３Ａ】
2014092888.tif 000016
【図１３Ｂ】
2014092888.tif 000017
【図１４】
2014092888.tif 000018
【図１５】
2014092888.tif 000019
【図１６】
2014092888.tif 000020
【図１７】
2014092888.tif 000021
【図１８】
2014092888.tif 000022
【図１９】
2014092888.tif 000023
【図２０】
2014092888.tif 000024
【図２１】
2014092888.tif 000025
【図２２】
2014092888.tif 000026
【図２３】
2014092888.tif 000027
【図２４】
2014092888.tif 000028