JP5199563B2 - データ処理システム、およびデータ処理方法 - Google Patents

Description

この発明は、伝票等に表示された２次元コードを読み取ることによって、伝票等の記載内容をディジタルデータとして取得するデータ処理システムに関する。

近年、必要な情報をバーコードのようなシンボルで表し、それらをバーコードリーダ等で読み取ることによってディジタル情報を取得し、入力負荷の軽減や誤入力の抑止を図ることができるシステムが多く導入されている。また、商品のトレーサビリティの実現にＱＲコードなどが利用される例も増えてきている。

また、特許文献１では、レシートやチケットなどの内容を２次元コード化し、それを携帯端末の２次元コードキャプチャで読み込み、ネットワークを介して接続されたデータベースに格納するシステムが開示されている。このシステムによりデータベースに格納された読み込みデータは必要に応じて加工され、たとえば、家計簿や経費計算書などに利用される。
特開２００２−３０４５１８号公報

また、特許文献２では、手形要件の全必要情報事項およびユニーク番号の情報事項をデータ領域に含む２次元シンボルマークを、その手形の表面に印字表現し、その後、照合チェック等のために、手形の２次元シンボルマークを読み取る手形処理システムが開示されている。
特開２００２−４１８１４号公報

しかしながら、こうした従来の技術では、たとえば、伝票に記載される製品の明細行に記載された明細データについての２次元コードは生成されておらず、２次元コードを読み取ることによって、これらの明細データを電子化・記録し、その後の効率的なコンピュータ処理につなげることができない。

したがって、本発明の目的は、伝票等の記載内容を２次元コード化して伝票等の表面に表示し、その２次元コードを読み取り、電子化・記録することによって、当該記載内容の入力作業を不要とし、こうして読み取られた記載内容のデータを、伝票発行処理などの他の帳票の作成処理と効果的に連携させるデータ処理システム、およびデータ処理方法を提供することにある。

また、本発明のさらなる目的は、伝票に記載される製品に関する明細データを２次元コードに含ませることにより、伝票入力の省力化および誤入力を防止することが可能なデータ処理システム、およびデータ処理方法を提供することにある。

またさらに、本発明の目的は、伝票等の表面に表示される２次元コードの元となるデータ（明細データ）を暗号化することによって、他人による２次元コードの流用を防止することのできるデータ処理システム、およびデータ処理方法を提供することにある。

また、業務横断的に複数の見積書を生成し、これらを同時に並べて表示させる機能を有するデータ処理システムを提供することも本発明の目的である。

本発明の第１の実施態様は、第１の帳票の表面に表されたシンボルから、第１の帳票の明細データを、シンボル読み取り手段を経由して受信する明細データ受信手段と、明細データを用いて、第１の帳票とは異なる第２の帳票を構成するための帳票データを生成する帳票データ生成手段を有するよう構成されるデータ処理システムである。

本発明の第２の実施態様は、第１の実施態様のデータ処理システムにおいて、第１の帳票が納品物に関連する帳票であり、明細データが、納品物の明細情報であるよう構成される。

本発明の第３の実施態様は、第１の実施態様のデータ処理システムにおいて、帳票データ生成手段は、明細データに関連付けて取得された関連データを用いて帳票データを生成するよう構成される。

本発明の第４の実施態様は、第１の実施態様のデータ処理システムにおいて、シンボルは、明細データを暗号化した暗号データを元に生成されており、明細データ受信手段は、シンボル読み取り手段により得られた暗号データを復号化することにより、明細データを取得するよう構成される。

本発明の第５の実施態様は、第４の実施態様のデータ処理システムにおいて、暗号化の方法が、第１の帳票の種別、または第１の帳票に記載された項目にしたがって切り替えられ、明細データ受信手段は、切り替えられた暗号化の方法に応じて復号化の方法を選択するよう構成される。

本発明の第６の実施態様は、第１の帳票の表面に表されたシンボルから、第１の帳票の明細データを、シンボル読み取り手段を経由して受信する明細データ受信ステップと、明細データを用いて、第１の帳票とは異なる第２の帳票を構成するための帳票データを生成する帳票データ生成ステップを有するよう構成されるデータ処理方法である。

本発明の第７の実施態様は、第６の実施態様のデータ処理方法において、第１の帳票が納品書であり、明細データが、納品書に明細行に記載されるデータであるよう構成される。

