CN107239325B - Document data processing method and device - Google Patents

Document data processing method and device Download PDF

Info

Publication number
CN107239325B
CN107239325B CN201610182478.XA CN201610182478A CN107239325B CN 107239325 B CN107239325 B CN 107239325B CN 201610182478 A CN201610182478 A CN 201610182478A CN 107239325 B CN107239325 B CN 107239325B
Authority
CN
China
Prior art keywords
underwriting
policy
task table
electronic
document data
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201610182478.XA
Other languages
Chinese (zh)
Other versions
CN107239325A (en
Inventor
陈长东
马骄
王飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
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 Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Priority to CN201610182478.XA priority Critical patent/CN107239325B/en
Publication of CN107239325A publication Critical patent/CN107239325A/en
Application granted granted Critical
Publication of CN107239325B publication Critical patent/CN107239325B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08Insurance

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention relates to a document data processing method and device. The method comprises the following steps: establishing a first task table; acquiring document data and extracting a state mark in the document data; judging whether the state mark is an underwriting success state mark or not; if the status mark is an underwriting success status mark, adding the document data into the first task table; and calling an electronic insurance policy generation thread to respectively execute the tasks in the first task table and generate a corresponding electronic insurance policy. The document data processing method and the document data processing device effectively reduce the error rate of electronic insurance policy generation and can improve the generation efficiency of the electronic insurance policy.

Description

Document data processing method and device
Technical Field
The invention relates to the field of computers, in particular to a document data processing method and device.
Background
In an insurance business, when an applicant buys an insurance product, a clerk enters insurance information related to the applicant, such as the name of the applicant, the kind of risk purchased, the amount of the insurance, and the like, into an underwriting system. The underwriting system can detect according to the input insurance information, and when the detection is passed, the underwriting system carries out underwriting and generates a corresponding electronic insurance policy. In a traditional underwriting system, electronic insurance policies are generated by processing according to underwriting batches, and in the processing process, when data of one electronic insurance policy in the underwriting batch is wrong, such as missing generation, the subsequent electronic insurance policy generation errors can be caused, the problem of repeated generation of the electronic insurance policies or delayed generation of the electronic insurance policies of the whole underwriting batch is easily caused, and the generation efficiency is low.
Disclosure of Invention
Accordingly, there is a need for a document data processing method that can improve the generation efficiency of an electronic policy and effectively reduce the error rate of electronic policy generation.
In addition, it is necessary to provide a document data processing apparatus capable of improving the generation efficiency of the electronic insurance policy and effectively reducing the error rate of the generation of the electronic insurance policy.
A document data processing method comprises the following steps:
establishing a first task table;
acquiring document data and extracting a state mark in the document data;
judging whether the state mark is an underwriting success state mark or not;
if the status mark is an underwriting success status mark, adding the document data into the first task table;
and calling an electronic insurance policy generation thread to respectively execute the tasks in the first task table and generate a corresponding electronic insurance policy.
In one embodiment, the invoking an electronic policy generation thread respectively executes the tasks in the first task table and generates the corresponding electronic policy, specifically including:
judging whether an idle electronic policy generating thread exists at present;
if yes, calling the idle electronic insurance policy generation thread to execute the task in the first task table and generate a corresponding electronic insurance policy;
if not, judging whether the number of the current electronic insurance policy generation threads is smaller than a preset threshold value, if so, creating a new electronic insurance policy generation thread to execute the tasks in the first task table, and generating the corresponding electronic insurance policy.
In one embodiment, the method further comprises the steps of:
establishing a second task table;
if the status mark of the document data is a underwriting failure status mark, adding the document data into the second task table;
and calling an underwriting thread to execute the tasks in the second task table, carrying out underwriting again, and generating corresponding policy data.
In one embodiment, after the step of invoking the underwriting thread to execute the task in the second task table, re-underwriting, and generating the corresponding policy data, the method further includes:
and calling a preset underwriting interface to return a re-underwriting result and corresponding policy data.
In one embodiment, after the step of invoking the underwriting thread to execute the task in the second task table, re-underwriting, and generating the corresponding policy data, the method further includes:
adding the policy data to the first task table;
and calling the electronic policy generation thread to extract the policy data from the first task table for processing and generating a corresponding electronic policy.
A document data processing apparatus comprising:
the establishing module is used for establishing a first task table;
the extraction module is used for acquiring the document data and extracting the state mark in the document data;
the judging module is used for judging whether the state mark is an underwriting success state mark or not;
the adding module is used for adding the document data into the first task table if the status mark is an underwriting success status mark;
and the generating module is used for calling the electronic insurance policy generating thread to respectively execute the tasks in the first task table and generate the corresponding electronic insurance policy.
In one embodiment, the generating module comprises:
the judging unit is used for judging whether an idle electronic insurance policy generation thread exists at present;
the calling unit is used for calling the idle electronic insurance policy generation thread to execute the task in the first task table and generate a corresponding electronic insurance policy if the idle electronic insurance policy generation thread exists currently;
the judging unit is also used for judging whether the number of the current electronic insurance policy generating threads is less than a preset threshold value or not if no idle electronic insurance policy generating threads exist currently;
and the creating unit is used for creating a new electronic insurance policy generating thread to execute the tasks in the first task table and generate the corresponding electronic insurance policy if the number of the current electronic insurance policy generating threads is less than the preset threshold value.
In one embodiment, the establishing module is further configured to establish a second task table;
the adding module is further used for adding the document data into the second task table if the status mark of the document data is an underwriting failure status mark;
the device also comprises an underwriting module which is used for calling an underwriting thread to execute the tasks in the second task table, conducting underwriting again and generating corresponding insurance policy data.
In one embodiment, the apparatus further comprises:
and the return module is used for calling a preset underwriting interface to return a re-underwriting result and corresponding insurance policy data.
In one embodiment, the adding module is further configured to add the policy data to the first task table;
the generating module is further used for calling the electronic policy generating thread to extract the policy data from the first task table for processing and generating a corresponding electronic policy.
According to the document data processing method and device, the first task table is established, document data with the status marked as successful underwriting is added into the first task table, the electronic policy generation thread is called to respectively execute tasks in the first task table to generate the electronic policies, each electronic policy is generated through processing one by one, when one electronic policy generates errors, generation of other electronic policies in the first task table is not affected, error rate of generation of the electronic policies is effectively reduced, the electronic policies are generated asynchronously through the electronic policy generation thread, and generation efficiency of the electronic policies can be improved.
In addition, the document data with the status mark as underwriting failure is added into the second task table, and the underwriting thread is called to conduct underwriting again, so that the underwriting failure document can be supplemented and underwrited to generate a corresponding electronic insurance policy, the need of re-entering the data for underwriting after the underwriting failure is avoided, the operation is simplified, and the efficiency of underwriting and generating the electronic insurance policy is improved.
Drawings
FIG. 1 is a schematic flow chart diagram illustrating a method for processing document data in one embodiment;
FIG. 2 is a flowchart illustrating an embodiment of invoking an electronic policy generation thread to execute tasks in a first task table and generate a corresponding electronic policy;
FIG. 3 is a schematic flow chart diagram illustrating a method for processing document data according to another embodiment;
FIG. 4 is a schematic diagram of the configuration of a document data processing apparatus according to one embodiment;
FIG. 5 is a diagram illustrating an internal structure of a generation module according to an embodiment;
FIG. 6 is a schematic configuration diagram of a document data processing apparatus according to another embodiment;
FIG. 7 is a schematic structural diagram of a document data processing apparatus according to still another embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
As shown in fig. 1, a document data processing method includes the following steps:
step S110, a first task table is established.
Specifically, the underwriting system may pre-establish a first task table in a background program, where the first task table may be used to store document data for generating the electronic insurance policy, and establish a task according to each piece of document data for generating a corresponding electronic insurance policy.
And step S120, acquiring the document data and extracting the state mark in the document data.
Specifically, the salesman can record the insurance application information related to the insurance applicant at the front end of the underwriting system, and the insurance application information can enter the underwriting stage after being verified by the insurance application rule and generate corresponding document data. The document data may include information such as a document number, a customer number, a date, a risk number, a status flag, and the like, where the status flag in the document data is used to indicate a current processing status of the document, and the status flag may include, but is not limited to, status flags of underwriting, underwriting failure, underwriting success, unprocessed, and the like. And only after the document insurance acceptance is successful, the background program of the underwriting system can generate the corresponding electronic insurance policy and return the corresponding insurance policy data to the foreground program. The background program of the underwriting system can acquire each piece of document data and extract the state marks in the document data. In other embodiments, the document data in different states may also be stored in different data tables, for example, the document data that is successfully underwritten is stored in the underwriting success table, the unprocessed document data is stored in the unprocessed table, and when the document data in a certain state needs to be acquired, the document data in the corresponding data table may be directly read.
Step S130, determining whether the status flag is an underwriting success status flag, if yes, performing step S140, and if no, returning to step S120.
Specifically, after the status flag of the document data is extracted, whether the status flag is the underwriting success status flag or not is further judged, and if the status flag is the underwriting success status flag, the document data can be added into the first task table to generate a corresponding electronic insurance policy.
Step S140, add the document data to the first task table.
Specifically, after the document data of which the status is marked as the underwriting success status is added to the first task table, the first task table can establish a task according to the document data for generating a corresponding electronic insurance policy.
And step S150, calling the electronic insurance policy generation thread to respectively execute the tasks in the first task table and generate the corresponding electronic insurance policy.
In particular, a thread, also referred to as a Lightweight Process (LWP), is the smallest unit of a program execution flow. A thread is an entity in a process and is a basic unit that is independently scheduled and dispatched by the system, and the thread can share all resources owned by the process with other threads belonging to the same process. A plurality of electronic insurance policy generation threads can be pre-established in a background program of the underwriting system and used for executing tasks in the first task table and generating corresponding electronic insurance policies. When the first task table has the electronic insurance policy generation task, the electronic insurance policy generation thread can be called to asynchronously and concurrently execute the task in the first task table, the document data in the first task table is extracted to be processed, and the corresponding electronic insurance policy is generated, so that the generation efficiency of the electronic insurance policy can be improved.
As shown in fig. 2, in an embodiment, the step S150 of invoking the electronic policy generation thread to respectively execute the tasks in the first task table and generate the corresponding electronic policy, may specifically include the following steps:
step S202, determining whether there is an idle electronic policy generation thread currently, if yes, performing step S204, and if no, performing step S206.
Specifically, when a background program of the underwriting system calls the electronic insurance policy to respectively execute tasks in the first task table, if the tasks in the first task table are not executed, whether an idle electronic insurance policy generation thread exists at present can be judged, if the tasks exist, the idle electronic insurance policy generation thread is called to execute the tasks in the first task table, document data in the first task table is extracted to be processed, and a corresponding electronic insurance policy is generated.
And step S204, calling an idle electronic insurance policy generation thread to execute the task in the first task table and generate a corresponding electronic insurance policy.
Specifically, for example, there are 4 electronic policy generation threads currently, where the electronic policy generation thread 1 and the electronic policy generation thread 2 execute the task 1 and the task 2 in the first task table, new policy data is added to the first task table at this time, and if the task 3 is established in the first task table, it is determined that there are idle electronic policy generation threads 3 and electronic policy generation threads 4 currently, that is, the electronic policy generation thread 3 or the electronic policy generation thread 4 is called to execute the task 3. The electronic policy generation thread processes the tasks in the first task table one by one to generate the electronic policy, and when an error occurs in one electronic policy generation, the generation of other electronic policies in the first task table is not influenced, so that the error rate of electronic policy generation can be effectively reduced.
Step S206, determining whether the number of the current electronic policy generation threads is smaller than a preset threshold, if so, performing step S208, and if not, performing step S210.
Specifically, if there is no idle electronic policy generation thread currently, it is determined whether the number of current electronic policy generation threads is smaller than a preset threshold, where the preset threshold refers to the maximum number of electronic policy generation threads to be established, and the preset threshold may be set according to actual requirements, such as the number of electronic policy generation threads, system resource allocation, and the like. The maximum number of the electronic policy generation threads is reasonably set, so that the electronic policy can be generated by asynchronous concurrent processing, the generation efficiency of the electronic policy is improved, system resources can be reasonably distributed, and the resource waste is reduced.
And step S208, creating a new electronic insurance policy generation thread to execute the tasks in the first task table and generate the corresponding electronic insurance policy.
Specifically, if the number of the current electronic policy generation threads is smaller than a preset threshold, a new electronic policy generation thread may be created, the new electronic policy generation thread is called to execute the task in the first task table, and document data in the first task table is extracted to be processed to generate the corresponding electronic policy. For example, if the number of current electronic policy generation threads is 4 and the preset threshold is 5, and the electronic policy generation threads 1 to 4 execute tasks 1 to 4 in the first task table respectively, and the first task table newly establishes task 5, a new electronic policy generation thread 5 can be created for executing task 5. If the task 6 is newly established in the first task table at this time, and no idle electronic policy generation thread exists currently, the task 6 can enter a waiting queue to wait for the execution of the idle electronic policy generation thread.
And step S210, waiting for an idle electronic insurance policy generation thread.
Specifically, if there are no idle electronic policy generation threads currently and the number of the current electronic policy generation threads is equal to the preset threshold, the unexecuted tasks in the first task table may be entered into the waiting queue to wait for the idle electronic policy generation threads to execute.
According to the document data processing method, the first task table is established, document data with the status marked as successful underwriting is added into the first task table, the electronic policy generation thread is called to respectively execute tasks in the first task table to generate the electronic policies, each electronic policy is generated through processing one by one, when one electronic policy generates errors, generation of other electronic policies in the first task table is not affected, error rate of electronic policy generation is effectively reduced, the electronic policies are generated asynchronously through the electronic policy generation thread, and generation efficiency of the electronic policies can be improved.
As shown in fig. 3, in another embodiment, the document data processing method further includes the following steps:
step S302, a second task table is established.
Specifically, when the document is subjected to insurance underwriting, insurance underwriting may fail due to errors of the network and the system. And a second task table can be established in a background program of the underwriting system and used for storing the document data which fails to underwrite, establishing a corresponding underwriting task and conducting underwriting again on the document data which fails to underwrit.
And step S304, if the status mark of the document data is the underwriting failure status mark, adding the document data into a second task table.
Specifically, the status flag in the acquired document data may be extracted, and when the status flag of the document data is a underwriting failure status flag, the document data is added to the second task table, and a corresponding underwriting task is established and underwriting is performed again.
And step S306, calling the underwriting thread to execute the task in the second task table, carrying out underwriting again, and generating corresponding policy data.
Specifically, a background program of the underwriting system may create a plurality of underwriting threads in advance, the underwriting threads are used for asynchronously and concurrently executing tasks in the second task table, document data in the second task table is extracted for underwriting again, corresponding policy data can be generated after underwriting is successful, the policy data is basically consistent with the content of the document data, the policy data may include information such as a policy number, a customer number, a risk seed number, a date and a channel number, and the channel number refers to a number corresponding to a channel in which the document is entered, for example, the channel number of a mobile phone android APP (Application, Application program) is 001, the channel number of an IOS APP is 002, the channel number of a computer client is 003, and the like. Different client versions are different and can also correspond to different channel numbers, for example, the channel number of the computer client version 1.0 is 0031, and the channel number of the computer client version 2.0 is 0032.
And step S308, calling a preset underwriting interface to return a re-underwriting result and corresponding insurance policy data.
Specifically, after the document is successfully re-underwrited, the background program of the underwriting system may call a preset underwriting interface, and call an external associated system through the underwriting interface to return a re-underwriting result and corresponding policy data, where the external associated system may refer to a front end of the underwriting system or a client end for entering application information, and the like, and may find the corresponding external associated system according to a channel number in the policy data, and return the re-underwriting result and the corresponding policy data.
According to the document data processing method, document data with the status marked as underwriting failure is added into the second task table, the underwriting thread is called to asynchronously execute the tasks in the second task table, underwriting is carried out again, the underwriting failure document can be subjected to supplementary underwriting, the situation that data needs to be input again for underwriting after underwriting failure is avoided, operation is simplified, and underwriting efficiency is improved.
In one embodiment, after invoking the underwriting thread to execute the task in the second task table, re-underwriting, and generating the corresponding policy data in step S306, the method further includes:
(1) policy data is added to the first task table.
Specifically, the underwriting thread is called to execute the tasks in the second task table, original document data which fails in underwriting are extracted to conduct underwriting again, and after underwriting is successful, corresponding insurance policy data can be generated. The generated policy data may be added to the first task table and a corresponding electronic policy generated.
(2) And calling an electronic policy generation thread to extract policy data from the first task table for processing and generate a corresponding electronic policy.
Specifically, a plurality of pre-established electronic insurance policy generation threads can be called to asynchronously and concurrently execute tasks in the first task table, the insurance policy data successfully generated by the documents and the underwriting again are extracted from the first task table to be processed, and corresponding electronic insurance policies are generated.
According to the document data processing method, the insurance policy data generated by successfully re-underwriting the document is added into the first task table, the insurance policy which fails to underwrit can be supplemented and the corresponding electronic insurance policy is generated, the condition that the data needs to be re-entered for underwriting after the insurance policy fails is avoided, the operation is simplified, and the efficiency of underwriting and generating the electronic insurance policy is improved.
As shown in fig. 4, a document data processing apparatus includes a creating module 410, an extracting module 420, a determining module 430, an adding module 440, and a generating module 450.
An establishing module 410 is configured to establish a first task table.
Specifically, the underwriting system may pre-establish a first task table in a background program, where the first task table may be used to store document data for generating the electronic insurance policy, and establish a task according to each piece of document data for generating a corresponding electronic insurance policy.
And the extracting module 420 is configured to acquire the document data and extract the status flag in the document data.
Specifically, the salesman can record the insurance application information related to the insurance applicant at the front end of the underwriting system, and the insurance application information can enter the underwriting stage after being verified by the insurance application rule and generate corresponding document data. The document data may include information such as a document number, a customer number, a date, a risk number, a status flag, and the like, where the status flag in the document data is used to indicate a current processing status of the document, and the status flag may include, but is not limited to, status flags of underwriting, underwriting failure, underwriting success, unprocessed, and the like. And only after the document insurance acceptance is successful, the background program of the underwriting system can generate the corresponding electronic insurance policy and return the corresponding insurance policy data to the foreground program. The background program of the underwriting system can acquire each piece of document data and extract the state marks in the document data. In other embodiments, the document data in different states may also be stored in different data tables, for example, the document data that is successfully underwritten is stored in the underwriting success table, the unprocessed document data is stored in the unprocessed table, and when the document data in a certain state needs to be acquired, the document data in the corresponding data table may be directly read.
The determining module 430 is configured to determine whether the status flag is an underwriting success status flag.
Specifically, after the status flag of the document data is extracted, whether the status flag is the underwriting success status flag or not is further judged, and if the status flag is the underwriting success status flag, the document data can be added into the first task table to generate a corresponding electronic insurance policy.
An adding module 440, configured to add the certification data to the first task table if the status flag is the underwriting success status flag.
Specifically, after the document data of which the status is marked as the underwriting success status is added to the first task table, the first task table can establish a task according to the document data for generating a corresponding electronic insurance policy.
The generating module 450 is configured to invoke the electronic policy generating thread to respectively execute the tasks in the first task table, and generate the corresponding electronic policy.
In particular, a thread, also referred to as a lightweight process, is the smallest unit of program execution flow. A thread is an entity in a process and is a basic unit that is independently scheduled and dispatched by the system, and the thread can share all resources owned by the process with other threads belonging to the same process. A plurality of electronic insurance policy generation threads can be pre-established in a background program of the underwriting system and used for executing tasks in the first task table and generating corresponding electronic insurance policies. When the first task table has the electronic insurance policy generation task, the electronic insurance policy generation thread can be called to asynchronously and concurrently execute the task in the first task table, the document data in the first task table is extracted to be processed, and the corresponding electronic insurance policy is generated, so that the generation efficiency of the electronic insurance policy can be improved.
As shown in fig. 5, the generating module 450 includes a determining unit 452, a calling unit 454, and a creating unit 456.
The determining unit 452 is configured to determine whether there is an idle electronic policy generation thread currently.
Specifically, when a background program of the underwriting system calls the electronic insurance policy to respectively execute tasks in the first task table, if the tasks in the first task table are not executed, whether an idle electronic insurance policy generation thread exists at present can be judged, if the tasks exist, the idle electronic insurance policy generation thread is called to execute the tasks in the first task table, document data in the first task table is extracted to be processed, and a corresponding electronic insurance policy is generated.
The invoking unit 454 is configured to invoke the idle electronic policy generation thread to execute the task in the first task table and generate the corresponding electronic policy if there is the idle electronic policy generation thread currently.
Specifically, for example, there are 4 electronic policy generation threads currently, where the electronic policy generation thread 1 and the electronic policy generation thread 2 execute the task 1 and the task 2 in the first task table, new policy data is added to the first task table at this time, and if the task 3 is established in the first task table, it is determined that there are idle electronic policy generation threads 3 and electronic policy generation threads 4 currently, that is, the electronic policy generation thread 3 or the electronic policy generation thread 4 is called to execute the task 3. The electronic policy generation thread processes the tasks in the first task table one by one to generate the electronic policy, and when an error occurs in one electronic policy generation, the generation of other electronic policies in the first task table is not influenced, so that the error rate of electronic policy generation can be effectively reduced.
The determining unit 452 is further configured to determine whether the number of current electronic policy generation threads is smaller than a preset threshold value if there is no idle electronic policy generation thread currently.
Specifically, if there is no idle electronic policy generation thread currently, it is determined whether the number of current electronic policy generation threads is smaller than a preset threshold, where the preset threshold refers to the maximum number of electronic policy generation threads to be established, and the preset threshold may be set according to actual requirements, such as the number of electronic policy generation threads, system resource allocation, and the like. The maximum number of the electronic policy generation threads is reasonably set, so that the electronic policy can be generated by asynchronous concurrent processing, the generation efficiency of the electronic policy is improved, system resources can be reasonably distributed, and the resource waste is reduced.
A creating unit 456, configured to create a new electronic policy generation thread to execute the task in the first task table and generate a corresponding electronic policy if the number of the current electronic policy generation threads is smaller than a preset threshold.
Specifically, if the number of the current electronic policy generation threads is smaller than a preset threshold, a new electronic policy generation thread may be created, the new electronic policy generation thread is called to execute the task in the first task table, and document data in the first task table is extracted to be processed to generate the corresponding electronic policy. For example, if the number of current electronic policy generation threads is 4 and the preset threshold is 5, and the electronic policy generation threads 1 to 4 execute tasks 1 to 4 in the first task table respectively, and the first task table newly establishes task 5, a new electronic policy generation thread 5 can be created for executing task 5. If the task 6 is newly established in the first task table at this time, and no idle electronic policy generation thread exists currently, the task 6 can enter a waiting queue to wait for the execution of the idle electronic policy generation thread.
If no idle electronic insurance policy generation thread exists currently and the number of the current electronic insurance policy generation threads is equal to a preset threshold value, the tasks which are not executed in the first task table can enter a waiting queue to wait for the idle electronic insurance policy generation thread to execute.
According to the document data processing device, the first task table is established, document data with the status marked as successful underwriting is added into the first task table, the electronic policy generation thread is called to respectively execute tasks in the first task table to generate the electronic policies, each electronic policy is generated through processing one by one, when one electronic policy generates errors, generation of other electronic policies in the first task table is not affected, error rate of electronic policy generation is effectively reduced, the electronic policies are generated asynchronously through the electronic policy generation thread, and generation efficiency of the electronic policies can be improved.
As shown in fig. 6, in another embodiment, the document data processing apparatus further includes an underwriting module 460 besides the creating module 410, the extracting module 420, the determining module 430, the adding module 440 and the generating module 450.
The building module 410 is also used for building a second task table.
Specifically, when the document is subjected to insurance underwriting, insurance underwriting may fail due to errors of the network and the system. And a second task table can be established in a background program of the underwriting system and used for storing the document data which fails to underwrite, establishing a corresponding underwriting task and conducting underwriting again on the document data which fails to underwrit.
The adding module 440 is further configured to add the document data to the second task table if the status flag of the document data is the underwriting failure status flag.
Specifically, the status flag in the acquired document data may be extracted, and when the status flag of the document data is a underwriting failure status flag, the document data is added to the second task table, and a corresponding underwriting task is established and underwriting is performed again.
And the underwriting module 460 is used for calling the underwriting thread to execute the tasks in the second task table, carrying out underwriting again and generating corresponding insurance policy data.
Specifically, a background program of the underwriting system can create a plurality of underwriting threads in advance, the underwriting threads are used for asynchronously and concurrently executing tasks in the second task table, document data in the second task table is extracted for underwriting again, corresponding policy data can be generated after underwriting is successful, the policy data is basically consistent with the content of the document data, the policy data can comprise information such as a policy number, a customer number, a risk seed number, a date and a channel number, wherein the channel number refers to a number corresponding to a channel recorded by the document, for example, the channel number of an android APP of a mobile phone is 001, the channel number of an IOS APP of an IOS version is 002, the channel number of a computer client is 003 and the like. Different client versions are different and can also correspond to different channel numbers, for example, the channel number of the computer client version 1.0 is 0031, and the channel number of the computer client version 2.0 is 0032.
According to the document data processing device, document data with the status marked as underwriting failure is added into the second task table, the underwriting thread is called to asynchronously execute the tasks in the second task table, underwriting is carried out again, the underwriting failure document can be subjected to supplementary underwriting, the situation that the underwriting failure needs to be recorded again for underwriting is avoided, operation is simplified, and underwriting efficiency is improved.
As shown in fig. 7, in one embodiment, the document data processing apparatus further includes a returning module 470 in addition to the creating module 410, the extracting module 420, the judging module 430, the adding module 440, the generating module 450, and the underwriting module 460.
And a returning module 470, configured to call a preset underwriting interface to return a re-underwriting result and corresponding policy data.
Specifically, after the document is successfully re-underwrited, the background program of the underwriting system may call a preset underwriting interface, and call an external associated system through the underwriting interface to return a re-underwriting result and corresponding policy data, where the external associated system may refer to a front end of the underwriting system or a client end for entering application information, and the like, and may find the corresponding external associated system according to a channel number in the policy data, and return the re-underwriting result and the corresponding policy data.
In one embodiment, the adding module 440 is further configured to add policy data to the first task table.
Specifically, the underwriting thread is called to execute the tasks in the second task table, original document data which fails in underwriting are extracted to conduct underwriting again, and after underwriting is successful, corresponding insurance policy data can be generated. The generated policy data may be added to the first task table and a corresponding electronic policy generated.
The generating module 450 is further configured to invoke an electronic policy generating thread to extract policy data from the first task table for processing, and generate a corresponding electronic policy.
Specifically, a plurality of pre-established electronic insurance policy generation threads can be called to asynchronously and concurrently execute tasks in the first task table, the insurance policy data successfully generated by the documents and the underwriting again are extracted from the first task table to be processed, and corresponding electronic insurance policies are generated.
According to the document data processing device, the insurance policy data generated by successfully re-underwriting the document is added into the first task table, the documents failed in underwriting can be supplemented and underwrited, a corresponding electronic insurance policy is generated, data needs to be re-entered for underwriting after the underwriting failure is removed, operation is simplified, and the efficiency of underwriting and generating the electronic insurance policy is improved.
The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims (4)

1. A document data processing method is characterized by comprising the following steps:
establishing a first task table;
acquiring document data and extracting a state mark in the document data;
judging whether the state mark is an underwriting success state mark or not;
if the status mark is an underwriting success status mark, adding the document data into the first task table;
calling an electronic insurance policy generation thread to respectively execute the tasks in the first task table and generate a corresponding electronic insurance policy;
the method further comprises the steps of:
establishing a second task table;
if the status mark of the document data is a underwriting failure status mark, adding the document data into the second task table;
calling an underwriting thread to execute the tasks in the second task table, carrying out underwriting again, and generating corresponding policy data;
calling a preset underwriting interface to return a re-underwriting result and corresponding policy data;
the invoking of the electronic policy generation thread executes the tasks in the first task table respectively and generates the corresponding electronic policy, which specifically includes:
judging whether an idle electronic policy generating thread exists at present;
if yes, calling the idle electronic insurance policy generation thread to execute the task in the first task table and generate a corresponding electronic insurance policy;
if not, judging whether the number of the current electronic insurance policy generation threads is smaller than a preset threshold value, if so, creating a new electronic insurance policy generation thread to execute the tasks in the first task table, and generating the corresponding electronic insurance policy.
2. The document data processing method according to claim 1, wherein after the step of invoking the underwriting thread to execute the task in the second task table, re-underwriting, and generating corresponding policy data, further comprising:
adding the policy data to the first task table;
and calling the electronic policy generation thread to extract the policy data from the first task table for processing and generating a corresponding electronic policy.
3. A document data processing apparatus, comprising:
the establishing module is used for establishing a first task table;
the extraction module is used for acquiring the document data and extracting the state mark in the document data;
the judging module is used for judging whether the state mark is an underwriting success state mark or not;
the adding module is used for adding the document data into the first task table if the status mark is an underwriting success status mark;
the generating module is used for calling an electronic insurance policy generating thread to respectively execute the tasks in the first task table and generate a corresponding electronic insurance policy;
the establishing module is also used for establishing a second task table;
the adding module is further used for adding the document data into the second task table if the status mark of the document data is an underwriting failure status mark;
the device also comprises an underwriting module which is used for calling an underwriting thread to execute the tasks in the second task table, conducting underwriting again and generating corresponding insurance policy data;
the return module is used for calling a preset underwriting interface to return a re-underwriting result and corresponding policy data;
the generation module comprises:
the judging unit is used for judging whether an idle electronic insurance policy generation thread exists at present;
the calling unit is used for calling the idle electronic insurance policy generation thread to execute the task in the first task table and generate a corresponding electronic insurance policy if the idle electronic insurance policy generation thread exists currently;
the judging unit is also used for judging whether the number of the current electronic insurance policy generating threads is less than a preset threshold value or not if no idle electronic insurance policy generating threads exist currently;
and the creating unit is used for creating a new electronic insurance policy generating thread to execute the tasks in the first task table and generate the corresponding electronic insurance policy if the number of the current electronic insurance policy generating threads is less than the preset threshold value.
4. The document data processing apparatus of claim 3, wherein the adding module is further configured to add the policy data to the first task table;
the generating module is further used for calling the electronic policy generating thread to extract the policy data from the first task table for processing and generating a corresponding electronic policy.
CN201610182478.XA 2016-03-28 2016-03-28 Document data processing method and device Active CN107239325B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610182478.XA CN107239325B (en) 2016-03-28 2016-03-28 Document data processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610182478.XA CN107239325B (en) 2016-03-28 2016-03-28 Document data processing method and device

Publications (2)

Publication Number Publication Date
CN107239325A CN107239325A (en) 2017-10-10
CN107239325B true CN107239325B (en) 2020-05-22

Family

ID=59983160

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610182478.XA Active CN107239325B (en) 2016-03-28 2016-03-28 Document data processing method and device

Country Status (1)

Country Link
CN (1) CN107239325B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107679060B (en) * 2017-07-25 2019-02-05 平安科技(深圳)有限公司 Method for inquiring status, device, user terminal and the storage medium of electronic insurance policy
CN107918864B (en) * 2017-11-23 2021-06-04 平安科技(深圳)有限公司 Electronic insurance policy generation method and device, computer equipment and storage medium
CN108037996A (en) * 2017-11-27 2018-05-15 平安养老保险股份有限公司 Declaration form processing method, device, computer equipment and storage medium
CN110838071B (en) * 2019-11-05 2023-05-16 泰康保险集团股份有限公司 Policy data processing method, device and server
CN111176588B (en) * 2019-12-11 2023-09-29 中国平安财产保险股份有限公司 Service bill issuing method, device, medium and electronic equipment

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050119920A1 (en) * 2003-08-13 2005-06-02 Murphy Patrick J. Method and apparatus for automated insurance processing
US8694788B1 (en) * 2005-04-29 2014-04-08 Progressive Casualty Insurance Company Security system
CN102902494B (en) * 2012-08-16 2015-06-24 杜瑞江 Control method for valuable document printing of banks or insurances
CN105005504B (en) * 2015-07-30 2019-01-29 深圳创维-Rgb电子有限公司 A kind of the single task mode implementation method and system of Android platform

Also Published As

Publication number Publication date
CN107239325A (en) 2017-10-10

Similar Documents

Publication Publication Date Title
CN107239325B (en) Document data processing method and device
CN109257411B (en) Service processing method, call management system and computer equipment
CN111245900B (en) Distributed message sending processing system and processing method thereof
CN112445596B (en) Data importing method, system and storage medium based on multithreading
CN108491304B (en) electronic device, business system risk control method and storage medium
WO2019061998A1 (en) Intelligent breakpoint distribution method, electronic device, and computer readable storage medium
US20160284013A1 (en) Order processing system and order processing method
CN112114903A (en) File loading method and device
JP6351827B2 (en) Virus scanning method and virus scanning apparatus
CN108595178B (en) Hook-based data acquisition method, device and equipment
WO2019062020A1 (en) Asynchronous task unified processing method and apparatus, and storage medium
CN111737055A (en) Service processing method, device, equipment and computer readable storage medium
CN115509714A (en) Task processing method and device, electronic equipment and storage medium
CN107608827B (en) Backup method and terminal for package configuration file and related medium product
CN111488236A (en) Order abnormity processing method, server, storage medium and processing device
CN112799791A (en) Method and device for calling distributed lock, electronic equipment and storage medium
CN104572036B (en) Event processing method and device
CN112083952A (en) Spring architecture-based exception handling method and system
CN113297149A (en) Method and device for monitoring data processing request
JPWO2017094096A1 (en) Transaction processing system and transaction control method
CN111737129A (en) Service control method, service control device, computer readable medium and electronic equipment
CN115103076B (en) Outbound method, outbound device, computer equipment and storage medium
CN112463076A (en) Data export method, computer equipment and storage medium
US20240184643A1 (en) Proactive monitoring of file status updates in transaction systems
CN115437769A (en) Data processing method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant