A business data processing method, apparatus and computer-readable medium

Abstract

This application discloses a business data processing method, apparatus, and computer-readable medium. The method includes: determining data status information corresponding to each type of business data involved in settlement business; determining, based at least on the determined data status information, whether each type of business data needs to participate in each sub-business included in the current round of settlement processing; if there is business data that needs to participate in the current round of settlement processing, determining the target sub-business that needs to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business; obtaining the target business data that needs to participate in the target sub-business, and processing the target business data according to the processing logic of the target sub-business. This application can avoid unnecessary data from repeatedly participating in the business processing of settlement business. By controlling when each type of business data should participate in business processing and when it does not need to participate, the accuracy of the final data is guaranteed, while improving system computing efficiency and reducing system performance consumption.

Description

Technical Field

[0001] This application belongs to the field of aviation information processing technology, and in particular relates to a business data processing method, apparatus and computer-readable medium. Background Technology

[0002] Airline revenue settlement is a crucial core business for airlines in determining their revenue. The corresponding settlement system is located in the mid-to-downstream of the entire business and data chain, responsible for processing data from upstream systems and various parties involved in the settlement process. Based on this data, the settlement system performs complex calculations to ultimately obtain the airline's revenue data to be settled.

[0003] In this process, due to the numerous data sources involved in the calculations, and the fact that data quality and status change constantly as business operations progress, these numerous changes trigger massive data trials and calculations in the settlement system. This results in a large workload, low efficiency, and high complexity for the settlement system. Because of their complexity, these calculation functions are designed as offline background operations within the settlement system, and these operations still consume significant system resources. Summary of the Invention

[0004] In view of this, this application provides a business data processing method, apparatus and computer-readable medium to solve at least some of the technical problems existing in the prior art, improve system computing efficiency and save system resources.

[0005] The specific plan is as follows:

[0006] A business data processing method, comprising:

[0007] Determine the data status information corresponding to each type of business data involved in the settlement business;

[0008] Based at least on the data status information corresponding to each type of business data, determine whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing;

[0009] If there is business data that needs to participate in the current round of settlement processing, the target sub-business that needs to be triggered is determined according to the triggering conditions corresponding to each sub-business included in the settlement business;

[0010] Obtain the target business data that needs to participate in the target sub-business, and process the target business data according to the processing logic of the target sub-business.

[0011] Optionally, the data status information corresponding to each type of business data involved in the settlement business includes:

[0012] Obtain the data structure objects for ticket status management corresponding to each type of business data;

[0013] Read the data status information of the corresponding type of business data from the corresponding data structure object;

[0014] The data structure object used for ticket status management contains data status information that represents the processing status and status change trajectory of the corresponding type of business data.

[0015] Optionally, before determining the data status information corresponding to each type of business data involved in the settlement business, the method further includes:

[0016] Based on the created ticket status management processing interface, status change information of various types of business data is collected;

[0017] Based on the collected status change information, the data status information of that type of business data is recorded or updated in the data structure object used for ticket status management corresponding to the relevant type of business data.

[0018] Optionally, determining whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing, based at least on the data status information corresponding to each type of business data, includes:

[0019] Based on the corresponding data status information, determine whether the status of each type of business data has changed within the current time period;

[0020] Based on whether each type of business data has undergone a state change within the current time period, whether each type of business data has participated in the corresponding sub-businesses included in the settlement business, and whether the sub-businesses participated in have been successfully processed, it is determined whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing.

[0021] Optionally, determining the target sub-business to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business includes:

[0022] According to the preset sub-business processing order, determine the next sub-business to be processed in each sub-business included in the settlement business;

[0023] Determine whether the triggering condition corresponding to the next sub-service is met. If it is met, determine that the next sub-service is the target sub-service that needs to be triggered.

[0024] The triggering conditions for each sub-business are conditions related to the data status information of the corresponding business data.

[0025] Optionally, the above method also includes:

[0026] Determine whether the business protocols of at least some of the sub-businesses included in the settlement business have undergone protocol data changes;

[0027] If a change occurs, the corresponding type of business data should be synchronized according to the protocol data change information of the corresponding sub-business, and the data structure object for ticket status management corresponding to the corresponding type of business data should be updated based on the synchronized changes that should occur.

[0028] Optionally, determining the synchronization changes that should occur in the corresponding type of business data based on the protocol data change information of the corresponding sub-service includes:

[0029] Based on the protocol data change information of the corresponding sub-business, determine the first data in the business data within the scope of the original protocol that does not match the modified protocol, and the second data that needs to be added in the modified protocol compared to the original protocol.

