WO2019000967A1 - 企业年金交易方法、装置及计算机可读存储介质 - Google Patents

企业年金交易方法、装置及计算机可读存储介质 Download PDF

Info

Publication number
WO2019000967A1
WO2019000967A1 PCT/CN2018/076202 CN2018076202W WO2019000967A1 WO 2019000967 A1 WO2019000967 A1 WO 2019000967A1 CN 2018076202 W CN2018076202 W CN 2018076202W WO 2019000967 A1 WO2019000967 A1 WO 2019000967A1
Authority
WO
WIPO (PCT)
Prior art keywords
enterprise
transaction
transaction request
annuity
abnormal
Prior art date
Application number
PCT/CN2018/076202
Other languages
English (en)
French (fr)
Inventor
胡凯豪
吕彤
杨宝成
Original Assignee
平安科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019000967A1 publication Critical patent/WO2019000967A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Definitions

  • the present invention relates to the field of data processing technologies, and in particular, to an enterprise annuity transaction method, apparatus, and computer readable storage medium.
  • Enterprise annuity refers to an old-age pension established by enterprises and their employees on the basis of legally participating in basic endowment insurance, based on national policies and the economic situation of the enterprise, aimed at improving the living standards of employees after retirement and providing important supplements to the national basic endowment insurance. Insurance form. Enterprise annuity can not only enhance the corporate image, enhance the attraction of talents, but also contribute to the harmonious and stable society. With the rapid development of enterprises, more and more enterprises have established enterprise annuities.
  • the account management system conducts a unified transaction for the transaction request corresponding to the annuity plan of all enterprise annuities, so as to facilitate the later maintenance.
  • the process of conducting a unified transaction if there is an abnormality in a transaction, all transactions cannot be continued, and other enterprise annuities without abnormal transactions cannot complete the transaction on time.
  • the main object of the present invention is to provide an enterprise annuity transaction method, device and computer readable storage medium, which are aimed at solving the problem that an enterprise annuity that cannot be abnormally traded due to abnormal transactions in the existing annuity transaction process cannot complete the transaction on time. problem.
  • the present invention provides an enterprise annuity transaction method, the enterprise annuity transaction method comprising the following steps:
  • the present invention also provides an enterprise annuity transaction apparatus, the enterprise annuity transaction apparatus comprising: a memory, a processor, and an enterprise annuity transaction stored on the memory and operable on the processor
  • the program when the enterprise annuity transaction program is executed by the processor, implements the steps of the method of any of the above.
  • the present invention also provides a computer readable storage medium having stored therein an enterprise annuity transaction program, wherein the enterprise annuity transaction program is executed by a processor to implement any of the above The steps of the enterprise annuity transaction method described.
  • the invention obtains the first transaction request corresponding to the current enterprise annuity, acquires the business identifier of the enterprise annuity corresponding to the first transaction request, and the enterprise identifier, and then classifies the first transaction request based on the obtained service identifier and the enterprise identifier, And then, when there is an abnormal transaction request in the second transaction request, acquiring a third transaction request corresponding to the abnormal transaction request, and finally performing a transaction operation based on the fourth transaction request to obtain the first transaction data, and implementing the classified
  • the transaction request corresponding to each abnormal annuity plan and the annuity plan of the abnormal business identifier are processed first, and the transaction request corresponding to the abnormal enterprise identification is avoided, so that all the transactions cannot be continued due to the abnormal transaction request.
  • the situation is sent, which can ensure that enterprises without abnormal transaction requests can smoothly conduct transactions, improve the efficiency of enterprise annuity transactions, and improve the user experience.
  • FIG. 1 is a schematic structural diagram of a terminal to which an enterprise annuity transaction device belongs in a hardware operating environment according to an embodiment of the present invention
  • FIG. 2 is a schematic flow chart of a first embodiment of an enterprise annuity transaction method according to the present invention.
  • FIG. 1 is a schematic structural diagram of a terminal to which an enterprise annuity transaction apparatus belongs in a hardware operation environment according to an embodiment of the present invention.
  • the terminal may be a PC, or may be a terminal device such as a smart phone, a tablet computer, or a portable computer.
  • the terminal may include a processor 1001, such as a CPU, a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002.
  • the communication bus 1002 is used to implement connection communication between these components.
  • the user interface 1003 can include a display, an input unit such as a keyboard, and the optional user interface 1003 can also include a standard wired interface, a wireless interface.
  • the network interface 1004 can optionally include a standard wired interface, a wireless interface (such as a WI-FI interface).
  • the memory 1005 may be a high speed RAM memory or a stable memory (non-volatile) Memory), such as disk storage.
  • the memory 1005 can also optionally be a storage device independent of the aforementioned processor 1001.
  • the terminal may further include a camera, RF (Radio) Frequency, RF) circuits, sensors, audio circuits, WiFi modules, and more.
  • sensors such as light sensors, motion sensors, and other sensors.
  • the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display according to the brightness of the ambient light, and the proximity sensor may turn off the display and/or when the mobile terminal moves to the ear. Backlighting.
  • the gravity acceleration sensor can detect the magnitude of acceleration in each direction (usually three axes), and can detect the magnitude and direction of gravity when stationary, and can be used to identify the posture of the mobile terminal (such as horizontal and vertical screen switching, Related games, magnetometer attitude calibration), vibration recognition related functions (such as pedometer, tapping), etc.; of course, the mobile terminal can also be equipped with other sensors such as gyroscope, barometer, hygrometer, thermometer, infrared sensor, etc. No longer.
  • terminal structure shown in FIG. 1 does not constitute a limitation to the terminal, and may include more or less components than those illustrated, or a combination of certain components, or different component arrangements.
  • an operating system may be included in the memory 1005 as a computer storage medium.
  • a network communication module may be included in the memory 1005 as a computer storage medium.
  • a user interface module may be included in the memory 1005 as a computer storage medium.
  • an enterprise annuity transaction program may be included in the memory 1005 as a computer storage medium.
  • the network interface 1004 is mainly used to connect to the background server and perform data communication with the background server;
  • the user interface 1003 is mainly used to connect the client (user end), and perform data communication with the client; and the processor
  • the enterprise annuity transaction program stored in the memory 1005 can be used to execute the enterprise annuity transaction method provided in the embodiment of the present application.
  • FIG. 2 is a schematic flowchart of a first embodiment of the present invention with reference to FIG. 2.
  • the enterprise annuity transaction method includes:
  • Step S110 Acquire a first transaction request corresponding to the current enterprise annuity, and obtain a business identifier and an enterprise identifier of the enterprise annuity corresponding to the first transaction request;
  • the account of the enterprise user includes the enterprise account and the personal account
  • the enterprise annuity transaction includes: the payment operation of the enterprise account and the personal account in an annuity plan of the enterprise annuity Payment operation, registration and payment operation of the enterprise account, registration and payment operation of the personal account of the employee of the enterprise account, the operation of adding a new annuity plan for an enterprise, and the enterprise of the enterprise in the newly added annuity plan
  • User payment operation and payment operation of personal account cancellation of the account enterprise of an enterprise in an annuity plan, cancellation of the personal account of the employee in the enterprise, registration of the employee account of an enterprise in an annuity plan or Logout and so on.
  • the business identifier of the enterprise annuity refers to the identification information of the annuity plan corresponding to the enterprise annuity, and each annuity plan corresponds to a unique business identifier.
  • the corporate logo refers to the identification information of all participating companies in the annuity plan.
  • the enterprise annuity of the embodiment includes one or more annuity plans
  • the first transaction request is all transaction requests that are not processed in all annuity plans of the current enterprise annuity, including those received but not processed in the previous transaction cycle of the annuity plan
  • the transaction request and the transaction request received in the current transaction cycle specifically, the first transaction request may include a payment request of the enterprise account in the annuity plan of the enterprise annuity, a payment request of the personal account in the annuity plan of the enterprise annuity, and a business account registration Request, increase request for new annuity plan in enterprise account, personal account registration request, personal account cancellation request, etc.
  • the enterprise user when the corresponding enterprise first establishes an enterprise annuity, the enterprise user registers the enterprise account through the enterprise account registration request; The enterprise user adds a new annuity plan to the existing enterprise account by adding a request; the personal account registration request adds a new personal account to the corresponding enterprise account, and after an employee in a certain enterprise leaves or retires, the user has received the new annuity plan. All annuities, through personal account notes Request cancellation of the employee corresponding personal accounts.
  • the first transaction request corresponding to the current enterprise annuity, and the service identifier and the enterprise identifier corresponding to the first transaction request are obtained, so as to facilitate the obtained service identifier and the enterprise identifier. Classify the first transaction request.
  • Step S120 Perform a classification operation on the first transaction request based on the obtained service identifier and the enterprise identifier to obtain a second transaction request.
  • the second transaction request is a transaction request corresponding to each enterprise identifier in the transaction request of the annuity plan corresponding to the business identifier, that is, a transaction request of each enterprise in each annuity plan of the current enterprise annuity, specifically, the first transaction request
  • the transaction request of each annuity plan of the current enterprise annuity is obtained, and then the transaction request for each annuity plan is classified according to the company logo, and the transaction of each enterprise in each annuity plan of the current enterprise annuity is obtained.
  • the service identifier corresponding to the first transaction request is obtained, and When the enterprise is identified, the first transaction request is classified according to the service identifier and the enterprise identifier, and then the second transaction request corresponding to each enterprise identifier in the annuity plan corresponding to each service identifier is obtained, so as to request transactions for different annuity plans and
  • the trading requests of different companies in the same annuity plan are subject to independent trading operations.
  • Each of the annuity plans corresponds to a plurality of enterprise identifiers, that is, each annuity plan after the classification corresponds to a plurality of sets of transaction requests, that is, the second transaction request includes multiple sets of transaction requests.
  • Step S130 when there is an abnormal transaction request in the second transaction request, acquiring a third transaction request corresponding to the abnormal transaction request;
  • the second transaction request when the second transaction request is obtained by performing the classification operation on the first transaction request, determining whether the second transaction request has an abnormal transaction request, and determining an abnormal transaction when there is an abnormal transaction request in the second transaction request.
  • the corresponding enterprise identifier, that is, the abnormal enterprise identifier, and the service identifier corresponding to the abnormal transaction request, that is, the abnormal service identifier, and the third transaction request is obtained according to the abnormal service identifier and the abnormal enterprise identifier, wherein the third transaction request is an abnormal service identifier.
  • the transaction request corresponding to the abnormal enterprise identifier that is, the third transaction request is all the transaction requests of the annuity plan whose business identifier is the abnormal business identifier, and the enterprise identifier is the enterprise of the abnormal enterprise logo.
  • Transaction request is all the transaction requests of the annuity plan whose business identifier is the abnormal business identifier, and the enterprise identifier is the enterprise of the abnormal enterprise logo.
  • the abnormal transaction request may include an abnormal payment request, for example, when an individual user account of a certain enterprise needs to be cancelled due to the change of nationality, that is, when the account cancellation request of the account currently exists, there is also a payment request for the user account. Wait.
  • Step S140 performing a transaction operation based on the fourth transaction request to obtain first transaction data, wherein the fourth transaction request is a transaction request other than the third transaction request in the second transaction request.
  • the fourth transaction request is a transaction request other than the third transaction request in the second transaction request, that is, the fourth transaction request includes a transaction request corresponding to the service identifier without abnormality in the second transaction request, and no abnormal service identifier The transaction request corresponding to the abnormal corporate identity.
  • the transaction request corresponding to the business identifier without abnormality and the transaction request corresponding to the enterprise identifier without abnormality in the abnormal business identifier can be successfully completed, so as to ensure that the enterprise without abnormal transaction request can smoothly carry out the transaction.
  • the fourth transaction request includes the payment request of the enterprise account in the annuity plan of the enterprise annuity
  • the payment operation is performed according to the payment request
  • the enterprise account in the annuity plan may be updated according to the payment amount corresponding to the payment request.
  • the account balance which is the sum of the original account balance of the business account and the payment amount, which is the new account balance of the enterprise account in the annuity plan
  • the fourth transaction request includes the payment request of the personal account in the annuity plan of the enterprise annuity.
  • the payment operation is performed.
  • the account balance of the personal account in the annuity plan may be updated according to the payment amount corresponding to the payment request, and the original account balance of the individual account is added to the payment amount as the annuity plan.
  • the transaction operations corresponding to other transaction requests are not repeated here.
  • transactions are performed in a certain order, for example, according to the ranking of the enterprise identification, or the ranking of the business identification, etc., therefore, when the fourth transaction request is traded, the original sorting manner may be followed.
  • the transaction operation is performed on each group of the fourth transaction request in turn.
  • the abnormal cause of the abnormal transaction request in the third transaction request may be determined by manual checking or the like, and the abnormality information including the abnormal cause and the abnormal transaction request is sent to the abnormal identifier.
  • the first preset terminal corresponding to the information for the enterprise user corresponding to the first preset terminal, re-edits the transaction request according to the abnormal information, and proposes the transaction again.
  • the enterprise annuity transaction method proposed in this embodiment obtains the first transaction request corresponding to the current enterprise annuity, acquires the business identifier of the enterprise annuity corresponding to the first transaction request, and the enterprise identifier, and then is based on the obtained service identifier and the enterprise identification pair.
  • the first transaction request performs a classification operation, and then, when there is an abnormal transaction request in the second transaction request, acquiring a third transaction request corresponding to the abnormal transaction request, and finally performing a transaction operation based on the fourth transaction request to obtain the first transaction data, and implementing
  • the transaction request corresponding to each abnormal annuity plan and the annuity plan of the abnormal business identifier are dealt with in the absence of the abnormal business identifier to avoid the abnormal transaction request.
  • the situation that all transactions cannot be continued can be sent, thereby ensuring that enterprises without abnormal transaction requests can smoothly conduct transactions, improve the efficiency of enterprise annuity transactions, and improve the user experience.
  • step S130 includes:
  • Step S131 when there is an abnormal transaction request in the second transaction request, determining an abnormal enterprise identifier and an abnormal service identifier corresponding to the abnormal transaction request;
  • the second transaction request when the second transaction request is obtained by performing the classification operation on the first transaction request, determining whether the second transaction request has an abnormal transaction request, and determining an abnormal transaction when there is an abnormal transaction request in the second transaction request
  • the enterprise ID corresponding to the request is the abnormal enterprise identifier
  • the service identifier corresponding to the abnormal transaction request is the abnormal service identifier
  • Step S132 Acquire the third transaction request based on the abnormal enterprise identifier and the abnormal service identifier.
  • the third transaction request is obtained according to the abnormal service identifier and the abnormal enterprise identifier.
  • the third transaction request is a transaction request corresponding to the annuity plan corresponding to the abnormal enterprise identifier, and all the transaction requests corresponding to the abnormal enterprise identifier.
  • the enterprise annuity transaction method proposed in this embodiment determines an abnormal enterprise identifier and an abnormal service identifier corresponding to the abnormal transaction request when there is an abnormal transaction request in the second transaction request, and then acquires the third transaction based on the abnormal enterprise identifier and the abnormal service identifier.
  • the request is implemented to obtain a third transaction request according to the abnormal enterprise identifier and the abnormal business identifier, so that the third transaction request can be accurately determined, so that the fourth transaction request can smoothly perform the transaction operation, thereby avoiding all the problems caused by the abnormal transaction request.
  • the transaction can not be sent continuously, which can ensure that the company without abnormal transaction request can smoothly carry out the transaction, further improving the efficiency of the enterprise annuity transaction.
  • step S120 includes:
  • Step S121 acquiring a business scenario in the annuity plan corresponding to the service identifier
  • the second transaction request may be re-classified according to the business scenario to reduce the number of transaction requests in the third transaction request again. Therefore, the business scenario in the annuity plan corresponding to the business identifier can be obtained.
  • Step S122 Perform a classification operation on the first transaction request to obtain the second transaction request, based on the service identifier, the enterprise identifier, and the service scenario.
  • the second transaction request is a transaction request of each business scenario included in each enterprise identifier in the transaction request of the annuity plan corresponding to the service identifier, that is, the transaction request of the annuity plan corresponding to each service identifier is grouped according to each enterprise identifier.
  • the group transaction requests are grouped again according to the business scenario, and then multiple sets of second transaction requests are obtained.
  • the enterprise annuity transaction method proposed in this embodiment obtains the business scenario in the annuity plan corresponding to the service identifier, and then classifies the first transaction request based on the service identifier, the enterprise identifier, and the business scenario, and can reduce the classification as much as possible.
  • the number of transaction requests included in each group of second transaction requests thereby reducing the number of transaction requests included in the third transaction request, enabling as many transaction requests as possible to conduct smooth transactions, further improving the enterprise annuity The efficiency of the transaction.
  • the enterprise annuity transaction method further includes:
  • Step S150 when there is no abnormal transaction request in the second transaction request, performing a transaction operation based on the second transaction request to obtain second transaction data;
  • Step S160 performing a summary operation on the second transaction data based on the service identifier and the enterprise identifier.
  • the second transaction request when there is no abnormal transaction request in the second transaction request, the second transaction request is subjected to a transaction operation to obtain the first transaction data, and the first transaction is based on the service identifier and the enterprise identifier.
  • the data is aggregated.
  • the summary operation refers to summarizing the second transaction data based on the enterprise identifier, and after the second transaction data is summarized, the aggregated data corresponding to each enterprise identifier is separately sent to the terminal corresponding to each enterprise identifier, so that each enterprise user Being able to get timely information on the transaction, of course, can also generate various reports according to various needs.
  • transactions are performed in a certain order, for example, according to the ranking of the enterprise identification, or the ranking of the business identification, etc., therefore, when the transaction operation of the second transaction request is performed, the original sorting manner may be followed.
  • the transaction operation is performed on each group of the second transaction request in turn.
  • the enterprise annuity transaction method proposed in this embodiment when there is no abnormal transaction request in the second transaction request, performs a transaction operation based on the second transaction request to obtain the second transaction data, and then the second based on the service identifier and the enterprise identifier.
  • the transaction data is summarized and realized, and the transaction operation is directly performed when there is no abnormal transaction request in the second transaction request, thereby further improving the efficiency of the enterprise annuity transaction.
  • the enterprise annuity transaction method further includes:
  • Step S170 acquiring abnormal information of the abnormal transaction request
  • the abnormality detection rule of the abnormal transaction request may be set, and the abnormal cause of the abnormal transaction request may be detected according to the abnormality detection rule.
  • the abnormal cause of the abnormal transaction request may also be determined by manual inspection.
  • the abnormality information includes an abnormal reason of the abnormal transaction request, an abnormal transaction request, and a third transaction request.
  • Step S180 Send the abnormality information to the first preset terminal corresponding to the abnormal transaction request.
  • the abnormality information when the abnormality information is acquired, the abnormality information is sent to the first preset terminal corresponding to the abnormal transaction request, and when the first preset terminal receives the abnormality information, the first preset terminal corresponds to
  • the enterprise user can re-edit the abnormal transaction request according to the abnormal information, update the third transaction request according to the edited transaction request, and feed back the updated third transaction request, and after receiving the updated third transaction request, determine the update.
  • the transaction operation is performed based on the updated third transaction request.
  • the first preset terminal is a terminal corresponding to the abnormal enterprise identifier, and the abnormal enterprise identifier may be determined by using an abnormal transaction request, thereby determining the first preset terminal. If the abnormal transaction identifier corresponding to the abnormal transaction request is multiple, the third transaction request includes multiple sets of transaction requests respectively corresponding to the abnormal enterprise identifier, and the first preset terminal is multiple, and therefore, the abnormal information is sent and sent separately. A plurality of different abnormal information to the corresponding first preset terminal.
  • the abnormal information may be sent to the first preset terminal corresponding to the abnormal transaction request by using a short message, an email, an instant message, or the like.
  • the enterprise annuity transaction method of the present embodiment by acquiring the abnormal information of the abnormal transaction request, sends the abnormality information to the first preset terminal corresponding to the abnormal transaction request, so that the enterprise user corresponding to the first preset terminal can re Editing the abnormal transaction request, thereby enabling the abnormal transaction request in the third transaction request to be updated as soon as possible, so that the updated third transaction request can complete the transaction in time, further improving the efficiency of the enterprise annuity transaction.
  • the enterprise annuity transaction method further includes:
  • Step S190 performing a verification operation on the first transaction data
  • the verification operation of the first transaction data may be performed by using an existing verification method.
  • the enterprise identifier and the service identifier corresponding to the transaction data that the verification fails are obtained; and the pre-transaction data and the transaction request are obtained according to the enterprise identifier and the service identifier, that is, The transaction data and the transaction request corresponding to the transaction data corresponding to the unverified transaction data are verified; and the transaction data of the previous transaction period corresponding to the enterprise identifier and the business identifier is verified, and when the transaction data of the previous transaction date is verified, The transaction operation is performed again based on the pre-trade data and the transaction request to obtain the third transaction data, and the transaction data that the verification fails in the first transaction data is updated based on the third transaction data.
  • Step S200 Perform a summary operation on the first transaction data based on the service identifier and the enterprise identifier when the first transaction data is verified.
  • the summary operation refers to the aggregation of the first transaction data based on the enterprise identifier. After the first transaction data is aggregated, the aggregated data corresponding to each enterprise identifier is separately sent to the terminal corresponding to each enterprise identifier, so that each enterprise user Being able to get timely information on the transaction, of course, can also generate various reports according to various needs.
  • the enterprise annuity transaction method proposed in this embodiment performs a verification operation on the first transaction data, and when the first transaction data is verified, the first transaction data is summarized based on the service identifier and the enterprise identifier, and the first transaction is realized.
  • the data verification is summarized when it is passed, thereby ensuring the accuracy of the second transaction data, and further improving the accuracy and efficiency of the enterprise annuity transaction.
  • the enterprise annuity transaction method further includes:
  • Step S210 when receiving the transaction request for the enterprise annuity, acquiring the receiving method, the employee information, and the enterprise parameter information corresponding to the employee information corresponding to the receiving transaction request;
  • the company when receiving the transaction request for the enterprise annuity, the company obtains the enterprise parameter information corresponding to the collection method, the employee information, and the employee information corresponding to the transaction request, wherein the employee information includes: the working age, the payment period, and the work of the company.
  • the enterprise parameter information includes enterprise subsidy rule information, etc.
  • the enterprise subsidy rule information includes fixed compensation information or difference compensation information.
  • the fixed compensation information refers to the fixed compensation for the user each time the user receives the annuity according to the method prescribed by the enterprise.
  • Amount fixed compensation information means that when the user receives the annuity according to the method prescribed by the enterprise, when the current collection amount is less than the minimum amount received, the difference compensation is performed to receive the annuity according to the minimum amount received.
  • Step S220 Calculate a receiving parameter based on the receiving mode, the employee information, and the enterprise parameter information, where the receiving parameter includes a receiving time, a receiving amount, and a tax amount.
  • the receiving parameter of the user corresponding to the transaction request is calculated based on the receiving method, the employee information, and the enterprise parameter information, and specifically, according to the receiving transaction request
  • the corresponding algorithm of the corresponding enterprise calculates the receiving parameters, and the receiving parameters include the receiving time, the receiving amount, and the tax amount.
  • the user may receive the transaction request by selecting the option of the tax amount provided by the interface, and the receiving method corresponding to the receiving transaction request is the receiving method with the least tax amount, and the user receives the transaction according to the receiving transaction.
  • Requesting the corresponding collection parameters for the receipt of an annuity can ensure that the tax required is the least, so as to ensure the best interests of the user.
  • the flow in this embodiment may be different from the process of the enterprise annuity transaction in the foregoing embodiments, and may be before step S110, or after step S140, or between any two steps described above. Therefore, in this embodiment, The sequence between step S210 and step S220 and other steps is not specifically limited.
  • the enterprise annuity transaction method proposed in this embodiment acquires the enterprise parameter information corresponding to the collection method, the employee information, and the employee information corresponding to the transaction request when receiving the transaction request of the enterprise annuity, based on the collection method, the employee information, and the enterprise.
  • the parameter information is calculated and received, and the user can be provided with an optimal receiving parameter according to the receiving mode selected by the user, which is convenient for the user to select and improve the user experience.
  • an eighth embodiment of the enterprise annuity transaction method of the present invention is proposed.
  • the enterprise annuity transaction method further includes:
  • Step S230 when receiving the payment estimation request of the enterprise annuity, acquiring the enterprise identifier corresponding to the payment measurement request;
  • the enterprise user may trigger the payment measurement request through the payment measurement option of the enterprise annuity interface, and obtain the enterprise identification corresponding to the payment measurement request when receiving the payment estimation request of the enterprise annuity.
  • the input window may be displayed at the payment measurement option of the enterprise annuity interface, and the enterprise user inputs the corresponding enterprise identifier in the input window.
  • the payment measurement request carries a corresponding enterprise identifier, or one-to-one correspondence with the enterprise identifier, and the corresponding enterprise identifier can be obtained through the payment measurement request.
  • Step S240 obtaining an individual payment parameter corresponding to the personal account of the enterprise identifier and a first enterprise payment parameter, and a second enterprise payment parameter corresponding to the enterprise account of the enterprise identifier;
  • the personal payment parameter of the personal account corresponding to the enterprise when the enterprise identifier corresponding to the payment measurement request is obtained, the personal payment parameter of the personal account corresponding to the enterprise, the first enterprise payment parameter of the personal account, and the second enterprise of the enterprise account may be obtained according to the enterprise identifier.
  • Step S250 calculating an individual payment amount of the personal account based on the personal payment parameter, calculating a first enterprise payment amount of the personal account based on the first enterprise payment parameter, and calculating the based on the second enterprise payment parameter.
  • the personal payment parameter, the first enterprise payment parameter, and the second enterprise payment parameter are obtained, and the personal payment amount of the personal account is calculated based on the individual payment parameter, and the first enterprise payment parameter is calculated to calculate the first account of the personal account.
  • the amount of the enterprise payment and the amount of the second enterprise payment based on the enterprise account of the second enterprise payment parameter, wherein different enterprises have different calculation rules for the individual payment amount, the first enterprise payment amount and the second enterprise payment amount.
  • the amount of personal payment, the amount of the first enterprise payment, and the amount of the second enterprise payment may include the amount of pre-tax payment and the amount of post-tax payment.
  • Step S260 Send the payment measurement result to the second preset terminal corresponding to the payment measurement request, based on the personal payment amount, the first enterprise payment amount, and the second enterprise payment amount.
  • the payment measurement result is sent to the second preset terminal corresponding to the payment measurement request, so that the payment measurement request corresponds to The enterprise user can view the measurement result in time, and carry out subsequent payment according to the measurement result.
  • the amount of personal contributions before tax and the amount of personal contributions after tax are fixed values, for example, 10 yuan and 0 yuan respectively;
  • the employee is a Chinese
  • the amount of the second enterprise payment (before tax) the total annual payment of the company - the sum of the contributions of all employees of the company.
  • the post coefficient is as follows: the general manager of the provincial company and the equivalent position (second grade), the post coefficient is 8; the deputy general manager of the civil company and the equivalent position (level 2), the post coefficient is 7; the city director and the equivalent position (level 3) Zheng), the post coefficient is 6; the deputy head of the municipal bureau and the equivalent position (level 3), the post coefficient is 5; the county director and the equivalent position (four grades), the post coefficient is 4; the deputy head of the county bureau and the equivalent position (four Level), the post coefficient is 3; other, the post coefficient is 2; the non-leadership coefficient at the same level is 0.3.
  • the amount of the first enterprise payment (before tax) is the actual contribution rate of the enterprise payment * the monthly payment base of the individual, wherein the actual proportion of the enterprise payment is the actual contribution rate of the enterprise payment of the enterprise to which the employee belongs;
  • the amount of the second enterprise contribution (before tax) is the sum of the measured employees (personal monthly payment base *0.01), or the total salary of the previous year *5%/12 - the sum of the basic contributions of the employee's enterprise.
  • the individual contribution amount (before tax) is the first enterprise contribution amount (before tax) / proportional coefficient, otherwise the individual contribution amount (before tax) is Min (average work in the previous year, social wages *3) * 4%; of which, the average work of the previous year is the base of the new employee's monthly payment; the social wage is the corresponding employee's monthly salary in the middle and upper months.
  • the scale factor is the system entry value.
  • the individual contribution amount (after tax) is the first enterprise contribution amount (before tax) / proportional coefficient - Z * 4%, otherwise 0;
  • the amount of the second enterprise's contribution (before tax) is the total amount of the personal contribution base of all participating companies under the enterprise *5% - the enterprise is the total amount of personal contributions.
  • the flow in this embodiment may be different from the process of the enterprise annuity transaction in the foregoing embodiments, and may be before step S110, or after step S140, or between any two steps described above. Therefore, in this embodiment, The sequence between step S210 and step S220 and other steps is not specifically limited.
  • the enterprise annuity transaction method proposed in the embodiment obtains the enterprise identification corresponding to the payment measurement request by receiving the payment calculation request of the enterprise annuity, and then obtains the personal payment parameter of the personal account corresponding to the enterprise identification and the first enterprise payment parameter, and The enterprise logo corresponds to the second enterprise payment parameter of the enterprise account, and then calculates the personal payment amount of the personal account based on the individual payment parameter, calculates the first enterprise payment amount of the personal account based on the first enterprise payment parameter, and calculates the enterprise account based on the second enterprise payment parameter.
  • the second enterprise payment amount is finally based on the individual payment amount, the first enterprise payment amount, and the second enterprise payment amount to send the payment measurement result to the second preset terminal corresponding to the payment measurement request, and realizes that the payment measurement request is the first
  • the enterprise's calculation of the payment of the annuity can provide accurate and fast payment calculation for the enterprise users, further improving the user experience.
  • the present invention also provides a computer readable storage medium.
  • a computer readable storage medium stores an enterprise annuity transaction program, and the enterprise annuity transaction method is implemented by the processor to implement the enterprise annuity transaction method. A step of.
  • portions of the technical solution of the present invention that contribute substantially or to the prior art may be embodied in the form of a software product stored in a storage medium (such as a ROM/RAM as described above). , a disk, an optical disk, including a number of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • a terminal device which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • General Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Technology Law (AREA)
  • Data Mining & Analysis (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明公开了一种企业年金交易方法，包括：获取当前企业年金对应的第一交易请求，并获取业务标识以及企业标识；基于业务标识以及企业标识对第一交易请求进行分类操作，以获得第二交易请求；在第二交易请求中存在异常交易请求时，获取异常交易请求对应的第三交易请求；基于第四交易请求进行交易操作。本发明还公开了一种企业年金交易装置及计算机可读存储介质。本发明实现了在分类后的第二交易请求中存在异常交易请求时，先处理各个无异常年金计划的交易请求以及异常业务标识的年金计划中无异常企业标识对应的交易请求，进而能够保证无异常交易请求的企业能够顺利进行交易，提高了企业年金交易的效率。

Description

企业年金交易方法、装置及计算机可读存储介质
本申请要求于2017年06月26日提交中国专利局、申请号为201710498908.3、发明名称为“企业年金交易方法、装置及计算机可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在申请中。
技术领域
　　　本发明涉及数据处理技术领域，尤其涉及一种企业年金交易方法、装置及计算机可读存储介质。
背景技术
　　　企业年金是指企业及其职工在依法参加基本养老保险的基础上，依据国家政策和本企业经济状况建立的、旨在提高职工退休后生活水平、对国家基本养老保险进行重要补充的一种养老保险形式。企业年金不仅可以提升企业形象，增强对人才的吸引，也有利于社会的和谐稳定。随着企业的快速发展，越来越多的企业建立了企业年金。
　　　目前，在进行企业年金的交易时，账管系统对所有企业年金的年金计划对应的交易请求进行统一交易，以便于后期的维护。但是，在进行统一交易的过程中，若某一交易存在异常，则会造成所有的交易无法继续进行，进而导致其他无异常交易的企业年金无法准时完成交易。
　　　上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。
发明内容
　　　本发明的主要目的在于提供一种企业年金交易方法、装置及计算机可读存储介质，旨在解决现有年金交易过程中因存在异常交易而导致其他无异常交易的企业年金无法准时完成交易的技术问题。
　　　为实现上述目的，本发明提供一种企业年金交易方法，所述企业年金交易方法包括以下步骤：
　　　获取当前企业年金对应的第一交易请求，并获取所述第一交易请求对应的企业年金的业务标识以及企业标识；
　　　基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作，以获得第二交易请求；
　　　在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求；
　　　基于第四交易请求进行交易操作，以获得第一交易数据，其中，所述第四交易请求为所述第二交易请求中除所述第三交易请求之外的其他交易请求。
　　　此外，为实现上述目的，本发明还提供一种企业年金交易装置，所述企业年金交易装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的企业年金交易程序，所述企业年金交易程序被所述处理器执行时实现上述任一项所述的方法的步骤。
　　　此外，为实现上述目的，本发明还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有企业年金交易程序，所述企业年金交易程序被处理器执行时实现上述任一项所述的企业年金交易方法的步骤。
　　　本发明通过获取当前企业年金对应的第一交易请求，并获取第一交易请求对应的企业年金的业务标识以及企业标识，接着基于获取到的业务标识以及企业标识对第一交易请求进行分类操作，而后在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求，最后基于第四交易请求进行交易操作，以获得第一交易数据，实现了在分类后的第二交易请求中存在异常交易请求时，先处理各个无异常年金计划的交易请求以及异常业务标识的年金计划中无异常企业标识对应的交易请求，避免因异常交易请求而导致造成所有的交易无法继续进行的情况发送，进而能够保证无异常交易请求的企业能够顺利进行交易，提高了企业年金交易的效率，提升了用户体验。
附图说明
　　　图1是本发明实施例方案涉及的硬件运行环境中企业年金交易装置所属终端的结构示意图；
　　　图2为本发明企业年金交易方法第一实施例的流程示意图。
　　　本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
　　　应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
　　　本发明提供一种企业年金交易装置，如图1所示，图1是本发明实施例方案涉及的硬件运行环境中企业年金交易装置所属终端的结构示意图。
　　　本发明实施例终端可以是PC，也可以是智能手机、平板电脑、便携计算机等终端设备。
　　　如图1所示，该终端可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏（Display）、输入单元比如键盘（Keyboard），可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口（如WI-FI接口）。存储器1005可以是高速RAM存储器，也可以是稳定的存储器（non-volatile memory），例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
　　　可选地，终端还可以包括摄像头、RF（Radio Frequency，射频）电路，传感器、音频电路、WiFi模块等等。其中，传感器比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示屏的亮度，接近传感器可在移动终端移动到耳边时，关闭显示屏和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上（一般为三轴）加速度的大小，静止时可检测出重力的大小及方向，可用于识别移动终端姿态的应用（比如横竖屏切换、相关游戏、磁力计姿态校准）、振动识别相关功能（比如计步器、敲击）等；当然，移动终端还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。
　　　本领域技术人员可以理解，图1中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
　　　如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及企业年金交易程序。
　　　在图1所示的终端中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端（用户端），与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的企业年金交易程序，并执行本申请实施例提供的企业年金交易方法。
　　　本发明还提供一种企业年金交易方法。参照图2，图2为本发明参照图2，第一实施例的流程示意图，在本实施例中，该企业年金交易方法包括：
　　　步骤S110，获取当前企业年金对应的第一交易请求，并获取所述第一交易请求对应的企业年金的业务标识以及企业标识；
　　　目前，现有的企业年金的年金计划中，大部分是以一个月为一个交易周期进行年金缴费的，还有一小部分是以一个季度为一个交易周期进行年金缴费的，在上一交易周期内接收到的交易请求，可能需要在年金计划的单价跟新时，才能进行交易。其中，对于某一年金计划中某一企业用户而言，企业用户的账户包括企业账户以及个人账户，因此，企业年金交易包括：企业年金的某一年金计划中企业账户的缴费操作与个人账户的缴费操作，企业账户的注册与缴费操作、该企业账户所述企业的员工的个人账户的注册与缴费操作，为某企业增加新的年金计划的操作、该新增加的年金计划中该企业的企业用户缴费操作及个人账户的缴费操作，某一年金计划中的某一企业的账户企业的注销、该企业中员工的个人账户的注销，某一年金计划中的某一企业的员工账户的注册或注销等。企业年金的业务标识是指该企业年金对应的年金计划的标识信息，每一个年金计划对应唯一的业务标识。企业标识是指年金计划中所有参与企业的标识信息。
　　　其中，本实施例的企业年金包括一个或多个年金计划，第一交易请求为当前企业年金的所有年金计划中未处理的所有交易请求，包括年金计划中上一交易周期接收到但未处理的交易请求以及当前交易周期接收到的交易请求，具体地，第一交易请求可包括该企业年金的年金计划中企业账户的缴费请求、该企业年金的年金计划中个人账户的缴费请求、企业账户注册请求、企业账户中新的年金计划的增加请求、个人账户注册请求、个人账户注销请求等，具体地，在对应的企业首次建立企业年金时，企业用户通过企业账户注册请求进行企业账户的注册；企业用户通过增加请求在已有的企业账户添加新的年金计划；通个人账户注册请求过在对应的企业账户中添加新的个人账户，在某企业中的某员工离职或退休后，已领取完所有年金时，通过个人账户注销请求注销该员工对应的个人账户。
　　　在本实施例中，在企业年金的单价更新时，获取当前企业年金对应的第一交易请求，以及该第一交易请求对应的业务标识及企业标识，以便于根据获取到的业务标识及企业标识对第一交易请求进行分类。
　　　步骤S120，基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作，以获得第二交易请求；
　　　其中，第二交易请求为业务标识对应的年金计划的交易请求中各个企业标识对应的交易请求，即当前企业年金的每一个年金计划中的各个企业的交易请求，具体地，将第一交易请求按照业务标识进行分类，得到当前企业年金的每一个年金计划的交易请求，而后对每一个年金计划的交易请求按照企业标识进行分类，得到当前企业年金的每一个年金计划中的每一个企业的交易请求，并将每一个年金计划中的每一个企业的交易请求作为一组第二交易请求，进而得到多组第二交易请求。
　　　在本实施例中，由于不同的年金计划的交易请求以及同一年金计划中不同企业的交易请求之间相互不影响，因此，在本实施例中，在获取到第一交易请求对应的业务标识以及企业标识时，根据业务标识以及企业标识对第一交易请求进行分类操作，进而得到各个业务标识对应的年金计划中的各个企业标识对应的第二交易请求，以对不同的年金计划的交易请求以及同一年金计划中不同企业的交易请求进行独立的交易操作。其中，每一个年金计划对应多个企业标识，即分类后每一个年金计划对应多组交易请求，即第二交易请求包括多组交易请求。
　　　步骤S130，在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求；
　　　在本实施例中，在对第一交易请求进行分类操作获得第二交易请求时，确定该第二交易请求是否存在异常交易请求，在第二交易请求中存在异常交易请求时，确定该异常交易请求对应的企业标识即异常企业标识，以及异常交易请求对应的业务标识即异常业务标识，并根据该异常业务标识以及异常企业标识获取第三交易请求，其中，该第三交易请求为异常业务标识对应的年金计划的交易请求中，该异常企业标识对应的交易请求，即第三交易请求为业务标识为该异常业务标识的年金计划的所有交易请求中，企业标识为该异常企业标识的企业的交易请求。
　　　其中，异常交易请求可包括异常缴费请求等，例如，某一企业的个人用户账户因变换国籍而需要注销时，即当前存在该账户的账户注销请求时，同时还存在对该用户账户的缴费请求等。
　　　步骤S140，基于第四交易请求进行交易操作，以获得第一交易数据，其中，所述第四交易请求为所述第二交易请求中除所述第三交易请求之外的其他交易请求。
　　　其中，第四交易请求为第二交易请求中除第三交易请求之外的其他交易请求，即第四交易请求包括第二交易请求中无异常的业务标识对应的交易请求以及异常业务标识中无异常的企业标识对应的交易请求。
　　　在本实施例中，在获取到第三交易请求，在第二交易请求中获取除该第三交易请求之外的其他交易请求即第四交易请求，基于该第四交易请求进行交易操作，能够保证无异常的业务标识对应的交易请求以及异常业务标识中无异常的企业标识对应的交易请求能够顺利完成，以保证无异常交易请求的企业能够顺利进行交易。例如，在第四交易请求中包括企业年金的年金计划中企业账户的缴费请求时，按照该缴费请求执行缴费操作，具体的可根据该缴费请求对应的缴费金额更新该年金计划中该企业账户的账户余额，即将该企业账户的原账户余额与缴费金额相加后作为该年金计划中该企业账户新的账户余额，在第四交易请求中包括该企业年金的年金计划中个人账户的缴费请求时，按照该缴费请求执行缴费操作，具体的可根据该缴费请求对应的缴费金额更新该年金计划中该个人账户的账户余额，即将该个人账户的原账户余额与缴费金额相加后作为该年金计划中该个人账户新的账户余额，其他交易请求对应的交易操作再次不在赘述。
　　　现有的企业年金交易过程中，按照一定的顺序进行交易，例如按照企业标识的排序、或者业务标识的排序等进行交易，因此，对第四交易请求进行交易操作时，可按照原来的排序方式依次对各组第四交易请求进行交易操作。
　　　在一实施例中，对于第三交易请求，可通过人工检查等方式确定第三交易请求中的异常交易请求的异常原因，将该包括该异常原因及异常交易请求的异常信息发送至该异常标识信息对应的第一预设终端，以供第一预设终端对应的企业用户，根据该异常信息重新编辑交易请求，再次提出交易。
　　　本实施例提出的企业年金交易方法，通过获取当前企业年金对应的第一交易请求，并获取第一交易请求对应的企业年金的业务标识以及企业标识，接着基于获取到的业务标识以及企业标识对第一交易请求进行分类操作，而后在第二交易请求中存在异常交易请求时，获取异常交易请求对应的第三交易请求，最后基于第四交易请求进行交易操作，以获得第一交易数据，实现了在分类后的第二交易请求中存在异常交易请求时，先处理各个无异常年金计划的交易请求以及异常业务标识的年金计划中无异常企业标识对应的交易请求，避免因异常交易请求而导致造成所有的交易无法继续进行的情况发送，进而能够保证无异常交易请求的企业能够顺利进行交易，提高了企业年金交易的效率，提升了用户体验。
　　　基于第一实施例，提出本发明企业年金交易方法的第二实施例，在本实施例中，步骤S130包括：
　　　步骤S131，在第二交易请求中存在异常交易请求时，确定所述异常交易请求对应的异常企业标识以及异常业务标识；
　　　在本实施例中，在对第一交易请求进行分类操作获得第二交易请求时，确定该第二交易请求是否存在异常交易请求，在第二交易请求中存在异常交易请求时，确定该异常交易请求对应的企业标识即异常企业标识，以及异常交易请求对应的业务标识即异常业务标识。
　　　步骤S132，基于所述异常企业标识以及异常业务标识获取所述第三交易请求。
　　　在本实施例中，在获取到异常企业标识以及异常业务标识时，根据该异常业务标识以及异常企业标识获取第三交易请求。其中，该第三交易请求为异常企业标识对应的年金计划的交易请求中，该异常企业标识对应的所有交易请求。
　　　本实施例提出的企业年金交易方法，通过在第二交易请求中存在异常交易请求时，确定异常交易请求对应的异常企业标识以及异常业务标识，接着基于异常企业标识以及异常业务标识获取第三交易请求，实现了根据异常企业标识以及异常业务标识获取第三交易请求，进而能够准确的确定第三交易请求，使得第四交易请求能够顺利的进行交易操作，避免因异常交易请求而导致造成所有的交易无法继续进行的情况发送，进而能够保证无异常交易请求的企业能够顺利进行交易，进一步提高了企业年金交易的效率。
　　　基于第一实施例，提出本发明企业年金交易方法的第三实施例，在本实施例中，步骤S120包括：
　　　步骤S121，获取所述业务标识对应的年金计划中的业务场景；
　　　在本实施例中，可以对第二交易请求按照业务场景进行再次分类，以再次减少第三交易请求中交易请求的数量。因此，可获取业务标识对应的年金计划中的业务场景。
　　　步骤S122，基于所述业务标识、所述企业标识及所述业务场景，对所述第一交易请求进行分类操作，以获得所述第二交易请求。
　　　其中，第二交易请求为业务标识对应的年金计划的交易请求中各个企业标识所包括的各个业务场景的交易请求，即将各个业务标识对应的年金计划的交易请求，按照各个企业标识进行分组后，再次对各组交易请求按照业务场景进行分组，进而得到多组第二交易请求。
　　　本实施例提出的企业年金交易方法，通过获取业务标识对应的年金计划中的业务场景，接着基于业务标识、企业标识及业务场景，对第一交易请求进行分类操作，能够尽可能的降低分类后的各组第二交易请求中所包含的交易请求的数量，进而能够减少第三交易请求中所包含的交易请求的数量，使得尽可能多的交易请求能够进行顺利的交易，进一步提高了企业年金交易的效率。
　　　基于第一实施例，提出本发明企业年金交易方法的第四实施例，在本实施例中，在步骤S120之后，该企业年金交易方法还包括：
　　　步骤S150，在所述第二交易请求中不存在异常交易请求时，基于所述第二交易请求进行交易操作，以获得第二交易数据；
　　　步骤S160，基于业务标识以及企业标识对第二交易数据进行汇总操作。
　　　在本实施例中，在所述第二交易请求中不存在异常交易请求时，对所述第二交易请求进行交易操作，以获得第一交易数据，并基于业务标识以及企业标识对第一交易数据进行汇总操作。
　　　其中，汇总操作是指基于企业标识对第二交易数据进行汇总，在第二交易数据汇总后，将各个企业标识对应的汇总后的数据分别发送至各个企业标识对应的终端，以使各个企业用户能够及时了解到交易信息，当然，还可以根据各种需求生成各种报表。
　　　现有的企业年金交易过程中，按照一定的顺序进行交易，例如按照企业标识的排序、或者业务标识的排序等进行交易，因此，对第二交易请求进行交易操作时，可按照原来的排序方式依次对各组第二交易请求进行交易操作。
　　　本实施例提出的企业年金交易方法，通过在第二交易请求中不存在异常交易请求时，基于第二交易请求进行交易操作，以获得第二交易数据，接着基于业务标识以及企业标识对第二交易数据进行汇总操作，实现了在第二交易请求中不存在异常交易请求时直接进行交易操作，进一步提高了企业年金交易的效率。
　　　基于第一实施例，提出本发明企业年金交易方法的第五实施例，在本实施例中，在步骤S140之后，该企业年金交易方法还包括：
　　　步骤S170，获取所述异常交易请求的异常信息；
　　　在本实施例中，可设置异常交易请求的异常检测规则，根据该异常检测规则检测异常交易请求的异常原因，当然也可通过人工检查的方式确定异常交易请求的异常原因。
　　　其中，异常信息包括异常交易请求的异常原因、异常交易请求以及第三交易请求。
　　　步骤S180，将所述异常信息发送至所述异常交易请求对应的第一预设终端。
　　　在本实施例中，在获取到异常信息时，将该异常信息发送至异常交易请求对应的第一预设终端，在第一预设终端接收到该异常信息时，该第一预设终端对应的企业用户可以根据该异常信息重新编辑异常交易请求，根据编辑后的交易请求更新第三交易请求，并反馈更新后的第三交易请求，在接收到更新后的第三交易请求，确定更新后的第三交易请求中不存在异常交易请求时，基于更新后的第三交易请求进行交易操作。
　　　其中，该第一预设终端为异常企业标识对应的终端，可通过异常交易请求确定异常企业标识，进而确定该第一预设终端。若异常交易请求对应的异常企业标识为多个，则第三交易请求包括分别与异常企业标识对应的多组交易请求，并且第一预设终端为多个，因此，在发送异常信息，分别发送多个不同的异常信息至对应的第一预设终端。
　　　在一实施例中，可通过短信、邮件、即时信息等方式将异常信息发送至异常交易请求对应的第一预设终端。
　　　本实施例提出的企业年金交易方法，通过获取异常交易请求的异常信息，将异常信息发送至异常交易请求对应的第一预设终端，使得第一预设终端对应的企业用户能够根据异常信息重新编辑异常交易请求，进而使得能够尽快更新第三交易请求中的异常交易请求，以使更新后的第三交易请求能够及时完成交易，进一步提高了企业年金交易的效率。
　　　基于第一实施例，提出本发明企业年金交易方法的第六实施例，在本实施例中，在步骤S140之后，该企业年金交易方法还包括：
　　　步骤S190，对所述第一交易数据进行验证操作；
　　　在本实施例中，可采用现有的验证方式对第一交易数据进行验证操作。
　　　具体地，若在第一交易数据中存在验证未通过的交易数据时，获取该验证未通过的交易数据对应的企业标识以及业务标识；根据企业标识以及业务标识获取交易前数据以及交易请求，即该验证未通过的交易数据对应的交易前的据以及交易请求；并对该企业标识以及业务标识对应的前一交易周期的交易数据进行验证操作，在前一交易日的交易数据验证通过时，基于交易前数据以及交易请求再次进行交易操作，以得到第三交易数据，基于第三交易数据更新第一交易数据中的验证未通过的交易数据。
　　　步骤S200，在所述第一交易数据验证通过时，基于所述业务标识以及企业标识对所述第一交易数据进行汇总操作。
　　　其中，汇总操作是指基于企业标识对第一交易数据进行汇总，在第一交易数据汇总后，将各个企业标识对应的汇总后的数据分别发送至各个企业标识对应的终端，以使各个企业用户能够及时了解到交易信息，当然，还可以根据各种需求生成各种报表。
　　　本实施例提出的企业年金交易方法，通过对第一交易数据进行验证操作，在第一交易数据验证通过时，基于业务标识以及企业标识对第一交易数据进行汇总操作，实现了在第一交易数据验证通过时进行汇总，进而能够保证第二交易数据的准确性，进一步提高了企业年金交易的准确性及效率。
　　　基于第一实施例，提出本发明企业年金交易方法的第七实施例，在本实施例中，在步骤S140之后，该企业年金交易方法还包括：
　　　步骤S210，在接收到所述企业年金的领取交易请求时，获取所述领取交易请求对应的领取方式、员工信息及所述员工信息对应的企业参数信息；
　　　在本实施例中，在接收到企业年金的领取交易请求时，获取领取交易请求对应的领取方式、员工信息及员工信息对应的企业参数信息，其中员工信息包括：工龄、缴费年限、本公司工作年限等，企业参数信息包括企业补贴规则信息等，企业补贴规则信息包括固定补偿信息或者差额补偿信息，固定补偿信息是指在用户按照企业规定的方式领取年金时，每次为该用户固定补偿的金额，固定补偿信息是指在用户按照企业规定的方式领取年金时，在当前领取金额小于领取最小金额时，进行差额补偿以按照该领取最小金额进行年金的领取。
　　　步骤S220，基于所述领取方式、所述员工信息以及所述企业参数信息计算领取参数，其中，所述领取参数包括领取时间、领取金额以及纳税金额。
　　　在本实施例中，在获取到领取方式、员工信息以及企业参数信息时，基于领取方式、员工信息以及企业参数信息计算该领取交易请求对应的用户的领取参数，具体地，根据该领取交易请求对应的企业的预设算法计算领取参数，其中领取参数包括领取时间、领取金额以及纳税金额。
　　　在本实施例中，用户在选择领取方式时，可通过选择界面提供的纳税金额的选项触发领取交易请求，且该领取交易请求对应的领取方式为纳税金额最少的领取方式，用户按照该领取交易请求对应的领取参数进行年金的领取，能够确保所需要交的税最少，以保证用户的最大利益。
　　　本实施例中的流程，由于与上述各个实施例中的企业年金交易的流程无关，可以在步骤S110之前，或者步骤S140之后，或者上述任意两个步骤之间，因此，本实施例中，对于步骤S210及步骤S220与其他步骤之间的先后顺序不做具体限定。
　　　本实施例提出的企业年金交易方法，通过在接收到企业年金的领取交易请求时，获取领取交易请求对应的领取方式、员工信息及员工信息对应的企业参数信息，基于领取方式、员工信息以及企业参数信息计算领取参数，能够根据用户选取的领取方式为用户提供最优的领取参数，便于用户进行选择，提高了用户体验。
　　　基于第一实施例，提出本发明企业年金交易方法的第八实施例，在本实施例中，该企业年金交易方法还包括：
　　　步骤S230，在接收到企业年金的缴费测算请求时，获取所述缴费测算请求对应的企业标识；
　　　在本实施例中，企业用户可以通过企业年金界面的缴费测算选项触发缴费测算请求，在接收到企业年金的缴费测算请求时，获取缴费测算请求对应的企业标识。
　　　其中，可以在企业年金界面的缴费测算选项处显示以输入窗口，企业用户在该输入窗口输入对应的企业标识。或者，在该企业用户已登录企业年金系统时，该缴费测算请求携带有对应的企业标识，或者与企业标识一一对应，可通过该缴费测算请求获取到对应的企业标识。
　　　步骤S240，获取所述企业标识对应个人账户的个人缴费参数及第一企业缴费参数，以及所述企业标识对应企业账户的第二企业缴费参数；
　　　在本实施例中，在获取到缴费测算请求对应的企业标识时，可以根据该企业标识获取该企业对应的个人账户的个人缴费参数、个人账户的第一企业缴费参数以及企业账户的第二企业缴费参数，其中，上述个人缴费参数、第一企业缴费参数以及第二企业缴费参数由该企业标识对应的预设测算规则决定，并且不同的企业设有不同的预设测算规则。
　　　步骤S250，基于所述个人缴费参数计算所述个人账户的个人缴费金额、基于所述第一企业缴费参数计算所述个人账户的第一企业缴费金额及基于所述第二企业缴费参数计算所述企业账户的第二企业缴费金额；
　　　在本实施例中，在获取到个人缴费参数、第一企业缴费参数以及第二企业缴费参数，基于个人缴费参数计算个人账户的个人缴费金额、基述第一企业缴费参数计算个人账户的第一企业缴费金额及基于第二企业缴费参数企业账户的第二企业缴费金额，其中，针对个人缴费金额、第一企业缴费金额以及第二企业缴费金额，不同的企业设有不同的计算规则。
　　　其中，个人缴费金额、第一企业缴费金额以及第二企业缴费金额均可包括税前缴费金额以及税后缴费金额。
　　　步骤S260，基于所述个人缴费金额、第一企业缴费金额及第二企业缴费金额发送缴费测算结果至所述缴费测算请求对应的第二预设终端。
　　　在本实施例中，在计算得到个人缴费金额、第一企业缴费金额及第二企业缴费金额时，发送缴费测算结果至缴费测算请求对应的第二预设终端，以使该缴费测算请求对应的企业用户能够及时查看测算结果，并根据该测算结果进行后续的缴费。
　　　一下以某企业为例，对上述缴费测算进行详细的阐述：
　　　例如，企业一：
　　　其中，税前的个人缴费金额以及税后的个人缴费金额均为固定值，例如，分别为10元与0元；
　　　第一企业缴费金额（税前）：
　　　若该员工为中人，则第一企业缴费金额（税前）Y=round（（月领取标准*240–Z）/48，2），其中，Z为个人账户余额及收益信息中的期末余额，月领取标准=max（测算月领取标准，最低领取标准）；
　　　若该员工为非中人，则第一企业缴费金额（税前）Y=round(X/12，2)，其中，X=单位系数金额*员工个人系数；员工个人系数=个人工龄系数+个人岗位系数，单位系数金额=企业基础分配总额/Σ员工个人系数，企业基础分配总额=本公司年度缴费总额*基础缴费比例；个人工龄系数：本企业工龄+非本企业工龄/2，本企业工龄=本企业工龄1+测算年份-参加计划时间年份；本企业工龄1为录入的值；个人岗位系数：根据企业职级和岗位序列确定，如果岗位序列是非领导序列，等于企业职级对应的系数-0.3，如果岗位序列是领导序列及其他等于企业职级对应的系数；单位系数金额为系统录入金额；
　　　第二企业缴费金额（税前）=本公司年度缴费总额-本公司所有员工企业缴费之和。
　　　其中，岗位系数如下：省公司总经理及相当职务（二级正），岗位系数为8；省公司副总经理及相当职务（二级），岗位系数为7；市局长及相当职务（三级正），岗位系数为6；市局副长及相当职务（三级），岗位系数为5；县局长及相当职务（四级正），岗位系数为4；县局副长及相当职务（四级），岗位系数为3；其他，岗位系数为2；同级非领导岗位系数下浮0.3。
　　　企业二：
　　　若个人缴费实际比例*个人月缴费基数<Z*4%，则个人缴费金额（税前）为个人缴费实际比例*个人月缴费基数，否则个人缴费金额（税前部分）为Z*4%，其中，Z=社平工资*3，社平工资为员工所属企业对应的上年度月社平资，个人缴费实际比例为员工所属企业的个人缴费实际缴费比例；
　　　若个人缴费实际比例*个人月缴费基数>Z*4%，则个人缴费金额（税后）为个人缴费实际比例*个人月缴费基数-Z*4%，否则为0；
　　　第一企业缴费金额（税前）为企业缴费实际缴费比例*个人月缴费基数，其中，企业缴费实际比例为员工所属企业的企业缴费实际缴费比例；
　　　第二企业缴费金额（税前）为测算员工（个人月缴费基数*0.01）之和，或者上一年度工资总额*5%/12-测算员工企业基本缴费之和。
　　　企业三：
　　　第一企业缴费金额（税前）=min(X，Y)，其中，X=月工挂年金+月工龄年金，月工挂年金=个人缴费基数×工挂缴费比例，月工龄年金=自然工作年限×每年限缴费标准，Y=职务上限/12；个人缴费基数为员工信息中的个人缴费基数；工挂缴费比例为PTS系统中设置的、员工所属企业对应的工挂缴费比例；每年限缴费标准为PTS系统中设置的、员工所属企业对应的每年限缴费标准；自然工作年限：年-年+1（例如，简历的时间为200101~200106、200501~200801，则自然年限计算为（2001-2001+1）+（2008-2005+1））；简历的时间为200501~200801，则自然工作年限为2008-2001+1）；职务上线为系统录入值。
　　　若第一企业缴费金额（税前）/比例系数<Z*4%，则个人缴费金额（税前）为第一企业缴费金额（税前）/比例系数，否则个人缴费金额（税前）为min(上年月平均工作，社平工资*3)*4%；其中，上年月平均工作为对应员工新增中月缴费基数；社平工资为对应员工新增中上年度月社平工资；比例系数为系统录入值。
　　　若第一企业缴费金额（税前）/比例系数>Z*4%，则个人缴费金额（税后）为第一企业缴费金额（税前）/比例系数-Z*4%，否则为0；
　　　第二企业缴费金额（税前）为企业下所有参与测算的个人缴费基数的总额*5%-企业为个人缴费总额。
　　　本实施例中的流程，由于与上述各个实施例中的企业年金交易的流程无关，可以在步骤S110之前，或者步骤S140之后，或者上述任意两个步骤之间，因此，本实施例中，对于步骤S210及步骤S220与其他步骤之间的先后顺序不做具体限定。
　　　本实施例提出的企业年金交易方法，通过在接收到企业年金的缴费测算请求时，获取缴费测算请求对应的企业标识，接着获取企业标识对应个人账户的个人缴费参数及第一企业缴费参数，以及企业标识对应企业账户的第二企业缴费参数，而后基于个人缴费参数计算个人账户的个人缴费金额、基于第一企业缴费参数计算个人账户的第一企业缴费金额及基于第二企业缴费参数计算企业账户的第二企业缴费金额，最后基于个人缴费金额、第一企业缴费金额及第二企业缴费金额发送缴费测算结果至缴费测算请求对应的第二预设终端，实现了根据缴费测算请求为第一的企业进行年金的缴费测算，能够为企业用户提供准确快速的缴费测算，进一步提高了用户体验。
　　　本发明还提供一种计算机可读存储介质，在本实施例中，计算机可读存储介质上存储有企业年金交易程序，所述企业年金交易方法被所述处理器执行时实现上述企业年金交易方法的步骤。
　　　需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
　　　上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
　　　通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
　　　以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (20)

  1. 一种企业年金交易方法，其特征在于，所述企业年金交易方法包括以下步骤：
    　　　获取当前企业年金对应的第一交易请求，并获取所述第一交易请求对应的企业年金的业务标识以及企业标识；
    　　　基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作，以获得第二交易请求；
    　　　在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求；
    　　　基于第四交易请求进行交易操作，以获得第一交易数据，其中，所述第四交易请求为所述第二交易请求中除所述第三交易请求之外的其他交易请求。　　　
  2. 如权利要求1所述的企业年金交易方法，其特征在于，所述在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求的步骤包括：
    　　　在第二交易请求中存在异常交易请求时，确定所述异常交易请求对应的异常企业标识以及异常业务标识；
    　　　基于所述异常企业 标识以及异常业务标识获取所述第三交易请求。　　　
  3. 如权利要求1所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤包括：
    　　　获取所述业务标识对应的年金计划中的业务场景；
    　　　基于所述业务标识、所述企业标识及所述业务场景，对所述第一交易请求进行分类操作，以获得所述第二交易请求。　　　
  4. 如权利要求1所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤之后，所述企业年金交易方法还包括：
    　　　在所述第二交易请求中不存在异常交易请求时，基于所述第二交易请求进行交易操作，以获得第二交易数据；
    　　　基于业务标识以及企业标识对第二交易数据进行汇总操作。　　　
  5. 如权利要求1所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　获取所述异常交易请求的异常信息；
    　　　将所述异常信息发送至所述异常交易请求对应的第一预设终端。　　　
  6. 如权利要求1所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　对所述第一交易数据进行验证操作；
    　　　在所述第一交易数据验证通过时，基于所述业务标识以及企业标识对所述第一交易数据进行汇总操作。　　　
  7. 如权利要求1所述的企业年金交易方法，其特征在于，所述企业年金交易方法还包括：
    　　　在接收到所述企业年金的领取交易请求时，获取所述领取交易请求对应的领取方式、员工信息及所述员工信息对应的企业参数信息；
    　　　基于所述领取方式、所述员工信息以及所述企业参数信息计算领取参数，其中，所述领取参数包括领取时间、领取金额以及纳税金额。　　　
  8. 如权利要求7所述的企业年金交易方法，其特征在于，所述在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求的步骤包括：
    　　　在第二交易请求中存在异常交易请求时，确定所述异常交易请求对应的异常企业标识以及异常业务标识；
    　　　基于所述异常企业 标识以及异常业务标识获取所述第三交易请求。　　　
  9. 如权利要求7所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤包括：
    　　　获取所述业务标识对应的年金计划中的业务场景；
    　　　基于所述业务标识、所述企业标识及所述业务场景，对所述第一交易请求进行分类操作，以获得所述第二交易请求。　　　
  10. 如权利要求7所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤之后，所述企业年金交易方法还包括：
    　　　在所述第二交易请求中不存在异常交易请求时，基于所述第二交易请求进行交易操作，以获得第二交易数据；
    　　　基于业务标识以及企业标识对第二交易数据进行汇总操作。　　　
  11. 如权利要求7所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　获取所述异常交易请求的异常信息；
    　　　将所述异常信息发送至所述异常交易请求对应的第一预设终端。　　　
  12. 如权利要求7所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　对所述第一交易数据进行验证操作；
    　　　在所述第一交易数据验证通过时，基于所述业务标识以及企业标识对所述第一交易数据进行汇总操作。　　　
  13. 如权利要求1所述的企业年金交易方法，其特征在于，所述企业年金交易方法还包括：
    　　　在接收到企业年金的缴费测算请求时，获取所述缴费测算请求对应的企业标识；
    　　　获取所述企业标识对应个人账户的个人缴费参数及第一企业缴费参数，以及所述企业标识对应企业账户的第二企业缴费参数；
    　　　基于所述个人缴费参数计算所述个人账户的个人缴费金额、基于所述第一企业缴费参数计算所述个人账户的第一企业缴费金额及基于所述第二企业缴费参数计算所述企业账户的第二企业缴费金额；
    　　　基于所述个人缴费金额、第一企业缴费金额及第二企业缴费金额发送缴费测算结果至所述缴费测算请求对应的第二预设终端。　　　
  14. 如权利要求13所述的企业年金交易方法，其特征在于，所述在第二交易请求中存在异常交易请求时，获取所述异常交易请求对应的第三交易请求的步骤包括：
    　　　在第二交易请求中存在异常交易请求时，确定所述异常交易请求对应的异常企业标识以及异常业务标识；
    　　　基于所述异常企业 标识以及异常业务标识获取所述第三交易请求。　　　
  15. 如权利要求13所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤包括：
    　　　获取所述业务标识对应的年金计划中的业务场景；
    　　　基于所述业务标识、所述企业标识及所述业务场景，对所述第一交易请求进行分类操作，以获得所述第二交易请求。　　　
  16. 如权利要求13所述的企业年金交易方法，其特征在于，所述基于获取到的所述业务标识以及企业标识对所述第一交易请求进行分类操作的步骤之后，所述企业年金交易方法还包括：
    　　　在所述第二交易请求中不存在异常交易请求时，基于所述第二交易请求进行交易操作，以获得第二交易数据；
    　　　基于业务标识以及企业标识对第二交易数据进行汇总操作。　　　
  17. 如权利要求13所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　获取所述异常交易请求的异常信息；
    　　　将所述异常信息发送至所述异常交易请求对应的第一预设终端。　　　
  18. 如权利要求13所述的企业年金交易方法，其特征在于，所述基于第四交易请求进行交易操作的步骤之后，所述企业年金交易方法还包括：
    　　　对所述第一交易数据进行验证操作；
    　　　在所述第一交易数据验证通过时，基于所述业务标识以及企业标识对所述第一交易数据进行汇总操作。　　　
  19. 一种企业年金交易装置，其特征在于，所述企业年金交易装置包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的企业年金交易程序，所述企业年金交易程序被所述处理器执行时实现如权利要求1所述的方法的步骤。　　　
  20. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有企业年金交易程序，所述企业年金交易程序被处理器执行时实现如权利要求1所述的企业年金交易方法的步骤。
PCT/CN2018/076202 2017-06-26 2018-02-11 企业年金交易方法、装置及计算机可读存储介质 WO2019000967A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710498908.3 2017-06-26
CN201710498908.3A CN109118373A (zh) 2017-06-26 2017-06-26 企业年金交易方法、装置及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2019000967A1 true WO2019000967A1 (zh) 2019-01-03

Family

ID=64740953

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/076202 WO2019000967A1 (zh) 2017-06-26 2018-02-11 企业年金交易方法、装置及计算机可读存储介质

Country Status (2)

Country Link
CN (1) CN109118373A (zh)
WO (1) WO2019000967A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110111209A (zh) * 2019-05-05 2019-08-09 泰康保险集团股份有限公司 支付通知业务的处理方法、装置及可读存储介质
CN110889771A (zh) * 2019-10-30 2020-03-17 泰康保险集团股份有限公司 账户处理方法、装置、电子设备和计算机可读介质
CN111681117B (zh) * 2020-05-25 2023-09-12 泰康保险集团股份有限公司 一种待遇支付系统、方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477671A (zh) * 2009-01-19 2009-07-08 招商银行股份有限公司 养老账户管理的系统和方法
CN103684865A (zh) * 2013-12-11 2014-03-26 北京先进数通信息技术股份公司 一种交换系统及一种信息交换方法
CN106470204A (zh) * 2015-08-21 2017-03-01 阿里巴巴集团控股有限公司 基于请求行为特征的用户识别方法、装置、设备及系统
CN106603262A (zh) * 2015-10-19 2017-04-26 阿里巴巴集团控股有限公司 客户服务方式的分配方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105989232A (zh) * 2015-02-17 2016-10-05 深圳迈瑞生物医疗电子股份有限公司 样本检验结果自动审核系统及方法
CN106126958B (zh) * 2016-07-06 2018-10-19 温冬梅 医疗实验室临床生化检验自动审核系统
CN106354887A (zh) * 2016-10-21 2017-01-25 上海延华智能科技（集团）股份有限公司 一种城市交通信息互联共享的操作方法及其系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101477671A (zh) * 2009-01-19 2009-07-08 招商银行股份有限公司 养老账户管理的系统和方法
CN103684865A (zh) * 2013-12-11 2014-03-26 北京先进数通信息技术股份公司 一种交换系统及一种信息交换方法
CN106470204A (zh) * 2015-08-21 2017-03-01 阿里巴巴集团控股有限公司 基于请求行为特征的用户识别方法、装置、设备及系统
CN106603262A (zh) * 2015-10-19 2017-04-26 阿里巴巴集团控股有限公司 客户服务方式的分配方法及系统

Also Published As

Publication number Publication date
CN109118373A (zh) 2019-01-01

Similar Documents

Publication Publication Date Title
WO2020006852A1 (zh) 差旅费自助核销处理方法、装置、设备和计算机存储介质
WO2020015067A1 (zh) 数据采集方法、装置、设备及存储介质
WO2019037196A1 (zh) 任务分配方法、装置及计算机可读存储介质
WO2019144738A1 (zh) 金融业务的验证方法、装置、设备和计算机存储介质
WO2020019403A1 (zh) 用电量异常检测方法、装置、设备及可读存储介质
WO2019000967A1 (zh) 企业年金交易方法、装置及计算机可读存储介质
WO2020078053A1 (zh) 医疗数据异常检测方法、装置、设备及存储介质
WO2020119115A1 (zh) 数据审核方法、装置、设备及存储介质
WO2020015060A1 (zh) 用电量异常评估方法、装置、设备和计算机存储介质
WO2021027143A1 (zh) 信息推送方法、装置、设备及计算机可读存储介质
WO2020087981A1 (zh) 风控审核模型生成方法、装置、设备及可读存储介质
WO2017111195A1 (ko) 신뢰도 평가기반의 차량 직거래 인터페이스 제공 방법 및 이를 운용하는 서버
WO2021027158A1 (zh) 车辆信息的推送方法、装置、设备及计算机可读存储介质
WO2021003956A1 (zh) 产品信息的管理方法、装置、设备及存储介质
WO2020107591A1 (zh) 重复投保限制方法、装置、设备及可读存储介质
WO2020077837A1 (zh) 业务数据核算方法、装置、设备及计算机可读存储介质
WO2020119118A1 (zh) 异常数据的处理方法、装置、设备及计算机可读存储介质
WO2020122291A1 (ko) 인공지능 기반의 공동주택 관리업무지시 자동화 장치 및 방법
WO2020087985A1 (zh) 赔付金额的调整方法、装置、设备及可读存储介质
WO2019033511A1 (zh) 基于数据库的数据透视方法、装置和计算机存储介质
WO2020215701A1 (zh) 眼部图像处理方法、装置、设备及计算机可读存储介质
WO2020143296A1 (zh) 数据采集方法、装置、设备及计算机可读存储介质
WO2020062645A1 (zh) 基于数据分析的定价方法、设备、存储介质及装置
WO2021010706A1 (en) Method and apparatus for generating structured relation information based on a text input
WO2021132831A1 (ko) 인공지능 학습데이터 생성을 위한 크라우드소싱 기반 프로젝트의 작업자 및 검수자의 증감 운영 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18824877

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 20.05.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18824877

Country of ref document: EP

Kind code of ref document: A1