Itinerary node driven travel budget accounting method and system

Abstract

The application belongs to the technical field of data processing, and particularly relates to a trip node driven travel budget accounting method and system. The method comprises the following steps: obtaining travel task information, constructing a trip node state diagram comprising trip nodes and budget transmission edges and determining trip time constraint relationships; generating a budget token set according to the trip nodes; in response to a trip node change event, updating the trip time constraint relationships and determining node time sequence pressure, and determining a node influence domain in combination with the budget transmission edges; determining an old budget token set and a new budget demand token set according to the node influence domain; determining a migration cost and an optimal migration result according to the node time sequence pressure and attribute differences between the old budget token and the new budget demand token; migrating and updating the budget token according to the optimal migration result, and generating a travel budget accounting result through budget conservation verification. The application can limit the budget influence range corresponding to the trip change, and keep the amount relationship consistent before and after the budget migration.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a travel budget calculation method and system driven by travel nodes. Background Technology

[0002] Travel budgeting is used to record and adjust the budgeted amounts, reimbursement standards, approval limits, and accounting categories for expenses such as accommodation, meetings, and transportation during the execution of business trips. Current technology typically generates budget data based on travel application forms, expense categories, and static budget tables. When the trip's time, location, or activities change, the relevant expenses are recalculated according to the revised travel information, or the original budget data is modified item by item. This approach usually uses individual expense records as the basic unit, failing to uniformly express the temporal sequence, locational connections, and budget dependencies between travel items such as accommodation, meetings, and return trips. Therefore, it is difficult to accurately define the actual budgetary impact of a change in a travel activity.

[0003] When meetings are postponed, accommodation periods change, or return travel arrangements are adjusted, existing technologies often recalculate the entire travel task or only modify the individual expenses that have changed. The former approach will duplicate unaffected budget data in the calculation, while the latter may overlook related changes caused by time constraints, inheritance of reimbursement standards, transmission of approval limits, or derivation of accounting categories. Meanwhile, the lack of a unified representation of the original budget data, migration conditions, and amount constraints between the original budget data and the changed budget requirements easily leads to problems such as duplicate budget allocation, erroneous release, unreasonable conversion between different expense categories, and inability to verify budget amounts before and after migration. Therefore, existing methods struggle to simultaneously ensure the scope of impact, budget attribute migration, and budget amount consistency when travel time, location, or events change. Summary of the Invention

[0004] This invention provides a travel budget accounting method and system driven by itinerary nodes, which at least solves the problem of how to determine the affected budget range when itinerary nodes change, and how to complete budget migration and budget amount consistency verification under budget attribute constraints.

[0005] This invention provides a trip node-driven travel budget accounting method, which includes: acquiring travel task information, constructing a trip node state graph including trip nodes and budget transmission edges, and determining trip time constraints; generating a set of budget tokens based on the trip nodes, where each budget token represents the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item; responding to trip node change events, updating the trip time constraints and determining the node time pressure, and determining the node influence domain based on the budget transmission edges; determining the old budget token set and the new budget demand token set based on the node influence domain; determining the migration cost and optimal migration result based on the node time pressure and the attribute differences between the old and new budget demand tokens; migrating and updating the budget tokens based on the optimal migration result, and generating a travel budget accounting result after budget conservation verification.

[0006] Secondly, this invention provides a trip node-driven travel budget accounting system for implementing a trip node-driven travel budget accounting method. The system includes: a graph construction module for acquiring travel task information, constructing a trip node state graph including trip nodes and budget transmission edges, and determining trip time constraints; a token generation module for generating a set of budget tokens based on trip nodes, where each budget token represents the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item; an impact determination module for responding to trip node change events, updating trip time constraints, determining node time pressure, and determining the node impact domain based on budget transmission edges; a set determination module for determining the old budget token set and the new budget demand token set based on the node impact domain; a migration determination module for determining migration costs and the optimal migration result based on node time pressure and the attribute differences between the old and new budget demand tokens; and an accounting generation module for migrating and updating budget tokens based on the optimal migration result, and generating a travel budget accounting result after budget conservation verification.

[0007] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By organizing travel task information into a travel node state graph consisting of travel nodes and budget transmission edges, and defining travel time constraints, a unified expression is achieved for the temporal relationships, location connections, budget dependencies, reimbursement standard inheritance relationships, approval limit transmission relationships, and accounting subject derivation relationships among travel nodes. By generating budget tokens for travel nodes that represent budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting subject, budget data can participate in subsequent processing as objects with clearly defined binding relationships and status attributes.

[0008] By updating travel time constraints after a travel node change event occurs, determining node timing pressure, and combining budget propagation edges to define the node influence domain, the scope of travel nodes requiring recalculation can be limited, avoiding the duplication of irrelevant budget data. The migration cost and optimal migration result are determined by the attribute differences between the old budget token set and the new budget demand token set, ensuring that budget amounts are migrated under constraints of expense category, budget status, and accounting subject. Budget conservation verification verifies changes in budget amounts before and after migration, generating travel budget accounting results with clear sources and consistent attributes. Attached Figure Description

[0009] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is a diagram showing the state of travel nodes and the relationship between travel time constraints in an embodiment of the present invention. Figure 3 This is a matrix diagram showing the determination of node timing pressure and node influence domain in an embodiment of the present invention; Figure 4 This is a graph showing the relationship between candidate migration edges and migration costs in an embodiment of the present invention. Figure 5 This is a diagram illustrating the budget token transitions and budget conservation verification in an embodiment of the present invention. Figure 6 This is a block diagram of the module composition of the system of the present invention. Detailed Implementation

[0010] The embodiments of the present invention will be described below with reference to the accompanying drawings. These embodiments are used to illustrate the technical solutions of the present invention and are not intended to limit the scope of protection of the present invention. Those skilled in the art can make adaptive adjustments to the relevant processing order, data structure, or parameter values ​​without changing the technical concept of the present invention.

[0011] In this embodiment, itinerary nodes are used to carry travel items with independent node time, node location, and node status in travel task information. Specifically, they are generated by travel time, destination, travel item, and return arrangements. Budget dependencies, reimbursement standard inheritance relationships, approval limit transmission relationships, and accounting item derivation relationships are established between itinerary nodes through budget transmission edges. The travel budget corresponds to the budget amount occupied or required by each itinerary node, as well as its budget status, expense category, reimbursement standard, approval limit, and accounting item, and is recorded using budget tokens bound to the itinerary node. In this embodiment, the accounting attributes are a collective term for budget status, expense category, reimbursement standard, approval limit, and accounting item. The accounting process takes travel task information, itinerary node status diagram, itinerary time constraints, and budget token set as processing inputs. When a itinerary node change event occurs, the node time sequence pressure and node influence domain are determined, forming an old budget token set and a new budget demand token set. Based on this, migration cost calculation, optimal migration result determination, budget token migration, and budget conservation verification are performed to generate the travel budget accounting result.

