Proposal server, communication system, providing method, and program

Abstract

To solve the following problem: a method, i.e., factoring, for procuring funds by quickly cashing accounts receivable generated through transactions is commonly used in commercial transactions, however, when a user as a creditor owns various debts, it is difficult for the user to identify future financing when procuring funds with the debts since the user may collect the debts at different times.SOLUTION: A recommendation server 3 displays a financing screen 220 that visualizes future financing for the case of specifying a document form to be used for financing, on a user terminal 1, thereby enabling a user to easily identify future financing.SELECTED DRAWING: Figure 25

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 widely used method of raising funds by quickly converting accounts receivable arising from transactions into cash.

[0003] For example, Patent Document 1 discloses a method for quickly purchasing accounts receivable while reducing the manual administrative burden, by using a technology that implements the procedure for purchasing accounts receivable through factoring using a computer system. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6707700 Summary of the Invention [Problem to be solved by the invention]

[0005] However, if a user as a creditor holds various claims, the time when the user can collect the claims varies. In such a situation, when a user tries to raise funds using claims, it becomes difficult to grasp the future cash flow situation. [Means for solving the problem]

[0006] The invention of claim 1 is a proposal server that provides information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner, By receiving from the user one or more selections from the reception fields of the types of forms including at least an invoice, an order form, and an estimate, which are displayed on the screen of the user terminal, The user terminal sent, Types of documents to be funded a receiving means for receiving condition information indicating the future cash flow situation; and a cash flow screen indicating the future cash flow situation. The type of document to be funded selected by the userand a transmitting means for transmitting data constituting the cash flow screen based on information of a specific form that satisfies the above condition so that the data can be received by the user terminal. [Effects of the Invention]

[0007] As described above, according to the present invention, by visualizing the future cash flow situation when a document to be used for fund raising is specified, it is possible to make it easier for users to understand the future cash flow situation. [Brief explanation of the drawings]

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

[0009] [Inter-company relationships] The relationships between the companies will be explained using Figure 1. Figure 1 is a diagram showing the relationships between the companies according to this embodiment.

[0010] As shown in Figure 1, service user company A is a company that uses a service to receive recommended fundraising proposals 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.

[0011] 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 the services indicated above and are all funding service companies. From the perspective of service user company A, funding service companies are sources of funding.

[0012] 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 is a collective term for multiple PO finance service companies F1, F2, ... Fn. Quotation finance service company G is a collective term for multiple quotation finance service companies G1, G2, ... Gn.

[0013] Credit information service company H is a company that holds credit information indicating the reliability of management, etc. 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 multiple credit information service companies H1, H2, ... Hn.

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

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

[0016] As a result, service user company A applies for funding by sending a document to the proposed specific funding source (funding service company) (S4). In response, the specific funding service company provides funding to service user company A after screening (S5). Furthermore, the specific funding service company requests accounts receivable from trading partner company B corresponding to accounts receivable, etc. (S6). As a result, trading partner company B pays the accounts receivable to the specific funding service company on the due date (S7).

[0017] [Communication system overview] 2 is a schematic diagram of the communication system of this embodiment, showing the terminals or servers of each company in FIG.

[0018] User company A is equipped with a user terminal 1 such as a PC (personal computer), which is operated by user A1. Proposal company C is equipped with a proposal server 3. Factoring service company D, accounts receivable financing service company E, PO finance service company F, and quotation finance service company G are equipped with funding service servers 5d, 5e, 5f, and 5g, respectively. Credit information service company H is equipped with a credit information server 7. Each server is composed of a computer. The user terminal 1, funding service servers 5d, 5e, 5f, and 5g, and credit information server 7 can communicate with each other via a communication network 100 such as the Internet. Hereinafter, funding service servers 5d, 5e, 5f, and 5g will be collectively referred to as the "funding service server 5."

[0019] [Hardware configuration of communication system] Next, the hardware configuration of each terminal and server that constitutes the communication system shown in Fig. 1 will be described using 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.

[0020] As shown in Figure 3, the user terminal 1 is composed of a computer and includes a CPU 101, a ROM 102, a RAM 103, a HD 104, an HDD (Hard Disk Drive) controller 105, a display 106, an external device connection I / F (Interface) 108, a network I / F 109, a bus line 110, a keyboard 111, a pointing device 112, a DVD-RW (Digital Versatile Disk Rewritable) drive 114, and a media I / F 116.

