A charging pile industrial cloud platform intelligent charging and settlement integrated management system

Abstract

The present application relates to the technical field of industrial cloud platform data processing and billing settlement, and particularly relates to a charging pile industrial cloud platform intelligent billing and settlement integrated management system. The system converts charging start, stop, cumulative power, order state, billing rules and payment confirmation data into standard events, constructs a billing causal event graph according to state transition, cumulative power continuity and event sequence constraints, and generates a physical event timeline and a rule event timeline, and divides the charging process into billing segments. The system distinguishes stable billing segments and to-be-confirmed billing segments according to event closed states, determines the affected node closure when late events are written, only rebuilds the billing segments covered by the closure, and updates the corresponding settlement balance according to the segment version mapping and contribution index. The system can restore the causal order of asynchronous events, limit the recalculation range of late data, and keep the data versions of the billing results and the settlement results consistent.

Description

Technical Field

[0001] This invention relates to the field of industrial cloud platform data processing and billing settlement technology, specifically to an integrated intelligent billing and settlement management system for charging pile industrial cloud platforms. Background Technology

[0002] Existing charging pile industrial cloud platforms typically consist of software components such as pile-end data access, order management, billing rule management, and settlement processing. During the charging process, charging piles continuously upload records such as start time, stop time, cumulative electricity consumption, order status, and payment confirmation. The platform aggregates data from different sources into the same order according to the order identifier and sorts the records by platform reception time or pile-end time. After the order ends, the billing program reads the pre-configured time-of-use electricity price, service fee, occupancy fee, and discount rules. It divides the billing period based on the charging start and end intervals and the difference in cumulative electricity consumption, calculates the cost for each period, and summarizes it to form a bill. The settlement program then extracts fields such as the operating entity, fee type, and settlement cycle from the bill, performs aggregation, billing, and summarization for multiple orders, and generates corresponding settlement details. To avoid duplicate uploads and resulting duplicate billing, some platforms also perform simple deduplication based on order identifier, event type, and time fields, and use a cache queue to wait for the order end event before triggering the entire order billing.

[0003] The platform sets up a state machine or time window for charging events, rearranges data arriving out of order within a short period, and saves the rule version when billing rules are adjusted, ensuring that orders match the corresponding rules according to the charging time. Some systems also use message queues and transaction tables to record data processing status. When order data is missing, cumulative electricity is discontinuous, or rule versions are inconsistent, the order is marked as abnormal and enters the recalculation process. Recalculation usually takes the complete order as the processing object, rereads the charging event, reconstructs the time period, calls the billing rules, and overwrites the original bill; if the original bill has already entered the settlement batch, the original settlement record is reversed or the entire order is transferred to the next settlement cycle. This type of solution can handle some data delays and rule switching situations, but its data sorting, billing calculation, and settlement processing are mostly completed by independent software processes, each process saves its processing results separately, and the billing stage and settlement stage lack a unified event causal boundary and fragment version reference relationship.

[0004] When charging events are uploaded asynchronously from different software nodes, the order in which events arrive at the industrial cloud platform may differ from the actual order of occurrence. Delayed events, duplicate events, or clock skew can alter the boundaries of charging periods and the positions of power segments. Existing platforms typically use the order of receipt or a single time field as the basis for billing, and the complete order as the minimum processing object for recalculation and settlement correction. When subsequent events are inserted into the existing order sequence, the platform struggles to determine the actual billing interval affected, and can only cancel the original invoice and re-execute the entire order billing. If the original invoice has already generated settlement details, the recalculation result may be separate from the existing settlement version, causing local data changes to spread along the order summary relationship to all billing periods and related settlement records. Consequently, the platform cannot maintain the causal consistency of billing data while limiting the correction scope caused by delayed events to the actually affected data segments. Summary of the Invention

[0005] The purpose of this invention is to provide an integrated intelligent billing and settlement management system for charging pile industrial cloud platforms, which can solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A smart billing and settlement integrated management system for charging pile industrial cloud platform includes an event access module, a causal orchestration module, a dual time axis billing module, a segment stabilization module, and a settlement linkage module; The event access module converts charging start, charging stop, cumulative power consumption, order status, billing rules, and payment confirmation data into standard events containing order identifier, occurrence time, receipt time, sequence identifier, and rule version. The causal orchestration module constructs a billing causal event graph based on state transition constraints, cumulative electricity continuity constraints, and event sequence constraints. The dual-time-axis billing module generates physical event time axes and rule event time axes based on the billing causal event graph, and forms billing segments; The segment stabilization module divides stable billing segments and unconfirmed billing segments according to the event closure state, and determines the affected node closure when a late event is written. The settlement linkage module uses the billing segment identifier, rule version, and causal summary to generate settlement details, and updates the corresponding settlement difference according to the affected node closure.

[0007] Preferably, the event access module performs semantic deduplication and clock consistency processing on the standard events in the same order. First, it generates event fingerprints according to the event source, pile end sequence identifier and cumulative electricity value. Standard events with consistent fingerprints and consistent load digests are merged into a single event node, and standard events with consistent fingerprints but different load digests are marked as conflict candidate nodes. Then, based on the difference in cumulative power between adjacent nodes, the reachability of charging status, and the receiving time, the priority order of each candidate node for conflict is determined, and the occurrence time at the charging pile is converted into a relative time within the order. The causal orchestration module establishes directed constraint edges based on the relative time, priority order, and state reachability relationship, and records the set of predecessor nodes, the set of successor nodes, and the set of conflicting references for each standard event.

[0008] Preferably, the dual-time-axis billing module divides the physical event time axis into an energy increment interval defined by adjacent cumulative energy events, and divides the rule event time axis into a rule validity interval defined by billing rule activation events and failure events; For cases where a power increment range spans at least two rule valid ranges, multiple sub-segments are generated according to the projection boundary of the rule valid ranges on the physical event time axis, and the start and end event nodes, corresponding power increment, applicable rule version, billing factor set and parent segment identifier are recorded for each sub-segment; When the rule version in the rule event timeline is replaced, only the sub-segments that intersect with the replacement boundary are reconstructed, while the identification and reference relationships of the non-intersecting sub-segments are maintained.

