Data processing method and device for travel reservation, electronic equipment and storage medium

Abstract

The application provides a data processing method and device for travel reservation, electronic equipment and storage medium, relates to the technical field of travel data processing, and comprises the following steps: receiving travel application data sent by a terminal of a person who submits a bill, and obtaining a permission identifier associated with the person who submits the bill; determining a trigger condition for synchronizing the travel application data to a reservation system platform based on the permission identifier; when it is monitored that the trigger condition is met, sending the travel application data to the reservation system platform to generate travel information available for reservation on the reservation system platform. The application solves the technical problems that the coordination between travel approval and ticket reservation is poor, and it is difficult to balance emergency travel and compliance control in the prior art, and improves the flexibility and compliance of travel management.

Description

Technical Field

[0001] This application relates to the field of travel data processing technology, and in particular to a data processing method, apparatus, electronic device and storage medium for travel booking. Background Technology

[0002] In corporate travel management, employees need to book air and train tickets for business trips. Existing expense control systems typically employ either a strong or weak control model: a strong control model requires travel application form approval before booking, which can easily delay trips in emergency situations; a weak control model allows bookings without application forms, ensuring timeliness but lacking compliance constraints, making it prone to fraudulent bookings. Neither of these models can effectively balance travel efficiency and compliance control, making it difficult to meet the diverse travel needs of enterprises. Summary of the Invention

[0003] The purpose of this application is to provide a data processing method, apparatus, electronic device, and storage medium for travel booking, so as to alleviate the aforementioned technical problems existing in the prior art.

[0004] In a first aspect, the present invention provides a data processing method for travel booking, applied to a travel management system, the method comprising: Receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder; Based on the permission identifier, determine the trigger conditions for synchronizing the travel application data to the booking system platform; When the triggering conditions are detected, the travel application data is sent to the booking system platform to generate bookable itinerary information on the booking system platform.

[0005] In an optional implementation, receiving travel application data sent by the bill of lading holder's terminal and obtaining the permission identifier associated with the bill of lading holder includes: Receive travel application data sent by the bill of lading holder's terminal, and parse the bill of lading holder's identity information in the travel application data; Based on the identity information of the bill of lading holder, query the preset permission configuration list to determine whether the bill of lading holder is configured as a preset job level role; If the bill of lading holder is configured with the preset job level role, an authorization identifier representing the holder's flexible booking eligibility is generated.

[0006] In an optional implementation, when the triggering condition is detected, the travel application data is sent to the booking system platform, including: When the triggering condition is detected, the travel application data is encapsulated to generate a synchronization request instruction containing signature information; The synchronization request instruction is sent to the reservation system platform, and the reception status returned by the reservation system platform is monitored; If the received status indicates that synchronization has failed, the synchronization request instruction will be resent according to the preset retry policy until synchronization is successful or the maximum number of retries is reached.

[0007] In an optional implementation, after sending the travel request data to the booking system platform, the method further includes: Monitor the approval process of the travel application data in the approval system; If the approval process status is updated to "approval rejected", a trip processing prompt instruction is generated and sent to the bill of lading holder's terminal to prompt the bill of lading holder's terminal to cancel or modify the reservation order generated based on the travel application data.

[0008] In an optional implementation, after prompting the bill of lading holder terminal to cancel or modify the booking order generated based on the travel application data, the method further includes: Obtain the operation instructions from the bill of lading holder's terminal in response to the reservation order; If the operation instruction indicates that the cancellation operation is not performed within the specified time, a violation warning message is generated and sent to the management terminal for display.

[0009] In an optional implementation, after sending the travel request data to the booking system platform, and after the booking system platform generates bookable itinerary information, the method further includes: Obtain the order settlement data generated by the reservation system platform, and extract the application form association number from the order settlement data; Based on the application form's associated number, retrieve the corresponding approval process status in the approval system; The approval process status is added to the order settlement data to generate and display a reconciliation list containing the approval progress.

[0010] In an optional implementation, based on the permission identifier, the triggering conditions for synchronizing the travel application data to the booking system platform are determined, including: If the permission identifier indicates that the travel application data is eligible for flexible ticket booking, then the submission completion time of the travel application data will be determined as the triggering condition. If the permission identifier indicates that the travel application data does not qualify for flexible ticket booking, then the approval time of the travel application data will be determined as the triggering condition.

[0011] Secondly, the present invention provides a data processing apparatus for travel booking, applied to a travel management system, the apparatus comprising: The data receiving module is used to receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder; The condition determination module is used to determine the triggering conditions for synchronizing the travel application data to the booking system platform based on the permission identifier; The data synchronization module is used to send the travel application data to the booking system platform when the triggering condition is detected, so as to generate booking-available itinerary information on the booking system platform.

[0012] Thirdly, the present invention provides an electronic device including a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method described in any of the foregoing embodiments.

[0013] Fourthly, the present invention provides a computer-readable storage medium storing computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the method described in any of the foregoing embodiments.

