JP2008276404A - Collection support system, collection support method, and collection support program - Google Patents

Abstract

A collection support system, a collection support method, and a collection support program for supporting management of collection from a business partner are provided.
A reward management server includes a participating master database. In this participating master database, a participating master record for a business partner of a tax accountant office is recorded. In this participation master record, a mouth transfer usage classification for identifying whether or not account transfer is used is recorded. Then, a billing statement record is recorded in the billing statement database in accordance with the mouthpiece use category. In addition, information on whether or not retransfer is possible and transfer stop are also reflected in the billing statement record. When the billing confirmation date arrives, the control unit 21 of the reward management server 20 specifies the transfer target using the billing detail record, and further generates the transfer request message using the corresponding billing statement breakdown record. To do.
[Selection] Figure 1

Description

  The present invention relates to a collection support system, method, and program for supporting management of collection from a business partner.

  When a transaction is performed, an invoice is issued to the business partner, and the collection management of the billing amount from the billing business is performed. In this case, the billing source needs to manage the payment for each bill. However, with the recent diversification of transactions, expansion of business partners, etc., issuing bills and collecting and managing the amount of bills from billing parties can be a heavy burden on the billing source. Therefore, a system for substituting billing and deposit management is being studied. (For example, see Patent Documents 1 and 2.) In the techniques described in these patent documents, an account for accepting the transfer of the billing amount is provided for each billing destination. Then, an invoice with this account as the deposit destination is created and sent to the invoice destination. When there is a deposit in this account, the billing address is specified according to the transfer information.

  Further, an account transfer processing system for reducing the burden of the application work by checking the validity of the payment amount by the payer systematically (for example, see Patent Document 3). In the technique described in this document, a payer and a loan account are associated with each other, and funds transferred to each loan account are transferred to a “collection account”. Here, when the money is transferred to the loan account, it is determined whether or not the account transfer from the loan account to the “collection account” is possible based on the transfer amount preset in each loan account. The “collecting account” is configured such that an amount matching the amount charged can be transferred.

In addition, a system related to an accounting paperwork management system has been studied (for example, see Patent Document 4). The accounting paperwork management system described in this document includes a business management system, a personnel and labor management system, a work evaluation system, and a budget management system. Through these management systems, profits for each product and each customer can be grasped, and manufacturing, sales, management costs, etc. of the entire company can be instantly confirmed.
JP 2003-123020 A (first page) JP 2003-67583 A (first page) JP2003-122932A (first page) Japanese Patent Laying-Open No. 2005-174073 (first page)

  By the way, when there is a continuous transaction between the billing source and the billing destination, it is convenient if account transfer can be used. On the other hand, the depositing method may be appropriately changed depending on the situation with such a business partner. Managing these deposits individually requires great effort.

  The present invention has been made to solve the above-described problems, and provides a collection support system, a collection support method, and a collection support program for supporting management of collection from a business partner.

In order to solve the above-mentioned problem, the invention described in claim 1 is the supplier information including account information and a transfer usage flag for determining whether or not to use the account transfer for the user identifier and the customer identifier. The customer information storage means that records the information, the calendar information storage means that records the calendar information including information about the transfer date and the scheduled transfer date, and the bill that records the billing information from the user to the supplier for each scheduled transfer date A collection support system comprising information storage means and control means connected to a user terminal via a network and performing billing management, wherein the control means obtains a user identifier from the accessed user terminal When the billing supplier identifier is obtained from the user authentication means and the user terminal, the bill associated with the user identifier and the supplier identifier When an amount input screen is generated, transmitted to the user terminal, and the charged amount input on the charged amount input screen is acquired, the acquired charged amount and supplier identifier are associated with the user identifier and supplier identifier. A billing registration processing unit that records a transfer usage flag corresponding to the billing information in the billing information storage unit, and confirms the input of the billing amount based on the scheduled transfer date recorded in the calendar information storage unit, from the billing information storage unit The billing information in which the transfer use flag is recorded is acquired, the account information recorded in the customer information storage means is acquired for the customer identifier of the billing information, the transfer request message is generated, and the transfer request process is executed. And a bill processing means.

  According to a second aspect of the present invention, in the money collection support system according to the first aspect, when the control unit receives a transfer stop request for stopping a transfer from the user terminal, the user information is stored in the bill information storage unit. The invention further includes means for recording transfer stop information in association with the identifier and the business partner identifier, and the claim processing means does not include the charge information in which the transfer stop information is recorded in the transfer request message.

  According to a third aspect of the present invention, in the money collection support system according to the first or second aspect, the supplier information stored in the supplier information storage means further includes a retransfer category for determining whether or not retransfer is possible. The billing processing unit acquires a transfer result corresponding to the transfer request message, records a transfer result in association with a user identifier and a business partner identifier in the billing information storage unit, and the billing registration processing unit includes: If the transfer result includes a non-transferable transaction identifier, this non-transferable business partner identifier is specified, and if a retransferable category that allows a retransfer is recorded in this business partner information, the next transfer request The gist is to register as billing information in processing.

  According to a fourth aspect of the present invention, in the money collection support system according to any one of the first to third aspects, the customer information stored in the customer information storage means includes a sales recording month relative to a transfer date. Sales recording month calculation information for specifying is further recorded, and the billing registration processing means records the sales recording recorded in the supplier information storage means for each billing information for the transfer date for executing the transfer request process. The gist is to calculate the billing date using the month calculation information and to record it in the billing information.

  The invention according to claim 5 is a supplier information storage means for recording customer information including account information and a transfer usage flag for determining whether or not to use account transfer for a user identifier and a customer identifier; A calendar information storage unit that records calendar information including information about the transfer date and a scheduled transfer date, a billing information storage unit that records billing information from a user to a customer for each scheduled transfer date, and a network A method for executing a collection support process using a collection support system that is connected to a user terminal and includes a control unit that performs billing management, wherein the control unit obtains a user identifier from the accessed user terminal. When acquiring the user authentication stage to be acquired and the supplier identifier to be charged from the user terminal, the user identifier and the supplier identifier are associated with each other. When the charge amount input screen is generated and transmitted to the user terminal and the charge amount input on the charge amount input screen is acquired, the acquired charge amount and transaction are associated with the user identifier and the business partner identifier. A billing registration processing step of recording a transfer usage flag corresponding to a destination identifier in the billing information storage unit, and confirming an input of a billing amount based on a scheduled transfer date recorded in the calendar information storage unit, and the billing information storage The billing information in which the transfer usage flag is recorded is acquired from the means, the account information recorded in the supplier information storage means is acquired for the customer identifier of the billing information, the transfer request message is generated, and the transfer request processing is performed. The main point is to execute the billing process stage to be executed.

  The invention according to claim 6 is a supplier information storage means for recording customer information including account information and a transfer usage flag for determining whether or not to use account transfer for a user identifier and a customer identifier. A calendar information storage unit that records calendar information including information about the transfer date and a scheduled transfer date, a billing information storage unit that records billing information from a user to a customer for each scheduled transfer date, and a network A program for executing a collection support process using a collection support system that is connected to a user terminal and includes a control unit that performs billing management, wherein the control unit receives a user identifier from an accessed user terminal. When acquiring the billing supplier identifier from the user authentication means to be acquired and the user terminal, it is related to the user identifier and the supplier identifier. The generated billing amount input screen is generated, transmitted to the user terminal, and when the billing amount input on the billing amount input screen is acquired, the acquired billing amount is associated with the user identifier and the supplier identifier. And a billing registration processing means for recording a transfer usage flag corresponding to the supplier identifier in the billing information storage means, and confirming the input of the billing amount based on the scheduled transfer date recorded in the calendar information storage means, The billing information in which the transfer usage flag is recorded is acquired from the information storage means, the account information recorded in the supplier information storage means is acquired for the supplier identifier of this billing information, and a transfer request message is generated to generate the transfer request. The gist is to function as billing processing means for executing processing.

(Function)
According to the first, fifth, and sixth aspects of the present invention, the control means acquires the user identifier from the user terminal that has been accessed. When the billing supplier identifier is acquired from the user terminal, a billing amount input screen associated with the user identifier and the supplier identifier is generated and transmitted to the user terminal. Further, when the charge amount input on the charge amount input screen is acquired, the acquired charge amount is recorded in the charge information storage means in association with the user identifier and the business partner identifier. Then, the input of the billing amount is closed based on the scheduled transfer date recorded in the calendar information storage means. Next, the billing information in which the transfer usage flag is recorded is obtained from the billing information storage means, and the account information recorded in the supplier information storage means is obtained for the supplier identifier of the billing information to generate a transfer request message. To execute the transfer request process. Accordingly, it is possible to centrally manage business partners that use account transfer and business partners that do not use account transfer, and efficiently manage business partner information corresponding to various transaction forms. And when using account transfer by transfer use identification information, it can collect money at a predetermined time based on the calendar information without taking the user's trouble.

  According to the second aspect of the present invention, when a transfer stop request for stopping transfer is received from the user terminal, transfer stop information is recorded in the charge information storage means in association with the user identifier and the supplier identifier. The billing processing means does not include the billing information in which the transfer stop information is recorded in the transfer request message. Thereby, the account transfer can be stopped at any time even in the business partners using the account transfer.

  According to the invention described in claim 3, the billing processing means acquires the transfer result corresponding to the transfer request message, and records the transfer result in correspondence with the user identifier and the supplier identifier in the billing information storage means. Then, when the transfer result includes non-transferability in the transfer result, the billing registration processing means specifies the non-transferable supplier identifier. Further, when a re-transferable category enabling re-transfer is recorded in the supplier information, it is registered as billing information in the next transfer request process. Thereby, when it becomes uncollected in the previous account transfer, a recharge can be performed without a user's burden.