[0009] Preferably, the segment stabilization module establishes a stability record for each billing segment, consisting of the complete state of the preceding event, the complete state of the subsequent event, the closed state of the accumulated electricity, the fixed state of the rule version, and the payment dependency state. The billing segments whose predecessor event complete state, successor event complete state, cumulative power consumption closed state, and rule version fixed state are all closed and whose payment dependency state does not contain any pending references are written into the stable segment set, and the remaining billing segments are written into the unconfirmed segment set. A stable snapshot containing the first and last event fingerprints, rule version summary, and segment power summary is generated for the billing segments in the stable segment set. When a subsequent standard event arrives, the range of billing segments that are destabilized is determined by the stable snapshot and the insertion position of the new event in the billing causal event graph.

[0010] Preferably, when the causal orchestration module inserts a new standard event into the billing causal event graph, it first locates the candidate subgraph based on the order identifier, and then filters the connectable nodes based on the cumulative power value, charging status and relative time of the new standard event. When multiple connectable nodes simultaneously satisfy the conditions for establishing directed constraint edges, a local constraint subgraph is constructed containing the newly added standard event, each connectable node and its adjacent nodes. The local constraint subgraph is then subjected to state transition legality checks, cumulative power monotonicity checks, and sequence continuity checks, and edge combinations that simultaneously satisfy all three types of checks are retained. For newly added standard events that cannot form a unique edge combination, a suspended node and a candidate edge set are established until subsequent standard events cause the candidate edge set to converge before being incorporated into the billing causal event graph.

[0011] Preferably, the dual-time-axis billing module establishes a physical boundary index and a rule boundary index for each sub-segment. The physical boundary index is associated with the cumulative electricity events before and after the sub-segment, and the rule boundary index is associated with the effective and ineffective events of the rules applicable to the sub-segment. When the newly added standard event changes the physical event timeline or the rule event timeline, the first affected sub-segment set and the second affected sub-segment set are determined by the physical boundary index and the rule boundary index, respectively. The boundary is re-segmented on the union of the two sets, and the billing factor set of the unchanged boundary segment is inherited according to the original parent segment identifier. Only the newly added boundary segment is assigned a new sub-segment identifier and rule version reference.

[0012] Preferably, the segment stabilization module propagates the stability records of each billing segment in the set of segments to be confirmed to the associated settlement details according to the dependency direction in the billing causal event graph; When a settlement detail references both the stable billing segment and the billing segment to be confirmed, the settlement detail is split into a stable settlement share and a billing segment to be confirmed, and the segment contribution index is recorded separately. The settlement linkage module only generates a settlement version number and version lock record for the stable settlement share, and retains an unlocked state for the settlement share to be confirmed. When a billing segment is destabilized, the version lock record of the corresponding stable settlement share is revoked based on the segment contribution index, and the version number of the unaffected share in the same settlement details is retained.

[0013] Preferably, when the segment stabilization module determines that the newly added standard event affects the stable billing segment, it takes the node corresponding to the newly added standard event as the starting point and extends along the predecessor constraint edge and successor constraint edge of the billing causal event graph until it encounters a boundary node with a stable snapshot and whose first and last event fingerprints, rule version summaries and segment power summaries have not changed, thus obtaining the minimum affected node closure. The dual-time-axis billing module only re-divides the billing segments for the physical event time-axis intervals and the rule event time-axis intervals covered by the least affected node closure, and establishes a version mapping from the original segment identifier to the new segment identifier for the reconstructed billing segments. Billing segments not covered by the least affected node closure maintain the original stable snapshot.

[0014] Preferably, the causal orchestration module generates a graph change transaction for the convergence of the candidate edge set of the suspended node. The graph change transaction records the order identifier, trigger event fingerprint, local constraint subgraph version, original edge combination and target edge combination, and generates a transaction idempotency identifier based on the trigger event fingerprint, the local constraint subgraph boundary and the target edge combination. Before submitting the graph change transaction, verify the consistency between the version of the local constraint subgraph and the original edge combination with the current content of the billing causal event graph; For graph change transactions with duplicate idempotency flags, the committed target edge combinations are reused. For graph change transactions that fail consistency checks, candidate subgraphs are reread, local constraint subgraphs are reconstructed, and edge combinations that simultaneously satisfy all three types of checks are re-selected.

[0015] Preferably, the settlement linkage module determines the settlement share that needs to be updated based on the version mapping from the original fragment identifier to the new fragment identifier and the fragment contribution index, and forms a set of fee items corresponding to the original fragment version set and the new fragment version set respectively; The expense items in the expense item set that have the same settlement object, expense type and rule version are merged by difference, and the expense items that do not have a corresponding relationship are registered as reversal items and new items respectively. For pending settlement shares that are in an unlocked state, update the corresponding expense items with the difference merging result. For stable settlement shares with version locking records, generate a difference settlement record that is associated with the original settlement version number, the new standard event summary, and the new fragment version set. The new standard event summary is generated by the order identifier, sequence identifier, and receipt time. The difference settlement record is then written into the subsequent settlement version.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By converting charging start, charging stop, cumulative electricity consumption, order status, billing rules, and payment confirmation data into standard events containing order identifier, occurrence time, receipt time, sequence identifier, and rule version, and constructing a billing causal event graph based on state transition constraints, cumulative electricity consumption continuity constraints, and event sequence constraints, the data order within the order can be restored according to the actual dependencies between events. The physical event time axis is used to limit the electricity consumption increment range, and the rule event time axis is used to limit the rule validity range. Both types of time axes jointly determine the billing segments, ensuring that charging facts and rule facts correspond within the same segment boundary. After a late event is written, the minimum affected node closure is determined starting from the insertion node. Only the physical and rule intervals covered by the closure are re-divided into billing segments; uncovered stable segments retain their original stable snapshots. Settlement details directly reference the billing segment identifier, rule version, and causal summary. Billing corrections can be mapped to the corresponding settlement difference along the segment version, changing the entire order rollback to a partial update of the affected segments, and maintaining that the billing result and settlement result are based on the same event version.

[0017] 2. After standard events are processed using event fingerprints, payload summaries, and relative time within the order, duplicate events can be merged. Events with conflicting fingerprints are retained as conflict candidate nodes, and edge combinations are jointly filtered by state transition legality, cumulative electricity monotonicity, and sequence continuity. For events whose unique connection relationship cannot be determined temporarily, they are saved as suspended nodes and candidate edge sets, and then incorporated into the billing causal event graph after subsequent events bring the connection relationship together, avoiding unresolved events directly changing the existing billing order. Physical boundary indexes and rule boundary indexes locate sub-segments affected by event changes and rule changes, respectively. Stability records and stability snapshots are used to identify lockable billing segments, and segment contribution indexes are used to split a settlement detail into stable settlement shares and pending settlement shares. Graph change transactions are restricted from repeated submissions through local subgraph versions, original edge combinations, and idempotency identifiers. Differential settlement records complete the continuous registration of reversal items, new items, and differential items through the original segment version, new segment version, and cost item correspondence, ensuring that event retransmission, partial rearrangement, and segment reconstruction do not cause duplicate processing of unaffected settlement shares. Attached Figure Description