[0012] like Figure 1 As shown, a trip node-driven travel budget accounting method includes the following processing steps.

[0013] After obtaining travel task information, itinerary nodes are generated based on travel time, destination, travel items, and return arrangements. Budget transmission edges are then generated based on temporal relationships, location connections, budget dependencies, reimbursement standard inheritance, approval limit transmission, and accounting item derivation, forming an itinerary node state graph. Minimum time intervals, maximum time intervals, and coverage relationships are determined based on the start time, end time, and validity period of each itinerary node, forming itinerary time constraints. In one embodiment, travel task information is organized around a single travel item. Travel time determines the node time of an itinerary node, destination determines the node location, travel item determines the node type, and return arrangements determine the node time and location of the return trip. For travel content with independent start times, end times, node locations, or node states, separate itinerary nodes are generated to avoid merging travel content with different budget accounting criteria into the same itinerary node.

[0014] If the travel time or destination is missing, no travel node will be generated for the corresponding travel content to be included in the budget calculation; if the return trip arrangement is not yet determined, a return trip node will be generated with the status of pending determination, and the node time and node location of the return trip node will be updated after the return trip arrangement is obtained.

[0015] After the itinerary nodes are generated, the temporal relationship is determined based on the node times. When the end time of one itinerary node is earlier than the start time of another itinerary node, the two itinerary nodes form a directional temporal relationship. When the validity periods of two itinerary nodes overlap, the travel-related matters are considered to determine whether the two itinerary nodes form an overlay relationship, and a unidirectional temporal relationship is not directly established based on the start time.

[0016] Location connectivity is determined based on the locations of adjacent travel nodes. Travel nodes with the same location form location connectivity within the same destination range; travel nodes with different locations but consecutive time intervals form location connectivity across destinations. Both temporal and location connectivity relationships jointly define the direction of budget propagation, preventing budget changes from being transmitted in directions inconsistent with the actual travel sequence.

[0017] Budget dependencies are determined based on whether the budget amount of one itinerary node is affected by the node time, node location, or node status of another itinerary node. For example, when the end time of a meeting node changes, causing a change in the validity period of an accommodation node, a budget dependency is formed between the meeting node and the accommodation node. Reimbursement standard inheritance is determined based on whether adjacent itinerary nodes apply the same reimbursement standard; when a node location changes, the reimbursement standard inheritance points to the itinerary node that applies the changed location.

[0018] The approval limit transmission relationship is determined based on whether changes in the budget amount require adjustments to the approval limit along the order of the travel nodes. The accounting subject derivation relationship is determined based on whether a change in a travel node requires re-determining the accounting subject for the affected travel node. Each relationship forms a budget transmission edge, and multiple budget transmission edges representing different relationships can exist between the same pair of travel nodes.

[0019] During the associated storage process, the starting and ending travel nodes and relationship type of each budget transmission edge are saved together with the node type, node time, node location, node status, and validity period of the travel node. If two travel nodes only have a sequential relationship in time but no budget dependency, reimbursement standard inheritance relationship, approval limit transmission relationship, or accounting subject derivation relationship, no budget transmission edge is generated. After the associated storage is completed, a travel node state graph is formed. This graph is used to determine the range of travel nodes to which travel node change events can be transmitted and provides travel nodes and budget transmission edges to the budget token set generation stage.

[0020] Budget dependencies correspond to budget transmission markers, reimbursement standard inheritance corresponds to reimbursement standard transmission markers, approval limit transmission corresponds to approval limit transmission markers, and accounting item derivation corresponds to accounting item transmission markers. These corresponding transmission markers are then written to the budget transmission edge. When a travel node has an unreleaseable budget amount, a frozen budget, or a budget reversal situation, and a change in another travel node can cause a change in that budget amount, a loss liability marker is written to the corresponding budget transmission edge based on the travel node's status and travel rules.

[0021] In one embodiment, the travel time constraints are determined after the travel node state diagram is formed. The node time of a travel node is represented by the start and end times, and the effective period is formed from the start time to the end time. For adjacent travel nodes with temporal or locational connections, the end time of the previous travel node and the start time of the next travel node are read, and the minimum and maximum time intervals are determined by combining the node type, node location, and travel rules of the two travel nodes.

[0022] The minimum time interval represents the lower limit of the time interval that must be maintained before the next trip node begins, used to prevent the next trip node from starting before the previous trip node has finished. The maximum time interval represents the upper limit of the time interval allowed between adjacent trip nodes, used to prevent trip nodes with excessively large time spans from maintaining an adjacent relationship. The minimum and maximum time intervals are determined based on the trip node type, node location, location connection relationship, and travel rules, and are associated with and stored separately for each trip node.

[0023] When accommodation, meeting, and return trip nodes exist simultaneously, the lower limit of the time interval between the end time of the meeting node and the start time of the return trip node is determined based on the node locations of the meeting and return trip nodes, as well as travel rules. When the meeting and return trip nodes are located at the same destination, the lower limit of the time interval is determined according to return travel arrangements within the same destination range; when the meeting and return trip nodes are located at different destinations, the lower limit of the time interval is determined by considering the location connectivity. If the start time of the return trip node exceeds the upper limit of the time interval between adjacent travel nodes, the return trip node no longer maintains a continuous temporal relationship with the meeting node, and the node time of the return trip node needs to be re-determined based on the return travel arrangements.

[0024] Coverage relationships are used to ensure that the validity period of an accommodation node covers the validity period of a conference node. The coverage relationship between an accommodation node and a conference node is satisfied when the accommodation node's start time is no later than the conference node's start time and the accommodation node's end time is no earlier than the conference node's end time. When an accommodation node only covers a portion of the conference node's validity period, the uncovered portion of the conference node's validity period is used to determine whether a supplementary accommodation node is needed. When the accommodation node's validity period exceeds the conference node's validity period, the excess portion remains within the accommodation node and is included in the subsequent budget determination process.

[0025] When establishing travel time constraints, the lower limit of the time interval is associated with the meeting node and the return node, the upper limit of the time interval is associated with adjacent travel nodes, and the coverage relationship is associated with the accommodation node and the meeting node. If both a lower and upper limit of the time interval exist for the same pair of travel nodes, the lower limit of the time interval must not exceed the upper limit. If the lower limit of the time interval exceeds the upper limit, no travel time constraint is generated between the pair of travel nodes, and the node times are adjusted according to the travel arrangements and return schedule. If the validity period of the accommodation node cannot cover the validity period of the meeting node, the coverage relationship remains unmet until the accommodation node's time is updated.