[0014] The data processing method, apparatus, electronic device, and storage medium for travel booking provided in this application receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder. This enables the system to quickly identify whether the bill of lading holder has flexible booking eligibility based on pre-configured role permission information, solving the problem of permission abuse caused by the lack of dedicated role control in existing technologies. Based on this permission identifier, the triggering conditions for synchronizing travel application data to the booking system platform are determined, allowing different roles of bill of lading holders to have different synchronization times—those with flexible booking eligibility can synchronize their itinerary immediately after application submission, while ordinary personnel synchronize after approval, balancing the timeliness requirements of urgent travel with the need for cost compliance control. When the triggering conditions are detected, the travel application data is sent to the booking system platform and bookable itinerary information is generated, realizing the automatic flow of application data to the booking system and providing a data foundation for subsequent ticket booking, approval linkage, and reconciliation collaboration. Overall, this application solves the technical problems of poor coordination between travel approval and ticketing, and difficulty in balancing emergency travel and compliance control in existing technologies through a differentiated synchronization mechanism driven by permission identifiers, thereby improving the flexibility and compliance of travel management. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a data processing method for travel booking provided in this application embodiment; Figure 2 A flowchart illustrating another data processing method for travel booking provided in this application embodiment; Figure 3 A structural diagram of a data processing apparatus for travel booking provided in an embodiment of this application; Figure 4 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0018] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0019] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0020] This application provides a data processing method for travel booking, applied to a travel management system. In a corporate travel management scenario, employees need to submit travel applications for business trips, which must be approved before booking air tickets, train tickets, and other transportation. However, in urgent business trips, waiting for approval may delay travel. This method introduces a differentiated synchronization strategy based on permission identifiers, enabling some personnel with flexible booking qualifications to synchronize their itineraries to the booking system platform immediately after submitting their applications, thus balancing travel timeliness and compliance control. See also... Figure 1As shown, the method mainly includes the following steps.

[0021] S110, receive travel application data sent by the bill of lading holder's terminal, and obtain the permission identifier associated with the bill of lading holder.

[0022] Travel application data refers to the content of the electronic application form submitted by the bill of lading holder (i.e., the travel applicant) through the travel management system. This data includes at least the bill of lading holder's identity information (such as name, employee ID, and department), travel details (travel time, destination, mode of transport, and accompanying persons), reason for the trip, and budget amount. The access identifier is a tag associated with the bill of lading holder, used to indicate whether the bill of lading holder enjoys special operational permissions different from ordinary users in the travel booking process.

[0023] In practice, the bill of lading holder logs into the travel management system via their terminal device (such as a computer or mobile phone), fills out a travel application form, and submits it. Upon receiving the application data, the system first verifies its integrity, confirming that all necessary fields are filled in and formatted correctly. Subsequently, the system extracts the bill of lading holder's identity information from the application data and queries a pre-configured permission list based on this information. This permission list records the list of employees within the company who have been granted specific roles and their corresponding permission scopes. If the bill of lading holder is configured with a preset job level role (e.g., "flexible booking role"), the system generates a permission identifier indicating eligibility for flexible booking; if the bill of lading holder has not been granted this role, the permission identifier indicates that they do not have flexible booking eligibility. This permission identifier is used in subsequent steps to determine the triggering time for itinerary synchronization.

[0024] S120, Based on the permission identifier, determine the triggering conditions for synchronizing the travel application data to the booking system platform.

[0025] A booking system platform refers to an external business travel booking system (such as a booking system platform) that interfaces with a travel management system, enabling the person making the order to actually complete the booking of travel documents such as air tickets, train tickets, and hotels. Triggering conditions refer to the preconditions that must be met before the travel application data is sent to the booking system platform—in other words, the system will not synchronize the application data at any given time, but will only perform the synchronization operation after a specific event occurs.

[0026] In practice, the system determines the appropriate permissions based on the identifier obtained in step S110. If the identifier indicates that the bill of lading holder is eligible for flexible booking, the system uses the completion time of the travel application data submission as the trigger condition. This means that once the bill of lading holder submits the application, the system is ready to synchronize the itinerary data to the booking system platform without waiting for approval. If the identifier indicates that the bill of lading holder is not eligible for flexible booking, the system uses the approval time of the travel application data as the trigger condition; that is, the system will only perform the itinerary synchronization operation after the application is approved by the reviewer. Through these differentiated trigger condition settings, the system achieves both authorization and compliance constraints for those with flexible booking qualifications and for ordinary personnel.

[0027] S130, when the triggering condition is detected, the travel application data is sent to the booking system platform to generate bookable itinerary information on the booking system platform.

[0028] When the system detects that the triggering conditions defined in step S120 are met, it performs a data synchronization operation. The travel application data is encapsulated into a data format recognizable by the booking system platform and transmitted to the booking system platform via the inter-system interface. Upon receiving the data, the booking system platform generates an itinerary information (e.g., a flight search itinerary or a list of itineraries to be booked) that the bill of lading holder can use to make a booking. The bill of lading holder can then complete the actual ticket booking operation based on this itinerary information within the booking system platform.

[0029] In practice, if the trigger condition is "submission completion time," the system immediately synchronizes the itinerary after the bill of lading holder submits the application, allowing the holder to log in to the booking system platform and book tickets without waiting for approval. If the trigger condition is "approval time," the system monitors the approval process and only performs data synchronization when the approver completes the approval and the status is "approved." Only then can the bill of lading holder book tickets. During the synchronization process, the system also performs data encapsulation, API calls, result verification, and exception retries to ensure the reliability of the synchronization and the consistency of the data.