本発明の第８の実施態様は、第６の実施態様のデータ処理方法において、シンボルは、明細データを暗号化した暗号データを元に生成されており、明細データ受信ステップは、シンボル読み取り手段により得られた暗号データを復号化することにより、明細データを取得するよう構成される。

本発明の第９の実施態様は、コンピュータを、第１の帳票の表面に表されたシンボルから、第１の帳票の明細データを、シンボル読み取り手段を経由して受信する明細データ受信手段、および、明細データを用いて、第１の帳票とは異なる第２の帳票を構成するための帳票データを生成する帳票データ生成手段として動作させるためのプログラムである。

本発明の第１０の実施態様は、あらかじめ登録された提案用のコースをもとに複数の見積書を作成する見積書作成手段と、複数の見積書を同時に並べて表示するよう制御する表示制御手段を有するよう構成されたデータ処理システムである。

本発明の第１１の実施態様は、第１０の実施態様のデータ処理システムにおいて、複数の見積書は業務横断的に作成され、それぞれの見積書の表示部から見積書作成画面へのリンク付けがされるよう構成される。

本発明のデータ処理システムにより、伝票等の記載内容を手入力する作業が不要となるとともに、２次元コードの読み取りによって得られたデータを即座に、他の関連処理と連携させることができ、全体として迅速なデータ処理が可能となる。

また、伝票等の記載内容を手入力する作業が不要となるため、一切の誤入力をなくすことができる。さらに、２次元コードを生成するための元データ（明細データ）を暗号化するため、伝票等の表面に表示された２次元コードを第三者が不正に読み取っても、伝票等の記載内容を把握することができず、結果的にデータ漏洩の危険性が少なく、高いセキュリティレベルを実現できる。

さらに、本発明のデータ処理システムで、業務横断的に複数の見積書を生成し、これらを同時に並べて表示させることができるため、顧客に対して分かりやすく有用なサービスを提供できる。

最初に、本発明の一実施形態に係るデータ処理システムについて、図１を参照して、そのシステム構成の概要を説明する。図１に示すデータ処理システム１０は、大きくは２つのサイトにおけるシステムを含むものとして捉えることができる。

第１サイト１００では、コンピュータ１１０と、コンピュータ１１０に接続されたプリンタ１２０が配置され、プリンタ１２０から伝票１３０がプリントアウトされる。一方、第２サイト２００では、コンピュータ２１０と、コンピュータ２１０に接続された２次元コードリーダ２２０が配置され、第１サイト１００から郵送やファクシミリ送信等によって届けられた伝票１３０を２次元コードリーダ２２０で読み取り、読み取りの結果得られたデータを、コンピュータ２１０を介してデータベース２３０に送信し、たとえば伝票番号と対応付けて格納する。

ここで、第１サイト１００は、たとえば、自動車の部品を納入する部品商であり、伝票１３０は、納品した商品（納品物）に関する情報を記載した帳票の１つである納品書である。このとき、第２サイト２００は、たとえば、整備工場であり、データベース２３０に送信されるデータは、仕入情報として記録される。なお、データベース２３０は、コンピュータ２１０が備える記録手段上に構成されてもよいし、インターネットやＬＡＮといったネットワークを介して他のコンピュータやサイトに配置されていてもよい。

図２に示す納品書３００は、第１サイト１００が部品商であり、第２サイトが整備工場である上述したケースにおける、伝票１３０の一例である。第１サイト１００である部品商は、第２サイトである整備工場の発注等に基づいて部品を納入し、納入した部品を記載した納品書３００を整備工場に送付する。

納品書３００には、納入した各部品の明細情報が明細３１０に記載されている。この納品書３００のフォーマットでは、６種類の部品を記載することができ、図２の例では３つの部品が記載されている。各部品については、たとえば、図２に示すように、型式と車名・年式、品番・コードと品名、出荷数、単価、金額、標準価格、備考といった部品の属性等を示す明細情報が記載される。

また、納品書３００には、ＱＲコード３２０が示されている。ＱＲコード３２０は、明細３１０に記載されている各部品の明細データを含んでおり、明細データは、（好ましくは）暗号化されたうえでコード化される。明細データは、上述のように部品の属性を示す明細情報で構成されるが、ＱＲコード３２０には、一部の情報だけを含むように構成することもできる。たとえば、明細情報のうち部品のコードと出荷数だけをＱＲコードに埋め込み、これを受信した側で、単価等のデータを他のデータソースから取得するような構成も考えられる。