According to the fourth aspect of the present invention, the sales partner month storage information for specifying the sales sales month for the transfer date is further recorded in the customer information of the customer information storage means. Then, the billing registration processing means calculates the billing date using the sales record month calculation information recorded in the supplier information storage means for each billing information for the scheduled transfer date for executing the transfer request process. Record. As a result, it is possible to specify the billing date regardless of the transfer date and to manage accurate sales recording.

  According to the present invention, it is possible to provide a collection support system, a collection support method, and a collection support program for supporting management of collection from a business partner.

  DESCRIPTION OF EMBODIMENTS Hereinafter, embodiments embodying the present invention will be described with reference to FIGS. In this embodiment, when a tax accountant office manages billing / payment of remuneration from a customer (participant) who is a customer, a collection support system, a collection support method, and a collection support program for supporting this management Will be described.

  In the present embodiment, as shown in FIG. 1, the reward management server 20 as a collection support system executes a management request process for compensation request / payment at a tax accountant office. A user terminal 10 installed in a tax accountant office is connected to the reward management server 20 via the Internet as a network. The reward management server 20 transmits and receives data to and from the financial institution server BK.

  This user terminal 10 is a computer terminal used by a person in charge of a tax accountant office that uses a service for collecting tax on behalf of a tax accountant reward. In addition to a CPU, RAM, and ROM (not shown), the user terminal 10 includes input means such as a keyboard and a mouse, output means such as a display, and communication means. The user terminal 10 is used when the user accesses the reward management server 20. The user terminal 10 stores a browser program for realizing a function of transmitting data via a network, a function of displaying received data, and the like.

The financial institution server BK is a computer system of a financial institution that manages deposit accounts and performs account transfer processing in response to an account transfer request.
The reward management server 20 is a computer system that performs various types of data processing based on data received from the user terminal 10 in order to realize a collection support service for managing compensation requests and deposits. The reward management server 20 includes a control unit 21. The control unit 21 functions as a control unit that performs various data management processes for performing the collection support process. The control unit 21 includes a CPU, RAM, ROM, and the like (not shown). Then, the processes described later (user authentication stage, billing registration process stage, billing process stage, billing information registration stage in the next transfer request process, billing date calculation stage, etc.) are executed. By executing the collection support program for that purpose, the control unit 21, as shown in FIG. 1, causes the user IF unit 210, billing information registration unit 211, billing input processing unit 212, billing confirmation processing unit 213, account transfer processing unit. 214, which functions as an individual deposit management means 215. In the present embodiment, the billing confirmation processing unit 213 and the account transfer processing unit 214 function as a billing processing unit.

The billing information registration unit 211 functions as a billing registration processing unit, and executes processing for generating billing information and registering in the billing information storage unit.
The billing input processing unit 212 executes processing for generating billing information and updating in the billing information storage unit in response to an instruction from the user terminal.

The billing confirmation processing unit 213 confirms the billing information registered in the billing information storage unit, and executes a transfer request message creation process.
The account transfer processing unit 214 transmits a transfer request message to the financial institution server BK. Furthermore, the transfer result is acquired from the financial institution server BK and registered in the billing information storage means.

The individual deposit management means 215 executes a deposit cancellation process and a deposit cancellation process which will be described later.
The user IF unit 210 functions as a user authentication unit, and includes a screen request acquisition unit 210a, a screen output unit 210b, an input information acquisition unit 210c, a screen expansion order memory 210e, and a temporary input memory 210f as shown in FIG. The user IF unit 210 includes a screen data storage unit (not shown), and holds screen data for performing collection support in response to various requests from the user.

  The screen request acquisition unit 210a of the user IF unit 210 receives the screen request from the user terminal, and records this request history in the screen development order memory 210e. The screen output unit 210b transmits screen data corresponding to the screen request acquired by the screen request acquisition unit 210a to the user terminal 10. Further, the input information acquisition unit 210 c acquires data input on the screen provided to the user terminal 10. In this case, the data yet to be determined is stored in the temporary input memory 210f.

  The screen development order memory 210e records a screen development history provided to the user terminal 10 for one session. When the screen request acquisition unit 210a acquires a “return” request (front screen request) or a “forward” request (rear screen request) of the screen flow from the user terminal 10, the screen output unit 210b The screens are developed in the order recorded in the order memory 210e. In this case, the screen output unit 210b acquires the value temporarily input on the preceding screen from the temporary input memory 210f, embeds it in the requested screen data, and transmits it to the user terminal 10.

Next, a screen flow using each screen data recorded in the screen data storage unit will be described with reference to FIG.
First, the login screen data LG is expanded into the menu screen data 50. The menu screen data 50 includes participating party search screen data 51, participating party list screen data 51a, billing schedule list (detail) screen data 52, billing confirmation list (detail) screen data 53, and transfer result list (detail) screen data. 54. Further, the menu screen data 50 includes a new participant registration screen data 55, a payment application screen data 56, a receivable balance list screen data 57, various data screen data, common item setting screen data, a system management screen data, and a schedule management screen. The data 59 is expanded.

  Participant search screen data 51 is expanded into participant list screen data 51a, and further, basic information change screen data 61, transfer account change screen data 62, charge amount input (monthly) screen data 63, charge amount input. (As needed) The screen data 64, the remuneration ledger management screen data 65, and the advance payment ledger screen data 66 are expanded.

  The billing schedule list (details) screen data 52 is expanded into billing schedule list (total) screen data 52a, billing amount input (monthly) screen data 63, and billing amount input (as needed) screen data 64.

  Here, basic information change screen data 61, transfer account change screen data 62, billing amount input (monthly) screen data 63, billing amount input (as needed) screen data 64, compensation ledger management screen data 65, and advance payment ledger screen data 66 are associated with each other and can be expanded to other screen data.

The billing confirmation list (details) screen data 53 is expanded into billing confirmation list (total) screen data 53a, billing confirmation amount (monthly) screen data 53b, and billing confirmation amount (as needed) screen data 53c.

  The transfer result list (details) screen data 54 is expanded into billing result list (total) screen data 54a, billing result amount (monthly) screen data 54b, and billing result amount (as needed) screen data 54c.

Furthermore, as shown in FIG. 1, the reward management server 20 includes a master data storage unit 22, a calendar data storage unit 23, and a billing data storage unit 24.
The master data storage unit 22 stores a tax accountant office master database 221, a user master database 222, and a participating master database 223.

The calendar data storage unit 23 functions as a calendar information storage unit and stores a calendar database 231.
The billing data storage unit 24 functions as billing information storage means, and stores a billing database 241, a billing details database 242, a billing details breakdown database 243, and a billing confirmation database 244.

  In the tax accountant office master database 221, a tax accountant office master record R21 is recorded as shown in FIG. This tax accountant office master record R21 is registered before the use of the collection support service is started. The tax accountant office master record R21 includes the tax accountant office identifier and data related to the tax accountant office name and the account identifier.

  In the tax accountant office identifier data field, data relating to an identifier for identifying each tax accountant office is recorded, and functions as a user identifier for identifying a user who uses the service.

In the tax accountant office name data field, data relating to the name of the tax accountant office is recorded.
In the account identifier data field, data for specifying a deposit account of this tax accountant office is recorded. This deposit account will be used to transfer remuneration collected from the tax accountant office.

  In the user master database 222, as shown in FIG. 4B, a user master record R22 for each person in charge (user) of the tax accountant office is recorded. This user master record R22 is registered before the use of the collection support service is started. The user master record R22 includes a tax accountant office identifier and user ID, a password, and data related to the previous login date and time.

In the tax accountant office identifier data field, data relating to an identifier for identifying each tax accountant office is recorded.
In the user ID data field, data relating to the identifier assigned to the person in charge of this tax accountant office is recorded.

  Data for authenticating the user is recorded in the password data field. The user ID and password are used to perform user authentication at the time of login to the reward management server 20.

Data for specifying the date and time when this user last logged in is recorded in the previous login date / time data field. This previous login date and time is updated for each login.

  The involved party master database 223 functions as a supplier information storage means, and as shown in FIG. 5, an involved party master record R23 is recorded as basic information about the business partner (participant) of the tax accountant office. This participating master record R23 is recorded when the tax accountant office registers each business partner. Participating master record R23 is the tax accountant office identifier, the participating party identifier, the participating party name, the billing category, the scheduled billing month (January) to the scheduled billing month (December), the transfer date category, the forward use category , Including the data related to the sales record month, retransfer category, account identifier, and cancellation code.

In the tax accountant office identifier data field, data relating to an identifier for identifying each tax accountant office is recorded.
Data related to an identifier for identifying each business partner of the tax accountant office is recorded in the involved party identifier data field, and functions as a business partner identifier for identifying the business partner of the user.

In the participant name data field, data relating to the name of the participant is recorded.
In the billing category data field, a flag for identifying “monthly billing” or “anytime billing” is recorded. Here, the “monthly billing” flag is recorded when billing is performed every month, and the “anytime billing” flag is recorded when billing is performed only for the month set by the tax accountant office.

  In the billing scheduled month (January) to billing scheduled month (December) data field, a flag for specifying whether or not there is a billing (scheduled) in each month from January to December is recorded. In the case of billing at any time, billing can be entered only in the month in which this flag is recorded.

  In the transfer date classification data field, data relating to an identifier for classifying a scheduled date for account transfer is recorded. In this embodiment, it is assumed that the transfer is performed twice a month at the beginning of the month (5th) and the end of the month (28th). In this transfer date category data field, data for specifying “5-day transfer” or “28-day transfer” is recorded in order to identify the transfer date category.

  Transfer use identification information (transfer use flag) relating to the presence / absence of use of account transfer is recorded in the bank transfer use classification data field. In the present embodiment, a flag that specifies either “use of mouth vibration” or “not use mouth vibration” is recorded. In principle, when the “use of mouth transfer” flag is set, the reward management server 20 automatically collects money by account transfer. On the other hand, in the case where the “no wager” flag is set, the tax accountant office itself collects money by cash or check.

  In the sales recording month data field, data relating to a month (billing month) in which sales are recorded for the billing of the involved party is recorded. In the present embodiment, data relating to “previous month”, “current month”, and “next month” are recorded.

  In the retransfer category data field, data on whether or not retransfer is necessary next time is recorded when the account transfer cannot be performed. In the present embodiment, a “retransfer” flag is recorded when retransfer is used.