[0030] The data processing method for travel booking provided in this application introduces an access identifier to distinguish the operating permissions of different bills of lading holders, and determines differentiated itinerary synchronization triggering conditions based on the access identifier. This enables flexible authorization to specific personnel in emergency travel scenarios, allowing qualified personnel to book travel transportation as soon as the application is submitted, avoiding delays in official travel due to waiting for the approval process, while retaining compliance constraints on ordinary personnel, thus balancing travel timeliness and compliance control.

[0031] For ease of understanding, the method provided in this application will be described in detail below.

[0032] In one specific implementation, the specific way to obtain the permission identifier associated with the bill of lading holder in step S110 is as follows.

[0033] After receiving travel application data from the bill of lading holder's terminal, the system first parses the data to extract the bill of lading holder's identity information. This identity information includes, but is not limited to, fields such as name, employee ID, department, and job title. The system obtains this information by parsing specific fields in the application data; for example, it reads the name from the "Applicant" field and the employee ID from the "Employee ID" field.

[0034] Then, the system queries the preset permission configuration list based on the extracted bill of lading holder's identity information. The permission configuration list is a mapping table pre-maintained by the system administrator in the enterprise travel management system. This table records the list of employees granted specific roles and their corresponding permission scopes. In this implementation, the specific role is the "flexible booking role," and employees configured with the "flexible booking role" have the permission to synchronize their itinerary and book tickets immediately after submitting an application. The permission configuration list allows administrators to add, delete, and modify role members as needed.

[0035] If the system finds that the person holding the bill of lading is configured with a preset job level in the permission configuration list, it generates a permission identifier indicating that they are eligible for flexible ticket booking. If no matching record is found, the generated permission identifier indicates that they are not eligible for flexible ticket booking. This permission identifier is stored in the system memory as a Boolean value or an enumeration value for use in subsequent processes. Through this permission configuration list query mechanism, the system achieves precise control over the scope of personnel eligible for flexible ticket booking, preventing the abuse of permissions.

[0036] In one specific implementation, the method for sending travel application data to the booking system platform when the triggering condition is detected in step S130 is as follows.

[0037] When the system detects that the trigger conditions are met, it first encapsulates the travel application data. This encapsulation process involves organizing the core itinerary fields (bill holder information, travel time, destination, mode of transport, budget, etc.) into structured data (e.g., JSON format) according to the format requirements of the booking system platform interface. Simultaneously, the system adds a signature to the data to prevent tampering during transmission. The signature can be generated by hashing the data content and using a pre-defined key.

[0038] Then, the system sends the encapsulated synchronization request command to the booking system platform via an HTTP / HTTPS interface and monitors the reception status returned by the booking system platform. The reception status includes synchronization success (the booking system platform has successfully received and parsed the data) and synchronization failure (interface call error or data format error).

[0039] If the received status indicates that synchronization has failed, the system resends the synchronization request command according to a preset retry policy. The retry policy includes: a maximum number of retries (e.g., 3 times), a retry interval (e.g., an initial retry interval of 2 seconds, with subsequent retry intervals increasing), and retry conditions (e.g., retries are only performed for network timeouts and temporary errors returned by the server; non-temporary errors such as data format errors are not retried). If synchronization is successful within the maximum number of retries, the system records a synchronization success log; if synchronization still fails after reaching the maximum number of retries, the system generates a synchronization failure warning message and notifies the administrator for manual intervention. Simultaneously, the system sets a debouncing time window (e.g., 5 seconds) to prevent repeated sending of synchronization requests due to frequent changes in the application status.

[0040] In one specific implementation, after the travel application data is sent to the booking system platform, the system also monitors the approval flow status of the travel application data in the approval system and performs corresponding itinerary linkage processing based on the approval result.

[0041] The approval workflow status refers to the current stage of a travel application in the approval process, including "Pending Review," "Under Review," "Approved," and "Rejected." The system obtains updates to the approval workflow status by polling the approval system interface or subscribing to event notifications from the approval system.

[0042] If the system detects that the approval process status has been updated to "approval rejected," it generates a trip processing prompt. This prompt notifies the bill of lading holder that further processing is needed for the trip information already synchronized to the booking system platform. Specifically, if the bill of lading holder has already booked tickets for this trip, a refund or itinerary change is required; if no tickets have been booked, confirmation is needed regarding whether to proceed with the booking. The trip processing prompt is sent to the bill of lading holder's terminal via system message and email, clearly indicating that the application has been rejected and informing them that they should log in to the booking system platform within a specified time (e.g., 24 hours) to process a refund or itinerary change.

[0043] Through this collaborative processing mechanism for approval rejections, the system synchronizes approval results with itinerary arrangements, avoiding itinerary conflicts and financial losses caused by tickets already booked but not processed in a timely manner after approval rejection.

[0044] In one specific implementation, after prompting the bill of lading holder's terminal to cancel or modify the booking order generated based on travel application data, the system continues to monitor the bill of lading holder's subsequent actions.

