Provident fund payment method, device, electronic device and computer readable medium

Abstract

The present invention discloses a method, device, electronic device and computer-readable medium for providing housing provident fund, and relates to the field of automatic programming technology. The method comprises: receiving a request for verification of a housing provident fund submitted by a user terminal; verifying multiple bills carried by the request for verification of the housing provident fund; after the verification of multiple bills involved in the request for verification of the housing provident fund is passed, registering the multiple bills, and accounting for housing provident fund payment based on the registered multiple bills. Through the above steps, not only the flexibility of housing provident fund payment can be improved, the user experience of housing provident fund payment can be improved, but also the probability of errors in housing provident fund payment can be reduced.

Description

Technical Field

[0001] The present invention relates to the field of automatic program design technology, and in particular to a provident fund payment method, device, electronic equipment and computer-readable medium. Background Art

[0002] Provident Fund payment is the act of an employer depositing the housing provident fund borne by the employer and deducted on behalf of employees, as well as the housing provident fund voluntarily paid by self-employed individuals, freelancers, part-time employees and other personnel without fixed employment into a special housing provident fund account, including remittance and supplementary payment.

[0003] In the construction of the provident fund information system, the most primitive way to handle provident fund payment is manual handling by tellers. This method requires the unit's handler to bring checks and manually handle provident fund payment on site through bank tellers. The handling outlet staff will check the approved records of remittance and supplementary payment with the amount of the transfer check. Only when they match can the payment be processed. In this mode, when the unit submits multiple checks for remittance and payment, the temporary deposit business is involved only when there is a return check. The funds collected will be deposited into the central account and recorded in the temporary deposit. After all other funds have been collected, the bank counter will directly use the original temporary deposit to record the business account together with the last collected funds. When processing the business, the temporary deposit only involves the funds collected in the previous period.

[0004] After the housing provident fund system was connected to the settlement platform of the Ministry of Housing and Urban-Rural Development, the "three accounts in one" accounting mechanism was implemented in accordance with the requirements of the implementation of the standards. At the same time, according to the anti-money laundering regulations of the People's Bank of China, the internal bank account was cancelled as a transit transition, and each fund was directly recorded in the center's fund account. When multiple checks were deposited, multiple remittances were deposited, and the remittance amount did not match the amount approved by the system, a temporary deposit would be generated, which required the outlets and units to check one by one. When the balance of the temporary deposit was equal to the amount approved by the unit, the temporary deposit was used to handle the remittance. In this mode, since any unit can remit any amount of money to the center's bank account through online banking remittance, letter and telegraphic transfer, and check withdrawal at the paying bank, it is impossible to drive funds through business, resulting in a large number of uncollected accounts and temporary deposits. In response to such problems, the provident fund center often establishes rules and systems, clarifies the division of labor among departments, or reduces the occurrence of such transactions through real-time monitoring and timely reporting. However, the disadvantages of these measures are that they consume a lot of manpower and material resources and lack automation and intelligence.

[0005] To further facilitate payment by customers, the Housing Provident Fund Center has launched a commissioned collection method to automatically deduct the provident fund funds of the contributing units through contract signing. Under this model, the unit only needs to submit a remittance verification before the deduction date to ensure that the balance of funds in the settlement account is sufficient for deduction, and then the provident fund payment items can be automatically deducted.

[0006] The existing housing provident fund payment and deposit processing scheme has at least the following shortcomings: First, the original payment method of manual handling by tellers has a large manpower cost for both units and banks, and there is a risk of human operational errors in business handling; Second, the payment method of any unit remitting any amount of money into the central bank account cannot realize the driving of funds through business, and does not achieve the correspondence between one business account and one received fund information, resulting in a large number of uncollected accounts and temporary deposits, and the detection and processing of pending accounts will consume a lot of manpower and material resources; Third, the payment method of entrusted collection cannot guarantee the timeliness of collection, and the way in which each unit participates in the provident fund payment is not flexible enough. Summary of the invention

[0007] In view of this, the present invention provides a provident fund deposit method, device, electronic device and computer-readable medium, which can at least solve at least one of the problems existing in existing provident fund deposit schemes, such as poor flexibility, low timeliness, high probability of human operation errors, etc., and improve the user experience of provident fund deposit.

[0008] To achieve the above objective, according to a first aspect of the present invention, a provident fund payment method is provided.

[0009] The provident fund payment method of the present invention includes: receiving a payment verification request submitted by a user terminal; verifying multiple bills carried by the payment verification request; after the multiple bills involved in the payment verification request are verified, registering the multiple bills to record the provident fund payment based on the registered multiple bills.

[0010] Optionally, the method further includes: before receiving the deposit verification request submitted by the user terminal, sending account list information to the user terminal, so that the user terminal splits the total amount of the deposit verification service into multiple bills based on the account list information.

[0011] Optionally, the verification of multiple bills carried in the deposit verification request includes: when the deposit verification business type is a supplementary payment verification business, verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; and / or, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table.

[0012] Optionally, the verification of multiple bills carried in the deposit verification request includes: when the deposit verification business type is a remittance verification business, determining the total amount of the remittance verification business according to the remittance verification month, and verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; and / or, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table.

[0013] Optionally, the registering of the multiple bills includes: when the multiple bills include bills using a temporary deposit account, making a temporary deposit reservation, generating a bill record including a temporary deposit reservation number in a bill detail table, and setting the status of the bill record to a paid status; when the multiple bills include bills using a general payment account, generating a corresponding bill record in the bill detail table, and setting the status of the bill record to an unpaid status.

[0014] Optionally, the method also includes: after receiving a modification request from a user terminal for a bill for a deposit verification service, determining whether the bill requested to be modified by the user terminal meets the modification conditions; if the bill requested to be modified by the user terminal meets the modification conditions, updating the bill details table according to the modified bill information carried in the bill modification request.

[0015] Optionally, the method further includes: sending bill modification failure prompt information to the user terminal when the bill requested to be modified by the user terminal does not meet the modification conditions.

[0016] Optionally, the determination of whether the bill requested to be modified by the user terminal meets the modification conditions includes: querying the bill detail table according to the code of the bill requested to be modified to query the status of the corresponding bill record; when the status of the bill record is unpaid, confirming that the bill requested to be modified meets the modification conditions; otherwise, confirming that the bill requested to be modified does not meet the modification conditions; or, determining whether there is an account arrival notification that matches the bill requested to be modified; in the absence of an account arrival notification that matches the bill requested to be modified, confirming that the bill requested to be modified meets the modification conditions; otherwise, confirming that the bill requested to be modified does not meet the modification conditions.

[0017] Optionally, the method further includes: before updating the bill details list according to the modified bill information carried in the bill modification request, confirming that the sum of the payment amounts of each bill of the deposit verification business after modification is the same as the total amount of the deposit verification business.

[0018] Optionally, the method also includes: after receiving a request from a user terminal to cancel a deposit verification service, determining whether the deposit verification service requested to be canceled by the user terminal meets the cancellation conditions; if the deposit verification service requested to be canceled by the user terminal meets the cancellation conditions, setting the bill corresponding to the deposit verification service to an invalid state.