In the account identifier data field, data for specifying the deposit account of the participating party is recorded. This deposit account is used as a debit account for direct debit.
In the cancellation code data field, data relating to the cancellation of the use of this service is recorded for this participating party. In this field, data for specifying “in transaction”, “cancellation scheduled”, and “cancellation” is recorded, and in the case of “cancellation scheduled” and “cancellation”, it is excluded from each processing described later. .

  As shown in FIG. 6A, the billing database 241 records a billing record R41 for managing the billing information of the involved party for each transfer year. This billing record R41 is recorded according to the setting of the participating master record R23. The billing record R41 includes data relating to a billing category, a forward usage category, a re-transfer category, and a transfer result code for a tax accountant office identifier, a participant identifier, a transfer date, and a transfer date category.

In the tax accountant office identifier data field, data relating to an identifier for identifying the tax accountant office that is the billing source is recorded.
In the participation destination identifier data field, data relating to an identifier for specifying the participation destination as the billing destination is recorded.

In the transfer year / month data field, data for specifying the year / month when the request is made is recorded.
In the transfer date division data field, data relating to an identifier for dividing a date (in this embodiment, “5th day”, “28th day”) for performing the account transfer for this request is recorded.

In the billing classification data field, data for classifying the billing type (in this embodiment, “monthly billing”, “anytime billing”) is recorded.
Data relating to the presence / absence of the use of account transfer for this claim (in this embodiment, “no wager use” flag or “no wager use” flag) is recorded in the wager use classification data field.

  In the retransfer category data field, when the account transfer cannot be performed for this charge, data relating to the necessity of the retransfer next time (in this embodiment, the “retransfer” flag or the “no retransfer” flag). To be recorded. That is, the retransfer category functions as one piece of identification information for determining whether or not retransfer is possible.

  In the transfer result code data field, data for specifying the result of the account transfer for this charge is recorded. In this embodiment, “transfer completed”, “insufficient funds”, “no deposit transaction”, “transfer stop due to depositor convenience”, “no transfer request request”, “transfer stop due to consignor convenience”, “others” Is recorded.

  In the billing details database 242, as shown in FIG. 6B, a billing statement record R42 for managing the details of the billing information of the unit to be involved and identifying the target of the account transfer is recorded. This billing detail record R42 is recorded corresponding to the billing record R41. This billing statement record R42 includes a tax accountant office identifier, a participant identifier, a transfer date, a transfer date category, a billing type, a line number, an actual transfer date, an actual transfer date category, a previous transfer date, and a previous transfer. It includes data on the date category, billing date, detailed name, billing amount, consumption tax, withholding tax, deduction amount, transfer suspension category, and account transfer status category.

In the tax accountant office identifier data field, data relating to an identifier for identifying the tax accountant office for this request is recorded.
In the participation identifier data field, data relating to an identifier for specifying the participation destination for this request is recorded.

In the transfer year / month data field, data for specifying the year / month when the request is made is recorded.
In the transfer date section data field, data relating to an identifier for classifying the date (“5 days”, “28 days”) for performing the account transfer for this charge is recorded.

In the billing type data field, data for specifying the type of billing (“monthly compensation”, “extraordinary compensation”, “monthly advance payment”, “temporary advance payment”) is recorded.
In the line number data field, data relating to the display position (line number) of the billing amount input screen is recorded for each billing type.

  In the actual transfer date and actual transfer date category data fields, data relating to the actual transfer date and transfer date category are recorded. In the present embodiment, the next account transfer target is specified using the actual transfer date and actual transfer date classification. When the account transfer is completed, the date and time when the transfer was actually performed and the data related to the transfer date category are recorded.

  In the previous transfer date and previous transfer date category data fields, data related to the year and month when the previous account transfer was performed and the previous transfer date category are recorded. In the present embodiment, the previous transfer date and the previous transfer date section function as one piece of identification information for determining whether or not retransfer is possible in the billing statement record R42.

In the billing date data field, data related to the billing date (sales record date) and date for this billing is recorded.
In the detailed name data field, data relating to the detailed name for this request is recorded.

In the billing amount, consumption tax, withholding tax, and deduction amount data fields, data relating to the billing amount, consumption tax, withholding tax, and deduction amount for this billing is recorded.
In the transfer stop classification data field, data relating to whether or not to stop the account transfer is recorded. In the present embodiment, when the “forward transfer use” flag is recorded, it is a target of account transfer. Further, even if the participating party uses account transfer, the “transfer stop” flag is recorded when the account transfer is temporarily interrupted.

  Data for identifying the progress status of the account transfer is recorded in the account transfer status classification data field. In the present embodiment, data for identifying “billing schedule”, “during account transfer”, “end of account transfer”, and “not subject to account transfer” are recorded.

  In the billing details database 243, as shown in FIG. 7A, there is recorded a billing details record R43 for managing the details of the billing information for each participating party by dividing by branch numbers. The billing details breakdown record R43 is recorded corresponding to the billing record R41. The billing details breakdown record R43 includes a tax accountant office identifier, a participant identifier, a transfer date, a transfer date category, a billing type, a line number, and a branch number, a billing date, a detailed name, a deposit amount, a deposit date, and a deposit method. It includes data on classification, invoiced amount, consumption tax, withholding tax, deduction amount, receipt clearing flag, and receivable status.

In the tax accountant office identifier data field, data relating to an identifier for identifying the tax accountant office for this request is recorded.
In the participation identifier data field, data relating to an identifier for specifying the participation destination for this request is recorded.

In the transfer year / month data field, data for specifying the year / month when the request is made is recorded.
In the transfer date section data field, the date ("5 days") when the account transfer is made for this charge.
, “28 days”) is recorded.

In the billing type data field, data for specifying the type of billing (“monthly compensation”, “extraordinary compensation”, “monthly advance payment”, “temporary advance payment”) is recorded.
In the line number data field, data relating to the display position of the billing amount input screen is recorded for each billing type.

  In the branch number data field, data related to the branch number for specifying each deposit when the partial deposit is made in this billing specification is recorded. This branch number is sequentially incremented (added “1”) from the initial value “1”.

In the billing date data field, data related to the billing date (sales record date) and date for this billing is recorded.
In the detailed name data field, data relating to the detailed name for this request is recorded.

In the deposit amount / payment date data field, data relating to the deposit amount and the deposit date for this billing is recorded.
In the depositing method classification data field, data for specifying the depositing method for this claim is recorded. In the present embodiment, flags for identifying “transfer”, “cash”, “transfer”, “check”, and “other” are recorded.

  In the billing amount, consumption tax, withholding tax, and deduction amount data fields, data relating to the billing amount, consumption tax, withholding tax, and deduction amount for this billing is recorded. In this embodiment, the amount of account transfer is calculated based on the amount charged in the billing breakdown database 243.

  In the receipt application flag data field, data relating to the application information regarding this billing is recorded. In the present embodiment, when the collection for billing is completed, the “paid” flag is recorded.

  In the unpaid status data field, data relating to the unpaid status for the bill is recorded. In the present embodiment, “schedule”, “non-transferable”, “transfer stop”, and “amount fixed” flags are recorded.

  As shown in FIG. 7 (b), the billing confirmation database 244 records a billing confirmation record R44 for managing the bills that have been confirmed for the involved units on the input confirmation date. This billing confirmation record R44 is recorded when billing input is confirmed corresponding to the billing record R41. The billing confirmation record R44 includes a tax accountant office identifier, a participant identifier, a transfer date, a transfer date category, a billing type, a line number, a billing date, a detailed name, a deposit amount, a deposit date, a billing amount, a consumption tax, Consists of data on withholding tax, deduction amount, transfer stoppage indicator, and receipt clearing flag.

In the tax accountant office identifier data field, data relating to an identifier for identifying the tax accountant office for this request is recorded.
In the participation identifier data field, data relating to an identifier for specifying the participation destination for this request is recorded.

In the transfer year / month data field, data for specifying the year / month when the request is made is recorded.
In the transfer date section data field, the date ("5 days") when the account transfer is made for this charge.
, “28 days”) is recorded.

  In the billing type data field, data for specifying the billing type is recorded. In this billing type data field, in addition to “Monthly remuneration”, “Extraordinary remuneration”, “Monthly reimbursement money”, and “Extraordinary reimbursement money”, “Receivable retransfer May be recorded.

In the line number data field, data relating to the display position of the billing amount input screen is recorded for each billing type.
In the billing date data field, data related to the billing date (sales record date) and date for this billing is recorded.

In the detailed name data field, data relating to the detailed name for this request is recorded.
In the deposit amount / payment date data field, data relating to the deposit amount and the deposit date for this billing is recorded.

In the billing amount, consumption tax, withholding tax, and deduction amount data fields, data relating to the billing amount, consumption tax, withholding tax, and deduction amount for this billing is recorded.
In the transfer stop classification data field, data relating to whether or not to stop the account transfer is recorded.
In the receipt application flag data field, data relating to the receipt application flag that has been collected by transfer is recorded.

  In the calendar database 231, as shown in FIG. 8, a calendar record R31 for managing a reference date for each process is recorded. This calendar record R31 is registered when a schedule for providing the collection support service is determined. Then, a calendar management unit (not shown) of the control unit 21 instructs execution of each process to be described later according to the calendar record R31. This calendar record R31 is configured to include data on the actual transfer date, the input period start, the input period end, the transfer fixed date, the transfer result fixed date, and the transfer date for the transfer date category and the transfer date.