[0021] Of these, the CPU 101 controls the operation of the entire computer. The ROM 102 stores programs used to drive the CPU 101, such as the IPL. 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 the 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, menus, windows, characters, or images. The external device connection I / F 108 is an interface for connecting various external devices. In this case, the external devices are, for example, USB (Universal Serial Bus) memories, printers, etc. 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, etc. for electrically connecting the components, such as the CPU 101, shown in FIG. 3.

[0022] 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 medium is not limited to a DVD-RW, and may be a DVD-R or a Blu-ray Disc (registered trademark), etc. The media I / F 116 controls reading and writing (storing) of data from a recording medium 115, such as a flash memory.

[0023] 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.

[0024] [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 funding service server 5 and the credit information server 7 do not have any new functions in the communication processing of this embodiment, so their description will be omitted.

[0025] <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 transmitting / receiving unit 11, a receiving unit 12, a display control unit 14, a determining unit 15, and a storage / readout processing unit 19. Each of these units is a function or a means for performing the function, which 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 HD 104 shown in Figure 3.

[0026] (Functional configuration of user terminal) Next, we will explain each component of the user terminal 1. The transmitting / receiving unit 11 is realized by commands from the CPU 101 shown in Fig. 3, an external device connection I / F 108, and a 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.

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

[0028] 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 108. The display control unit 14 has a web browser function.

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

[0030] The storage / readout processing unit 19 is mainly realized by instructions from the CPU 101 shown in Figure 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.

[0031] <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 transmitting / receiving unit 31, a calculating unit 33, a determining unit 35, a creating unit 36, and a storing / reading 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 in response 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 HD 104 shown in Fig. 3.

[0032] (Tenant regular expense management table) Fig. 5 is a conceptual diagram showing a tenant regular expense management table. A tenant regular expense management DB 3001 configured with a tenant regular expense management table such as that shown in Fig. 5 is constructed in the memory unit 3000. This table manages past expenditure types, expenditure months, and amounts for regular payments in association with each tenant ID used to identify tenants (such as service user company A) that receive services from proposing company C. Future regular payments are predicted based on this table.

[0033] (Tenant individual payment management table) Fig. 6 is a conceptual diagram showing an individual tenant payment management table. The storage unit 3000 has created an individual tenant payment management DB 3002 that is configured using the individual tenant payment management table shown in Fig. 6. In this table, tenant payment information is managed by associating each piece of information, such as ID, biller, payment deadline, amount, and payment status, for each tenant ID.

[0034] (Funding information management table) FIG. 7 is a conceptual diagram showing a funding information management table. A funding information management DB 3003 consisting of a funding information management table such as that shown in FIG. 7 is constructed in the storage unit 3000. This table shows the contents of forms used for funding. Therefore, this table associates and manages, for each tenant ID, information such as ID, business partner, funding object type, payment deadline, amount, and payment status, as well as the storage location of the form image digitized into PDF or the like. The funding object types include invoices, purchase orders, and estimates.

[0035] (Tenant bank account management 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 such as that shown in Fig. 8 is constructed in the storage unit 3000. This table shows the details of the user's own bank account that the user has registered in advance with the proposal server 3. Therefore, this table manages the bank name, branch name, account number, user name, and password in association with each tenant ID.

[0036] (Tenant credit card management table) Fig. 9 is a conceptual diagram showing a tenant credit card management table. A tenant credit card management DB 3005 configured with a tenant credit card management table such as that shown in Fig. 9 is constructed in the storage unit 3000. This table shows information about 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 will later be used for the cash balance.

[0037] (Tenant management table) FIG. 10 is a conceptual diagram showing a tenant management table. A tenant management DB 3006 configured with a tenant management table such as that shown in FIG. 10 is constructed in the storage unit 3000. This table shows details related to the company information of the tenant. Therefore, this table associates and manages the tenant ID, tenant name, tenant address (location), tenant industry, and tenant business type. This information is used, for example, when the tenant is in the construction industry, to exclude from selection funding service companies that do not provide funding to the construction industry in particular.

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

[0039] (Funding Service Management Table) Figure 12 is a conceptual diagram showing a funding service management table. A funding service management DB 3008 consisting of a funding service management table such as that shown in Figure 12 is constructed in the memory unit 3000. This table associates and manages the funding service type, funding service name (company name), non-supported industries, supported areas for funding, individual business support for funding, funding amount conditions, and the connection URL (destination information) to the funding service server 5 of the funding service company. Note that if the funding support for individual business is "false," the funding service company provides funding to companies but does not provide funding to individuals.

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

[0041] (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 configured with a credit information adjustment management table such as that shown in Fig. 14 is constructed in the memory unit 3000. In this table, the credit ratings provided by each credit information service company are associated and managed for each credit rating. Since the credit rating levels set by each credit information service company are different, this table is used to adjust and unify them.

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

[0043] (Recommended candidate information management table) FIG. 16 is a conceptual diagram showing a recommendation candidate information management table. A recommendation candidate information management DB 3012 configured with a recommendation candidate information management table such as that shown in FIG. 16 is constructed in the storage unit 3000. This table shows recommendation candidate information including the contents of forms used for fundraising. Therefore, this table associates and manages the business partner, the business partner's creditworthiness, the transaction amount shown in the form, the type of fundraising target, the type of fund providing service (type of procurement), the name of the fund providing service (company name), the fee rate for fund provision, and the date of deposit to the service using company if fund provision is made. Note that from this recommendation candidate information, the recommended information that will be ultimately proposed to the service using company is extracted.

[0044] (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, when 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.

[0045] The transmission / reception unit 31 of the proposal 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.

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

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

[0048] 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.

[0049] The storage / readout 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 storage unit 3000 and reading out various data stored in the storage unit 3000.

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

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

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

[0053] 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. Now, the case where the service using company A is a legitimate tenant will be described.

[0054] 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 cash flow screen data.

[0055] Next, the proposal server 3 performs a process for creating a cash flow screen (S26). Here, the process for creating a cash flow screen will be described in detail with reference to Fig. 18. Fig. 18 is a flowchart showing the process for creating a cash flow screen.

[0056] (Cash flow screen creation process) 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 during authentication as a search key to read out the corresponding tenant regular expense 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). Then, the calculation unit 33 calculates expenditure information for each target period (one month in this case) to be displayed based on the tenant regular expense information and the tenant individual payment information (S103). The target period may be expressed as a predetermined period.

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

[0058] 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).

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

[0060] Next, returning to FIG. 17, the display control unit 14 of the user terminal 1 uses the web browser function to display the initial cash flow screen as shown in FIG. 19 on the display 106 of the user terminal 1 (S27).

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

[0062] As shown in FIG. 19, the 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.

[0063] Of these, the operation date display field 212 shows 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 shows the income and expenditure results (expenses, 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, income was 1 million yen, the cash balance was 1.2 million yen, and expenses were 700,000 yen. Of these, the cash balance is the value of "income + cash balance - expenditure" for the previous month, July.

[0064] Furthermore, the future income / expense forecast display field 214 displays actual monthly results (expenses, income, and cash balance) for months beyond the operation date. Since the income / expense forecast is a value at the end of the month, if the operation date is September 15th, the income / expense for the end of September will be displayed in the income / expense forecast display field 214. Here, information 2141 indicating a shortfall of 2 million yen at the end of October is displayed. 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 cover this 2.6 million yen. As a result, shortfall information 2141 indicating a shortfall of 2 million yen in October is displayed. Note that the predicted income of 500,000 yen for October may not be paid in time for the payment date of the 2.6 million yen, so it will not be used to cover the shortfall of the 2.6 million yen expenditure. This allows the user to visually and easily understand that there will be a shortfall of 2 million yen at the end of October, 2020.

[0065] Furthermore, a line graph 2271 showing the "difference between cash balance and expenditure" for a predetermined period (here, one month) is displayed in the future income and expenditure forecast display field 214. This makes it easier for user A1 to grasp the month in which the "difference between cash balance and expenditure" will be in the red, and therefore allows user A1 to understand that he or she must raise funds to prepare for the deficit in October.

[0066] Furthermore, three reception fields 215 to 217 for receiving selections or inputs from the user are included at the bottom of the financing screen 210. From the user's perspective, the fund providing service company is the source of funding.

[0067] Of these, the "recommended priority conditions" reception column 215 displays a "commission rate priority (condition)" radio button 2151 and a "risk avoidance priority (condition)" radio button 2152.

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

[0069] Furthermore, "risk avoidance priority" is an example of a predetermined condition for selecting a specific fund-raising source from among multiple fund-raising sources (fund-providing service companies) by prioritizing the trustworthiness of the business partner. When the 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 company, accounts receivable from such a company will be given priority in raising funds.

[0070] Additionally, the "payment deadline for fund raising target" reception field 216 displays a period input field 2161 for inputting a predetermined period (here, one month). In FIG. 19, the predetermined period is input from the month including the operation date (here, September 2020) to six months later (February 2021). As a result, the recommended information described below is limited to information including reports in which payments are deducted from income up to February 2021.

[0071] Furthermore, the "Type of Funding Object" reception column 217 displays check boxes 2171, 2172, and 2173 for "invoice," "order form," and "quote" as specific examples of funding objects. Of the check boxes 2171 to 2173, documents (including electronic data) of the type checked by the user are eligible for fundraising. As shown in FIG. 19, in this embodiment, the types of fundraising objects also include "quotations" before a transaction (sale and purchase) is concluded. In other words, by selecting (specifying) the type of fundraising object desired, the user can narrow down the candidates for fundraising sources (funding service companies) to use.

[0072] Next, the "request recommendation" button 219 is a button that the user presses when, after making the desired selection and input in each reception field 215, 216, 217, the user wishes to have the proposal server 3 of proposing company C recommend a fundraising source (funding service company) that best suits the user's wishes.

[0073] <Recommended screen display process> Next, the display process of the recommendation screen will be described with reference to Fig. 19 to Fig. 29. Fig. 20 is a sequence diagram showing the display process of the financing screen and the recommendation screen.

[0074] First, in FIG. 19, when user A1 makes desired selections and inputs in each of the reception fields 215 to 217, the reception unit 12 receives the selections and inputs of priority conditions, etc. (S41). Furthermore, when 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). Note that the processing of this step S43 corresponds to the processing of the above-mentioned step S2. Therefore, this request for recommended screen data includes the above-mentioned condition information (see S2). This condition information is information specified by the selections and inputs received in step S41, and indicates predetermined conditions related to fundraising by user A1 using a form issued to provide a product or service.

[0075] 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.

[0076] (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 recommendation screen, the proposal server 3 performs a preparatory process to identify a funding service company from among a plurality of funding service companies (funding sources) that will actually be inquired about the commission rate (S121).

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

[0078] First, the storage / readout 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, business type, etc. (S141).

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

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

[0081] Next, the storage / readout 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 the information (funding service information) of the record that includes the corresponding funding service name (S144).

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

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

[0084] Next, the determination unit 35 executes a determination process based on each piece of information read (acquired) by the storage / readout processing unit 39 in steps S141 to S146 as described above. Specifically, based on the "non-compatible business type" information, the determination unit 35 determines whether the tenant business type of user A1 is non-compatible (S147). If it is not non-compatible (S147; NO), the determination unit 35 determines whether the tenant address of user A1 is outside the compatible area (S148). If it is not outside the compatible area (S148; NO), the determination unit 35 determines whether the business type of user A1's tenant corresponds to sole proprietorship (S149). If it is compatible (S149; YES), the determination unit 35 identifies the funding service (company) that will actually inquire about the commission rate (S150). Then, returning to step S145, the proposal server 3 performs 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 processing of step S150, but returns to step S145 and performs similar processing on the next specified funding service information, thereby completing the processing of Figure 22.

[0085] In this way, 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).

[0086] 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).

[0087] ((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.

[0088] As shown in Fig. 23, the storage / readout processing unit 39 reads out from the funding information management DB 3003 (see Fig. 7) the funding information (each record) whose payment deadline is included in the "payment deadline for funding 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 funding information read out in step S161.

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

[0090] Next, the transmitter / receiver 31 creates inquiry information for each identified type of funding service among the specific funding services (companies) for which the commission rate is to be queried, and obtains the commission rate from the funding service server 5 that manages the specific funding service (S164). The transmitter / receiver 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 processing of step S164, in FIG. 20, the transmitter / receiver 31 of the proposal server 3 sends commission rate inquiry information to each funding service server 5 (S164-1), and receives the latest commission rate information sent by the funding service server 5 (S164-2).

[0091] 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).

[0092] Next, the creation unit 36 ​​identifies information in which the funding information is associated with the funding service with the lowest commission rate as the comparison target for the comparison described below (secondary narrowing down) (S166). For example, in Fig. 16, if 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, funding service B2 with the lowest commission rate (5%) is identified as the comparison target, in which the funding information (X1 Corporation, credit rating of 5, invoice of 900,000 yen, etc.) is associated with the funding information.

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

[0094] Next, the transmitting and receiving unit 31 acquires the credit information of trading partner company B from each credit information server 7 (S168). In this case, the transmitting and 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. In addition, as the processing of step S168, in FIG. 20, the transmitting and 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).

[0095] However, the content of the credit information varies depending on the credit information service company. For example, some companies manage credit information using a three-level scale (H, N, L), while others manage it using a seven-level scale (7-1), so adjustments are 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 customer (company) in the credit information management DB 3011 (S170).

[0096] 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 business partner, in the recommended candidate information management DB 3012 (see FIG. 16) (S171).

[0097] In this way, the proposal server 3 can manage the recommendation candidate information.

[0098] ((Sorting by recommendation)) 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.

[0099] 19, when commission rate priority is selected as the priority condition for recommendation (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 that meets the user's request. In this manner, the storage / readout processing unit 39 sorts the recommended candidate information, which are comparison targets, in descending order of commission rate as a first condition and descending order of trustworthiness as a 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 include 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, recommended candidate information indicating service B2 with the lowest commission rate of 6%, 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. Furthermore, sorting the comparison targets in ascending order of commission rate (first condition) results in the following order: 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 those with the same first condition are sorted by the second condition. The same applies if risk avoidance priority is selected as the priority condition described below.

[0100] On the other hand, if risk avoidance priority is selected as the priority condition in Figure 19 (S123; risk avoidance priority), the storage and 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.In this way, the storage and reading processing unit 39 sorts 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).

[0101] Next, the storage / read processing unit 39 extracts the documents after rearrangement in steps S124 and S125 so as to make up for the shortfall in the cash flow (S126).

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

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

[0104] First, after the process of narrowing down the recommended information is completed in step S44, the calculation unit 33 recalculates the income information and cash balance for each target period (here, each month) based on the invoice amount and payment due date in the recommended information (S45).Then, the creation unit 36 ​​creates a cash flow screen that reflects the recommended information (S46).

[0105] Next, the transmitter / receiver 31 transmits all of the recommended information recalculated in step S45 and the data of the recommended screen frame read in step S127 to the user terminal 1 (S47). As a result, the transmitter / receiver 11 of the user terminal 1 receives all of the recommended information and the data of the recommended screen frame. Note that the processing of step S45 corresponds to the processing of step S3 described above.

[0106] Next, in the user terminal 1, the display control unit 14 includes the recommendation information in the recommendation screen frame received in step S47, thereby displaying the cash flow screen as shown in Fig. 25 and the recommendation screen as shown in Fig. 26 (or Fig. 27) on the display 106 of the user terminal 1 (S48). At this point, no check boxes are checked in Figs. 25 to 27.

[0107] (Display processing of cash flow screen and recommendation screen) The processing of step S48 will now be described in detail with reference to Figures 24 to 27. Figure 24 is a flowchart showing the display processing of the financing screen and the recommendation screen.

[0108] As shown in FIG. 24, the display control unit 14 displays a cash flow screen that reflects the recommended information received in step S47 on the display 106 of the user terminal 1 (S201).

[0109] (Cash flow screen reflecting recommended information) Here, the cash flow screen 220 that reflects the recommended information when the commission rate is prioritized will be described with reference to Fig. 25. Fig. 25 is a diagram showing a display example of the cash flow screen that reflects the recommended information when the commission rate is prioritized.

[0110] As shown in Figure 25, the cash flow screen 220 displays information 2251 indicating that 2,069,000 yen can be raised if new funds are provided, in addition to the cash flow screen 210 of Figure 19. In addition, the income and cash balance from October 2020 onwards will be changed due to the provision of 2,069,000 yen. In particular, since the funds etc. raised by user A1 in October 2020 will not be considered income thereafter, information 2261, 2262, and 2263 indicating this non-income amount is displayed.

[0111] Furthermore, a line graph 2272 showing the "difference between cash balance and expenditure" for the target period (here, one month) is displayed in the future income and expenditure forecast display field 214. This makes it easier for user A1 to understand that there are no months in which the "difference between cash balance and expenditure" is in the red.

[0112] Additionally, the lower right side of the cash flow screen 220 includes a "View Details" button 228 and a "Confirm" button 229. The "View Details" button 228 is a button that user A1 presses when he or she wishes to display the recommendation screen shown in FIG. 26. The "Confirm" button 229 is a button that user A1 presses when he or she has confirmed the content shown in FIG. 25 and wishes to confirm the recommended cash flow content. When the "Confirm" button 229 is pressed, the processing of step S49 in FIG. 20 is performed.

[0113] Here, when user A1 presses the "View details" button 228 in Fig. 25, the reception unit 12 receives a request to display detailed information (S202), as shown in Fig. 24. As a result, the display control unit 14 displays a recommendation screen (fee rate priority) as shown in Fig. 26.

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

[0115] As shown in Figure 26, the recommendation screen 250 includes each recommended information item (business partner, which is information about the documents used for fundraising, type of fundraising target, transaction amount, payment due date, type of fundraising, which is information about the fundraising source, 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 recommended information item. The transaction amount is the amount that the user plans to receive from the business partner. The procurement amount is the amount to be received from the fund providing service company (fundraising source), after commission has been deducted. Also, all check boxes currently displayed are checked from the start.

[0116] Furthermore, the total procurement amount and the shortfall amount are displayed in the lower left corner of the recommendation screen 250. The total procurement amount indicates the total procurement amount of the recommended information for which the user A1 has checked the checkbox. From the beginning, the total procurement amount is displayed as the lowest total amount, even though it exceeds the shortfall amount.

[0117] Also, a "View in graph" button 256, a "Confirm" button 257, and a "View other recommendations" button 258 are displayed on the lower right side of the recommendation screen 250. The "View in graph" button 256 is a button that user A1 presses when updating and displaying the cash flow screen 220 shown in FIG. 25. The "Confirm" button 257 is a button that user A1 presses when confirming the display content of FIG. 26. When the "Confirm" button 257 is pressed, the user terminal 1 transmits confirmation information to the proposal server 3 indicating that the confirmation has been made. The "View other recommendations" button 258 is a button that user A1 presses when displaying other examples of the recommended information.

[0118] In this state, when user A1 presses the "See other recommendations" button 258, the display control unit 14 changes to the recommendation screen 251 as shown in FIG. 27 (S204). Here, two new recommended information items are displayed, but the check boxes are not checked. If user A1 checks the check boxes, the reception unit 12 accepts the checked recommended information items (S205). That is, a third refinement is performed using the recommended information items displayed in FIG. 26.

[0119] 24, when user A1 presses the "View as a graph" button 256, the reception unit 12 receives a request to update and display the cash flow screen (S206; YES). As a result, the display control unit 14 updates and redisplays the cash flow screen based on the latest recommended information received in step S205 (S207). Thereafter, the process returns to step S201.

[0120] On the other hand, if user A1 presses the "Confirm" button 257 without pressing the "View in graph" button 256, the reception unit 12 will accept that the fundraising target (document) recommended by the proposal server will be confirmed using the recommended information shown in Fig. 24 (S208). As a result, returning to Fig. 20, the transmission / reception unit 11 of the user terminal 1 will transmit confirmation information indicating the content confirmed in step S208 to the proposal server 3 (S49). As a result, the transmission / reception unit 31 of the proposal server 3 receives the confirmation information.

[0121] As a result of the above, the user A1 can decide to raise funds for a selected form from among the multiple forms (invoices) proposed by the proposal server 3.

[0122] As described above, the recommendation screens in Figures 26 and 27 display information about the forms used for fundraising and information about the source of fundraising, but it is also possible to display only information about the forms used for fundraising, or only information about the source of fundraising.

[0123] 25 shows a cash flow screen for when fee rate is prioritized, but the display format is similar for when risk aversion is prioritized, so explanations are omitted. Similarly, in FIGS. 26 and 27, a recommendation screen for when fee rate is prioritized is displayed, but the display format is similar for when risk aversion is prioritized, so explanations are omitted.

[0124] The following describes in more detail the processing that occurs when user A1 changes the check status of the recommended information on the recommendation screen 251 shown in Fig. 27. Fig. 28 is a diagram showing an example of the display after user A1 changes the recommended information in the case of prioritizing the commission rate.

[0125] The recommendation screen 252 shown in Fig. 28 is the recommendation screen that appears when user A1 unchecks the third checkbox from the top and checks the fourth and fifth checkboxes from the top in response to an operation by user A1 on the recommendation screen 251 shown in Fig. 27. The total procurement amount displayed in the lower left corner of the recommendation screen 252 is updated to the total procurement amount of the recommended information whose checkboxes are checked each time the check status of the checkboxes is changed.

[0126] There are the following cases where user A1 may want to change the ledger used for fundraising from the fundraising target proposed by proposal server 3. For example, there is a case where user A1 wants to collect accounts receivable from a business partner with higher priority than the business partner of the fundraising target proposed by proposal server 3. One example of the reason for this is when, although the business partner has a high credit rating registered in credit information management DB 3011, it is determined from recent transactions that there are circumstances that may make it difficult to collect accounts receivable (for example, there is a possibility that the business partner may go bankrupt soon).

[0127] When user A1 presses the "View as a graph" button 256 on the recommendation screen 252, the reception unit 12 receives a request to update and display the cash flow screen. As a result, the display control unit 14 updates and redisplays the cash flow screen based on the latest recommendation information.

[0128] Figure 29 is a diagram showing an example of the display of the cash flow screen after user A1 changes the recommended information for the fee rate priority case. As shown in Figure 29, the cash flow screen 221 that is redisplayed after changing the check status of the check box on the recommendation screen 252 displays a line graph 2273 showing the "difference between cash balance and expenditures" for the target period, which has been newly recalculated based on the recommended information selected by user A1, in addition to the cash flow screen 220 of Figure 25. In addition, information 2251 showing the amount of funds that can be raised is redisplayed with the amount recalculated based on the recommended information selected by user A1.

[0129] Line graph 2273 is displayed in a line type different from line graph 2272, which shows the "difference between cash balance and expenditures" for the target period, calculated based on the fundraising target proposed by proposal server 3. For example, if line graph 2272 is displayed as a solid line, line graph 2273 may be displayed as a line type that is visually different from the solid line, such as a dotted line, dashed line, or dashed dotted line. Furthermore, line graph 2272 and line graph 2273 may be displayed in different line colors. For example, if line graph 2272 is displayed as a black line, line graph 2273 may be displayed as a line color that is visually different from black, such as red, blue, or green.

[0130] 29 displays a line graph 2272 showing the "difference between cash balance and expenditure" for the target period based on the fundraising target proposed by the proposal server 3, and a line graph 2273 showing the "difference between cash balance and expenditure" for the target period based on the recommended information selected by user A1, in a manner that allows comparison. This allows user A1 to easily compare the fundraising when changing the fundraising target, and enables him or her to appropriately determine the fundraising target.

[0131] [Major Effects of the Present Embodiment] As described above, according to this embodiment, by visualizing the future cash flow situation when a document to be used for fund raising is specified, it is possible to make it easier for users to understand the future cash flow situation.

[0132] Furthermore, the proposal server 3 transmits to the user terminal 1 specific fund-raising sources (or ledger forms) that provide fund-raising that meets the predetermined conditions requested by the user A1. In other words, the proposal server 3 makes a proposal to the user terminal 1 indicating "where" to apply for fund-raising, thereby resolving the problem that the user A1 has difficulty in finding fund-raising sources (or ledger forms) that meet the conditions that the user A1 expects.

[0133] Furthermore, the proposal server 3 transmits information indicating a specific form determined based on predetermined conditions from among multiple forms issued when 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 funding from a predetermined fund-raising source, thereby resolving the problem that user A1 has difficulty finding a fund-raising source that meets the conditions he or she envisions.

[0134] 〔supplement〕 After step S49 in FIG. 20, the proposal server 3 may apply for step S4 in FIG. 1 on behalf of the user A1.

[0135] 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 console, a device dedicated to video calls, etc. The presenter terminal is an example of another communication terminal.

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

[0137] Each function in the above-described embodiments can be realized by one or more processing circuits. Here, the "processing circuit" in the present embodiment includes a processor programmed to execute each function by software, such as a processor implemented by an electronic circuit, and devices designed to execute each of the above-described functions, such as an ASIC (Application Specific Integrated Circuit), a DSP (Digital Signal Processor), an FPGA (Field Programmable Gate Array), a SOC (System on a Chip), a GPU, and a conventional circuit module.

[0138] Additionally, each of the servers 3, 5, and 7 described in the above embodiments merely represents one of multiple computing environments for implementing the embodiments disclosed herein. For example, the proposal server 3 may include multiple 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, etc., and perform the processes disclosed herein. Similarly, the proposal server 3 may include multiple computing devices configured to communicate with each other.

[0139] 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. Furthermore, the elements of the proposal server 3 and other servers can be combined into one server or separated into multiple devices.

[0140] Furthermore, in communications between each terminal and each server, other servers, routers, etc. may relay data.

[0141] 〔summary〕 The present embodiment will be summarized below. Note that the descriptions in parentheses do not limit the scope of the claims, but are merely examples.

[0142] A proposal server 3 provides information via a communication network 100 to a user terminal 1 of a user who provides or plans to provide a product or service to a business partner, and receives condition information sent by the user terminal 1 indicating specified conditions for fundraising using a form issued when the user provides the product or service to be provided (S43), and transmits data constituting a cash flow screen showing the future cash flow situation, which is based on information from a specific form that satisfies the specified conditions, to be received by the user terminal 1 (S47). [Explanation of symbols]

[0143] 1. User terminal 3 Proposal Server 5 Funding Service Server 7. Credit Information Server 11 Transmitter / Receiver 12 Reception 14 Display control unit 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

Claims

1. A proposal server that provides information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner, a receiving means for receiving condition information indicating the type of document to be funded, transmitted by the user terminal, by receiving from the user one or more selections from reception fields for document types including at least an invoice, an order form, and an estimate, displayed on the screen of the user terminal; a transmitting means for transmitting data constituting a cash flow screen showing the future cash flow status, the data being based on information of a specific form that satisfies the type of form selected by the user as the target of the fund raising, so that the data can be received by the user terminal; A proposal server comprising:

2. 2. The proposal server according to claim 1, wherein the information on the specific form is information indicating the amount of the claim related to the specific form or the payment due date of the claim related to the specific form.

3. 3. The proposal server according to claim 2, a calculation means for calculating a cash balance in the future cash flow based on the amount of the receivables related to the specific ledger; The proposal server is characterized in that the data constituting the cash flow screen includes information indicating the cash balance calculated by the calculation means.

4. the calculation means calculates the cash balance for each target period in the future cash flow based on the payment due date of the receivables related to the specific document; 4. The proposal server according to claim 3, wherein the data constituting the cash flow screen includes information indicating the cash balance for each of the target periods calculated by the calculation means.

5. the calculation means calculates the difference between the total amount of funds raised using the specific ledger and the cash balance for a target period to which the payment due date set by the specific ledger belongs, and the amount of expenditure for the target period; 5. The proposal server according to claim 3, wherein the data constituting the cash flow screen includes information indicating the difference calculated by the calculation means.

6. The receiving means further receives information transmitted from the user terminal indicating a second form that satisfies the type of form for which the fundraising is to be conducted and that is different from the specific form; The calculation means further calculates a second difference, which is the difference between the amount of funds raised and the total amount of cash balance for the target period for the funds raised, and the amount of expenditure for the target period, using the second form; 6. The proposal server according to claim 5, wherein the data constituting the cash flow screen further includes information indicating the second difference calculated by the calculation means.

7. A proposal server as described in any one of claims 1 to 6, characterized in that the condition information further includes a commission rate priority condition for determining a specific fundraising source by prioritizing a low fundraising commission rate determined by the contents of the form, or a risk avoidance priority condition for determining a specific fundraising source by prioritizing a low level of reliability of the business partner related to the form.

8. A communication system constructed by a user terminal of a user who provides or plans to provide a product or service to a business partner, and a proposal server that provides information to the user terminal via a communication network, The user terminal transmits condition information indicating the type of form to be funded by accepting from the user one or more selections from reception fields for the type of form, including at least an invoice, an order form, and an estimate, displayed on the screen of the user terminal; the proposal server receives the condition information and transmits data constituting a cash flow screen showing the future cash flow situation, the cash flow screen being based on information on a specific form that satisfies the type of form selected by the user as the target of fund raising; The user terminal receives data that constitutes the cash flow screen. A communication system comprising:

9. A provision method executed by a proposal server that provides information via a communication network to a user terminal of a user who provides or plans to provide a product or service to a business partner, a receiving step of receiving condition information indicating the type of document to be funded, transmitted by the user terminal, by receiving from the user one or more selections from reception fields for document types including at least an invoice, an order form, and an estimate, displayed on the screen of the user terminal; a sending step of sending data constituting a cash flow screen showing the future cash flow status, the cash flow screen being based on information of a specific form that satisfies the type of form selected by the user as the target of the fund raising, to be received by the user terminal; A providing method characterized by carrying out the above.

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

Images