[0019] Optionally, the judgment as to whether the deposit verification business requested to be canceled by the user terminal meets the cancellation conditions includes: judging whether the billing records of the deposit verification business in the bill details table are all in an unpaid state; if the billing records corresponding to the deposit verification business are all in an unpaid state, confirming that the cancellation conditions are met; otherwise, confirming that the cancellation conditions are not met; or, judging whether there is an account arrival notification that matches the billing record of the deposit verification business; if there is no account arrival notification that matches the billing record of the deposit verification business, confirming that the cancellation conditions are met; otherwise, confirming that the cancellation conditions are not met.

[0020] Optionally, the method further includes: sending a cancellation failure prompt message to the user terminal when the deposit verification service requested to be canceled by the user terminal does not meet the cancellation conditions.

[0021] To achieve the above objective, according to a second aspect of the present invention, another provident fund payment method is provided.

[0022] The provident fund payment method of the present invention comprises: sending an account query request to a server; after receiving the account list information corresponding to the account query request returned by the server, displaying the account list information; providing a bill splitting control to split the total amount of the payment verification business into multiple bills based on the bill splitting control; sending the payment verification request carrying the multiple bills to the server; wherein, after the server verifies the multiple bills carried by the payment verification request, the server registers the multiple bills to perform provident fund payment accounting based on the registered multiple bills.

[0023] To achieve the above objective, another provident fund deposit device is provided according to a third aspect of the present invention.

[0024] The provident fund deposit device of the present invention comprises: a receiving module for receiving a deposit verification request submitted by a user terminal; a verification module for verifying multiple bills carried in the deposit verification request; and a registration module for registering the multiple bills after the multiple bills involved in the deposit verification request have been verified, so as to record the provident fund deposit based on the registered multiple bills.

[0025] To achieve the above-mentioned purpose, according to a fourth aspect of the present invention, another provident fund deposit device is provided.

[0026] The provident fund deposit device of the present invention comprises: a first sending module, used for sending an account query request to a server; a display module, used for displaying the account list information corresponding to the account query request after receiving the account list information returned by the server; a splitting module, used for providing a bill splitting control, so as to split the total amount of the deposit verification business into multiple bills based on the bill splitting control; a second sending module, used for sending the deposit verification request carrying the multiple bills to the server; wherein, after the server verifies the multiple bills carried by the deposit verification request, the server registers the multiple bills, so as to perform provident fund deposit accounting based on the registered multiple bills.

[0027] To achieve the above objective, according to a fifth aspect of the present invention, an electronic device is provided.

[0028] The electronic device of the present invention comprises: one or more processors; and a storage device for storing one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the provident fund deposit method of the present invention.

[0029] To achieve the above objective, according to a sixth aspect of the present invention, a computer readable medium is provided.

[0030] The computer-readable medium of the present invention stores a computer program thereon, and when the program is executed by a processor, the provident fund payment method of the present invention is implemented.

[0031] An embodiment of the above invention has the following advantages or beneficial effects: In the present invention, by receiving a deposit verification request submitted by a user terminal, multiple bills carried by the deposit verification request are verified, and after the multiple bills involved in the deposit verification request are verified, the multiple bills are registered, and provident fund deposit accounting is performed based on the registered multiple bills. These steps provide a new, bill-based provident fund deposit solution, which can not only improve the flexibility of provident fund deposits, improve the user experience of provident fund deposits, but also reduce the probability of errors in provident fund deposits.

[0032] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific implementation examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0034] Figure 1 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0035] Figure 2is a schematic diagram of the main flow of the provident fund payment method according to the first embodiment of the present invention;

[0036] Figure 3 This is a partial flow chart of the provident fund payment method according to the second embodiment of the present invention;

[0037] Figure 4 is another partial flow chart of the provident fund payment method according to the second embodiment of the present invention;

[0038] Figure 5 is a schematic diagram of another part of the flow chart of the provident fund payment method according to the second embodiment of the present invention;

[0039] Figure 6 is a schematic diagram of the main flow of the provident fund payment method according to the third embodiment of the present invention;

[0040] Figure 7 is a schematic diagram of main modules of a provident fund payment device according to a fourth embodiment of the present invention;

[0041] Figure 8 is a schematic diagram of main modules of a provident fund deposit device according to a fifth embodiment of the present invention;

[0042] Fig. 9 It is a schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present invention. DETAILED DESCRIPTION

[0043] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0044] It should be pointed out that the various embodiments of the present invention and the technical features in the embodiments may be combined with each other without affecting the implementation of the present invention.

[0045] Before describing the embodiments of the present invention in detail, some technical terms involved in the embodiments of the present invention are first explained.

[0046] Collective Payment and Deposit: refers to the process in which an organization that has registered for an account at a fund center pays the housing provident fund paid by the organization and on behalf of its employees to the fund center on a monthly basis within the prescribed period.

[0047] Supplementary Payment and Deposit: refers to the payment by the unit of the housing provident fund that should have been paid but not paid or deferred before the current month, as well as the housing provident fund that was missed or underpaid by the employees.

[0048] Figure 1 An exemplary system architecture 100 is shown to which the provident fund payment method or the provident fund payment device according to the embodiment of the present invention can be applied.

[0049] like Figure 1 As shown, the system architecture 100 may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0050] Users (such as unit personnel who need to handle provident fund payment business, bank tellers, etc.) can use terminal devices 101, 102, 103 to interact with server 105 through network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, 103, such as provident fund payment applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0051] The terminal devices 101 , 102 , and 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0052] The server 105 may be a server that provides various services, such as a background management server that provides support for provident fund payment applications browsed by users using the terminal devices 101, 102, and 103. For example, the background management server may process the provident fund payment request sent by the terminal device through the network, and feed back the processing result (such as the provident fund payment processing result) to the terminal device.

[0053] It should be noted that the provident fund payment methods provided in some embodiments of the present invention are generally executed by the server 105, and accordingly, the provident fund payment device is generally set in the server 105. In addition, the provident fund payment methods provided in other embodiments of the present invention are generally executed by terminal equipment, and accordingly, the provident fund payment device is generally set in the terminal equipment.

[0054] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0055] First embodiment

[0056] Figure 2 1 is a schematic diagram of the main flow of the provident fund payment method according to the first embodiment of the present invention. The provident fund payment method of the embodiment of the present invention is generally executed by the server. Figure 2 As shown, the housing provident fund payment method of the embodiment of the present invention includes:

[0057] Step S201: receiving a deposit verification request submitted by a user terminal.

[0058] Exemplarily, the user terminal is a terminal device such as a mobile phone, a computer, or a bank self-service terminal used by a unit handler who needs to make a provident fund deposit, or a terminal device used by a bank teller who handles the provident fund deposit business. The unit handler or bank teller can query the account list of the deposit unit based on the user terminal, including ordinary payment account information and temporary deposit account information. Next, the terminal can distribute the total amount of the deposit verification to multiple accounts based on the account list of the deposit unit, that is, split the total amount of a deposit verification business into multiple bills. Then, the user terminal can send a deposit verification request carrying multiple bill information to the service end.

[0059] Step S202: verifying the multiple bills carried in the deposit verification request.

[0060] There are many types of housing fund payment verification, such as remittance verification and supplementary payment verification. Depending on the type of housing fund payment verification, the corresponding verification method can be adopted.

[0061] In an optional example, when the type of deposit verification business is a remittance verification business, step S202 includes: determining the total amount of the remittance verification business according to the remittance verification month, verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; if the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business, confirming that the verification has passed; otherwise, confirming that the verification has not passed. By verifying whether the sum of the amounts of the multiple bills after splitting is the same as the remittance verification total amount, the possibility of errors in the provident fund remittance business caused by errors in bill splitting can be reduced.

[0062] In another optional example, when the deposit verification business type is a remittance verification business, step S202 includes: verifying whether the payment accounts of the multiple bills are in the settlement registration account table. If the payment accounts of the multiple bills are all in the settlement registration account table, confirming that the verification is passed; otherwise, confirming that the verification is not passed.

[0063] In another optional example, when the type of deposit verification business is the remittance verification business, step S202 includes: step c, determining the total amount of the remittance verification business according to the remittance verification month, and verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; and step d, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, step c can be executed first. If the verification result of step c is that the amounts are different, it is confirmed that the verification has not passed, and there is no need to execute step d; if the verification result of step c is that the amounts are the same, step d is executed again. If the verification result of step d is that the payment accounts of the multiple bills are all located in the settlement registration account table, it is confirmed that the verification has passed; otherwise, it is confirmed that the verification has not passed. In addition, in specific implementation, step d can also be executed first. If the verification result of step d is that the payment accounts of the multiple bills are all located in the settlement registration account table, step c is executed again. By verifying the deposit amount and the deposit account, the possibility of errors in the remittance of provident funds can be further reduced.

[0064] In an optional example, when the deposit verification business type is the supplementary payment verification business, step S202 includes: verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; if the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business, confirming that the verification has passed; otherwise, confirming that the verification has not passed. By verifying whether the sum of the amounts of the split multiple bills is the same as the supplementary payment verification total amount, the possibility of errors in the provident fund supplementary payment business caused by errors in bill splitting can be reduced.

[0065] In another optional example, when the deposit verification business type is a supplementary payment verification business, step S202 includes: verifying whether the payment accounts of the multiple bills are located in the settlement registration account table. If the payment accounts of the multiple bills are all located in the settlement registration account table, confirm that the verification has passed; otherwise, confirm that the verification has not passed. By verifying whether the payment account of the bill is located in the settlement registration account table, it is possible to prevent the situation where the funds cannot be matched to the corresponding unit after they are received, and then cannot be matched to the corresponding bill of the unit, thereby reducing the possibility of failure in the supplementary payment of the provident fund.

[0066] In another optional example, when the type of deposit verification business is supplementary payment verification business, step S202 includes: step e, verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; and step f, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, step e can be executed first. If the verification result of step e is that the amounts are different, confirm that the verification has not passed, and there is no need to execute step f; if the verification result of step e is that the amounts are the same, then execute step f. If the verification result of step f is that the payment accounts of the multiple bills are all located in the settlement registration account table, confirm that the verification has passed; otherwise, confirm that the verification has not passed. In addition, in specific implementation, step f can also be executed first. If the verification result of step f is that the payment accounts of the multiple bills are all located in the settlement registration account table, then execute step e. By verifying the deposit amount and the deposit account, the possibility of errors in provident fund supplementary payment can be further reduced.

[0067] Optionally, when the deposit verification business type is a remittance verification or supplementary payment verification business, step S202 may further include the following steps: verify whether the billing month is the minimum month for deposit verification. If the billing month is the minimum month for deposit verification, execute other verification logics; if the billing month is not the minimum month for deposit verification, confirm that the verification has not passed.

[0068] Step S203: After the multiple bills involved in the deposit verification request are verified, the multiple bills are registered to perform provident fund deposit accounting based on the registered multiple bills.

[0069] Exemplarily, in step S203, the registering of the multiple bills includes: when the multiple bills include bills using a temporary deposit account, making a temporary deposit reservation, and then generating a bill record including the temporary deposit reservation number in the bill details table, and setting the status of the bill record to a paid status; when the multiple bills include bills using a general payment account, generating a corresponding bill record in the bill details table, and setting the status of the bill record to an unpaid status.

[0070] In the bill details table, the status of bill records includes: unpaid, paid, and deposited. After registering multiple bills for a deposit verification business, for bills using ordinary accounts, their status in the bill details table is set to unpaid, and for bills using temporary deposit accounts, their status in the bill details table is set to paid; after the unpaid bill is successfully matched with the arrival notification, the bill status is set to paid; after multiple bills for a deposit verification business are successfully automatically remitted or supplemented using temporary deposits, their status in the bill details table is set to "deposited".

[0071] Provident fund payment mainly includes the payment verification link and the payment entry link. After registering the multiple bills split through the payment verification link, the provident fund payment is recorded. Provident fund payment entry mainly includes the following steps: the system matches the arrival notification pushed by the settlement platform of the Ministry of Housing and Urban-Rural Development with the unit that needs to pay the provident fund, and then matches it to the unit's bill to realize the automatic payment of the bill. After multiple bills of a payment verification business are successfully paid, the system automatically triggers the automatic entry of remittance or supplementary payment, and automatically sets the bill status to "paid". In this way, business drives funds, meets the requirement that one business bill corresponds to one received fund, avoids the generation of excess uncollected accounts and temporary deposits, and one deposit business can use multiple bank accounts for payment. The handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, which gives the unit handlers great flexibility and convenience.

[0072] In the embodiment of the present invention, a new bill-based provident fund payment scheme different from the prior art is realized through the above steps. The bill-based provident fund payment scheme is different from the existing provident fund payment scheme in terms of the payment verification process and the automatic payment entry process after the payment verification. Moreover, a key improvement point compared with the existing provident fund payment scheme is that it can support the use of multiple bank settlement accounts for payment of a provident fund payment business. After the unit remits multiple payments to the settlement account, the system can automatically use multiple funds to handle the provident fund payment business. It is precisely because the scheme supports the depositing unit to use multiple accounts to deposit a provident fund business that the handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, thereby giving the depositing unit great flexibility and convenience. Moreover, the embodiment of the present invention improves the automation and intelligence level of handling the provident fund payment business through the above steps, and reduces the probability of errors in the provident fund payment.

[0073] Second embodiment

[0074] Figure 3 FIG. 1 is a schematic diagram of a portion of a method for providing housing provident fund according to a second embodiment of the present invention. The method of the embodiment of the present invention is generally executed by a server. Figure 3 As shown, the provident fund payment method of the embodiment of the present invention includes the following steps:

[0075] Step S301: sending account list information to a user terminal, so that the user terminal splits the total amount of the deposited and approved business into multiple bills based on the account list information.

[0076] In an optional example, after receiving the account query request from the user terminal, the server queries the settlement registration account table according to the account query request to obtain corresponding account list information, and then sends the queried account list information to the user terminal.

[0077] In another optional example, after the person in charge of the contributing unit logs into the provident fund contribution application, the server obtains the unique identifier of the contributing unit, queries the settlement registration account table based on the unique identifier of the contributing unit to obtain the corresponding account list information, and then pushes the queried account list information to the user terminal.

[0078] After receiving the account list information sent by the server, the user terminal displays the account list information to the user, so that the user can split the total amount of a deposit verification business into multiple accounts in the account list according to the actual situation, that is, split the total amount of a deposit verification business into multiple bills. Then, the user terminal can send a deposit verification request carrying multiple bill information to the server.

