Table data processing method, device, equipment and medium based on actuarial software

Abstract

The present invention discloses a table data processing method based on actuarial software, comprising: after determining that the actuarial software has successfully uploaded a table, querying the target expansion field corresponding to the table and the target expansion data corresponding to the target expansion field from a pre-set data expansion table; adding the target expansion field and the target expansion data to the table; judging whether the table has a corresponding merge table; when judging that the table has a corresponding merge table, merging the data in the table into the merge table corresponding to the table; when judging that the table does not have a corresponding merge table, creating a merge table corresponding to the table, and triggering the execution of an operation to merge the data in the table into the merge table corresponding to the table. It can be seen that the present invention can integrate the table data in the actuarial software, which is conducive to the data docking between the external business system and the actuarial software. The present invention also relates to the field of blockchain technology.

Description

Technical Field

[0001] The present invention relates to the technical field of data reporting, and in particular to a method, device, computer equipment and storage medium for processing table data based on actuarial software. Background Art

[0002] Prophet is a very mature actuarial software that is widely used in the financial services industry. It can provide a variety of financial service functions such as profit testing, asset valuation, business model setting, etc., thereby meeting the various business needs of financial services companies. However, due to the complexity and diversity of Prophet software's functions, the tables generated by Prophet software are also complex and numerous. As a result, when connecting data between external business systems and Prophet software, it may even be necessary to access hundreds or even thousands of tables. The data in the tables is usually messy and cannot meet the data connection requirements of external business systems (for example, some tables may lack fields and data required by external business systems). It can be seen that existing actuarial software has many tables and messy data, and fails to meet the data connection requirements of external business systems, which is not conducive to data connection between external business systems and actuarial software. Summary of the Invention

[0003] The technical problem to be solved by the present invention is that the existing actuarial software has numerous tables and messy data, and fails to meet the data docking requirements of external business systems, which is not conducive to data docking between external business systems and actuarial software.

[0004] In order to solve the above technical problems, the first aspect of the present invention discloses a table data processing method based on actuarial software, the method comprising:

[0005] After confirming that the actuarial software has successfully uploaded the form, querying the target expansion field corresponding to the form and the target expansion data corresponding to the target expansion field from a pre-set data expansion table;

[0006] adding the target extension field and the target extension data to the table;

[0007] Determine whether the table has a corresponding merged table;

[0008] When it is determined that the table has a corresponding merged table, merging the data in the table into the merged table corresponding to the table;

[0009] When it is determined that the table does not have a corresponding merged table, a merged table corresponding to the table is created, and the operation of merging the data in the table into the merged table corresponding to the table is triggered.

[0010] A second aspect of the present invention discloses a table data processing device based on actuarial software, the device comprising:

[0011] A query module is used to query the target expansion field corresponding to the table and the target expansion data corresponding to the target expansion field from a preset data expansion table after determining that the actuarial software has successfully uploaded the table;

[0012] an adding module, configured to add the target extension field and the target extension data to the table;

[0013] A judgment module, used to judge whether the table has a corresponding merged table;

[0014] a merging module, configured to merge the data in the table into the merged table corresponding to the table when the judging module judges that the table has a corresponding merged table;

[0015] A creation module is used to create a merged table corresponding to the table when the judgment module determines that the table does not have a corresponding merged table, and trigger the merging module to execute the operation of merging the data in the table into the merged table corresponding to the table.

[0016] A third aspect of the present invention discloses a computer device, comprising:

[0017] a memory storing executable program code;

[0018] a processor connected to the memory;

[0019] The processor calls the executable program code stored in the memory to execute part or all of the steps in the table data processing method based on actuarial software disclosed in the first aspect of the present invention.

[0020] The fourth aspect of the present invention discloses a computer storage medium, which stores computer instructions. When the computer instructions are called, they are used to execute some or all of the steps in the table data processing method based on actuarial software disclosed in the first aspect of the present invention.

[0021] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0022] In an embodiment of the present invention, after the actuarial software successfully uploads a table, the data in the table is expanded according to the data docking requirements of different business systems, and then after ensuring that a corresponding merged table exists for the table (determine whether a corresponding merged table exists for the table, and if no corresponding merged table exists, create a merged table corresponding to the table), the data in the table is merged into the merged table, so that the table uploaded by the actuarial software can be integrated into the merged table, and by expanding the table data, the merged table obtained after the data merging can adapt to the data docking requirements of different business systems, which facilitates the use of the merged table for data docking of different business systems, and is beneficial to the data docking of external business systems with the actuarial software. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0024] Figure 1 This is a flow chart of a table data processing method based on actuarial software disclosed in an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of the structure of a table data processing device based on actuarial software disclosed in an embodiment of the present invention;