図２の例では、２次元コードの例としてＱＲコード３２０が用いられているが、ＱＲコードには限られない。たとえば、スタック型２次元コードではＰＤＦ４１７、マトリックス型２次元コードでは、（ＱＲコードの他）Data MatrixやMaxi Codeなどの様々なコードを用いることができる。また、１次元のバーコードのようなコードを用いることもできる。本発明では、明細３１０のデータを別のシンボル（表示形式）に変換でき、後でその明細３１０のデータを再現できる限り、どのようなシンボルを用いることも可能である。

図１に示す２次元コードリーダ２２０も、光学的にＱＲコードを読み取るＱＲコードリーダのほか、伝票１３０に表示されたシンボルの種類に応じて様々なシンボル読み取り装置が考えられる。たとえば、１次元のバーコードを読み取る場合は、これを読み取り可能なバーコードリーダが用いられる。

また、図１では、このようなシンボルを含む伝票１３０がプリンタ１２０により印刷される例を示したが、本発明では、伝票１３０と一体となってシンボルが表示されていれば足りる。したがって、伝票１３０と同時に印刷される場合のほか、シンボルを表示したシールを伝票１３０に貼るようにしてもよいし、別の図形形成装置で伝票１３０上に当該シンボルを表示するようにしてもよい。

図３には、読み取った明細３１０の明細データが反映された仕入伝票入力画面４００が示されている。仕入伝票入力画面４００は、図１に示す第２サイト２００（整備工場）のコンピュータ２１０の表示装置上に表示される。明細３１０の明細データは、データベース２３０で、仕入情報として記憶されたあと（または、データベース２３０を経由することなく直接）、コンピュータ２１０またはサーバのプログラムによってデータベース２３０から抽出され、仕入伝票入力画面４００の入力項目にセットされる。ここで、仕入伝票入力画面４００を表示する前、または入力の確定が行われた後といったタイミングで、仕入伝票に対応する帳票データが生成される。

仕入伝票入力画面４００の明細４１０の部分には、図２で示したような納品書３００に記載された明細３１０の内容が、部品として自動的にセットされる。そのため、図３の明細４１０に示された各部品の明細情報は、図２に示す納品書３００に記載されたものと一致することになるが、ここでは、それぞれ別の例を用いたため一致していないことに注意が必要である。

図４には、読み取った明細３１０のデータが反映された整備伝票発行画面５００が示されている。整備伝票発行画面５００は、図１に示す第２サイト２００（整備工場）のコンピュータ２１０の表示装置上に表示される。明細３１０の明細データは、データベース２３０で、仕入情報として記憶されたあと（または、データベース２３０を経由することなく直接）、コンピュータ２１０またはサーバのプログラムによってデータベース２３０から抽出され、整備伝票発行画面５００の入力項目にセットされる。ここでも、整備伝票に関するデータを含む帳票データが、所定のタイミングで生成される。

整備伝票発行画面５００の符号５１０で示す明細行の部分には、図２で示したような納品書３００に記載された明細３１０の内容が、部品として自動的にセットされる。そのため、図４の符号５１０で示す明細行に示された各部品の明細情報は、図２に示す納品書３００に記載されたものと一致することになるが、ここでは、それぞれ別の例を用いたため一致していないことに注意が必要である。

また、図４の整備伝票発行画面５００においては、納品書３００に記載された明細３１０の内容を取り込むとともに、その部品に関連する作業が、明細行として自動的に（あるいは、その部品の情報を元にしたユーザによる所定の指示で）追加される。たとえば、上記プログラムは、明細行Ｎｏ．３の部品（コード＝２３８、フロント・ディスクパッドキット）の追加に応じて、明細行Ｎｏ．２の作業（コード＝４８０、フロント・ディスク・パッド取替）が追加される。また、上記のプログラムにより、当該作業の技術料や工賃等など、その作業に関連する項目が、データベース２３０から取得されセットされる。

次に、図５を参照して、シンボルによってデータが第１サイトから第２サイトに渡される手順について説明する。この例では、シンボルとしてＱＲコードが用いられ、データとして納品書の明細行等に記載された明細データとその他の情報を含む納品データが用いられる。

