Whole-process data processing method, system and device for business travel order, and storage medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a whole-process data processing method, system and device for a business travel order, and a storage medium, and the method comprises the steps: generating a unique main Hash identifier of the business travel order, and uploading the unique main Hash identifier to a block chain network; for a plurality of business links in the life cycle of the business travel order, sequentially constructing sub-hash identifiers associated with the main hash identifier on a block chain network to form a main-sub-hash chain; wherein when each sub-hash identifier is constructed, the input data at least comprises the main hash identifier, the link data of the current service link and the sub-hash identifier generated by the adjacent previous service link, so that the sub-hash identifiers are nested and bound in sequence; and dynamically generating and synchronizing consumption details associated with the order based on the link data recorded in the main-sub hash chain. According to the invention, automation, refinement and compliance of the whole business travel management process under data driving are realized.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a method, system, device, and storage medium for the whole process of travel order data processing. Background Technology

[0002] In the current field of travel management, data related to orders, payments, and reimbursements is often scattered across independent systems such as TMC, finance, and payment, forming data silos that are difficult to synchronize and trace in real time. Existing solutions either rely on centralized storage, which makes data susceptible to tampering and has low reliability; or they only use blockchain for post-event static evidence storage, failing to deeply integrate with consumption detail management and unable to achieve real-time linkage and proactive business control for dynamic order changes. In addition, these solutions often have poor compatibility with existing enterprise IT architectures, requiring system reconstruction for implementation, which is costly. Therefore, how to build an integrated solution that can ensure the reliability and real-time traceability of data throughout the entire process, while seamlessly integrating with existing systems and achieving intelligent linkage and control, has become an urgent technical challenge to be solved. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a method, system, device and storage medium for full-process data processing of travel orders to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a method for processing the entire process of travel order data, including: Generate a unique master hash identifier for the travel booking and upload it to the blockchain network; For multiple business stages in the lifecycle of the travel order, sub-hash identifiers associated with the main hash identifier are sequentially constructed on the blockchain network to form a main-sub-hash chain. When constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the stage data of the current business stage, and the sub-hash identifier generated by the immediately preceding business stage, so that each sub-hash identifier is nested and bound in sequence. Based on the process data recorded in the master-child hash chain, consumption details associated with the order are dynamically generated and synchronized.

[0005] In one optional implementation, generating a unique master hash identifier for the travel order and uploading it to the blockchain network includes: The order's unique identifier, creation timestamp, traveler identifier, and business type identifier are concatenated to form the first input data; The first input data is calculated using a cryptographic hash algorithm to generate the master hash identifier; The master hash identifier is distributed to multiple participating nodes that make up the blockchain network for storage, wherein the participating nodes include at least enterprise nodes and travel service provider nodes.

[0006] In an optional implementation, for multiple business stages in the lifecycle of the travel order, sub-hash identifiers associated with the main hash identifier are sequentially constructed on the blockchain network, including: For the first business step, the main hash identifier, a preset initial vector, the step data of the first business step, the type identifier of the first business step, and the first timestamp are concatenated to form the second input data; the second input data is calculated using a cryptographic hash algorithm to generate the first sub-hash identifier; For any current business step after the first business step, the main hash identifier, the sub-hash identifier generated by the immediately preceding business step, the step data of the current business step, the type identifier of the current business step, and the current timestamp are concatenated to form the current input data; the encrypted hash algorithm is used to calculate the current input data to generate the current sub-hash identifier corresponding to the current business step; The generated sub-hash identifiers are distributed to the participating nodes of the blockchain network for storage.

[0007] In one alternative implementation, multiple business processes include the booking process, payment process, change process, invoice acquisition process, and reimbursement process in the travel order lifecycle.

[0008] In an optional implementation, it further includes: The system obtains raw data for the current business process in real time from the corresponding external business systems through a standardized application programming interface (API). Specifically, the raw data for the booking process is obtained from the travel management (TMC) platform or the enterprise office automation (OA) system; the raw data for the payment process is obtained from the payment institution system; and the raw data for the invoice acquisition process is obtained from the invoice management system. The acquired raw data is serialized into a standardized structured data string according to a preset data structure rule, which serves as the stage data; wherein, the serialization includes organizing the data fields into key-value pairs and concatenating them in a predetermined order.

[0009] In one optional implementation, the preset data structure rules include: Organize the key fields of the original data into key-value pairs of "field name: field value"; Sort all key-value pairs lexicographically according to their field names; The sorted key-value pairs are concatenated using a preset delimiter.

[0010] In an optional implementation, based on the stage data recorded in the master-child hash chain, consumption details associated with the order are dynamically generated and synchronized, including: Obtain payment process data from the master-child hash chain, and generate initial consumption details records based on the payment process data; When a sub-hash identifier of a change step is added to the master-sub hash chain, the change content is extracted from the step data of the change step, and the initial consumption detail record is updated according to the change content to obtain the updated consumption detail record; If the change is a rescheduling, a rescheduling fee entry will be added to the consumption details record; if the change is a refund, the refund status and refund amount will be marked in the consumption details record. The updated consumption details will be synchronized to the company's financial system via a standardized application programming interface (API). If it is detected that the order has been submitted for reimbursement, the status of the reimbursement application is updated according to the updated consumption details record.