[0026] Figure 3 It is a structural diagram of a computer device disclosed in an embodiment of the present invention;

[0027] Figure 4 It is a structural diagram of a computer storage medium disclosed in an embodiment of the present invention. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0029] The terms "first," "second," and so on, in the description and claims of the present invention and the accompanying drawings are used to distinguish between different items, not to describe a specific order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or end comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed therein, or may optionally include other steps or elements inherent to such process, method, product, or end.

[0030] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute a separate or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0031] The present invention discloses a table data processing method, device, computer equipment and storage medium based on actuarial software. After the actuarial software successfully uploads a table, the data of the table can be expanded according to the data docking requirements of different business systems. Then, after ensuring that a corresponding merged table exists for the table (determining whether a corresponding merged table exists for the table, and if no corresponding merged table exists, creating a merged table corresponding to the table), the data in the table is merged into the merged table, so that the table uploaded by the actuarial software can be integrated into the merged table. Moreover, by expanding the table data, the merged table obtained after the data merging can adapt to the data docking requirements of different business systems, making it easy to use the merged table to perform data docking of different business systems, thereby facilitating data docking of external business systems with the actuarial software. Detailed descriptions are given below.

[0032] Example 1

[0033] See also Figure 1 , Figure 1 This is a flow chart of a table data processing method based on actuarial software disclosed in an embodiment of the present invention. Figure 1 As shown, the table data processing method based on actuarial software may include the following operations:

[0034] 101. After confirming that the actuarial software has successfully uploaded the table, query the target expansion field corresponding to the table and the target expansion data corresponding to the target expansion field from a preset data expansion table.

[0035] 102. Add the target extension field and the target extension data to the table.

[0036] 103. Determine whether there is a corresponding merged table for the table.

[0037] 104. When it is determined that a corresponding merged table exists for the table, merge the data in the table into the merged table corresponding to the table.

[0038] 105. When it is determined that the table does not have a corresponding merged table, create a merged table corresponding to the table, and trigger the execution of the operation of merging the data in the table into the merged table corresponding to the table.

[0039] In an embodiment of the present invention, the actuarial software may refer to the prophet actuarial software. In a system including prophet, an upload log table named prophet_result may be generated. The upload log table is used to store records of each upload of a form by prophet. Each upload record may include information such as the table name prefix (described later), the time when the upload starts, the time when the upload is completed, the upload role, and the upload result of the form corresponding to the upload record. The upload result can be represented by an identifier in a field named success set in the upload log table. If the identifier in the success field is 1, it indicates that the form corresponding to the upload record has been successfully uploaded. If the identifier in the success field is 0, it indicates that the form corresponding to the upload record has failed to be uploaded. A scheduled task may be set in the system to regularly scan the upload log table. If there is an update to the upload log table, and the identifier in the success field in the updated record is 1, it can be determined that prophet has successfully uploaded the form and subsequent processing begins.

[0040] In addition, the table name prefix of the uploaded table can be pre-set according to factors such as the business or product involved in the table, and then the table name prefix of the table can be used to find the merged table to which the table will be merged. Among them, the table name of the merged table can be set according to the table name prefix of the uploaded table, which makes it easy to find the corresponding merged table according to the table name prefix of the uploaded table. For example, the table name of the uploaded table is life_date, and the life_date table stores relevant date information of life insurance, where life is the table name prefix pre-set for the life_date table, which is used to indicate that the life_date table is a related table for life insurance. Then, the table name of the merged table can be set to the uppercase letter of the table name prefix, such as the table name of the merged table corresponding to the life_date table is set to LIFE, indicating that the merged table is used to store relevant data of life insurance. In this way, by setting the association relationship between the uploaded forms and the merged forms, the data of the forms to be merged can be merged into the corresponding merged forms. The merging rules can also be set according to actual needs. For example, forms belonging to the same product can be merged into the same merged form (for example, forms related to life insurance are merged into the same form, and forms related to auto insurance are merged into another merged form), forms belonging to the same salesperson can be merged into the same merged form, and so on.