最初に、ステップＳ１２において、第１サイト１００のコンピュータ１１０に、納品データが第１サイト１００のユーザや他のシステムから入力される。コンピュータ１１０は、納品データを受けると、ステップＳ１４において、その納品データを暗号化する。納品データは、図２に示したように、１つまたは複数の部品の属性等を示す明細情報である。

その後、コンピュータ１１０は、ステップＳ１６において、暗号化した納品データを元に、ＱＲコードから形成されるシンボルを生成し、ステップＳ１８において、生成されたＱＲコードのシンボルを納品書３００に印刷する。

こうして印刷されたＱＲコード付きの納品書３００は、郵送やファクシミリ送信等の手段で第２サイト２００、すなわち、実際に部品の納品を受けた整備工場等に送られる。

ＱＲコード付きの納品書３００を受け取った第２サイト２００では、ステップＳ２０において、コンピュータ２１０に接続された２次元コードリーダ２２０（ＱＲコードリーダ）で、それぞれの納品書３００のＱＲコードを読み取り、暗号化された納品データを取得する。

暗号化されている納品データは、ステップＳ２２において復号される。この復号は、ステップＳ１４の暗号化に対応するものであり、暗号化されたものが確実に元のコードに復号される限り、どのような暗号化手段を用いてもよい。また、納品書３００に記載されたいずれかの項目や、その他の取り決めによって決定されたルールにしたがって暗号化の方法を切り替えるようにしてもよい。

こうして復号されたデータは、ステップＳ１２の納品データであり、各部品の明細情報（明細データ）が含まれる。各部品の明細情報は、ステップＳ２４で、たとえば、伝票番号等に対応付けられてデータベース２３０に記録される。これらの明細情報が直接、コンピュータ２１０のアプリケーションで使用され、その後利用されることがない場合は、データベース２３０への記録は必須の処理ではない。データベース２３０に記録された明細情報は、その後、図３や図４に示すように、様々なアプリケーションに利用されうる。

ここで、第１サイト１００のコンピュータ１１０と第２サイト２００のコンピュータ２１０には、それぞれの別のシステム（プログラム）が導入される可能性もあるが、図５の一連の処理を実現するには、ＱＲコードの生成・展開（ステップＳ１６とステップＳ２０）と暗号化・復号の処理（ステップＳ１４とステップＳ２２）において、両方のシステム間で整合性がとれている必要がある。

ここまで、本発明のデータ処理システム１０を、納品書３００のような伝票１３０に関連するデータを処理するシステムとして説明してきたが、特に、伝票や納品書を対象としたものに限られるわけではなく、その記載内容を読み取り、その記載内容をデータとして利用することが必要な全ての帳票が対象となりうる。

次に、図６を参照して、本発明に係るデータ処理システム１０のコンピュータ２１０（あるいはコンピュータ１１０）として用いられるコンピュータのハードウエア構成の例について説明する。ただし、図６のコンピュータ６００は、データ処理システム１０で用いられるコンピュータの代表的な構成を例示したにすぎない。

コンピュータ６００は、ＣＰＵ６０１、メモリ６０２、音声出力装置６０３、ネットワークインタフェース６０４、ディスプレイコントローラ６０５、表示装置６０６、入力機器インタフェース６０７、キーボード６０８、マウス６０９、外部記憶装置６１０、記録媒体駆動装置６１１、２次元コードリーダインタフェース６１２、およびこれらの構成要素を互いに接続するバス６１３を含んでいる。なお、コンピュータ２１０については、少なくとも、音声出力装置６０３およびネットワークインタフェース６０４は、必須の構成要素ではない。

ＣＰＵ６０１は、コンピュータ６００の各構成要素の動作を制御し、ＯＳの制御下で、各プログラムの実行をコントロールし、本発明に係るデータ処理システム１０の各構成要素の動作を制御する。メモリ６０２は通常、不揮発性メモリであるＲＯＭ（Read Only Memory）、および揮発性メモリであるＲＡＭ（Random Access Memory）から構成される。ＲＯＭには、コンピュータ６００の起動時に実行されるプログラム等が格納される。ＲＡＭには、ＣＰＵ６０１で実行され、本発明のサーバ、管理端末、クライアント端末の各機能を実現するためのプログラムや、それらのプログラムが実行中に使用するデータが格納される。