[0018] Figure 1 This is the overall processing flowchart of the intelligent billing and settlement integrated management system for the charging pile industrial cloud platform; Figure 2 A flowchart for constructing standard event semantic deduplication, clock consistency, and billing causal event graphs; Figure 3 Flowchart for collaborative segmentation of physical event timelines and rule event timelines, and for determining the stability of billing segments; Figure 4Flowchart for partial closure reconstruction, graph change transaction submission, and settlement difference update for late arrival events. Detailed Implementation

[0019] In one embodiment, please refer to Figure 1 The charging pile industrial cloud platform's intelligent billing and settlement integrated management system consists of an event access module, a causal orchestration module, a dual-time-axis billing module, a segment stabilization module, and a settlement linkage module. The event access module receives charging start, charging stop, cumulative electricity consumption, order status, billing rules, and payment confirmation data, and converts these data into standard events containing order identifiers, occurrence times, receipt times, sequence identifiers, and rule versions. The causal orchestration module constructs a billing causal event graph based on state transition constraints, cumulative electricity consumption continuity constraints, and event sequence constraints. The dual-time-axis billing module generates physical event time axes and rule event time axes based on the billing causal event graph and forms the billing data. The segment stabilization module divides stable billing segments and pending billing segments according to the event closure state and determines the affected node closure when a late event is written. The settlement linkage module generates settlement details by referencing the billing segment identifier, rule version, and causal summary, and updates the corresponding settlement difference according to the affected node closure. Each module establishes a connected data reference chain through the order identifier, event node identifier, segment identifier, and settlement version identifier. Any billing result in the platform can be traced back to the corresponding standard event and rule version, and any settlement difference can be traced back to the changed billing segment. The entire process is based on the common data foundation of event causal relationship and segment version relationship.

[0020] Specifically, the event access module sets a unified data encapsulation structure for each type of access data. The order identifier is used to merge asynchronous records generated in the same charging process. The occurrence time indicates the time when the record is formed on the data source side, the reception time indicates the time when the record enters the industrial cloud platform, the sequence identifier indicates the order in which records are generated in the same order from the same data source, and the rule version indicates the valid version of the billing rule in the corresponding time interval. The platform temporarily stores records lacking order identifiers in the pending association area and completes order attribution using charging pile identifiers, session identifiers, and adjacent status records. For records lacking occurrence time but having continuous sequence identifiers, a relative order is established according to the occurrence time of adjacent known events. For repeatedly received records, the initial entry position is retained and a retransmission reference is added. After standard events are entered into the database, the original payload is not directly overwritten. Instead, the original payload summary, standardized fields, and source mapping are saved so that the conversion process can still be reproduced when the cause-effect graph is adjusted later. Billing rule data establishes rule events according to rule version, effective time, expiration time, applicable fee type, and priority relationship, so that charging facts and rule facts enter the same event processing framework.

[0021] In this embodiment, the causal orchestration module uses standard events as nodes and the reachability relationships between events as directed edges. State transition constraints limit the connection to the charging in progress, paused, or stopped states after the charging start state, and prohibit the reverse connection from the charging stopped state to the charging in progress state. The cumulative power continuity constraint limits the cumulative power of the successor node within the same order to not be less than the cumulative power of the predecessor node. The event sequence constraint combines the occurrence time, reception time, and sequence identifier to determine the candidate order of nodes. When the occurrence time is the same but the sequence identifier is different, the order is determined according to the sequence identifier. When the occurrence time is missing or there is clock rollback, the candidate order is corrected using the cumulative power change and state transition relationship. To avoid incorrect edge connections caused by relying on only a single field, the module calculates the constraint consistency degree for each candidate edge and only writes the candidate edges that meet the three basic conditions of state, energy, and sequence into the billing causal event graph. Nodes store the predecessor set, successor set, conflict reference set, and source record set. When subsequent events arrive, only the local subgraph that has a causal relationship with the newly added node is modified.

[0022] ; in, This represents the constraint consistency degree between standard event node i and standard event node j. This indicates whether a state transition is allowed; a value of 1 indicates allowed, and a value of 0 indicates disallowed. This indicates whether the accumulated battery charge satisfies a non-decreasing relationship; a value of 1 indicates that the condition is met, and a value of 0 indicates that the condition is not met. This indicates whether the order determined by the occurrence time, reception time, and sequence identifier is consistent; a value of 1 indicates consistency, and a value of 0 indicates inconsistency. , , The weights for state, energy, and order constraints are respectively set and the sum of the three is 1. During implementation, state transition and accumulated power are set as mandatory constraints, that is, no candidate edge is established when any corresponding variable is 0. The order variable is used to determine the priority connection relationship among multiple feasible candidate edges. For example, if node i is in the charging state and the accumulated power is 12, and node j is in the charging stopped state and the accumulated power is 15, the candidate edge from node i to node j is retained when all three types of variables are 1.

[0023] For preferred options, please refer to [the provided text]. Figure 3The dual-time-axis billing module extracts charging start, cumulative power change, pause, resumption, and charging stop nodes from the billing causal event graph, forming a physical event time axis according to causal edges. The physical event time axis is not directly sorted by reception time, but represents the actual charging process by a causal order after constraint verification. The module also extracts rule activation, rule replacement, and rule failure nodes from rule events to form a rule event time axis. The rule event time axis is used to determine the applicable electricity price rules, service fee rules, occupancy fee rules, and discount deduction rules in each time interval. The module divides adjacent cumulative power nodes in the physical event time axis into power increment intervals, and then projects the rule boundaries in the rule event time axis onto the corresponding power increment intervals. When the projected boundary falls inside the interval, the original interval is split into multiple sub-segments. Each sub-segment records the parent segment identifier, start and end event nodes, start and end times, allocated power, rule version, and billing factor set. The billing amount is determined by the power, duration, and applicable rules within the sub-segment. Any subsequent rule replacement only affects the sub-segments that intersect with the replacement boundary.