[0030] Optionally, the various types of business data include at least some of the following types of data: transportation data, sales data, inbound cash-on-delivery data, and internal billing data;

[0031] The settlement business includes at least some of the sub-businesses such as freight rate calculation, transportation allocation, transportation revenue calculation, and ticket monitoring.

[0032] A business data processing apparatus, comprising:

[0033] The first determining unit is used to determine the data status information corresponding to each type of business data involved in the settlement business;

[0034] The second determining unit is used to determine, at least based on the data status information corresponding to each type of business data, whether each type of business data needs to participate in each sub-business included in the settlement business in the current round of settlement processing;

[0035] The third determining unit is used to determine the target sub-business to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business if there is business data that needs to participate in the current round of settlement processing.

[0036] The business processing unit is used to acquire target business data that needs to participate in the target sub-business, and process the target business data according to the processing logic of the target sub-business.

[0037] A computer-readable medium having a computer program stored thereon, the computer program comprising program code for performing the methods described in any of the preceding descriptions.

[0038] In summary, this application provides a business data processing method, apparatus, and computer-readable medium. The method includes: determining data status information corresponding to each type of business data involved in a settlement business; determining, at least based on the data status information corresponding to each type of business data, whether each type of business data needs to participate in each sub-business included in the current round of settlement processing; if there is business data that needs to participate in the current round of settlement processing, determining the target sub-business that needs to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business; obtaining the target business data that needs to participate in the target sub-business, and processing the target business data according to the processing logic of the target sub-business.

[0039] This application, through the above processing, avoids unnecessary data duplication in the settlement business process. Only data that needs to participate in the corresponding sub-business, such as data whose status has changed, will trigger the corresponding sub-business process again. By controlling when different types of business data should participate in the business process and when they do not, the accuracy of the final data is guaranteed, while improving system computing efficiency and reducing system computational load and performance / resource consumption. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0041] Figure 1 This is a flowchart illustrating the business data processing method provided in this application;

[0042] Figure 2 This is a schematic diagram illustrating the application of the ticket status management provided in this application in business processing;

[0043] Figure 3 This is a diagram illustrating the modification methods for various types of business data provided in this application;

[0044] Figure 4 This is a structural diagram of the business data processing device provided in this application. Detailed Implementation

[0045] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0046] The applicant discovered that the mail revenue management platform requires that each data processing unit must meet the requirements of completeness, validity, and accuracy before processing that unit can cease. However, these data processing units occur at different times in actual business operations, enter the system for processing at different times, and may require multiple processing iterations to achieve the final accuracy target. Under these circumstances, the same, unchanged data processing units are repeatedly calculated and processed within the system, and the results of these repeated processing remain unchanged. This repeated processing degrades system performance, wastes system resources, and results in high computational workload, low efficiency, and high complexity.

[0047] Users of the settlement system are typically the finance or settlement departments of airlines. Due to the monetary value involved, the system demands high data accuracy. Simultaneously, with the development of settlement business, the amount of data processed is rapidly increasing, making the timeliness of data processing a greater concern. The settlement system includes numerous computational functions, among which crucial functions include fare calculation, allocation processing, and ticket monitoring. These functions are essentially the core business processes of airline settlement operations. Due to their complex logic and large computational load, these core functions are currently processed offline. Data sources involved in the calculations include: settlement data processing units, various agreements (fare agreements, allocation agreements, sales agreements, etc.), and basic information (flight information, geographic information, etc.). Furthermore, there are many control points in the business process that can cause changes to the data involved in the data processing units, such as: data modification, data adjustment, data review, and agreement modification and cancellation. Additionally, the order in which data processing units occur within the business also affects the final result.

[0048] The high demands that settlement operations place on system processing, coupled with the variability of data processing units and other auxiliary data, necessitate a complete mechanism to control the core processing functions of the settlement system.

[0049] To address the aforementioned issues, this application provides a business data processing method, apparatus, and computer-readable medium to avoid the same data processing units repeatedly participating in calculations and processing, reduce the impact of data changes in data units on all data in the entire data chain, and reduce the consumption of system resources by repeated calculations, thereby improving system processing efficiency, reducing system computation, and saving system resources.

[0050] The business data processing method provided in this application is specifically a business data processing method based on ticket status management, and will be mainly illustrated using the business data processing based on ticket status management for airline settlement as an example.

[0051] For the sake of reference or clarity, the technical terms, nouns, or English abbreviations used in the embodiments of this application are explained as follows:

[0052] CMRM: It is the abbreviation for Cargo and Mail Revenue Management system, which can be regarded as a settlement system.