音声出力装置６０３は、たとえば、スピーカ等の、音声を出力する機器であり、ネットワークインタフェース６０４は、ネットワーク６２０に接続するためのインタフェースである。

ディスプレイコントローラ６０５は、ＣＰＵ６０１が発行する描画命令を実際に処理するための専用コントローラである。ディスプレイコントローラ６０５で処理された描画データは、一旦グラフィックメモリに書き込まれ、その後、表示装置６０６に出力される。表示装置６０６は、たとえば、ＬＣＤやＣＲＴで構成されるディスプレイ装置であり、コンピュータ２１０で図３や図４に示すような画面を表示するのに使用される。

入力機器インタフェース６０７は、キーボード６０８やマウス６０９から入力された信号を受信して、その信号パターンに応じて所定の指令をＣＰＵ６０１に送信する。キーボード６０８やマウス６０９は、コンピュータ２１０において業務アプリケーションの操作等をする場合に必要となる。

外部記憶装置６１０は、たとえば、ハードディスクドライブ（ＨＤＤ）のような記憶装置であり、この装置内には上述したプログラムやデータが記録され、実行時に、必要に応じてそこからメモリ６０２のＲＡＭにロードされる。コンピュータ２１０のデータベース２３０等の格納される記憶手段が、この外部記憶装置６１０に相当する。

記録媒体駆動装置６１１は、ＣＤ（Compact Disc）、ＭＯ（Magneto-Optical Disc）、ＤＶＤ（Digital Versatile Disc）などの可搬型ディスクタイプの記録媒体６３０の記録面にアクセスして、そこに記録されているデータを読み取る装置である。記録媒体６３０には、本発明に係るデータ処理システム１０を実現するためのプログラムも記録することが可能である。記録媒体６３０に記録されているデータは、記録媒体駆動装置６１１を介して外部記憶装置６１０に格納され、プログラムであれば、実行時にメモリ６０２のＲＡＭにロードされる。

また、本発明に係るデータ処理システム１０を実現するためのプログラムの他の流通形態としては、ネットワーク上の所定のサーバから、ネットワーク６２０およびネットワークインタフェース６０４を介して外部記憶装置６１０に格納され、あるいは直接実行されるということも考えられる。このようなルートで格納されたプログラムは、上記と同様に、実行時にメモリ６０２のＲＡＭにロードされ、実行される。

２次元コードリーダインタフェース６１２は、２次元コードリーダ６４０に接続される。たとえばＵＳＢ端子のような端子である。２次元コードリーダ６４０が所定のシンボルを読み取った結果、取得したディジタルデータは、２次元コードリーダインタフェース６１２を介して、メモリ６０２や外部記憶装置６１０に取り込まれ、以降の処理で使用される。２次元コードリーダ６４０は、図１の２次元コードリーダ２２０に対応する。

第２サイトのコンピュータ２１０はこの他、サーバと協働して、あるいは単独で以下のような自動車整備業に関連する機能を実現する。また、これらのシステムは、設計次第で、コンピュータ２１０が、サーバの提供するデータを表示するためだけに動作するように構成することもできる。

［１．見積条件設定機能］
図７ないし図９は、見積条件の設定機能に関するＧＵＩを示している。図７に示す見積条件設定画面７００では、下取車、車検、保証、納車場所といった見積条件パターンごとに、見積条件を設定できる。たとえば、図７に示す例では、下取車の見積条件パターン（左側「見積条件」表示部７１０）に対して、「なし」と「あり」の２つの設定がされており、さらに、納車場所の見積条件パターン（左側「見積条件」表示部７１０）に対しては、たとえば、「お客様宅」、「販売店」、「指定先」の３つの設定がある。また、図７に示すように、それぞれの見積条件パターンに対し、初期表示をどの内容にするかを指定できる。この例では、下取車の見積条件パターンについて、初期表示が「なし」に設定されている。

図８には、設定表示画面８００で、下取車の見積条件パターンについては「なし」、車検の見積条件パターンについては「点検」、保証の見積条件パターンについては「国産」、そして納車場所の見積条件パターンについては「指定先」という見積条件が設定されている場合に自動表示される諸費用表示画面８１０が示されている。この場合、納車場所は「指定先」となっているため、納車費用が発生し、諸費用表示画面８１０の「納車費用」の欄には、「１３，３３３」の金額（税抜）および「１４，０００」の金額（税込）が表示されている（符号８２０で示される明細行）。