[0045] The system retrieves operation instructions from the bill of lading holder's terminal regarding the booking order. These instructions include statuses such as "Order Cancelled" (refund completed), "Itinerary Changed" (travel plans modified), and "Pending" (no operation yet performed). The system also records the execution time and details of each operation, creating an operation log.

[0046] If the system does not detect any cancellation or modification operations performed by the bill of lading holder within a preset timeframe (e.g., 24 hours), it determines that the bill of lading holder has failed to fulfill its processing obligations within the stipulated time, and the system generates a violation warning. This violation warning includes key fields such as the bill of lading holder's information, application number, order information, and number of overdue days, and is sent to the management terminal for display, allowing administrators to intervene promptly. Simultaneously, the system records this violation in the bill of lading holder's operational behavior database as a reference for subsequent permission adjustments or compliance audits.

[0047] In one specific implementation, after the travel application data is sent to the booking system platform and the booking system platform generates bookable itinerary information, the system also involves the linkage processing of the reconciliation and settlement process.

[0048] The system retrieves order settlement data generated by the booking system platform. Order settlement data refers to the billing record generated by the booking system platform after the bill of lading holder completes the actual ticket booking operation, containing information such as order amount, travel mode, and booking time. The system extracts the application form association number from this settlement data. This association number is a unique identifier generated by the system in step S110, used to associate the ticket booking order with the travel application form.

[0049] Based on the extracted application form association number, the system retrieves the corresponding approval workflow status (i.e., the current approval progress of the application form) in the approval system. Then, the system adds the retrieved approval workflow status to the order settlement data, generating a reconciliation list containing the approval progress. When processing reconciliation, finance personnel can directly see the approval status (approved / under review / rejected) of each travel application form corresponding to a ticket order in the reconciliation list, without needing to switch system pages to view application form details. This allows them to determine whether the reconciliation and settlement process can proceed normally, thereby improving the efficiency of financial reconciliation.

[0050] In one specific implementation, the specific way to determine the triggering condition based on the permission identifier in step S120 is as follows.

[0051] The system determines the content represented by the permission identifier. If the permission identifier indicates that the bill of lading holder has the qualification for flexible booking, the system determines the completion time of the travel application data submission as the trigger condition. This means that after the bill of lading holder clicks the submit application button, the system completes data verification and generates an application number, the system immediately prepares to execute the itinerary synchronization operation. This mode is suitable for urgent business trip scenarios, allowing the bill of lading holder to book travel transportation without waiting for the approval process.

[0052] If the permission identifier indicates that the bill of lading holder does not have flexible booking eligibility, the system will use the approval time of the travel application data as the trigger condition. In this mode, the system will continuously monitor the status of the approval system, and will only execute the itinerary synchronization operation when the approver completes the approval and the approval status is "approved". The bill of lading holder can only log in to the booking system platform to book tickets after the approval is approved. This mode is suitable for ordinary business travel scenarios, ensuring that compliance control takes precedence over travel timeliness.

[0053] The logic for determining the two triggering conditions mentioned above can also be summarized as follows: roles with flexible ticket booking eligibility correspond to the "submission and synchronization" mode, while roles without flexible ticket booking eligibility correspond to the "approval and synchronization" mode.

[0054] The following is combined with Figure 2 The flowchart shown in one embodiment of the present application illustrates the intelligent linkage management method for travel booking and ticketing, and provides a complete description of the technical solution of the present application. Figure 2 The document illustrates six core steps from system initialization to full-process exception handling, and each step is described in detail below.

[0055] S1, Initialize system configuration and role permissions.

[0056] The system receives and initializes basic information such as travel application form management, role permissions, and itinerary synchronization rules, providing basic support for subsequent itinerary synchronization, ticket booking control, and approval linkage.

[0057] In implementation, the system first adds a "Flexible Ticketing Role" to the access control module. This role distinguishes the personnel eligible for the "submit an application and book tickets immediately" mode. Companies can assign roles to employees based on job level, position, and other factors. The system configures differentiated access permissions for different roles: the "Flexible Ticketing Role" only has the permission to "synchronize itinerary and book tickets after application submission"; ordinary roles can only choose "synchronize itinerary and book tickets after application approval"; administrators have full permissions, including role assignment, permission modification, and exception handling; and finance personnel have permissions such as reconciliation and settlement, and application status inquiry. After configuration, the system associates roles with employee information, automatically identifying the employee's role and matching the corresponding itinerary synchronization and ticketing permissions.

[0058] The system simultaneously initializes the itinerary synchronization rules. Two synchronization timings are preset: "synchronization after application submission" and "synchronization after application approval," clearly defining the applicable roles and operational logic for each timing. Synchronization interface parameter configurations include request method (POST), parameter format (JSON), signature mechanism, timeout (default 30 seconds), and number of retries (default 3). The itinerary data synchronized to the booking system platform includes core information such as the person submitting the order, travel time, destination, mode of transport, and budget, ensuring the completeness of data required for ticket booking.