[0053] Airway Bill: One of the basic documents for cargo and mail transportation, it is a document for transportation and sale agreed upon by the airline, agent and shipper.

[0054] Manifest: One of the basic documents for airline transportation, which records the contents of the airline's transport manifest.

[0055] Transit manifest: The basis for document transfer between various airlines in the event of connecting flights.

[0056] Ground transport manifest: A document for ground transport other than air transport, currently mainly referring to truck transport.

[0057] Data Processing Unit: The basic data unit processed by the cargo and mail revenue management platform, which can be divided into the following categories according to business type: transportation data, sales data, inbound freight collect data, and internal billing data. The corresponding basic business documents include: transport manifest, transport manifest, transport transshipment manifest, ground transport manifest, sales manifest, inbound freight collect data documents, and internal billing data documents.

[0058] Computational Logic Unit: Key computational logic functions in the freight and mail revenue management platform, including: freight rate calculation engine, transportation allocation engine, transportation revenue calculation engine, and ticket monitoring engine.

[0059] See Figure 1 The business data processing method shown in this application includes the following processing steps:

[0060] Step 101: Determine the data status information corresponding to each type of business data involved in the settlement business.

[0061] Taking airline settlement business as an example, various types of business data can refer to the various data processing units that the cargo and mail revenue management platform needs to process, namely various basic data units, such as transportation data, sales data, inbound cash-on-delivery data, and internal billing data.

[0062] This application's embodiments utilize various types of business data, such as the aforementioned basic data units, and design multi-dimensional data structure objects to record relevant attribute information for each type of business data. This includes, but is not limited to, the business unit to which the data belongs, the data modification method, the control logic between computational logic units, and the priority of data processing logic, etc., for use in ticket status management. A schematic diagram illustrating the application of ticket status management in business processing is shown below. Figure 2 As shown.

[0063] Data structure objects can be persisted in various ways, including but not limited to memory objects, caches, and databases.

[0064] In practical applications, object-oriented technology can be used to first create multi-dimensional data structure objects for ticket status management for various types of business data. Then, when a settlement system, such as an airline's settlement system, starts, the data structure objects for ticket status management should be loaded into the server's memory or cache mechanism first.

[0065] Correspondingly, this application embodiment also creates a ticket status management processing interface based on various types of business data, such as various data modification methods in various data processing units, for each data processing unit to call and process. Based on this, the time and status of the data processing unit are recorded in the corresponding data structure object. With the time and status of the data processing unit, in ticket status management, it can be determined whether the corresponding data processing unit should participate in or re-participate in the calculation and processing when the calculation logic unit triggers the calculation.

[0066] It is worth noting that, in this embodiment of the application, for the sake of simplification, the term "data processing unit" is used in some places to refer to the various types of business data such as transportation data, sales data, port arrival payment data, and internal billing data, which are also the basic data units of each type. When it comes to changes to these data, such as additions, deletions, and modifications, the data processing unit can also refer to the functional unit that can be used to record status information to the data structure object by calling the ticket status management processing interface.

[0067] Taking the settlement business of airlines as an example, the embodiments of this application mainly divide the business units to which the various types of business data belong into: transportation module, sales module, internal billing module and inbound cash on delivery module, which correspond to transportation data, sales data, internal billing data and inbound cash on delivery data, respectively.

[0068] In this example, each business module corresponds to multiple data modification methods, which can also be understood as the data modification methods for different types of data processing units, such as... Figure 3 As shown, they are as follows:

[0069] Transportation data:

[0070] Add, modify, or delete shipping manifests;

[0071] Add, modify, or delete transport manifests;

[0072] Add, modify, and delete transit manifests;

[0073] Add, modify, and delete ground transport manifests;

[0074] Transportation ticket verification;

[0075] Transportation freight rate review;

[0076] Transportation tickets are adjusted within the same month and across periods.

[0077] Sales data:

[0078] Add, modify, and delete sales orders;

[0079] Sales order approval;

[0080] Sales order review.

[0081] Internal accounting data:

[0082] Add, modify, and delete internal invoices;

[0083] Review and modification of internal invoices.

[0084] Inbound freight collect data:

[0085] Add, modify, or delete inbound freight collect.

[0086] Freight rate agreement:

[0087] Signing, modifying, and publishing agreement information;

[0088] The freight rate calculation requires modifications to the data processing unit.

[0089] Transportation sharing agreement:

[0090] Signing, modifying, and publishing agreement information;

[0091] Modifying the allocation information causes data changes to the data processing unit.

[0092] It should be noted that the freight rate agreement belongs to the freight rate agreement module, and the transportation cost sharing agreement belongs to the transportation cost sharing agreement module. These two agreements (modules) are the basis for calculation by the data processing units of the "freight rate calculation engine" and the "transportation cost sharing engine". With the basis (agreement) and the data (transportation, sales, internal billing, and port collection), the result can be calculated and the business settlement can be realized.

[0093] Optionally, in this example, the multidimensional data structure object used for ticket status management is designed with multiple attributes. These attributes record data status information characterizing the processing status and status change trajectory of the corresponding type of business data. The included attributes may include, but are not limited to, some or all of the following attributes:

[0094] a1) Unique identifier for the data processing unit;

[0095] Each piece of sales data, transportation data, internal billing data, and port arrival payment data is considered a data processing unit and corresponds to a unique identifier, which can be the data's ID or sequence number.

[0096] a2) Sales data processing status;

[0097] Such as adding, modifying, or deleting sales orders, sales order approval, and sales order review.

[0098] a3) Sales data change time;

[0099] a4) Transportation data processing status;

[0100] Examples include "adding, modifying, and deleting" transport manifests, transport orders, transshipment manifests, and ground transport manifests; "ticket monitoring," "freight rate review," and "monthly and inter-period adjustments."

[0101] a5) Time of change of transportation data;

[0102] a6) Internal accounting data processing status;

[0103] a7) Internal accounting data change time;

[0104] a8) Inbound freight collect processing status;

[0105] a9) Time of change of data for inbound payment upon arrival;

[0106] a10) Freight rate calculation and processing status;

[0107] a11) Freight rate calculation and processing time;

[0108] a12) Transportation allocation processing status;

[0109] a13) Transportation allocation processing time;

[0110] a14) Input accounting data processing status;

[0111] a15) Input accounting processing time;

[0112] a16) Ticket monitoring data processing status;

[0113] a17) Ticket monitoring and processing time.

[0114] In addition to designing the data structure for the multidimensional data structure object used to store the ticket status, it is also necessary to provide each data processing unit with interface method logic for recording the data processing status and processing time, that is, the interface method logic of the ticket status management and processing interface, so as to collect data change information and provide data basis for the calculation logic unit to determine the range of data to be calculated.

[0115] In this example, these interfaces include, but are not limited to:

[0116] b1) Data interface for obtaining ticket management status;

[0117] b2) Sales data change interface;

[0118] b3) Sales audit data change interface;

[0119] b4) Sales review data change interface;

[0120] b5) Transportation data change interface;

[0121] b6) Transport manifest modification interface;

[0122] b7) Interface for changing transportation fare audit data;

[0123] b8) Interface for changing internal accounting data;

[0124] b9) Interface for changing inbound payment on delivery data;

[0125] b10) Freight rate agreement change interface;

[0126] b11) Change interface for cost-sharing protocol.

[0127] Based on the above processing, in this embodiment of the application, the status change information of various types of business data is collected based on the created ticket status management processing interface, and the data status information of the corresponding type of business data is recorded or updated in the data structure object for ticket status management corresponding to the corresponding type of business data.

[0128] Accordingly, when it is necessary to determine the data status information corresponding to each type of business data involved in the settlement business, the data structure objects for ticket status management corresponding to each type of business data can be obtained, and the data status information of the corresponding type of business data can be read from the corresponding data structure objects.

[0129] Step 102: Based on the data status information corresponding to each type of business data, determine whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing.

[0130] Optionally, based on the data status information obtained from the corresponding data structure object used for ticket status management, it can be determined whether the status of each type of business data has changed within the current time period; then, based on whether the status of each type of business data has changed within the current time period, whether each type of business data has participated in the corresponding sub-businesses included in the settlement business, and whether the sub-businesses participated in have been successfully processed, it can be determined whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing.

[0131] The current round's time period can be understood as the time elapsed between the most recently completed settlement process and the next process to be triggered. The next process can be understood as the current round's calculation process, specifically the settlement process to be executed or triggered in the current round.

[0132] Taking airline settlement operations as an example, ticket status management primarily controls the following computational logic units: fare calculation engine, transportation allocation engine, transportation revenue calculation engine, and ticket monitoring engine. These engines are the core data processing operations for airline settlement operations. In this example, the various sub-businesses included in the settlement operations can respectively provide fare calculation, transportation allocation, transportation revenue calculation, and ticket monitoring sub-businesses to the aforementioned engines.

[0133] Taking airline settlement business as an example, after collecting the processing status and change trajectory information (such as processing status and status change time) of various business data in the system based on the data structure object used for ticket status management, this application embodiment uses this as a basis to determine whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing, such as determining whether each data processing unit (basic data unit) needs to participate in the sub-business processes provided by the fare calculation engine, transportation allocation engine, transportation revenue calculation engine and ticket monitoring engine respectively.

[0134] The following provides an example of decision logic:

[0135] c1) If the relevant data has not undergone any state changes or participated in the calculation process of the relevant sub-business within the current time period, it can participate in the next calculation logic of the sub-business.

[0136] c2) If the relevant data has not undergone any state change within the current time period, but has already participated in the relevant calculation of a certain sub-business and the calculation was successful, then it does not need to participate in the next calculation logic of that sub-business.

[0137] c3) If the relevant data has not changed in state within the current time period, but the relevant calculation of the most recent sub-business failed, then it needs to participate in the next calculation logic of that sub-business.

[0138] c4) If the relevant data has undergone a state change within the current time period, it needs to participate in the next calculation logic of that sub-business, regardless of whether the relevant calculation of the most recent sub-business was successful or failed.

[0139] It should be noted that the next calculation logic of a sub-business refers to the processing of the sub-business in the current round to be triggered.

[0140] Based on the above judgment, it can be determined when each type of business data should participate in the business processing of a certain sub-business and when it does not need to participate.

[0141] Step 103: If there is business data that needs to participate in the current round of settlement processing, determine the target sub-business that needs to be triggered at the current time according to the triggering conditions corresponding to each sub-business included in the settlement business.

[0142] The various sub-businesses in a settlement process typically need to be executed in a certain order. For example, in airline settlement, fare calculation is usually performed first, then allocation is done, then accounting is done, and finally ticket monitoring is performed. Based on this, this step can further determine the next sub-business to be processed in each of the sub-businesses included in the settlement process according to the preset sub-business processing order, and determine whether the triggering conditions corresponding to the next sub-business are met. If they are met, the next sub-business is determined to be the target sub-business to be triggered.

[0143] The triggering conditions for each sub-business are conditions related to the data status information of the corresponding business data.

[0144] For airline settlement operations, the business processing sequence can be followed: first calculate fares, then allocate them, then record them, and finally monitor the tickets. Based on the trigger conditions for calculation processing added to each calculation engine in ticket status management, it can be determined whether to trigger the processing of a certain engine.

[0145] The trigger conditions added to each computing engine in ticket status management are explained below:

[0146] (I) Freight Calculation Engine

[0147] As the primary processing logic function, any data processing unit entering the system can participate in the freight rate calculation engine. For example, when a freight bill enters the system, freight rate calculation can be performed using only the freight bill data. However, the results obtained from freight rate calculations based solely on freight bill data are unstable and inaccurate. If the data from this freight processing unit is to generate stable and accurate data, more data needs to enter the system. Therefore, when other data arrives, the freight data processing status and time of this freight processing unit are updated, and it is ready to participate in a new round of freight rate calculation.

[0148] The freight rate calculation engine is triggered by either: (the data processing unit undergoes a state change within the current time period) or (the previous freight rate calculation failed).

[0149] (II) Transportation Sharing Engine

[0150] The transportation allocation engine is executed after the freight rate calculation. This means that the transportation allocation result is only valid after the correct freight rate calculation engine's result has been determined. However, this does not mean that transportation allocation cannot be triggered before freight rate calculation; the data processing unit can perform transportation allocation engine calculations before the freight rate engine's calculation.

[0151] The trigger conditions for the transportation allocation engine calculation are: (the data processing unit undergoes a state change within the current time cycle) or (the previous transportation allocation calculation failed) or (the preceding function - the freight rate calculation engine succeeded and its execution time is later than the previous transportation allocation time).

[0152] (III) Transportation Revenue Calculation Engine

[0153] The result of transportation revenue calculation is the final and confirmed value of the airline's revenue for each period. This requires that the data it processes be accurate and correct, and that the data it processes be data from data processing units that have been correctly calculated for fares and correctly allocated to transportation costs.

[0154] The transportation revenue calculation engine is triggered under the following conditions: (the data processing unit has not undergone a state change within the current time period) and (the previous freight rate calculation result was successful and correct) and (the previous transportation allocation result was successful and correct) and (the data change time of the data processing unit must be earlier than the freight rate calculation result time, and the freight rate calculation result time must be less than the allocation result time).

[0155] (iv) Ticket Monitoring and Processing Engine

[0156] Ticket monitoring is a logical function that can be triggered at any time. Being able to be triggered at any time means that it can monitor the processing status of all data processing units at any time. However, for a stable final result, the data from the data processing units themselves must be stable, and the freight rate calculations, transportation allocations, and transportation revenue results must be correct and up-to-date.