一方、図９には、設定表示画面９００で、下取車の見積条件パターンについては「なし」、車検の見積条件パターンについては「点検」、保証の見積条件パターンについては「国産」、そして納車場所の見積条件パターンについては「販売店」という見積条件が設定されている場合に自動表示される諸費用表示画面９１０が示されている。この場合、納車場所は「販売店」となっているため、納車費用は発生せず、諸費用表示画面９１０の「納車費用」の欄には、「０」の金額（税抜）および「０」の金額（税込）が表示されている（符号９２０で示される明細行）。

この例のように、見積時に必要な条件を設定しておき、条件の初期表示・変更を可能とすることができる。また、見積時の条件を選択することで全ての担当者が同じ見積を作成することが可能となる。

［２．見積書比較機能］
図１０は、顧客に対して見積書を比較可能なように同時に複数表示するＧＵＩを示すものである。図１０に示した比較見積書画面１０００では、たとえば、車検整備に関する見積書の表示部１０２０、軽鈑金に関する見積書の表示部１０３０、および車両販売に関する見積書の表示部１０４０が同時に並べて表示される。

整備工場等では、たとえば、顧客依頼分の見積書を作成後、顧客に対する提案用見積の自動作成を可能とする。そのために、あらかじめ提案用のコースを登録しておき、顧客にとって有用な提案型見積を作成する。図１０に示すように、作成した見積書は１画面に並べて表示されるため、説明も容易であり、顧客にとっても比較検討を容易に行うことができる。また、整備、鈑金、車両販売といった異なる業務に亘る見積書であっても（業務横断的に作成され）１画面で表示・確認することができる。また、図１０に示す状態から、伝票編集ボタン１０１０やその他のリンク等を押下すると、それぞれの見積書の表示部（１０２０〜１０４０）に対応した見積書作成画面に遷移することができる。

［３．工程管理機能］
図１１は、入庫車両の作業工程を管理する工程管理一覧画面１１００を示しており、図１２は、分類別工程詳細一覧画面１２００a、１２００ｂを示している。整備工場等は、自社で管理したい工程を自由に設定可能であり、通常の運用で自動的に、入庫している車両のステータス管理を行うことができる。

図１１の工程管理一覧画面１１００では、入庫車両の車両登録番号、車種、得意先、状態、工程分類、およびスケジュールバー（日単位の工程）が示される。このうち、状態については、たとえば、符号１１１０に示すような、伝票の状態（見積、指示、納品）に基づいた工程の状態が関連付けられ表示される。この工程は、たとえば、工程設定マスタメンテナンスにて、アプリケーション動作毎に反映させる工程の状態を変更可能である。また、スケジュールバーは、チェックポイントとなる工程に達した段階で表示色を変えるように設定できる。

図１２の分類別工程詳細一覧画面１２００a、１２００ｂは、横に連結した場合に、分類別工程詳細一覧画面の一部（上部）を構成する。また、図１２には、工程設定登録画面１２１０も示されており、ここで登録された各アプリケーション動作の状態、および工程が、分類別工程詳細一覧画面の表示に反映される。すなわち、伝票の状態（見積、指示、納品）に基づいた工程の状態が関連付けられ表示される。たとえば、工程設定登録画面１２１０での各工程が、分類別工程詳細一覧画面の欄の表示として設定されており、工程設定登録画面１２１０における見積書発行の状態「完」が、そのまま、分類別工程詳細一覧画面の「見積」の欄の「完」の表示となって反映されている。この工程は、たとえば、工程設定マスタメンテナンスにて、アプリケーション動作毎に反映させる工程の状態を変更可能である。

［４．申請書類状況管理機能］
図１３には、申請書類発行画面１３００が示されている。申請書類発行画面１３００では、複数の申請書類の状況を管理する。たとえば、書類の作成のために項目に入力・保存を行うと、その項目を使用する全ての帳票について入力された項目を反映させ、その結果、それぞれの帳票（書類）について不足項目があるかどうかを複数のレベルでチェック（入力状況チェック）する。一例としては、必要情報が全て入力済みの場合は「○」のサインを、一部入力が必要であるが、提出先の検査はパスする見込みである場合は「△」のサインを、必須項目が不足している場合は「×」のサインを、それぞれの書類に関して表示する。