[0024] Furthermore, the segment stabilization module maintains the event closure state for each billing segment. The event closure state consists of at least the completeness of the preceding event, the completeness of the succeeding event, the closure of the cumulative power consumption, the fixedness of the rule version, and the determination of the payment dependency. The completeness of the preceding event indicates that there are no unprocessed events before the segment's starting point that may change the starting point. The completeness of the succeeding event indicates that there are events after the segment's ending point that can close the current interval. The closure of the cumulative power consumption indicates that the cumulative power consumption at the beginning and end of the segment is determined and there are no conflicting candidate values. The fixed rule version indicates that the effective and invalidation boundaries of the rules within the segment's coverage time are determined. The determination of the payment dependency indicates that there are no pending references to the payment results corresponding to the billing segment. Billing segments that meet the stability conditions are written into the stable segment set and a stable snapshot is generated. Billing segments that do not meet the stability conditions are written into the unconfirmed segment set. The stable snapshot saves the fingerprints of the first and last events, the rule version summary, the segment power consumption summary, and the current version number. When a new standard event is inserted inside the causal boundary of a stable segment, the module determines the scope of destabilization based on the insertion position and the stable snapshot.

[0025] In a preferred embodiment, the settlement linkage module does not re-parse the original charging data. Instead, it uses billing segments as settlement input. For each billing segment, it reads the segment identifier, rule version, fee type, billing amount, settlement object, and causal summary, and generates a contribution record from the billing segment to the settlement details. The causal summary is formed by combining the event node identifiers covered by the segment, the fingerprints of the first and last events, and the rule version summary. The settlement details summarize multiple contribution records according to the settlement object and fee type and save the version reference of each contribution record. When a late event causes a billing segment to be rebuilt, the settlement linkage module finds the affected contribution record according to the mapping from the original segment identifier to the new segment identifier, merges the difference between the original contribution amount and the new contribution amount, keeps the original version reference for unaffected contribution records, and does not regenerate the complete settlement details. If the original contribution record is not locked, the corresponding fee item is directly updated. If it is locked, an independent difference settlement record is established and associated with the original settlement version number.

[0026] In the operation of this embodiment, an order sequentially generates a charging start event, a record of accumulated power of 8, a record of accumulated power of 14, and a charging stop event. Among them, the record of accumulated power of 11 enters the industrial cloud platform later than the charging stop event due to network caching. The event access module converts the late record into a standard event and locates the existing billing causal event graph according to the order identifier. The causal orchestration module inserts the late node between the nodes of accumulated power of 8 and 14 based on the non-decreasing relationship of accumulated power and the state transition relationship. The dual time axis billing module only redivides the power increment interval covered by the late node. The segment stabilization module releases the stable state of the corresponding segment and retains the stable snapshot of other segments. The settlement linkage module forms the difference fee item according to the segment version mapping. In this process, billing segments that occur before the late node and whose boundaries have not changed are not recalculated. Billing segments that occur after the late node and whose causal relationship has not changed continue to reference the original version. The platform thus uses the local causal closure as the common boundary for billing and settlement correction.

[0027] In one embodiment, please refer to Figure 2The event access module performs semantic deduplication and clock consistency processing on standard events in the same order. The module encodes the event source, charging pile sequence identifier, and cumulative power value in a fixed field order, and generates an event fingerprint by combining the event type and order identifier. If the event fingerprints of two standard events are consistent and the original payload digests are consistent, the later event is registered as a retransmission reference of the earlier event without creating a new billing node. If the event fingerprints are consistent but the original payload digests are different, the two standard events are saved separately and marked as conflict candidate nodes. Conflict candidate nodes do not immediately enter the stable billing segment, but determine the priority order by combining the difference in adjacent cumulative power, the charging status reachability relationship, and the reception time. The module also converts the charging pile occurrence time of each event into the order-specific time relative to the order's starting event to reduce the impact of differences in clock references between different charging piles on event sorting. The causal orchestration module establishes directed constraint edges based on relative time, priority order, and status reachability relationship, and records the predecessor set, successor set, and conflict reference set for each node.

[0028] ; in, This represents the retention priority value of the conflict candidate node r. This represents the continuity of the difference between a candidate node and its preceding and following cumulative electricity records, with a value ranging from 0 to 1. This represents the reachability consistency between the charging state of a candidate node and its adjacent states, with a value of 1 for reachability and 0 for inaccessibility. This indicates the degree of consistency between the candidate node reception order and the order of the homologous sequence, with a value ranging from 0 to 1. , and They are respectively represented as , ,and The platform calculates and retains priority values ​​for multiple conflict candidate nodes under the same event fingerprint, using corresponding non-repeating normalized weights. The node with the higher value is set as the primary candidate node, while the remaining nodes are retained as conflict references. For example, if two candidate nodes record cumulative battery levels of 10 and 16 respectively, and the cumulative battery levels of adjacent nodes are 9 and 11, the node corresponding to the cumulative battery level of 10 has a higher continuity of difference than the cumulative battery level of 16, and its state is reachable. In this case, the node corresponding to the cumulative battery level of 10 is set as the primary candidate node.

[0029] Specifically, the relative time within an order is based on the occurrence time of the order's initiation event. When a standard event has a credible occurrence time, the difference between the occurrence time of the standard event and the occurrence time of the order's initiation event is directly calculated. When a standard event lacks an occurrence time but has consecutive sequence identifiers, interval interpolation is performed based on the relative time positions of the preceding and following credible events. When only the preceding credible event exists, a monotonically increasing provisional relative time is established based on the same-source sequence interval and the receiving order. The provisional relative time is only used for candidate edge screening and is not directly used as the basis for cost calculation. After subsequent credible events arrive, the relative time is recalibrated and a local subgraph check is triggered. When establishing directed constraint edges, the causal orchestration module records the basis of the edge, including state transition basis, cumulative power consumption basis, relative time basis, and same-source sequence basis. When conflicts occur later, it can identify the directed edges that need to be recalculated, avoiding the reconstruction of the entire order graph due to a single relative time correction.

[0030] In a preferred embodiment, the dual-time-axis billing module divides the physical event time axis into power increment intervals defined by adjacent cumulative power events, and the rule event time axis into rule validity intervals defined by billing rule activation and deactivation events. When a power increment interval spans at least two rule validity intervals, the module generates multiple sub-segments according to the projection boundary of the rule validity interval on the physical event time axis. The projection process takes the start and end times of the interval and the difference between adjacent cumulative power as input. When there are no finer-grained power records within the interval, the power of each sub-segment is calculated according to the time-corrected allocation function. When there are cumulative power records within the interval, the power of the sub-segment is determined directly using the record difference. Each sub-segment stores the start and end event nodes, the corresponding power increment, the applicable rule version, the billing factor set, and the parent segment identifier. When the rule version in the rule event time axis is replaced, only the sub-segments that intersect with the replacement boundary are reconstructed, and the identifiers and reference relationships of the non-intersecting sub-segments are maintained.