[0041] If a table has been successfully uploaded but no existing merge table is found, you can create a new merge table for the successfully uploaded table and then merge the successfully uploaded table into the newly created merge table. The table name of the newly created merge table can be set to the capital letter prefix of the table name. For example, if the life_date table is successfully uploaded but the LIFE merge table is not found, you can create a new LIFE merge table and then merge the life_date table into the LIFE merge table.

[0042] Optionally, merging the data in the table into a merged table corresponding to the table includes:

[0043] Determine whether each field in the table has a corresponding target field in the merged table corresponding to the table;

[0044] When it is determined that the field has a corresponding target field, the data of the field is written to the target field corresponding to the field;

[0045] When it is determined that there is no corresponding target field for the field, a target field corresponding to the field is created in the merged table corresponding to the table, and the operation of writing the data of the field to the target field corresponding to the field is triggered.

[0046] When merging tables into corresponding merged tables, the fields in the tables remain unchanged and the data in the tables is merged into the corresponding merged table. If the fields in the table have corresponding fields in the merged table, the data in the fields in the table are copied to the corresponding fields in the merged table. If the fields in the table do not have corresponding fields in the merged table, corresponding fields are created in the merged table, and then the data in the fields in the table are copied to the newly created fields.

[0047] For example, the life_date table is:

[0048] ueser begin_date salesman Zhang San 2020-01-01 Li Si

[0049] The LIFE merged table corresponding to the life_date table is:

[0050] ueser begin_date expiredate Wang Wu 2020-02-01 3 years

[0051] After merging the life_date table into the LIFE merged table, the new LIFE merged table is:

[0052] ueser begin_date expiredate salesman Wang Wu 2020-02-01 3 years Zhang San 2020-01-01 Li Si

[0053] In the embodiment of the present invention, the system that includes prophet usually also needs to carry out data docking with other business systems. When docking with other business systems, different business systems usually have different requirements for the format of docking data. For example, some business systems need to verify the source of data. When docking with these business systems, the form of transmission needs to include the field (such as database name field, IP address field, etc.) that can be used for the business system to verify the source of data. Other business systems have requirements for the version number of data. When docking with these business systems, the form of transmission needs to include the version number field of data. To realize directly using the merged form to carry out data docking with other business systems, the data of the form needs to be appropriately expanded to adapt to the data docking requirements of different business systems. To adapt to the data docking requirements, the expansion fields and expansion data corresponding to different forms can be pre-stored in the data expansion form. Like this, when the form needs to be expanded, the target expansion fields and target expansion data corresponding to the form can be queried from the data expansion form. For example, for the life_date table above, if the target expansion field is version and the target expansion data is 2.0, the life_date table after expansion data is:

[0054] ueser begin_date salesman version Zhang San 2020-01-01 Li Si 2.0

[0055] After merging the expanded life_date table into the merged table, the merged table will also include a version field. This allows the merged table to be used directly for data integration when the business system needs to verify the version number of the table data, improving the applicability of the merged table.

[0056] It can be seen that implementation Figure 1 The described table data processing method based on actuarial software can expand the table data according to the data docking requirements of different business systems after the actuarial software successfully uploads the table, and then merge the data in the table into the merged table after ensuring that a corresponding merged table exists for the table (determine whether a corresponding merged table exists for the table, and if no corresponding merged table exists, create a merged table corresponding to the table), so that the table uploaded by the actuarial software can be integrated into the merged table, and by expanding the table data, the merged table obtained after the data merging can adapt to the data docking requirements of different business systems, making it convenient to use the merged table for data docking of different business systems, and thus facilitating data docking between external business systems and actuarial software.

[0057] In an optional embodiment, before determining that the actuarial software has successfully uploaded the form, the method further includes:

[0058] detecting whether a request to upload the form from the actuarial software has been received;

[0059] When receiving a request from the actuarial software to upload the form, starting to receive form data corresponding to the form uploaded by the actuarial software;

[0060] If the form data is not received successfully, a warning prompt is sent to the target terminal that uploaded the form data, wherein the warning prompt is used to prompt the user of the target terminal that the form upload has failed;

[0061] If the form data is received successfully, it is determined that the actuarial software has successfully uploaded the form.

[0062] In this optional embodiment, the data stored in the tables involved in the financial system is usually quite large, so uploading a table usually takes about ten to thirty minutes. Since it takes a long time to upload a table, and whether the table can be successfully uploaded is affected by many factors (such as the quality of the transmission network, the stability of the system, etc.), there is a possibility that the table upload fails. In addition, uploading a table takes a certain amount of time. If the table upload fails and the table is not re-uploaded in time, it is easy to cause a waste of time. Therefore, it is necessary to detect whether the table has been successfully uploaded. If it is detected that the table upload failed, the relevant person who uploaded the form is notified so that the relevant person can re-upload the form in time to reduce the waste of time. In addition, the method of sending a warning prompt to the target terminal (i.e., notifying the relevant person who uploaded the form) can be by sending an email or by sending a message through a real-time communication tool (such as Happy Ping An, WeChat, DingTalk, etc.).

[0063] It can be seen that the implementation of this optional embodiment can detect whether the form is uploaded successfully when the actuarial software uploads the form, and issue a warning prompt if the form is not uploaded successfully, thereby ensuring the smooth progress of the form merging and improving the reliability and efficiency of the form merging.

[0064] In an optional embodiment, after receiving the request from the actuarial software to upload the form, and before starting to receive the form data corresponding to the form uploaded by the actuarial software, the method further includes:

[0065] Calculate the upload time required for the actuarial software to upload the form;

[0066] Determining the completion time of the actuarial software uploading the form based on the current time and the upload duration;

[0067] Obtaining a working time period of the target terminal;

[0068] Determining whether the completion time is within the working time period;

[0069] When it is determined that the completion time is within the working time period, the operation of starting to receive the table data corresponding to the table uploaded by the actuarial software is triggered.

[0070] In this optional embodiment, due to the high security requirements of the financial system, the financial system usually sets certain restrictions on the target terminal uploading data. For example, the target terminal is usually not allowed to upload data during non-working hours. For another example, to ensure the normal operation of the financial system, the data upload time period for terminals in different areas will be set to different time periods (such as terminals in area A are only allowed to upload forms from 9:00 am to 11:00 am, and terminals in area B are only allowed to upload forms from 3:00 pm to 5:00 pm). Since uploading a form takes a certain amount of time, if the form cannot be uploaded within the working time period allowed by the target terminal to upload the form, the form upload will fail. If this situation occurs frequently, it is easy to cause confusion in the form data in the system, which is not conducive to maintaining the normal operation of the system. Therefore, after receiving a request from Prophet to upload a form, the upload time required for Prophet to upload the form is first estimated. If it is estimated that the form upload can be completed within the target terminal's working time, the form uploaded by Prophet will be accepted. If it is estimated that the form upload cannot be completed within the target terminal's working time, a return prompt can be issued to the target terminal, prompting the target terminal user that the form uploaded will be returned and will not be uploaded. Optionally, after it is estimated that the form upload cannot be completed within the target terminal's working time, the form uploaded can be cached in a predetermined cache space. At the beginning of the next target terminal's working time, the form stored in the cache space can be uploaded. The upload time required for Prophet to upload the form can be calculated as follows: first, the data volume of the form to be uploaded is determined. Then, based on the upload speed estimated from the target terminal's network quality or the upload status of previous form uploads, the upload time required for Prophet to upload the form is calculated. For example, if the data volume of the form to be uploaded is 1GB and the estimated upload speed is 1M / s, the upload time required for Prophet to upload the form is calculated to be approximately 15 minutes.

[0071] It can be seen that the implementation of this optional embodiment can estimate the upload time required for the actuarial software to upload the form, and then determine whether the upload of the form can be completed within the working time period of the target terminal. Only after it is determined that the upload of the form can be completed, will the form uploaded by the actuarial software be received. This is conducive to ensuring the successful upload of the form, ensuring the normal progress of the form merging, and maintaining the normal operation of the system.

[0072] In an optional embodiment, after merging the data in the table into a merged table corresponding to the table, the method further includes:

[0073] Verify the data in the merged table corresponding to the table;

[0074] If the verification is passed, a merge success prompt is sent to the target terminal, where the merge success prompt is used to prompt the user of the target terminal that the tables have been merged successfully;

[0075] If the verification fails, a merge failure prompt is sent to the target terminal, where the merge failure prompt is used to prompt the user of the target terminal that the table merge has failed.