In the transfer date division data field, data relating to an identifier for dividing a scheduled date (“5 days”, “28 days”) for account transfer is recorded.
In the transfer date data field, data for specifying the year and month for account transfer is recorded.

In the actual transfer date data field, data relating to the date of actual account transfer in the transfer date is recorded.
In the input period start data field and the input period end data field, data for specifying a period during which the billing using the account transfer can be input for the actual transfer date is recorded.

In the transfer confirmation date data field, data related to the date for confirming the billing contents for performing the account transfer on the actual transfer date is recorded.
In the transfer result confirmation date data field, data relating to the date on which the result of the account transfer is confirmed is recorded.

In the transfer date data field, data related to the scheduled date of transferring the reward collected by account transfer to the deposit account of each tax accountant office is recorded.
Next, processing when performing collection support according to the present embodiment will be described. Here, billing information management processing (FIG. 9), login management processing (FIG. 10), billing schedule list creation processing (FIG. 11), billing amount input processing (FIG. 12), billing confirmation processing, transfer processing (FIG. 13), The payment cancellation process and the payment cancellation process (FIG. 14) will be described in this order.

(Billing information management process)
First, the billing information management process will be described with reference to FIG. This processing is executed when the billing data generation time (in this embodiment, a predetermined time before the input start date) has arrived for each transfer date category. The following processing is sequentially repeated for all participating master records R23 recorded in the participating master database 223. Specifically, first, the control unit 21 of the reward management server 20 specifies the participation master record R23 recorded in the participation master database 223.

  And the control part 21 of the reward management server 20 performs the judgment process of a transfer day classification (step S1-1). Specifically, the billing information registration unit 211 of the control unit 21 compares whether the transfer date category recorded in the participating master record R23 matches the transfer date category to be processed.

  If the transfer date classifications do not match (in the case of “NO” in step S1-1), the process for the participating master record R23 is terminated. On the other hand, when the transfer date divisions match (in the case of “YES” in step S1-1), the control unit 21 of the reward management server 20 executes a billing division confirmation process (step S1-2). Specifically, the billing information registration unit 211 of the control unit 21 uses the flag recorded in the billing category data field of the participating master record R23. Here, when the “monthly billing” flag is recorded in the billing category data field (in the case of “YES” in step S1-2), the control unit 21 of the reward management server 20 performs the monthly billing management process. Execute. In the monthly billing management process, the control unit 21 of the reward management server 20 executes a billing information registration process (step S1-3). Specifically, the billing information registration unit 211 of the control unit 21 acquires the tax accountant office identifier and the participating party identifier of the participating master record R23. Then, the billing information registration unit 211 generates a billing record R41 including the calculated transfer date and transfer category. In this case, the billing category, mouthpiece usage category, and retransfer category recorded in the participating master record R23 are recorded in the billing category, mouthpiece usage category, and retransfer category of the billing record R41. The billing information registration unit 211 registers the billing record R41 in the billing database 241.

  Next, the control part 21 of the reward management server 20 performs the search process of the monthly fixed reward information for the previous month (step S1-4). Specifically, the billing information registration unit 211 of the control unit 21 is a record including the tax accountant office identifier to be processed and the involved party identifier from the billing statement database 242, and the billing statement record R42 whose transfer date is the previous month. Search for. Next, the billing information registration unit 211 identifies the billing detail record R42 in which “monthly reward” or “monthly advance payment” is recorded in the billing type data field.

  And control part 21 of remuneration management server 20 performs registration processing of monthly remuneration information (Step S1-5). Specifically, the billing information registration unit 211 of the control unit 21 acquires the billing amount for the previous month recorded in the identified billing detail record R42.

Then, the billing information registration unit 211 generates a billing detail record R42 corresponding to the billing record R41. In this case, the billing information registration unit 211 generates a billing detail record R42 to which the line number is assigned and “monthly reward” and “monthly advance payment” are set as the billing type. Further, when the “transfer use” flag is recorded in the account transfer use category data field of the billing record R41, the “transfer” flag is recorded in the transfer stop category data field of the billing statement record R42.

  Further, since the billing details record R42 generated at this stage is not subject to retransfer, the transfer date of the billing record R41 is recorded in the actual transfer date data field. Further, the billing information registration unit 211 records the acquired billing amount for the previous month as an initial value of the billing amount of the current billing detail record R42.

Then, the billing information registration unit 211 registers this billing statement record R42 in the billing statement database 242.
Next, the billing information registration unit 211 generates a billing details breakdown record R43 corresponding to the billing details record R42. In this case, the billing information registration unit 211 assigns “1” as the initial value of the branch number. Then, the billing information registration unit 211 registers the billing details breakdown record R43 in the billing details breakdown database 243.

  Next, the control unit 21 of the reward management server 20 executes a billing month registration process (step S1-6). Specifically, the billing information registration unit 211 of the control unit 21 calculates the billing date based on the transfer date and the sales record month information of the participating master record R23. Here, when the sales recording month is “current month”, the billing month is calculated using the transfer date. In addition, when the sales recording month is “previous month”, the billing month is calculated by specifying “the month before the transfer date”, and when it is “next month”, the “month after the transfer date” is specified. Then, the billing information registration unit 211 records the billing date in the billing date data field of the billing statement record R42 and the billing statement breakdown record R43. The date of the billing date can be set separately using a predetermined input screen at a tax accountant office or the like.

  For example, when the transfer date is “October 28, 2006” and the sales recording month is “current month”, the billing date is “October 2006”. Further, when the transfer date is “November 5, 2006” and the sales recording month is “previous month”, the billing date is “October 2006”.

  On the other hand, when the “anytime billing” flag is recorded in the billing category data field (in the case of “NO” in step S1-2), the control unit 21 of the reward management server 20 executes the billing management process as needed. . In this occasional billing management process, first, the control unit 21 of the reward management server 20 executes a confirmation process of a billing month to be processed (step S1-7). Specifically, the billing information registration unit 211 of the control unit 21 determines whether the transfer date to be processed matches the billing scheduled month (billing month) in which the billing schedule flag is recorded in the involved master record R23. Confirm.

  When the transfer date to be processed does not correspond to the billing month (in the case of “NO” in step S1-7), the control unit 21 of the reward management server 20 ends the process for the involved master record R23.

On the other hand, when the transfer date to be processed corresponds to the billing month (“YES” in step S1-7), the control unit 21 of the reward management server 20 executes a billing information registration process (step S1-). 8). Specifically, the billing information registration unit 211 of the control unit 21 generates a billing record R41 and registers it in the billing database 241. In this case as well, the billing category, mouth usage category, and retransfer category recorded in the participating master record R23 are recorded in the billing category, mouth usage category, and retransfer category of the billing record R41.
The above processing is executed for all participating master records R23.

(Login management process)
Next, the login management process will be described with reference to FIG.

  First, a user performs a login request process with respect to the reward management server 20 using the user terminal 10 (step S2-1). Specifically, the user terminal 10 accesses the reward management server 20 and acquires the login screen data LG. This login screen is provided with a user ID input field and a password input field. When the user terminal 10 completes the input to each input field, the user terminal 10 transmits a login request to the reward management server 20. This login request includes data related to the user ID and password entered on the login screen.

  The control unit 21 of the reward management server 20 that has received the login request executes user authentication processing (step S2-2). Specifically, the user IF unit 210 of the control unit 21 extracts a user master record R22 including the user ID of the login request in the user master database 222. Then, it is confirmed whether or not the login request password matches the password recorded in the user master record R22. If the two match, the user authentication is completed. By using this user master record R22, the tax accountant office identifier can be specified. On the other hand, when the user authentication cannot be performed, the user IF unit 210 rejects the login.

  Next, the control part 21 of the reward management server 20 performs the acquisition process of the present date (step S2-3). Specifically, the user IF unit 210 of the control unit 21 acquires the current date from the system timer in the reward management server 20.

  And the control part 21 of the reward management server 20 performs the acquisition process of the next billing scheduled date next time (step S2-4). Specifically, the user IF unit 210 of the control unit 21 acquires a calendar record R31 whose current date is included in the input period start to the input period end. In the present embodiment, twice / monthly transfer of “5 days” and “28 days” is performed, so that it is possible to acquire twice (next time, next time) scheduled billing dates.

  Next, the control part 21 of the reward management server 20 executes the acquisition process of the next input deadline next time (step S2-5). Specifically, the user IF unit 210 of the control unit 21 acquires the end of the input period recorded in the acquired next and subsequent calendar record R31, and sets each input period end as the next and next input deadline. .

  Next, the control unit 21 of the reward management server 20 executes menu screen data generation processing (step S2-6). Specifically, the user IF unit 210 of the control unit 21 acquires data related to the previous login date and time from the user master record R22 of this user. Further, the tax accountant office master record R21 is extracted from the tax accountant office master database 221 using the tax accountant office identifier of the user master record R22, and the tax accountant office name is acquired. Then, the user IF unit 210 generates menu screen data in which the next billing scheduled date, the input deadline date, the tax accountant office name, and the previous login date and time are set.

  And the control part 21 of the reward management server 20 performs the transmission process of menu screen data (step S2-7). Specifically, the user IF unit 210 of the control unit 21 transmits menu screen data to the user terminal 10 via the Internet.

The user terminal 10 that has received the menu screen data executes menu screen output processing (step S2-8). In this case, a menu screen 500 shown in FIG. 15 is displayed on the display of the user terminal 10. In the upper column of the menu screen 500, the name of the tax accountant office and the previous login date and time are displayed. This last login date can be used for security confirmation.

  Further, the menu screen 500 includes a participant registration content confirmation change column 501, a billing / payment input / confirmation column 502, a new participant registration column 503, various material creation columns 504, a common item setting column 505, and a system management input column 506. Is provided. Further, the menu screen 500 includes an input deadline display field 507 and an information posting field 508.

  In this participation destination registration content confirmation change column 501, "basic information", "transfer account", "billing amount input", "reward ledger", "repayment ledger", "participant list", "participant search" The selection icon is displayed. When the selection icons of “Basic Information”, “Transfer Account”, “Billing Amount Input”, “Reward Ledger”, “Reimbursement Ledger”, and “Participant Search” are selected, the “Participant Search” screen is output. The On this “Participant Search” screen, set the conditions (participant identifier, participant name, etc.) for identifying the participant, narrow down the participant, and the registration details (basic information, transfer account, billing) for each participant. It is possible to confirm and change the amount input, remuneration ledger and advance payment ledger). Further, by selecting the “participant list” selection icon, it is possible to display the “participant list” screen and narrow down the parties involved.

The billing / payment input / confirmation field 502 includes a “billing schedule input” field, a “billing confirmation / transfer result confirmation” field, and a “accrual receivable confirmation / payment application” field.
In the “Billing schedule input” field, a billing amount can be input for each participant.

In the “confirm bill confirmation / transfer result” column, the transfer result can be confirmed for each participant.
In the “Confirmation of receivables / payment application” column, it is possible to confirm the untransferable portion, the transfer stop portion, and the unused portion from the list of unpaid balances. Then, it is possible to perform the payment cancellation for the deposit other than the account transfer such as the cash collection and the transfer deposit. Furthermore, it is automatically recorded in the compensation ledger.

In the new participation destination registration field 503, the new participation destination can be registered by inputting the basic information to the account information in order.
In the various material creation column 504, various management materials can be obtained. For example, “Billing details”, “Deposit details”, and “Monthly summary table” can be downloaded in CSV format. Further, in the “transfer amount calculation statement”, it is possible to confirm the amount to be transferred after a predetermined business day (for example, 9 business days) of the transfer date. In addition, an address label or “payment record” for the participating party can be printed, and “dealing” and “payment of compensation etc.” can be output for explanation to the participating party.

In the common item setting field 505, “consumption tax” fraction processing, “withholding tax” handling, the closing date of the office, and a summary display in the bankbook of the participating party can be set.
In the system management input field 506, user level setting, password setting, and the like can be performed.

The input deadline display field 507 displays the annual schedule and the input deadline date.
In the notice posting column 508, various notices from the reward management server 20 are posted. For example, server maintenance, server emergency stop, campaigns, news topics, etc. are posted.

(Billing schedule list creation process)
Next, the billing schedule list process will be described with reference to FIG.
The control unit 21 of the reward management server 20 executes transfer date information acquisition processing (step S3-1). Specifically, on the menu screen 500 displayed on the display of the user terminal 10, the transfer date in the “billing schedule input” field of the billing / payment input / confirmation field 502 is selected. In this case, the user terminal 10 transmits a billing schedule input request to the reward management server 20. This billing schedule input request includes data relating to the selected transfer date. Accordingly, the billing input processing unit 212 of the control unit 21 that has received the billing schedule input request acquires the date and date of transfer to be processed.

  And the control part 21 of the reward management server 20 performs the specific process of a participating party (step S3-2). Specifically, the billing input processing unit 212 of the control unit 21 obtains from the participating master database 223 the participating master record R23 including the tax accountant office identifier that has performed user authentication. And the participating party identifier of the participating party of this tax accountant office is acquired by the participating party master record R23. Then, the involved identifiers to be repeatedly processed are sequentially identified and the following processing is executed.

  First, the control unit 21 of the reward management server 20 executes a display setting process for billing information (step S3-3). Specifically, the charge input processing means 212 of the control unit 21 records the transfer date and transfer date classification to be processed from the charge database 241 in the transfer date data field and transfer date classification data field for further processing. A billing record R41 in which the target participant identifier is recorded is acquired. Then, the billing input processing unit 212 acquires from the billing statement database 242 the billing statement record R42 (the billing statement record R42 whose transfer date / transfer date classification matches the billing record R41) corresponding to the billing record R41. Amounts related to "Monthly compensation", "Extraordinary compensation", "Monthly advance payment", "Extraordinary advance", and "Retransfer" are listed for each participant based on the data recorded in the billing statement record R42. The billing schedule list (details) screen data 52 is set.

  Next, the control unit 21 of the reward management server 20 executes a display setting process of the extra reward record (Step S3-4). Specifically, the billing input processing means 212 of the control unit 21 is a billing statement record R42 in which the tax accountant office identifier and the involved party identifier are recorded in the billing statement database 242, and 1 in the transfer date data field. Search for records in which the transfer date is set one year ago. Further, the charge input processing means 212 searches the extracted charge detail record R42 for a record in which the “temporary reward” flag is recorded in the charge type data field. When such a billing detail record R42 can be extracted, the control unit 21 of the reward management server 20 displays a display indicating that there is an extraordinary reward record as shown in the billing schedule list 510 of FIG. Display).

  Next, the control unit 21 of the reward management server 20 executes retransfer information display setting processing (step S3-5). Specifically, first, the billing input processing means 212 of the control unit 21 performs a billing detail record in which the transfer date and transfer date classification to be processed are recorded in the actual transfer date data field and the actual transfer date classification data field. R42 is acquired. Next, the billing input processing means 212 searches the bill detail record R42 for a record in which (actual transfer date, actual transfer date category) does not match (transfer date, transfer date category). When such a billing detail record R42 can be extracted, the billing input processing means 212 acquires a billing statement breakdown record R43 corresponding to the billing detail record R42. When a plurality of billing details breakdown records R43 that differ only in branch numbers are obtained, the billing input processing means 212 uses the billing amount recorded in the billing details breakdown record R43 to which the largest branch number is assigned. To calculate the amount of retransfer of accounts receivable.

  Next, the control unit 21 of the reward management server 20 executes a total amount calculation process (step S3-6). Specifically, the billing input processing means 212 of the control unit 21 acquires the billing amount of the billing details breakdown record R43 corresponding to the billing record R41 of the transfer date, and calculates the total amount of the billing amount. The above processing is repeated for each participating party to be processed.

  Then, when the repetitive process is completed for the tax accountant office involved, the control unit 21 of the reward management server 20 executes a billing schedule list output process (step S3-7). Specifically, the billing input processing means 212 of the control unit 21 transmits this billing schedule list screen data to the user terminal 10.

  The billing schedule list 510 shown in FIG. 16 is output to the display of the user terminal 10 that has received the billing schedule list screen data. In the billing schedule list 510, for each participant identifier and each participant name, the amount of monthly payment, extra payment, monthly payment, temporary payment, and receivable retransfer is displayed. The shaded display indicates that there is a previous year's performance for extraordinary compensation. The participation destination identifier is composed of a selectable icon.

(Invoice amount input process)
Next, a procedure for inputting a billing amount for a desired participating party will be described. First, a selection icon of a participant identifier in the billing schedule list 510 is selected. In this case, the user terminal 10 transmits a request input screen request for the involved party to the reward management server 20. The request input screen request includes data related to the selected participant identifier. In this case, the charge amount input process shown in FIG. 12 is executed.

  In this billing amount input process, first, the control unit 21 of the reward management server 20 that has received the billing input screen request executes a destination identification process (step S4-1). Specifically, the billing input processing unit 212 of the control unit 21 identifies the participating party by extracting the participating party identifier included in the billing input screen request acquired via the user IF unit 210.

  Next, the control part 21 of the reward management server 20 performs the acquisition process of the charge information of the selected participating party (step S4-2). Specifically, the billing input processing means 212 of the control unit 21 sets the identified tax accountant office identifier and the involved party identifier from the billing database 241, and the transfer date and transfer date classification to be processed are the transfer date and time. The billing record R41 recorded in the data field and transfer date section data field is acquired. Then, the billing input processing means 212 acquires from the billing statement database 242 the billing statement record R42 in which the billing record R41 has the date of transfer and date of transfer recorded in the date of transfer data field and date of transfer date category data field. .

  And the control part 21 of the reward management server 20 performs the display setting process of a monthly reward (step S4-3). Specifically, the billing input processing means 212 of the control unit 21 acquires a billing detail record R42 in which a “monthly reward” flag is recorded in the billing type data field from the extracted billing detail record R42. Then, the billing input processing means 212 obtains the amount breakdown (amount, consumption tax, withholding tax, deducted amount) for the billing amount (main body amount) recorded in the billing statement record R42, and bills this amount. This is set in the monthly fee setting field of the amount input (monthly) screen data 63.

  Furthermore, the control part 21 of the reward management server 20 executes a display setting process for extra rewards (step S4-4). Specifically, the billing input processing means 212 of the control unit 21 acquires the billing details record R42 in which the “temporary reward” flag is recorded in the billing type data field from the extracted billing details record R42. Then, the billing input processing means 212 obtains the amount breakdown (amount, consumption tax, withholding tax, deducted amount) for the billing amount (main body amount) recorded in the billing statement record R42, and bills this amount. This is set in the temporary reward setting field of the amount input (monthly) screen data 63.

Further, the control unit 21 of the reward management server 20 executes a display setting process for monthly advance payment and extraordinary payment (step S4-5). Specifically, the billing input processing means 212 of the control unit 21 is
From the extracted billing statement record R42, the billing statement record R42 in which the “monthly advance payment” or “temporary advance” flag is recorded in the billing type data field is acquired. Then, the billing input processing means 212 obtains the amount breakdown (amount, consumption tax, withholding tax, deducted amount) for the billing amount (main body amount) recorded in the billing statement record R42, and bills this amount. It is set in the monthly settlement advance setting field and the temporary advance setting field in the amount input (monthly) screen data 63.

  Next, the control unit 21 of the reward management server 20 executes a display setting process for the extra reward record (step S4-6). Specifically, the billing input processing means 212 of the control unit 21 is a billing statement record R42 in which the tax accountant office identifier to be processed and the involved party identifier are recorded in the billing statement database 242, and includes a transfer date data field. Search for records in which the transfer date of one year ago is set. Further, the charge input processing means 212 searches the extracted charge detail record R42 for a record in which the “temporary reward” flag is recorded in the charge type data field. When such a billing detail record R42 can be extracted, the billing input processing means 212 sets a message “billed in same month last year” in the billing amount input (monthly) screen data 63.

  Next, the control unit 21 of the reward management server 20 executes a retransfer information display setting process (step S4-7). Specifically, the billing input processing means 212 of the control unit 21 uses the (detailed transfer date, actual transfer date category) and (transfer date, transfer date category) in the billing statement record R42 acquired in the previous step. Search for records that do not match. When such a billing detail record R42 can be extracted, the billing input processing means 212 acquires a billing statement breakdown record R43 corresponding to the billing detail record R42. When a plurality of billing details breakdown records R43 having only different branch numbers are acquired, the billing input processing unit 212 identifies the billing details breakdown record R43 to which the largest branch number is assigned. Then, using the billing amount recorded in the billing statement breakdown record R 43, the amount of unaccrued retransfer is calculated and set in the billing amount input (monthly) screen data 63.

  Next, the control unit 21 of the reward management server 20 executes a display setting process for the bill total (step S4-8). Specifically, the billing input processing unit 212 of the control unit 21 calculates the total amount of the billing amount using the billing amount recorded in the billing statement record R42 and the billing statement breakdown record R43 acquired in the previous steps. To do. Then, the billing input processing means 212 sets this amount in the total amount display field of the billing amount input (monthly) screen data 63.

  Next, the control part 21 of the reward management server 20 performs the output process of a billing amount input screen (step S4-9). Specifically, the billing input processing means 212 of the control unit 21 transmits billing amount input (monthly) screen data 63 in which each billing information is set to the user terminal 10.

  A billing amount input screen 520 shown in FIG. 17 is output to the display of the user terminal 10 that has received the billing amount input screen data. The billing amount input screen 520 includes a monthly decision remuneration setting field, a special remuneration setting field, a monthly remuneration setting field, a temporary reimbursement setting field, a retransfer display field, and a total amount display field. In addition, the billing amount input screen 520 includes a transfer stop check box used when transfer stop is performed.

Furthermore, a temporary compensation claim result icon is displayed on the charge amount input screen 520. In this icon, link information to the temporary reward achievement list display data is embedded. When this icon is selected, the user terminal 10 transmits a temporary reward result screen request. In this case, the control unit 21 of the remuneration management server 20 extracts from the billing statement database 242 the billing statement record R42 in which the specified tax accountant office identifier and the involved party identifier are set and the same month of the previous year is recorded as the transfer date. . In this billing detail record R42, the record of the extraordinary reward is obtained by specifying the record in which the “temporary reward” flag is recorded in the billing type data field. And the control part 21 of the reward management server 20 produces | generates the temporary reward performance list display data which made this temporary reward performance a list, and transmits to the user terminal 10. FIG. In this case, the special reward performance screen 530 shown in FIG. Using this special reward result screen 530, the special reward request result can be confirmed.

  Then, the user sets a desired billing amount in each setting field of the billing amount input screen 520. In this case, the script embedded in the billing amount input screen 520 calculates the amount breakdown (amount, consumption tax, withholding tax, deduction amount) for the billing amount (main body amount) recorded in each billing detail record R42. To do. Here, the consumption tax amount is calculated by multiplying the main body amount by the consumption tax rate (5/100). The withholding tax amount is calculated by multiplying the main body amount by the withholding tax rate (10/100). Further, the amount of deduction is calculated by multiplying the main body amount by the deduction rate (95/100). Each amount is displayed on the billing amount input screen 520.

  When the registration button on the billing amount input screen 520 is selected, the user terminal 10 transmits a registration request including the data set on the billing amount input screen 520 to the reward management server 20. The registration request includes data relating to the set amount for each line number of the added or changed billing type. If the transfer stop check box is selected, transfer stop information is included in this registration request.

  The control unit 21 of the reward management server 20 that has received the registration request executes a billing input information acquisition / registration process (step S4-10). Specifically, when a new charge is added on the charge amount input screen 520, the charge input processing means 212 of the control unit 21 generates a charge description record R42, and charges Register in the detail database 242. When the billing amount is corrected, the billing input processing unit 212 identifies the billing detail record R42 that has been corrected and corrects the billing amount.

  Further, when transfer stop information is included in the registration request, the billing input processing means 212 records a “transfer stop” flag in the transfer stop section data field of this billing statement record R42.

  Further, the billing input processing means 212 adds / changes each record recorded in the billing database 241 and the billing details database 243 in accordance with the change of the billing detail record R42.

(Billing confirmation process)
Next, the bill confirmation process will be described with reference to FIG. This process is executed when the schedule management means detects that the current date has reached the transfer confirmation date registered in the calendar database 231.

  In the bill confirmation process, first, the control unit 21 of the reward management server 20 executes a bill confirmation information registration process (step S5-1). Specifically, when the current date reaches the transfer confirmation date, the schedule management unit of the control unit 21 outputs a confirmation instruction to the billing confirmation processing unit 213. In this case, the billing confirmation processing unit 213 generates a billing confirmation record R44 using each data of the billing details breakdown record R43 recorded in the billing details breakdown database 243. Then, the billing confirmation processing unit 213 registers each billing confirmation record R44 in the billing confirmation database 244.

Next, the control unit 21 of the reward management server 20 executes a process for acquiring billing information to be transferred (step S5-2). Specifically, the billing confirmation processing unit 213 of the control unit 21 performs the billing details record R42 in which the transfer date section and the transfer date that have reached the transfer confirmation date are recorded in the transfer date section data field and the actual transfer date data field. The billing information to be transferred is specified using.

  And the control part 21 of the reward management server 20 performs the production | generation process of transfer request data (step S5-3). Specifically, the billing confirmation processing unit 213 of the control unit 21 generates an account transfer request message using the billing details breakdown record R43 to be transferred, using the specified billing details record R42. In this case, the billing confirmation processing means 213 sums the billing amount recorded in the billing statement breakdown record R43 for each tax accountant office identifier and the participating identifier. Then, the billing confirmation processing unit 213 acquires the account identifier of each participating party from the participating party master database 223. Then, an account transfer request message for performing transfer to the account of the collection support service provider is generated using each participating account as a withdrawal account. In addition, the account transfer request message includes a tax accountant office identifier and identification information for specifying the involved party.

(Transfer process)
Next, the transfer process will be described with reference to FIG. This process is executed when the schedule management means detects that the current date has reached a predetermined period before the actual transfer date registered in the calendar database 231.

  In this transfer process, first, the control unit 21 of the reward management server 20 executes a transfer request process (step S6-1). Specifically, when the current date reaches a predetermined period before the actual transfer date, the schedule management unit of the control unit 21 outputs a transfer instruction to the account transfer processing unit 214. In this case, the account transfer processing unit 214 transmits the generated account transfer request message to the financial institution server BK via the network.

  And the control part 21 of the reward management server 20 performs the acquisition process of a transfer result (step S6-2). Specifically, the account transfer processing unit 214 of the control unit 21 acquires a transfer result for the transfer request message from the financial institution server BK. This transfer result includes a transfer completion notification and a transfer impossible notification. Using this transfer completion notification or non-transferable notification, it is possible to specify billing identification information (tax accountant office identifier, participating party, actual transfer date, transfer date classification).

  Next, the control unit 21 of the reward management server 20 executes a transfer result registration process (step S6-3). Specifically, the account transfer processing unit 214 of the control unit 21 uses the billing identification information corresponding to the transfer completion notification to identify the billing details breakdown record R43, and sets the deposit amount and receipt date corresponding to the billed amount. Record. Furthermore, the account transfer processing means 214 records a “paid” flag in the deposit application flag data field of the billing details breakdown record R43.

  Further, the account transfer processing unit 214 specifies the charge confirmation record R44 using the charge identification information corresponding to the transfer completion notification, and records the deposit amount and the payment date corresponding to the billed amount. Furthermore, the account transfer processing unit 214 records a “paid” flag in the deposit application flag data field of the billing confirmation record R44.

  Furthermore, the account transfer processing unit 214 specifies the charge record R41 using the charge identification information corresponding to the transfer completion notification, and records “transferred” in the transfer result code data field in the charge record R41.

  On the other hand, when the transfer impossible notification is acquired in the transfer result, the account transfer processing unit 214 of the control unit 21 specifies the billing details breakdown record R43 using the bill identification information corresponding to the transfer impossible notification, Record "non-transferable" in the receivable status data field.