[0011] Secondly, the present invention provides a full-process data processing system for travel orders, comprising: The generation module is used to generate a unique master hash identifier for travel orders and upload it to the blockchain network; The association module is used to construct sub-hash identifiers associated with the main hash identifier on the blockchain network for multiple business links in the life cycle of the travel order, forming a main-sub-hash chain; wherein, when constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the link data of the current business link, and the sub-hash identifier generated by the immediately preceding business link, so that the sub-hash identifiers are nested and bound in sequence. The synchronization module is used to dynamically generate and synchronize the consumption details associated with the order based on the process data recorded in the master-child hash chain.

[0012] Thirdly, a device is provided, comprising: Memory, used to store the entire data processing program for travel orders; The processor is configured to implement the steps of the full-process data processing method for travel orders as provided in the first aspect when executing the full-process data processing program for the travel orders.

[0013] Fourthly, a computer-readable storage medium is provided, on which a full-process data processing program for travel orders is stored, wherein when the full-process data processing program for travel orders is executed by a processor, the steps of the full-process data processing method for travel orders as provided in the first aspect are implemented.

[0014] The beneficial effects of this invention are that the end-to-end data processing method, system, equipment, and storage medium for travel orders provided by this invention, by constructing a master-sub hash chain based on blockchain, achieves tamper-proof, sequentially nested storage, and second-level reliable traceability of data throughout the entire travel order process, fundamentally solving the problems of data silos and trustworthiness. Through an intelligent linkage mechanism, the system can automatically generate and synchronize consumption details in real time based on hash chain data, and provide real-time early warning and linkage control for changes, exceeding limits, and anomalies, significantly moving risk control nodes forward. This method seamlessly integrates with existing enterprise systems through standardized interfaces, significantly reducing deployment costs and adaptation difficulties, and realizing full-process automation, refinement, and compliance of data-driven travel management. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] The full-process data processing method for travel orders provided in this embodiment of the invention is executed by computer equipment, and correspondingly, the full-process data processing system for travel orders runs on computer equipment.

[0022] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a full-process data processing system for travel orders. Depending on different needs, the order of steps in this flowchart can be changed, and some steps can be omitted.

[0023] like Figure 1 As shown, the method includes: S1. Generate a unique master hash identifier for the travel booking and upload it to the blockchain network; S2. For multiple business stages in the lifecycle of the travel order, sub-hash identifiers associated with the main hash identifier are sequentially constructed on the blockchain network to form a main-sub-hash chain; wherein, when constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the stage data of the current business stage, and the sub-hash identifier generated by the adjacent previous business stage, so that each sub-hash identifier is nested and bound in sequence. S3. Based on the process data recorded in the master-child hash chain, dynamically generate and synchronize the consumption details associated with the order.

[0024] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0025] S101. Data Concatenation to Form the First Input Data. The system extracts four core static fields from the received travel order request: a unique order identifier (e.g., a globally unique order number generated by the TMC platform), a creation timestamp (the UTC time accurate to milliseconds when the order was initiated), a traveler identifier (an employee ID or unique identification code within the company, such as "EMP1001"), and a business type identifier (a code used to distinguish business types such as travel and procurement, such as "TRAVEL"). The system concatenates these fields into a complete string in a predetermined order (e.g., "unique order identifier + creation timestamp + traveler identifier + business type identifier"). To ensure consistency in subsequent hash calculations, specific delimiters (such as semicolons) can be used to connect the fields, forming the final first input data.

[0026] S102. Calculate and generate the master hash identifier using a cryptographic hash algorithm. The system calls a cryptographic hash function, such as the SHA-256 algorithm, to calculate the first input data string obtained in step S101. This algorithm maps input data of arbitrary length to a fixed-length (e.g., 256-bit) seemingly random hexadecimal string output. This output is the master hash identifier of the travel order (e.g., "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef1234"). This hash value has strong collision resistance, meaning it is extremely difficult to find two different order data that generate the same master hash, thus ensuring its uniqueness as the "digital fingerprint" of the order.

[0027] S103. Distribute and store the master hash identifier on the blockchain network. The system packages the generated master hash identifier, along with optional associated order core metadata (such as order number and creation time), into a transaction and broadcasts it to a pre-configured consortium blockchain network. This network is jointly maintained by multiple participating nodes, including at least enterprise nodes (deployed on internal enterprise servers or private clouds, representing the enterprise's finance or audit department) and travel service provider nodes (deployed on the service provider side such as TMCs, airlines, or hotel groups). After receiving the transaction, each node verifies and reaches consensus according to a predetermined consensus mechanism (such as the Practical Byzantine Fault Tolerance (PBFT) mechanism). Once consensus is reached, the transaction containing the master hash identifier is encapsulated into a new block and appended to the blockchain ledger copies of all nodes, thereby achieving immutable and permanent storage of the master hash identifier in the decentralized network. At this point, the travel order obtains its unique and trusted root identity identifier on the blockchain.

[0028] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0029] S201. Data Acquisition and Standardization Processing at Each Stage For each business stage in the travel order lifecycle (such as booking, payment, changes, invoice acquisition, and reimbursement), the system first performs the acquisition and standardization of stage data.