[0076] In this optional embodiment, similar to the table upload process, because the tables involved in financial systems can store a large amount of data, merging tables also takes a certain amount of time. Furthermore, the merging process is affected by many factors (e.g., system performance, processing thread availability, etc.), resulting in the possibility of table merging failure or table merging errors. Furthermore, because financial systems generally require high data accuracy, after the table merging is completed, the data in the merged table needs to be verified to ensure the reliability of the table merging. Furthermore, because table uploading and merging takes a long time, after the table upload and merging is completed and the merged table passes verification, the relevant person who uploaded the form needs to be notified that the table merging is complete, allowing the relevant person to proceed to the next business process, thereby improving the operational efficiency of the business process. If the merged table fails to pass verification, the relevant person needs to be notified so that they can take appropriate measures to restore the table merging to normal. Furthermore, the method of sending the merge success or merge failure notification (i.e., notifying the relevant person) to the target terminal can be by sending an email or a message via an instant messaging tool (such as Kuaisui Ping An, WeChat, DingTalk, etc.).

[0077] It can be seen that by implementing this optional embodiment, after the tables are merged, the data in the merged table can be verified to verify whether the table merge has been performed correctly, thereby improving the reliability and processing efficiency of the table merge.

[0078] In an optional embodiment, verifying the data in the merged table corresponding to the table includes:

[0079] Obtaining a first total number of all tables that have been successfully uploaded by the actuarial software and correspond to the merged table;

[0080] Obtaining a second total number of all tables that have been successfully merged into the merged table;

[0081] Determine whether the first total quantity and the second total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or,

[0082] calculating a third total number of records contained in the table;

[0083] Obtaining a fourth total number of records processed when merging the table;

[0084] Determine whether the third total quantity and the fourth total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or,

[0085] Calculating a first sum of the data in the table;

[0086] calculating a second sum of the data processed when the tables are merged;

[0087] It is determined whether the first sum and the second sum are the same; if they are the same, the verification passes; if they are not the same, the verification fails.

[0088] In this optional embodiment, a merge log table named merge_result can be generated in a system including prophet. The merge log table is used to save records of each table merge. Each merge record may include information such as the table name prefix of the table merged this time, the time when the merge started, and the time when the merge was completed. By querying the prophet_result upload log table and the merge_result merge log table, the first total quantity and the second total quantity can be obtained. The third total quantity can be calculated by the count statement in the SQL statement, and the fourth total quantity can be obtained by querying the merge_result merge log table. The first sum and the second sum can be calculated by the sum statement in the SQL statement.

[0089] It can be seen that implementing this optional embodiment can provide multiple merge verification methods, ensure the correct execution of table merge, and improve the reliability of table merge.

[0090] In an optional embodiment, after sending the merge failure prompt to the target terminal, the method further includes:

[0091] If it is determined that the first total amount and the second total amount are not the same or the first sum and the second sum are not the same, requesting the actuarial software to upload the form again;

[0092] If it is determined that the third total quantity and the fourth total quantity are different, the operation of merging the data in the table into the merged table corresponding to the table is triggered again.

[0093] In this optional embodiment, in the verification of the merged table, if the first total quantity and the second total quantity are not the same or the first sum and the second sum are not the same, there is a high possibility that errors have occurred in both the uploading process and the merging process of the table, so at this time it is necessary to request prophet to upload the table again, and then merge the table again based on the re-uploaded table. This is equivalent to performing both the uploading process and the merging process of the table again, which is conducive to restoring the merging of the tables to normal. If the third total quantity and the fourth total quantity are not the same, it is that an error has occurred in the merging process of the table, so at this time it is only necessary to perform the operation of merging the data in the table into the merged table again.

[0094] It can be seen that by implementing this optional embodiment, different repair operations can be performed according to the result of the merge check when the merge check fails, thereby achieving automatic repair of the table merge, which is beneficial to improving the reliability of the table merge operation.

[0095] Optionally, it is also possible to upload the combined result information of the table data processing method based on the actuarial software to the blockchain.

[0096] Specifically, the merge result information, obtained by running the table data processing method based on actuarial software, records the table merge status, such as the table name of the merged table, the data in the merged table, and the data in the merged table. Uploading the merge result information to the blockchain ensures its security and fairness and transparency for users. Users can download this merge result information from the blockchain to verify whether the merge result information generated by the table data processing method based on actuarial software has been tampered with. The blockchain referred to in this example is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Blockchain is essentially a decentralized database, a string of data blocks generated using cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of the information (to prevent counterfeiting) and generate the next block. Blockchain can include the blockchain underlying platform, the platform product service layer, and the application service layer.