[0026] Once the travel task information enters the budget token generation stage, the travel nodes in the travel node status diagram are read, and the travel task information is used to determine the travel rules applicable to this travel matter. For each travel node, the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item are determined by combining the node type, node time, node location, node status, and travel rules.

[0027] Budget tokens are budget data objects bound to itinerary nodes, used to store the budget amount and corresponding accounting attributes occupied by the itinerary node in its current state. After all the details are finalized, the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item are written into the budget tokens, forming a budget token set. The budget token set is linked to the itinerary node state diagram and serves as input for determining the old budget token set and the new budget requirement token set after an itinerary node change event occurs.

[0028] In one embodiment, travel rules are determined by matching travel task information with pre-saved travel rules. During matching, the destination, travel details, departure time, and return arrangements from the travel task information are read, and the applicable scope is determined by combining this with the node type of the itinerary node. If multiple travel rules are applicable, the travel rule whose node location and time are both within the applicable scope is selected; if no applicable travel rule can be determined, a budget token is not generated for the corresponding itinerary node, and matching is re-executed after the travel task information is updated or the travel rules are supplemented.

[0029] Travel rules must at least record the expense categories corresponding to different node types, the reimbursement standards for node locations, the conditions for determining the budget amount, the transition relationship between node status and budget status, the constraint relationship between budget amount and approval limit, and the attribution relationship between expense categories and accounting subjects. Travel rules do not directly generate budget tokens, but rather serve as the processing basis for determining the various contents of budget tokens. When travel rules are updated, budget tokens that have already been generated and whose node status has not changed retain their original content, while newly generated budget tokens adopt the updated travel rules, avoiding unfounded changes to budget tokens in the same node status due to travel rule updates.

[0030] The budget amount is determined based on the node type, node time, node location, and reimbursement standard; the budget status is determined based on the node status and status transition relationship in the travel rules; the expense category is determined based on the node type and travel item; the reimbursement standard is determined based on the node type, node location, and travel rules; the approval limit is determined based on the budget amount and the limit constraint relationship in the travel rules; and the accounting subject is determined based on the expense category and the attribution relationship in the travel rules. When a trip node generates multiple expense categories, budget tokens are generated separately for each expense category and bound to the trip node. If any attribute cannot be determined, the corresponding budget token is not written to the budget token set and is regenerated after the travel task information or travel rules are supplemented. Through this process, when a budget token enters the budget token set, the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting subject all have a clear source.

[0031] In one embodiment, a trip node change event is used to record the fact that a node's time, location, or state has changed. A trip node change event can locate at least one trip node and carries the node's time before and after the change. When a trip node change event involves multiple trip nodes simultaneously, it is determined whether each trip node directly experienced a change in its time. Trip nodes that directly experienced a change in their time are identified as triggering trip nodes; trip nodes that are only indirectly affected by budget propagation edges are not identified as triggering trip nodes, but are included in the candidate trip nodes during subsequent budget propagation edge search.

[0032] The changed node time is determined by the start and end times in the itinerary node change event. When the itinerary node change event only changes the start time, the end time remains the same as the end time in the original node time; when only the end time changes, the start time remains the same as the start time in the original node time; when both the start and end times change, the complete node time recorded in the itinerary node change event is used. If the changed node time lacks a start or end time and cannot be supplemented from the original node time, the itinerary time constraints are not updated, and the itinerary node change event remains in a pending state.

[0033] When updating travel time constraints, the node time of the triggering travel node is replaced with the changed node time, and the actual time interval between the triggering travel node and adjacent travel nodes is recalculated. When the actual time interval is not greater than the maximum time interval, the time slack is the difference between the actual time interval and the minimum time interval; when the actual time interval is greater than the maximum time interval, the time slack is the difference between the maximum time interval and the actual time interval. The original adjacent relationships no longer satisfy the travel time constraints, and the budget influence relationship is retained along the budget propagation edge.

[0034] When an accommodation node and a meeting node have an overlap relationship, after updating the node time of either the accommodation node or the meeting node, it is re-evaluated whether the validity period of the accommodation node covers the validity period of the meeting node. If the overlap relationship is not satisfied, the time slack corresponding to the overlap relationship is the smaller of the difference between the start time of the meeting node and the start time of the accommodation node, and the difference between the end time of the accommodation node and the end time of the meeting node. A time slack less than zero indicates that the overlap relationship is not satisfied. When a minimum time interval exists between a return node and a meeting node, delaying the end time of the meeting node or advancing the start time of the return node will reduce the time slack; a time slack less than zero indicates that the updated itinerary nodes no longer meet the minimum time interval requirement. When a itinerary node is associated with multiple itinerary time constraints, the time slack of that itinerary node is the minimum value among the time slack values ​​corresponding to each itinerary time constraint.

[0035] Node timing pressure is determined in the following way:

[0036] in, For the first The timing pressure of each process node; For the first The change in the start time of each process node; For the first The change in the node end time of each travel node; For the first The duration of each process node before the update; For the first Time slack for each travel node; In order to be with the first The budget status parameters of the budget token bound to each trip node; , and As weight; The time normalization parameter is stored in the travel rules and determined according to the time slack range allowed by the travel rules. It is used to convert the time slack into a dimensionless quantity. A positive number is set to avoid the node time length being zero. The minimum recording granularity is adopted at node time.

[0037] Budget status parameters are determined by travel rules based on whether the budget amount has been occupied, whether migration is allowed, and whether it is frozen. When a trip node is bound to multiple budget tokens, the budget status of each budget token is converted into budget status parameters, and the maximum value among these parameters is determined as the budget status parameter for that trip node. Budget statuses that can be released but have not yet been occupied use lower budget status parameters, while budget statuses that have been occupied, allow only partial migration, or are frozen use higher budget status parameters. All budget status parameters remain unchanged within the same travel rule version. Weights are determined based on the contribution of node time changes, insufficient time slack, and the correlation between budget status and actual budget changes in historical trip node change events, and are normalized so that the sum of the three weights is 1. When historical records are insufficient, the initial weights saved in the travel rules are used, and all weights remain unchanged during the same travel task information processing. Node time-series pressure is generated and written to the trip node, and used for subsequent candidate trip node selection.

[0038] In one embodiment, the node influence domain is used to define the range of travel nodes whose budget amount, reimbursement standard, approval limit, or accounting item changes are caused by a travel node change event. The search process starts from the triggering travel node, reads the budget transmission edge connected to the triggering travel node, and visits adjacent travel nodes in the direction of the budget transmission edge. When the budget transmission edge has a budget transmission mark, the budget amount of adjacent travel nodes may change; when it has a reimbursement standard transmission mark, the reimbursement standard of adjacent travel nodes may change; when it has an approval limit transmission mark, the approval limit of adjacent travel nodes may change; when it has an accounting item transmission mark, the accounting item of adjacent travel nodes may change.