[0031] ; in, This represents the amount of electricity allocated to the u-th sub-segment. This represents the total energy increment between the previous accumulated energy node p and the next accumulated energy node q in the physical event timeline. This represents the duration of the u-th sub-segment within the corresponding power increment interval, where m represents the number of sub-segments obtained by dividing the power increment interval by the rule boundary, and the denominator represents the sum of the durations of all sub-segments. For example, if the total power increment is 12 and the interval is divided into 3 sub-segments with durations of 20, 10, and 30, the 3 sub-segments are allocated 4, 2, and 6 units of power respectively. If there are cumulative power records within the interval, the cumulative power difference is used to replace the time ratio allocation result, and the corresponding record is written to the power source field of the sub-segment.

[0032] Furthermore, the dual-time-axis billing module establishes physical boundary indexes and rule boundary indexes for each sub-segment. The physical boundary indexes are associated with the cumulative electricity events before and after the sub-segment, the parent segment identifier, and the physical time-axis version. The rule boundary indexes are associated with the effective events, invalid events, rule versions, and rule time-axis versions of the rules applicable to the sub-segment. When a new standard event changes the physical event time-axis, the module uses the physical boundary indexes to locate the sub-segments whose start and end event nodes are replaced, inserted, or deleted, forming the first set of affected sub-segments. When a rule event is added, replaced, or invalidated, the module uses the rule boundary indexes to locate the sub-segments that intersect with the changed rule boundary, forming the second set of affected sub-segments. The module re-executes boundary segmentation on the union of the two sets. Unchanged boundary segments inherit the original parent segment identifier and billing factor set. Newly added boundary segments are assigned new sub-segment identifiers and the source rule version is recorded. Deleted boundary segments retain the termination version record for reference in the settlement difference calculation.

[0033] In one embodiment, the segment stabilization module establishes a stability record for each billing segment, consisting of the completeness of the preceding event, the completeness of the succeeding event, the closure of the cumulative power consumption, the fixed rule version, and the payment dependency status. The completeness of the preceding event is determined based on whether all candidate preceding events at the segment's starting node have completed conflict resolution. The completeness of the succeeding event is determined based on whether there is a valid successor at the segment's ending node and whether the order has reached its end state. The closure of the cumulative power consumption is determined based on whether the starting and ending cumulative power consumption records are unique and satisfy a non-decreasing relationship. The fixed rule version is determined based on whether there are any pending rule replacement events within the segment's coverage area. The payment dependency status is determined based on whether a unique reference is formed between the payment confirmation record and the order fee item. Billing segments with the first four items closed and payment dependencies without pending references are written into the stable segment set, while the remaining segments are written into the unconfirmed segment set. Each segment in the stable segment set generates a stable snapshot containing the fingerprints of the first and last events, a rule version summary, and a segment power consumption summary.

[0034] ; in, This represents the stability determination value for billing segment k. This indicates that the preceding event is complete. Indicates the complete state of subsequent events. Indicates the status of the accumulated charge. This indicates that the rule version is in a fixed state. This indicates the payment dependency state. Each variable is 1 when closed and 0 when not closed. The stability determination value is 1 and a stable snapshot is generated only when all 5 variables are 1. For example, if the order has ended and the events before and after the fragment are unique, the accumulated battery power is not conflicting, the rule version is fixed, and a unique reference has been established for the payment record, all 5 variables are 1. If there are still two candidate references for the payment record, the payment dependency state is 0, and the fragment continues to be retained in the set of fragments to be confirmed.

[0035] Preferably, stable snapshots use immutable version records. The first and last event fingerprints are used to confirm whether segment boundary events have been replaced. The rule version summary is used to confirm whether the applicable rule set and execution order within the segment have changed. The segment power summary is used to confirm whether the allocated power and its source record have changed. After a new standard event arrives, the segment stabilization module first retrieves adjacent stable snapshots based on the insertion position of the new event in the billing causal event graph. Then, it compares whether the new event has changed the first and last event fingerprints, rule version summary, and segment power summary. The stabilization state of the corresponding segment is deactivated only when at least one of these items has changed. If the new event is located between two stable segments and does not change the boundary or power of either segment, only a new segment to be confirmed is created without deactivating the stabilization state of the adjacent segments. When deactivating the stabilization state, the termination version, trigger event fingerprint, and deactivation reason of the original stable snapshot are saved for subsequent segment version mapping and settlement difference tracking.

[0036] In a preferred embodiment, when a new standard event is inserted into the billing causal event graph, the causal orchestration module first locates candidate subgraphs based on the order identifier, and then filters connectable nodes based on the cumulative power value, charging status, and relative time of the new standard event. The range of candidate subgraphs consists of the nearest node whose cumulative power is less than or equal to the cumulative power of the new event, the nearest node whose cumulative power is greater than or equal to the cumulative power of the new event, and adjacent nodes between them. When the new event does not contain cumulative power, the candidate subgraph is limited by the nearest predecessor node and the nearest successor node that are reachable from the state. When multiple connectable nodes simultaneously meet the conditions for establishing directed constraint edges, the module constructs a local constraint subgraph containing the new standard event, each connectable node, and its adjacent nodes, and performs state transition legality checks, cumulative power monotonicity checks, and sequence continuity checks on the local constraint subgraph. Edge combinations that meet the three types of checks are added to the committable set, and edge combinations that do not meet any of the mandatory checks are deleted.

[0037] Specifically, the state transition legality check verifies the starting and ending states of each candidate edge according to the preset state diagram; the cumulative power monotonicity check compares the cumulative power node by node along the directed path of the candidate edge combination and verifies the non-decreasing relationship; the sequence continuity check verifies that there is no reverse jump between the sequence identifiers of adjacent nodes for the same event source; for cases where multiple edge combinations can still be submitted but all three types of checks are met, the causal orchestration module compares the number of conflicting candidate nodes, the number of provisional relative times, and the number of nodes crossed in each edge combination, and retains the edge combination with lower constraint uncertainty as the main combination, while the remaining edge combinations are saved as candidate edge sets. For new standard events that cannot form a unique main combination, a suspended node is established. The suspended node saves the original load summary, candidate predecessor set, candidate successor set, and conditions to be satisfied until the subsequent standard event arrives and the candidate edge set converges before being incorporated into the billing causal event graph. During the suspension period, it does not participate in the generation of stable billing segments.

[0038] In one embodiment, the segment stabilization module propagates the stability records of each billing segment in the set of segments to be confirmed to the associated settlement details according to the dependency direction in the billing causal event graph. The propagation process is executed through the contribution records from the billing segment to the settlement details. When a settlement detail references both stable billing segments and billing segments to be confirmed, the settlement linkage module splits the settlement detail into stable settlement shares and settlement shares to be confirmed according to the contribution records. The stable settlement shares only contain the contributions of billing segments with a stability judgment value of 1, and the settlement shares to be confirmed contain the contributions of billing segments with a stability judgment value of 0. The two types of shares record the segment contribution index, fee type, settlement object, and source version, respectively. The settlement linkage module only generates a settlement version number and version lock record for the stable settlement shares, and retains an unlocked state for the settlement shares to be confirmed. When the status of the billing segment changes subsequently, the corresponding share is updated according to the segment contribution index.

[0039] Furthermore, when a billing segment referenced by a locked stable settlement share is destabilized, the segment stabilization module searches for all settlement shares referencing the billing segment based on the segment contribution index and cancels the version lock record of the corresponding share. The cancellation operation only applies to shares containing contributions from changed segments. Shares formed by other stable segments in the same settlement details continue to retain the original settlement version number. The destabilized segment re-enters the set of segments to be confirmed and retains the termination version of the original contribution record. After the segment is rebuilt and meets the stabilization conditions again, the settlement linkage module establishes a version mapping between the original contribution record and the new contribution record. If the new contribution amount is consistent with the original contribution amount, the original settlement reference relationship is restored and an equivalent replacement record is registered. If the amounts are different, a reversal item, a new item, or a merged difference item is generated according to the difference processing logic.

[0040] In a preferred embodiment, please refer to Figure 4When determining whether a new standard event affects a stable billing segment, the segment stabilization module starts from the node corresponding to the new standard event and extends along the predecessor and successor constraint edges in the billing causal event graph. It extends forward until it encounters a front boundary node with a stable snapshot and whose first and last event fingerprints, rule version summaries, and segment power summaries have not changed. It extends backward until it encounters a back boundary node that meets the same conditions. The nodes and constraint edges between the front and back boundary nodes form the minimum affected node closure. If a suspended node is encountered during the extension process, all candidate predecessors and candidate successors of the suspended node are included in the closure. If a rule replacement event intersects with the physical time axis interval covered by the closure, the corresponding rule boundary node is included in the closure. The dual time axis billing module only re-divides the billing segments for the physical event time axis interval and rule event time axis interval covered by the closure.

[0041] ; in, This represents the smallest affected node closure formed starting from the newly added event node x. This indicates that node y can be reached from node x along the directed constraint edge. This indicates that node x can be reached from node y along the directed constraint edge. This indicates that the first and last event fingerprints, rule version summaries, and fragment battery summaries of the stable snapshot corresponding to node y remain unchanged. This indicates that the condition is not met; the extension occurs when a condition is met. The closure stops when the boundary node is reached. For example, when a late event is inserted between two stable segments and only changes the middle segment, the boundary nodes of the two stable segments satisfy the stopping condition. The closure only contains the node corresponding to the middle segment and the newly added event node.

[0042] In this embodiment, after recalculating the interval covered by the least affected node closure, the dual-time-axis billing module establishes a version mapping from the original segment identifier to the new segment identifier for each reconstructed billing segment. The mapping types include one-to-one replacement, one-to-many splitting, many-to-one merging, and termination of addition. One-to-one replacement means that the original segment boundary is maintained but the segment content changes. One-to-many splitting means that the original segment is divided into multiple new segments due to the addition of events or rule boundaries. Many-to-one merging means that multiple original segments are merged into a new segment due to the resolution of conflict events or the revocation of rule boundaries. Termination of addition means that the original segment no longer exists or the new segment does not have a direct original version. Billing segments not covered by the least affected node closure continue to use the original stable snapshot, original segment identifier, and original settlement reference. The version mapping records the original version number, new version number, mapping type, trigger event fingerprint, and boundary change summary.

[0043] In one embodiment, the causal orchestration module generates a graph change transaction for the convergence of the candidate edge set of suspended nodes. The graph change transaction records the order identifier, trigger event fingerprint, local constraint subgraph version, original edge combination, and target edge combination. The original edge combination represents the set of directed edges that already exist in the local constraint subgraph before the transaction is committed, and the target edge combination represents the set of directed edges that should be written after conflict resolution. The module generates a transaction idempotency identifier based on the trigger event fingerprint, the boundary of the local constraint subgraph, and the target edge combination. Before the graph change transaction enters the commit phase, it reads the current version of the corresponding local constraint subgraph in the billing causal event graph, verifies whether the current version is consistent with the transaction record version, and verifies whether the original edge combination is still consistent with the current graph content. After the verification is passed, the replaced edge is deleted atomically, the target edge is written, the predecessor set and successor set of the node are updated, and the local constraint subgraph version is incremented.

[0044] Preferably, for graph change transactions with duplicate idempotency identifiers, the causal orchestration module queries committed transaction records and reuses committed target edge combinations, new versions of local constraint subgraphs, and fragment reconstruction trigger results, without repeatedly deleting or writing directed edges. For graph change transactions that fail consistency checks, the module does not directly overwrite the current billing causal event graph, but instead rereads candidate subgraphs, reconstructs local constraint subgraphs, re-executes state transition legality checks, cumulative electricity monotonicity checks, and sequence continuity checks, and re-selects edge combinations based on the latest node status. The regenerated transaction retains the original trigger event fingerprint and updates the local constraint subgraph version and target edge combination. If the same trigger event does not change the existing edge combination after re-selection, an empty change transaction is generated and the processing completion status is recorded to avoid message retransmission or concurrent processing causing the same order graph to be modified repeatedly.