[0079] In the embodiment of the present invention, the server sends the account list information based on the terminal request or actively pushes the account list information, which helps the user terminal to conveniently and quickly split the total amount of a deposit verification business into multiple bills, thereby improving the user experience.

[0080] Step S302: receiving a deposit verification request sent by a user terminal.

[0081] In this step, the service end receives a deposit verification request sent by the user terminal. Exemplarily, the deposit verification request may include information such as a unique identifier of the deposit verification unit, accounts of the multiple bills split out, and payment amounts of each bill.

[0082] Step S303: verifying the multiple bills carried in the deposit verification request.

[0083] There are many types of housing fund payment verification, such as remittance verification and supplementary payment verification. Depending on the type of housing fund payment verification, the corresponding verification method can be adopted.

[0084] In an optional example, the housing fund payment verification type is remittance verification, and step S303 specifically includes: step c, determining the total amount of the remittance verification business according to the remittance verification month, and verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; and step d, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, step c can be executed first. If the verification result of step c is that the amounts are different, it is confirmed that the verification has not passed, and there is no need to execute step d; if the verification result of step c is that the amounts are the same, then step d is executed. If the verification result of step d is that the payment accounts of the multiple bills are all located in the settlement registration account table, it is confirmed that the verification has passed; otherwise, it is confirmed that the verification has not passed. In addition, in specific implementation, step d can also be executed first. If the verification result of step d is that the payment accounts of the multiple bills are all located in the settlement registration account table, then step c is executed. By verifying the deposit amount and the deposit account, the possibility of errors in housing fund remittance can be further reduced.

[0085] In another optional example, the housing provident fund payment verification type is supplementary payment verification, and step S303 specifically includes: step e, verifying whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; and step f, verifying whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, step e can be executed first. If the verification result of step e is that the amounts are different, it is confirmed that the verification has not passed, and there is no need to execute step f; if the verification result of step e is that the amounts are the same, then step f is executed. If the verification result of step f is that the payment accounts of the multiple bills are all located in the settlement registration account table, it is confirmed that the verification has passed; otherwise, it is confirmed that the verification has not passed. In addition, in specific implementation, step f can also be executed first. If the verification result of step f is that the payment accounts of the multiple bills are all located in the settlement registration account table, then step e is executed. By verifying the deposit amount and the deposit account, the possibility of errors in the provident fund supplementary payment can be further reduced.

[0086] Optionally, when the deposit verification business type is remittance verification or supplementary payment verification, step S303 may also include the following steps: verify whether the billing month is the minimum month for deposit verification. If the billing month is the minimum month for deposit verification, execute other verification logics; if the billing month is not the minimum month among the deposit verification months, confirm that the verification has not passed. In addition, optionally, when the deposit verification business type is remittance verification, it is also possible to check whether the deposit unit is a contracted unit or a general unit. If the deposit unit is a contracted unit, only single-month bills are allowed to be entered. If the deposit unit is a general unit, multiple-month bills are allowed to be entered.

[0087] If the verification passes, execute step S304; if the verification fails, execute step S305.

[0088] Step S304: register the multiple bills to record provident fund contributions based on the registered multiple bills.

[0089] Exemplarily, registering the multiple bills includes: when the multiple bills include bills using a temporary deposit account, making a temporary deposit reservation to freeze this part of the funds to prevent them from being used for other transactions (such as temporary deposit withdrawal, transfer, etc.), and then generating a bill record including the temporary deposit reservation number in the bill details table, and setting the status of the bill record to a paid status; when the multiple bills include bills using a general payment account, generating a corresponding bill record in the bill details table, and setting the status of the bill record to an unpaid status.

[0090] In the bill details table, the status of bill records includes: unpaid, paid, and deposited. After registering multiple bills for a deposit verification business, for bills using ordinary accounts, their status in the bill details table is set to unpaid, and for bills using temporary deposit accounts, their status in the bill details table is set to paid; after the unpaid bill is successfully matched with the arrival notification, the bill status is set to paid; after multiple bills for a deposit verification business are successfully automatically remitted or supplemented using temporary deposits, their status in the bill details table is set to "deposited".

[0091] Housing fund payment mainly includes payment verification and payment entry. Figure 3 The processing steps are shown. After registering the multiple bills split through the deposit verification link, the provident fund deposit is recorded. The provident fund deposit mainly includes the following steps: the system matches the receipt notification pushed by the settlement platform of the Ministry of Housing and Urban-Rural Development with the unit that needs to deposit the provident fund, and then matches it to the unit's bill to realize the automatic payment of the bill. After multiple bills of a deposit verification business are paid successfully, the system automatically triggers the automatic recording of remittance or supplementary payment, and automatically sets the bill status to "deposited". In this way, business drives funds, meets the requirement that one business bill corresponds to one received fund, avoids the generation of excess uncollected accounts and temporary deposits, and one deposit business can use multiple bank accounts for payment. The handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, which gives the unit handlers great flexibility and convenience.

[0092] Step S305: Send a deposit verification failure prompt message to the user terminal.

[0093] If the verification result of step S303 is that the verification fails, the service end sends a deposit verification failure prompt message such as "the deposit verification amount is inconsistent with the total amount of the bill" or "the bill account is not registered" to the user terminal. By sending the deposit verification failure prompt message to the user terminal, the user can promptly know the reason for the deposit verification failure so that adjustments can be made in time, thereby improving the user's experience of depositing provident funds.

[0094] In the embodiment of the present invention, a new housing provident fund payment scheme different from the prior art is realized through the above steps. The scheme supports the paying units to use multiple accounts to pay a housing provident fund business, so that the handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, thereby giving the paying units great flexibility and convenience. Moreover, the embodiment of the present invention improves the automation and intelligence level of handling housing provident fund payment business through the above steps, and reduces the probability of errors in housing provident fund payment.

[0095] After the remittance or supplementary payment is verified, in order to facilitate the unit handler to flexibly adjust the remittance amount of each account later, the second embodiment of the present invention also supports the modification and maintenance of the bills that have been remitted or supplementary payment verified.

[0096] Figure 4 FIG. 2 is another partial flow chart of the housing provident fund payment method according to the second embodiment of the present invention. Figure 4 As shown, the provident fund payment method of the embodiment of the present invention also includes a verification bill modification process, which specifically includes the following steps:

[0097] Step S401: receiving a request from a user terminal to modify a bill for a deposit verification service.

[0098] After the deposit verification is completed, the user terminal can modify the bill of the deposit verification service, and then send a modification request carrying the deposit verification service code and the modified bill information to the service end. In addition, in the specific implementation, the modification request for the bill of the deposit verification service may also include all the bill information of the deposit verification service before the modification, or include the bill information requested to be modified in the deposit verification service.

[0099] For example, suppose a deposit verification business includes bill 1, bill 2 and bill 3, and bill 1 uses ordinary payment account A with a payment amount of 1,000 yuan, bill 2 uses ordinary payment account B with a payment amount of 2,000 yuan, and bill 3 uses ordinary payment account C with a payment amount of 3,000 yuan. Suppose the user wants to keep bill 1 and bill 2 of the deposit verification business unchanged, and modify bill 3 to bill 4 of "using ordinary payment account d, payment amount of 3,000 yuan", then the modified bill information carried in the modification request includes the information of bill 1, bill 2, and bill 4. In addition, the modification request may also carry the bill information before modification, namely the information of bill 1, bill 2 and bill 3, or carry the bill information requested to be modified in the deposit verification business, namely the information of bill 3.

