JP5755968B2 - Application method and application device - Google Patents
Application method and application device Download PDFInfo
- Publication number
- JP5755968B2 JP5755968B2 JP2011176656A JP2011176656A JP5755968B2 JP 5755968 B2 JP5755968 B2 JP 5755968B2 JP 2011176656 A JP2011176656 A JP 2011176656A JP 2011176656 A JP2011176656 A JP 2011176656A JP 5755968 B2 JP5755968 B2 JP 5755968B2
- Authority
- JP
- Japan
- Prior art keywords
- customer
- application
- information
- storage unit
- unit
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims description 68
- 238000003860 storage Methods 0.000 claims description 273
- 238000004590 computer program Methods 0.000 claims 1
- 238000007726 management method Methods 0.000 description 194
- 238000013474 audit trail Methods 0.000 description 64
- 230000008569 process Effects 0.000 description 51
- 238000012545 processing Methods 0.000 description 39
- 230000006870 function Effects 0.000 description 18
- 238000004519 manufacturing process Methods 0.000 description 10
- 230000004044 response Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 4
- 238000012508 change request Methods 0.000 description 4
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 230000000881 depressing effect Effects 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 230000001788 irregular Effects 0.000 description 3
- 230000008450 motivation Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
この発明は、申請技術に関し、特に、証券業務に関連した申請を実行する申請方法および申請装置に関する。 The present invention relates to an application technique, and more particularly, to an application method and an application apparatus for executing an application related to securities business.
会社等の組織において業務上の責任の所在を明確にするために、一般的に、書類の申請および承認がなされている。従来、書類の申請および承認手続きは、紙媒体を使用してサインや押印によって行われていた。近年、コンピュータおよびネットワークの普及によって、コンピュータによる申請書類の作成が可能となり、申請者の端末にて作成された申請書類のデータが、ネットワークを通じて承認者の端末に伝送される。さらに、承認者の端末において承認入力がなされることによって、書類の申請および承認が迅速かつ容易に行われる。 In order to clarify the location of business responsibilities in an organization such as a company, documents are generally applied and approved. Conventionally, application and approval procedures for documents have been performed by signing or stamping using paper media. In recent years, with the spread of computers and networks, it has become possible to create application documents by computer, and data of application documents created at the applicant's terminal is transmitted to the approver's terminal through the network. In addition, by inputting approval at the approver's terminal, application and approval of the document can be performed quickly and easily.
しかしながら、申請者が書類のデータを管理者に一度申請をしてしまうと、申請後に緊急に書類を修正する必要が発生しても、承認者の承認または非承認を受けるまでは、再度編集できない。そのため、効率的でなかった。これに対応するため、書類データに対して、作成中、申請中、承認済み、申請却下のステータスを付与して一元管理し、申請者の端末でステータスを「作成中」から「申請中」へと変更することにより申請がなされる。また、「申請中」から「作成中」へと変更することにより申請取下げがなされる(例えば、特許文献1参照)。 However, once the applicant has submitted the document data to the administrator, even if the document needs to be urgently revised after the application, it cannot be edited again until it is approved or rejected by the approver. . Therefore, it was not efficient. In order to respond to this, the document data is created, applied, approved, and application rejection status is centrally managed, and the status is changed from “Creating” to “Applying” on the applicant's terminal. Application is made by changing. Further, the application is withdrawn by changing from “in application” to “in preparation” (see, for example, Patent Document 1).
申請および承認をコンピュータネットワークにて実行するシステムは、証券業務でも必要とされる。例えば、信用取引口座開設申請書、短期売却届出書等を申請して承認を受けるために申請書の作成と承認処理が必要となる。このような証券業務における申請および承認をコンピュータネットワークにて実行するシステムで行おうとする場合、証券業務に特有の課題がある。課題のひとつは、申請を承認するか否かを判断するために申請内容応じた種々の情報が必要であり、例えば顧客の住所、氏名、年齢といった属性情報のみならず、顧客の所有している資産情報や顧客の投資方針等が必要になる場合があることである。ここで、申請・承認の際に必要となる情報は任意のタイミングで更新される必要があり、更新の頻度やタイミングは情報によって異なる。例えば顧客の住所のような属性情報は更新は少なく、更新するタイミングも顧客から連絡があった場合や証券会社の社員が顧客に営業を行うなどして連絡を取った場合のように自由に更新できることが好ましい。一方、顧客の資産情報については例えば、株価は日々変動するため更新頻度は多く、株価情報は通常、定期的に更新されるため、資産情報についてはある程度、定期的に更新できることが好ましい。このように申請および承認に際して必要な様々な情報は多岐にわたり、それぞれ異なる頻度やタイミングで更新できる必要があることが別の課題となっている。以下、この課題を具体的に説明する。 A system that performs application and approval in a computer network is also required for securities business. For example, in order to apply for a credit transaction account opening application form, a short-term sale notification form, etc. and receive approval, an application form must be created and approved. There is a problem peculiar to securities business when trying to perform such application and approval in the securities business by a system that executes on a computer network. One of the issues is that various information according to the contents of the application is necessary to determine whether or not to approve the application. For example, it is owned by the customer as well as attribute information such as the customer's address, name, and age. Asset information and customer investment policies may be required. Here, information necessary for application / approval needs to be updated at an arbitrary timing, and the frequency and timing of the update differ depending on the information. For example, attribute information such as a customer's address is rarely updated, and the update timing can be freely updated when a customer contacts the customer or when a brokerage company employee contacts the customer to do business. Preferably it can be done. On the other hand, for the asset information of the customer, for example, since the stock price fluctuates daily, the update frequency is high, and the stock price information is normally updated regularly. Therefore, it is preferable that the asset information can be updated periodically to some extent. As described above, various information necessary for application and approval is diverse, and it is necessary to be able to update the information at different frequencies and timings. Hereinafter, this problem will be specifically described.
申請および承認の内容を事後的に監査等することを考慮すると、申請および承認の際に参照される情報は少なくとも申請時点において固定された状態で承認申請、承認判断、承認完了という承認申請手続きを経て保存される必要がある。このため、申請および承認をシステムで行うためには、申請および承認に必要な情報を任意のタイミングで更新可能とすることと、申請および承認時に参照された情報が固定されることとを両立させる必要がある。 Considering that the contents of the application and approval are audited afterwards, the information to be referred to at the time of application and approval is at least fixed at the time of application. Needs to be preserved after. For this reason, in order to apply and approve in the system, make it possible to update the information required for application and approval at any time and to fix the information referenced at the time of application and approval. There is a need.
本発明はこうした状況に鑑みてなされたものであり、その主たる目的は、証券業務の状況を考慮して書類の申請処理を実行する技術を提供することである。 The present invention has been made in view of such circumstances, and its main object is to provide a technique for executing document application processing in consideration of the status of securities business.
上記課題を解決するために、本発明のある態様の申請装置は、ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつける第1受付部と、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部と、第1受付部において受けつけた開始指示に対する顧客の情報を参照して、第1記憶部に記憶した顧客の資産情報と顧客の属性情報から、当該顧客についての資産情報と属性情報とを取得する取得部と、取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、生成部において生成した承認申請画面を端末装置に表示させるために、ネットワークを介して端末装置へ承認申請画面を出力する出力部と、出力部から出力した承認申請画面が端末装置に表示された状態において、端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつける第2受付部と、第1記憶部とは別に設けられた第2記憶部と、第2受付部が申請指示を受けつけると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、第2受付部において受けつけた顧客の資産情報と顧客の属性情報を第2記憶部に記憶させる登録部と、を備える。 In order to solve the above-described problem, an application device according to an aspect of the present invention includes a first reception unit that receives an instruction to start an approval application related to securities business for a predetermined customer from a terminal device connected via a network; For each of a plurality of customers, a first storage unit that stores customer asset information and customer attribute information, and a first storage unit with reference to customer information for a start instruction received in the first reception unit Based on the customer asset information and customer attribute information acquired from the customer asset information and customer attribute information, and the acquisition unit that acquires the asset information and attribute information about the customer. , To generate an approval application screen for securities business, and to display the approval application screen generated in the generation unit on the terminal device via the network, In the state where the output unit to output and the approval application screen output from the output unit are displayed on the terminal device, the terminal device receives an application instruction for applying for approval of securities business via the network, and the approval application screen When the second reception unit that receives customer asset information and customer attribute information included in the second storage unit, the second storage unit provided separately from the first storage unit, and the second reception unit receive the application instruction, There is provided a registration unit for storing, in the second storage unit, customer asset information and customer attribute information received in the second reception unit, instead of the customer asset information and customer attribute information stored in the storage unit.
この態様によると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、承認申請画面に含まれた顧客の資産情報と顧客の属性情報を第2記憶部に記憶させるので、上記課題を解決できる。 According to this aspect, since the customer asset information and the customer attribute information included in the approval application screen are stored in the second storage unit, not the customer asset information and the customer attribute information stored in the first storage unit. The above problems can be solved.
本発明の別の態様は、申請方法である。この方法は、ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、生成した承認申請画面を端末装置に表示させるために、ネットワークを介して端末装置へ承認申請画面を出力するステップと、出力した承認申請画面が端末装置に表示された状態において、端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、申請指示を受けつけると、第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、第1記憶部とは別に設けられた第2記憶部に記憶させるステップと、を備える。 Another aspect of the present invention is an application method. This method includes a step of receiving an instruction to start an application for approval concerning securities business for a predetermined customer from a terminal device connected via a network, and for each of a plurality of customers, customer asset information and customer attributes A step of acquiring asset information and attribute information about the customer with reference to the customer information corresponding to the received start instruction from the first storage unit storing information, and the acquired customer asset information and customer attributes Generating an approval application screen related to securities business based on the information, outputting an approval application screen to the terminal device via the network in order to display the generated approval application screen on the terminal device, and outputting An application to apply for approval of securities business from the terminal device via the network while the approved application screen is displayed on the terminal device And receiving the customer asset information and customer attribute information included in the approval application screen, and receiving the application instruction, not the customer asset information and the customer attribute information stored in the first storage unit Storing the customer asset information and customer attribute information received together with the application instruction in a second storage unit provided separately from the first storage unit.
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。 It should be noted that any combination of the above-described constituent elements and a representation of the present invention converted between an apparatus, a method, a system, a program, a recording medium storing the program, etc. are also effective as an aspect of the present invention.
本発明によれば、証券業務の状況を考慮して書類の申請処理を実行できる。 According to the present invention, application processing for documents can be executed in consideration of the status of securities business.
本発明を具体的に説明する前に、まず概要を述べる。本発明の実施例に係る証券業務システムは、証券会社の社員である申請者の操作によって、証券業務における書類を作成し、作成した書類を申請する。また、証券業務システムは、証券会社の別の社員である承認者の操作によって、申請された書類を承認したり、非承認したりするとともに、承認前の書類や承認後の書類を管理する。ここで、書類とは、例えば、信用取引口座開設申請書、短期売却届出書であり、これらには、不正な取引を防止するためのコンプライアンスを遵守するといった目的のために、申請および承認が必要とされる。申請および承認のための証券業務システムでは、証券業務特有の事情を考慮して構成されるべきである。 Before describing the present invention specifically, an outline will be given first. The securities business system according to the embodiment of the present invention creates documents in securities business and applies for the created documents by operation of an applicant who is an employee of a securities company. In addition, the securities business system approves or disapproves the requested documents by the operation of an approver who is another employee of the securities company, and manages documents before and after approval. Here, the documents are, for example, a margin transaction account opening application form and a short-term sale registration form, which require application and approval for the purpose of complying with compliance to prevent fraudulent transactions. It is said. The securities business system for application and approval should be structured taking into account the circumstances specific to securities business.
承認する際に、顧客の資産が考慮されることもある。このような資産には、株、社債、投資信託が含まれ、それらも証券業務システムにて管理されている。それらの価値は日々変動しているので、顧客の資産は日々変動している。また、承認に際しては顧客の氏名や住所といった属性情報も必要であるが、これらの情報は任意のタイミングで変動する。つまり、これらの情報は任意のタイミング、頻度で変動するため、これらをシステムで管理するに際しては任意のタイミングで更新可能としておくことが望ましい。一方、承認対象となる書類において資産や顧客属性の情報は固定されていないと、承認者は承認できず、承認後の監査も困難となる。なお、承認に際して必要な顧客の情報は顧客が個人であるか法人であるかによっても異なる。そのため、書類を作成する際に、顧客の種類に応じて承認に必要な情報が申請および承認時に容易に参照できるようになっていることが望まれる。 In approving, customer assets may be taken into account. Such assets include stocks, bonds, and investment trusts, which are also managed by the securities business system. Their value fluctuates daily, so customer assets fluctuate daily. In addition, attribute information such as a customer's name and address is required for approval, but such information fluctuates at an arbitrary timing. That is, since these pieces of information fluctuate at an arbitrary timing and frequency, it is desirable that the information can be updated at an arbitrary timing when managed by the system. On the other hand, if asset and customer attribute information is not fixed in the document to be approved, the approver cannot approve, and auditing after approval becomes difficult. Note that the customer information required for approval varies depending on whether the customer is an individual or a corporation. Therefore, it is desirable that information necessary for approval can be easily referred to at the time of application and approval when creating a document.
これらに対応するために、本実施例に係る証券業務システムでは、申請者が書類を作成する際に、申請および承認に際して求められる情報を任意のタイミングで更新可能な状態で記憶されたデータベースから、必要なデータを抽出する。なお、抽出されるデータは、顧客の種類によって異なる。申請者が作成した書類を申請する際に、証券業務システムは、書類の作成時に抽出したデータを固定して別のデータベースに記憶する。当該別のデータベースでは、固定したデータが記憶されている。承認者が書類を承認する際には、固定したデータが記憶されたデータベースが参照される。このように、申請および承認に必要なデータは、更新可能に記憶された記憶部に保持され任意のタイミングで更新され、申請時にはこの記憶部から取得され、申請完了に伴って固定されることで固定したデータが別のデータベースに格納される。 In order to cope with these, in the securities business system according to the present embodiment, when an applicant creates a document, information required for application and approval can be updated from a database stored in a state that can be updated at an arbitrary timing. Extract the necessary data. Note that the extracted data varies depending on the type of customer. When applying for a document created by the applicant, the securities business system fixes the data extracted at the time of document creation and stores it in a separate database. In the other database, fixed data is stored. When an approver approves a document, a database storing fixed data is referred to. In this way, the data required for application and approval is stored in an updatable storage unit, updated at any time, acquired from this storage unit at the time of application, and fixed upon completion of the application. Fixed data is stored in a separate database.
以下では、説明を明瞭にするために、証券業務システムを複数に分けて説明する。まず、1.全体構成を説明した後に、2.顧客情報生成処理、3.書類登録処理、4.申請登録処理、5.承認登録処理、6.事務処理登録処理、7.申請保管処理、8.監査証跡管理処理の各処理を説明する。その後、9.動作を説明する。さらに、10.全体構成の追記を説明する。
In the following, in order to clarify the explanation, the securities business system is divided into a plurality of explanations. First, 1. After explaining the overall configuration, 2. 2. Customer information generation process Document registration process, 4. 4.
1.全体構成
図1は、本発明の実施例に係る証券業務システム200の構成を示す。証券業務システム200は、申請サーバ10、端末装置12と総称される第1端末装置12a、第2端末装置12b、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22、ネットワーク24、顧客情報生成部70を含む。資産情報記憶部14は、預りDB30、資産DB32を含み、顧客属性記憶部16は、共通属性DB34、個人属性DB36、法人属性DB38を含み、顧客情報記憶部18は、既存客情報管理DB40、顧客カードDB42を含む。申請情報記憶部20は、第1DB44、第2DB46、申請書類管理DB56を含み、第1DB44は、申請顧客情報DB48を含み、第2DB46は、申請管理DB50、申請状況管理DB52、監査証跡管理DB54を含む。承認情報記憶部22は、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64を含む。
1. Overall Configuration FIG. 1 shows a configuration of a
端末装置12は、証券会社の社員が証券業務のための書類を作成する際に使用する装置であり、例えば、PCに相当する。端末装置12は、通信機能を備え、ネットワーク24に接続される。図1では、2台の端末装置12が示されているが、これに限定されない。また、第1端末装置12aは、書類を申請すべき社員(以下、「申請者」という)によって使用され、第2端末装置12bは、申請された書類を承認すべき社員(以下、「承認者」という)によって使用されるものとする。
The terminal device 12 is a device used when an employee of a securities company creates a document for securities business, and corresponds to a PC, for example. The terminal device 12 has a communication function and is connected to the
申請サーバ10は、ネットワーク24を介して、端末装置12に接続されたサーバである。申請サーバ10は、端末装置12からの指示に応じた処理を実行し、その結果を端末装置12に返信する。
The
資産情報記憶部14は、預りDB30、資産DB32を記憶するための記憶媒体である。資産情報記憶部14は、ネットワーク24に接続され、申請サーバ10からアクセスされることで申請サーバ10によって必要な情報が取り出されてもよい。図1の態様では、後述する顧客情報生成部70が資産情報記憶部14と顧客属性記憶部16とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および承認に必要な情報を生成した情報を記憶する顧客情報記憶部18を介して資産情報記憶部14の情報が申請サーバ10に取り出されるように構成されている。預りDB30および資産DB32に格納されるデータの内容については後述するが、これらのデータの内容は日々変動する。変動の周期は、一般的に1日よりも短く変動タイミングは一般的に予め定められている。このように、資産情報記憶部14は、所定のタイミグで更新されるデータを更新可能な状態で記憶するための記憶媒体(第1記憶部)である。
The asset
顧客属性記憶部16は、共通属性DB34、個人属性DB36、法人属性DB38を記憶するための記憶媒体である。本実施形態では上述した通り顧客属性記憶部16の情報は顧客情報生成部70により生成され顧客情報記憶部18に記憶された情報として申請サーバ10によって取り出されるように構成されているが、顧客属性記憶部16は、ネットワーク24に接続され、申請サーバ10からアクセスされることで申請サーバ10が直接、顧客属性記憶部16から必要な情報を取り出すようにしてもよい。共通属性DB34、個人属性DB36、法人属性DB38に格納されるデータの内容については後述するが、これらのデータの内容は任意のタイミングで変動する。このように、顧客属性記憶部16は、任意のタイミングで更新されるデータを更新可能な状態で記憶するための記憶媒体(第1記憶部)である。
The customer
顧客情報記憶部18は、資産情報記憶部14と顧客属性記憶部16とから顧客の資産情報と顧客属性とをそれぞれ取り込んで顧客ごとに申請および必要な情報として取り出しやすくした状態として既存客情報管理DB40、顧客カードDB42に情報を記憶するための記憶媒体である。顧客情報記憶部18は、ネットワーク24に接続され、申請サーバ10からアクセスされる。既存客情報管理DB40および顧客カードDB42に格納されるデータは、預りDB30、資産DB32、共通属性DB34、個人属性DB36、法人属性DB38に格納されたデータをもとに生成される。そのため、顧客情報記憶部18のデータは、適宜、更新され、顧客情報記憶部18も適宜、更新されるデータを更新可能な状態で記憶するための記憶媒体である。
The customer
申請情報記憶部20は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56を記憶するための記憶媒体である。申請情報記憶部20は、申請サーバ10からアクセスされる。申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56は、書類を申請してから承認するまでの期間においてデータを格納する。申請顧客情報DB48に格納されたデータは、書類を申請してから承認するまでの期間において固定されている。つまり、削除される場合を除いて編集や修正はなされない。
The application
そのため、申請完了時点では顧客情報記憶部18と申請顧客情報DB48に同様の内容のデータが記憶され、その後、顧客情報記憶部18のデータ内容が変更されても申請情報記憶部20には申請時点のデータが内容変更できない(すなわち固定された)状態で記憶される。このように申請完了時点に取得された顧客情報を申請顧客情報DB48に固定して記憶させることで編集禁止のデータを誤って編集してしまうが防止され、その後の承認手続きにおいて申請時点の顧客情報を参照することができる。一方、申請情報記憶部20の申請管理DB50、申請状況管理DB52、監査証跡管理DB54、申請書類管理DB56に格納されたデータは、編集可能である。このように、申請情報記憶部20は、固定されたデータが記憶される申請顧客情報DB48(第1DB44)と申請完了から承認完了までの間、更新可能なデータが記憶される申請管理DB50、申請状況管理DB52、監査証跡管理DB54(第2DB46)とを備える記憶媒体である。
Therefore, when the application is completed, data with the same content is stored in the customer
承認情報記憶部22は、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64を記憶するための記憶媒体である。承認情報記憶部22は、ネットワーク24に接続され、申請サーバ10からアクセスされる。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64は、承認された申請についてのデータを格納する。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に格納されたデータは、編集されずに固定された状態で記憶されている。このように承認情報記憶部22は、固定されたデータを格納するための記憶媒体であるともいえる。
The approval
承認情報記憶部22のうち、申請顧客履歴情報DB58には申請完了時点で取得され申請顧客情報DB48に固定して記憶された顧客情報が固定して記憶されており、承認手続き中と同様に承認完了後も申請完了時点に取得された顧客情報が保持され参照することができる。申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に記憶されたデータは、それぞれ申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータの内容が承認完了時に固定されたものである。そのため、承認手続き中は申請情報記憶部20の申請管理DB50、申請状況管理DB52、監査証跡管理DB54により申請内容や承認申請の状況等を確認しつつ、承認手続き後は申請の内容、履歴、承認履歴等が誤って編集してしまうことを防止して申請内容等を確認することができる。
In the approval
図2は、申請サーバ10の構成を示す。申請サーバ10は、書類登録部72、申請登録・照会部74、承認登録部76、事務処理登録部78、申請保管部80、監査証跡管理部82、IF部84を含む。IF部84は、図示しないネットワーク24に接続され、通信機能を実行する。IF部84は、ネットワーク24を介して、図示しない端末装置12、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22と通信し、顧客情報記憶部18と顧客情報生成部70を介して資産情報記憶部14および顧客属性記憶部16にアクセスする。
FIG. 2 shows the configuration of the
図1の顧客情報生成部70は、申請者が端末装置12を操作して書類を作成する前に、書類の作成に必要な顧客データを収集し、顧客ごとの顧客属性情報と顧客資産情報とを作成する。詳細は後述するが、顧客情報生成部70は、資産情報記憶部14および顧客属性記憶部16に記憶されたデータをもとに、顧客の資産情報と顧客の属性情報とを取得し、加工して顧客情報記憶部18に記憶する。前述のごとく、資産情報記憶部14および顧客属性記憶部16に記憶されたデータは変動するので、顧客情報生成部70は、これらのデータの変動に合わせて、データを更新する。なお、顧客情報生成部70は、申請サーバ10の内部に設けられ、ネットワーク24を介して資産情報記憶部14と顧客属性記憶部16とが申請サーバ10に接続され、申請サーバ10が資産情報記憶部14と顧客属性記憶部16から必要な情報を取得してもよい。
The customer
書類登録部72は、書類フォーマットの作成者が端末装置12を操作して作成した書類のフォーマットを更新書類管理DBに登録する。具体的には書類登録部72は、申請情報記憶部20の申請書類管理DB56に申請書類のフォーマット情報を登録する。申請の処理が開始されると、申請登録・照会部74は、書類登録部72で作成され申請書類管理DB56に登録されている申請書類のフォーマットの中から申請の種類に応じた書類のフォーマットを呼び出すとともに、顧客情報記憶部18を介して資産情報記憶部14と顧客属性記憶部16に記憶されたデータのうち、申請の種類に応じて必要な顧客情報を抽出し、申請画面を生成する。申請者が申請画面から申請を行う旨の指示(申請指示)を入力すると、申請登録・照会部74はこの指示を受け付けて、顧客情報記憶部18を介して資産情報記憶部14と顧客属性記憶部16から取得し申請画面に表示した顧客情報を申請情報記憶部20の申請顧客情報DBに固定した状態で記憶させる。また、申請登録・照会部74は、申請に関する情報を第2DB46に記憶させる。
The
承認登録部76は、申請登録・照会部74が申請者からの承認申請指示を受け付けて登録した後、承認者による端末装置12の操作に応じて、承認者が行う承認処理の結果を受け付けてその内容を登録する。承認結果が受け付けられて登録されると、承認登録部76は、申請情報記憶部20の申請顧客情報DB48に固定して記憶していたデータを承認情報記憶部22に更新不可の状態で記憶させる。事務処理登録部78は、申請登録・照会部74が申請指示を受け付けて登録した後、申請内容にしたがった事務処理を登録する。事務処理とは、例えば、申請の内容が信用口座の開設であった場合、実際に信用口座を開設するための処理である。このような事務処理は、申請者や承認者とは異なった証券会社の社員によってなされる。事務処理に際しては申請情報記憶部20の申請顧客情報DB48に記憶していたデータが参照される。
The
申請保管部80は、承認登録部76が承認処理の結果を登録した後、端末装置12からの指示にしたがって、承認した内容を表示させる。その際、申請保管部80は、承認情報記憶部22に記憶されたデータを抽出する。監査証跡管理部82は、承認登録部76が承認処理の結果を登録した後、端末装置12からの指示にしたがって、申請から承認までの履歴を表示させる。その際、監査証跡管理部82は、監査証跡管理DB54または監査証跡履歴管理DB64に記憶されたデータを抽出する。
The
以下の各処理に対する説明では、図1に示した申請処理部100の構成、図2に示した申請サーバ10の構成のうち、必要な部分だけを図示する。この構成は、ハードウエア的には、任意のコンピュータのCPU、メモリ、その他のLSIで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。
In the following description of each process, only necessary portions are illustrated in the configuration of the
2.顧客情報生成処理
図3は、顧客情報生成部70の構成を示す。顧客情報生成部70は、第1取込部90、第2取込部92を含む。また、顧客情報生成部70は、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18に接続される。なお、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。前述のごとく、顧客情報生成部70は、申請サーバ10の内部に設けられてもよいが、その際、申請サーバ10は資産情報記憶部14、顧客属性記憶部16とネットワークを介して接続され、これら記憶部の情報を取り出して顧客情報生成部70で必要な情報を生成する。
2. Customer Information Generation Processing FIG. 3 shows the configuration of the customer
預りDB30は、顧客の保有している預り情報を記憶する。預りDB30では、預りごとの記憶がなされている。図4は、預りDB30のデータ構造を示す。図示のごとく、ユーザ欄300、部店欄302、口座番号欄304、商品欄306、銘柄欄308、数量欄310、取得単価欄312、時価欄314が含まれる。預りDB30は、各ユーザから預っているっている株式、債券、投信等の銘柄、数量、価格等を記憶する。預りDB30に格納されたデータは、商品を売買したタイミング、時価が変動したタイミングにおいて更新される。図3に戻る。
The
資産DB32は、顧客の保有している預り資産を記憶する。資産DB32では、口座ごとの記憶がなされている。図5は、資産DB32のデータ構造を示す。図示のごとく、ユーザ欄320、部店欄322、口座番号欄324、総資産額欄326が含まれる。総資産額欄326に含まれた総資産額は、預りDB30に格納されたデータと図示しない株価情報DBとをもとに導出される。そのため、株価情報DBのデータや預りDB30に格納されたデータが更新されると、資産DB32に格納されたデータ、つまり総資産額も更新される。一般に株価情報DBのデータは所定のタイミング(例えば一日一回)で更新されるため、これに伴って資産DB32のデータも更新される。また、預りDB30は株式等の売買が成立した場合などの任意のタイミングで更新され、資産DB32は株価情報DBに対する所定の更新タイミングのみならず、任意で発生する預りDBの更新に合わせてもデータが更新可能なように構成されている。図3に戻る。
The
共通属性DB34は、個人客、法人客に共通する属性情報を記憶する。共通属性DB34では、口座ごとの記憶がなされている。図6は、共通属性DB34のデータ構造を示す。図示のごとく、ユーザ欄330、部店欄332、口座番号欄334、顧客名欄336、住所欄338、電話番号欄340、職業欄342、リスク説明不要(株式)欄344、リスク説明不要(債券)欄346、リスク説明不要(転換社債)欄348、リスク説明不要(外証)欄350、コンプラランク欄352、口座開設日欄354が含まれる。例えば、住所欄338の住所が変更されたタイミングのような任意の不定期なタイミングにおいて、共通属性DB34に格納されたデータは更新される。図3に戻る。
The
個人属性DB36は、個人客に関する属性情報を記憶する。個人属性DB36でも、口座ごとの記憶がなされている。図7(a)−(c)は、個人属性DB36のデータ構造を示す。個人属性DB36に格納されたデータの項目数が多いので、ここでは図7(a)−(c)に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄360、部店欄362、口座番号欄364、顧客名欄366、生年月日欄368、性別欄370、勤務先欄372、役職欄374、取引動機欄376、資金性格欄378、投資方針欄380、資産運用期間欄382、投資経験有無(株式現物)欄384、投資経験有無(債券)欄386、投資経験有無(転換社債)欄388、投資経験有無(株式信用)欄390、投資経験有無(ワラント)欄392、投資経験有無(先物・OP)欄394、投資経験有無(貯蓄型投信)欄396、投資経験有無(投資信託)欄398、投資経験有無(外国証券)欄400、投資経験有無(その他)欄402、主な収入源欄404、推定年収欄406、金融資産欄408が含まれる。個人属性DB36に格納されたデータも、共通属性DB34に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図3に戻る。
The
法人属性DB38は、法人客に関する属性情報を記憶する。法人属性DB38でも、口座ごとの記憶がなされている。図8(a)−(b)は、法人属性DB38のデータ構造を示す。法人属性DB38に格納されたデータの項目数が多いので、ここでは図8(a)−(b)に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄410、部店欄412、口座番号欄414、顧客名欄416、取引動機欄418、資金性格欄420、投資方針欄422、資産運用期間欄424、投資経験有無(株式現物)欄426、投資経験有無(債券)欄428、投資経験有無(転換社債)欄430、投資経験有無(株式信用)欄432、投資経験有無(ワラント)欄434、投資経験有無(先物・OP)欄436、投資経験有無(貯蓄型投信)欄438、投資経験有無(投資信託)欄440、投資経験有無(外国証券)欄442、投資経験有無(その他)欄444、資本金欄446、代表者名欄448が含まれる。法人属性DB38に格納されたデータも、共通属性DB34に格納されたデータと同様に、任意の不定期なタイミングにおいて更新される。図3に戻る。
The
個人の顧客に対するデータと法人の顧客に対するデータとは異なるので、個人属性DB36と法人属性DB38とが別に設けられる。なお、個人属性DB36に格納されたデータと法人属性DB38に格納されたデータは、承認申請の際および承認処理(承認/非承認判断)の際に使用される。承認申請および承認処理の判断に際し、個人の顧客と法人の顧客とでは必要な情報が異なるので、個人属性DB36と法人属性DB38とが別に設けられている。
Since the data for individual customers is different from the data for corporate customers, a
第1取込部90は、各顧客に対して、預りDB30および資産DB32に格納されたデータを読み込む。第1取込部90は、読み込んだデータを既存客情報管理DB40に出力する。第2取込部92は、各顧客に対して、共通属性DB34、個人属性DB36、法人属性DB38に格納されたデータを読み込む。なお、顧客の属性の種類に応じて、個人属性DB36あるいは法人属性DB38が選択される。第1取込部90は、読み込んだデータを既存客情報管理DB40および顧客カードDB42に出力する。
The
既存客情報管理DB40は、各顧客に対して、第1取込部90および第2取込部92からのデータを取り込み、顧客属性情報の一部と顧客資産情報とを記憶する。具体的には、顧客の属性情報の種類が個人である場合、口座開設日、住所、職業、生年月日、性別、電話番号、勤務先、役職、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。一方、顧客の属性情報の種類が法人である場合、口座開設日、住所、役職・代表者名、電話番号、業種、資本金、預り資産、コンプラランク、リスク説明不要な商品の情報が含まれる。つまり、顧客情報記憶部18のうちの既存客情報管理DB40では、顧客の属性情報の種類として、複数の種類、具体的には個人と法人が規定されている。
The existing customer
顧客カードDB42は、各顧客に対して、第2取込部92からのデータを記憶し顧客属性情報を記憶する。具体的には、投資経験に関する情報、取引種類、資金性格、投資方針、資産運用期間、主な収入源、金融資産、年収が含まれる。顧客カードDB42に格納されるデータの項目は、顧客の属性情報の種類にかかわらず同一である。既存客情報管理DB40および顧客カードDB42に格納されたデータは、資産情報記憶部14および顧客属性記憶部16に格納されたデータの更新に応じて、更新される。そのため、顧客情報記憶部18に格納されたデータは、所定のまたは任意のタイミングにて更新できるよう構成されている。
The
3.書類登録処理
図9は、書類登録部72の構成を示す。書類登録部72は、書類生成部94を含む。また、書類登録部72は、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
3. Document Registration Processing FIG. 9 shows the configuration of the
受付部96は、承認申請の申請者からの入力を受けつける。入力は、キーボードやマウス等の入力機器を介してなされる。ここでの入力は、申請書類のフォーマットを作成するためのデータの入力に相当する。受付部96は、入力されたデータを書類生成部94へ出力する。書類生成部94は、受付部96からのデータを受けつける。書類生成部94は、受けつけたデータをもとに、承認申請に用いられる書類(以下、「申請書類」という)のフォーマットを生成する。書類生成部94は、作成中の申請書類のフォーマットを表示部98に表示させる。フォーマットが定められた申請書類は、申請書類管理DBに記憶される。
The
表示部98は、書類生成部94からの指示に応じて申請書類のフォーマットを表示する。図10は、書類生成部94によって生成される申請書類のフォーマットの登録画面を示す。画面中、書類コード欄600には、申請書類を識別するために付与される書類コードが表示される。書類分類欄602には、申請書類の分類が表示される。書類名欄604には、申請書類の名称が表示される。申請書類を新規登録する場合、書類コード欄600、書類分類欄602、書類名欄604は、新たに入力される。これらの下段には、申請書類に含まれる項目が示される。書類フォーマットの登録者は、項目内容を編集できる。そのため、右側の内容の部分に表示されるチェックボックス等は任意に設定可能である。
The
図11は、書類生成部94によって生成され承認者を設定するための申請書類承認者定義画面を示す。申請書類は、一般的に、書類の種類に応じて承認者が異なる。図9に戻る。申請書類管理DB56は、書類生成部94によって作成された申請書類のフォーマット情報を記憶する。申請書類管理DB56に記憶される申請書類のフォーマット情報には、各書類について設定され登録された承認者情報も含まれる。
FIG. 11 shows an application document approver definition screen generated by the
4.申請登録処理
図12は、申請登録・照会部74の構成を示す。申請登録・照会部74は、申請処理部100、申請状況照会部102を含み、申請処理部100は、申請画面生成部104、取得部106、移動部108を含む。また、申請登録・照会部74は、顧客情報記憶部18、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、顧客情報記憶部18、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
4). Application Registration Processing FIG. 12 shows the configuration of the application registration /
申請画面生成部104は、受付部96から受けつけた指示であって、かつ申請者からの指示を受けつける。申請画面生成部104は、受付部96で受けつけた指示をもとに、申請書類を作成するための画面を作成し、申請処理を実行する。図13は、申請画面生成部104によって生成され申請書類管理DBから申請の種類に応じて申請書類のフォーマットを呼び出した状態の書類選択画面を示す。書類コード欄610、書類分類欄612、書類名欄614は、図10の書類コード欄600、書類分類欄602、書類名欄604に対応しており、受付部96が申請者からのこれらの欄への入力または顧客に紐づけられた口座番号の入力を受け付けることによってこれらの欄への入力で特定される申請書類または口座番号により特定される顧客について必要な申請書類のフォーマットが呼び出される。図13では口座番号が指定されることでこの口座番号に紐づけられた顧客に関する承認申請に必要な複数の申請書類フォーマットの候補が書類コード欄610、書類分類欄612、書類名欄614の下に複数、表示された状態を示している。このように申請書類のフォーマットが示された状態において申請者は申請に必要な書類を特定して、申請入力ボタン616を押し下げることで申請書類の作成を開始する指示を入力する。図12に戻る。申請画面生成部104は、申請書類の作成開始指示を受けつけると、申請書類管理DB56から特定された申請書類のフォーマットを取得する。また、申請画面生成部104は、申請書類の作成開始指示を受けつけると、その旨を取得部106に通知する。その際、口座番号欄に入力され口座番号と一意に紐づけられた顧客を特定する情報(例えば顧客コード)も取得部106に通知される。
The application
取得部106は、申請画面生成部104からの申請書類作成開始指示を受けつけると、顧客情報記憶部18に含まれた既存客情報管理DB40と顧客カードDB42とから、該当する顧客の属性情報および資産情報等を取得する。これらを取得するために、取得部106は、顧客コード等による検索を実行する。ここで、顧客情報記憶部18の顧客情報は、顧客コードに紐づけられ記憶されている。よって、ひとつの顧客コードから、個人の属性情報あるいは法人の属性情報が取得されるので、申請画面生成部104から受けつけた顧客コードは、顧客の種類を特定するための情報ともいえる。
Upon receiving the application document creation start instruction from the application
前述のごとく、取得部106によってアクセスされる顧客情報記憶部18では、既存客情報管理DB40の内容と顧客カードDB42の内容とが、所定のまたは任意のタイミングにて更新されている。取得部106は、顧客情報記憶部18にアクセスした時点、すなわち、受付部96が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部18に保持されている顧客の属性情報と資産情報とを取得し、取得した顧客の資産情報と顧客の属性情報等を申請画面生成部104へ出力する。
As described above, in the customer
申請画面生成部104は、既に取得した申請書類のフォーマット情報に加えて、取得部106において取得した顧客の資産情報と顧客の属性情報等をもとに、顧客に対する証券業務に関する承認申請を行うための申請内容編集画面を生成する。申請画面生成部104は、作成した画面を表示部98に表示させる。表示部98は、申請画面生成部104からの指示に応じて画面を表示する。図14は、申請画面生成部104によって生成された申請内容編集画面を示す。特に、図14は、顧客が個人である場合の申請内容編集画面である。図中の第1顧客属性表示欄620において既存客情報管理DBから取得した顧客の属性情報が表示され、第2顧客属性表示欄622において顧客カードDB42から取得した顧客の属性情報が表示され、図中の預り資産欄624において、顧客カードDB42から取得した顧客の資産情報が表示される。これらの顧客情報表示欄620、622、624の下段には、申請内容が表示される。
The application
図15は、申請内容を照会するために申請画面生成部104によって生成される申請内容照会画面を示す。申請内容照会画面は、図14の申請書類作成画面において仮保存ボタンが押し下げられたことを受付部96が受け付けることで生成され、図14の顧客情報表示欄の下段に表示された申請内容を表示する画面である。図16は、申請画面生成部104によって生成される別の申請内容編集画面を示す。特に、図16は、顧客が法人である場合の申請内容編集画面である。図中の第1顧客属性表示欄630において既存客情報管理DB40から取得した顧客の属性情報が表示され、第2顧客属性表示欄632において顧客カードDB42から取得した顧客の属性情報が表示され、図中の預り資産欄634において、顧客カードDB42から取得した顧客の資産情報が表示される。第1顧客属性表示欄630に含まれる項目は、図14の第1顧客属性表示欄620に含まれる項目と異なっている。これは、顧客の種類が異なるためである。一方、第2顧客属性表示欄632、預り資産欄634に含まれる項目は、図14の第2顧客属性表示欄622、預り資産欄624に含まれる項目と同一である。
FIG. 15 shows an application content inquiry screen generated by the application
図17は、申請画面生成部104によって生成される別の申請内容照会画面を示す。これは、必要な項目の入力が完了し、申請可能な状態である場合に相当する。そのため、申請ボタン640が表示されている。図12に戻る。表示部98に申請内容照会画面を表示させた状態において、申請者が申請ボタン640を押し下げることで承認申請の開始を行う指示を入力することにより、申請画面生成部104は、受付部96から証券業務の申請開始指示を受けつける。申請画面生成部104は、証券業務の申請開始指示を受けつけると、申請に係るデータを申請情報記憶部20に記憶させるよう、移動部108に指示する。
FIG. 17 shows another application content inquiry screen generated by the application
移動部108は、申請画面生成部104からの指示を受けつけると、申請画面を生成するために使用したデータを申請情報記憶部20に記憶させる。つまり、申請書類の作成が完了し申請開始が指示された申請に係るデータは、申請情報記憶部20に記憶される。特に、移動部108は、既存客情報管理DB40と顧客カードDB42から取得された顧客の資産情報と顧客の属性情報等とを申請顧客情報DB48へ削除以外の編集が不可能な状態(すなわち固定した状態)で記憶させる。また、移動部108は、申請開始指示を行ってから承認が完了するまでの間、追加や修正等の編集が行われるデータを申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶させる。申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶させるデータの内容は後述する。
When the moving
前述のごとく、申請顧客情報DB48に記憶されたデータは、申請から承認までの間において、削除される場合を除いて、追加や変更等の編集ができないように固定されている。そのため、既存客情報管理DB40と顧客カードDB42に記憶され種々のタイミングや頻度で更新され変動しうるデータは、申請開始の指示が完了されたタイミングにおいて、申請顧客情報DB48に記憶されることによって固定される。一方、申請開始指示により申請顧客情報DB48に固定されたデータの元データであって既存客情報管理DB40と顧客カードDB42に記憶されていたデータは、申請顧客情報DB48への記憶が行われた後も変動され続けうる。一方、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータは、申請から承認までの間において、編集可能である。
As described above, the data stored in the application
申請顧客情報DB48は、申請書類の作成が完了し申請開始の指示が完了したタイミングで顧客情報を記憶する。申請顧客情報DB48では、ひとつの申請につき、1行の情報が登録される。図18(a)−(f)は、申請顧客情報DB48のデータ構造を示す。申請顧客情報DB48に格納されたデータの項目数が多いので、ここでは図18(a)−(f)に分割されているが、実際はひとつのまとまりとして構成されている。図示のごとく、ユーザ欄450、申請番号欄452、部店欄454、口座番号欄456、顧客名欄458、郵便番号欄460、住所欄462、職業欄464、生年月日欄466、電話番号欄468、口座開設日欄470、性別欄472、資産欄474、コンプラランク欄476、役職欄478、勤務先欄480、代表者名欄482、資本金欄484、リスク説明不要(株式)欄486、リスク説明不要(債券)欄488、リスク説明不要(転換社債)欄490、リスク説明不要(外証)欄492、取引動機欄494、投資経験有無(株式現物)欄496、投資経験有無(債券)欄498、投資経験有無(転換社債)欄500、投資経験有無(株式信用)欄502、投資経験有無(ワラント)欄504、投資経験有無(先物・OP)欄506、投資経験有無(貯蓄型投信)欄508、投資経験有無(投資信託)欄510、投資経験有無(外国証券)欄512、投資経験有無(その他)欄514、資金性格欄516、投資方針欄518、主な収入源欄520、推定年収欄522、金融資産欄524、資産運用期間欄526が含まれる。申請は、申請番号欄452に示された申請番号によって各申請が一意に識別される。他の項目は、既存客情報管理DB40および顧客カードDB42に格納されたデータの項目に類似する。
The application
申請管理DB50は、申請開始の指示が完了した申請書類に係るデータを記憶する。申請管理DB50は、ふたつの部分によって構成される。ひとつが申請管理であり、もうひとつが申請内容管理である。申請管理は、申請書類の基本的な情報(すなわち属性情報)を記憶する。申請管理では、ひとつの申請につき、1行の情報が登録される。図19は、申請管理DB50のデータ構造を示す。図示のごとく、ユーザ欄530、申請番号欄532、書類コード欄534、部店欄536、口座番号欄538、顧客名欄540、申請者名欄542、申請状況欄544、申請日時欄546、申請完了日欄548が含まれる。
The
一方、申請内容管理は、申請ごとに申請内容を記憶する。つまり、申請内容管理に記憶された内容が、申請書類の実質的な内容に相当し、申請管理は、申請内容管理を識別するためのインデックスに相当する。そのため、申請内容では、ひとつの申請につき、申請書類の項目数に応じた1以上の行の情報が登録される。図20は、申請管理DB50の別のデータ構造を示す。図示のごとく、ユーザ欄550、申請番号欄552、申請内容の項目番号欄554、内容欄556が含まれる。申請管理DBのデータは、申請内容等に変更が生じた場合等のタイミングで更新される。
On the other hand, the application content management stores the application content for each application. That is, the content stored in the application content management corresponds to the substantial content of the application document, and the application management corresponds to an index for identifying the application content management. Therefore, in the application content, information of one or more lines corresponding to the number of items in the application document is registered for each application. FIG. 20 shows another data structure of the
申請状況管理DB52は、申請ごとに定義された申請者および承認者の登録状況を記憶する。申請状況管理DB52では、ひとつの申請につき、複数行の情報が登録される。複数行は、書類に対する承認者の数と申請者の数との和に相当する。申請状況DBのデータは承認処理が行われたタイミングなどで更新される。図21は、申請状況管理DB52のデータ構造を示す。図示のごとく、ユーザ欄560、申請番号欄562、役職欄564、登録状況欄566、登録日時欄568、登録者氏名欄570が含まれる。登録状況欄566において、現在のステータスが示される。
The application
監査証跡管理DB54は、申請書類に対する更新の履歴を記憶する。監査証跡管理DB54では、ひとつの申請につき、更新した数だけの情報が記憶される。監査証跡管理DB54も更新が行われたタイミングで更新される。図22は、監査証跡管理DB54のデータ構造を示す。図示のごとく、ユーザ欄580、申請番号欄582、更新時間欄584、更新者欄586、更新内容欄588、役職欄590が含まれる。更新時間欄584では、更新時間が示される。図12に戻る。
The audit
申請状況照会部102は、申請開始の指示が完了した後、受付部96から受けつけた指示であって、照会者からの照会指示を受けつける。当該指示は、申請状況の照会要求である。申請状況照会部102は、照会指示を受けつけると、申請状況管理DB52に記憶されたデータを取得する。なお、申請状況照会部102は、申請管理DB50、監査証跡管理DB54に記憶されたデータを取得しない。つまり、申請情報記憶部20は、参照のタイミングに応じて、複数の部分に分割して構成されている。複数の部分は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に相当する。このうち、申請顧客情報DBには固定された状態でデータが記憶され削除以外の編集ができない一方、その他のDBについてはデータが編集可能に構成されている。申請状況照会部102は、取得したデータをもとに申請状況一覧画面を生成し、生成した画面を表示部98に表示する。図23は、申請状況照会部102によって生成される申請状況一覧画面を示す。図示のごとく、申請状況と承認状況が申請ごとに表示される。複数の承認者が設定されている場合、複数の承認者のそれぞれにおける承認状況が示される。
The application
5.承認登録処理
図24は、承認登録部76の構成を示す。承認登録部76は、承認画面生成部110、移動部112を含む。また、承認登録部76は、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
5. Approval Registration Processing FIG. 24 shows the configuration of the
承認画面生成部110は、受付部96から受けつけた指示であって、かつ承認者からの承認申請表示指示を受けつける。当該指示は、承認申請を表示させる要求であり、この例では承認状況情報を伴って承認申請案件が表示されるため、承認申請表示要求は、前述の申請状況の照会要求と類似している。申請状況の照会要求では、申請状況と承認状況が申請ごとに表示部98に表示されるのに対して、承認申請表示要求では、承認状況が申請ごとに表示部98に表示される。承認画面生成部110は、承認申請表示指示を受けつけると、申請状況管理DB52に記憶されたデータを取得する。承認画面生成部110は、取得したデータをもとに承認申請表示画面を生成し、生成した画面を表示部98に表示する。図25は、承認画面生成部110によって生成される承認申請表示画面を示す。図示のごとく、承認状況が申請ごとに表示される。承認状況が「承認待ち」であることは、承認あるいは非承認すべき状況に相当する。一方、承認状況が「未承認」であることは、他の承認者が承認あるいは非承認すべき状況に相当する。さらに、承認状況が「承認済」であることは、既に承認した状況に相当する。なお、承認状況が「非承認」であることは、いずれかの承認者によって非承認された状況に相当する。図24に戻る。
The approval
表示部98に承認申請表示画面を表示させた状態において、承認者が申請番号を特定して押し下げると、承認画面生成部110は、受付部96から、特定された申請番号に対応した申請書類の表示指示を受けつける。承認画面生成部110は、受けつけた指示に応じて、該当する顧客の顧客情報を申請顧客情報DB48から取得し、申請についての属性情報と申請内容の情報とを申請管理DB50から取得する。承認画面生成部110は、取得したデータをもとに、承認内容照会画面を作成し、作成した承認内容照会画面を表示部98に表示させる。
In the state where the approval application display screen is displayed on the
図26は、承認画面生成部110によって生成される承認内容照会画面を示す。図示のごとく、申請書類と同様の内容が表示される。承認者は、承認内容照会画面の内容を確認し、承認する場合、承認ボタン650をマウスでクリックする。一方、承認者は非承認する場合、非承認ボタン652をマウスでクリックする。なお、承認者記入ボタンがクリックされると、承認画面生成部110は、承認者記入欄編集画面を表示部98に表示させる。図27は、承認画面生成部110によって生成される承認者記入欄編集画面を示す。内容の部分に示された項目は、顧客の属性に応じて規定される。図24に戻る。
FIG. 26 shows an approval content inquiry screen generated by the approval
承認者による承認・非承認の指示が入力されると、承認画面生成部110は、受付部96から、承認者による承認処理完了の指示を受けつける。これは、申請開始指示に対する承認処理の完了指示である。承認画面生成部110は、承認処理完了の指示を受けつけると、承認対象のデータを移動部112に更新不能な状態で記憶するように指示する。なお、複数の承認者が設定されている場合、承認画面生成部110は、最後の承認者が承認処理の完了を指示したときに移動部112にデータの記録を指示する。承認者が残っている場合、承認画面生成部110は、申請状況管理DB52および監査証跡管理DB54のデータを更新する。
When an approval / non-approval instruction by the approver is input, the approval
移動部112は、承認画面生成部110からの指示を受けつけると、申請顧客情報DB48に記憶されたデータを申請顧客履歴情報DB58に更新不能な状態で記憶させる。ここでのデータは、前述のごとく、顧客の資産情報と顧客の属性情報等に相当する。また、移動部112は、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータを申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64にそれぞれ更新不能な状態で記憶させる。これらのデータは、申請顧客情報DB48に記憶されたデータに付随した申請情報ともいえ、申請開始の指示から承認完了の指示までの間において内容が更新可能とされていたデータを元データとする。
When the moving
一方、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64に記憶された申請情報は、更新不可能である。申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64は、承認情報記憶部22に格納されているので、承認情報記憶部22は、承認後のデータを記憶する。なお、申請顧客履歴情報DB58、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64でのデータ構造は、申請顧客情報DB48、申請管理DB50、申請状況管理DB52、監査証跡管理DB54でのデータ構造とそれぞれ同様であるので、ここでは説明を省略する。
On the other hand, the application information stored in the application
6.事務処理登録処理
図28は、事務処理登録部78の構成を示す。事務処理登録部78は、申請情報記憶部20、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
6). Business Process Registration Process FIG. 28 shows the configuration of the business
事務処理登録部78は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、事務処理状況の照会要求である。事務処理登録部78は、指示を受けつけると、申請管理DB50、申請状況管理DB52、監査証跡管理DB54に記憶されたデータを取得する。
The business
事務処理登録部78は、取得したデータをもとに事務処理状況一覧画面を生成し、生成した画面を表示部98に表示する。図29は、事務処理登録部78によって生成される事務処理状況一覧画面を示す。図示のごとく、処理状況が申請ごとに表示される。処理状況が「処理待ち」であることは、事務処理を実行すべき状況に相当する。一方、処理状況が「未処理」であることは、他の社員が事務処理を実行すべき状況に相当する。さらに、処理状況が「処理済」であることは、既に処理した状況に相当する。
The business
7.申請保管処理
図30は、申請保管部80の構成を示す。申請保管部80は、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
7). Application Storage Processing FIG. 30 shows the configuration of the
申請保管部80は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、承認が完了した申請書類の照会要求である。申請保管部80は、指示を受けつけると、申請状況履歴管理DB62に記憶されたデータを取得する。申請保管部80は、取得したデータをもとに保管している申請を表示する画面を生成し、生成した画面を表示部98に出力する。図31は、申請保管部80によって生成される保管申請表示画面を示す。図示のごとく、承認状況が確認される。なお、申請番号が選択されると、申請保管部80は、申請顧客履歴情報DB58、申請履歴管理DB60に記憶されたデータを取得し、承認された申請書類を表示部98に表示してもよい。
The
8.監査証跡管理処理
図32は、監査証跡管理部82の構成を示す。監査証跡管理部82は、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続される。受付部96、表示部98は、図1の端末装置12に含まれている。なお、申請情報記憶部20、承認情報記憶部22、受付部96、表示部98に接続されるためには、図1のネットワーク24や図2のIF部84を介しているが、ここでは、説明を明瞭にするためにこれらを省略する。
8). Audit Trail Management Processing FIG. 32 shows the configuration of the audit
監査証跡管理部82は、受付部96から受けつけた指示であって、かつ証券会社の社員からの指示を受けつける。当該指示は、申請書類に対する監査証跡の照会要求である。ここで、照会対象の申請書類に対して、承認が完了している場合があれば、承認が完了していない場合もある。監査証跡管理部82は、指示とともに申請番号も受けつけており、監査証跡管理DB54および監査証跡履歴管理DB64を参照することによって、申請番号に対応したデータが格納されている方を特定する。申請番号に対応したデータが監査証跡管理DB54に含まれていることは、承認が完了していない申請書類に対する監査証跡を照会することに相当する。
The audit
一方、申請番号に対応したデータが監査証跡履歴管理DB64に含まれていることは、承認が完了した申請書類に対する監査証跡を照会することに相当する。監査証跡管理部82は、申請番号に対応したデータが監査証跡管理DB54に含まれている場合、監査証跡管理DB54に記憶されたデータを取得する。一方、監査証跡管理部82は、申請番号に対応したデータが監査証跡履歴管理DB64に含まれている場合、監査証跡履歴管理DB64に記憶されたデータを取得する。監査証跡管理部82は、取得したデータをもとに申請更新履歴照会画面を生成し、生成した画面を表示部98に出力する。
On the other hand, the fact that the data corresponding to the application number is included in the audit trail
ここで、申請情報記憶部20に記憶された第2DB46のうち、監査証跡管理DB54だけが使用され、申請管理DB50、申請状況管理DB52は使用されていない。また、承認情報記憶部22に記憶された申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64のうち、監査証跡履歴管理DB64だけが使用され、残りは使用されていない。つまり、監査証跡管理部82によって使用される部分は、申請情報記憶部20および承認情報記憶部22のうち、対応した部分である。そのため、承認情報記憶部22は、申請履歴管理DB60、申請状況履歴管理DB62、監査証跡履歴管理DB64のように、複数の部分に分割して構成されている。このような分割は、第2DB46での構成に合わせられている。図33は、監査証跡管理部82によって生成される申請更新履歴照会画面を示す。図示のごとく、誰がいつ、何を実施したかが確認可能なような表示がなされる。
Here, among the
9.動作
以上の構成による証券業務システム200の動作を説明する。図34は、証券業務システム200による申請処理の手順を示すシーケンス図である。第1端末装置12aは、申請者からの開始指示を申請サーバ10へ送信する(S10)。申請サーバ10は、顧客情報記憶部18からデータを取得する(S12)。申請サーバ10は、申請画面を生成する(S14)。申請サーバ10は、生成した申請画面の表示指示を第1端末装置12aへ送信する(S16)。第1端末装置12aは、申請画面を表示する(S18)。第1端末装置12aは、申請者からの申請開始の指示を申請サーバ10へ出力する(S20)。申請サーバ10は、申請画面を生成するために取得し、および入力されたデータを申請情報記憶部20に送信する(S22)。申請情報記憶部20は、データを記憶する(S24)。
9. Operation The operation of the
図35は、証券業務システム200による承認処理の手順を示すシーケンス図である。申請サーバ10は、申請情報記憶部20からデータを取得する(S30)。申請サーバ10は、承認画面を生成する(S32)。申請サーバ10は、生成した承認画面の表示指示を第2端末装置12bへ送信する(S34)。第2端末装置12bは、承認画面を表示する(S36)。第2端末装置12bは、承認者からの承認指示を申請サーバ10へ出力する(S38)。申請サーバ10は、データの移動指示を申請情報記憶部20へ送信し(S40)、申請情報記憶部20は、データを承認情報記憶部22に送信する(S42)。承認情報記憶部22は、データを記憶する(S44)。
FIG. 35 is a sequence diagram showing the procedure of the approval process by the
10.全体構成の追記
ここでは、1.全体構成において説明した証券業務システム200の構成を別の観点から説明する。図36は、本発明の実施例に係る証券業務システム200の別の構成を示す。証券業務システム200は、端末装置12と総称される第1端末装置12a、第2端末装置12b、ネットワーク24、Webアプリケーションサーバ210、BL(Business Logic)サーバ212、DB(Data Base)サーバ214を含む。BLサーバ212は、申請承認処理部216、管理部218を含み、DBサーバ214は、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22を含む。また、管理部218は、顧客情報生成部70を含む。ここで、申請承認処理部216、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22は、申請機能実行部230としてまとめられ、管理部218、資産情報記憶部14、顧客属性記憶部16は、管理機能実行部232としてまとめられる。
10. Addition of overall configuration Here, 1. The configuration of the
まず、図36の証券業務システム200と図1の証券業務システム200との対応を説明する。同一の符号で示された端末装置12、資産情報記憶部14、顧客属性記憶部16、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22、ネットワーク24、顧客情報生成部70は、互いに対応する。また、図36の申請承認処理部216は、図1の申請サーバ10に対応する。
First, the correspondence between the
Webアプリケーションサーバ210は、一方において、ネットワーク24を介して端末装置12と接続され、他方において、BLサーバ212と接続される。そのため、Webアプリケーションサーバ210は、証券業務システム200のうち、端末装置12とのインターフェイスの役割を担う。つまり、Webアプリケーションサーバ210は、ネットワーク24を介して端末装置12からの要求等の信号を受信するとともに、ネットワーク24を介して端末装置12へ応答や画面等の信号を送信する。
On the one hand, the
BLサーバ212は、Webアプリケーションサーバ210に接続され、Webアプリケーションサーバ210からの要求に応じて処理を実行する。BLサーバ212は、実行すべき処理の内容に応じて複数の機能を実行しており、ここでは、一例として、申請承認処理部216、管理部218が含まれる。なお、端末装置12からの要求は、各機能に対応しており、Webアプリケーションサーバ210において割振りがなされる。また、申請承認処理部216は、処理を実行するために、顧客情報記憶部18、申請情報記憶部20、承認情報記憶部22と連携しており、これらによってなされる機能が申請機能実行部230である。管理部218は、処理を実行するために、資産情報記憶部14、顧客属性記憶部16と連携しており、これらによってなされる機能が管理機能実行部232である。
The
ここでは、管理機能実行部232の処理をまず説明する。これは、2.顧客情報生成処理に関連する。資産情報記憶部14は、図3のごとく、預りDB30、資産DB32を備えている。預りDB30、資産DB32に記憶されたデータは、所定のタイミングで更新される。ここでは、更新処理を説明する。顧客が商品を売買したタイミングや、資産の時価が変動したタイミングにおいて、証券会社の担当者は、端末装置12を操作して、預りDB30に記憶されたデータの変更要求をWebアプリケーションサーバ210へ出力する。Webアプリケーションサーバ210は、預りDB30の変更要求であるので、BLサーバ212から管理部218を選択し、選択した管理部218へ変更要求を出力する。管理部218は、変更要求を受けつけてから対応可能になると、Webアプリケーションサーバ210を介して端末装置12へ、対応可能になったことが示された応答を送信する。端末装置12が応答を受信すると、担当者は端末装置12を操作して、変更内容を入力する。端末装置12は、Webアプリケーションサーバ210を介して、変更内容を管理部218へ出力する。管理部218は、変更内容に応じて、預りDB30のうちの対応したデータを更新する。
Here, the process of the management
前述のごとく、資産DB32に格納されたデータは、預りDB30に格納されたデータに依存する。そのため、管理部218は、預りDB30に格納されたデータを更新すると、資産DB32に格納されたデータも更新する。さらに、DBサーバ214には、図示しない株価情報DBが含まれており、当該株価情報DBは、定期的に更新されるので、管理部218は、予め定められた時刻に株価情報DBにアクセスし、株価情報DBに格納されたデータの更新を確認する。株価情報DBに更新があれば、管理部218は、それを反映させるように、資産DB32に格納されたデータを更新する。このように、預りDB30は、担当者の操作によって更新されるが、資産DB32は自動的に更新される。
As described above, the data stored in the
また、顧客属性記憶部16は、図3のごとく、共通属性DB34、個人属性DB36、法人属性DB38を含む。共通属性DB34、個人属性DB36、法人属性DB38も、預りDB30と同様に、担当者の操作によって更新されるので、ここでは説明を省略する。このように、資産情報記憶部14や顧客属性記憶部16は、所定のタイミングで更新される顧客の資産情報と顧客の属性情報とを逐次記憶する。
The customer
顧客情報生成部70は、資産情報記憶部14、顧客属性記憶部16に記憶されたデータに更新があった場合、予め定められた一部の種類のデータによって、顧客情報記憶部18に記憶したデータを更新する。予め定められた一部の種類のデータは、例えば、顧客属性情報である。このような更新は、資産情報記憶部14、顧客属性記憶部16においてデータの更新がなされてから、一定の期間内に自動的になされる。その結果、一部の種類のデータについては、顧客情報記憶部18において最新の状態が維持される。また、更新には、AQ連携が使用される。さらに、夜間等の予め定められたタイミングにおいて、顧客情報生成部70は、残りの種類のデータによって、顧客情報記憶部18に記憶したデータを更新する。つまり、変更に追従して変更がなされなかった種類のデータが、一括して変更される。
When the data stored in the asset
このように顧客情報生成部70は、管理機能実行部232内のデータによって、申請機能実行部230内のデータを更新する。これは、機能をまたいでデータを更新することに相当する。ここで、顧客情報生成部70による顧客の資産情報と顧客の属性情報との更新方向は、資産情報記憶部14、顧客属性記憶部16から、顧客情報記憶部18への一方向である。つまり、顧客情報記憶部18から、資産情報記憶部14、顧客属性記憶部16の方向への更新はなされない。これは、顧客情報記憶部18に格納されたデータよりも、資産情報記憶部14、顧客属性記憶部16に格納されたデータの方が重要性が高いためである。これは、資産情報記憶部14、顧客属性記憶部16が主となり、顧客情報記憶部18が従となるような主従関係が存在するためであるともいえる。
As described above, the customer
次に、申請機能実行部230の処理を説明する。これは、3.書類登録処理、4.申請登録処理、5.承認登録処理、6.事務処理登録処理、7.申請保管処理、8.監査証跡管理処理に関連する。ここでは、特に、4.申請登録処理を説明する。申請者は、第1端末装置12aを操作することによって、所定の顧客についての証券業務に関する承認申請の開始指示を入力する。第1端末装置12aは、ネットワーク24を介して開始指示をWebアプリケーションサーバ210へ出力する。Webアプリケーションサーバ210は、第1端末装置12aから、証券業務に関する承認申請の開始指示を受けつける。当該開始指示には、対象となる顧客に関する顧客コードが含まれるとともに、顧客が個人であるか法人であるかを識別するための識別情報も含まれる。Webアプリケーションサーバ210は、開始指示をもとに、申請承認処理部216を選択し、申請承認処理部216に開始指示を出力する。
Next, processing of the application
図12の取得部106は、Webアプリケーションサーバ210からの開始指示を入力する。取得部106は、受けつけた開始指示に対する顧客コードを参照して、顧客情報記憶部18に記憶した顧客の資産情報と顧客の属性情報等から、当該顧客についての資産情報と属性情報とを取得する。前述のごとく、取得部106によってアクセスされる顧客情報記憶部18では、既存客情報管理DB40の内容と顧客カードDB42の内容とが、所定のまたは任意のタイミングにて更新されている。取得部106は、顧客情報記憶部18にアクセスした時点、すなわち、受付部96が申請者からの申請書類作成指示の入力を受け付けた時点とほぼ同じ時点に顧客情報記憶部18に保持されている顧客の属性情報と資産情報とを取得する。その後、顧客情報記憶部18に記憶された顧客の属性情報と資産情報とが更新されても、更新内容は、取得部106において取得された顧客の属性情報と資産情報に反映されない。
The acquisition unit 106 in FIG. 12 inputs a start instruction from the
図12の申請画面生成部104は、取得部106において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する申請内容編集画面を生成する。申請画面生成部104において生成される申請内容編集画面は、前述のとおりであり、取得部106での取得後における顧客の属性情報と資産情報の更新を反映しない。また、顧客の属性情報と資産情報の更新履歴も含まれない。申請画面生成部104は、顧客コードをもとに、顧客が個人であるか法人であるかを特定する。なお、前述のごとく、顧客の種別と顧客コードとの紐づけは予めなされている。申請画面生成部104は、特定した結果に応じて異なった形式の申請内容編集画面を生成する。例えば、顧客が個人である場合の申請内容編集画面は、図14のように示され、顧客が法人である場合の申請内容編集画面は、図16のように示される。
The application
このように、申請画面生成部104に入力される顧客の資産情報と顧客の属性情報は、顧客が個人であるか法人であるかにかかわらず同一であるのに対して、申請画面生成部104によって生成される申請内容編集画面は、顧客が個人であるか法人であるかに応じて異なる。申請画面生成部104は、生成した申請内容編集画面をWebアプリケーションサーバ210に出力する。また、顧客情報等には、さまざまな項目が存在しており、顧客情報生成部70によって顧客情報記憶部18へ移動される際に項目が絞られるとともに、申請画面生成部104において画面を生成する際にも項目が絞られている。つまり、顧客情報等に含まれた項目は、2段階で絞られている。
As described above, the customer asset information and the customer attribute information input to the application
Webアプリケーションサーバ210は、申請画面生成部104において生成した申請内容編集画面を第1端末装置12aに表示させるために、ネットワーク24を介して第1端末装置12aへ申請内容編集画面を出力する。第1端末装置12aは、図示しないモニタに申請内容編集画面を表示する。申請者は、申請内容編集画面が第1端末装置12aに表示された状態において、図17の申請ボタン640を押し下げることによって、承認申請を行う旨の申請指示を入力する。第1端末装置12aは、証券業務の承認申請を行う旨の申請指示をWebアプリケーションサーバ210に出力する。なお、当該申請指示には、申請内容編集画面に含まれた顧客の資産情報と顧客の属性情報も含まれる。
The
Webアプリケーションサーバ210は、申請指示を受けつけるとともに、申請内容編集画面に含まれた顧客の資産情報と顧客の属性情報も受けつける。Webアプリケーションサーバ210は、これらを申請承認処理部216に出力する。ここでは、図12の取得部106が登録部であるとする。登録部は、Webアプリケーションサーバ210が申請指示を受けつけると、Webアプリケーションサーバ210において受けつけた顧客の資産情報と顧客の属性情報を申請情報記憶部20に記憶させる。つまり、顧客情報記憶部18に記憶した顧客の資産情報と顧客の属性情報ではなく、第1端末装置12aにおいて申請者に直接確認された顧客の資産情報と顧客の属性情報とが記憶される。これは、申請者によって、所定の顧客についての証券業務に関する承認申請の開始指示が入力されてから申請指示が入力されるまでの間に、顧客情報記憶部18に記憶されたデータが更新されても、それが申請情報記憶部20に記憶されるデータに反映されないことに相当する。つまり、承認申請処理において、開始指示が入力されたタイミングでの顧客の資産情報と顧客の属性情報が使用されており、その後の更新内容は無視される。これより、更新履歴も記憶されない。仮に、申請者が、更新された顧客の資産情報と顧客の属性情報を反映させたいと考えれば、それまでの申請処理が破棄され、新たな開始指示が入力される。
The
本発明の実施例によれば、顧客が個人であるか法人であるかに応じてコンプライアンスチェックやその他の承認に必要な属性情報が異なっていても、顧客が個人であるか法人であるかに応じて属性情報を別々に記憶するので、属性情報を効率的に記憶できる。また、顧客が個人であるか法人であるかに応じて属性情報を別々に取得して表示するので、承認判断に必要な情報を顧客の種類に応じて的確に参照できる。また、変動する資産情報や属性情報等を予め顧客情報記憶部に記憶しておくので、申請に際して必要な顧客情報を迅速に取得できる。また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な情報を、固定の情報として申請情報記憶部に記憶させるので、申請を承認する際に必要な情報が変動することを防止できる。また、固定すべき情報を誤って更新してしまう危険性を低減できる。 According to the embodiment of the present invention, whether the customer is an individual or a corporation even if the attribute information necessary for the compliance check and other approvals differs depending on whether the customer is an individual or a corporation. Accordingly, attribute information is stored separately, so that attribute information can be stored efficiently. In addition, attribute information is acquired and displayed separately depending on whether the customer is an individual or a corporation, so that information necessary for approval determination can be accurately referred to according to the type of customer. In addition, since asset information, attribute information, and the like that fluctuate are stored in the customer information storage unit in advance, customer information necessary for application can be quickly acquired. In addition, when an application instruction is received, the updatable information stored in the customer information storage unit is stored as fixed information in the application information storage unit, so the information necessary for approving the application varies. Can be prevented. Further, it is possible to reduce a risk that information to be fixed is erroneously updated.
また、情報の性質に応じて、記憶部の構成を分けるので、処理を効率的に実行できる。また、開始指示に対する顧客の種類と、属性情報の種類とが対応しているので、受けつけた顧客の種類に合った属性情報を取得できる。また、受けつけた顧客の種類に合った属性情報が取得されるので、承認判断に必要な属性情報を正確に取得できる。また、承認判断に必要な属性情報が正確に取得されるので、承認の正確な処理を実現できる。 Moreover, since the structure of a memory | storage part is divided according to the property of information, a process can be performed efficiently. In addition, since the customer type corresponding to the start instruction corresponds to the attribute information type, it is possible to acquire attribute information suitable for the received customer type. Moreover, attribute information suitable for the type of customer received is acquired, so that attribute information necessary for approval determination can be accurately acquired. In addition, since the attribute information necessary for the approval determination is accurately acquired, it is possible to realize an accurate process of approval.
また、承認指示を受けつけた場合に、申請情報記憶部に記憶された更新可能な情報を、更新不可能の情報として承認情報記憶部に記憶させるので、更新不可能な情報を誤って更新してしまう危険性を低減できる。また、更新不可能な情報を誤って更新してしまう危険性が低減されるので、性質の異なった情報を確実に処理できる。また、第2DBは、参照のタイミングに応じて、複数の部分に分割して構成されているので、必要な情報のみにアクセスできる。また、必要な情報のみにアクセスされるので、処理を効率を向上できる。 In addition, when the approval instruction is received, the updatable information stored in the application information storage unit is stored in the approval information storage unit as non-updatable information. Can reduce the risk. In addition, since the risk of erroneously updating information that cannot be updated is reduced, information of different properties can be reliably processed. Further, since the second DB is divided into a plurality of parts according to the reference timing, only the necessary information can be accessed. In addition, since only necessary information is accessed, processing efficiency can be improved.
また、申請の指示を受けつけた場合に、顧客情報記憶部に記憶された更新可能な顧客情報等ではなく、端末装置に表示された顧客情報等を申請情報記憶部に記憶させるので、申請者が確認した内容で申請を実行できる。また、端末装置に表示された顧客情報等が更新されても、申請情報記憶部は更新した内容を記憶しないので、固定すべき情報を誤って更新してしまう危険性を低減できる。また、資産情報記憶部、顧客属性記憶部から、顧客情報記憶部への一方向の更新がなされ、逆方向の更新がなされないので、資産情報記憶部、顧客属性記憶部が主であり、顧客情報記憶部が従である関係を維持できる。また、主従関係が維持されるので、資産情報記憶部、顧客属性記憶部が誤って更新されることを回避できる。また、顧客情報等が同一であっても、顧客が個人であるか法人であるかによって異なった画面が生成されるので、顧客の種類に適した画面を生成できる。また、顧客の種類に適した画面が生成されるので、申請者の利便性を向上できる。 In addition, when receiving the application instruction, the application information storage unit stores the customer information displayed on the terminal device instead of the updatable customer information stored in the customer information storage unit. The application can be executed with the confirmed contents. Moreover, even if the customer information or the like displayed on the terminal device is updated, the application information storage unit does not store the updated content, so that the risk of erroneously updating the information to be fixed can be reduced. In addition, since the asset information storage unit and customer attribute storage unit are updated in one direction to the customer information storage unit and not in the reverse direction, the asset information storage unit and customer attribute storage unit are mainly used. The relationship in which the information storage unit is subordinate can be maintained. Moreover, since the master-slave relationship is maintained, it is possible to avoid the asset information storage unit and the customer attribute storage unit from being updated by mistake. Moreover, even if the customer information is the same, different screens are generated depending on whether the customer is an individual or a corporation, so that a screen suitable for the type of customer can be generated. In addition, since a screen suitable for the type of customer is generated, the convenience of the applicant can be improved.
以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。 In the above, this invention was demonstrated based on the Example. This embodiment is an exemplification, and it will be understood by those skilled in the art that various modifications can be made to the combination of each component and each processing process, and such modifications are also within the scope of the present invention. .
10 申請サーバ、 12 端末装置、 14 資産情報記憶部、 16 顧客属性記憶部、 18 顧客情報記憶部、 20 申請情報記憶部、 22 承認情報記憶部、 24 ネットワーク、 70 顧客情報生成部、 200 証券業務システム、 210 Webアプリケーションサーバ、 212 BLサーバ、 214 DBサーバ、 216 申請承認処理部、 218 管理部、 230 申請機能実行部、 232 管理機能実行部。
DESCRIPTION OF
Claims (4)
複数の顧客のそれぞれに対して、顧客の資産情報と顧客の属性情報とを記憶する第1記憶部と、
前記第1受付部において受けつけた開始指示に対する顧客の情報を参照して、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報から、当該顧客についての資産情報と属性情報とを取得する取得部と、
前記取得部において取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成する生成部と、
前記生成部において生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力する出力部と、
前記出力部から出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつける第2受付部と、
前記第1記憶部とは別に設けられた第2記憶部と、
前記第2受付部が申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、前記第2受付部において受けつけた顧客の資産情報と顧客の属性情報を前記第2記憶部に記憶させる登録部と、
所定のタイミングで更新される顧客の資産情報と顧客の属性情報とを逐次記憶する元情報記憶部と、
前記元情報記憶部に記憶した顧客の資産情報と顧客の属性情報であって、かつ所定のタイミングで更新された顧客の資産情報と顧客の属性情報によって、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報を更新する更新制御部とをさらに備え、
前記更新制御部による顧客の資産情報と顧客の属性情報との更新方向は、前記元情報記憶部から前記第1記憶部への一方向であることを特徴とする申請装置。 A first reception unit that receives an instruction to start an application for approval concerning securities business from a terminal device connected via a network;
A first storage unit for storing customer asset information and customer attribute information for each of a plurality of customers;
With reference to the customer information for the start instruction received in the first reception unit, asset information and attribute information about the customer are obtained from the customer asset information and customer attribute information stored in the first storage unit An acquisition unit to
Based on the customer asset information and customer attribute information acquired in the acquisition unit, a generation unit that generates an approval application screen for securities business,
An output unit for outputting an approval application screen to the terminal device via a network in order to display the approval application screen generated in the generation unit on the terminal device;
In a state where the approval application screen output from the output unit is displayed on the terminal device, the terminal device receives an application instruction for applying for approval of securities business via the network, and is included in the approval application screen. A second reception unit for receiving customer asset information and customer attribute information;
A second storage unit provided separately from the first storage unit;
When the second reception unit receives the application instruction, the customer asset information and customer attribute information received in the second reception unit are used instead of the customer asset information and customer attribute information stored in the first storage unit. A registration unit to be stored in the second storage unit;
An original information storage unit for sequentially storing customer asset information and customer attribute information updated at a predetermined timing;
The customer asset information and customer attribute information stored in the original information storage unit, and the customer asset information and customer attribute information updated at a predetermined timing, the customer information stored in the first storage unit An update control unit for updating asset information and customer attribute information;
The application apparatus according to claim 1, wherein the update direction of the customer asset information and the customer attribute information by the update control unit is one direction from the original information storage unit to the first storage unit .
前記生成部は、前記第1受付部において受けつけた識別情報をもとに、顧客が個人であるか法人であるかを特定し、特定した結果に応じて異なった形式の承認申請画面を生成することを特徴とすることを特徴とする請求項1に記載の申請装置。 The start instruction received in the first reception unit includes identification information for identifying whether the customer is an individual or a corporation.
The generation unit specifies whether the customer is an individual or a corporation based on the identification information received by the first reception unit, and generates an approval application screen of a different format according to the specified result. The application apparatus according to claim 1, wherein
前記元情報記憶部が、所定のタイミングで更新される顧客の資産情報と顧客の属性情報とを逐次記憶するステップと、
前記更新制御部が、前記元情報記憶部に記憶した顧客の資産情報と顧客の属性情報であって、かつ所定のタイミングで更新された顧客の資産情報と顧客の属性情報によって、第1記憶部に記憶した顧客の資産情報と顧客の属性情報を更新するステップと、
前記第1受付部が、ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、
前記取得部が、複数の顧客のそれぞれに対して、前記第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、
前記生成部が、取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、
前記出力部が、生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力するステップと、
前記第2受付部が、出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、
前記登録部が、申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、前記第1記憶部とは別に設けられた第2記憶部に記憶させるステップとを備え、
前記更新するステップによる顧客の資産情報と顧客の属性情報との更新方向は、前記元情報記憶部から前記第1記憶部への一方向であることを特徴とする申請方法。 An application method executed in an application device including an original information storage unit, an update control unit, a first reception unit, an acquisition unit, a generation unit, an output unit, a second reception unit, and a registration unit,
The original information storage unit sequentially stores customer asset information and customer attribute information updated at a predetermined timing;
The update control unit includes customer asset information and customer attribute information stored in the original information storage unit, and the customer storage information and customer attribute information updated at a predetermined timing, the first storage unit Updating customer asset information and customer attribute information stored in
The first accepting unit receiving an instruction to start an application for approval concerning securities business for a predetermined customer from a terminal device connected via a network;
A step of the acquisition unit, for each of a plurality of customers, from the first storage unit, by referring to the customer information for the start instruction received, acquires the property information and the attribute information about the customer,
The generation unit generates an approval application screen related to securities business based on the acquired customer asset information and customer attribute information;
Outputting the approval application screen to the terminal device via a network in order for the output unit to display the generated approval application screen on the terminal device;
The second reception unit receives an application instruction for applying for approval of securities business from the terminal device via the network in a state where the output approval application screen is displayed on the terminal device, and the approval application screen. Accepting customer asset information and customer attribute information included in the
When the registration unit receives the application instruction, the customer asset information and customer attribute information received together with the application instruction are not the customer asset information and customer attribute information stored in the first storage unit. Storing in a second storage unit provided separately from the storage unit ,
The updating method of the customer asset information and the customer attribute information in the updating step is one direction from the original information storage unit to the first storage unit .
前記元情報記憶部に記憶した顧客の資産情報と顧客の属性情報であって、かつ所定のタイミングで更新された顧客の資産情報と顧客の属性情報によって、第1記憶部に記憶した顧客の資産情報と顧客の属性情報を更新するステップと、
ネットワークを介して接続された端末装置から、所定の顧客についての証券業務に関する承認申請の開始指示を受けつけるステップと、
複数の顧客のそれぞれに対して、前記第1記憶部から、受けつけた開始指示に対する顧客の情報を参照して、当該顧客についての資産情報と属性情報とを取得するステップと、
取得した顧客の資産情報と顧客の属性情報とをもとに、証券業務に関する承認申請画面を生成するステップと、
生成した承認申請画面を前記端末装置に表示させるために、ネットワークを介して前記端末装置へ承認申請画面を出力するステップと、
出力した承認申請画面が前記端末装置に表示された状態において、前記端末装置からネットワークを介して、証券業務の承認申請を行う旨の申請指示を受けつけるとともに、承認申請画面に含まれた顧客の資産情報と顧客の属性情報も受けつけるステップと、
申請指示を受けつけると、前記第1記憶部に記憶した顧客の資産情報と顧客の属性情報ではなく、申請指示とともに受けつけた顧客の資産情報と顧客の属性情報を、前記第1記憶部とは別に設けられた第2記憶部に記憶させるステップとを備え、
前記更新するステップによる顧客の資産情報と顧客の属性情報との更新方向は、前記元情報記憶部から前記第1記憶部への一方向であるをコンピュータに実行させるためのコンピュータプログラム。 Sequentially storing the asset information of the customer and the attribute information of the customer updated at a predetermined timing in the original information storage unit;
Customer asset information and customer attribute information stored in the original information storage unit, and customer asset information and customer attribute information updated at a predetermined timing and stored in the first storage unit Updating information and customer attribute information;
Receiving from a terminal device connected via a network an instruction to start an approval application for securities business for a given customer;
For each of a plurality of customers, from the first storage unit, by referring to the customer information for the start instruction received, acquiring the asset information and attribute information of the customer,
Generating an approval application screen for securities business based on the acquired customer asset information and customer attribute information;
Outputting the approval application screen to the terminal device via a network in order to display the generated approval application screen on the terminal device;
In the state where the output approval application screen is displayed on the terminal device, the terminal device receives an application instruction to apply for approval of securities business via the network, and the customer's assets included in the approval application screen Receiving information and customer attribute information,
When receiving the application instruction, not the customer asset information and customer attribute information stored in the first storage unit, but the customer asset information and customer attribute information received together with the application instruction are separated from the first storage unit. And storing in a second storage unit provided,
A computer program for causing a computer to execute an updating direction of customer asset information and customer attribute information in the updating step in one direction from the original information storage unit to the first storage unit .
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011176656A JP5755968B2 (en) | 2011-01-14 | 2011-08-12 | Application method and application device |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011006502 | 2011-01-14 | ||
JP2011006502 | 2011-01-14 | ||
JP2011176656A JP5755968B2 (en) | 2011-01-14 | 2011-08-12 | Application method and application device |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011216594A Division JP2012160164A (en) | 2011-01-14 | 2011-09-30 | Application method and application device |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012160162A JP2012160162A (en) | 2012-08-23 |
JP5755968B2 true JP5755968B2 (en) | 2015-07-29 |
Family
ID=46840616
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011176656A Active JP5755968B2 (en) | 2011-01-14 | 2011-08-12 | Application method and application device |
JP2011216594A Withdrawn JP2012160164A (en) | 2011-01-14 | 2011-09-30 | Application method and application device |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011216594A Withdrawn JP2012160164A (en) | 2011-01-14 | 2011-09-30 | Application method and application device |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP5755968B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112686757A (en) * | 2020-12-31 | 2021-04-20 | 京东数字科技控股股份有限公司 | Method and device for processing security business data, electronic equipment and storage medium |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3547180B2 (en) * | 1994-11-17 | 2004-07-28 | 株式会社日立製作所 | Examination work support system and examination work support method |
JP2006277452A (en) * | 2005-03-30 | 2006-10-12 | Daiwa Securities Group Inc | Loan method and loan system with security document as collateral |
JP4251301B2 (en) * | 2007-03-12 | 2009-04-08 | クオリティ株式会社 | Business management system, business management server, and business management program |
-
2011
- 2011-08-12 JP JP2011176656A patent/JP5755968B2/en active Active
- 2011-09-30 JP JP2011216594A patent/JP2012160164A/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
JP2012160162A (en) | 2012-08-23 |
JP2012160164A (en) | 2012-08-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7865412B1 (en) | Method and system for account tracking | |
US20090282006A1 (en) | Transaction Management | |
US8463667B2 (en) | Exporting and importing business templates | |
JP2007536607A (en) | System and method for user creation and command of rich content lifecycle | |
US20200334325A1 (en) | Sections for themes | |
JP2022173544A (en) | Business property evaluation support device, business property evaluation support method, program, and business property evaluation support system | |
WO2015060326A1 (en) | Information management system | |
JP2015184723A (en) | document creation support system | |
JP2021060883A (en) | Computer program, transmission method, and transmission device | |
JP5755968B2 (en) | Application method and application device | |
JP4043251B2 (en) | Server program | |
KR101782534B1 (en) | System for providing automatic of work by requirement of customer on demand | |
JP6924309B2 (en) | Computer program, output method and output device | |
JP4827989B1 (en) | Application method and application device | |
JP2022019974A (en) | Customer extraction system, customer extraction apparatus, customer extraction method, and computer program | |
JP2021120913A (en) | Financial product transaction management device, financial product transaction management system, and program | |
US20200089200A1 (en) | Production management support apparatus and production management support method | |
JP2009070028A (en) | Investment contract support apparatus, and investment contract support program | |
JPWO2019138670A1 (en) | Business management system and business management method | |
JP2003167997A (en) | Customer information management system | |
JP7094515B1 (en) | Matching system, matching method and program | |
JP4818764B2 (en) | Asset management result analysis support system and method | |
US20240202803A1 (en) | System And Method for Modifying a Portion of a User Interface According to An Interaction with A Message | |
JPH1139407A (en) | Slip creation system | |
JP2002269392A (en) | Purchase agent supporting server using internet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20140129 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20140912 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20141104 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20141219 |
|
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: 20150526 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20150528 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5755968 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |