Proposal server, communication system, providing method, and program

Abstract

To solve the problem in which: in the world of commercial transactions, factoring that is a method for turning accounts receivable generated from transactions into cash early to raise funds is frequently used; however, funding service company for factoring (fund-raising destinations) have different fees, and in the first place, some companies do not receive an application from a privately-run store; and therefore, a user has difficulty in finding out a fund-raising destination that meets a condition assumed by the user.SOLUTION: A proposal server 3 informs a user terminal 1 of a specific fund-raising destination that conducts fund-raising meeting a predetermined condition demanded by a service using company A, thereby allowing the service using company A to easily find out a fund-raising destination that meets a condition assumed by the company.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to a proposal server, a communication system, a providing method, and a program. [Background technology]

[0002] In the world of commercial transactions, factoring is a method of quickly converting accounts receivable arising from transactions into cash and raising funds. For example, Patent Document 1 discloses a method of quickly purchasing accounts receivable while reducing the manual administrative burden by implementing the procedures for purchasing accounts receivable through factoring using a computer system. Summary of the Invention [Problem to be solved by the invention]

[0003] However, depending on the financing service provider (funding source) such as factoring, there are various companies with different fees, some of which do not even accept applications from individual stores. Therefore, users have a problem in that it is difficult to find a funding source that meets the conditions they expect. [Means for solving the problem]

[0004] The invention according to claim 1 is a proposal server that provides information via a communication network to a user terminal of a user of a transaction that provides or is to provide a product or service to a trading partner, and raises funds based on the transaction from the user terminal. Target Type Funding for Target Type Information and Priority regarding risk aversion that prioritizes the creditworthiness of the said business partner A receiving means for receiving conditions, and a fund raising means for receiving the conditions from a plurality of fund raising sources. Target Type a means for determining a corresponding source of financing; a generating means for generating recommendation candidate information to be candidates for recommendation information to be provided to the user terminal based on a result of the judgment by the judging means; The above The recommendation candidate information created by the creating means is rearranged as recommendation information according to the priority conditions. A sending means for sending screen information to the user terminal. Effect of the Invention

[0005] As described above, according to the present invention, the proposal server communicates to the user terminal specific fund-raising sources that provide funds that meet the specified conditions required by the user, thereby eliminating the problem that it is difficult for users to find fund-raising sources that meet the conditions they expect. [Brief description of the drawings]

[0006] [Figure 1] FIG. 2 is a diagram showing the relationships between companies according to the present embodiment. [Diagram 2] 1 is a schematic diagram of a communication system according to an embodiment; [Diagram 3] FIG. 2 is a hardware configuration diagram of a user terminal, a proposal server, a fund providing service server, and a sewage information server in this embodiment. [Figure 4] FIG. 2 is a functional block diagram of the communication system according to the embodiment. [Diagram 5] FIG. 13 is a conceptual diagram of a tenant regular expense history table. [Figure 6] FIG. 13 is a conceptual diagram of a tenant individual payment management table. [Figure 7] FIG. 13 is a conceptual diagram of a fund raising information management table. [Figure 8] FIG. 13 is a conceptual diagram of a tenant bank account information table. [Figure 9] FIG. 13 is a conceptual diagram of a tenant credit card information management table. [Figure 10] FIG. 2 is a conceptual diagram of a tenant management table. [Figure 11] FIG. 13 is a conceptual diagram of a fund providing service type management table. [Figure 12] FIG. 13 is a conceptual diagram of a funding service management table. [Figure 13] FIG. 4 is a conceptual diagram of a destination information management table. [Figure 14] FIG. 13 is a conceptual diagram of a credit information adjustment management table. [Figure 15] FIG. 13 is a conceptual diagram of a credit information management table. [Figure 16] FIG. 13 is a conceptual diagram of a recommended candidate information management table. [Figure 17] FIG. 13 is a sequence diagram showing a process for displaying a cash flow screen. [Figure 18] 13 is a flowchart showing a process for creating a cash flow screen. [Figure 19] FIG. 13 is a diagram showing an example of a financial management screen display. [Figure 20] FIG. 11 is a sequence diagram showing a display process of a recommendation screen. [Figure 21] 13 is a flowchart showing a process of narrowing down recommended information. [Figure 22] 11 is a flowchart showing a preparation process. [Diagram 23] 11 is a flowchart showing a process of creating recommendation candidate information. [Figure 24] FIG. 13 is a diagram showing an example of a recommendation screen displayed when priority is given to commission. [Diagram 25] FIG. 13 is a diagram showing an example of a recommended screen after the display has been changed in the case of prioritizing commission. [Figure 26] FIG. 13 is a diagram showing an example of a display of a recommendation screen in the case where priority is given to risk avoidance. [Figure 27] FIG. 13 shows an example of a redisplayed cash flow screen. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] [Inter-company relationships] The relationships between the companies will be described with reference to Figure 1. Figure 1 is a diagram showing the relationships between the companies according to this embodiment.

[0008] As shown in Figure 1, service user company A is a company that uses the service to receive proposals for recommended fundraising sources from proposing company C. Client company B is a client of service user company A. In this case, a relationship may arise in which service user company A is the creditor and client company B is the debtor. Proposing company C is a company that provides the above service to service user company A.

[0009] In addition, factoring service company D, accounts receivable secured loan service company E, PO finance service Company F and quotation finance service company G are companies that provide services with the same names, and both are funding service companies. From the perspective of service user company A, the funding service companies are the sources of funding.

[0010] Factoring service company D is a collective term for multiple factoring service companies D1, D2, ... Dn. Accounts receivable secured loan service company E is a collective term for multiple accounts receivable secured loan service companies E1, E2, ... En. PO Finance service Company F has multiple PO financing service A generic term for companies F1, F2, ..., Fn. Quotation finance service company G is a generic term for quotation finance service companies G1, G2, ..., Gn.

[0011] Credit information service company H is a company that holds credit information that indicates the reliability of management of business partners and other companies, and provides credit information to proposing company C. Note that credit information service company H is a collective term for credit information service companies H1, H2, ... Hn.

[0012] Here, an outline of the processing in this embodiment will be described.