[0100] Step S402: Determine whether the bill requested to be modified meets the modification conditions.

[0101] In an optional example, step S402 includes: querying the bill details table according to the code of the bill requested to be modified to query the status of the corresponding bill record; when the status of the bill record is unpaid, confirming that the bill requested to be modified meets the modification conditions; otherwise, confirming that the bill requested to be modified does not meet the modification conditions. Specifically, in this optional example, the code of the bill requested to be modified, the account used, and the payment amount and other information can be carried in the modification request. After receiving the modification request for the bill of the deposit verification business, the modification request is parsed to parse the code of the bill requested to be modified. Then, querying the bill details table according to the code of the bill requested to be modified to query the status of the corresponding bill record, that is, the status of the bill requested to be modified. In the case that the status of the bill requested to be modified is unpaid, confirming that the bill meets the modification conditions; in the case that the bill requested to be modified is not unpaid (for example, it is paid or deposited), confirming that the bill does not meet the modification conditions.

[0102] In another optional example, step S402 includes: determining whether there is an arrival notification matching the bill requested to be modified; if there is no arrival notification matching the bill requested to be modified, confirming that the bill requested to be modified meets the modification conditions; otherwise, confirming that the bill requested to be modified does not meet the modification conditions. Specifically, in this optional example, the modification request may carry information such as the code of the bill requested to be modified, the account used, and the payment amount. After receiving the modification request for the bill of the deposit verification business, the modification request is parsed to parse out the code of the bill requested to be modified. Then, the bill details table is queried according to the code of the bill requested to be modified to query the business serial number in the corresponding bill record; if the business serial number has a value, it means that the bill has been matched with the arrival notification, and it is confirmed that the bill requested to be modified does not meet the modification conditions; if the business serial number is empty, it means that the bill has not been matched with the arrival notification, and it is confirmed that the bill requested to be modified meets the modification conditions.

[0103] If the bill requested to be modified meets the modification conditions, step S403 is executed; if the bill requested to be modified does not meet the modification conditions, step S404 is executed.

[0104] In the embodiment of the present invention, by determining whether the bill requested to be modified meets the modification conditions, and updating the bill details list after confirming that the bill requested to be modified meets the modification conditions, it can not only meet the user's needs to modify the bill of the deposit verification business and improve the flexibility of provident fund deposits, but also reduce the probability of errors in the process of modifying the provident fund deposit verification bill, which helps to further reduce the probability of errors in provident fund deposits.

[0105] Step S403: updating the bill details table according to the modified bill information carried in the bill modification request.

[0106] Optionally, before step S403, the method of the embodiment of the present invention further includes the following steps: confirming that the sum of the payment amounts of each bill of the deposit verification business after modification is the same as the total amount of the deposit verification business; and / or confirming that the account of each bill of the deposit verification business after modification exists in the settlement registration account table. By verifying the bill amount and / or the account information used before modifying the bill, the error probability in the modification process of the provident fund deposit verification bill can be reduced, which helps to further reduce the probability of error in provident fund deposit.

[0107] In step S403, when the code of the modified bill does not exist in the bill detail table, it indicates that there is no corresponding bill record in the bill detail table, then the updating of the bill detail table according to the modified bill information carried by the bill modification request is specifically: inserting a new account record in the bill detail table; when the code of the modified bill exists in the bill detail table, it indicates that there is a corresponding bill record in the bill detail table, then the updating of the bill detail table according to the modified bill information carried by the bill modification request is specifically: updating the corresponding bill record.

[0108] Optionally, when updating the bill details table according to the modified bill information carried by the bill modification request, an optimistic lock mode is adopted for updating. In this way, the lock overhead in the modification of the provident fund payment and verification bill can be saved, and the throughput of the system can be improved. Step S404: Send a bill modification failure prompt message to the user terminal.

[0109] When the result of the judgment in step S402 is that the bill requested to be modified does not meet the modification conditions, a bill modification failure prompt message such as "a sub-bill is being entered, modification is not allowed, please try again later" is sent to the user terminal.

[0110] In the embodiment of the present invention, the above steps realize the process of modifying the bills that have been remitted or approved for supplementary payment, which can meet the needs of users to modify the approved payment bills. Each user can modify the bills split from a deposit approval business according to actual conditions, thereby improving the user experience of provident fund deposits.

[0111] After the remittance or supplementary payment is verified, in order to meet the needs of the unit handler to cancel the payment verification due to various reasons, the second embodiment of the present invention also supports the cancellation of the payment verification business.

[0112] Figure 5 FIG. 2 is another partial flow chart of the housing provident fund payment method according to the second embodiment of the present invention. Figure 5 As shown, the provident fund payment method of the embodiment of the present invention also includes a payment verification business cancellation process, which specifically includes the following steps:

[0113] Step S501: receiving a request from a user terminal to cancel a deposit verification service.

[0114] After the deposit verification is completed, the user terminal can cancel the deposit verification service, and then send a request to cancel the deposit verification service carrying the deposit verification service code and other information to the server. The server receives the request to cancel the deposit verification service sent by the user terminal.

[0115] Step S502: Determine whether the deposit verification business requested to be cancelled meets the cancellation conditions.

[0116] In an optional example, step S502 includes: determining whether all bill records of the deposit verification business in the bill details table are in an unpaid state; if all bill records corresponding to the deposit verification business are in an unpaid state, confirming that the cancellation conditions are met; otherwise, confirming that the cancellation conditions are not met.

[0117] Specifically, in this optional example, the request to cancel the deposit verification business may carry information such as the code of the deposit verification business requested to be canceled. After receiving the request to cancel the deposit verification business, the request to cancel the deposit verification business is parsed to find out the code of the deposit verification business requested to be canceled. Then, the billing details table is queried according to the code of the deposit verification business requested to be canceled to find out the status of all bills corresponding to the deposit verification business requested to be canceled. If the status of the bills corresponding to the deposit verification business requested to be canceled are all unpaid, it is confirmed that the conditions for deposit verification cancellation are met; otherwise, it is confirmed that the conditions for deposit verification cancellation are not met.

[0118] In another optional example, step S502 includes: determining whether there is an arrival notification that matches the billing record of the deposit verification business; if there is no arrival notification that matches the billing record of the deposit verification business, confirming that the cancellation condition is met; otherwise, confirming that the cancellation condition is not met.

[0119] Specifically, in this optional example, the request to cancel the deposit verification business may carry information such as the code of the deposit verification business requested to be canceled. After receiving the request to cancel the deposit verification business, the request to cancel the deposit verification business is parsed to parse out the code of the deposit verification business requested to be canceled. Then, the billing details table is queried according to the code of the deposit verification business requested to be canceled to query the business serial number in all billing records corresponding to the deposit verification business requested to be canceled; if the business serial number in all billing records corresponding to the deposit verification business requested to be canceled has no value, it means that the billing records are not matched with the account arrival notification, and it is confirmed that the conditions for deposit verification cancellation are met; otherwise, it is confirmed that the conditions for deposit verification cancellation are not met.