図１３に示す例では、書類入力状況表示部１３２０において、それぞれの書類名とともに、上述した入力状況チェックのサインを表示する（符号１３１０により表示される部分）。また、各書類の入力画面を選択するためのタブ表示部１３３０にも、書類名とともに入力状況チェックのサインが表示される。図１３の例では、保安基準適合証の入力状況チェックの結果が「△」であり、書類入力状況表示部１３２０で、保安基準適合証について「△」のサインが表示され、それとともに、保安基準適合証のタブ表示部１３３０にも、書類名「保安基準適合証」とともに「△」のサインが表示される。

［５．事前点検機能］
図１４には、事前点検項目設定画面１４００、事前点検項目表示画面（整備伝票発行画面）１４２０、および法定点検項目表示画面（整備伝票発行画面）１４４０が示されている。たとえば、顧客側の設定あるいは依頼により、事前点検項目設定画面１４００で事前点検の点検内容を設定すると、その内容が、法定点検項目に自動的にリンク・反映され、事前点検と法定点検で同じ内容を２重で点検したりすることを防止できる。また、整備工場等における入力作業の省力化にも貢献する。

たとえば、顧客が、図１４の事前点検項目設定画面１４００で、「ベルトの緩み、損傷」を点検項目として選択したとすると（符号１４１０で示す部分）、その依頼は、事前点検項目表示画面１４２０に反映され（符号１４３０で示す部分）、さらに、法定点検項目表示画面１４４０に自動的に引き継がれる（符号１４５０で示す部分）。

［６．テキスト追加出力機能］
システムが有するデータ項目をユーザが選択してテキスト出力することができる。たとえば、ユーザは、システムで取引先情報といった、一定の出力対象をテキスト出力する場合に、必要な項目を選択して出力されることができる。出力テキストは、たとえばＣＳＶ形式のテキストである。図１５には、出力項目を設定する出力項目設定画面１５００と、出力テキストの内容を表す表１５５０が示されている。

ユーザは、たとえば、出力項目設定画面１５００の左側に配置された入力項目部１５１０に表示された項目から必要な項目をマウスのクリック等で選択し、右側の出力項目部１５２０に、右矢印ボタン１５３０をマウス等で押下して登録する。逆に、一端登録したものの、不要であると判断した項目については、左矢印ボタン１５４０によって、出力項目部１５２０から削除する。

こうして出力されたテキストデータは、表１５５０のようなデータである。ＣＳＶとは、カンマをデリミッターとして項目間を判断するテキストであるが、どのような形式のファイルを使用してもよい。

［７．受注・仕入データの統合管理機能］
本システムでは、整備、鈑金、車両販売（車販）といった各業務システムによって別々の売上伝票データ・仕入伝票データとなっていたものを、全システムで統一された「受注データ」、「仕入データ」として管理する。このことにより、各業務システムを横断する効果的な伝票検索も可能となる。

図１６には、受注検索画面１６００が示されている。ここでは、検索の対象として、全システム、整備、鈑金、車販のどれかを選択することができ（符号１６１０）、伝票検索指示部１６２０で抽出条件を設定して検索を実行すると、抽出結果表示部１６３０には、条件を満たす伝票が一覧表示される。ここで、検索の対象として「全システム」を指定すると、抽出結果表示部１６３０には、各システム（整備、鈑金、車販）から、伝票が抽出される（符号１６４０）。

［８．出力済み帳票検索・出力機能］
過去に出力したことのある帳票を容易に呼び出し、出力したり、ＰＤＦ形式で保存したりすることができる。図１７には、日次帳票画面１７００が示されている。過去に出力された帳票は、カレンダー部１７１０から日指定、週指定等により呼び出すことができる。帳票表示部１７２０には、こうして呼び出された帳票が一覧表示される。呼び出された帳票に対しては、印刷、ＰＤＦ詳細表示、ＰＤＦ履歴保存等が可能である。