[0039] During the search, visits continue only along budget transmission edges that have at least one transmission marker. If a budget transmission edge does not have a budget transmission marker, reimbursement standard transmission marker, approval limit transmission marker, or accounting subject transmission marker, the search will not continue along that edge. If a circular connection exists in the process node state graph, process nodes that have already been searched will not be searched again to avoid the same process node repeatedly entering the candidate process node list due to multiple budget transmission edges. The searched process nodes and the triggering process node together form the candidate process nodes.

[0040] The timing pressure of candidate travel nodes is determined according to the updated travel time constraints. For candidate travel nodes whose node times have not been directly changed, the timing pressure is determined based on the change in node start time, change in node end time, or time slack resulting from the triggering of the travel node change. For candidate travel nodes whose travel time constraints and budget status have not changed, their timing pressure remains zero or below the node pressure threshold, and they do not enter the node influence domain formed based on node timing pressure.

[0041] The node stress threshold is used to distinguish between candidate travel nodes that need to enter the budget token migration phase and those that only maintain budget transmission relationships. The node stress threshold can be determined based on historical travel node change events. Specifically, it selects travel nodes whose timing stress actually caused changes in budget amount, reimbursement standards, approval limits, or accounting items in historical processing, and determines the node stress threshold based on a lower limit that can stably cover this type of travel node. When historical processing records are lacking, the node stress threshold can be determined based on the allowed range of node time changes and the lower limit of time slack in the travel rules.

[0042] When the node timing pressure of a candidate travel node is greater than or equal to the node pressure threshold, the candidate travel node is added to the node influence domain. When the node timing pressure is lower than the node pressure threshold, the candidate travel node is generally not added to the node influence domain, except when the budget propagation edge has a loss responsibility marker. The loss responsibility marker indicates that a travel node change event may cause non-releaseable budget amount, budget freeze, or budget reversal. Even if the change in the travel node's node time is small, it still needs to enter the subsequent budget token migration stage.

[0043] Nodes obtained by searching along budget transmission edges marked with loss responsibility are directly added to the node influence domain and are no longer subject to node pressure thresholds. For example, if the meeting node's time changes but the return node's time still satisfies the travel time constraint, the return node's time-series pressure may be lower than the node pressure threshold. If the return node has already formed an uncancellable budget state and the budget transmission edge between the meeting node and the return node has a loss responsibility mark, the return node still enters the node influence domain.

[0044] After a node's influence domain is formed, the budget tokens bound to each process node within that domain are read, and budget tokens with an "unclosed" budget status are aggregated into an old budget token set. An "unclosed" budget status means that the budget token has not yet completed final accounting and still needs to retain the budget amount or participate in subsequent processing, including allowing migration, allowing partial migration, and freezing.

[0045] Based on the itinerary node change event, determine the changed status of each itinerary node within the affected domain, and in conjunction with travel rules, re-determine the budget requirement amount, budget status, expense category, reimbursement standard, approval limit, and accounting item, generating a new set of budget requirement tokens. When an itinerary node generates multiple expense categories, new budget requirement tokens are generated separately for each expense category; if any attribute cannot be determined, no corresponding new budget requirement token is generated temporarily.

[0046] In one embodiment, travel rules store expense category conversion relationships, accounting item derivation relationships, and matching relationships between change reasons and expense categories. Expense category conversion relationships are used to determine whether expense categories in the old budget token can be transferred to expense categories in the new budget demand token. Accounting item derivation relationships are used to determine whether accounting items in the old budget token can be derived into accounting items in the new budget demand token. Matching relationships are used to determine whether the change reason for a travel node change event can form an expense category in the new budget demand token. If any relationship cannot be determined, no candidate migration edge is established between the corresponding old budget token and new budget demand token.

[0047] The system reads old budget tokens one by one from the old budget token set and matches them with each new budget demand token from the new budget demand token set. If the budget status of the old budget token allows migration, it continues to verify the expense category conversion relationship and accounting subject derivation relationship; if the budget status does not allow migration, the current matching is terminated. When the expense category satisfies the expense category conversion relationship and the accounting subject satisfies the accounting subject derivation relationship, a candidate migration edge is established between the old budget token and the new budget demand token. The candidate migration edge stores the old budget token, the new budget demand token, and the process nodes bound to the budget tokens at both ends.

[0048] Migration costs are determined using the following calculation relationship:

[0049] in, For the first Gejiu Budget Token and the First Migration costs between new budget requirement tokens; The difference in node timing pressure between the two ends of the candidate migration edge; Due to location differences; Differences in expense categories; Differences in budget status; For accounting subject differences; The value corresponding to the matching relationship between the reason for the change and the expense category of the new budget requirement token; , , , , and As weight.

[0050] The node timing pressure difference is determined by the absolute difference in node timing pressure between the two endpoints of the travel edge. Location difference, cost category difference, budget status difference, and accounting item difference are represented by values ​​between 0 and 1 according to travel rules. When the node locations of the two endpoints of a candidate migration edge are the same, the location difference is 0; when the node locations are different, a location difference greater than 0 is determined based on the location connection relationship. When the cost categories are the same, the cost category difference is 0; when the cost categories are different, a cost category difference greater than 0 is determined based on the cost category conversion relationship. When the budget status is the same, the budget status difference is 0; when the budget status is different, a budget status difference greater than 0 is determined based on the budget status conversion relationship in the travel rules. When the accounting items are the same, the accounting item difference is 0; when the accounting items are different, an accounting item difference greater than 0 is determined based on the accounting item derivation relationship.

[0051] When a matching relationship is satisfied, the matching difference between 0 and 1 is determined according to the travel rules; when a matching relationship is not satisfied, no candidate migration edge is established. Each weight is determined based on the budgeted migration results used in historical itinerary node change events and is normalized so that the sum of all weights is 1; if historical records are insufficient, the initial weights saved in the travel rules are used. The migration cost is written into the candidate migration edge to determine the total cost of the candidate migration.

[0052] In one embodiment, after the candidate migration edge completes the migration cost writing, it reads the budget amount and budget status of each old budget token to determine the migrateable amount of the old budget token. When the budget status allows full migration, the migrateable amount equals the budget amount; when the budget status only allows partial migration, the migrateable amount is determined according to the budget amount allowed to be released or transferred in the travel rules; when the budget status does not allow migration, the corresponding old budget token does not participate in the generation of candidate migration schemes. The budget requirement amount of the new budget requirement token adopts the budget requirement amount recorded in the new budget requirement token and serves as the upper limit of the migration amount flowing into the corresponding new budget requirement token.

[0053] When allocating migration amounts on candidate migration edges, the sum of migration amounts for multiple candidate migration edges connected to the same old budget token must not exceed the migrateable amount of that old budget token, and the sum of migration amounts for multiple candidate migration edges connected to the same new budget requirement token must not exceed the budget requirement amount of that new budget requirement token. Candidate migration edges with migration amounts greater than zero collectively constitute a candidate migration scheme. By changing the allocation method of migration amounts for each candidate migration edge, multiple candidate migration schemes are formed whose total migration amount equals the maximum total migration amount, and each candidate migration scheme is verified to simultaneously satisfy the outbound limit, inbound limit, and maximum total migration amount constraints. Candidate migration schemes that fail the verification are not included in the calculation of the total candidate migration cost.

[0054] The total cost of candidate migrations is determined using the following calculation relationship:

[0055] in, For the first The total cost of candidate migrations for each candidate migration option; For the first Among the candidate migration schemes, the first one is... Gejiu Budget Token and the First Migration amount of candidate migration edges between new budget requirement tokens; The migration cost is the cost of the corresponding candidate migration edge. The number of old budget tokens; The number of tokens required for the new budget. The product of the migration amount and the migration cost represents the cost of migrating the budget amount along the corresponding candidate migration edge. The sum of the products of all candidate migration edges forms the total candidate migration cost.

[0056] After calculating the total migration cost for all candidate migration schemes, the total migration costs are compared, and the candidate migration scheme with the lowest total migration cost is determined as the optimal migration result. When multiple candidate migration schemes have the same total migration cost, the candidate migration scheme with fewer candidate migration edges is selected first to reduce the number of migrations between budget tokens; if the number of candidate migration edges is still the same, any one of the candidate migration schemes is determined as the optimal migration result. If the candidate migration edges cannot cover the entire budget requirement amount, the optimal migration result is formed according to the established candidate migration edges, and the unallocated budget requirement amount remains in the new budget requirement token and is processed as an append in the budget token migration stage. The optimal migration result records the old budget tokens, new budget requirement tokens, candidate migration edges, migration amounts, and total candidate migration costs involved in the migration, and is passed to the budget token change instruction generation process.

[0057] In one embodiment, budget token transition instructions are generated one by one based on the optimal migration result. The old budget token is written into the source budget token, the new budget requirement token is written into the target budget requirement token, and the migration amount allocated to the candidate migration edge is written into the budget token transition instructions. The migration type is determined based on the budget status of the source budget token, the budget requirement amount of the target budget requirement token, and the itinerary node change event. The target budget status is determined based on whether the target budget requirement token reaches the budget requirement amount after migration and the budget status transition relationship in the travel rules.

[0058] When the migration type is "Transfer," the migration amount is deducted from the budget amount of the source budget token, and the same migration amount is written to the target budget requirement token. When the migration type is "Release," the source budget token is released from its occupation of the migration amount, and the total budget amount before and after the migration remains unchanged. When the migration type is "Freeze," the budget amount of the source budget token remains unchanged, and the budget status is updated. When the migration type is "Append," the budget amount of the target budget requirement token is increased by the budget append amount. When the migration type is "Reverse," the budget amount of the source budget token is reduced by the budget reverse amount. After completing the corresponding processing, a post-migration budget token is generated.

[0059] After the budget token is generated following the migration, the budget status is updated based on the migration type and target budget status. The reimbursement standards are updated according to changes in itinerary nodes, determining whether they change with node location, node time, or expense category. The approval limit is determined based on the target budget status and budget requirement amount. The accounting category is determined based on the expense category and accounting category derivation relationship. If any element cannot be determined according to travel rules, the budget token change instruction is stopped, and no budget token migration result is generated. After completion, the migration type, migration amount, target budget status, reimbursement standards, approval limit, and accounting category are written into the budget token migration result.

[0060] The budget conservation check uses the following relationship to determine the change in budget amount:

[0061] in, This is the difference between the total budget amount after the relocation and the total budget amount before the relocation. The sum of budget additions corresponding to all budget token transition instructions; This represents the total budget reversal amount corresponding to all budget token transition instructions. When the transition type is transfer, release, or freeze, the corresponding budget token transition instruction does not change the total budget amount. The budget conservation check passes when the sum of the budget increases and the sum of the budget reversals equals the difference between the total budget increases and the total budget reversals.

[0062] The total budget amount before migration is the sum of the budget amounts of each old budget token in the old budget token set; the total budget amount after migration is the sum of the budget amounts of all migrated budget tokens and the budget amounts of the source budget tokens that still retain budget amounts. The budget amounts corresponding to the source budget tokens whose budget status is frozen are included in the total budget amount after migration.

[0063] When the budget conservation check passes, the travel budget accounting result is generated based on the budget token migration result, and the itinerary node change event, migration type, migration amount, budget status, reimbursement standard, approval limit, accounting item and optimal migration result are recorded; when the budget conservation check fails, the contents before the budget token migration are restored and no travel budget accounting result is generated.

[0064] In one embodiment, the travel management system receives travel task information T20260310017, with travel dates from March 10th to March 12th, 2026, destination Beijing, travel purpose a project review meeting, and return trip from Beijing to Shanghai. Based on the travel task information, it generates an accommodation node H1, a meeting node M1, and a return trip node R1: the node time for accommodation node H1 is from 20:00 on March 10th to 8:00 on March 12th, and the node location is Beijing; the original node time for meeting node M1 is from 9:00 to 17:00 on March 11th, and the node location is Beijing; the node time for return trip node R1 is from 9:30 to 11:40 on March 12th, and the node location points from Beijing to Shanghai. All three travel nodes are in a confirmed status. The accommodation node H1 and the meeting node M1 form a coverage relationship, a budget dependency relationship, and a reimbursement standard inheritance relationship. The meeting node M1 and the return node R1 form a time sequence relationship, a location connection relationship, a budget dependency relationship, and an approval limit transmission relationship. The return arrangements have already been ticketed, and the corresponding budget transmission edge has a loss liability mark.

[0065] The travel rules limit the reimbursement standard for Beijing accommodation expenses to 600 yuan per night, the reimbursement standard for conference expenses to 300 yuan per conference, and return transportation expenses to be calculated based on the actual amount with an approved limit of 2,000 yuan. A budget token set is generated based on the node type, node time, node location, node status, and travel rules of the itinerary nodes.

[0066] Accommodation node H1 is bound to budget token O1, with a budget amount of 1200 yuan, a budget status of "allowed migration," an expense category of "accommodation fee," a reimbursement standard of 600 yuan per night, an approval limit of 1800 yuan, and is accounted for as accommodation fees within travel expenses. Meeting node M1 is bound to budget token O2, with a budget amount of 300 yuan, a budget status of "allowed migration," an expense category of "meeting fee," a reimbursement standard of 300 yuan per instance, an approval limit of 500 yuan, and is accounted for as meeting fee. Return node R1 is bound to budget token O3, with a budget amount of 1500 yuan, a budget status of "partially allowed migration," an expense category of "transportation fee," a reimbursement standard of "calculated based on actual amount," an approval limit of 2000 yuan, and is accounted for as transportation fees within travel expenses.

[0067] Upon receiving the itinerary node change event E01, the meeting node M1 is identified as the triggering itinerary node from the itinerary node change event E01. The itinerary node change event E01 changes the node time of meeting node M1 from 9:00 to 17:00 on March 11, 2026 to 9:00 to 14:00 on March 12, 2026. The change in the node start time of meeting node M1 is 1440 minutes, and the change in the node end time is 1260 minutes.

[0068] like Figure 2 As shown, Figure 2 The upper data is generated from travel task information, itinerary node change event E01, and itinerary node status diagram. Itinerary node change event E01 points to meeting node M1, which is the triggering itinerary node; the accommodation node H1 and meeting node M1 record the overlay relationship, and establish a budget transmission edge from meeting node M1 to accommodation node H1, with budget transmission markers and reimbursement standard transmission markers; the meeting node M1 and return node R1 record the time sequence relationship, and establish a budget transmission edge from meeting node M1 to return node R1, with budget transmission markers, approval limit transmission markers, and loss liability markers.

[0069] After the node time of meeting node M1 is updated, the validity period of accommodation node H1 ends at 8:00 on March 12, 2026, and the validity period of meeting node M1 ends at 14:00 on March 12, 2026. The validity period of accommodation node H1 cannot cover the validity period of meeting node M1, and the coverage relationship is in an unsatisfied state.

[0070] The end time of meeting node M1 is 14:00 on March 12, 2026, and the start time of return node R1 is 9:30 on March 12, 2026. The actual time interval between the end time of meeting node M1 and the start time of return node R1 is -270 minutes. The travel rules stipulate that the lower limit of the time interval between the end time of the meeting node and the start time of the return node is 90 minutes, thus determining the time slack to be -360 minutes.

[0071] The budget transmission edge between accommodation node H1 and meeting node M1 is marked with budget transmission marker and reimbursement standard transmission marker respectively according to budget dependency relationship and reimbursement standard inheritance relationship; the budget transmission edge between meeting node M1 and return node R1 is marked with budget transmission marker and approval amount transmission marker respectively according to budget dependency relationship and approval amount transmission relationship, and a loss responsibility marker is marked according to the node status where return tickets have been issued and the remaining budget amount cannot be fully released. Figure 2 The three verification regions in the diagram represent the coverage relationship verification result, the minimum time interval verification result, and the budget propagation edge marker, respectively, providing input for determining the node timing pressure and the node influence domain.

[0072] Node timing stress is determined based on the changes in node start time, node end time, time slack, and budget status. To enable the budget status to participate in numerical calculations, it is converted into budget status parameters. These parameters only represent the numerical values ​​of the budget status in the node timing stress calculations and do not change the meaning of the budget status. When the budget status allows migration or partial migration, the budget status parameter is set to 1.00.

[0073] The weights for changes in node start time and end time are 0.50, the weight for time slack is 0.30, the weight for budget status parameters is 0.20, and the time normalization parameter is 120 minutes, with a positive value of 1 minute set to avoid zero node time length. These weights are determined based on the proportion of influence of node time changes, time slack, and budget status on budget token changes in historical itinerary node change events, and remain unchanged during the current travel task information processing.

[0074] The node time length of conference node M1 before the update was 480 minutes. The node timing pressure of conference node M1 is calculated by multiplying 0.50 by 2700 and dividing by 481, adding 0.30 by 360 and dividing by 120, and adding 0.20 by 1.00. The result is 3.91.

[0075] The start and end time changes for both accommodation node H1 and return node R1 are 0, the time slack is -360 minutes, and the budget state parameter is 1.00. The timing stress for both accommodation node H1 and return node R1 is calculated by multiplying 0.30 by 360 and dividing by 120, then adding 0.20 by 1.00, resulting in a value of 1.10.

[0076] The node pressure threshold is determined based on 48 historical itinerary node change events under the same travel rule version. Among the historical itinerary node change events, the minimum node time-series pressure corresponding to the itinerary node that actually causes changes in budget amount, reimbursement standard, approval amount or accounting item is 0.82, and the node pressure threshold is set to 0.80 to retain a calculation tolerance of 0.02.

[0077] like Figure 3 As shown, Figure 3 Record the changes in node start time, node end time, time slack, budget status parameters, node timing pressure, and node pressure threshold for accommodation node H1, meeting node M1, and return node R1. The timing pressure of meeting node M1 is 3.91, and the timing pressure of accommodation node H1 and return node R1 is 1.10, both of which are greater than the node pressure threshold of 0.80.

[0078] Accommodation node H1 and meeting node M1 enter the node influence domain based on node timing pressure. The timing pressure of return node R1 is also greater than the node pressure threshold, and the budget propagation edge between meeting node M1 and return node R1 has a loss responsibility marker. Therefore, return node R1 enters the node influence domain and the loss responsibility marker is recorded. The node influence domain consists of accommodation node H1, meeting node M1, and return node R1.

[0079] Extract budget tokens O1, O2, and O3 from the budget token set that are bound to the travel nodes in the node's influence domain and whose budget status is not closed. Then, designate budget tokens O1, O2, and O3 as old budget tokens O1, O2, and O3, respectively, to form the old budget token set.

[0080] Based on the itinerary node change event E01, the changed status of each itinerary node in the node's influence domain is determined. The changed status of accommodation node H1 is that the accommodation arrangement needs to be extended; the changed status of meeting node M1 is that it continues; and the changed status of return node R1 is that the return arrangement needs to be re-determined. Travel rules stipulate that if the validity period of an accommodation node cannot cover the validity period of a meeting node, the supplementary accommodation fee budget is calculated based on a new accommodation billing period; in this example, the supplementary amount is 600 yuan. Based on the changed return arrangement, the transportation fee budget for return node R1 is determined to be 1850 yuan.

[0081] A new set of budget request tokens is generated based on the changed status and travel rules. New budget request token N1 is bound to accommodation node H1, with a budget request amount of 1800 yuan, a budget status of "not closed," an expense category of "accommodation fee," a reimbursement standard of 600 yuan per night, an approval limit of 1800 yuan, and an accounting category of "accommodation fee within travel expenses." New budget request token N2 is bound to meeting node M1, with a budget request amount of 300 yuan, a budget status of "not closed," an expense category of "meeting fee," a reimbursement standard of 300 yuan per instance, an approval limit of 500 yuan, and an accounting category of "meeting fee." New budget request token N3 is bound to return trip node R1, with a budget request amount of 1850 yuan, a budget status of "not closed," an expense category of "transportation fee," a reimbursement standard calculated based on the actual amount, an approval limit of 2000 yuan, and an accounting category of "transportation fee within travel expenses."

[0082] The travel rules allow direct conversion between the same expense categories and allow conversion between accommodation and transportation expenses within the approved limit, but do not allow conversion between meeting expenses and accommodation or transportation expenses. The original return trip arrangement corresponding to the old Budget Token O3 can be refunded with 1100 yuan, and the remaining 400 yuan cannot be released. Therefore, the transferable amount of the old Budget Token O3 is 1100 yuan.

[0083] Migration costs are determined by the matching relationship between differences in node timing pressure, location, expense category, budget status, accounting items, and the reason for the change in the itinerary node change event and the expense category of the new budget requirement token. The weights of each item are 0.20, 0.10, 0.25, 0.10, 0.15, and 0.20, respectively.

[0084] The old budget token O1 and the new budget request token N1 have the same expense category, node location, and accounting item. The difference in budget status is 0.10, the difference in matching the reason for change and expense category is 0.40, and all other differences are 0, thus determining the migration cost to be 0.09. The old budget token O2 and the new budget request token N2 have only a 0.10 matching difference, resulting in a migration cost of 0.02. The old budget token O3 and the new budget request token N3 have only a 0.10 matching difference, resulting in a migration cost of 0.02.

[0085] The location difference between the old budget token O1 and the new budget request token N3 is set at 1.00, the expense category difference at 0.80, the budget status difference at 0.10, the accounting item difference at 0.40, the matching difference at 0.20, and the migration cost at 0.41. The location difference between the old budget token O3 and the new budget request token N1 is set at 1.00, the expense category difference at 0.80, the budget status difference at 0.20, the accounting item difference at 0.40, the matching difference at 0.20, and the migration cost at 0.42.

[0086] like Figure 4 As shown, a candidate migration edge is established between the old budget token O1 and the new budget demand token N1, with a migration cost of 0.09 and a migration amount of 1200 yuan; a candidate migration edge is established between the old budget token O2 and the new budget demand token N2, with a migration cost of 0.02 and a migration amount of 300 yuan; a candidate migration edge is established between the old budget token O3 and the new budget demand token N3, with a migration cost of 0.02 and a migration amount of 1100 yuan. The migration edges from old budget token O1 to new budget demand token N3 and from old budget token O3 to new budget demand token N1 are considered as alternative migration edges.

[0087] The total transferable amount of old budget tokens O1, O2, and O3 is 2600 yuan. The maximum total transfer amount that the candidate migration edge can support under the constraints of the migration-out limit and migration-in limit is 2600 yuan. The total transfer amount of each candidate migration scheme is 2600 yuan.

[0088] In Scheme A, the old budget token O1 is migrated to the new budget demand token N1 for 1200 yuan, the old budget token O2 is migrated to the new budget demand token N2 for 300 yuan, and the old budget token O3 is migrated to the new budget demand token N3 for 1100 yuan. The total cost of the candidate migration is the sum of 1200 multiplied by 0.09, 300 multiplied by 0.02, and 1100 multiplied by 0.02, which is 136.

[0089] In Option B, the old budget token O1 is migrated to the new budget demand token N3 for 1200 yuan, the old budget token O2 is migrated to the new budget demand token N2 for 300 yuan, and the old budget token O3 is migrated to the new budget demand token N1 for 1100 yuan. The total cost of the candidate migrations is the sum of 1200 multiplied by 0.41, 300 multiplied by 0.02, and 1100 multiplied by 0.42, which is 960.

[0090] In Scheme C, old budget token O1 migrates 600 yuan to new budget demand token N1 and 600 yuan to new budget demand token N3; old budget token O2 migrates 300 yuan to new budget demand token N2; old budget token O3 migrates 600 yuan to new budget demand token N1 and 500 yuan to new budget demand token N3. The total migration cost for Scheme C is the sum of 600 multiplied by 0.09, 600 multiplied by 0.41, 300 multiplied by 0.02, 600 multiplied by 0.42, and 500 multiplied by 0.02, which equals 568. Scheme A has the lowest total migration cost, therefore Scheme A is determined as the optimal migration result.

[0091] Based on the optimal migration result, a budget token transition instruction is generated. The old budget token O1, as the source budget token, transfers 1200 yuan to the new budget demand token N1, and adds 600 yuan to the new budget demand token N1; the old budget token O2, as the source budget token, transfers 300 yuan to the new budget demand token N2; the old budget token O3, as the source budget token, transfers 1100 yuan to the new budget demand token N3, freezes the remaining 400 yuan of the old budget token O3, and adds 750 yuan to the new budget demand token N3.

[0092] like Figure 5 As shown, after migration, the budget amounts for budget tokens N1, N2, and N3 are 1800 yuan, 300 yuan, and 1850 yuan respectively, with a total budget amount of 3950 yuan. The frozen source budget token O3 retains 400 yuan, bringing the total budget amount after migration to 4350 yuan. The total budget amount before migration was 3000 yuan. Adding the budget increase amount of 1350 yuan and subtracting the budget reversal amount of 0 yuan equals 4350 yuan, thus passing the budget conservation check. The travel budget accounting results record the above budget amount, frozen budget amount, budget increase amount, and the budget status, reimbursement standard, approval limit, and accounting item for each budget token.

[0093] like Figure 6 As shown, the graph construction module consists of a data input interface, a processor, and a graph data storage area, used to receive travel task information, generate and store the travel node state graph and travel time constraints; the token generation module consists of a processor, a travel rule storage area, and a budget token storage area, used to generate and store the budget token set; the impact determination module consists of an event receiving interface, a processor, and a state cache area, used to receive travel node change events, determine node timing pressure and node impact domain; the set determination module consists of a processor, a budget token index area, and a set cache area, used to generate and cache the old budget token set and the new budget requirement token set; the migration determination module consists of a processor, a migration parameter storage area, and a computation cache area, used to determine the migration cost and the optimal migration result; the accounting generation module consists of a processor, a budget conservation verification unit, and a result storage interface, used to migrate and update budget tokens, and output the travel budget accounting result after budget conservation verification.

[0094] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0095] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

Claims

1. A trip node-driven travel budget accounting method, characterized in that, The method includes: Obtain travel task information, construct a travel node state graph including travel nodes and budget propagation edges, and determine travel time constraints; A set of budget tokens is generated based on the trip nodes. The budget tokens represent the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item. In response to a travel node change event, update the travel time constraints and determine the node timing pressure, and determine the node influence domain by combining the budget propagation edge; Determine the old budget token set and the new budget demand token set based on the node's influence domain; The migration cost and optimal migration result are determined based on the node timing pressure and the attribute differences between the old budget token and the new budget demand token. The budget token is migrated and updated based on the optimal migration result, and the travel budget calculation result is generated after budget conservation verification.