[0157] Ticket monitoring and processing engine trigger conditions: It can be triggered at any time; however, the final stable data requirements are (the data processing unit has not undergone a state change within the current time cycle) and (the previous freight rate calculation result was successful and correct) and (the previous transportation allocation result was successful and correct) and (the previous transportation entry calculation result was successful and correct) and (the data change time of the data processing unit must be earlier than the freight rate calculation result time, the freight rate calculation result time must be less than the allocation result time, and the allocation result time must be later than the transportation entry calculation result time).

[0158] Business processes inherently have a sequential order. For airline settlement processes, the typical order is: fare calculation engine first, transportation allocation second (only after fare and transportation allocation are completed can transportation revenue be calculated), and finally, ticket monitoring. This order can be flexibly customized. Because of this sequential order, if data processing units do not enter the system in the correct order, or if data occurs out of sequence within the business process, problems arise where data participates in subsequent operations but ultimately becomes inaccurate. The business processing control based on ticket status management in this application aims to control this processing order, reduce redundant and meaningless calculations, and increase system throughput and operational efficiency.

[0159] When business data, such as data in the data processing unit, remains unchanged, based on the solution in this application, it does not need to repeatedly participate in the processing of the corresponding subtask, i.e., the corresponding computational logic unit. Only when the data in the business processing unit changes will the processing of the corresponding computational logic unit be triggered again. Ticket status management controls when the data processing unit should participate in computation and when it does not, thereby ensuring the accuracy of the final data and reducing system performance consumption.

[0160] Step 104: Obtain the target business data that needs to participate in the target sub-business, and process the target business data according to the processing logic of the target sub-business.

[0161] After identifying the target sub-business that needs to be triggered based on the triggering conditions of each sub-business, such as freight rate calculation, transportation allocation, transportation revenue calculation, or ticket monitoring, the target business data that needs to participate in the sub-business can be obtained in a more targeted manner. The processing flow of the target sub-business can be triggered on the obtained data, and the target business data can be processed according to the processing logic of the target sub-business.

[0162] In summary, the business data processing method provided in this application includes: determining the data status information corresponding to each type of business data involved in the settlement business; determining, at least based on the data status information corresponding to each type of business data, whether each type of business data needs to participate in each sub-business included in the settlement business in the current round of settlement processing; if there is business data that needs to participate in the current round of settlement processing, determining the target sub-business that needs to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business; obtaining the target business data that needs to participate in the target sub-business, and processing the target business data according to the processing logic of the target sub-business.

[0163] This application, through the above processing, avoids unnecessary data duplication in the settlement business process. Only data that needs to participate in the corresponding sub-business, such as data whose status has changed, will trigger the corresponding sub-business process again. By controlling when different types of business data should participate in the business process and when they do not, the accuracy of the final data is guaranteed, while improving system computing efficiency and reducing system computational load and performance / resource consumption.

[0164] In one embodiment, the business data processing method provided in this application may further include the following processing:

[0165] Determine whether the business agreements for at least some of the sub-businesses included in the settlement business have undergone protocol data changes;

[0166] If a change occurs, the corresponding type of business data should be synchronized according to the protocol data change information of the corresponding sub-business, and the data structure object for ticket status management corresponding to the corresponding type of business data should be updated based on the synchronized changes that should occur.

[0167] Specifically, determining the synchronous changes that should occur in the corresponding type of business data based on the protocol data change information of the corresponding sub-business can be further implemented as follows: based on the protocol data change information of the corresponding sub-business, determining the first data in the business data within the scope of the original protocol that does not match the modified protocol, and the second data that the modified protocol needs to add compared to the original protocol.

[0168] In other words, changes to protocol data mainly fall into two categories. First, some or all of the business data (such as data processing units) within the scope of the original protocol are no longer applicable to the modified protocol; this type of data is identified as the first type of data mentioned above. Second, the business data within the scope of the modified protocol has been newly added compared to the original protocol; this type of data is identified as the second type of data mentioned above. Both of these situations will cause changes to business data, such as the data in the data processing units. Therefore, it is necessary to update and record the relevant status data in the core data structure of ticket status management, and determine whether the changed data needs to participate in the processing of each sub-task according to the processing logic of the above embodiment. Then, based on the corresponding triggering conditions, the calculation logic unit of the corresponding sub-task is triggered to recalculate.

[0169] While protocol data in settlement systems, such as that in airline settlement systems, is not part of the business data (data processing unit), it is still one of the key data involved in business processing. Business data is the data used for calculations, while the protocol is the logical basis for those calculations. Changes in this part of the data will also cause adaptive changes in the business data and affect the scope of data involved in business processing. This embodiment, by performing the aforementioned processing to match changes in protocol data, can effectively achieve accurate, fast, and efficient business processing of changes in business data caused by changes in protocol data.