[0030] Data Acquisition: The system obtains raw data of the current business process from the corresponding external business system in real time through a standardized application programming interface (API).

[0031] The raw data for the booking process is obtained from the Travel Management (TMC) platform or the Office Automation (OA) system.

[0032] The raw data for the payment process is obtained from the payment institution's (such as a bank or a third-party payment platform) system.

[0033] The raw data for the invoice acquisition process is obtained from the invoice management system.

[0034] Data standardization: After acquiring the raw data, the system serializes it into a standardized structured data string according to preset data structure rules. This string serves as the data for that stage. The serialization process specifically includes: Key-value pair organization: Organize the key business fields in the original data into the form of "field name:field value" (e.g., airline:CA1234, price:1500).

[0035] Lexicographical sorting: All generated key-value pairs are sorted in ascending order strictly according to the lexicographical order of their "field names".

[0036] Delimiter concatenation: Sorted key-value pairs are concatenated sequentially using a preset delimiter (such as a semicolon;) to ultimately form a unified and standardized structured data string (e.g., airline:CA1234;price:1500;...). This method ensures that identical content will generate a consistent string.

[0037] S202. Generate sub-hash identifiers based on process data and upload them to the blockchain. After obtaining standardized process data, the system then generates sub-hashes and stores them on the blockchain to construct a hash chain.

[0038] Generate the first sub-hash (taking "reservation" as an example): This involves using the already generated master hash identifier (H... m The input data is formed by concatenating a preset initial vector (such as the hash value of the string "INIT_BOOKING"), the booking stage data (Data1) obtained in step 1, the stage type identifier (such as "BK"), and the first timestamp (T1) of the stage occurrence. Then, a cryptographic hash algorithm (such as SHA-256) is used to calculate the first sub-hash identifier (H). s1 ).

[0039] Generate sub-hashes for subsequent processes (taking "payment" and "change" as examples): For any current business process such as payment or rescheduling, the system will assign a primary hash (H) to the primary hash identifier. m ), the sub-hash identifier (H) generated by the immediately preceding business process. sn-1 The current stage data obtained in step 1 (Data) n The current stage's type identifier (such as "PY", "CHG") and the current timestamp (T) nThe data is concatenated to form the current input data. Similarly, a cryptographic hash algorithm is used to calculate and generate the current sub-hash identifier (H) corresponding to the current business process. sn ).

[0040] Hash identifiers are stored on-chain: all generated sub-hash identifiers (H s1 H s2 ,…H sn All data will be distributed to participating nodes in a consortium blockchain network consisting of enterprise nodes, travel service provider nodes, etc., and stored through a consensus mechanism. This process forms a master-child hash chain that is bound to the master hash, with each node linked to the next, a clear time sequence, and is tamper-proof, fully recording the entire lifecycle of data from booking, payment, changes to invoicing and reimbursement.

[0041] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0042] S301. Generation of Initial Consumption Details Once the payment process is complete, its corresponding payment sub-hash (e.g., H) s2 After the serialized payment process data (Data_PY, such as payment_id:PY001;amount:1650;channel:Alipay;status:success) is stored on the blockchain, the consumption details management module is triggered. This module first obtains and parses this payment process data by querying the blockchain network. Based on the amount and channel fields, and combined with the consumption items (such as airfare and accommodation fees) parsed from the on-chain booking process data (Data_BK), the system automatically creates the initial consumption details record for this travel order. This record is stored in the database as a structured data entry, with core fields including: order number, consumption item, amount, payment status (marked as "paid"), and the corresponding payment sub-hash identifier (H). s2 (and timestamps.)

[0043] S302. Change-driven dynamic update of consumption details When an order changes (such as rescheduling or refund), the corresponding change sub-hash (e.g., H) is used. s3 After the data (Data_CHG) is uploaded to the blockchain, the system's event listening mechanism will capture this on-chain event. The consumption details module then obtains and parses the Data_CHG, determines the change type based on fields such as change_reason (reason for change), and executes different update logic accordingly. If it's a rescheduling: The system will parse out fields such as `change_fee` (rescheduling fee) and `new_total_price` (new total price). A new sub-record will be added to the order's transaction details, with the transaction item being "rescheduling fee" and the amount being the parsed fee value, and will be associated with the change sub-hash H. s3 At the same time, the amounts for the original transportation expenses may be updated.