[0045] In one embodiment, the settlement linkage module determines the settlement share that needs to be updated based on the version mapping from the original fragment identifier to the new fragment identifier and the fragment contribution index, and forms a set of fee items corresponding to the original fragment version set and the new fragment version set respectively. The fee item includes at least the settlement object, fee type, rule version, fragment version and amount. The module establishes a correspondence between the fee items in the two sets that have the same settlement object, fee type and rule version and performs difference merging. Fee items that exist in the original set but not in the new set are registered as reversal items. Fee items that exist in the new set but not in the original set are registered as new items. For fee items that can establish a correspondence, the difference item is obtained by subtracting the original amount from the new amount. When multiple difference items belong to the same settlement object, fee type and rule version, they are merged and the source fragment version list is retained.

[0046] ; in, This represents the merged difference of the corresponding relation group h. This represents the set of cost item indexes belonging to the corresponding relation group h in the new fragment version set. This represents the amount of the new expense item n. This represents the set of cost item indexes belonging to the corresponding relation group h in the original fragment version set. This indicates the amount of the original expense item o. When the difference is greater than 0, a new difference item is created; when the difference is less than 0, a reversal difference item is created; when the difference is equal to 0, only the version replacement relationship is registered. For example, if the original expense item amounts are 30 and 20 under the same settlement object and expense type, and the new expense item amounts are 25 and 28, the merged difference is 3 and associated with the fragment versions of the 4 source expense items.

[0047] Specifically, for pending settlement shares that are in an unlocked state, the settlement linkage module directly updates the corresponding expense items with the difference merging result and marks the original expense items as replaced by the new version. For stable settlement shares with version locking records, the module does not modify the existing amount in the original settlement version, but generates difference settlement records that are associated with the original settlement version number, the new standard event summary, and the new fragment version set. The new standard event summary is generated by encoding the order identifier, sequence identifier, and receipt time in a fixed order. The difference settlement records are written into subsequent settlement versions and save the reversal items, new items, merged difference items, and source fragment mappings. When subsequent settlement versions are summarized, the difference records are collected according to the settlement object, expense type, and rule version, while retaining the reference chain with the original settlement version, so that multiple fragment splits caused by the same late event can maintain a traceable difference relationship in consecutive versions.

[0048] In this embodiment, the industrial cloud platform uses an append-only data organization method to store standard events, causal edges, billing segments, and settlement contribution records. After a standard event is formed, a non-repeatable event node identifier is assigned. Subsequent deduplication, conflict resolution, and clock correction are all expressed by adding new version records without modifying the original event content. The causal edge table stores the start node identifier, end node identifier, edge state, constraint basis, and local subgraph version, respectively. The billing segment table stores the parent segment identifier, start and end node identifiers, physical time axis version, rule time axis version, rule version, and stable state. The settlement contribution table stores the billing segment version, settlement detail version, fee type, and contribution amount. Modules read data through versioned references. When any processing task submits its result, it simultaneously writes the input version set and the output version set. When the input version changes during task execution, the current output is discarded and reprocessed based on the new version, thereby avoiding the concurrent late events and rule events from overwriting the local correction results generated by each other.

[0049] Furthermore, each billing rule version in the rule event timeline is parsed into a rule record with applicable conditions, fee type, calculation order, and rounding position. The applicable conditions are at least associated with order attributes, charging time interval, and billing segment type. The calculation order is used to determine the reference relationship between electricity price, service fee, placeholder fee, and deductible fee. The rounding position is used to determine whether the numerical processing occurs at the sub-segment level, parent segment level, or settlement detail level. When generating sub-segments, the dual-timeline billing module solidifies the applicable rule record into a billing factor set and saves the execution order summary. After the rule version is replaced, only the applicable conditions and execution order are rematched for sub-segments where the rule boundaries intersect. If the replacement rule only changes the fee type that is not referenced by the current sub-segment, the atomic segment version is retained and the change without impact is registered in the rule boundary index. If the replacement rule changes the referenced fee type or execution order, a new sub-segment version is generated and enters the subsequent stability judgment.

[0050] In a preferred embodiment, the settlement linkage module performs a cost conservation check after the difference settlement record is written. The module aggregates the total amount of cost items in the original fragment version set, the total amount of generated reversal items, the total amount of new items, the total amount of merged difference items, and the total amount of cost items in the new fragment version set according to the order identifier. It also verifies that the sum of the original cost item total and all difference changes equals the new cost item total. The verification results are grouped according to the settlement object and cost type. If the order-level verification passes but the group verification fails, the difference settlement record is not submitted. Instead, the fragment contribution index is reread to check the mapping relationship of the settlement object or cost type. After the group verification passes, an immutable verification summary is generated for the difference settlement record and written to the subsequent settlement version. If the same fragment version mapping is triggered repeatedly, the processed difference is identified according to the verification summary and the existing record is reused without adding reversal items or new items again.

[0051] In the complete application process of this embodiment, the industrial cloud platform receives asynchronous events from multiple charging orders and completes standardization. Event fingerprints are used to identify duplicate and conflicting records. Relative time within an order is used to correct clock deviations from different sources. The causal orchestration module uses state, cumulative power consumption, and sequence constraints to construct an order-level billing causal event graph. The dual-time-axis billing module projects the physical charging process and rule activation process into billing segments. The segment stabilization module generates stable snapshots based on event completeness, cumulative power consumption closure, rule fixity, and payment dependency determinism. The settlement linkage module uses the billing segment as the minimum contribution object to form settlement details. When late events, rule replacement events, or conflict resolution results change the existing graph structure, the platform limits the scope of modification through local constraint subgraphs, graph change transactions, and minimum affected node closures. Then, it transmits the modification results through segment version mapping, segment contribution index, and differential cost item set. Event nodes, billing segments, and settlement shares that have not undergone causal changes retain their original version references.

Claims

1. A smart billing and settlement integrated management system for a charging pile industrial cloud platform, characterized in that, It includes an event access module, a causal orchestration module, a dual-time axis billing module, a segment stabilization module, and a settlement linkage module; The event access module converts charging start, charging stop, cumulative power consumption, order status, billing rules, and payment confirmation data into standard events containing order identifier, occurrence time, receipt time, sequence identifier, and rule version. The causal orchestration module constructs a billing causal event graph based on state transition constraints, cumulative electricity continuity constraints, and event sequence constraints. The dual-time-axis billing module generates physical event time axes and rule event time axes based on the billing causal event graph, and forms billing segments; The segment stabilization module divides stable billing segments and unconfirmed billing segments according to the event closure state, and determines the affected node closure when a late event is written. The settlement linkage module uses the billing segment identifier, rule version, and causal summary to generate settlement details, and updates the corresponding settlement difference according to the affected node closure.

2. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 1, characterized in that, The event access module performs semantic deduplication and clock consistency processing on the standard events in the same order. First, it generates event fingerprints according to the event source, pile end sequence identifier and cumulative electricity value. Standard events with consistent fingerprints and consistent load digests are merged into a single event node. Standard events with consistent fingerprints but different load digests are marked as conflict candidate nodes. Then, based on the difference in cumulative power between adjacent nodes, the reachability of charging status, and the receiving time, the priority order of each candidate node for conflict is determined, and the time of occurrence at the charging pile is converted into a relative time within the order. The causal orchestration module establishes directed constraint edges based on the relative time, priority order, and state reachability relationship, and records the set of predecessor nodes, the set of successor nodes, and the set of conflicting references for each standard event.

3. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 2, characterized in that, The dual-time-axis billing module divides the physical event time axis into an energy increment range defined by adjacent cumulative energy events, and divides the rule event time axis into a rule validity range defined by billing rule activation events and failure events; For cases where a power increment range spans at least two rule valid ranges, multiple sub-segments are generated according to the projection boundary of the rule valid ranges on the physical event time axis, and the start and end event nodes, corresponding power increment, applicable rule version, billing factor set and parent segment identifier are recorded for each sub-segment; When the rule version in the rule event timeline is replaced, only the sub-segments that intersect with the replacement boundary are reconstructed, while the identification and reference relationships of the non-intersecting sub-segments are maintained.

4. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 1, characterized in that, The segment stabilization module establishes a stability record for each billing segment, consisting of the complete state of the preceding event, the complete state of the subsequent event, the closed state of the accumulated electricity, the fixed state of the rule version, and the payment dependency state. The billing segments whose predecessor event complete state, successor event complete state, cumulative power consumption closed state, and rule version fixed state are all closed and whose payment dependency state does not contain any pending references are written into the stable segment set, and the remaining billing segments are written into the unconfirmed segment set. A stable snapshot containing the first and last event fingerprints, rule version summary, and segment power summary is generated for the billing segments in the stable segment set. When a subsequent standard event arrives, the range of billing segments that are destabilized is determined by the stable snapshot and the insertion position of the new event in the billing causal event graph.

5. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 3, characterized in that, When inserting a new standard event into the billing causal event graph, the causal orchestration module first locates candidate subgraphs based on the order identifier, and then filters connectable nodes based on the cumulative power value, charging status, and relative time of the new standard event. When multiple connectable nodes simultaneously satisfy the conditions for establishing directed constraint edges, a local constraint subgraph is constructed containing the newly added standard event, each connectable node and its adjacent nodes. The local constraint subgraph is then subjected to state transition legality checks, cumulative power monotonicity checks, and sequence continuity checks, and edge combinations that simultaneously satisfy all three types of checks are retained. For newly added standard events that cannot form a unique edge combination, a suspended node and a candidate edge set are established until subsequent standard events cause the candidate edge set to converge before being incorporated into the billing causal event graph.

6. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 4, characterized in that, The dual-time-axis billing module establishes a physical boundary index and a rule boundary index for each sub-segment. The physical boundary index is associated with the cumulative electricity events before and after the sub-segment, and the rule boundary index is associated with the effective and ineffective events of the rules applicable to the sub-segment. When the newly added standard event changes the physical event timeline or the rule event timeline, the first affected sub-segment set and the second affected sub-segment set are determined by the physical boundary index and the rule boundary index, respectively. The boundary is re-segmented on the union of the two sets, and the billing factor set of the unchanged boundary segment is inherited according to the original parent segment identifier. Only the newly added boundary segment is assigned a new sub-segment identifier and rule version reference.

7. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 6, characterized in that, The segment stabilization module propagates the stability records of each billing segment in the set of segments to be confirmed to the associated settlement details according to the dependency direction in the billing causal event graph. When a settlement detail references both the stable billing segment and the billing segment to be confirmed, the settlement detail is split into a stable settlement share and a billing segment to be confirmed, and the segment contribution index is recorded separately. The settlement linkage module only generates a settlement version number and version lock record for the stable settlement share, and retains an unlocked state for the settlement share to be confirmed. When a billing segment is destabilized, the version lock record of the corresponding stable settlement share is revoked based on the segment contribution index, and the version number of the unaffected share in the same settlement details is retained.

8. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 7, characterized in that, When determining whether the newly added standard event affects the stable billing segment, the segment stabilization module starts from the node corresponding to the newly added standard event and extends along the predecessor and successor constraint edges of the billing causal event graph until it encounters a boundary node with a stable snapshot and whose first and last event fingerprints, rule version summaries, and segment power summaries have not changed, thus obtaining the closure of the least affected node. The dual-time-axis billing module only re-divides the billing segments for the physical event time-axis intervals and the rule event time-axis intervals covered by the least affected node closure, and establishes a version mapping from the original segment identifier to the new segment identifier for the reconstructed billing segments. Billing segments not covered by the least affected node closure maintain the original stable snapshot.

9. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 5, characterized in that, The causal orchestration module generates graph change transactions for the convergence of the candidate edge set of suspended nodes. The graph change transaction records the order identifier, trigger event fingerprint, local constraint subgraph version, original edge combination and target edge combination, and generates a transaction idempotency identifier based on the trigger event fingerprint, the local constraint subgraph boundary and the target edge combination. Before submitting the graph change transaction, verify the consistency between the version of the local constraint subgraph and the original edge combination with the current content of the billing causal event graph; For graph change transactions with duplicate idempotency flags, the committed target edge combinations are reused. For graph change transactions that fail consistency checks, candidate subgraphs are reread, local constraint subgraphs are reconstructed, and edge combinations that simultaneously satisfy all three types of checks are re-selected.

10. The integrated intelligent billing and settlement management system for charging pile industrial cloud platform according to claim 8, characterized in that, The settlement linkage module determines the settlement share that needs to be updated based on the version mapping from the original fragment identifier to the new fragment identifier and the fragment contribution index, and forms a set of fee items corresponding to the original fragment version set and the new fragment version set respectively. The expense items in the expense item set that have the same settlement object, expense type and rule version are merged by difference, and the expense items that do not have a corresponding relationship are registered as reversal items and new items respectively. For pending settlement shares that are in an unlocked state, update the corresponding expense items with the difference merging result. For stable settlement shares with version locking records, generate a difference settlement record that is associated with the original settlement version number, the new standard event summary, and the new fragment version set. The new standard event summary is generated by the order identifier, sequence identifier, and receipt time. The difference settlement record is then written into the subsequent settlement version.

Images