[0097] As can be seen, the method for processing table data based on actuarial software disclosed in Example 1 can, after the actuarial software successfully uploads a table and ensures that a corresponding merged table exists for the table, maintain the data fields in the table unchanged and merge the data into the merged table. This allows the table uploaded by the actuarial software to be integrated into the merged table, facilitating user verification and statistics of table data in the actuarial software. It can also expand the table data based on the data connection requirements of different business systems, so that the merged table obtained after the data merging can adapt to the data connection requirements of different business systems, facilitating the use of the merged table for data connection between different business systems and improving the applicability of the merged table. It can also detect whether the table upload is successful when the actuarial software uploads the table, and issue a warning if the table upload is not successful, thereby ensuring the smooth progress of the table merging and improving the reliability and efficiency of the table merging. It can also estimate the upload time required for the actuarial software to upload the table, and then determine whether the table upload can be completed within the working hours of the target terminal. Only after it is determined that the table upload can be completed will the form uploaded by the actuarial software be received. This helps ensure the successful upload of the table, ensure the normal progress of the table merging, and maintain the normal operation of the system. After merging tables, the data in the merged tables can be verified to verify whether the merge was performed correctly, thereby improving the reliability and processing efficiency of the table merge. It can also provide multiple merge verification methods to ensure the correctness of the table merge and improve the reliability of the table merge. If the merge verification fails, different repair operations can be performed based on the results of the merge verification, thereby achieving automatic repair of the table merge, which is conducive to improving the reliability of the table merge operation.

[0098] Example 2

[0099] See also Figure 2 , Figure 2 This is a schematic diagram of the structure of a table data processing device based on actuarial software disclosed in an embodiment of the present invention. Figure 2 As shown, the table data processing device based on actuarial software may include:

[0100] The query module 201 is configured to query the target expansion field corresponding to the table and the target expansion data corresponding to the target expansion field from a preset data expansion table after determining that the actuarial software has successfully uploaded the table;

[0101] An adding module 202, configured to add the target expansion field and the target expansion data to the table;

[0102] A judgment module 203 is used to judge whether the table has a corresponding merged table;

[0103] A merging module 204 is configured to merge the data in the table into the corresponding merged table when the judging module 203 judges that the table has a corresponding merged table;

[0104] The creation module 205 is used to create a merged table corresponding to the table when the judgment module 203 determines that the table does not have a corresponding merged table, and trigger the merging module 204 to execute the operation of merging the data in the table into the merged table corresponding to the table.

[0105] In an optional embodiment, the table data processing device based on actuarial software may further include:

[0106] a detection module, configured to detect whether a request from the actuarial software to upload the form is received before the query module 201 determines that the actuarial software has successfully uploaded the form;

[0107] The receiving module is configured to, when the detection module receives a request from the actuarial software to upload the form, start receiving the table data corresponding to the table uploaded by the actuarial software; if the table data is not received successfully, send a warning prompt to the target terminal that uploaded the table data, wherein the warning prompt is used to prompt the user of the target terminal that the table upload has failed; if the table data is received successfully, trigger the query module 201 to determine whether the actuarial software has successfully uploaded the table.

[0108] In an optional embodiment, the table data processing device based on actuarial software may further include:

[0109] a calculation module, configured to calculate the upload time required for the actuarial software to upload the form after the detection module receives the request from the actuarial software to upload the form and before the receiving module starts receiving the form data corresponding to the form uploaded by the actuarial software;

[0110] A determination module, configured to determine a completion time when the actuarial software completes uploading the form based on the current time and the upload duration;

[0111] An acquisition module, configured to acquire a working time period of the target terminal;

[0112] The judgment module 203 is further used to judge whether the completion time is within the working time period; when it is judged that the completion time is within the working time period, the receiving module is triggered to execute the operation of starting to receive the table data corresponding to the table uploaded by the actuarial software.

[0113] In an optional embodiment, the table data processing device based on actuarial software may further include:

[0114] a verification module, configured to verify the data in the merged table corresponding to the table after the merging module 204 merges the data in the table into the merged table corresponding to the table;

[0115] A sending module, configured to send a merge success prompt to the target terminal when the verification is passed, wherein the merge success prompt is used to prompt a user of the target terminal that the tables have been merged successfully;