[0120] If the deposit verification service requested to be cancelled meets the cancellation conditions, step S503 is executed; if the deposit verification service requested to be cancelled does not meet the cancellation conditions, step S504 is executed.

[0121] Step S503: setting the bill corresponding to the deposit verification service to an invalid state.

[0122] Exemplarily, in this step, each bill record corresponding to the deposit verification business requested to be canceled may be deleted from the bill details table; or, a deposit verification business status identification field may be set in the bill details table, and the field value of the field may be set to "invalid".

[0123] Optionally, when the bill corresponding to the deposit verification service is set to an invalid state, an optimistic lock mode is adopted for processing. In this way, the lock overhead in the provident fund deposit verification cancellation process can be saved, and the system throughput can be improved.

[0124] Step S504: Sending a cancellation failure prompt message to the user terminal.

[0125] When the deposit verification service requested to be canceled by the user terminal does not meet the cancellation conditions, a cancellation failure prompt message such as "A sub-bill is being credited to the account, and cancellation of verification is not allowed. Please try again later" or "Part of the bill funds have been deposited into the temporary deposit, and cancellation of verification is not allowed. Please cancel the temporary deposit and try again" is sent to the user terminal.

[0126] Optionally, the method of the embodiment of the present invention further comprises the following steps: if some bills in the deposit verification business are in the paid state, these bills are restored to the unpaid state through the temporary deposit cancellation process, and then the cancellation process for the deposit verification business is re-initiated. In addition, for temporary deposit type bills, before restoring the bill status to the unpaid state, the temporary deposit reservation needs to be cancelled.

[0127] In the embodiment of the present invention, the above steps realize the process of cancelling the remittance or supplementary payment verification business, which can meet the user's needs to cancel the payment verification business. Each user can cancel the payment verification business according to the actual situation, thereby improving the user experience of provident fund payment.

[0128] Third embodiment

[0129] Figure 6 1 is a schematic diagram of the main flow of the provident fund payment method according to the third embodiment of the present invention. The provident fund payment method of the embodiment of the present invention is generally executed by a user terminal. Figure 6 As shown, the housing provident fund payment method of the embodiment of the present invention includes:

[0130] Step S601: Send an account query request to the server.

[0131] For example, the user terminal is a mobile phone, computer, or bank self-service terminal used by a unit agent who needs to make a provident fund payment, or a terminal used by a bank teller who handles the provident fund payment business. The unit agent or bank teller can send an account query request to the server based on the user terminal.

[0132] After receiving the account query request, the server queries the corresponding account list information according to the account query request, and sends the queried account list information to the user terminal. Exemplarily, the account list information specifically includes ordinary payment account information and temporary deposit account information.

[0133] Step S602: after receiving the account list information corresponding to the account query request returned by the server, the account list information is displayed.

[0134] After receiving the account list information corresponding to the account query request, the user terminal displays the account list information to the user so that the user can understand which payment accounts are available for provident fund payment.

[0135] Step S603: Provide a bill splitting control to split the total amount of the deposited and approved business into multiple bills based on the bill splitting control.

[0136] In this step, the user terminal provides the user with a bill splitting control, based on which the user can allocate the total amount of the deposit verification to multiple accounts, that is, split the total amount of a deposit verification business into multiple bills.

[0137] Step S604: Sending a deposit verification request carrying the multiple bills to the server.

[0138] After detecting a specified event, such as detecting an event in which a user clicks a bill save button, a deposit verification request carrying multiple split bills is sent to the server. After receiving the deposit verification request, the server verifies the multiple bills carried by the deposit verification request, and registers the multiple bills involved in the deposit verification request after the verification passes, and performs provident fund deposit accounting based on the registered multiple bills.

[0139] In the embodiment of the present invention, a new housing provident fund payment scheme different from the prior art is realized through the above steps. The scheme supports the paying units to use multiple accounts to pay a housing provident fund business, so that the handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, thereby giving the paying units great flexibility and convenience. Moreover, the embodiment of the present invention improves the automation and intelligence level of handling housing provident fund payment business through the above steps, and reduces the probability of errors in housing provident fund payment.

[0140] Fourth embodiment

[0141] Figure 7 Schematic diagram of the main modules of the housing provident fund payment device according to the fourth embodiment of the present invention. Figure 7 As shown, the provident fund deposit device 700 of the embodiment of the present invention includes: a receiving module 701, a verification module 702, and a registration module 703.

[0142] The receiving module 701 is used to receive a deposit verification request submitted by a user terminal.

[0143] Exemplarily, the user terminal is a terminal device such as a mobile phone, a computer, or a bank self-service terminal used by a unit handler who needs to make a provident fund deposit, or a terminal device used by a bank teller who handles the provident fund deposit business. The unit handler or bank teller can query the account list of the deposit unit based on the user terminal, including ordinary payment account information and temporary deposit account information. Next, the terminal can distribute the total amount of the deposit verification to multiple accounts based on the account list of the deposit unit, that is, split the total amount of a deposit verification business into multiple bills. Then, the user terminal can send a deposit verification request carrying multiple bill information to the service end.

[0144] The verification module 702 is used to verify the multiple bills carried in the deposit verification request.

[0145] There are many types of housing fund payment verification, such as remittance verification and supplementary payment verification. Depending on the type of housing fund payment verification, the corresponding verification method can be adopted.

[0146] In an optional example, when the type of deposit verification business is a remittance verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 determines the total amount of the remittance verification business according to the remittance verification month, and verifies whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; if the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business, the verification module 702 confirms that the verification is passed; otherwise, the verification module 702 confirms that the verification is not passed. By verifying whether the sum of the amounts of the multiple bills after splitting is the same as the remittance verification total amount, the possibility of errors in the provident fund remittance business caused by errors in bill splitting can be reduced.

[0147] In another optional example, when the deposit verification business type is a remittance verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 verifies whether the payment accounts of the multiple bills are in the settlement registration account table. If the payment accounts of the multiple bills are all in the settlement registration account table, the verification module 702 confirms that the verification is passed; otherwise, the verification module 702 confirms that the verification is not passed.

[0148] In another optional example, when the deposit verification business type is the remittance verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 determines the total amount of the remittance verification business according to the remittance verification month, and verifies whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; and the verification module 702 verifies whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, the amount verification step can be performed first. If the verification result of the amount verification step is that the amounts are different, it is confirmed that the verification has not passed, and there is no need to perform the account verification step; if the verification result of the amount verification step is that the amounts are the same, the account verification step is performed again. If the verification result of the account verification step is that the payment accounts of the multiple bills are all located in the settlement registration account table, it is confirmed that the verification has passed; otherwise, it is confirmed that the verification has not passed. In addition, in specific implementation, the account verification step can also be performed first. If the verification result of the account verification step is that the payment accounts of the multiple bills are all located in the settlement registration account table, the amount verification step is performed again. By verifying the deposit amount and deposit account, the possibility of errors in provident fund remittance can be further reduced.

[0149] In an optional example, when the deposit verification business type is the supplementary payment verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 verifies whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; if the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business, the verification module 702 confirms that the verification is passed; otherwise, the verification module 702 confirms that the verification is not passed. By verifying whether the sum of the amounts of the multiple bills after splitting is the same as the total amount of the supplementary payment verification, the possibility of errors in the provident fund supplementary payment business caused by errors in bill splitting can be reduced.