Further, the account transfer processing unit 214 specifies the charge record R41 using the charge identification information corresponding to the transfer impossible notification, and records the acquired transfer impossible flag in the transfer result code data field.

  Next, the control unit 21 of the reward management server 20 executes retransfer registration processing (step S6-4). This process is executed only for a request for which a transfer impossible notification is received. Specifically, the account transfer processing unit 214 of the control unit 21 specifies the billing detail record R42 using the billing identification information corresponding to the non-transferable notification. Here, when there is no record of the transfer date in the previous transfer date data field of this billing statement record R42, the account transfer processing means 214 confirms the retransfer category of the billing record R41. When the “transfer again” flag is recorded in the retransfer category data field, the account transfer processing unit 214 records the current transfer date in the previous transfer date data field of the billing statement record R42, and Record the next transfer date in the actual transfer date data field.

  On the other hand, when the transfer date has already been recorded in the previous transfer date data field and the previous transfer date section data field, the account transfer processing unit 214 performs the previous transfer date data field and the previous transfer in the billing statement record R42. Record the current transfer date and transfer date in the date field.

(Deposit application processing)
Next, with reference to FIG. 14A, a payment application process by depositing by a method other than account transfer will be described.

  First, the control unit 21 of the reward management server 20 executes a deposit information acquisition process (step S7-1). When the user terminal 10 is used to perform the payment application, the “deposit payment application” button in the billing / payment input / confirmation field 502 of the menu screen 500 is selected. In this case, the user terminal 10 transmits a payment application screen request to the reward management server 20.

  The control unit 21 of the reward management server 20 that has received the payment application screen request extracts unpaid information. Specifically, the individual deposit management means 215 of the control unit 21 extracts a record in which the “deposited” flag is not recorded in the deposit application flag data field of the billing details breakdown record R43. Then, the individual deposit management means 215 sets information regarding this record in the deposit application screen data 56 displayed as a list. Here, the individual receipt management means 215 embeds in the receipt application screen data 56 the application target identification information that can individually specify the billing details breakdown record R43 for each account receivable display. Then, the individual deposit management means 215 transmits deposit application screen data 56 to the user terminal 10.

  In this case, a deposit application screen 540 shown in FIG. 19 is output on the display of the user terminal 10. Then, on the payment application screen 540, the payment date, the payment category, and the payment amount are input for the collected bill. When the “Register” button is selected, the user terminal 10 transmits a payment application request to the reward management server 20. This payment application request includes data related to application object identification information, payment date, payment category, and payment amount. Thereby, the reward management server 20 acquires payment information.

And the control part 21 of the reward management server 20 performs the confirmation process of a money_receiving | payment amount (step S7-2). Specifically, the individual deposit management means 215 of the control unit 21 specifies the billing details breakdown record R43 based on the application target identification information. Then, the billing amount recorded in the billing statement breakdown record R43 is compared with the deposit amount included in the deposit application request. Here, when the deposit amount is larger than the billing amount (in the case of “YES” in step S7-2), the control unit 21 of the reward management server executes an error output process (step S7-3). Specifically, the individual deposit management means 215 of the control unit 21 notifies the user terminal 10 that the deposit application cannot be performed, and ends the deposit application process.

  On the other hand, when the deposit amount is equal to or less than the billing amount (in the case of “NO” in step S7-2), the control unit 21 of the reward management server executes a process for recording the consumption information (step S7-4). Specifically, the individual deposit management means 215 of the control unit 21 records a deposit application flag in this billing item breakdown record R43. Here, when the deposit amount and the billing amount match (in the case of “YES” in step S7-5), the control unit 21 of the reward management server ends the deposit application process.

  On the other hand, when the deposit amount is smaller than the billed amount (in the case of “NO” in step S7-5), the control unit 21 of the reward management server 20 executes a difference calculation process (step S7-6). Specifically, the individual deposit management means 215 of the control unit 21 calculates a difference obtained by subtracting the deposit amount from the billed amount. This difference becomes the amount of the account receivable and becomes the amount subject to billing management.

  And the control part 21 of the reward management server 20 performs a new branch number provision process (step S7-7). Specifically, the individual deposit management means 215 of the control unit 21 obtains the maximum branch number recorded in the billing statement breakdown record R43, and adds (increments) “1” to this branch number. Is calculated.

  Next, the control unit 21 of the reward management server 20 executes a new registration process for billing information (step S7-8). Specifically, the individual deposit management means 215 of the control unit 21 newly registers the billing details breakdown record R43 in the billing details breakdown database 243.

(Payment cancellation processing)
Next, with reference to FIG. 14B, a deposit cancellation process for canceling a deposit by a method other than account transfer will be described.

  First, the control unit 21 of the reward management server 20 executes cancellation target information acquisition processing (step S8-1). When the user terminal 10 is used to cancel the deposit, the “reward ledger” button is selected on the screen for each participant in the billing / payment input / confirmation field 502 of the menu screen 500. In this case, the user terminal 10 transmits a reward ledger screen request to the reward management server 20.

  The control unit 21 of the reward management server 20 that has received the reward ledger screen request extracts reward information. Specifically, the individual deposit management means 215 of the control unit 21 extracts the billing details breakdown record R43 using the participation destination identifier. Then, the individual deposit management means 215 sets the information related to this record in the reward ledger management screen data 65 displayed as a list. Here, the individual deposit management means 215 embeds cancellation target identification information that can individually identify the billing details breakdown record R43 in each reward display in the reward ledger management screen data 65. Furthermore, data for displaying a cancel button is embedded in the reward received by a method other than account transfer. Then, the individual deposit management unit 215 transmits the reward ledger management screen data 65 to the user terminal 10.

  In this case, a reward ledger screen 550 shown in FIG. 20 is output on the display of the user terminal 10. When the “Cancel” button is selected for a desired item on the reward ledger screen 550, the user terminal 10 transmits a payment cancellation request to the reward management server 20. This payment cancellation request includes cancellation target identification information. Thereby, the reward management server 20 acquires cancellation object information.

The control unit 21 of the reward management server 20 that has received the payment cancellation request executes an addition process to the record of the maximum branch number (step S8-2). Specifically, the individual deposit management means 215 of the control unit 21 specifies the cancellation details of the billing details breakdown record R43 to be canceled using the cancellation target identification information included in the payment cancellation request. Then, the individual deposit management means 215 selects the billing details breakdown record R43 to which the largest branch number is assigned among the billing details breakdown records R43 to which the same participant identifier, transfer date, billing type and line number are assigned. Identify. Then, the individual deposit management means 215 adds the billing amount of the billing item breakdown record R43 to be canceled to the billing amount of the billing item breakdown record R43.

  And the control part 21 of the reward management server 20 performs the deletion process of the cancellation | release target record (step S8-3). Specifically, the individual deposit management means 215 of the control unit 21 deletes the billing breakdown item record R43 to be canceled.

As described above, according to the present embodiment, the following effects can be obtained.
-In the said embodiment, the participating master database 223 has recorded the participating master record R23 about the business partner (participating party) of a tax accountant office. The participating master record R23 includes data relating to the use of the custodian for the tax accountant office identifier and the participating identifier. In the present embodiment, a flag that specifies either “use of mouth vibration” or “not use mouth vibration” is recorded. Thereby, the reward management server 20 can identify the participating party that collects money by account transfer and the participating party that the tax accountant office itself collects money. Accordingly, the remuneration management server 20 can collectively manage billing for the involved parties regardless of whether or not account transfer is used.

  In the above embodiment, the participating master record R23 includes data related to the sales recording month for the tax accountant office identifier and the participating identifier. In the sales recording month data field, data relating to a month in which sales are recorded for the billing of the related party is recorded. And the control part 21 of the reward management server 20 performs the registration process of a billing month (step S1-6). Specifically, the billing information registration unit 211 of the control unit 21 specifies the billing date based on the transfer date and the sales recording month. This makes it possible to set the sales recording month and manage the sales using the billing date regardless of the transfer date and the actual payment date according to the agreement between the involved party and the tax accountant office.

  -In above-mentioned embodiment, the participating master record R23 is comprised including the data regarding a claim classification with respect to a tax accountant office identifier and a participating identifier. In this billing category data field, a flag for identifying “monthly billing” or “anytime billing” is recorded. Thus, it can be used for monthly billing and monthly billing whenever necessary. Then, when the transfer date to be processed does not correspond to the billing month (in the case of “NO” in step S1-7), the control unit 21 of the reward management server 20 ends the process for the participating master record R23. . On the other hand, when the transfer date to be processed corresponds to the billing month (“YES” in step S1-7), the control unit 21 of the reward management server 20 executes a billing information registration process (step S1-). 8). This makes it possible to make a request at an appropriate time according to the agreement between the involved party and the tax accountant office.

  In the above embodiment, in the monthly reward management process in the billing information management process, the control unit 21 of the reward management server 20 executes a billing information registration process (step S1-3). At this time, the control unit 21 of the reward management server 20 executes a process for searching for monthly fixed reward information for the previous month (step S1-4). Since the monthly fee is not much changed every month, it is possible to efficiently set a bill by setting the amount for the previous month as an initial value.

In the above embodiment, the control unit 21 of the reward management server 20 executes the display setting process for the extra reward record (steps S3-4 and S4-6). Unlike monthly payments, extraordinary rewards differ in amount depending on the time, but by displaying actual results, it is possible to accurately set extraordinary rewards by referring to past results.

  In the above embodiment, when the deposit amount is smaller than the billing amount in the deposit application process, the control unit 21 of the reward management server 20 calculates the difference (step S7-6) and assigns a new branch number. (Step S7-7). And the control part 21 of the reward management server 20 performs the new registration process of claim information (step S7-8). As a result, when a part of the billing amount is collected, it is possible to manage the remaining balance.

  -In above-mentioned embodiment, the control part 21 of the reward management server 20 which received the payment cancellation | release request performs the addition process to the record of the largest branch number (step S8-2), and performs the deletion process of the cancellation | release target record (Step S8-3). As a result, the receivable can be managed by the maximum branch number while the divided deposit is managed by the branch number.