[0059] In addition, the system has completed interface testing with the reservation system platform and approval system to ensure smooth data transmission. A dedicated database uses AES-256 encryption technology to encrypt and store sensitive data such as employee information and ticketing information. Anomaly warning configurations include: a threshold for the number of failed itinerary synchronization attempts (default ≥1 attempt triggers a warning), and a threshold for the time after approval rejection without processing refunds (default ≥24 hours triggers a warning). Warnings are sent via system messages, emails, and SMS, and recipients include administrators, finance liaisons, and the person issuing the order.

[0060] S2, select the timing for schedule synchronization.

[0061] When the bill of lading holder submits a travel application, they can select the timing for synchronizing the itinerary plan to the booking system platform on the system interface. The system records the selection result and triggers the corresponding synchronization logic.

[0062] Specifically, the bill of lading holder enters travel application information through the system interface, including the bill of lading holder's information, travel details (travel time, destination, mode of transport, accompanying persons), reason for travel, and budget amount. The system performs a preliminary check on the entered information—checking the completeness of the information (confirming no missing required fields) and the correctness of the format (e.g., date format is "YYYY-MM-DD HH:MM:SS"). If the check fails, the bill of lading holder is prompted to modify and resubmit. After successful check, the system generates a unique travel application number, which is used for subsequent itinerary synchronization, approval, and reconciliation tracking.

[0063] Subsequently, the system displays the available synchronization timings based on the bill of lading holder's role: "Flexible Booking Roles" can choose "Synchronize after application submission" or "Synchronize after application approval"; ordinary roles can only choose "Synchronize after application approval." After the bill of lading holder makes a selection, the system displays a confirmation prompt, clarifying the corresponding operational rules for the synchronization timing (e.g., "Synchronize after application submission; if approval is rejected, a refund must be processed promptly"). After the bill of lading holder confirms, the system records the selected synchronization timing and its selection time, stores it in association with the application number, synchronously updates the application status to "Pending Submission / Submitted (Pending Review)," and triggers subsequent itinerary synchronization logic.

[0064] S3, itinerary planning and ticket booking.

[0065] Based on the selected synchronization timing, the system uses a trip synchronization control algorithm that combines role permissions with the synchronization timing to synchronize the trip plan to the booking system platform. Eligible bill holders can book airline or train tickets through the booking system platform before or after the application is approved.

[0066] In its implementation, the system extracts the bill of lading holder's role information, permission configuration, selected synchronization timing, and the submission and approval status of the application form from the database. First, it performs permission verification—determining whether the bill of lading holder's role has the necessary permissions for the corresponding synchronization timing: if the "flexible booking role" selects "synchronize after application submission," the permission verification passes; if a regular role selects "synchronize after application submission," the permission verification fails, and the algorithm outputs "cannot synchronize" and prompts "no corresponding permission." Simultaneously, it performs application form status verification—determining whether the application form has been submitted; if not submitted, it outputs "cannot synchronize" and prompts "please submit the travel application form first."

[0067] After permission and status verifications pass, the system executes the trigger judgment based on the selected synchronization timing. If "Synchronize after application submission" is selected, the system immediately triggers the itinerary synchronization command after successful application submission, generating synchronized data including the application number, bill of lading information, and travel details. If "Synchronize after application approval" is selected, the system continuously monitors the approval status. When the approval status updates to "Approved," the itinerary synchronization command is triggered; if the approval status is "Pending review" or "Under review," it is not triggered; if it is "Rejected," "Cannot synchronize" is output, and the message "Application has been rejected, please modify and resubmit" is displayed. The system also has a debouncing time (default 5 seconds) to avoid multiple triggers of the synchronization command due to frequent changes in application status.

[0068] Upon synchronization triggering, the system encapsulates the core itinerary data of the application form into JSON-formatted synchronization request data according to the requirements of the booking system platform interface. A data signature is added to ensure secure transmission, and the data is then pushed to the booking system platform via the interface, with real-time synchronization progress recorded. The system receives the synchronization response from the booking system platform—if the response is "successful," the system generates a "bookable" flag, and the booking system platform synchronously displays the itinerary plan and allows the applicant to book tickets; if the response is "failed," the system records the reason for the failure (such as interface timeout or incorrect data format) and triggers a retry mechanism (retrying a preset number of times). If the retry still fails, an alert is sent to the administrator and the applicant.

[0069] After successful synchronization, the system assigns temporary booking permissions based on the bill of lading holder's role and the timing of the synchronization. The validity period of these permissions is the same as the validity period of the application form (7 days by default from the date of application submission). When the bill of lading holder books tickets through the booking system platform, the system automatically associates the application form number, records the booking information (order number, mode of transport, amount, booking time), and stores it in conjunction with the application form data. If the application form is rejected, expires, or the trip has been completed, the system automatically revokes the bill of lading holder's booking permissions, and booking operations based on that application form will no longer be permitted.

[0070] In addition, the system records the results of each trip synchronization (synchronization success rate, permission verification accuracy, and failure reason) and the bill of lading holder's operation behavior (synchronization timing selection, ticket booking frequency, and ticket refund frequency). Through reinforcement learning algorithms, it continuously optimizes parameters such as synchronization timing trigger logic, debouncing time, and retry count. Abnormal synchronization data is added to the training dataset, and the algorithm model is retrained regularly (monthly by default) to improve the accuracy and efficiency of trip synchronization.

[0071] S4, Application approval and rejection processing.

[0072] The reviewer approves the travel application form, and the system executes the corresponding operation based on the approval result (approved or rejected), realizing the linkage control between approval and itinerary.

[0073] After the application is submitted, the system automatically forwards it to the corresponding reviewer (according to the company's approval process). The reviewer can view the application details, itinerary synchronization status, and ticketing status (if tickets have been booked). Based on the company's travel management regulations, the reviewer can select "Approved" or "Rejected" and fill in their review comments (e.g., rejection reason "unreasonable travel time" or "budget exceeded"). The system updates the application approval status in real time and simultaneously pushes approval result notifications to the submitter (system message, email), clearly stating the approval comments and subsequent operational requirements.

[0074] If the application is approved, the system maintains the itinerary synchronization status, and the person making the order can continue to complete the ticket booking process (if no tickets have been booked yet) or travel normally according to the booked itinerary. The system will synchronize the approval status to the booking system platform and the reconciliation module to support subsequent reconciliation and settlement, and record the approval information (reviewer, review time, review comments), which will be stored in association with the application and ticket booking data.

[0075] If the application is rejected, the system will send a rejection notification to the bill of lading holder, specifying the reason for rejection and the processing requirements. The bill of lading holder should take the appropriate action based on the rejection scenario: In the event of a trip cancellation, the bill of lading holder must process the refund through the booking system platform within a specified time (default 24 hours). Upon completion of the refund, the system records the refund information (refund time, refund amount, and reason for refund) and updates the application status to "Rejected - Trip Cancelled". If the refund is not processed within the specified time, the system will send an alert to both the bill of lading holder and the administrator, reminding them to handle the matter promptly.

[0076] In cases of itinerary changes, the bill of lading holder does not need to resubmit an application. They can modify the travel details (such as adjusting travel dates or destinations) on the original travel application form and then resubmit for approval. The system will automatically trigger a new itinerary synchronization logic (executed at the originally selected synchronization time), synchronously updating the itinerary plan on the booking system platform. If tickets have already been booked, the bill of lading holder must first process a refund and then rebook.

[0077] After the bill of lading holder completes the refund or itinerary change, they resubmit the application form, and the system re-executes the verification, synchronization, and approval process to ensure a closed loop.

[0078] S5, linked to reconciliation and settlement.

[0079] The system has added an "Application Status" field to the statement list, enabling real-time linkage between the statement and the application approval status, thereby improving the efficiency of reconciliation and settlement.

[0080] Specifically, a "Application Status" field has been added to the statement list (categorized by flight, hotel, train, etc.) on the booking system platform. The field options include "Under Review," "Approved," and "Rejected." The system synchronizes the approval status of travel applications in real time, associating the application status with the corresponding ticket order and automatically updating the application status field in the statement, eliminating the need for manual updates. Each ticket order corresponds to a unique application number. Finance personnel can quickly jump to the corresponding travel application details page by clicking on the "Application Status" in the statement to view the application details, approval records, and itinerary synchronization records.

[0081] Finance staff process reconciliations based on the application status: When the status is "Approved," finance staff proceed with the reconciliation and settlement process normally, verifying the ticket amount against the application budget before completing the settlement; when the status is "Under Review," finance staff proactively contact the bill of lading holder to urge superiors to complete the review as soon as possible, and the system records the urging record (urging time, urging method); when the status is "Rejected," finance staff contact the bill of lading holder to verify the reason for rejection, confirming whether to resubmit the application or process a refund. If a refund has been processed, the refund amount is verified and the reconciliation data is adjusted; if a resubmitted application is processed, the settlement is initiated only after approval.

[0082] If the application status in the reconciliation statement is inconsistent with the actual approval status, the system will automatically trigger an alert, prompting finance personnel and administrators to investigate data synchronization issues. If abnormal situations such as "rejected but not refunded" or "approved but no corresponding booking record" occur, the system will push an alert specifying the abnormal details, allowing finance personnel and administrators to collaborate and ensure the accuracy of the reconciliation data.

[0083] S6, full-process exception handling.

[0084] The system establishes an anomaly handling mechanism covering the entire process of itinerary synchronization, ticketing, approval, and reconciliation, achieving integrated anomaly warning, processing, and archiving to ensure smooth process operation.

[0085] The system clearly identifies various abnormal scenarios, including itinerary synchronization failure, permission verification failure, approval and booking conflicts (such as rejection without refund), inconsistent reconciliation data, expired and unprocessed application forms, and booking failures. For different types of anomalies, the system pushes alerts according to preset methods, specifying the anomaly details (application form number, anomaly type, anomaly reason), handling suggestions, and handling time limits, ensuring that relevant personnel are aware of and can handle the issues in a timely manner.

[0086] Administrators, finance personnel, and bill of lading holders collaborate to handle anomalies based on the anomaly type and suggested handling methods. For example, synchronization failures require checking the interface and data; unrefunded tickets after approval rejections require urging the bill of lading holder to process refunds; reconciliation anomalies require verifying the application form and booking data. After processing, the system automatically updates the anomaly status and records the results.

[0087] All anomalies, processing procedures, and results are automatically archived, generating an anomaly handling ledger that supports filtering and querying by anomaly type, processing status, and time range. Administrators periodically (monthly by default) analyze the anomaly data to investigate the causes of high-frequency anomalies (such as unstable interfaces or non-standard bill of lading operations), optimize system configuration and algorithm parameters, and reduce the anomaly incidence rate.

[0088] Through the complete process of steps S1 to S6 above, this embodiment realizes integrated management and control from system initialization, trip synchronization timing selection, trip synchronization and ticketing, approval and rejection processing, reconciliation and settlement linkage to full-process abnormal handling, effectively solving the conflict between the timeliness of emergency travel and compliance management in corporate travel management.

[0089] The technical solution of this application will be fully explained below with reference to a specific application scenario.

[0090] A large enterprise group adopted the travel booking data processing method described in this application. The company pre-configured its travel management system. The administrator added a "Flexible Ticketing Role" to the permission configuration list, assigned this role to employees at level B and above, and configured the corresponding permission scope for this role—namely, "synchronize itinerary and book tickets after application submission." Simultaneously, the system configured itinerary synchronization interface parameters, timeout (default 30 seconds), number of retries (default 3), and debouncing time (default 5 seconds). The interface between the booking system platform and the travel management system has been successfully integrated, and data transmission is smooth.

[0091] Mr. Zhang, an employee of the company (a Class B employee), needed to travel to Shanghai for business the following morning due to an urgent client request. Mr. Zhang logged into the travel management system, entered a travel application form, and filled in the travel time (8:00 AM flight the following day), destination (Shanghai), mode of transportation (airplane), and budget. After submitting the application, the system received the application data, extracted Mr. Zhang's identity information, checked the permission configuration list, confirmed that Mr. Zhang belonged to the "flexible booking role," and generated a permission identifier that granted him flexible booking eligibility. Based on this permission identifier, the system determined the trigger condition as the "time of application form submission completion."

[0092] Since the trigger condition is the submission completion time, the system immediately performs the itinerary synchronization operation after Mr. Zhang submits his application. The system encapsulates the travel application data into a JSON-formatted synchronization request, adds a signature, and sends it to the booking system platform interface via POST. The booking system platform receives and parses the synchronized data, generates a pending booking itinerary record, and returns a "synchronization successful" status to the travel management system. Mr. Zhang then logs into the booking system platform and completes the flight booking based on this itinerary record, ensuring the timeliness of his business trip the following day. The system also associates and stores Mr. Zhang's booking information with the application number.

[0093] After Zhang's travel application was submitted, it was automatically forwarded to his supervisor, Manager Li, for approval. During the approval process, Manager Li found that Zhang's description of the reason for the trip was incomplete, selected "Reject" on the application, and filled in the rejection comment: "Please provide a detailed explanation of the reason for the trip." The system detected the change in approval status to "Rejected" and immediately generated a trip processing prompt, sending it to Zhang's terminal via system message and email, indicating: "Your travel application has been rejected. If you have already booked tickets, please log in to the booking system platform within 24 hours to process the refund." Upon receiving the notification, Zhang logged into the booking system platform as instructed, canceled the booked flight order, and completed the refund process. The system recorded the refund information (refund time, refund amount) and updated the application status to "Rejected - Trip Cancelled." Zhang modified the application and resubmitted it, and the system re-executed the verification and synchronization process.

[0094] At the end of the month, finance staff log into the booking system platform to view the reconciliation statement list. The system has added a "Request Status" field to the statement list, which synchronizes the approval status of travel requests in real time. Finance staff check each pending settlement order and find that the request status for one order is "Under Review." Therefore, they temporarily suspend settlement for that order and contact the bill of lading holder to urge their supervisor to complete the approval as soon as possible. The request status for another order is "Approved." After confirming that the booking amount matches the budget in the request, the finance staff completes the settlement. Throughout the entire reconciliation process, finance staff do not need to switch to the approval system to check the request status, significantly improving reconciliation efficiency.

[0095] In a historical order, the system detected that the corresponding application form was in the "rejected" status, but the order itself was still in the "not refunded" status. The system automatically pushed a violation warning to the finance personnel and administrator terminals, prompting, "The application form has been rejected but the refund has not been processed within the specified time. Please handle this promptly." The administrator contacted the bill of lading holder to verify the situation. After the bill of lading holder completed the refund operation, the system updated the order status, and the finance personnel completed the subsequent reconciliation processing. The entire process of this anomaly, from occurrence to resolution, was recorded and archived by the system, forming an anomaly handling log for administrators to periodically analyze the causes of high-frequency anomalies.

[0096] As can be seen from the above embodiments, this application achieves intelligent linkage management of travel applications and business travel bookings through core steps such as determining differentiated itinerary synchronization trigger conditions based on permission identifiers, encapsulation and retransmission mechanisms for synchronization requests, linked processing after approval rejection, violation warnings for unprocessed ticket refunds, and real-time linkage between reconciliation lists and application approval status. This balances the timeliness of urgent business trips with compliance-based cost control, significantly improving the overall efficiency of corporate travel management. Among these, the core elements—flexible booking control based on role-based permissions, itinerary synchronization control based on permission identifiers and synchronization timing, linked processing of approval and booking, and real-time linkage between reconciliation settlement and approval status—constitute a complete end-to-end solution.

[0097] Based on the above method embodiments, this application also provides a data processing device for travel booking, applied to a travel management system. See [link to relevant documentation]. Figure 3 As shown, the device includes: The data receiving module 310 is used to receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder; The condition determination module 320 is used to determine the triggering conditions for synchronizing the travel application data to the booking system platform based on the permission identifier; The data synchronization module 330 is used to send the travel application data to the booking system platform when the triggering condition is detected, so as to generate booking-available itinerary information on the booking system platform.

[0098] The device provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts of the device embodiment not mentioned can be referred to the corresponding content in the aforementioned method embodiment.

[0099] This application also provides an electronic device, such as... Figure 4 The diagram shows the structure of the electronic device 100, which includes a processor 41 and a memory 40. The memory 40 stores computer-executable instructions that can be executed by the processor 41. The processor 41 executes the computer-executable instructions to implement any of the methods described above.

[0100] exist Figure 4 In the illustrated embodiment, the electronic device further includes a bus 42 and a communication interface 43, wherein the processor 41, the communication interface 43, and the memory 40 are connected via the bus 42.

[0101] The memory 40 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 43 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc. The bus 42 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 42 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0102] Processor 41 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of processor 41 or by instructions in software form. Processor 41 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in the memory, and the processor 41 reads the information in the memory and, in conjunction with its hardware, completes the steps of the method described in the foregoing embodiment.

