JP2005084880A - Settlement system and settlement program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To ensure appropriate settlement without spoiling the convenience of policyholders and while reducing an office work burden on a company which sells products. <P>SOLUTION: A settlement system comprises an amount receivable data management part 22 for, upon a product purchase contract, storing amount receivable data including information specifying an amount receivable and the contract product, as a record of an amount receivable data table, an amount received data management part 24 for storing amount received data including information specifying an amount received and a product, generated according to the payment using a payment slip created according to the amount receivable data, as a record of an amount received data table, and a data negation part 26 for matching the records of both tables to negate the records. If a plurality of records includes information specifying the same product, the amounts included in the plurality of records are summed up, and the sum total is matched for negation. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a system and a program that can smoothly execute a payment process.

  Conventionally, insurance premiums are generally paid by transferring a designated amount to an insurance agent account or by handing the designated amount directly to an insurance agent staff. In order to increase the convenience of paying insurance premiums by policyholders, for example, settlement using a convenience store has been proposed.

  Patent Document 1 proposes to use a convenience store for paying a fire mutual aid premium. In this proposal, the following procedure is followed.

  The station translator fills out a report and application form for fire mutual aid at the same time as the rental agreement for the housing at the dealer of the mutual aid association. This report and application form has a management number.

  The dealer will give the contractor a payment slip with a management number for payment at the convenience store.

  The dealer will send a report and application form to the mutual aid association by fax.

  The mutual aid association inputs the contents of the report / application form as contract data into the system together with the management number. This data is stored in the system.

  The contractor brings a payment slip to a convenience store and pays a predetermined amount.

  The paid amount data (payment data) is sent to the mutual aid association through the storage agent.