2. The method according to claim 1, characterized in that, The construction of the travel node state graph, which includes travel nodes and budget propagation edges, includes: Generate itinerary nodes based on the travel time, destination, travel details, and return arrangements in the travel task information; Budget transmission edges are generated based on the temporal relationships, location connections, budget dependencies, reimbursement standard inheritance relationships, approval limit transmission relationships, and accounting item derivation relationships among the aforementioned itinerary nodes; The process nodes and the budget transmission edges are associated and stored to generate a process node state graph.

3. The method according to claim 1, characterized in that, The determination of the travel time constraints includes: When the itinerary nodes include accommodation nodes, meeting nodes, and return nodes, determine the minimum time interval, maximum time interval, and coverage relationship between the itinerary nodes; The minimum time interval is used to limit the lower limit of the time interval between the end time of the meeting node and the start time of the return node; the maximum time interval is used to limit the upper limit of the time interval between adjacent trip nodes; and the coverage relationship is used to limit the validity period of the accommodation node to cover the validity period of the meeting node. The travel time constraint relationship is generated based on the minimum time interval, the maximum time interval, and the coverage relationship.

4. The method according to claim 1, characterized in that, The step of generating a budget token set based on the itinerary nodes includes: Determine travel rules based on the aforementioned travel mission information; Based on the node type, node time, node location, node status, and travel rules of the itinerary nodes, determine the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item respectively; Write the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item into the budget token bound to the itinerary node to generate a budget token set.

5. The method according to claim 1, characterized in that, The step of responding to a travel node change event, updating the travel time constraints, and determining the node timing pressure includes: The triggering time of the itinerary node and the time of the changed node are determined based on the itinerary node change event; Update the travel time constraint relationship based on the changed node time; Based on the travel time constraints before and after the update, determine the change in node start time, the change in node end time, and the time slack of the travel node; The node timing pressure of the trip node is determined based on the change in the node start time, the change in the node end time, the time slack, and the budget status of the budget token bound to the trip node. The determination of the node influence domain by combining the budget transmission edge includes: Starting from the triggering trip node, a search is performed along the budget transmission edge that has a budget transmission mark, reimbursement standard transmission mark, approval amount transmission mark or accounting subject transmission mark, and the triggering trip node and the trip node obtained by the search are determined as candidate trip nodes; The travel nodes in the candidate travel nodes whose timing pressure is greater than or equal to the node pressure threshold, as well as the travel nodes obtained by searching along the budget transmission edge with loss responsibility label, are determined as the node influence domain.

6. The method according to claim 5, characterized in that, The step of determining the old budget token set and the new budget demand token set based on the node influence domain includes: Determine travel rules based on the aforementioned travel mission information; Extract budget tokens that are bound to the trip nodes in the node's influence domain and whose budget status is not closed from the budget token set to obtain the old budget token set; Determine the changed state of the travel nodes in the node influence domain based on the travel node change event; Based on the changed status and the travel rules, determine the budget requirement amount, budget status, expense category, reimbursement standard, approval limit and accounting item of the travel node in the node influence domain, and generate a new budget requirement token set.

7. The method according to claim 6, characterized in that, The determination of the migration cost includes: Based on the aforementioned travel rules, determine the expense category conversion relationship, accounting item derivation relationship, and the matching relationship between the change reason of the itinerary node change event and the expense category; Select an old budget token from the old budget token set and select a new budget requirement token from the new budget requirement token set; If the budget status of the old budget token allows migration, the expense categories of the old budget token and the new budget demand token satisfy the expense category conversion relationship, and the accounting items of the old budget token and the new budget demand token satisfy the accounting item derivation relationship, a candidate migration edge is established between the old budget token and the new budget demand token. The migration cost of the candidate migration edge is determined based on the differences in node timing pressure and location of the trip nodes bound to the budget tokens at both ends of the candidate migration edge, the differences in cost categories, budget status, and accounting items of the budget tokens at both ends of the candidate migration edge, and the matching relationship between the change reason of the trip node change event and the cost category of the new budget demand token.

8. The method according to claim 7, characterized in that, Determining the optimal migration result includes: The corresponding transferable amount is determined based on the budget amount and budget status of each old budget token in the old budget token set; Using the migration limit of each old budget token as the migration limit and the budget requirement amount of each new budget requirement token as the migration limit, determine the maximum total migration amount that the candidate migration edge can bear under the constraints of the migration limit and the migration limit. Migration amounts are allocated to the candidate migration edges so that the sum of the migration amounts for each candidate migration scheme equals the maximum total migration amount, thus obtaining multiple candidate migration schemes; The total cost of candidate migration is obtained by summing the products of migration amount and migration cost for each candidate migration edge in each candidate migration scheme; The candidate migration scheme with the minimum total migration cost is determined as the optimal migration result.

9. The method according to claim 8, characterized in that, Based on the optimal migration result, the budget token is migrated and updated, and a travel budget calculation result is generated after budget conservation verification, including: Based on the optimal migration result, a budget token transition instruction is generated, which includes the source budget token, the target budget requirement token, the migration amount, the migration type, and the target budget status. According to the migration type, a transfer is performed between the source budget token and the target budget demand token according to the budget token change instruction, or the source budget token is released, frozen, or reversed, or the target budget demand token is appended, to obtain the migrated budget token; Based on the migration type, the itinerary node change event, and the target budget status, update the budget status, reimbursement standard, approval limit, and accounting item of the migrated budget token to generate the budget token migration result; Summarize the budget addition and budget reversal amounts corresponding to each budget token transition instruction, and verify whether the difference between the total budget amount after migration and the total budget amount before migration is equal to the difference between the total budget addition amount and the total budget reversal amount. Among them, budget token transition instructions with the migration type of transfer, release or freeze do not change the total budget amount. If the budget conservation check passes, the travel budget calculation result is generated based on the budget token migration result.

10. A trip node-driven travel budget accounting system, used to implement the trip node-driven travel budget accounting method according to any one of claims 1 to 9, characterized in that, The system includes: The graph construction module is used to obtain travel task information, construct a travel node state graph including travel nodes and budget transmission edges, and determine travel time constraints. The token generation module is used to generate a set of budget tokens based on the itinerary nodes. The budget tokens represent the budget amount, budget status, expense category, reimbursement standard, approval limit, and accounting item. The impact determination module is used to respond to the travel node change event, update the travel time constraint relationship and determine the node timing pressure, and determine the node impact domain in combination with the budget transmission edge; The set determination module is used to determine the old budget token set and the new budget demand token set based on the node's influence domain. The migration determination module is used to determine the migration cost and optimal migration result based on the node timing pressure and the attribute differences between the old budget token and the new budget demand token; The accounting generation module is used to migrate and update the budget token based on the optimal migration result, and generate the travel budget accounting result after budget conservation verification.

Images