[0116] The sending module is further configured to send a merge failure prompt to the target terminal when the verification fails, wherein the merge failure prompt is configured to prompt the user of the target terminal that the table merge has failed.

[0117] In an optional embodiment, the specific manner in which the verification module verifies the data in the merged table corresponding to the table is:

[0118] Obtaining a first total number of all tables that have been successfully uploaded by the actuarial software and correspond to the merged table;

[0119] Obtaining a second total number of all tables that have been successfully merged into the merged table;

[0120] Determine whether the first total quantity and the second total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or,

[0121] calculating a third total number of records contained in the table;

[0122] Obtaining a fourth total number of records processed when merging the table;

[0123] Determine whether the third total quantity and the fourth total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or,

[0124] Calculating a first sum of the data in the table;

[0125] calculating a second sum of the data processed when the tables are merged;

[0126] It is determined whether the first sum and the second sum are the same; if they are the same, the verification passes; if they are not the same, the verification fails.

[0127] In an optional embodiment, the table data processing device based on actuarial software may further include:

[0128] A repair module is used to request the actuarial software to upload the table again after the sending module sends a merge failure prompt to the target terminal, if the verification module has determined that the first total quantity and the second total quantity are not the same or the first sum and the second sum are not the same; if the verification module has determined that the third total quantity and the fourth total quantity are not the same, trigger the merge module 204 again to perform the operation of merging the data in the table into the merged table corresponding to the table.

[0129] In an optional embodiment, the specific manner in which the merging module 204 merges the data in the table into the merged table corresponding to the table is:

[0130] Determine whether each field in the table has a corresponding target field in the merged table corresponding to the table;

[0131] When it is determined that the field has a corresponding target field, the data of the field is written to the target field corresponding to the field;

[0132] When it is determined that there is no corresponding target field for the field, a target field corresponding to the field is created in the merged table corresponding to the table, and the operation of writing the data of the field to the target field corresponding to the field is triggered.

[0133] For the detailed description of the table data processing device based on actuarial software, reference may be made to the detailed description of the table data processing method based on actuarial software, which will not be described in detail here.

[0134] Example 3

[0135] See also Figure 3 , Figure 3 This is a schematic diagram of the structure of a computer device disclosed in an embodiment of the present invention. Figure 3 As shown, the computer device may include:

[0136] A memory 301 storing executable program code;

[0137] a processor 302 connected to the memory 301;

[0138] The processor 302 calls the executable program code stored in the memory 301 to execute the steps of the table data processing method based on actuarial software disclosed in the first embodiment of the present invention.

[0139] Example 4

[0140] The embodiment of the present invention discloses a computer storage medium 401, which stores computer instructions. When the computer instructions are called, they are used to execute the steps of the table data processing method based on actuarial software disclosed in the first embodiment of the present invention.

[0141] The device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, i.e., they may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Those skilled in the art can understand and implement the present invention without inventive effort.

[0142] Through the detailed description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus the necessary general hardware platform, or of course, by means of hardware. Based on this understanding, the above technical solution, in essence, or the portion that contributes to the prior art, can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, including a read-only memory (ROM), a random access memory (RAM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), a one-time programmable read-only memory (OTPROM), an electronically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, magnetic disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0143] Finally, it should be noted that the table data processing method, device, computer equipment and storage medium based on actuarial software disclosed in the embodiments of the present invention are only preferred embodiments of the present invention, which are only used to illustrate the technical solutions of the present invention, rather than to limit them. Although the present invention has been described in detail with reference to the aforementioned embodiments, it should be understood by those skilled in the art that the technical solutions described in the aforementioned embodiments can still be modified, or some of the technical features therein can be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.

Claims

1. A table data processing method based on actuarial software, characterized in that: The method comprises: After confirming that the actuarial software has successfully uploaded the form, querying the target expansion field corresponding to the form and the target expansion data corresponding to the target expansion field from a pre-set data expansion table; adding the target extension field and the target extension data to the table; Determine whether the table has a corresponding merged table, wherein the table name prefix of the table corresponds to the table name of the merged table corresponding to the table; When it is determined that the table has a corresponding merged table, merging the data in the table into the merged table corresponding to the table; When it is determined that the table does not have a corresponding merged table, a merged table corresponding to the table is created, and the operation of merging the data in the table into the merged table corresponding to the table is triggered.