The mutual aid association confirms the payment by collating the management number of the payment data with the management number of the contract data stored in the system.
JP 2002-183440 A

  However, in particular, in the field of non-life insurance, the application content may be changed, and multiple applications may be issued with the same security number. In this case, the payment is confirmed only when both the original application amount and the new application amount are received. Also, depending on the insurance, part of the maturity refund may be used for the insurance premiums that are continued. Even in such a case, it is desirable to realize payment without impairing the convenience of the contractor and appropriate payment confirmation.

  An object of the present invention is to provide a system and program capable of making an appropriate settlement without impairing the convenience of a contractor and reducing the business burden of a company that sells products.

  An object of the present invention is a deposit schedule data management means for storing a deposit schedule data including a schedule of deposit amount and information for specifying a product related to the contract as a record of a deposit schedule data table. The payment data generated according to the payment using the payment slip for the payment person to pay the payment amount at the store, which is created based on the input schedule data, and specifies the payment amount and the product The received data management means for storing the received data including the information to be received as a record of the received data table, the record of the received data table, and the record of the received data table are collated, and the application of the record is performed. A data erasure means to be executed, wherein a plurality of records including information for identifying the same product in the record of the deposited data table are included. If there are multiple records that contain information identifying the same product in the records in the deposit schedule data table to be verified, This is achieved by a settlement system characterized by comprising a data application means for performing an application by adding together the scheduled deposit amounts included in the plurality of records and collating the combined amount.

  According to the present invention, even when a plurality of payment slips are created for a certain product, it is possible to apply by adding the payment amounts paid by these items. In particular, even if there is a possibility that multiple applications with the same security number may be issued, such as insurance products for non-life insurance, it will be possible to apply for an insurance product unit, for example, a security number unit. it can. Thereby, the business burden in an insurance company can be remarkably reduced.

  In a preferred embodiment, the product is an insurance product, the information for identifying the product is a security number, and a maturity refund for a certain insurance product is applied to a premium for a contract for a new insurance product. As you can see, the deposit schedule data corresponds to the old security number that is the security number of the original insurance product, the amount of the maturity refund of the original insurance product, and the difference between the maturity refund and the premium A payment slip is created that includes the difference collection amount, the difference collection amount corresponds to the deposit amount, and the old security number and the amount of the maturity refund. Including the amount of money, and the data application means that the sum of the amount of money received and the amount of maturity refund matches the planned amount of money received in the corresponding record in the data table Determines whether or not Luke.

  In a preferred embodiment, the data application means sets at least an application flag for a record scheduled to be deposited after the application has been completed.

  In another preferred embodiment, the data erasing means further notifies the information of the record for which the erasure is completed to the system of the merchandise seller via the network.

  Further, an object of the present invention is to store payment schedule data including a payment schedule amount and information for specifying a product related to the contract as a record of a payment schedule data table according to a purchase contract of the product, Deposited data generated according to payment using a payment slip for the settlement person to pay the settlement amount at the store, created based on the scheduled input data, and information specifying the deposit amount and the product Storing the received data including the data as a record in the received data table, comparing the record in the received data table with the record in the received data table, and executing application for the record. When there are a plurality of records including information specifying the same product in the record of the deposited data table, Deposits included in multiple records when there are multiple records that contain information identifying the same product in the records in the deposit schedule data table to be collated and summed the deposit amounts included in multiple records The step of adding the scheduled amount and executing the application by checking the combined amount is performed by a computer-readable payment program characterized by causing the computer to execute.

  In a preferred embodiment, the product is an insurance product, the information for identifying the product is a security number, and a maturity refund for a certain insurance product is applied to a premium for a contract for a new insurance product. As you can see, the deposit schedule data corresponds to the old security number that is the security number of the original insurance product, the amount of the maturity refund of the original insurance product, and the difference between the maturity refund and the premium A payment slip is created that includes the difference collection amount, the difference collection amount corresponds to the deposit amount, and the old security number and the amount of the maturity refund, and the entered data is the old security number and the maturity return. In the step of executing the application including the amount of money, the sum of the amount of money received and the amount of maturity return in the record of the entered data table is the amount of money received in the corresponding record of the payment scheduled data table. The step of determining whether to meet the constant amount, causes the computer to perform.

  Further, in the step of executing the application, it is preferable that the computer execute at least a step of setting an application flag of a record to be deposited after the application is completed. Further, in the step of executing the application, it is preferable that the computer execute a step of notifying the seller system of the product of the information of the record that has been completed through the network.

  According to the present invention, it is possible to provide a system and a program capable of appropriate settlement without impairing the convenience of a contractor and reducing the business burden of a company that sells products.

  Embodiments of the present invention will be described below with reference to the accompanying drawings. FIG. 1 is a block diagram showing an outline of the entire system according to the present embodiment. As shown in FIG. 1, in this system, a server 10 connected via a network 16, 18 is provided between a convenience store system 12 and an insurance company system 14.

  As shown in FIG. 1, the server 10 receives a DB 20 for storing various data, which will be described later, and a deposit schedule data from the insurance company system 14, performs necessary processing, and stores the deposit in the DB 20. The payment data management unit 24, the payment data management unit 24 that receives the payment data from the convenience store system 12 and performs necessary processing and stores it in the DB 20, the payment schedule data, and the payment data Based on the data application unit 26 that executes an application process described later, and payment that executes processes for presenting various information to the system 14 in response to a request from the system 14 of the insurance company. And a status management unit 28.

  With reference to FIG. 2, description will be made on creation of a payment slip and generation of data of funds transfer when using the system according to the present embodiment. The insurance application form entered by the contractor is sent from the agency to the insurance company (see reference numeral 201). In the insurance company system 14, payment schedule data is generated based on the application form and transmitted to the server 10 (see reference numerals 202 and 203). FIG. 3A is a diagram showing a data configuration of a deposit schedule data table that stores deposit schedule data in the DB 20. The records in the deposit schedule data table include the following items: “Contractor name”, “Planned deposit premium”, “Securities number”, “Agent code”, “Department code”, “Main store code”, “Application” "Date", "Payment type", "Agent name", "Contractor address", "Contractor zip code", "Contractor telephone number", "Insurance liability start date" and "Serial number". Here, the “serial number” is numbered so that the record of the deposit scheduled data is uniquely identified. The numbers used for the serial numbers are numbered by the insurance company system 14 and may be transmitted to the server 10 or may be numbered by the server 10.

  In the server 10, the payment schedule data is referred to and a payment slip is created (see reference numeral 204). The created payment slip is sent, for example, to the settlement person by mail (see reference numeral 205). The settlement person is usually a contractor, but may be other than that. In the payment slip, in addition to the payment amount, “securities number” and “serial number” are described. "Securities number" and "Serial number"

  A settlement person (contractor) pays a predetermined insurance premium by bringing a payment slip to a convenience store (see reference numeral 211). The paid insurance premium data is sent to the convenience store system 12 and further sent to the server 10 as paid-in data. FIG. 3B is a diagram illustrating a data configuration of a deposited data table that stores deposited data in the DB 20. The record in the deposited data table includes “Deposit date”, “Deposit amount”, “Deposit time”, “Securities number”, and “Serial number” as items.

  When the deposit schedule data from the insurance company system 14 is received by the server 10, the deposit schedule data management unit 22 of the server 10 stores the received deposit schedule data as a record in the deposit schedule data table of the DB 20. When the received data from the convenience store system 12 is received by the server 10, the received data management unit 24 of the server 10 stores the received received data as a record of the received data table in the DB 20. .

  The server 10 refers to the deposit schedule data and the deposited data stored in the DB 20 and executes the processing described below. FIG. 4 is a flowchart showing a consumption process executed by the server 10. This process may be executed every time the deposited data from the convenience store system 12 is received, or may be executed at a predetermined timing (for example, every day at a predetermined time). In the latter case, it is only necessary to perform processing on all records in the deposited data table that have not been completed.

  As shown in FIG. 4, the data application unit 26 of the server 10 records in the deposited data table a record that is the target of processing in the deposited data table and a record having the same “securities number” and “deposited amount”. It is determined whether or not it already exists (step 401). In the present embodiment, as described with reference to FIG. 2, when the payment schedule data is transmitted to the server 10, a payment slip is created and mailed to the settlement person in response thereto. Further, in accordance with payment using the payment slip, the paid data is generated and transmitted to the server 10. Therefore, basically, the record of the deposit schedule data and the record of the deposit have a one-to-one correspondence. However, there is a possibility that the same deposited data may be transmitted to the server 10 in a plurality of errors due to some mistakes. Therefore, in step 401, such erroneous deposited data is eliminated.

  In the present embodiment, “sequential number” is included in the record of the deposit scheduled data table and the deposited data record. Accordingly, if it is determined that the “serial number” is duplicated in the deposited data table, it is possible to realize a double check for eliminating duplicate records.

  If it is determined as Yes in step 401, it is considered that an error has occurred. Therefore, an error message is displayed on the display device of the server 10 to notify the operator that an error has occurred. (Step 402). In addition to this, an error may be notified to the convenience store system 12.

  Next, the data application unit 26 refers to the “securities number” of the record in the deposited data table to be processed, and there is another record in the deposited data table having the same “securate number”. It is determined whether or not to perform (step 403). If it is determined as Yes in step 403, the data application unit 26 adds up the “payment amounts” in the plurality of records (step 404). If NO is determined in step 403, the process proceeds to step 405 described later.

  Thereafter, the data application unit 26 refers to the records having the same “securities number” from the deposit schedule data table and acquires the “scheduled deposit premium” (step 405). When there are a plurality of records, the sum total of the “scheduled insurance premiums” of the plurality of records is obtained. Next, it is determined whether the “deposit amount” obtained based on the deposited data table or the sum thereof and the “scheduled insurance premium amount” obtained based on the scheduled deposit data table or the sum thereof match. (Step 406). If they do not match (No in step 406), it is considered that an error has occurred. Therefore, an error message is displayed on the display device of the server 10 to indicate to the operator that an error has occurred. Notification is made (step 407). On the other hand, if it is determined as Yes in step 406, the record to be processed in the deposited data table and the scheduled deposit data table, that is, the record used for calculating the matching amount in both. Is set to a consumption flag (not shown) (step 408). The records for which the consumption flag is set are subsequently excluded from the object of the consumption process.

  Further, the data application processing unit 26 notifies the insurance company system 14 of the securities number for which the application has been completed (step 409).

  According to the present embodiment, in response to receipt of payment schedule data based on an application form from an insurance company, the server 10 creates a payment slip including the “insurance amount” and “securities number”. Further, in response to the payment at the convenience store by the settlement person, the paid data including the “paid amount” and the “securities number” is transmitted to the server 10. In the server 10, the “securities number” is used as a key, and the deposited data having the same “securities number” are added together to execute the application. Accordingly, the application can be executed for each “securities number”, and the completion of application to the insurance company is also notified in units of “securities numbers”. Therefore, it is possible to make a clear application without mistake, and it is possible to easily confirm the receipt of the premium amount in the insurance company. In the insurance industry, additional insurance premiums may be collected from policyholders before insurance contracts are finalized. In the present embodiment, when there are a plurality of deposits with the same securities number, they can be erased by adding them in units of securities numbers.

  Next, processing executed by the deposit status management unit 28 will be briefly described. In accordance with a request from the insurance company system 14 given via the network 18, the deposit status management unit 28 can read a record of desired deposit schedule data and present it to the insurance company system 14. . The presented information includes information indicating payment / non-payment based on the application flag included in each record. For example, if a deposit is scheduled, but there is no deposit due to cancellation of the contract, the record can be deleted. Alternatively, the contents of the record can be changed as necessary.

  In FIG. 1, the deposit status management unit 28 can present necessary information to the insurance company system 14, but the present invention is not limited to this. A record having an agency code of an insurance agency may be referred to. In addition, it is desirable to restrict the deletion or change of records based on the agency code, department code, main store code, etc. so that only the agency, department, or main store corresponding to that code can perform it. .

  Furthermore, the deposit status management unit 28 refers to the record in the deposit schedule data table, and records that the application flag is not set even after a certain period of time has elapsed from the application date, or a predetermined date before the insurance liability start date. Regardless, find a record that does not have the clear flag set. For these records, it is desirable to identify the contractor in the record, create a payment slip again, and send it by mail.

  Next, a second embodiment of the present invention will be described. When a contract with a maturity refund reaches the maturity, even if it is applied to the temporary payment premium for a new contract, such as an automatic continuation special contract, the difference between the maturity refund and the single payment premium is collected from the contractor There is. In such a case, the server 10 according to the second embodiment erases the lump sum premium required for the new contract by adding up the maturity refund of the old contract and the difference collected from the new contract. And the security number for application can be transmitted to the insurance company system 14. The outline of the entire system in the second embodiment is almost the same as that of the first embodiment shown in FIG. Also, the creation of a payment slip and the creation of funds transfer data are substantially the same as those shown in FIG.

  Again, the creation of payment slips and the creation of funds transfer data will be briefly described. Also in the second embodiment, the insurance application form entered by the contractor is sent from the agency to the insurance company, and in the insurance company system 14, the security number of the contract that has expired ("old securities number"). The payment schedule data is generated based on the security number of the new insurance contract (also referred to as “new security number”) and transmitted to the server 10.

  FIG. 5A is a diagram showing a data configuration portion of a deposit schedule data table according to the second embodiment. In the record of the deposit scheduled data table according to the second embodiment, in addition to the record item of the data table shown in FIG. 3A, as shown in FIG. "Number", "amount of refund for maturity", and "collected difference". Further, the value of the item “securities number” in the record of the deposit schedule data table corresponds to the new security number related to the new insurance contract. In addition, in the record of the deposit schedule data table, the deposit expected insurance amount matches the insurance amount (for example, the one-time insurance premium amount) in the new insurance contract.

  The server 10 includes at least a new security number, a paid-in amount corresponding to the difference collection amount, an old security number, and a serial number. The created payment slip is sent to a settlement person (contractor), and the settlement person (contractor) pays the difference collection amount at a convenience store.

  The convenience store system 12 generates the paid-in data based on the paid-in payment data and transmits it to the server 10. In addition to the items shown in FIG. 3B, the record in the deposited data table according to the second embodiment includes “old securities number” and “maturity refund amount” as shown in FIG. 5B. "including. Further, in the second embodiment, the item “payment amount” in FIG. 3B corresponds to the difference collection amount.

  Similar to the first embodiment, when the deposit schedule data from the insurance company system 14 is received by the server 10, the deposit schedule data management unit 22 accepts it as a record of the deposit schedule data table of the DB 20. The received payment schedule data is stored. Further, even when the deposited data from the convenience store system 12 is received by the server 10, the deposited data management unit 24 stores the received deposited data as a record in the deposited data table of the DB 20. .

  Next, the process of the data consumption part 26 of the server 10 concerning 2nd Embodiment is demonstrated. FIG. 6 is a flowchart illustrating an application process executed when the maturity refund is applied, which is executed in the server 10 according to the second embodiment. This process can be executed following the consumption process shown in FIG.

  As shown in FIG. 6, the data application unit 26 of the server 10 refers to the record to be processed in the deposited data table and determines whether the item “old securities number” exists (step 601). . If it is determined NO in step 601, the process ends. On the other hand, if it is determined as Yes in step 601, the data application unit 26 uses the same “old securities number” as the “old securities number” existing in the record of the deposited data table. It is determined whether or not a record included as an item exists in the deposit schedule data table (step 602). If it is determined NO in this step 602, it is considered that an error has occurred, so an error message is displayed on the display device of the server 10 to notify the operator that an error has occurred. (Step 603).

  If it is determined yes in step 602, the data application unit 26 determines that a record including the “securities number” that is the same as the “new securities number” existing in the records of the deposited data table is It is determined whether or not it exists in the deposit schedule data table (step 604). Even if it is determined NO in step 604, the data erasure unit 26 displays an error message on the display device of the server 10 to notify the operator that an error has occurred (step 605).

  If it is determined as Yes in step 602 and step 604, the data application unit 26 adds up the amount of the maturity refund and the difference collection amount in the record of the deposited data table (step 606). ), It is determined whether or not the total amount matches the insurance amount of the record including the new security number in the deposit schedule data table (step 607). If it is determined NO in step 607, it is determined whether the total amount is smaller than the insurance premium amount (step 608). If the amount is small (Yes in step 608), a payment slip is created with the difference as the payment amount so as to collect the difference between the premium and the sum (step 609). , Sent to the settlement person. When the total amount is small, for example, a predetermined flag (re-send flag) is set in the record to be processed in the deposited data table, and at the time of the next processing, For records with the re-send flag set, search for other records with the same new security number and old security number (paid-in data records based on payment using the difference payment slip) and collect the difference between the two records. 6 is added, and the process shown in FIG. 6 may be executed using this as a new difference collection amount.

  If no in step 608, that is, if the sum is greater than the insurance premium, a process for refund is executed (step 610). When the payment to the settlement person is completed, as in step 611, which will be described later, the application flag of the record of the received data table and the record of the scheduled payment data table (records including new securities numbers) to be processed are set. Set.

  If yes in step 607, that is, if the total amount and the insurance premium amount match, the data application unit 26 applies the application application flag and the payment flag of the record of the received data table to be processed. The consumption flag of the record including the new security number in the schedule data table is set (step 611). As a result, in the subsequent processing, for the record for which the application flag is set, the object of data application processing (see FIG. 4) and application processing (see FIG. 6) when the maturity refund is applied thereafter. Get out. Next, the data application processing unit 26 notifies the insurance company system 14 of the securities number for which the application has been completed (step 612).

  According to the second embodiment, when an insurance contract with a maturity refund reaches its maturity, the maturity refund is converted into a part of the insurance premium (for example, a one-time insurance premium) in a new contract based on an automatic continuation special contract. Can be applied as In this case, the user only has to pay the difference collection amount to the convenience store according to the payment slip. In addition, in the server 10, appropriate cancellation can be realized in the above-described case by adding the amount of the maturity refund amount and the difference collection amount and performing the cancellation.

  In the second embodiment, the present invention is applied to a case where an insurance contract with a maturity refund reaches a maturity, and a new contract of the same insurance type is concluded by an automatic continuation special contract. However, the present invention is not limited to this, and the present invention can also be applied to a case where a new contract is made for insurance of a different insurance type. For example, there may be a case where a small shortage occurs due to the limit of the premium calculation unit when the refund for maturity insurance is applied to the initial payment for the life insurance newly contracted. In such a case, a payment slip may be created using the shortage as a difference collection amount, and the processing shown in FIG. 6 may be executed based on the payment data obtained by the payment by the settlement person.

  The present invention is not limited to the above embodiments, and various modifications can be made within the scope of the invention described in the claims, and these are also included in the scope of the present invention. Needless to say.