[0170] Corresponding to the above-described business data processing method, this application also provides a business data processing apparatus, the structure of which is as follows: Figure 4 As shown, it includes:

[0171] The first determining unit 10 is used to determine the data status information corresponding to each type of business data involved in the settlement business;

[0172] The second determining unit 20 is used to determine, at least based on the data status information corresponding to each type of business data, whether each type of business data needs to participate in each sub-business included in the settlement business in the current round of settlement processing;

[0173] The third determining unit 30 is used to determine the target sub-business to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business if there is business data that needs to participate in the current round of settlement processing.

[0174] The business processing unit 40 is used to obtain target business data that needs to participate in the target sub-business, and process the target business data according to the processing logic of the target sub-business.

[0175] In one embodiment, the first determining unit 10 is specifically used for:

[0176] Obtain the data structure objects for ticket status management corresponding to each type of business data;

[0177] Read the data status information of the corresponding type of business data from the corresponding data structure object;

[0178] The data structure object used for ticket status management contains data status information that represents the processing status and status change trajectory of the corresponding type of business data.

[0179] In one embodiment, the above-described apparatus further includes: a data status maintenance unit, configured to:

[0180] Based on the created ticket status management processing interface, status change information of various types of business data is collected;

[0181] Based on the collected status change information, the data status information of that type of business data is recorded or updated in the data structure object used for ticket status management corresponding to the relevant type of business data.

[0182] In one embodiment, the second determining unit 20 is specifically used for:

[0183] Based on the corresponding data status information, determine whether the status of each type of business data has changed within the current time period;

[0184] Based on whether each type of business data has undergone a state change within the current time period, whether each type of business data has participated in the corresponding sub-businesses included in the settlement business, and whether the sub-businesses participated in have been successfully processed, it is determined whether each type of business data needs to participate in the various sub-businesses included in the settlement business in the current round of settlement processing.

[0185] In one embodiment, the third determining unit 30 is specifically used for:

[0186] According to the preset sub-business processing order, determine the next sub-business to be processed in each sub-business included in the settlement business;

[0187] Determine whether the triggering condition corresponding to the next sub-service is met. If it is met, determine that the next sub-service is the target sub-service that needs to be triggered.

[0188] The triggering conditions for each sub-business are conditions related to the data status information of the corresponding business data.

[0189] In one embodiment, the above-described apparatus further includes:

[0190] The protocol change processing unit is configured to: determine whether the business protocol of at least some of the sub-businesses included in the settlement business has undergone protocol data change; if a change has occurred, determine the synchronous change that should occur in the corresponding type of business data based on the protocol data change information of the corresponding sub-business, and update the data structure object for ticket status management corresponding to the corresponding type of business data based on the synchronous change that should occur in the corresponding type of business data.

[0191] In one embodiment, when the protocol change processing unit determines the synchronous changes that should occur in the corresponding type of service data based on the protocol data change information of the corresponding sub-service, it is specifically used for:

[0192] Based on the protocol data change information of the corresponding sub-business, determine the first data in the business data within the scope of the original protocol that does not match the modified protocol, and the second data that needs to be added in the modified protocol compared to the original protocol.

[0193] In one embodiment, the various types of business data include at least some of the following types of data: transportation data, sales data, inbound cash-on-delivery data, and internal billing data;

[0194] The settlement business includes at least some of the sub-businesses such as freight rate calculation, transportation allocation, transportation revenue calculation, and ticket monitoring.

[0195] The business data processing apparatus provided in this application embodiment is described simply because it corresponds to the business data processing method provided in the above method embodiment. For any similarities, please refer to the description of the above method embodiment, which will not be detailed here.

[0196] This application also provides a computer-readable medium having a computer program stored thereon, the computer program including program code for performing the business data processing method provided in the above method embodiments.

[0197] In the context of this application, a computer-readable medium (machine-readable medium) can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0198] It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0199] The aforementioned computer-readable medium may be contained within an electronic device or may exist independently without being assembled into an electronic device.

[0200] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0201] For ease of description, the above systems or devices are described separately as various modules or units based on their functions. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware components.