[0044] If it's a refund: The system will parse out the `refund_amount` (refund amount). It will then locate the corresponding original payment entry in the transaction details, update its status field to "partially refunded" or "fully refunded," record the refund amount and time, and simultaneously associate the change with the sub-hash H. s3 The entire update process is fully automated, requiring no manual data entry, ensuring that the consumption details always remain consistent with the latest order status recorded on the blockchain.

[0045] S303. Real-time synchronization of updated details to the financial system Each time a consumption detail record is created or updated, the system immediately pushes the updated complete consumption detail data (in structured formats such as JSON) to the enterprise's financial system (such as ERP or accounting software) via a pre-configured standardized RESTful API or message middleware. The API call includes authentication and data encryption to ensure secure transmission. Upon receiving the data, the financial system can automatically generate or update internal accounting records such as accounts payable and cost accruals, achieving real-time synchronization between business and financial data.

[0046] S304. Intelligent status linkage with the reimbursement process After synchronizing the expense details to the financial system, the system will further query the reimbursement process status associated with the order. If it detects that the reimbursement application for the order has been submitted but not yet finalized, the system will automatically send a status update instruction to the reimbursement approval system. For example, if additional expenses are incurred due to changes, the system will mark the reimbursement form as "pending supplementary review"; if a refund occurs, the refunded portion will be automatically deducted from the reimbursement amount, or the reimbursement form will be marked as "needs correction". This linkage mechanism technically prevents duplicate or erroneous reimbursements based on expired order information, shifting the risk control point from post-event financial verification to automatic intervention during business operations.

[0047] In one embodiment of the present invention, implementation relies on a layered, decoupled, and intelligently interconnected system architecture. This architecture can be logically divided into four layers: a trusted data layer, an intelligent processing layer, a business application layer, and a system integration layer.

[0048] 1. Trusted Data Layer: Consortium Blockchain Network and Hash Chain Storage At the core of this layer is a permissioned consortium blockchain network maintained by multiple participants. Network nodes are deployed according to their business roles, primarily including: Enterprise Nodes: Deployed on the enterprise intranet or private cloud, representing the enterprise's finance, audit, and compliance departments. They are responsible for storing and verifying the hash chain of all travel orders related to themselves and participating in network consensus.

[0049] Travel service provider nodes: Deployed by travel management companies (TMCs), airlines, hotel groups, car rental companies, and other service providers. They are responsible for generating hashes and uploading real business data from booking, change, and other processes to the blockchain, while also verifying the authenticity of enterprise payment information.

[0050] Payment institution nodes: Deployed by banks and third-party payment platforms (such as Alipay and UnionPay). They are responsible for uploading payment / refund transaction information to the blockchain, providing non-repudiable proof of payment transactions.

[0051] Audit / Regulatory Nodes: These are held by the internal audit department or external compliance regulatory agencies. They typically function as observer nodes, possessing specific permissions for querying and verification capabilities, but do not participate in daily consensus.

[0052] The network employs an efficient consensus mechanism (such as the Practical Byzantine Fault Tolerance algorithm PBFT or its variants) to ensure data consistency and immutability while also considering transaction processing performance (TPS), meeting the high-frequency, real-time needs of business travel. The master hash and sub-hash identifiers of all travel orders are stored in the blockchain ledger at this layer, forming a globally trusted index.

[0053] 2. Intelligent Processing Layer: Core Engine This layer contains a series of microservice engines and is the "brain" of the system: Hash generation engine: It uniformly adopts the SHA-256 encrypted hash algorithm. The engine receives standardized process data and strictly follows the rule of "time stamp sequence nested binding method" to concatenate elements such as the main hash, previous sub-hash, type code, and timestamp to calculate and generate a unique hash identifier.

[0054] Data serialization engine: Built-in preset data structure rule templates (such as JSONSchema) are responsible for converting raw data from different sources and with different formats into unified key-value pair strings ordered lexicographically, ensuring the consistency of hash input.

[0055] Rules engine: Stores and enforces business rules, such as travel policies (accommodation and transportation standards for employees at all levels) and compliance rules (invoice verification rules and reimbursement association rules). It drives the "three-in-one" automatic verification and anomaly warning.

[0056] Intelligent Linkage and Synchronization Engine: Monitors hash events on the blockchain, parses the event content, and automatically triggers linked operations such as updating consumption details, pushing data to the financial system, and updating reimbursement status.

[0057] 3. Business Application Layer: Functional Modules This layer is user-facing and provides a detailed functional interface: Travel order management portal: the entry point for employees to make reservations, view order status, and submit change requests.

[0058] Expense Details and Reimbursement Platform: Displays real-time and accurate expense details, supports one-click generation of reimbursement forms, and receives verification results and alert notifications.

[0059] Management Dashboard and Audit Traceability Platform: Provides managers and auditors with visual dashboards, multi-dimensional cost analysis reports, and a powerful "one-click traceability" function, presenting the entire lifecycle of an order in seconds.

[0060] 4. System Integration Layer: Standardized Interfaces and Middleware This is key to the seamless integration of this system with the enterprise's existing IT ecosystem. It provides a set of RESTful APIs and message queue middleware (such as Kafka and RabbitMQ).

[0061] Input interface: Used to pull (Poll) or receive push (Webhook) business data from TMC, OA, payment institutions, invoice systems, etc.

[0062] Output interface: Used to push updated consumption details, early warning information and process status signals to ERP (such as SAP, Oracle), financial software (such as Yonyou, Kingdee), reimbursement system, etc.

[0063] All interfaces use HTTPS protocol for data transmission, the data format is JSON, and include authentication and authorization mechanisms based on OAuth2.0 or API keys to ensure integration security and data privacy.

[0064] The detailed data processing flow for each stage includes the following steps: 1. Order creation and initialization (reservation process) The process begins once an employee initiates and receives approval for a business trip through the company's OA or TMC platform.

[0065] Data Acquisition: The API client of the system integration layer periodically or through event subscriptions retrieves structured order data packets from the order confirmation interface of the TMC platform or the approval completion interface of the OA system. This data packet contains at least: order_id (a globally unique order number, such as CORP-TRAV-20240328-001), applicant_id (applicant's employee ID), department (department code), project_code (project cost center), purpose (travel purpose), and itinerary_details (itinerary details JSON, containing flight number, departure and arrival times, hotel name, check-in and check-out dates, etc.).

[0066] Generate the master hash (H) m The hash generation engine of the intelligent processing layer is invoked. The engine first extracts core static fingerprint information from the order data packet: order_id, the order's creation_timestamp (accurate to milliseconds), applicant_id, and a fixed business_type_code (e.g., "T") representing the "travel" business. Then, the engine concatenates these strings in a preset order (e.g., order_id + "|" + creation_timestamp + "|" + applicant_id + "|" + business_type_code) to generate the original string. Finally, a SHA-256 hash operation is performed on this string to obtain a 64-bit hexadecimal string, which is the main hash identifier H. m For example, H m =a1b2...f0e9.

[0067] Main hash on-chain: Generated H m The necessary metadata (such as order_id, creation_timestamp) is packaged into a "genesis transaction" and submitted to the consortium blockchain network via SDK call. The network nodes perform consensus verification; once verification is successful, the transaction is included in the new block. m It is permanently and immutably recorded on the blockchain, becoming the order's unique and credible "identity card" in the digital world.

[0068] Booking process data processing and sub-hash generation: Serialization: The data serialization engine begins its work. It extracts dynamic information such as `itinerary_details` and `price_breakdown` from the original order data packet. For example, for a flight booking, the engine extracts fields such as `airline`, `flight_number`, `cabin_class`, `ticket_price`, and `tax`. Following the rule of "field name:value", it generates multiple key-value pairs such as `airline:CA1234;cabin_class:Economy;ticket_price:1200;tax:120`. Subsequently, the engine strictly sorts these pairs according to the alphabetical order (ASCII code) of the field names, resulting in: airline:CA1234;cabin_class:Economy;tax:120;ticket_price:1200, Then connect them with semicolons to form the final standardized string Data_BK.

[0069] Generate the first sub-hash (H) s1 The hash generation engine is invoked again. Input parameters include: the main hash H. m The system requires a pre-defined, publicly available initialization vector IV_Start (e.g., a fixed value obtained by SHA-256 calculation of the string "DIFF_START_TRAVEL_BOOKING"), a stage type code "BK", a precise timestamp T1 indicating the subscription operation occurred, and the serialized Data_BK. The engine concatenates these parameters and calculates their SHA-256 hash to obtain the subscription sub-hash H. s1 Its mathematical expression is: H s1 =SHA256(H m ||IV_Start||"BK"||T1||Data_BK).

[0070] This H s1 It was also stored on-chain as a transaction, and along with H m Logically related. At this point, the hash chain of this order starts from the root node H. m The first branch H was generated. s1 .

[0071] 2. Payment fulfillment and related matters (payment process) After an employee completes a payment on the TMC platform, the payment information is transferred.

[0072] Data Collection: After a successful payment, the payment institution (such as an enterprise payment gateway) will notify the system integration layer of the payment result through a callback webhook or by actively querying the API. The notification data packet includes: order_id (associated with the order), payment_transaction_id (payment institution transaction number), payment_amount (actual payment amount), currency, payment_channel (payment channel), payment_status (status, such as SUCCESS), and payment_time (payment completion time).

[0073] Data processing and sub-hash generation: Serialization: The serialization engine processes payment data. It generates key-value pairs, such as: payment_id:PY202403280001;amount:1320.00;currency:CNY;channel:Corporate_Credit_Card;status:success, After sorting and concatenating, we get Data_PY.

[0074] Generate payment sub-hash (H) s2 The core logic of the hash generation engine is embodied here. Its input parameter is: main hash H. m Preorder sub-hash H s1 (This is key to achieving nested binding), the process type code "PY", the payment timestamp T2, and Data_PY. The calculation formula is: H s2 =SHA256(H m ||H s1 ||“PY”||T2||Data_PY). This ensures H s2 Not only with orders (H) m It is linked to, and even more so to, the "booking" behavior (H). s1 This forms a strict sequential dependency relationship. s2 Upload to the blockchain.

[0075] Initial generation of consumption details: The intelligent association engine monitors the blockchain, and when it detects H... s2 Upon the on-chain event, the complete Data_PY and Data_BK stored off-chain are immediately parsed. Based on the consumption item in Data_BK and the payment amount in Data_PY, the engine creates the initial consumption details record for that order in the business application layer database. For example, a record might be created as follows: {Order ID, Consumption Item: "Airfare", Amount: 1320.00, Payment Status: "Paid", Associated Payment Hash: H} s2Update time: T2}. At the same time, this record is marked as "Invoice to be associated".

[0076] 3. Dynamic changes and chained records (change process) When travel plans change, the system's intelligent linkage capabilities become apparent.

[0077] Data Collection: Employees initiate rebooking or refund requests on the TMC platform. After the TMC system completes the operation, it sends a change notification to this system via API. The data packet includes: order_id, change_type (change type: rebooking / REFUND), original_item_ref (original item reference, such as original flight number), new_item_details (new item details, new flight number), change_fee (rebooking fee), refund_amount (refund amount, if any), total_adjustment (total amount adjustment), change_reason (reason for change), and change_time (operation time).

[0078] Data processing and sub-hash generation: Serialization: The serialization engine generates key-value pairs, such as: change_type:REBOOKING;original_flight:CA1234;new_flight:CA5678;change_fee:200;refund_amount:0;total_adjustment:200;reason:Meeting_Delayed, After sorting, we get Data_CHG.

[0079] Generate change sub-hash (H) s3 The input parameters for the hash generation engine are: main hash H m The immediately preceding child hash H s2 (At this point, it's the payment sub-hash), the stage type code "CHG", the change timestamp T3, and Data_CHG. Calculation formula: H s3 =SHA256(H m ||H s2 ||“CHG”||T3||Data_CHG).

[0080] H s3 Uplink, it points to H s2 It clearly records the chronological logic that "a change occurred after payment".

[0081] Expense details are dynamically updated and synchronized with financial records: Automatic Updates: The intelligent association engine captures H s3 On-chain event. Parse Data_CHG. If change_type is REBOOKING, the engine automatically adds a sub-record to the consumption details: {Order ID, Consumption Item: "Rescheduling Fee", Amount: 200.00, Status: "Occurred", Related Change Hash: H} s3 At the same time, the original airfare amount may be updated (if the total price changes). The entire process requires no manual data entry by finance personnel.

[0082] Real-time synchronization: After the update is complete, the synchronization engine immediately pushes the latest and complete consumption details (JSON format) asynchronously to the enterprise financial system through the message queue of the system integration layer. After receiving the data, the financial system's interface service can automatically update its internal cost accrual or accounts payable modules, achieving near real-time synchronization between business data and financial data (the delay is usually within 3 seconds).

[0083] Reimbursement status linkage (real-time control): Before and after synchronization, the system will check the reimbursement status of the order. If it finds that the reimbursement application has been submitted but not yet paid, the system will automatically add an approval node "Order has been changed, please review" to the reimbursement approval flow and notify the person requesting the reimbursement and the financial reviewer, effectively preventing reimbursements based on old data before the change.

[0084] 4. Reimbursement verification is linked to the "three-in-one" system (invoices and reimbursement process). When an employee prepares to submit an expense report, the system's "firewall" function is activated.

[0085] Invoice data retrieval and sub-hash generation: Employees upload electronic invoices (PDF / OFD) or provide invoice numbers on the reimbursement platform. The system calls the verification interface of the tax authority or third-party invoice platform through the integration layer to obtain structured invoice data: invoice_code, invoice_number, total_amount (tax-inclusive amount), tax_amount, seller_name, issue_date, etc.

[0086] The serialization engine processes it as Data_INV, such as: invoice_code:044001800111;invoice_no:12345678;amount:1320.00;seller:ExampleTMCCo.,Ltd.;issue_date:20240329.

[0087] Generate invoice sub-hash Hs4 : H s4 =SHA256(H m ||H s3 ||“INV”||T4||Data_INV).

[0088] After being put on the blockchain, orders, payments, changes, and invoices are linked together on the hash chain.

[0089] "Three-in-one" automatic verification (core risk control): When H s4 When data is uploaded to the blockchain or an employee submits an expense reimbursement request, the rules engine is triggered. It performs a complex process of multi-source data aggregation and comparison: Data retrieval: Based on H m Find H from the chain index s1 H s2 H s3 H s4 And retrieve the complete Data_BK, Data_PY, Data_CHG, and Data_INV from off-chain storage.

[0090] Expense details reconstruction: Based on the above data, accurately reconstruct the expense details that should theoretically match at the current moment in memory (including airfare of 1320 yuan, rescheduling fee of 200 yuan, totaling 1520 yuan).

[0091] Cross-verification: Amount consistency verification: Compare the total_amount in the invoice's Data_INV with the "Reimbursable total amount" in the reconstructed expense details. For example, the invoice amount of 1320 yuan matches the airfare of 1320 yuan (the rescheduling fee may be paid directly by the company to the TMC without the employee having to pay it in advance, so it is not included in this reimbursement).

[0092] Transaction authenticity verification: Check whether the seller_name on the invoice matches the order service provider (TMC) to prevent fake invoices.

[0093] Policy compliance verification: The rules engine is called to check the employee's travel policy and whether the cabin class and hotel class in Data_BK exceed the limit, and whether the reason for the change fee in Data_CHG meets the fee waiver policy.

[0094] Verification result processing: If all passes: The system will automatically generate a reimbursement sub-hash H. s5 H s5 =SHA256(H m ||H s4||“EXP”||T5||Data_EXP), where Data_EXP contains information such as the expense report number, the final reimbursement amount, and the approval status. H s5 Uploading the expense reimbursement to the blockchain signifies that this step has been reliably "welded" to the end of the hash chain. The reimbursement process then automatically proceeds to the next approval stage.

[0095] If any step fails, the process is immediately halted. The system sends a precise alert to the employee via the application layer front-end and message notifications (email / DingTalk / WeChat Work), such as "Invoice amount does not match order payment amount, please verify," and simultaneously notifies the finance administrator. Expense reimbursement cannot be submitted until the problem is resolved.

[0096] 5. Audit traceability and archiving The system’s value is perfectly demonstrated when required by internal audits or external verifications.

[0097] Second-level traceability: Auditors input the employee's ID, order number, or time period into the audit platform. The backend service initiates a query to the consortium blockchain network. Due to the hash chain's index structure, the system does not need to scan the entire chain of data and can quickly locate the relevant hash. m Once H is obtained m By traversing the chain related to H m All associated sub-hash transactions (H) s1 To H s5 ), and you can get the complete process index instantly.

[0098] Visual Presentation: Based on the acquired hash sequence, the system retrieves complete stage data (Data_BK, Data_PY, ...) from off-chain storage or node caches. This data is then displayed on the audit platform interface as a timeline graph or a structured details page. Auditors can clearly see: when the reservation was made, how much was paid, when and why the reservation was changed, how much was incurred, when and which invoice was issued, and when reimbursement was applied for and approved. All data is interconnected and mutually corroborating.

[0099] Trustworthy Verification: Auditors can conduct random checks on any step at any time. The system provides a "one-click verification" function, which recalculates the hash value using existing data and compares it with the hash stored on the blockchain. If they match perfectly, it proves that the data in that step has never been tampered with since being uploaded to the blockchain, and the audit conclusion has extremely high credibility.

[0100] Process archiving: After order reimbursement is completed and the dispute period has passed, the system can automatically or manually trigger the archiving process to generate an archive sub-hash H. s `_final` stores the final state of the entire hash chain. The storage address indexes of all related electronic vouchers (itinerary slips, invoice images, approval forms) are also associated with this hash chain, ensuring long-term traceability.

[0101] Through the above specific embodiments, the present invention achieves: End-to-end trusted traceability: Based on the nested binding of master-child hash chains, it realizes the complete and tamper-proof record of travel data from birth to death, improving the traceability efficiency from "days" to "seconds".

[0102] Deep intelligent linkage: Through event listening and rule engine, it realizes automatic generation and updating of consumption details, real-time synchronization of financial system, and automatic interception and early warning in the process of reimbursement, which greatly moves the risk control node forward.

[0103] The "three-in-one" closed-loop risk control system creatively integrates orders, payments, and invoices through a hash chain and performs mandatory verification through automated rules, fundamentally eliminating risks such as data inconsistency, fake invoices, and duplicate reimbursements.

[0104] Loosely coupled integration and high adaptability: Through standardized interfaces and middleware design, the system can be flexibly integrated into the existing IT architecture of an enterprise like "Lego bricks" without the need for overhaul and reconstruction, which greatly reduces deployment costs and technical barriers, enabling this advanced travel management model to take root quickly in various organizations.

[0105] In some embodiments, the end-to-end data processing system for travel orders may include multiple functional modules composed of computer program segments. The computer programs for each program segment in the end-to-end data processing system for travel orders may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) Functionality for full-process data processing of travel orders.

[0106] In this embodiment, the end-to-end data processing system for travel orders can be divided into multiple functional modules based on the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0107] The generation module is used to generate a unique master hash identifier for travel orders and upload it to the blockchain network; The association module is used to construct sub-hash identifiers associated with the main hash identifier on the blockchain network for multiple business links in the life cycle of the travel order, forming a main-sub-hash chain; wherein, when constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the link data of the current business link, and the sub-hash identifier generated by the immediately preceding business link, so that the sub-hash identifiers are nested and bound in sequence. The synchronization module is used to dynamically generate and synchronize the consumption details associated with the order based on the process data recorded in the master-child hash chain.