本発明の一実施形態に係るデータ処理システムのシステム構成の概要を示す略線図である。 ＱＲコードが表示された納品書の例を示す図である。 本発明の一実施形態に係るデータ処理システムの仕入伝票入力画面の例を示す略線図である。 本発明の一実施形態に係るデータ処理システムの整備伝票発行画面の例を示す略線図である。 本発明の一実施形態に係るデータ処理システムにおいて、シンボルによってデータが第１サイトから第２サイトに渡される手順を示すフローチャートである。 本発明の一実施形態に係るデータ処理システムにおいて、第１サイトまたは第２サイトで使用されるコンピュータの構成例を示すブロック図である。 第１サイトのコンピュータ等に表示される見積条件設定画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される設定表示画面および諸費用表示画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される設定表示画面および諸費用表示画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される比較見積書画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される工程管理一覧画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される分類別工程詳細一覧画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される申請書類発行画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される事前点検項目設定画面、事前点検項目表示画面（整備伝票発行画面）、および法定点検項目表示画面（整備伝票発行画面）の例を示す略線図である。 第１サイトのコンピュータ等に表示される出力項目設定画面と、出力テキストの内容を表す表を示す略線図である。 第１サイトのコンピュータ等に表示される受注検索画面の例を示す略線図である。 第１サイトのコンピュータ等に表示される日次帳票画面の例を示す略線図である。

符号の説明

１０・・・データ処理システム、１００・・・第１サイト、１１０・・・コンピュータ、１２０・・・プリンタ、１３０・・・伝票、２００・・・第２サイト、２１０・・・コンピュータ、２２０・・・２次元コードリーダ、２３０・・・データベース、３００・・・納品書、６００・・・コンピュータ、６０１・・・ＣＰＵ、６０２・・・メモリ、６０３・・・音声出力装置、６０４・・・ネットワークインタフェース、６０５・・・ディスプレイコントローラ、６０６・・・表示装置、６０７・・・入力機器インタフェース、６０８・・・キーボード、６０９・・・マウス、６１０・・・外部記憶装置、６１１・・・記録媒体駆動装置、６１２・・・２次元コードリーダインタフェース、６１３・・・バス、６２０・・・ネットワーク、６３０・・・記録媒体、６４０・・・２次元コードリーダ

Claims (5)

1. 納品物に関する帳票である第１の帳票の表面に表され、当該第１の帳票の明細データである納品物の明細情報を暗号化した暗号データを元に生成されたシンボルを、シンボル読み取り手段で読み取ることにより得た暗号データを復号化することにより、明細データである納品物の明細情報を取得する明細データ受信手段と、
   前記明細データを仕入情報としてデータベースに記憶すると共に、
   当該明細データに対して、前記復号化によって取得した納品物の明細情報を用いて、当該明細データに関連付けられて記憶されている関連データをデータベースから読み出して追加した第２の帳票を構成するための帳票データを生成する帳票データ生成手段を有することを特徴とするデータ処理システム。
2. 請求項１に記載のデータ処理システムにおいて、
   前記関連データは納品物についての作業内容であり、
   前記帳票データには、当該作業の技術料、工賃など、その作業に関連する項目が、データベースから取得されてセットされることを特徴とするデータ処理システム。
3. 請求項１に記載のデータ処理システムにおいて、
   前記明細データ受信手段で取得した明細データは、データベースに仕入情報として記憶されたあとデータベースから抽出されるか、またはデータベースを経由することなく直接、整備伝票発行画面の入力項目にセットされ、
   前記帳票データ生成手段は、整備伝票に対応する帳票データを生成することを特徴とするデータ処理システム。
4. コンピュータが、
   納品物に関する帳票である第１の帳票の表面に表され、当該第１の帳票の明細データである納品物の明細情報を暗号化した暗号データを元に生成されたシンボルを、シンボル読み取り手段で読み取ることにより得た暗号データを復号化することにより、明細データである納品物の明細情報を取得する明細データ受信ステップと、
   前記明細データを仕入情報としてデータベースに記憶するステップと、
   当該明細データに対して、前記復号化によって取得した納品物の明細情報を用いて、当該明細データに関連付けられて記憶されている関連データをデータベースから読み出して追加した第２の帳票を構成するための帳票データを生成する帳票データ生成ステップを実行することを特徴とするデータ処理方法。
5. 請求項１〜３の何れか一項に記載のデータ処理システムにおいて、更に
   あらかじめ登録された提案用のコースをもとに複数の見積書を作成する見積書作成手段と、
   前記複数の見積書を同時に並べて表示するよう制御する表示制御手段を有することを特徴とするデータ処理システム。