[0202] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0203] Finally, it should be noted that in this document, relational terms such as first, second, third, and fourth are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0204] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A business data processing method, characterized in that, include: Determine the data status information corresponding to each type of business data involved in the settlement business; Based on the data status information corresponding to each type of business data, determine whether the status of each type of business data has changed within the current time period. The current time period is the time elapsed between the most recently completed settlement process and the next process to be triggered. The next process is the current round of settlement process. Based on whether each type of business data has undergone a state change within the current time period, whether each type of business data has participated in the corresponding sub-businesses included in the settlement business, and whether the sub-businesses it participated in have been successfully processed, it is determined whether each type of business data needs to participate in each sub-business included in the settlement business in the current round of settlement processing. Among them, business data that has not undergone a state change and has participated in the corresponding sub-businesses and been successfully processed skips the current round of settlement processing. Except for business data that has not undergone a state change and has participated in the corresponding sub-businesses and been successfully processed, all other business data need to participate in the current round of settlement processing. If there is business data that needs to participate in the current round of settlement processing, the target sub-business that needs to be triggered is determined according to the triggering conditions corresponding to each sub-business included in the settlement business; Obtain the target business data that needs to participate in the target sub-business, and process the target business data according to the processing logic of the target sub-business.

2. The method according to claim 1, characterized in that, The determination of the data status information corresponding to each type of business data involved in the settlement business includes: Obtain the data structure objects for ticket status management corresponding to each type of business data; Read the data status information of the corresponding type of business data from the corresponding data structure object; The data structure object used for ticket status management contains data status information that represents the processing status and status change trajectory of the corresponding type of business data.

3. The method according to claim 2, characterized in that, Before determining the data status information corresponding to each type of business data involved in the settlement business, the method further includes: Based on the created ticket status management processing interface, status change information of various types of business data is collected; Based on the collected status change information, the data status information of that type of business data is recorded or updated in the data structure object used for ticket status management corresponding to the relevant type of business data.

4. The method according to claim 1, characterized in that, The step of determining the target sub-business to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business includes: According to the preset sub-business processing order, determine the next sub-business to be processed in each sub-business included in the settlement business; Determine whether the triggering condition corresponding to the next sub-service is met. If it is met, determine that the next sub-service is the target sub-service that needs to be triggered. The triggering conditions for each sub-business are conditions related to the data status information of the corresponding business data.

5. The method according to claim 3, characterized in that, Also includes: Determine whether the business protocols of at least some of the sub-businesses included in the settlement business have undergone protocol data changes; If a change occurs, the corresponding type of business data should be synchronized according to the protocol data change information of the corresponding sub-business, and the data structure object for ticket status management corresponding to the corresponding type of business data should be updated based on the synchronized changes that should occur.

6. The method according to claim 5, characterized in that, The step of determining the synchronous changes that should occur in the corresponding type of business data based on the protocol data change information of the corresponding sub-business includes: Based on the protocol data change information of the corresponding sub-business, determine the first data in the business data within the scope of the original protocol that does not match the modified protocol, and the second data that needs to be added in the modified protocol compared to the original protocol.

7. The method according to claim 1, characterized in that, The various types of business data include at least some of the following types of data: transportation data, sales data, port arrival payment data, and internal billing data; The settlement business includes at least some of the sub-businesses such as freight rate calculation, transportation allocation, transportation revenue calculation, and ticket monitoring.

8. A business data processing device, characterized in that, include: The first determining unit is used to determine the data status information corresponding to each type of business data involved in the settlement business; The second determining unit is used to determine, at least based on the data status information corresponding to each type of business data, whether each type of business data needs to participate in each sub-business included in the settlement business in the current round of settlement processing; The third determining unit is used to determine the target sub-business to be triggered based on the triggering conditions corresponding to each sub-business included in the settlement business if there is business data that needs to participate in the current round of settlement processing. A business processing unit is used to acquire target business data that needs to participate in the target sub-business, and to process the target business data according to the processing logic of the target sub-business. The second determining unit is specifically used for: determining, based on the data status information corresponding to each type of business data, whether the status of each type of business data has changed within the current round of time period, wherein the current round of time period is the time elapsed between the most recently completed settlement process and the next process to be triggered, and the next process is the current round of settlement process; determining, based on whether the status of each type of business data has changed within the current round of time period, whether each type of business data has participated in the corresponding sub-business included in the settlement process, and whether the sub-business participated in has been successfully processed, whether each type of business data needs to participate in each sub-business included in the settlement process in the current round of settlement process, wherein business data that has not changed status and has participated in the corresponding sub-business and been successfully processed skips the current round of settlement process, and all other business data except for business data that has not changed status and has participated in the corresponding sub-business and been successfully processed need to participate in the current round of settlement process.

9. A computer-readable medium, characterized in that, It stores a computer program thereon, the computer program containing program code for performing the method as described in any one of claims 1-7.

Images