[0108] Figure 3 The end-to-end data processing method for travel orders provided in this application embodiment can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0109] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0110] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0111] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0112] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0113] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0114] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0115] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0116] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

[0117] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0119] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for end-to-end data processing of travel orders, characterized in that, include: Generate a unique master hash identifier for the travel booking and upload it to the blockchain network; For multiple business stages in the lifecycle of the travel order, sub-hash identifiers associated with the main hash identifier are sequentially constructed on the blockchain network to form a main-sub-hash chain. When constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the stage data of the current business stage, and the sub-hash identifier generated by the immediately preceding business stage, so that each sub-hash identifier is nested and bound in sequence. Based on the process data recorded in the master-child hash chain, consumption details associated with the order are dynamically generated and synchronized.

2. The method according to claim 1, characterized in that, Generate a unique master hash identifier for the travel booking and upload it to the blockchain network, including: The order's unique identifier, creation timestamp, traveler identifier, and business type identifier are concatenated to form the first input data; The first input data is calculated using a cryptographic hash algorithm to generate the master hash identifier; The master hash identifier is distributed to multiple participating nodes that make up the blockchain network for storage, wherein the participating nodes include at least enterprise nodes and travel service provider nodes.

3. The method according to claim 1, characterized in that, For each business stage in the lifecycle of the aforementioned travel order, sub-hash identifiers associated with the main hash identifier are sequentially constructed on the blockchain network, including: For the first business step, the main hash identifier, a preset initial vector, the step data of the first business step, the type identifier of the first business step, and the first timestamp are concatenated to form the second input data; the second input data is calculated using a cryptographic hash algorithm to generate the first sub-hash identifier; For any current business step after the first business step, the main hash identifier, the sub-hash identifier generated by the immediately preceding business step, the step data of the current business step, the type identifier of the current business step, and the current timestamp are concatenated to form the current input data; the encrypted hash algorithm is used to calculate the current input data to generate the current sub-hash identifier corresponding to the current business step; The generated sub-hash identifiers are distributed to the participating nodes of the blockchain network for storage.

4. The method according to claim 3, characterized in that, Multiple business processes include the booking, payment, change, invoice acquisition, and reimbursement stages in the business travel order lifecycle.

5. The method according to claim 4, characterized in that, The method further includes: The system obtains raw data for the current business process in real time from the corresponding external business systems through a standardized application programming interface (API). Specifically, the raw data for the booking process is obtained from the travel management (TMC) platform or the enterprise office automation (OA) system; the raw data for the payment process is obtained from the payment institution system; and the raw data for the invoice acquisition process is obtained from the invoice management system. The acquired raw data is serialized into a standardized structured data string according to a preset data structure rule, which serves as the stage data; wherein, the serialization includes organizing the data fields into key-value pairs and concatenating them in a predetermined order.

6. The method according to claim 5, characterized in that, The preset data structure rules include: Organize the key fields of the original data into key-value pairs of "field name: field value"; Sort all key-value pairs lexicographically according to their field names; The sorted key-value pairs are concatenated using a preset delimiter.

7. The method according to claim 1, characterized in that, Based on the process data recorded in the master-child hash chain, consumption details associated with the order are dynamically generated and synchronized, including: Obtain payment process data from the master-child hash chain, and generate initial consumption details records based on the payment process data; When a sub-hash identifier of a change step is added to the master-sub hash chain, the change content is extracted from the step data of the change step, and the initial consumption detail record is updated according to the change content to obtain the updated consumption detail record; If the change is a rescheduling, a rescheduling fee entry will be added to the consumption details record; if the change is a refund, the refund status and refund amount will be marked in the consumption details record. The updated consumption details will be synchronized to the company's financial system via a standardized application programming interface (API). If it is detected that the order has been submitted for reimbursement, the status of the reimbursement application is updated according to the updated consumption details record.

8. A full-process data processing system for travel orders, characterized in that, include: The generation module is used to generate a unique master hash identifier for travel orders and upload it to the blockchain network; The association module is used to construct sub-hash identifiers associated with the main hash identifier on the blockchain network for multiple business links in the life cycle of the travel order, forming a main-sub-hash chain; wherein, when constructing each sub-hash identifier, its input data includes at least: the main hash identifier, the link data of the current business link, and the sub-hash identifier generated by the immediately preceding business link, so that the sub-hash identifiers are nested and bound in sequence. The synchronization module is used to dynamically generate and synchronize the consumption details associated with the order based on the process data recorded in the master-child hash chain.

9. A full-process data processing device for travel orders, characterized in that, include: Memory, used to store the entire data processing program for travel orders; A processor, configured to implement the steps of the full-process data processing method for travel orders as described in any one of claims 1-7 when executing the full-process data processing program for the travel orders.

10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a full-process data processing program for travel orders, which, when executed by a processor, implements the steps of the full-process data processing method for travel orders as described in any one of claims 1-7.

Images