2. The table data processing method based on actuarial software according to claim 1, characterized in that: Before determining that the actuarial software has successfully uploaded the form, the method further includes: detecting whether a request to upload the form from the actuarial software has been received; When receiving a request from the actuarial software to upload the form, starting to receive form data corresponding to the form uploaded by the actuarial software; If the form data is not received successfully, a warning prompt is sent to the target terminal that uploaded the form data, wherein the warning prompt is used to prompt the user of the target terminal that the form upload has failed; If the form data is received successfully, it is determined that the actuarial software has successfully uploaded the form.

3. The table data processing method based on actuarial software according to claim 2, characterized in that: After receiving the request from the actuarial software to upload the form, and before starting to receive the form data corresponding to the form uploaded by the actuarial software, the method further includes: Calculate the upload time required for the actuarial software to upload the form; Determining the completion time of the actuarial software uploading the form based on the current time and the upload duration; Obtaining a working time period of the target terminal; Determining whether the completion time is within the working time period; When it is determined that the completion time is within the working time period, the operation of starting to receive the table data corresponding to the table uploaded by the actuarial software is triggered.

4. The table data processing method based on actuarial software according to any one of claims 1 to 3, characterized in that: After merging the data in the table into a merged table corresponding to the table, the method further includes: Verify the data in the merged table corresponding to the table; If the verification is passed, a merge success prompt is sent to the target terminal, where the merge success prompt is used to prompt the user of the target terminal that the tables have been merged successfully; If the verification fails, a merge failure prompt is sent to the target terminal, where the merge failure prompt is used to prompt the user of the target terminal that the table merge has failed.

5. The table data processing method based on actuarial software according to claim 4, characterized in that: The verifying the data in the merged table corresponding to the table includes: Obtaining a first total number of all tables that have been successfully uploaded by the actuarial software and correspond to the merged table; Obtaining a second total number of all tables that have been successfully merged into the merged table; Determine whether the first total quantity and the second total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or, calculating a third total number of records contained in the table; Obtaining a fourth total number of records processed when merging the table; Determine whether the third total quantity and the fourth total quantity are the same, if they are the same, the verification passes, if they are not the same, the verification fails; or, Calculating a first sum of the data in the table; calculating a second sum of the data processed when the tables are merged; It is determined whether the first sum and the second sum are the same; if they are the same, the verification passes; if they are not the same, the verification fails.

6. The table data processing method based on actuarial software according to claim 5, characterized in that: After sending the merge failure prompt to the target terminal, the method further includes: If it is determined that the first total amount and the second total amount are not the same or the first sum and the second sum are not the same, requesting the actuarial software to upload the form again; If it is determined that the third total quantity and the fourth total quantity are different, the operation of merging the data in the table into the merged table corresponding to the table is triggered again.

7. The table data processing method based on actuarial software according to any one of claims 1 to 3, characterized in that: Merging the data in the table into a merged table corresponding to the table includes: Determine whether each field in the table has a corresponding target field in the merged table corresponding to the table; When it is determined that the field has a corresponding target field, the data of the field is written to the target field corresponding to the field; When it is determined that there is no corresponding target field for the field, a target field corresponding to the field is created in the merged table corresponding to the table, and the operation of writing the data of the field to the target field corresponding to the field is triggered.

8. A table data processing device based on actuarial software, the device being used to implement the steps of the table data processing method based on actuarial software according to any one of claims 1 to 7, characterized in that: The device comprises: A query module is used to query the target expansion field corresponding to the table and the target expansion data corresponding to the target expansion field from a preset data expansion table after determining that the actuarial software has successfully uploaded the table; an adding module, configured to add the target extension field and the target extension data to the table; A judgment module, used to judge whether the table has a corresponding merged table; a merging module, configured to merge the data in the table into the merged table corresponding to the table when the judging module judges that the table has a corresponding merged table; A creation module is used to create a merged table corresponding to the table when the judgment module determines that the table does not have a corresponding merged table, and trigger the merging module to execute the operation of merging the data in the table into the merged table corresponding to the table.

9. A computer device, characterized in that: The computer device comprises: a memory storing executable program code; a processor connected to the memory; The processor calls the executable program code stored in the memory to execute the table data processing method based on actuarial software according to any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the table data processing method based on actuarial software according to any one of claims 1 to 7 is implemented.

Images