[0013] First, service user company A provides or plans to provide products or services to business partner company B, which generates accounts receivable (S1). Then, service user company A informs proposing company C of its desired specified conditions (priority on commission rate, priority on risk avoidance) in order to have multiple fundraising sources propose a source that meets its conditions (S2). Proposing company C then obtains credit information on business partner company B from credit information service company H, and makes a comprehensive judgment based on this credit information, the contents of the forms, the specified conditions from service user company A, etc., and proposes a specific recommended fundraising source to service user company A (S3).

[0014] As a result, service user company A applies for funding by sending a document to the proposed specific fund-raising source (funding service company) (S4). In response, the specific fund-raising service company provides funding to service user company A after screening (S5). Furthermore, the specific fund-raising service company bills trading partner company B for accounts receivable corresponding to accounts receivable, etc. (S6). As a result, trading partner company B pays the accounts receivable to the specific fund-raising service company on time (S7).

[0015] [Outline of the communication system] Fig. 2 is a schematic diagram of the communication system of this embodiment, showing terminals or servers of each company in Fig. 1.

[0016] User company A has a PC ( P ersonal C A user terminal 1 such as a personal computer is installed and operated by a user A1. A proposal server 3 is installed in the proposal company C. In addition, a factoring service company D, an accounts receivable secured loan service company E, a PO finance company F, and a factoring service company G are also installed. service Company F and quotation finance service company G are each provided with funding service servers 5d, 5e, 5f, and 5g. Credit information service company H is provided with a credit information server 7. Each server is constructed of a computer. The user terminal 1, the funding service servers 5d, 5e, 5f, and 5g, and the credit information server 7 can communicate with each other via a communication network 100 such as the Internet. Hereinafter, the funding service servers 5d, 5e, 5f, and 5g will be collectively referred to as the "funding service server 5."

[0017] [Hardware configuration of communication system] Next, the hardware configuration of each terminal and server constituting the communication system shown in Fig. 1 will be described with reference to Fig. 3. Since all of them have the same configuration, the hardware configuration of the user terminal 1 will be described and the description of the hardware configuration of each server will be omitted.

[0018] As shown in FIG. 3, user A1 is configured with a computer and has a CPU 101, ROM 102, RAM 103, HD 104, HDD (Hard Disk Drive) controller 105, display 106, external device connection I / F (Interface) 108, network I / F 109, bus line 110, keyboard 111, pointing device 112, DVD-RW (Digital Versatile Disk Rewritable) drive 114, and media I / F 116.

[0019] Among these, the CPU 101 controls the operation of the entire computer. The ROM 102 stores programs such as IPL used to drive the CPU 101. The RAM 103 is used as a work area for the CPU 101. The HD 104 stores various data such as programs. The HDD controller 105 controls reading and writing of various data from and to the HD 104 under the control of the CPU 101. The display 106 displays various information such as a cursor, a menu, a window, a character, or an image. The external device connection I / F 108 is an interface for connecting various external devices. In this case, the external device is, for example, a USB (Universal Serial Bus) memory or a printer. The network I / F 109 is an interface for data communication using the communication network 100. The bus line 110 is an address bus, a data bus, or the like for electrically connecting each component such as the CPU 101 shown in FIG. 3.

[0020] The keyboard 111 is a type of input means having multiple keys for inputting characters, numbers, various instructions, etc. The pointing device 112 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. The DVD-RW drive 114 controls reading and writing of various data from a DVD-RW 113, which is an example of a removable recording medium. Note that the input is not limited to DVD-RW, and can be DVD-R or Blu-ray (Registered Trademark)A media I / F 116 controls reading and writing (storing) data from and to a recording medium 115 such as a flash memory.

[0021] Furthermore, a microphone as an example of a sound collection device, a speaker as an example of a sound output device, and a camera as an example of an imaging device can be connected to the external device connection I / F.

[0022] [Functional configuration of the communication system] Next, the functional configuration of the communication system of this embodiment will be described with reference to Figures 3 to 16. Figure 4 is a functional block diagram of the communication system of this embodiment. Note that the fund provision service server 5 and the credit information server 7 do not have any new functions in the communication process of this embodiment, so their description will be omitted.

[0023] <Functional configuration of user terminal> First, the functional configuration of the user terminal 1 will be described with reference to Figures 3 and 4. As shown in Figure 4, the user terminal 1 has a transmission / reception unit 11, a reception unit 12, a display control unit 14, a judgment unit 15, and a storage / readout processing unit 19. Each of these units is a function or a means for performing a function that is realized when any of the components shown in Figure 3 operates in response to an instruction from the CPU 101 in accordance with a program loaded from the HD 104 onto the RAM 103. The user terminal 1 also has a storage unit 1000 constructed by the RAM 103 and the HD 104 shown in Figure 3.

[0024] (Functional configuration of user terminal) Next, we will explain each component of the user terminal 1. The transmission / reception unit 11 is realized by commands from the CPU 101 shown in Fig. 3, the external device connection I / F 108, and the network I / F 109, and transmits and receives various data (or information) to and from other terminals, devices, or systems via the communication network 100.

[0025] The reception unit 12 is realized mainly by commands from the CPU 101 shown in FIG. 3, as well as the keyboard 111, the pointing device 112, the operation buttons, and the power switch, and receives various inputs from the user.

[0026] The display control unit 14 is mainly realized by instructions from the CPU 101 shown in Fig. 3, and displays an image by outputting image data to the display 106 or an external display connected to the external device connection I / F. The display control unit 14 has a Web browser function.

[0027] The determination unit 15 is mainly realized by instructions from the CPU 101 shown in FIG. 3, and performs various determinations.

[0028] The storage / read processing unit 19 is mainly executed by instructions from the CPU 101 shown in FIG. 3 and the HDD controller 105, and performs processes such as storing various data in the memory unit 1000 and reading out various data stored in the memory unit 1000.

[0029] <Functional configuration of the proposed server> Next, the functional configuration of the proposal server 3 will be described with reference to Fig. 3 to Fig. 16. As shown in Fig. 4, the proposal server 3 has a transmission / reception unit 31, a calculation unit 33, a determination unit 35, a creation unit 36, and a storage / readout processing unit 39. Each of these units is a function or a means for performing a function that is realized when any of the components shown in Fig. 3 operates according to an instruction from the CPU 101 in accordance with a program loaded from the HD 104 onto the RAM 103. The proposal server 3 also has a storage unit 3000 constructed by the RAM 103 and the HD 104 shown in Fig. 3.

[0030] (Tenant regular expense history management table) Fig. 5 is a conceptual diagram showing a tenant regular expense history management table. A tenant regular expense management DB 3001 composed of a tenant regular expense history management table as shown in Fig. 5 is constructed in the memory unit 3000. In this table, the past expenditure type, expenditure month, and amount for which regular payments occurred are associated and managed for each tenant ID for identifying a service using company (tenant) that receives services from proposing company C. Future regular payments are predicted based on this table.

[0031] (Tenant individual payment management table) Fig. 6 is a conceptual diagram showing a tenant individual payment management table. A tenant regular expense management DB 3001 consisting of a tenant regular expense history management table as shown in Fig. 6 is constructed in the memory unit 3000. In this table, each piece of information on the ID, billing source, payment due date, amount, and payment status is managed in association with each other as tenant payment information for each tenant ID.

[0032] (Funding information management table) Fig. 7 is a conceptual diagram showing a fund raising information management table. A fund raising information management DB 3003 consisting of a fund raising information management table as shown in Fig. 7 is constructed in the storage unit 3000. This table shows the contents of forms used for fund raising. Therefore, in this table, for each tenant ID, information such as ID, business partner, fund raising object type, payment deadline, amount, and payment status, as well as the storage destination of the form image digitized to PDF or the like, are associated and managed. The fund raising object types include invoices, purchase orders, and estimates.

[0033] (Tenant Bank Account Table) Fig. 8 is a conceptual diagram showing a tenant bank account management table. A tenant bank account management DB 3004 consisting of a tenant bank account management table as shown in Fig. 8 is constructed in the memory unit 3000. This table shows the contents of the user's own bank account that the user has registered in advance in the proposal server 3. Therefore, in this table, the bank name, branch name, account number, user name, and password are associated and managed for each tenant ID.

[0034] (Tenant credit card information management table) Fig. 9 is a conceptual diagram showing a tenant credit card information management table. A tenant credit card management DB 3005 consisting of a tenant credit card information management table as shown in Fig. 9 is constructed in the memory unit 3000. This table shows information related to the user's own credit card that the user has registered in advance in the proposal server 3. Therefore, this table manages the card name (card number), user name, and password in association with each tenant ID. The amount that can be borrowed based on this information is used later as a cash balance.

[0035] (Tenant management table) Fig. 10 is a conceptual diagram showing a tenant management table. A tenant management DB 3006 configured by a tenant management table as shown in Fig. 10 is constructed in the memory unit 3000. This table shows contents related to the company information of the tenant. Therefore, in this table, the tenant ID, the tenant name, the tenant address (location), the tenant industry, and the tenant business type are associated and managed. This information is used, for example, when the tenant is in the construction industry, when fund provision service companies that do not provide funds to the construction industry are excluded from the selection targets.

[0036] (Funding service type management table) Fig. 11 is a conceptual diagram showing a funded service type management table. A funded service type management DB 3007 configured by a funded service type management table as shown in Fig. 11 is constructed in the memory unit 3000. In this table, funded object types and funded service types (procurement types) are managed in association with each other.

[0037] (Funding Service Management Table) Fig. 12 is a conceptual diagram showing a funding service management table. A funding service management DB 3008 consisting of a funding service management table as shown in Fig. 12 is constructed in the memory unit 3000. In this table, the funding service type, funding service name (company name), non-supported industries, supported areas for funding, funding support for personal businesses, supported amount conditions for funding, and the connection URL (destination information) to the funding service server 5 of the funding service company are managed in association with each other. Note that if funding support for personal businesses is "false", the funding service company provides funding to companies but does not provide funding to individuals.

[0038] (Destination information management table) Fig. 13 is a conceptual diagram showing a destination information management table. A destination information management DB 3009 configured by a destination information management table as shown in Fig. 13 is constructed in the storage unit 3000. In this table, a destination name (company name) for acquiring information and a connection URL (destination information) are associated and managed for each type of information.

[0039] (Credit information adjustment management table) Fig. 14 is a conceptual diagram showing a credit information adjustment management table. A credit information adjustment management DB 3010 consisting of a credit information adjustment management table as shown in Fig. 14 is constructed in the memory unit 3000. In this table, the credit provided by each credit information service company is associated with each credit rating and managed. Since the credit rating levels set by each credit information service company are different, this table is used to adjust and unify them.

[0040] (Credit information management table) Fig. 15 is a conceptual diagram showing a credit information management table. A credit information management DB 3011 configured by the credit information management table shown in Fig. 15 is constructed in the memory unit 3000. In this table, the creditworthiness adjusted in the credit information management table of Fig. 15 is managed in association with each trading partner.

[0041] (Recommended candidate information management table) Fig. 16 is a conceptual diagram showing a recommended candidate information management table. A recommended candidate information management DB 3012 configured by a recommended candidate information management table as shown in Fig. 16 is constructed in the storage unit 3000. This table shows recommended candidate information including the contents of the form used for fund raising. Therefore, this table manages in association with the business partner, the business partner's creditworthiness, the transaction amount shown in the form, the type of fund raising target, the fund providing service type (procurement type), the name of the fund providing service (company name), the commission rate for fund raising, and the date of deposit to the service using company when funding is provided. Note that recommended information to be ultimately proposed to the service using company is extracted from this recommended candidate information.

[0042] (Functional configuration of the proposed server) Next, a detailed description will be given of each functional configuration of the proposal server 3. In the following, in describing each functional configuration of the proposal server 3, the relationship between each component shown in FIG. 3 and the main components for realizing each functional configuration of the proposal server 3 will also be described.

[0043] The transmission / reception unit 31 of the proposed server 3 shown in Figure 4 is realized by instructions from the CPU 101 shown in Figure 3 and the network I / F 109, and transmits and receives various data (or information) with other terminals, devices, or systems via the communication network 100.

[0044] The calculation unit 33 is realized by an instruction from the CPU 101 shown in Fig. 3, and performs a predetermined calculation. The contents of the calculation will be described later.

[0045] The determination unit 35 is realized by an instruction from the CPU 101 shown in Fig. 3, and performs a predetermined determination. The contents of the determination will be described later.

[0046] The creation unit 36 ​​is realized by commands from the CPU 101 shown in FIG. 3, and creates a cash flow screen and the like.

[0047] The storage / read processing unit 39 is realized by instructions from the CPU 101 and the HDD controller 105 shown in FIG. 3, and performs processing such as storing various data in the memory unit 3000 and reading out various data stored in the memory unit 3000.

[0048] [Processing or Operation of the Embodiment] Next, the processing or operation of this embodiment will be described with reference to FIGS.

[0049] <Display process of the cash flow screen> First, the process of displaying the financing screen will be described with reference to Fig. 17. Fig. 17 is a sequence diagram showing the process of displaying the financing screen.

[0050] A user A1 makes a login request from the user terminal 1 to the proposed server 3 (S21). This login request includes a tenant ID and a password for identifying the service using company A, which is an example of a tenant. As a result, the transmitting / receiving unit 31 of the proposed server 3 receives the login request. Then, the determining unit 35 of the proposed server 3 performs authentication by determining whether the service using company A is a legitimate tenant that receives the service (S22).

[0051] Next, the transmitting / receiving unit 31 transmits the response to the user terminal 1 (S23). As a result, the transmitting / receiving unit 11 of the user terminal 1 receives the response. Here, the case where the service using company A is a legitimate tenant will be explained next.

[0052] When user A1 operates the user terminal 1, the reception unit 12 receives a request to display a cash flow screen (S24). Then, the transmission / reception unit 11 transmits a request for cash flow screen data to the proposal server 3 (S25). As a result, the transmission / reception unit 31 of the proposal server 3 receives the request for the cash flow screen data.

[0053] Next, the proposal server 3 performs a process for creating a financial management screen (S26). The process for creating a financial management screen will now be described in detail with reference to Fig. 18. Fig. 18 is a flowchart showing the process for creating a financial management screen.

[0054] (Creating the cash flow screen) As shown in Fig. 18, the storage / readout processing unit 39 searches the tenant regular expense management DB 3001 (see Fig. 5) using the tenant ID used at the time of authentication as a search key to read out the corresponding tenant regular expense history information (S101). The storage / readout processing unit 39 also searches the tenant individual payment management DB 3002 (see Fig. 6) using the tenant ID as a search key to read out the corresponding tenant individual payment information (S102). The calculation unit 33 then calculates expenditure information for the corresponding period (here, one month) based on the tenant regular expense history information and the tenant individual payment information (S103).

[0055] Next, the storage / read processing unit 39 searches the fund raising information management DB 3003 (see FIG. 7) using the tenant ID as a search key to read out the corresponding fund raising information (S104). Then, the calculation unit 33 calculates the income information for each target period (S105).

[0056] Next, the storage / readout processing unit 39 searches the tenant bank account management DB 3004 (see FIG. 8) using the tenant ID as a search key to read out the corresponding tenant bank account information (S106). The storage / readout processing unit 39 also searches the tenant credit card management DB 3005 (see FIG. 9) using the tenant ID as a search key to read out the corresponding tenant credit card information (S107). The calculation unit 33 then calculates the cash balance for each target period (S108).

[0057] Next, the creation unit 36 ​​creates a cash flow screen as shown in Fig. 19 using the results of the calculations made in steps S103, S105, and S108 (S109). Fig. 19 is a diagram showing an example of the cash flow screen. This completes the process of creating the cash flow screen.

[0058] Returning to FIG. 17, the display control unit 14 of the user terminal 1 then uses the Web browser function to display an initial cash flow screen such as that shown in FIG. 19 on the display 106 of the user terminal 1 (S27).

[0059] (First cash flow screen) The initial financing screen 210 will now be described with reference to Fig. 19. Fig. 19 is a diagram showing an example of the financing screen.

[0060] As shown in FIG. 19, a cash flow screen 210 includes a tenant ID display field 211, an operation date display field 212, a past income and expenditure performance display field 213, and a future income and expenditure forecast display field 214.

[0061] Of these, the operation date display field 212 displays the date on which the operation is performed on this cash flow screen (the date it is displayed). The past income and expenditure results display field 213 displays the income and expenditure results (expenditure, income, cash balance) for each month prior to the operation date. These income and expenditure results are values ​​at the end of the month. For example, in August 2020, the income was 1 million yen, the cash balance was 1.2 million yen, and the expenditure was 700,000 yen. Of these, the cash balance is the value of "income + cash balance - expenditure" for the previous month, July.

[0062] In addition, the future income and expenditure forecast display field 214 shows monthly actual results (expenses, income, cash balance) from the operation date onwards. Since the income and expenditure forecast is a value at the end of the month, if the operation date is September 15th, the income and expenditure at the end of September is displayed in the income and expenditure forecast display field 214. Here, information 2141 is displayed indicating that there will be a shortage of 2 million yen at the end of October. The expenditure for October is 2.6 million yen. Only the cash balance of 600,000 yen that will definitely exist by the payment date is used to fill the gap for this 2.6 million yen. As a result, the shortage information 2141 indicating that there will be a shortage of 2 million yen in October is displayed. Note that the predicted income of 500,000 yen for October is not used to fill the gap for the expenditure of 2.6 million yen because there is a possibility that it will not be paid in time for the payment date of 2.6 million yen. As a result, the user can visually and easily understand that there will be a shortage of 2 million yen at the end of October, 2020.

[0063] Furthermore, three reception fields 215-217 for receiving selections or inputs from the user are included in the lower portion of the financing screen 210. From the user's perspective, the fund providing service company is a fund source.

[0064] Of these, the “recommended priority conditions” reception column 215 displays a “fee rate priority (condition)” radio button 2151 and a “risk avoidance priority (condition)” radio button 2152 .

[0065] "Fee rate priority" is an example of a predetermined condition for determining a specific fund-raising source from among multiple fund-raising sources (fund-providing service companies) by prioritizing the lowest fee rate of each fund-raising source determined by each of the multiple fund-raising sources and the contents of multiple forms. When the user presses the "Fee rate priority" radio button 2151, the proposal server 3 proposes recommended information (described below) that prioritizes the fee rate.

[0066] Furthermore, "risk avoidance priority" is an example of a predetermined condition for determining a specific fund-raising source from among multiple fund-raising sources (funding service companies) by prioritizing a low level of reliability of the business partner. When a user presses the "risk avoidance priority" radio button 2152, the proposal server 3 determines a specific fund-raising source by prioritizing a low level of reliability of the business partner. When a user presses the "risk avoidance priority" radio button 2152, the proposal server 3 proposes recommended information described below that prioritizes risk avoidance. For example, if there is a high possibility that accounts receivable cannot be collected from a debtor who is a business partner, accounts receivable from such a company is given priority for fund-raising.

[0067] In addition, the "payment deadline for fund raising" reception field 216 displays a period input field 2161 for inputting a predetermined period (here, one month) in units of time. In FIG. 19, the predetermined period is input from the month including the operation date (here, September 2020) to six months later (February 2021). This limits the recommended information described below to information including forms in which payments are deducted from income up to February 2021.

[0068] Furthermore, in the "Type of Fund Raising Object" reception column 217, check boxes 2171, 2172, 2173 for "invoice," "order form," and "quote" are displayed as specific examples of fund raising objects. Of the check boxes 2171 to 2173, documents (including electronic data) of the type checked by the user are the object of fund raising. As shown in FIG. 19, in this embodiment, the type of fund raising object also includes a "quote" before a transaction (sale and purchase) is concluded. In other words, by the user selecting (specifying) the type of the desired fund raising object, the user can narrow down the candidates for fund raising sources (funding service companies) to be used.

[0069] Next, the “request recommendation” button 219 is a button that the user presses when, after making the desired selections and inputs in each input field 215, 216, 217, the user wishes to have the proposal server 3 of proposing company C recommend a fund raising source (funding service company) that best suits the user’s wishes.

[0070] <Recommended screen display process> Next, the display process of the recommended screen will be described with reference to Fig. 19 to Fig. 27. Fig. 20 is a sequence diagram showing the display process of the recommended screen.

[0071] 19, when the user A1 makes a desired selection and input in each of the reception fields 215 to 217, the reception unit 12 receives the selection and input (S41). Furthermore, when the user A1 presses the "request recommendation" button 219, the reception unit 12 receives a request for a recommended screen (S42). Then, the transmission / reception unit 11 transmits a request for recommended screen data to the proposal server 3 (S43).

[0072] Next, the proposal server 3 performs a process of narrowing down the recommended information (S44). Here, the process of narrowing down the recommended information will be described in detail with reference to Figs.

[0073] (Recommended screen creation process) Fig. 21 is a flowchart showing the process of narrowing down the recommended information. As shown in Fig. 21, when creating a recommended screen, the proposal server 3 performs a preparatory process (S121) for identifying a fund-providing service company that will actually inquire about the commission rate from among a plurality of fund-providing service companies (fund-providing sources).

[0074] ((Advance preparation)) Here, the preparation process will be described in more detail with reference to Fig. 22. Fig. 22 is a flowchart showing the preparation process.

[0075] First, the storage / read processing unit 39 searches the tenant management DB 3006 (see FIG. 10) using the tenant ID used for authentication in step S22 as a search key to read out information such as the tenant's address, industry, and business type (S141).

[0076] Next, the storage / read processing unit 39 reads out from the fundraising information management DB 3003 (see Figure 7) the fundraising information (each record) whose payment deadline is included in the "payment deadline for fundraising target" input in Figure 19 (S142).

[0077] Next, the memory / read processing unit 39 refers to the funding service type management DB 3007 (see FIG. 11) and identifies the type of funding service (procurement type) corresponding to the "type of funding target" selected in FIG. 19 (S143).

[0078] Next, the storage / read processing unit 39 searches the funding service management DB 3008 (see Figure 12) using the information on the type of funding service identified in step S143 as a search key, and identifies information on the record that includes the corresponding funding service name (funding service information) (S144).

[0079] Next, the proposal server 3 repeatedly executes the processes of steps S146 to S150 between steps S145 and S151 for each piece of fund-providing service information.

[0080] First, the storage / read processing unit 39 reads out the "non-supported industry," "supported area," and "supported by individual business" of the funding service from the predetermined funding service information identified in step S145 (S146).

[0081] Next, the judgment unit 35 judges whether the tenant business type of the user A1 is unsupported or not based on the "unsupported business type" information (S147). If it is not unsupported (S147; NO), the judgment unit 35 judges whether the tenant address of the user A1 is outside the supported area (S148). If it is not outside the supported area (S148; NO), the judgment unit 35 judges whether the business type of the tenant of the user A1 corresponds to personal business support or not (S149). Applicable If so (S149; YES), the judgment unit 35 identifies the funding service (company) that actually makes an inquiry about the commission rate (S150). Then, returning to step S145, the proposal server 3 proceeds with the same process for the next predetermined funding service information. On the other hand, if the answer is YES in step S147, YES in step S148, or NO in step S149, the proposal server 3 does not execute the process of step S150, but returns to step S145 and proceeds with the same process for the next predetermined funding service information, thereby ending the process of FIG. 22.

[0082] In this manner, the proposal server 3 can narrow down the specific funding services that are the subject of an inquiry about the commission rate from among all the funding services identified in step S144 (first narrowing down).

[0083] Next, returning to FIG. 21, the proposal server 3 creates recommendation candidate information that is a candidate for recommended information to be provided to the user A1 (S122).

[0084] ((Creating recommendation candidate information)) Here, the process of creating recommendation candidate information will be described with reference to Fig. 23. Fig. 23 is a flowchart showing the process of creating recommendation candidate information.

[0085] As shown in Fig. 23, the storage / read processing unit 39 reads out from the fundraising information management DB 3003 (see Fig. 7) fundraising information (each record) whose payment due date is included in the "payment due date for fundraising target" input in Fig. 19 (S161). Next, the proposal server 3 repeatedly executes the processes of steps S163 to S171 between steps S162 and S172 for each piece of fundraising information read out in step S161.

[0086] First, the storage / read processing unit 39 refers to the fund-providing service type management DB 3007 (see FIG. 11) and identifies the type of fund-providing service corresponding to the "type of fund-providing target" selected in FIG. 19 (S163).

[0087] Next, the transmitting / receiving unit 31 creates inquiry information for each identified type of funding service among the specific funding services (companies) that are the subject of the commission rate inquiry, and obtains the commission rate from the funding service server 5 that manages the specific funding service (S164). The transmitting / receiving unit 31 makes the commission rate inquiry by reference to the destination information of each funding service server 5 managed in the destination information management DB 3009 (see FIG. 12). Here, in the process of step S164, in FIG. 20, the transmitting / receiving unit 31 of the proposal server 3 transmits commission rate inquiry information to each funding service server 5 (S164-1) and receives the latest commission rate information transmitted by the funding service server 5 (S164-2).

[0088] Next, the storage / read processing unit 39 stores the commission rate information received from each funding service server 5 in the storage unit 3000 (S165).

[0089] Next, the creation unit 36 ​​identifies information in which the funding service with the lowest commission rate is associated with the funding information as a comparison target for the comparison described below (secondary narrowing down) (S166). For example, in Fig. 16, when the business partner is X1 Corporation and the transaction amount is an invoice of 900,000 yen, services A1, A2, B1, B2, etc. are listed as potential funding sources, and among these, the funding service B2 with the lowest commission rate (5%) is identified as information in which the funding information (X1 Corporation, credit rating of 5, invoice of 900,000 yen, etc.) is associated with the funding information as a comparison target.

[0090] Next, the storage / read processing unit 39 further acquires credit information of the business partner (company) from the fund raising information read in step S161 (S167).

[0091] Next, the transmitting / receiving unit 31 acquires credit information of the trading partner company B from each credit information server 7 (S168). In this case, the transmitting / receiving unit 31 makes an inquiry by referring to the destination information of each credit information server 7 managed in the destination information management DB 3009. Also, as the process of step S168, in FIG. 20, the transmitting / receiving unit 31 of the proposal server 3 transmits a request for credit information to each credit information server 7 (S168-1) and receives the credit information transmitted by the credit information server 7 (S168-2).

[0092] However, the contents of the credit information differ depending on each credit information service company. For example, some companies manage credit information in three levels "H, N, L", while others manage it in seven levels "7-1", so adjustment is necessary. Therefore, in order to adjust the response information received from each credit information server 7 to a unified credit rating, the storage and readout processing unit 39 refers to the credit information adjustment management DB 3010 and replaces the response information received from each credit information server 7 with the unified credit rating (S169). Then, the storage and readout processing unit 39 manages the credit rating of each business partner (company) in the credit information management DB 3011 (S170).

[0093] Then, the storage / read processing unit 39 manages each piece of recommended candidate information, which is obtained by collecting each piece of information acquired and managed in steps S161 to S171 for each supplier, in the recommended candidate information management DB 3012 (see FIG. 16) (S171).

[0094] In this manner, the proposal server 3 can manage the recommendation candidate information.

[0095] ((Sorting by recommendations)) Next, returning to FIG. 21, a process of rearranging (sorting) the recommendation candidate information as recommendation information according to the priority information selected in FIG. 19 will be described.

[0096] In the case where the commission rate priority is selected as the priority condition for recommendation in Fig. 19 (S123; commission rate priority), the storage / readout processing unit 39 compares each piece of recommended candidate information managed in the recommended candidate information management DB 3012 and finally extracts recommended information according to the request from the user, sorting the comparison targets, which are each piece of recommended candidate information, in ascending order of commission rate as the first condition and descending order of credibility as the second condition, and reads out each piece of recommended information that is optimal for commission rate priority (S124). For example, in Fig. 16, the comparison targets are recommended candidate information indicating service B2 with the lowest commission rate of 5% for an invoice for Co., Ltd. X1 with a transaction amount of 900,000 yen, recommended candidate information indicating service B1 with the lowest commission rate of 6% for an invoice for Co., Ltd. X2 with a transaction amount of 500,000 yen, and recommended candidate information indicating service B2 with the lowest commission rate of 7% for an invoice for Co., Ltd. X3 with a transaction amount of 800,000 yen. Moreover, as a result of sorting the comparison targets in ascending order of commission rate (first condition), the order is as follows: a combination of an invoice for a transaction amount of 900,000 yen to Co., Ltd. X1 and service B2 (commission rate 5%), a combination of an invoice for a transaction amount of 500,000 yen to Co., Ltd. X2 and service B1 (commission rate 6%), and a combination of an invoice for a transaction amount of 800,000 yen to Co., Ltd. X3 and service B2 (commission rate 7%). If there are multiple comparison targets with the same commission rate, the comparison targets with the same commission rate are further sorted in descending order of creditworthiness (second condition). That is, the comparison targets are sorted by the first condition, and the comparison targets with the same first condition are sorted by the second condition. The same applies when risk avoidance priority is selected as the priority condition described later.

[0097] On the other hand, when risk avoidance priority is selected as the priority condition in FIG. 19 (S123; risk avoidance priority), the storage / reading processing unit 39 compares each piece of recommended candidate information managed in the recommended candidate information management DB 3012 and finally extracts recommended information that meets the user's request by sorting the comparison targets, that is, each piece of recommended candidate information, in order of lowest credibility as the first condition and lowest commission rate as the second condition, and reads out each piece of recommended information that is optimal for risk avoidance priority (S125).

[0098] Then, the storage / read processing unit 39 reads out the data of the recommended screen frame stored in the storage unit 3000 (S126).

[0099] Finally, the creation unit 36 ​​creates a recommendation screen as shown in FIG. 24 based on each piece of recommendation information read out in step S124, or creates a recommendation screen as shown in FIG. 26 based on each piece of recommendation information read out in step S125 (S126). At this point, no check is entered in the checkbox. FIG. 24 is a diagram showing a display example of a recommendation screen in the case of prioritizing commission. FIG. 26 is a diagram showing a display example of a recommendation screen in the case of prioritizing risk avoidance. FIG. 25 is a diagram showing a display example of a recommendation screen after the display has been changed in the case of prioritizing commission.

[0100] <Redisplay process of the cash flow screen> Next, returning to FIG. 20, the process of redisplaying the cash flow screen will be described.

[0101] First, after the process of narrowing down the recommended information is completed in step S44, the transmitter / receiver 31 transmits all the recommended information narrowed down in step S44 and the data of the recommended screen frame read in step S126 to the user terminal 1 (S45). As a result, the transmitter / receiver 11 of the user terminal 1 receives all the recommended information and the data of the recommended screen frame.

[0102] Next, in the user terminal 1, the display control unit 14 includes the recommended information in the recommended screen frame received in step S45, thereby displaying a recommended screen such as that shown in FIG. 24 (or FIG. 26) on the display 106 of the user terminal 1 (S46).

[0103] (Recommended screen (priority on commission rate)) Here, a case where the recommendation screen indicates that priority is given to the commission rate will be described with reference to Fig. 24. Fig. 24 is a diagram showing a display example of the recommendation screen in the case where priority is given to the commission rate.

[0104] As shown in FIG. 24, the recommendation screen 250 includes each piece of recommended information (business partner, which is information about the forms used for fund raising, type of fund raising target, transaction amount, scheduled payment date, type of fund raising, which is information about the fund raising source, fund raising source, commission rate, adjustment amount, deposit date, and business partner creditworthiness). Also, a check box for selection is displayed to the left of each piece of recommended information. Note that the transaction amount is the amount that the user plans to receive from the business partner. Also, the procurement amount is the amount to be received from the fund providing service company (fund raising source) after commission has been deducted. Also, all check boxes displayed are checked from the start.

[0105] Furthermore, the total procurement amount and the shortfall are displayed on the lower left side of the recommendation screen 250. The total procurement amount indicates the sum of the procurement amounts of the recommended information for which the user A1 has checked the checkboxes. From the beginning, the total procurement amount is displayed as the lowest total amount, although it exceeds the shortfall.

[0106] In addition, at the bottom right of the recommendation screen 250, a "Confirm" button 257 and a "See other recommendations" button 25 8 24 is displayed. The "Confirm" button 257 is a button that the user A1 presses when the display content in FIG. 24 is confirmed. When the "Confirm" button 257 is pressed, the user terminal 1 transmits confirmation information indicating that the content has been confirmed to the proposal server 3. The "View other recommendations" button 258 is a button that the user presses when other examples of the recommended information are displayed.

[0107] In this state, when the user A1 presses the "See other recommendations" button 258, the display control unit 14 changes to the recommendation screen 251 as shown in FIG. 25 (S47). Here, two new pieces of recommended information are displayed, but the check boxes are not checked. That is, the recommended information displayed in FIG. 24 is the third-stage narrowing down. but It is being carried out.

[0108] Also, on the lower right side, a "Return to initial recommendation" button 259 is displayed instead of the "See other recommendations" button 258. When the "Return to initial recommendation" button 259 is pressed, the display control unit 14 returns the display from the recommendation screen 251 in Fig. 25 to the recommendation screen 250 in Fig. 24.

[0109] As described above, the recommendation screen in Figure 25 displays information about the forms used for fundraising and information about the source of fundraising, but it may also be possible to display only information about the forms used for fundraising, or only information about the source of fundraising.

[0110] (Recommended screen (prioritize risk avoidance)) A case where the recommendation screen indicates that priority is given to risk avoidance will be described with reference to Fig. 26. Fig. 26 is a diagram showing a display example of the recommendation screen in the case where priority is given to risk avoidance.

[0111] In this case, the configuration is basically the same as the recommendation screen with priority given to the commission rate. That is, as shown in Fig. 26, the recommendation screen 260 includes each piece of recommended information (business partner, which is information about the form used for fund raising, type of fund raising target, transaction amount, scheduled payment date, type of fund raising, which is information about the fund raising source, fund raising source, commission rate, adjustment amount, payment date, and creditworthiness of the business partner). Also, a check box for selection is displayed to the left of each piece of recommended information.

[0112] Furthermore, the total procurement amount and the shortfall amount are displayed on the lower left side of the recommendation screen 260. The total procurement amount indicates the combination of the procurement amounts of the recommended information for which user A1 has checked the checkboxes. Also, a "Confirm" button 268 and a "View other recommendations" button 269 on the lower right side of the recommendation screen 260 are the same as the "Confirm" button 257 and the "View other recommendations" button 258 on the lower right side of the recommendation screen 250 in FIG. 24, respectively.

[0113] Here, the case where the user A1 presses the "Confirm" button 257 with the three checkboxes in FIG. 24 still checked will be explained.

[0114] When user A1 presses the "Confirm" button 257, the reception unit 12 receives the recommended information selected by the checkboxes (S48), as shown in Fig. 20. Then, the transmission / reception unit 11 transmits the recommended information selected in step S48 to the proposal server 3 (S49). As a result, the transmission / reception unit 31 of the proposal server 3 receives the selected recommended information.

[0115] Next, in the proposal server 3, the creation unit 36 ​​creates a cash flow screen as shown in FIG. 27, reflecting the recommendation information received in step S49 (S50).

[0116] Next, after the process of creating the cash flow screen reflecting the recommended information is completed by step S50, the display control unit 14 of the user terminal 1 uses the web browser function to display the recommended screen created by step S50 on the display 106 of the user terminal 1 (S51).

[0117] In this case too, it is possible to change to a recommendation screen as shown in FIG. 26, but the explanation will be omitted.

[0118] As described above, the recommendation screen in Figure 26 displays information about the forms used for fundraising and information about the source of fundraising, but it may also be possible to display only information about the forms used for fundraising, or only information about the source of fundraising.

[0119] (Cash flow screen reflecting recommended information) Here, the financial management screen 220 reflecting the recommended information in the case where the commission rate is prioritized will be described with reference to Fig. 27. Fig. 27 is a diagram showing a display example of the financial management screen reflecting the recommended information in the case where the commission rate is prioritized.

[0120] As shown in Fig. 27, the cash flow screen 220 displays information 2251 indicating that 2,069,000 yen can be raised when new funds are provided, in comparison with the cash flow screen 210 of Fig. 19. In addition, the income and cash balance from October 2020 onwards are changed due to the raising of 2,069,000 yen. In particular, since the funds etc. raised by user A1 in October 2020 do not become income thereafter, information 2261, 2262, and 2263 indicating this non-income amount is displayed.

[0121] Also, the bottom right of the cash flow screen 220 includes a "Confirm" button 229. The "Confirm" button 229 is a button that user A1 presses when he / she confirms the contents shown in FIG. 27 and closes the screen 220 of FIG. 27. Also, when user A1 presses the "Confirm" button 228 of FIG. 27, the reception unit 12 receives the confirmation, as shown in FIG. 20 (S50). Then, the transmission / reception unit 11 transmits confirmation information indicating that the contents displayed in step S49 have been confirmed to the proposal server 3 (S53). As a result, the transmission / reception unit 31 of the proposal server 3 receives the confirmation information.

[0122] This completes the process of redisplaying the cash flow screen.

[0123] [Main Effects of the Present Embodiment] As described above, according to this embodiment, the proposal server 3 transmits specific fund-raising sources that provide fund-raising that meets the predetermined conditions requested by the user A1 to the user terminal 1. In other words, the proposal server 3 makes a proposal to the user terminal 1 indicating "where" to apply for fund-raising, thereby solving the problem that the user A1 has difficulty finding a fund-raising source that meets the conditions that he or she expects.

[0124] Furthermore, the proposal server 3 transmits information indicating a specific form determined based on predetermined conditions from among multiple forms issued when the user A1 provides a product or service to the user terminal 1. In other words, the proposal server 3 makes a proposal to the user terminal 1 indicating "what" to apply for fund raising from a predetermined fund raising source, thereby solving the problem that the user A1 has difficulty finding a fund raising source that meets the conditions that he or she expects.

[0125] 〔supplement〕 After step S53 in FIG. 20, the proposal server 3 may apply for the user A1 in step S in FIG.

[0126] The user terminal 1 is an example of a communication terminal. The user terminal 1 includes not only a PC but also a smart watch, a game machine, a device dedicated to video calling, and the like. The presenter terminal is an example of another communication terminal.

[0127] Each component such as the CPU 101 may be a single component or a plurality of components.

[0128] Each function in the above-described embodiment can be realized by one or more processing circuits. Here, the "processing circuit" in the present embodiment can be a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, or an ASIC (Application Specific Integrated Circuit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), S, or other device designed to execute each of the above-described functions. о C(System on a C This includes devices such as chips, GPUs, and traditional circuit modules.

[0129] Additionally, each of the servers 3, 5, and 7 described in the above embodiments merely illustrates one of a number of computing environments for implementing the embodiments disclosed herein. For example, the proposal server 3 may include a number of computing devices, such as a server cluster. The multiple computing devices are configured to communicate with each other via any type of communication link, including a communication network, shared memory, and the like, and perform the processes disclosed herein. Similarly, the proposal server 3 may include a number of computing devices configured to communicate with each other.

[0130] Furthermore, the proposal server 3 can be configured to share the disclosed processing steps in various combinations. For example, the processes performed by the proposal server 3 can be performed by other servers. Similarly, the functions of the proposal server 3 can be performed by other servers. Also, the elements of the proposal server 3 and the other servers can be integrated into one server or separated into multiple devices. [Explanation of symbols]

[0131] 1. User terminal 3. Proposal Server 11 Transmitter / receiver 12 Reception 14 Display control section 15 Judgment Department 19 Storage and readout processing section 31 Transmitting / receiving unit (an example of a transmitting means, an example of a receiving means) 33 Calculation section 35 Judgment Department 36 Creation Department 39 Storage and readout processing section 100 Communication Network [Prior art documents] [Patent documents]

[0132] [Patent Document 1] Patent No. 6707700

Claims

1. A proposal server that provides information via a communication network to a user terminal of a user who is to provide or plan to provide a product or service to a trading partner, a receiving means for receiving, from the user terminal, fund raising object type information regarding a fund raising object type based on the transaction and a priority condition regarding a risk aversion priority that prioritizes the creditworthiness of the transaction partner; A determination means for determining a fund-raising source corresponding to the fund-raising target type from a plurality of fund-raising sources; a generating means for generating recommendation candidate information to be candidates for recommendation information to be provided to the user terminal based on a result of the judgment by the judging means; a transmission means for transmitting, to the user terminal, screen information in which the recommendation candidate information created by the creation means has been rearranged as the recommendation information according to the priority condition; A proposal server comprising:

2. The proposal server according to claim 1, characterized in that the transmitting means transmits to the user terminal information indicating a specific form determined based on the priority conditions from among a plurality of forms issued when the user provides the product or service.

3. The proposal server according to claim 2, characterized in that the priority condition is a commission rate priority condition, in which each of the multiple fundraising sources determines a specific fundraising source by prioritizing a low commission rate for each fundraising method determined by the contents of the multiple forms.

4. 3. The proposal server according to claim 2, wherein the priority condition is a risk aversion priority condition for determining a specific fund raising source by giving priority to a low reliability of the business partner.

5. A reading processing unit that reads out, from the fund-raising information management unit, fund-raising information including a payment deadline for a fund-raising target, The receiving means receives information indicating a payment deadline for a fund raising target from the user terminal, The reading processing unit reads out the financing information including a payment deadline from the financing information management unit, the payment deadline being included in the received payment deadline; The transmitting means reads out the fundraising information including a payment due date within the payment due date of the fundraising target, and transmits information indicating a specific fundraising source that satisfies the priority condition to the user terminal. The proposal server according to any one of claims 1 to 4, characterized in that

6. The transmitting means transmits to the user terminal information indicating a specific fund-raising source that satisfies the priority condition within the range of the fund-raising target type. The proposal server according to any one of claims 1 to 4, characterized in that

7. 7. The proposal server of claim 6, wherein the fundraising object type indicates an invoice, a purchase order, or a quote.

8. A communication system constructed by a user terminal of a user who provides or plans to provide a product or service to a trading partner, and a proposal server that provides information to the user terminal via a communication network, the user terminal transmits to the proposal server fund raising object type information regarding the fund raising object type based on the transaction and a priority condition regarding a risk aversion priority that prioritizes the creditworthiness of the transaction partner; The proposal server determines a fund-raising source corresponding to the fund-raising target type from among a plurality of fund-raising sources, creates recommendation candidate information to be candidates for recommendation information to be provided to the user terminal based on the determination result, and transmits to the user terminal screen information in which the created recommendation candidate information is rearranged as recommendation information according to the priority conditions. A communication system comprising:

9. A method for providing information to a user terminal of a user who provides or is scheduled to provide a product or service to a trading partner, the method being executed by a proposal server that provides information via a communication network to the user terminal of a trading partner, the method comprising: a receiving step of receiving, from the user terminal, fund raising object type information regarding a fund raising object type based on the transaction and a priority condition regarding a risk aversion priority that prioritizes the creditworthiness of the trading partner; a determination step of determining a fund-raising source corresponding to the fund-raising object type from a plurality of fund-raising sources; a creating step of creating recommendation candidate information that is a candidate for recommendation information to be provided to the user terminal based on a result of the determination step; a transmission step of transmitting screen information in which the created recommendation candidate information has been rearranged as recommendation information according to the priority condition to the user terminal; Provided methods to perform.

10. A program causing a computer to execute the method according to claim 9.

Images