[0103] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the above-described method. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0104] The computer program products of the travel booking data processing method, apparatus, electronic device and storage medium provided in the embodiments of this application include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0105] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0106] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0107] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method for travel booking, characterized in that, Applied to a travel management system, the method includes: Receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder; Based on the permission identifier, determine the trigger conditions for synchronizing the travel application data to the booking system platform; When the triggering conditions are detected, the travel application data is sent to the booking system platform to generate bookable itinerary information on the booking system platform.

2. The method according to claim 1, characterized in that, Receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder, including: Receive travel application data sent by the bill of lading holder's terminal, and parse the bill of lading holder's identity information in the travel application data; Based on the identity information of the bill of lading holder, query the preset permission configuration list to determine whether the bill of lading holder is configured as a preset job level role; If the bill of lading holder is configured with the preset job level role, an authorization identifier representing the holder's flexible booking eligibility is generated.

3. The method according to claim 1, characterized in that, When the triggering condition is detected, the travel application data is sent to the booking system platform, including: When the triggering condition is detected, the travel application data is encapsulated to generate a synchronization request instruction containing signature information; The synchronization request instruction is sent to the reservation system platform, and the reception status returned by the reservation system platform is monitored; If the received status indicates that synchronization has failed, the synchronization request instruction will be resent according to the preset retry policy until synchronization is successful or the maximum number of retries is reached.