[0150] In another optional example, when the type of deposit verification business is a supplementary payment verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 verifies whether the payment accounts of the multiple bills are located in the settlement registration account table. If the payment accounts of the multiple bills are all located in the settlement registration account table, the verification module 702 confirms that the verification has passed; otherwise, the verification module 702 confirms that the verification has not passed. By verifying whether the payment account of the bill is located in the settlement registration account table, it is possible to prevent the situation where the funds cannot be matched to the corresponding unit after arrival, and then cannot be matched to the corresponding bill of the unit, thereby reducing the possibility of failure in the supplementary payment of provident fund.

[0151] In another optional example, when the deposit verification business type is the supplementary payment verification business, the verification module 702 verifies the multiple bills carried by the deposit verification request, including: the verification module 702 verifies whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; and the verification module 702 verifies whether the payment accounts of the multiple bills are located in the settlement registration account table. In specific implementation, the amount verification step can be performed first, and then the account verification step; or, the account verification step can be performed first, and then the amount verification step. By verifying the deposit amount and the deposit account, the possibility of errors in the provident fund supplementary payment can be further reduced.

[0152] The registration module 703 is used to register the multiple bills involved in the deposit verification request after the multiple bills are verified, so as to record the provident fund deposit based on the registered multiple bills.

[0153] Exemplarily, the registration module 703 registers the multiple bills including: when the multiple bills include bills using a temporary deposit account, the registration module 703 makes a temporary deposit reservation, and then the registration module 703 generates a bill record including the temporary deposit reservation number in the bill details table, and sets the status of the bill record to a paid status; when the multiple bills include bills using an ordinary payment account, the registration module 703 generates a corresponding bill record in the bill details table, and sets the status of the bill record to an unpaid status.

[0154] In the bill details table, the status of bill records includes: unpaid, paid, and deposited. After registering multiple bills for a deposit verification business, for bills using ordinary accounts, their status in the bill details table is set to unpaid, and for bills using temporary deposit accounts, their status in the bill details table is set to paid; after the unpaid bill is successfully matched with the arrival notification, the bill status is set to paid; after multiple bills for a deposit verification business are successfully automatically remitted or supplemented using temporary deposits, their status in the bill details table is set to "deposited".

[0155] Provident fund payment mainly includes the payment verification link and the payment entry link. After registering the multiple bills split through the payment verification link, the provident fund payment is recorded. Provident fund payment entry mainly includes the following steps: the system matches the arrival notification pushed by the settlement platform of the Ministry of Housing and Urban-Rural Development with the unit that needs to pay the provident fund, and then matches it to the unit's bill to realize the automatic payment of the bill. After multiple bills of a payment verification business are successfully paid, the system automatically triggers the automatic entry of remittance or supplementary payment, and automatically sets the bill status to "paid". In this way, business drives funds, meets the requirement that one business bill corresponds to one received fund, avoids the generation of excess uncollected accounts and temporary deposits, and one deposit business can use multiple bank accounts for payment. The handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, which gives the unit handlers great flexibility and convenience.

[0156] In the embodiment of the present invention, a new housing provident fund payment scheme different from the prior art is realized through the above device. The scheme supports the payment unit to use multiple accounts to pay a housing provident fund business, so that the handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, thereby giving the payment unit great flexibility and convenience. Moreover, the embodiment of the present invention improves the automation and intelligence level of handling housing provident fund payment business through the above steps, and reduces the probability of errors in housing provident fund payment.

[0157] Fifth embodiment

[0158] Figure 8 Schematic diagram of the main modules of the housing provident fund payment device according to the fifth embodiment of the present invention. Figure 8 As shown, the provident fund deposit device 800 of the embodiment of the present invention includes: a first sending module 801, a display module 802, a splitting module 803, and a second sending module 804.

[0159] The first sending module 801 is used to send an account query request to the server.

[0160] Exemplarily, the user terminal is a mobile phone, computer, or bank self-service terminal used by a unit agent who needs to make a provident fund payment, or a terminal used by a bank teller who handles a provident fund payment. The unit agent or bank teller can send an account query request to the server based on the first sending module 801 of the user terminal.

[0161] After receiving the account query request, the server queries the corresponding account list information according to the account query request, and sends the queried account list information to the user terminal. Exemplarily, the account list information specifically includes ordinary payment account information and temporary deposit account information.

[0162] The display module 802 is used to display the account list information after receiving the account list information corresponding to the account query request returned by the server.

[0163] After receiving the account list information corresponding to the account query request, the user terminal displays the account list information to the user through the display module 802, so that the user can understand which payment accounts are available for provident fund payment.

[0164] The splitting module 803 is used to provide a bill splitting control to split the total amount of the deposit and approval business into multiple bills based on the bill splitting control.

[0165] The splitting module 803 provides the user with a bill splitting control, based on which the user can distribute the total amount of the deposit verification to multiple accounts, that is, split the total amount of a deposit verification business into multiple bills.

[0166] The second sending module 804 is used to send the deposit verification request carrying the multiple bills to the server.

[0167] After detecting a specified event, such as detecting an event in which a user clicks a bill save button, the second sending module 804 sends a payment verification request carrying multiple split bills to the server. After receiving the payment verification request, the server verifies the multiple bills carried by the payment verification request, and registers the multiple bills involved in the payment verification request after the verification passes, and performs provident fund payment accounting based on the registered multiple bills.

[0168] In the embodiment of the present invention, a new housing provident fund payment scheme different from the prior art is realized through the above device. The scheme supports the payment unit to use multiple accounts to pay a housing provident fund business, so that the handling personnel of each unit can split the bill according to their actual situation, and the remittance time and amount can be controlled by themselves, thereby giving the payment unit great flexibility and convenience. Moreover, the embodiment of the present invention improves the automation and intelligence level of handling housing provident fund payment business through the above steps, and reduces the probability of errors in housing provident fund payment.

[0169] Reference below Fig. 9 , which shows a schematic diagram of the structure of a computer system 900 of an electronic device suitable for implementing an embodiment of the present invention. Fig. 9 The computer system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0170] like Fig. 9As shown, the computer system 900 includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage part 908 into a random access memory (RAM) 903. In the RAM 903, various programs and data required for the operation of the system 900 are also stored. The CPU 901, the ROM 902, and the RAM 903 are connected to each other via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0171] The following components are connected to the I / O interface 905: an input section 906 including a keyboard, a mouse, etc.; an output section 907 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, a modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to the I / O interface 905 as needed. A removable medium 911, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 910 as needed, so that a computer program read therefrom is installed into the storage section 908 as needed.

[0172] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 909, and / or installed from the removable medium 911. When the computer program is executed by the central processing unit (CPU) 901, the above-mentioned functions defined in the system of the present invention are executed.

[0173] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0174] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0175] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be set in a processor. For example, they may be described as: a processor includes a receiving module, a verification module, and a registration module. The names of these modules do not, in some cases, constitute limitations on the modules themselves. For example, the receiving module may also be described as a "module for receiving a deposit verification request submitted by a user terminal."