FIG. 1 is a block diagram showing an outline of the entire system according to the present embodiment. FIG. 2 is a diagram for explaining the creation of a payment slip and the generation of funds transfer data when using the system according to the present embodiment. FIGS. 3A and 3B are diagrams showing a data configuration of a deposit schedule data table storing deposit schedule data and a data configuration of a deposit data table storing deposit data. FIG. 4 is a flowchart showing the consumption process according to the present embodiment. FIGS. 3A and 3B are a part of the data structure of a payment schedule data table storing payment schedule data according to the second embodiment, and a payment data table storing payment data. It is a figure which shows a part of data structure of FIG. 6 is a flowchart showing an application process when a maturity refund according to the second embodiment is applied.

Explanation of symbols

10 Server 12 Convenience Store System 14 Insurance Company System 16, 18 Network 20 Payment Status DB
22 Payment Schedule Data Management Department 24 Deposited Data Management Department 26 Data Application Department 28 Payment Status Management Department

Claims (8)

A payment schedule data management means for storing payment schedule data including a payment schedule amount and information for specifying a product related to the contract as a record of the payment schedule data table in accordance with the purchase contract of the product;
Deposited data generated based on payment using a payment slip for a settlement person to pay a settlement amount at a store, which is created based on the input schedule data, and specifies the deposit amount and the product A received data management means for storing received data including information as a record of a received data table;
A data application unit that performs a record-related application by comparing a record in the received data table with a record in the received data table, and information that identifies the same product in the record in the received data table If there are multiple records that contain, the total of the deposit amounts included in the multiple records, and there are multiple records that contain information that identifies the same product in the records in the planned deposit data table to be verified A payment system, comprising: a data application unit for performing an application by adding together the planned deposit amounts included in the plurality of records and collating the combined amount. The product is an insurance product, and information specifying the product is a security number,
Furthermore, in order to apply the maturity refund of a certain insurance product to the insurance premium of the contract for the new insurance product, the deposit plan data is the old security number that is the security number of the original insurance product, the original insurance number Including the amount of the product's maturity refund and the difference collected corresponding to the difference between the maturity refund and the insurance premium. Is created, and the entered data includes the old security number and the amount of the maturity refund,
The data application means determines whether or not the sum of the deposit amount and the maturity refund amount in the record of the input data table matches the planned deposit amount in the corresponding record in the deposit schedule data table. The settlement system according to claim 1, wherein: The settlement system according to claim 1 or 2, wherein the data application unit sets at least an application flag of a record scheduled to be deposited after the application is completed. Further, the data erasure means notifies the information of the record for which the erasure is completed to the system of the merchandise seller via the network. The system described in the section. Storing a planned deposit amount and deposit schedule data including information for specifying a product related to the contract as a record in the deposit schedule data table in accordance with the purchase contract of the product;
Deposited data generated based on payment using a payment slip created by the settlement person to pay the settlement amount at the store, which is created based on the input schedule data, and identifies the deposit amount and the product Storing the received data including information as a record in the received data table;
A step of collating the record of the deposit data table with the record of the deposited data table and executing application for the record, and a plurality of information including information specifying the same product in the record of the deposited data table If there are multiple records that contain information that identifies the same product in the records in the deposit plan data table that should be verified, A computer-readable payment program, comprising: causing a computer to execute a step of performing an application by adding together planned payment amounts included in the plurality of records and collating the combined amount. The product is an insurance product, and information specifying the product is a security number,
Furthermore, in order to apply the maturity refund of a certain insurance product to the insurance premium of the contract for the new insurance product, the deposit plan data is the old security number that is the security number of the original insurance product, the original insurance number Including the amount of the product's maturity refund and the difference collected corresponding to the difference between the maturity refund and the insurance premium. Is created, and the entered data includes the old security number and the amount of the maturity refund,
Whether the sum of the deposit amount and the maturity refund amount in the record of the input data table matches the planned deposit amount in the corresponding record in the deposit schedule data table in the step of executing the application The program according to claim 5, wherein the computer is caused to execute the step of determining whether or not. 7. The program according to claim 5, wherein in the step of executing the application, the computer is caused to execute at least a step of setting an application flag of a record scheduled to be deposited after the application has been completed. . Further, in the step of executing the consumption, the computer is caused to execute a step of notifying the seller system of the product of information on the record for which the application has been completed via the network. The program according to any one of claims 5 to 7.

Images