4. The method according to claim 1, characterized in that, After sending the travel request data to the booking system platform, the process also includes: Monitor the approval process of the travel application data in the approval system; If the approval process status is updated to "approval rejected", a trip processing prompt instruction is generated and sent to the bill of lading holder's terminal to prompt the bill of lading holder's terminal to cancel or modify the reservation order generated based on the travel application data.

5. The method according to claim 4, characterized in that, After the bill of lading holder terminal prompts the user to cancel or modify the booking order generated based on the travel application data, the system further includes: Obtain the operation instructions from the bill of lading holder's terminal in response to the reservation order; If the operation instruction indicates that the cancellation operation is not performed within the specified time, a violation warning message is generated and sent to the management terminal for display.

6. The method according to claim 1, characterized in that, After sending the travel request data to the booking system platform, and after the booking system platform generates bookable itinerary information, the process further includes: Obtain the order settlement data generated by the reservation system platform, and extract the application form association number from the order settlement data; Based on the application form's associated number, retrieve the corresponding approval process status in the approval system; The approval process status is added to the order settlement data to generate and display a reconciliation list containing the approval progress.

7. The method according to claim 1, characterized in that, Based on the permission identifier, the trigger conditions for synchronizing the travel application data to the booking system platform are determined, including: If the permission identifier indicates that the travel application data is eligible for flexible ticket booking, then the submission completion time of the travel application data will be determined as the triggering condition. If the permission identifier indicates that the travel application data does not qualify for flexible ticket booking, then the approval time of the travel application data will be determined as the triggering condition.

8. A data processing device for travel booking, characterized in that, The device, used in a travel management system, includes: The data receiving module is used to receive travel application data sent by the bill of lading holder's terminal and obtain the permission identifier associated with the bill of lading holder; The condition determination module is used to determine the triggering conditions for synchronizing the travel application data to the booking system platform based on the permission identifier; The data synchronization module is used to send the travel application data to the booking system platform when the triggering conditions are detected, so as to generate booking-available itinerary information on the booking system platform.

9. An electronic device, characterized in that, The method includes a processor and a memory, the memory storing computer-executable instructions executable by the processor, the processor executing the computer-executable instructions to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when invoked and executed by a processor, cause the processor to perform the method according to any one of claims 1 to 7.

Images