[0176] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device executes the following process: receiving a deposit verification request submitted by a user terminal; verifying multiple bills carried by the deposit verification request; after the multiple bills involved in the deposit verification request are verified, registering the multiple bills, so as to record provident fund deposits based on the registered multiple bills.

[0177] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently and not be assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device executes the following process: sending an account query request to the server; after receiving the account list information corresponding to the account query request returned by the server, displaying the account list information; providing a bill splitting control to split the total amount of the deposit verification business into multiple bills based on the bill splitting control; sending the deposit verification request carrying the multiple bills to the server; wherein, after the server verifies the multiple bills carried by the deposit verification request, the multiple bills are registered to record the provident fund deposits based on the registered multiple bills.

[0178] According to the technical solution of the embodiment of the present invention, the flexibility of provident fund payment can be improved, and the user experience of provident fund payment can be improved.

[0179] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for providing housing provident fund, characterized in that: The method comprises: Receiving a deposit verification request submitted by a user terminal; Verifying multiple bills included in the deposit verification request; After the multiple bills involved in the deposit verification request are verified, the multiple bills are registered to record the provident fund deposit based on the registered multiple bills; The registering of the multiple bills includes: when the multiple bills include bills using a temporary deposit account, making a temporary deposit reservation, generating a bill record including a temporary deposit reservation number in a bill detail table, and setting the status of the bill record to a paid status.

2. The method according to claim 1, characterized in that The method further comprises: Before receiving the deposit verification request submitted by the user terminal, account list information is sent to the user terminal, so that the user terminal splits the total amount of the deposit verification service into multiple bills based on the account list information.

3. The method according to claim 1, characterized in that The verifying of the multiple bills carried in the deposit verification request includes: When the deposit verification business type is the supplementary payment verification business, verify whether the sum of the payment amounts of the multiple bills is the same as the total amount of the supplementary payment verification business; and / or verify whether the payment accounts of the multiple bills are in the settlement registration account table.

4. The method according to claim 1, characterized in that: The verifying of the multiple bills carried in the deposit verification request includes: When the deposit verification business type is the remittance verification business, the total amount of the remittance verification business is determined according to the remittance verification month, and it is verified whether the sum of the payment amounts of the multiple bills is the same as the total amount of the remittance verification business; and / or, it is verified whether the payment accounts of the multiple bills are located in the settlement registration account table.

5. The method according to claim 1, characterized in that: The registering of the multiple bills comprises: When the multiple bills include bills using a temporary deposit account, a temporary deposit reservation is made, a bill record including the temporary deposit reservation number is generated in the bill details table, and the status of the bill record is set to a paid status; when the multiple bills include bills using a general payment account, a corresponding bill record is generated in the bill details table, and the status of the bill record is set to an unpaid status.

6. The method according to claim 1, characterized in that The method further comprises: After receiving a modification request from a user terminal for a bill for a deposit verification service, determine whether the bill requested to be modified by the user terminal meets the modification conditions; if the bill requested to be modified by the user terminal meets the modification conditions, update the bill details table according to the modified bill information carried in the bill modification request.

7. The method according to claim 6, characterized in that The method further comprises: When the bill requested to be modified by the user terminal does not meet the modification conditions, a bill modification failure prompt message is sent to the user terminal.

8. The method according to claim 6, characterized in that The determining whether the bill requested to be modified by the user terminal meets the modification condition comprises: querying the bill details table according to the code of the bill requested to be modified to find out the status of the corresponding bill record; when the status of the bill record is unpaid, confirming that the bill requested to be modified meets the modification conditions; otherwise, confirming that the bill requested to be modified does not meet the modification conditions; or, Determine whether there is an arrival notification that matches the bill requested to be modified; if there is no arrival notification that matches the bill requested to be modified, confirm that the bill requested to be modified meets the modification conditions; otherwise, confirm that the bill requested to be modified does not meet the modification conditions.

9. The method according to claim 6, characterized in that The method further comprises: Before updating the bill details table according to the modified bill information carried in the bill modification request, it is confirmed that the sum of the payment amounts of the bills of the deposit verification service after modification is the same as the total amount of the deposit verification service.

10. The method according to claim 6, characterized in that The method further comprises: After receiving a request from a user terminal to cancel a deposit verification service, determine whether the deposit verification service requested to be canceled by the user terminal meets the cancellation conditions; if the deposit verification service requested to be canceled by the user terminal meets the cancellation conditions, set the bill corresponding to the deposit verification service to an invalid state.

11. The method according to claim 10, characterized in that The determining whether the deposit verification service requested to be cancelled by the user terminal meets the cancellation condition comprises: Determine whether all the billing records of the deposit verification business in the bill details table are in an unpaid state; if all the billing records corresponding to the deposit verification business are in an unpaid state, confirm that the cancellation condition is met; otherwise, confirm that the cancellation condition is not met; or, Determine whether there is an account arrival notification that matches the billing record of the deposit verification business; if there is no account arrival notification that matches the billing record of the deposit verification business, confirm that the cancellation conditions are met; otherwise, confirm that the cancellation conditions are not met.

12. The method according to claim 10, characterized in that The method further comprises: If the deposit verification service requested to be canceled by the user terminal does not meet the cancellation conditions, a verification cancellation failure prompt message is sent to the user terminal.

13. A method for providing housing provident fund, characterized in that: The method comprises: Send an account query request to the server; After receiving the account list information corresponding to the account query request returned by the server, displaying the account list information; Providing a bill splitting control to split the total amount of the deposited approved business into multiple bills based on the bill splitting control; A deposit verification request carrying the multiple bills is sent to the server; wherein, after the server has verified the multiple bills carried in the deposit verification request, the multiple bills are registered to record provident fund deposits based on the registered multiple bills; wherein, the registration of the multiple bills includes: when the multiple bills include bills using a temporary deposit account, a temporary deposit reservation is made, a bill record including the temporary deposit reservation number is generated in the bill details table, and the status of the bill record is set to a paid status.

14. A housing provident fund deposit device, characterized in that: The device comprises: A receiving module, used to receive a deposit verification request submitted by a user terminal; A verification module, used to verify multiple bills carried in the deposit verification request; A registration module, configured to register the multiple bills involved in the deposit verification request after the multiple bills are verified, so as to record the provident fund deposit based on the registered multiple bills; The registration module is specifically used to: when the multiple bills include a bill using a temporary deposit account, make a temporary deposit reservation, generate a bill record including a temporary deposit reservation number in a bill detail table, and set the status of the bill record to a paid status.

15. A housing provident fund deposit device, characterized in that: The device comprises: A first sending module, used to send an account query request to a server; A display module, configured to display the account list information after receiving the account list information corresponding to the account query request returned by the server; A splitting module, used to provide a bill splitting control, so as to split the total amount of the deposited and approved business into multiple bills based on the bill splitting control; The second sending module is used to send the deposit verification request carrying the multiple bills to the server; wherein, after the server verifies the multiple bills carried by the deposit verification request, the multiple bills are registered to record provident fund deposits based on the registered multiple bills; wherein, the registration of the multiple bills includes: when the multiple bills include bills using a temporary deposit account, a temporary deposit reservation is made, a bill record including a temporary deposit reservation number is generated in the bill details table, and the status of the bill record is set to a paid status.

16. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-12 and 13.

17. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 12 and 13 is implemented.

Images