In addition, you may change the said embodiment into the following aspects.
In the above embodiment, the reward management server 20 is provided in the tax accountant reward collection service, but the service target is not limited to this.

  In the above embodiment, the billing record R41 to the billing details breakdown record R43 are generated by the billing information management process at the billing data generation time. The generation timing of these records is not limited to this. For example, it may be configured to generate when a user logs in or when a billing schedule input request is made.

  The billing record R41 to the billing statement breakdown record R43 may be generated when a registration request is made using the billing amount input screen. In this case, steps S1-1 to S1-5 are executed at the time of the billing schedule list creation process or when the billing input screen is output.

  In the above-described embodiment, the billing data storage unit 24 stores the billing records separately in the billing database 241, the billing details database 242, the billing details breakdown database 243, and the billing confirmation database 244. The data structure is not limited to this, and can be realized using one database.

  In the above embodiment, in the payment application process, using the payment application screen 540 output on the display of the user terminal 10, the payment date, the payment category, and the payment amount collected by a method other than account transfer are input. Instead, it may be configured to use the deposit information transferred to a predetermined account (for example, an account of a tax accountant office) to perform the application. In this case, the control unit 21 of the reward management server 20 assigns a consumption identifier that can individually identify each claim and records it in the billing information storage unit. Then, an application identifier is notified to the tax accountant office involved in each request.

  Here, when the involved party makes a transfer to the account of the tax accountant office, this application identifier is added to the transfer request message. Then, when the user terminal 10 of the tax accountant office obtains the deposit information for the account from the financial institution server BK using the farm banking service or the like, the application identifier that is being charged is obtained from the reward management server 20. Then, the user terminal 10 searches for the presence or absence of the application identifier in the payment information. When detecting the application identifier notified to the participating party, the user terminal 10 manages the payment information associated with the application identifier (information such as payment date, transfer as payment category, payment amount, etc.) as reward management. Send to server 20. The control unit 21 of the reward management server 20 executes the processes after step S7-1.

Moreover, the account of the provider of the money collection support service can be used as a transfer account.
In this case, the control unit 21 of the reward management server 20 acquires the deposit information for the account from the financial institution server BK using a farm banking service or the like, and searches the deposit information for the presence or absence of the application identifier. Then, billing information corresponding to the consumption identifier is specified, and the processes after step S7-2 are executed.

  Thereby, it is possible to collect money using a transfer. Since the payment application is executed by the user terminal 10 or the control unit 21 of the reward management server 20, the payment application can be executed while suppressing an increase in the burden on the user.

The system schematic of embodiment of this invention. Explanatory drawing of the functional block of the user IF means of this invention. Explanatory drawing of the screen flow of each screen data recorded on the screen data storage part. It is explanatory drawing of the data recorded on the master data storage part, Comprising: (a) is the data recorded on the tax accountant office master database, (b) is explanatory drawing of the data recorded on the user master database. It is explanatory drawing of the data recorded on the master data storage part, Comprising: Explanatory drawing of the data recorded on the participating master database. It is explanatory drawing of the data recorded on the claim data storage part, Comprising: (a) is the data recorded on the claim database, (b) is explanatory drawing of the data recorded on the claim details database. It is explanatory drawing of the data recorded on the claim data storage part, Comprising: (a) is the data recorded on the claim details breakdown database, (b) is explanatory drawing of the data recorded on the claim confirmation database. Explanatory drawing of the calendar database recorded on the calendar data storage part. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of this embodiment. It is explanatory drawing of the process sequence of this embodiment, Comprising: (a) The process sequence of a bill confirmation process, (b) is explanatory drawing of the process sequence of a transfer process. It is explanatory drawing of the process sequence of this embodiment, Comprising: (a) The process procedure of a payment cancellation process, (b) is explanatory drawing of the process sequence of a payment cancellation process. An explanatory view of a display screen outputted on a display of a user terminal. Explanatory drawing of the display screen output on the display of a user terminal. Explanatory drawing of the display screen output on the display of a user terminal. Explanatory drawing of the display screen output on the display of a user terminal. Explanatory drawing of the display screen output on the display of a user terminal. Explanatory drawing of the display screen output on the display of a user terminal.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... User terminal, 20 ... Remuneration management server, 21 ... Control part, 210 ... User IF means, 211 ... Claim information registration means, 212 ... Claim input processing means, 213 ... Claim confirmation processing means, 214 ... Account transfer processing means, 215 ... Individual deposit management means, 210a ... Screen request acquisition means, 210b ... Screen output means, 210c ... Input information acquisition means, 210e ... Screen development order memory, 210f ... Temporary input memory, 22 ... Master data storage section, 23 ... Calendar Data storage unit, 24 ... billing data storage unit, 221 ... tax accountant office master database, 222 ... user master database, 223 ... participating master database, 231 ... calendar database, 241 ... billing database, 242 ... billing details database, 243 ... Billing statement breakdown database, 244 ... Billing confirmation Database, 510 ... according to schedule list, 520 ... invoice amount input screen, 530 ... extraordinary reward achievement screen, 540 ... payment Clearing screen, 550 ... reward ledger screen.

Claims (6)

For the user identifier and the customer identifier, account information, customer information storage means for recording customer information including a transfer usage flag for determining whether or not to use account transfer,
A calendar information storage means for recording calendar information including information about the transfer date and the scheduled transfer date;
Billing information storage means for recording billing information from the user to the supplier for each scheduled transfer date;
A collection support system comprising a control means connected to a user terminal via a network and performing billing management,
The control means is
User authentication means for obtaining a user identifier from a user terminal that has been accessed;
When obtaining a billing supplier identifier from the user terminal, generate a billing amount input screen associated with the user identifier and the supplier identifier, and transmit to the user terminal,
When the charge amount input on the charge amount input screen is acquired, the transfer usage flag corresponding to the acquired charge amount and the supplier identifier is recorded in the charge information storage unit in association with the user identifier and the supplier identifier. Billing registration processing means to
Based on the scheduled transfer date recorded in the calendar information storage unit, the input of the billing amount is confirmed, the billing information in which the transfer usage flag is recorded is obtained from the billing information storage unit, and the supplier identifier of this billing information A collection support system comprising: bill processing means for acquiring account information recorded in the supplier information storage means, generating a transfer request message, and executing transfer request processing. The control means further comprises means for recording transfer stop information in association with the user identifier and supplier identifier in the billing information storage means when receiving a transfer stop request for stopping transfer from the user terminal,
2. The money collection support system according to claim 1, wherein the billing processing unit does not include the billing information in which the transfer stop information is recorded in the transfer request message. In the supplier information of the supplier information storage means, a retransfer category for determining whether or not retransfer is possible is further recorded,
The claim processing means acquires a transfer result corresponding to the transfer request message, records a transfer result corresponding to a user identifier and a business partner identifier in the claim information storage means,
If the transfer result includes non-transferable in the transfer result, the non-transferable business partner identifier is specified, and the retransferable category that enables retransfer is recorded in the business partner information. Is registered as billing information in the next transfer request process. 3. The money collection support system according to claim 1 or 2, In the supplier information of the supplier information storage means, sales record month calculation information for specifying the sales record month for the transfer date is further recorded,
The billing registration processing means calculates the billing month using the sales record month calculation information recorded in the supplier information storage means for each billing information for the transfer date for executing the transfer request process, The money collection support system according to any one of claims 1 to 3, wherein the collection information is recorded by being included in the billing information. For the user identifier and the customer identifier, account information, customer information storage means for recording customer information including a transfer usage flag for determining whether or not to use account transfer,
A calendar information storage means for recording calendar information including information about the transfer date and the scheduled transfer date;
Billing information storage means for recording billing information from the user to the supplier for each scheduled transfer date;
A method for executing a collection support process using a collection support system that is connected to a user terminal via a network and includes a control unit that performs billing management,
The control means is
A user authentication stage for obtaining a user identifier from a user terminal that has been accessed;
When obtaining a billing supplier identifier from the user terminal, generate a billing amount input screen associated with the user identifier and the supplier identifier, and transmit to the user terminal,
When the charge amount input on the charge amount input screen is acquired, the transfer usage flag corresponding to the acquired charge amount and the supplier identifier is recorded in the charge information storage unit in association with the user identifier and the supplier identifier. A billing registration processing stage to
Based on the scheduled transfer date recorded in the calendar information storage unit, the input of the billing amount is confirmed, the billing information in which the transfer usage flag is recorded is obtained from the billing information storage unit, and the supplier identifier of this billing information A billing support method comprising: performing billing processing steps of acquiring account information recorded in the supplier information storage means, generating a transfer request message, and executing a transfer request process. For the user identifier and the customer identifier, account information, customer information storage means for recording customer information including a transfer usage flag for determining whether or not to use account transfer,
A calendar information storage means for recording calendar information including information about the transfer date and the scheduled transfer date;
Billing information storage means for recording billing information from the user to the supplier for each scheduled transfer date;
A program for executing a collection support process using a collection support system connected to a user terminal via a network and having a control means for performing billing management,
The control means;
User authentication means for obtaining a user identifier from a user terminal that has been accessed;
When obtaining a billing supplier identifier from the user terminal, generate a billing amount input screen associated with the user identifier and the supplier identifier, and transmit to the user terminal,
When the charge amount input on the charge amount input screen is acquired, the transfer usage flag corresponding to the acquired charge amount and the supplier identifier is recorded in the charge information storage unit in association with the user identifier and the supplier identifier. Billing registration processing means to
Based on the scheduled transfer date recorded in the calendar information storage unit, the input of the billing amount is confirmed, the billing information in which the transfer usage flag is recorded is obtained from the billing information storage unit, and the supplier identifier of this billing information A collection support program that functions as a billing processing unit that acquires account information recorded in the supplier information storage unit, generates a transfer request message, and executes a transfer request process.

Images