Supply chain multi-role collaborative automatic account division method and system and storage medium
By monitoring business events to generate accounting processing tasks, and combining a DSL expression parser with graph model calculation nodes, an accounting graph is generated and subject allocation calculation is performed. This solves the problem of insufficient expressive power of accounting rules in existing technologies, and realizes accurate allocation and efficient accounting under multiple roles, multiple expense items and multiple scenarios, ensuring the traceability of the accounting process and the consistency between accounts and reality.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-04
- Publication Date
- 2026-04-10
AI Technical Summary
Existing technologies in supply chain e-commerce and O2O transactions lack the ability to express revenue sharing rules, making it difficult to adapt to complex business scenarios. Revenue sharing under multiple roles, multiple expense items, and multiple scenarios cannot achieve accurate allocation and efficient revenue sharing.
By listening to business events through message queue tools, generating accounting processing tasks, and combining DSL expression parsers and graph model calculation nodes, accounting graphs are generated. A pluggable algorithm framework is used for account allocation calculation, and a layered decoupled architecture is used for account mapping and route matching to generate immutable atomic ledger vouchers. It also supports differential accounting processing for reverse events.
It enables flexible adaptation to multi-role and multi-expense item accounting in complex business scenarios, avoids rule conflicts, reduces cross-system reconciliation costs, and ensures the traceability of the accounting process and the consistency between accounts and reality.
Smart Images
Figure CN121836701A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of revenue sharing, and in particular to a supply chain multi-role collaborative automatic revenue sharing method and system and a storage medium. BACKGROUND
[0002] In the transaction technology field of supply chain e-commerce and O2O, when sharing the order income, multiple income subjects such as platforms, suppliers, channels / KAs, and fulfillment service providers are often involved. In order to accurately split the income and protect the interests of each subject, a series of technical means for sharing revenue by means of computer technology are available.
[0003] Among the existing technical means, there are common channel-level real-time revenue sharing schemes, platform self-built batch clearing and settlement schemes, and SaaS commission / distribution type schemes. Although these schemes can achieve certain revenue sharing functions, they all have the defects of insufficient rule expression ability and poor adaptation to complex business.
[0004] For example, in the channel-level real-time revenue sharing scheme, only single-layer proportion or fixed amount revenue sharing is supported, and the revenue sharing rules are strongly coupled with the payment channel, making it difficult to adapt to complex business elements such as multi-level roles and cost allocation. In the platform self-built batch clearing and settlement scheme, the asynchronous state change loop processing of orders is complex, and the cross-system reconciliation cost is high. In the SaaS commission / distribution type scheme, when multiple roles are concurrent and multiple scenarios coexist, rule conflicts and cost allocation chaos are prone to occur.
[0005] Therefore, the existing technology has the defects of insufficient rule expression ability and poor adaptation to complex business, and it is difficult to balance the needs of multiple roles, multiple cost items, and multiple scenarios. Therefore, there is an urgent need for a supply chain multi-role collaborative automatic revenue sharing technology that can flexibly adapt to complex business scenarios and achieve precise allocation and efficient revenue sharing of multiple roles and multiple cost items. SUMMARY
[0006] To solve the technical problems raised in the background art of the prior art, on the one hand, the present application provides a supply chain multi-role collaborative automatic revenue sharing method, comprising:
[0007] S1, listening to business events through a message queue tool to generate revenue sharing processing tasks;
[0008] S2, pulling the original data of the business event, parsing and packaging into a unified context object;
[0009] S3, in combination with the DSL expression parser and the graph model calculation node, parsing the pre-configured sharing rule and assembling with the role account node to generate a sharing graph, reading the fields in the sharing processing task, matching the corresponding sharing rule, and performing sharing calculation on each subject in the unified context object through the plug-in algorithm framework to generate a standardized subject sharing detail, and then generating an account execution chain based on the standardized subject sharing detail and the unified context object through the sharing graph to output a structured sharing instruction;
[0010] S4, using a hierarchical decoupling architecture, account mapping and routing matching of the sharing instruction are performed to determine the target account and the clearing and settlement path;
[0011] S5, based on the sharing instruction and the unified context object, atomic accounting is performed to generate an immutable atomic ledger voucher, and a complete account chain that can be traced is formed;
[0012] S6, the sharing information corresponding to the atomic ledger voucher is delivered to the external channel asynchronously and the execution receipt is received, and the reconciliation verification triggers the operation of supplementing, supplementing or correcting, and the account is consistent with the actual.
[0013] Further, it also includes:
[0014] S7, when a reverse event occurs, a difference sharing path is generated based on the sharing graph and a rollback or difference processing is performed, the account voucher is updated, and the reverse event at least includes refund, price change, partial delivery, and finally outputs the settlement single, reconciliation report and audit tracking log.
[0015] Further, in S1, the business events include order creation completion, payment success, full refund, partial refund, performance confirmation and partial performance completion, for each business event, a unique idempotent key is generated based on the business identifier, event type and currently effective rule version number, the business identifier includes order number, payment serial number or performance number, and the idempotent key is used to avoid repeated execution of the sharing processing task;
[0016] When generating the sharing processing task in S1, the original data of the business event, the idempotent key and the currently effective rule version number are associated and bound, and priority identification is made for each sharing processing task.
[0017] Further, S2 further includes the following steps:
[0018] S21, pulling the original data from the business event, the original data including order items, role relationships and subject dimension data;
[0019] S22, based on the pre-configured configuration center and rule version library, the pulled original data is standardized by a dynamic loading mechanism to form standardized information;
[0020] S23 encapsulates standardized information into a unified context object according to a preset structure. The unified context object includes at least order items, participants, subject dimensions, extended fields, version numbers, and idempotent keys. Data validation and default value strategies are executed synchronously during the encapsulation process.
[0021] Furthermore, S3 also includes the following steps:
[0022] S311, multiple algorithm plugins are pre-configured in the plug-in algorithm framework. The algorithm plugins include, but are not limited to, product price allocation plugins, freight allocation plugins, discount allocation plugins, subsidy allocation plugins and tax allocation plugins. Each algorithm plugin is configured to be able to be expanded and hot-updated as needed.
[0023] S312, based on the subject dimension in the unified context object, matches the corresponding algorithm plugin from the plug-in algorithm framework;
[0024] S313 uses the target algorithm plugin to calculate the amount of the corresponding subject, and uses a unified rounding rule to correct the error of the allocation result during the calculation process;
[0025] S314 summarizes and verifies the allocation results of each subject, and allocates the remaining difference to the designated beneficiary or according to the accounting weight ratio of each role according to the preset strategy, and finally generates a standardized subject allocation detail; the standardized subject allocation detail shall at least include subject type, allocation amount, error correction flag, corresponding role identifier and rule version association information.
[0026] Furthermore, S3 also includes the following steps:
[0027] S321, the revenue sharing rules are stored in a preset rule version library in a visual rule tree and JSON format; it supports configuration of ratio, fixed amount, threshold, tier, whitelist, blacklist and time window strategies, and the revenue sharing rules are bound to the currently effective rule version number;
[0028] S322 uses the DSL expression parser to parse the revenue sharing rules into a structured rule tree; it also obtains the role account nodes and role relationships of the platform, supplier, channel / KA, and fulfillment service provider from the role relationship modeling module.
[0029] S323, assemble the structured rule tree with the role account nodes to generate a directed acyclic graph in the form of a revenue sharing graph. The nodes of the revenue sharing graph are configured to correspond to each role account, and the edges of the revenue sharing graph are configured to correspond to the revenue sharing related attributes, including proportion, amount, and crediting timing.
[0030] S324, the preset traversal strategy traverses the ledger diagram, combines the standardized information and standardized account allocation details in the unified context object, performs condition matching and action triggering, and generates an accounting execution chain;
[0031] S325 outputs structured accounting instructions through the accounting execution chain. The accounting instructions include at least the target role account identifier, the corresponding account allocation amount, the accounting ratio, the entry time, the routing label, and the rule snapshot ID. The rule snapshot ID is used to associate the currently executed accounting rule version.
[0032] Furthermore, the layered and decoupled architecture in S5 includes a rules layer, a ledger layer, and a channel layer. The rules layer is used to parse the routing tags and accounting conditions in the accounting instructions. The ledger layer is used to associate the internal account information, accounting period, and freeze / unfreeze policies corresponding to the target role. The channel layer is used to match external settlement channel protocols.
[0033] Furthermore, when S5 masks the protocol differences between different banks and third-party channels, it uses the channel protocol adaptation module to convert the format of the billing instructions and generate a standardized billing request that meets the requirements of the target channel.
[0034] On the other hand, the present invention also provides an automated revenue sharing system for multi-role collaboration in the supply chain, comprising:
[0035] The event acquisition module is used to listen for business events, generate revenue sharing processing tasks and generate unique idempotent keys, and associate and bind the original data of the business event, the idempotent key and the version number of the currently effective rule;
[0036] The context building module is used to retrieve the raw data of business events, parse and encapsulate it into a unified context object;
[0037] The role relationship modeling module is used to maintain the role account nodes and role relationships of the platform, suppliers, channels / key accounts, fulfillment service providers, etc. using a graph model or relationship table.
[0038] The subject allocation module uses a plug-in algorithm framework to perform allocation calculations on each subject in a unified context object and generate standardized subject allocation details.
[0039] The rule orchestration engine module is used to parse the revenue sharing rules and assemble them with role account nodes to generate a revenue sharing diagram. Based on the revenue sharing diagram and standardized account allocation details, it generates an accounting execution chain and produces structured revenue sharing instructions.
[0040] The funds routing module adopts a layered and decoupled architecture to perform account mapping and routing matching for splitting instructions, determine the target account and clearing and settlement path, and shield the protocol differences between different banks and third-party channels.
[0041] The atomic ledger module is used to perform atomic accounting based on the accounting instructions and the unified context object, generate immutable atomic ledger vouchers, and form a traceable complete accounting chain;
[0042] The clearing and settlement channel adaptation module is used to asynchronously send the accounting information to the external channel and receive the execution receipt;
[0043] The reconciliation and exception handling module is used to trigger supplementary order, difference adjustment or reversal operations through reconciliation verification. When a reverse event occurs, it generates the difference accounting path based on the accounting diagram and performs rollback or difference adjustment processing, and updates the accounting vouchers.
[0044] The configuration and rule version management module is used to store revenue sharing rules, algorithm plugin configurations, and role relationship configurations, and supports rule version management and canary releases.
[0045] The audit and results output module is used to record the entire operation log and output settlement statements, reconciliation reports and audit trail logs.
[0046] The present invention also discloses a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above-mentioned automated revenue sharing methods for multi-role collaboration in the supply chain.
[0047] The beneficial effects of this invention are as follows: Through steps S1 and S2, the raw data is collected and preliminarily processed, ensuring the timeliness and consistency of business data processing and providing a unified data foundation for the subsequent revenue sharing process. Then, through step S3, the multiple expense items can be flexibly allocated through allocation calculation, solving the problem of chaotic expense allocation when multiple scenarios coexist in the prior art. Furthermore, step S3 improves the rule expression capability, avoiding the limitations of single-layer revenue sharing and strong coupling between rules and payment channels in the channel-level real-time revenue sharing scheme of the prior art, and avoiding rule conflicts under multiple role concurrency. Step S4 reduces the cost of cross-system reconciliation and improves the problems of complex asynchronous state processing and difficult reconciliation. Finally, steps S5 and S6 achieve the traceability and consistency of the revenue sharing process, thus achieving the overall technical effect of taking into account the needs of multiple roles, multiple expense items and multiple scenarios. Compared with the prior art, it can better complete the revenue sharing task in complex business scenarios. Attached Figure Description
[0048] Figure 1 This is a flowchart of the overall method in one embodiment of the present invention. Detailed Implementation
[0049] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.
[0050] On the one hand, this invention provides an automated revenue sharing method for multi-role collaboration in the supply chain, including:
[0051] S1 listens for business events through message queue tools and generates revenue sharing processing tasks;
[0052] S2 retrieves the raw data of business events, parses and encapsulates it into a unified context object;
[0053] S3, combining the DSL expression parser and graph model calculation node, parses the pre-configured accounting rules and assembles them with role account nodes to generate an accounting graph. It reads the fields in the accounting processing task, matches the corresponding accounting rules, and performs allocation calculations on each subject in the unified context object through a plug-in algorithm framework to generate standardized subject allocation details. Then, based on the standardized subject allocation details and the unified context object, it generates an accounting execution chain through the accounting graph to produce structured accounting instructions.
[0054] S4 adopts a layered and decoupled architecture to perform account mapping and routing matching for splitting instructions, and to determine the target account and clearing and settlement path.
[0055] S5 performs atomic accounting based on accounting instructions and a unified context object, generating immutable atomic ledger vouchers and forming a traceable complete accounting chain;
[0056] S6 asynchronously delivers the sub-account information corresponding to the atomic ledger voucher to the external channel and receives the execution receipt. It triggers supplementary order, difference adjustment or reversal operations through reconciliation verification to maintain consistency between the ledger and the actual situation.
[0057] In this embodiment, the system adopts an event-driven architecture.
[0058] Specifically, steps S1 and S2 collect and preliminarily process the raw data, ensuring the timeliness and consistency of business data processing. This provides a unified data foundation for subsequent revenue sharing processes. Step S3 then uses allocation calculations to flexibly allocate multiple expense items, resolving the chaotic expense allocation problem in existing technologies when multiple scenarios coexist. Step S3 further enhances rule expression capabilities, avoiding the limitations of single-layer revenue sharing and strong coupling between rules and payment channels in existing channel-level real-time revenue sharing solutions. It also avoids rule conflicts under concurrent multi-role scenarios. Step S4 reduces cross-system reconciliation costs and improves the complexity and difficulty of asynchronous state processing and reconciliation. Finally, steps S5 and S6 achieve traceability and consistency between accounts and actual data in the revenue sharing process. Overall, this achieves a technical effect that can accommodate the needs of multiple roles, multiple expense items, and multiple scenarios. Compared to existing technologies, it can effectively complete revenue sharing tasks in complex business scenarios.
[0059] Furthermore, it also includes: S7, which generates a difference accounting path based on the accounting diagram and performs rollback or supplementary processing when a reverse event occurs, updates accounting vouchers, and includes at least refunds, price changes, and partial shipments. Finally, it outputs settlement statements, reconciliation reports, and audit trail logs.
[0060] By configuring S8, traceability can be used to improve the system's performance in complex business scenarios before the final output of settlement statements, reconciliation reports, and audit trail logs, thus avoiding risks such as suspended transactions, duplicate profit sharing, and negative balances in complex situations.
[0061] Furthermore, in S1, business events include order creation completion, payment success, full refund, partial refund, fulfillment confirmation, and partial fulfillment completion. For each business event, a unique idempotent key is generated based on the business identifier, event type, and currently effective rule version number. The business identifier includes the order number, payment transaction number, or fulfillment order number. The idempotent key is used to prevent duplicate execution of the revenue sharing processing task. When executing S1 to generate revenue sharing processing tasks, the original data of the business event, the idempotent key, and the currently effective rule version number are associated and bound, and priority identifiers are assigned to each revenue sharing processing task.
[0062] In existing technologies, batch processing and manual verification are typically used to ensure accounting consistency. However, the above settings, based on the idempotent key settings, achieve good accounting consistency during the generation of accounting splitting tasks. This avoids the shortcomings of existing technologies, such as long cross-system links, complex failure recovery, and difficulty in ensuring consistency between accounting splitting instructions, ledger vouchers, and external entry receipts.
[0063] In various embodiments, the message queue tool uses existing technologies such as Kafka or RabbitMQ for listening, automatically generates accounting processing tasks, and ensures asynchronous decoupling and idempotent execution of events.
[0064] Furthermore, S2 also includes the following steps:
[0065] S21, pull raw data from business events. The raw data includes data on order items, role relationships, and subject dimensions.
[0066] S22, based on a preset configuration center and rule version library, uses a dynamic loading mechanism to standardize the fields of the pulled raw data to form standardized information;
[0067] S23 encapsulates standardized information into a unified context object according to a preset structure. The unified context object includes at least order items, participants, subject dimensions, extended fields, version numbers, and idempotent keys. Data validation and default value strategies are executed synchronously during the encapsulation process.
[0068] Because in existing technologies, the raw data of various business systems, such as transactions, payments, and performance, are often fragmented in format and have chaotic field definitions, lacking a unified standardized processing mechanism, this leads to frequent problems such as data mismatch and missing fields when executing subsequent accounting rules and allocating accounts. This not only requires a lot of manual intervention to complete and verify the data, but also easily causes deviations in the execution of accounting logic.
[0069] Therefore, in particular, S21 comprehensively collects the basic information required for revenue sharing; S22 standardizes the fields of the original data to completely eliminate the differences in data standards between different systems; and S23 integrates scattered data into a data carrier with a unified structure, complete information, and standardized format through the encapsulation of a unified context object and synchronous data verification and default value supplementation strategy.
[0070] The above steps provide a consistent data foundation for subsequent S3 processes such as account allocation and rule evaluation, avoiding issues such as accounting errors and rule execution failures caused by non-standard data. This improves the automated processing capabilities and data reliability of the accounting system, and further optimizes the accuracy and efficiency of the accounting process.
[0071] Furthermore, S3 also includes the following steps:
[0072] S311, multiple algorithm plugins are pre-configured in the plug-in algorithm framework. The algorithm plugins include, but are not limited to, product price allocation plugins, freight allocation plugins, discount allocation plugins, subsidy allocation plugins and tax allocation plugins. Each algorithm plugin is configured to be able to be expanded and hot-updated as needed.
[0073] S312, based on the subject dimension in the unified context object, matches the corresponding algorithm plugin from the plug-in algorithm framework;
[0074] S313 uses the target algorithm plugin to calculate the amount of the corresponding subject, and uses a unified rounding rule to correct the error of the allocation result during the calculation process;
[0075] S314 summarizes and verifies the allocation results of each subject, and allocates the remaining difference to the designated beneficiary or according to the accounting weight ratio of each role according to the preset strategy, and finally generates a standardized subject allocation detail; the standardized subject allocation detail shall at least include subject type, allocation amount, error correction flag, corresponding role identifier and rule version association information.
[0076] In the above steps, due to the setting of S311, the flexible configuration of the pluggable allocation algorithm is realized, which changes the status quo of the existing system algorithm being fixed and implemented separately by various business lines; S312 selects the matching plug-in based on the subject dimension so that each type of subject can be adapted to the algorithm plug-in that best fits the business logic; S313, together with the processing method of S314, avoids the amount confusion caused by allocation error through unified rounding and tail difference management.
[0077] The final standardized account allocation details carry complete account type, allocation amount, corresponding role identifier and rule version association information, forming a controlled allocation detail. This solves the problem of inconsistent allocation standards in the existing system, provides consistent basic data for subsequent accounting processes, and resolves the reconciliation difficulties caused by allocation issues in the existing technology.
[0078] Furthermore, S3 also includes the following steps:
[0079] S321, the revenue sharing rules are stored in a preset rule version library in a visual rule tree and JSON format; it supports configuration of ratio, fixed amount, threshold, tier, whitelist, blacklist and time window strategies, and the revenue sharing rules are bound to the currently effective rule version number;
[0080] S322 uses the DSL expression parser to parse the revenue sharing rules into a structured rule tree; it also obtains the role account nodes and role relationships of the platform, supplier, channel / KA, and fulfillment service provider from the role relationship modeling module.
[0081] S323, assemble the structured rule tree with the role account nodes to generate a directed acyclic graph in the form of a revenue sharing graph. The nodes of the revenue sharing graph are configured to correspond to each role account, and the edges of the revenue sharing graph are configured to correspond to the revenue sharing related attributes, including proportion, amount, and crediting timing.
[0082] S324, the preset traversal strategy traverses the ledger diagram, combines the standardized information and standardized account allocation details in the unified context object, performs condition matching and action triggering, and generates an accounting execution chain;
[0083] S325 outputs structured accounting instructions through the accounting execution chain. The accounting instructions include at least the target role account identifier, the corresponding account allocation amount, the accounting ratio, the entry time, the routing label, and the rule snapshot ID. The rule snapshot ID is used to associate the currently executed accounting rule version.
[0084] In the above process, S321 stores rules in a visual rule tree and JSON format, and supports multiple strategy configurations such as ratio, threshold, and tier, as well as version binding, which solves the defects of fixed rules and single expression in the existing technology and improves flexibility. S322 to S323 construct the rule tree through the DSL parser and assemble it with role account nodes to generate a directed acyclic graph in the form of a ledger graph, which can display multi-level role relationships and realize the visual orchestration of conditional branches. The ledger graph traversal and accounting execution chain generation process in S324 matches the rule logic with role accounts, avoiding the rule conflicts that are easy to occur under the concurrency of multiple roles in the existing technology. The ledger instruction output by S325 carries the rule snapshot ID, which provides a basis for subsequent traceability and further improves the reliability in the face of complex scenarios.
[0085] This rule orchestration method, centered on the revenue sharing graph, overcomes the limitations of existing system rules in terms of expressive power and high expansion costs. It provides a unified framework that enables the real-time orchestration and execution of complex revenue sharing logic involving multiple roles, conditions, and time points.
[0086] Furthermore, the layered and decoupled architecture in S4 includes a rules layer, a ledger layer, and a channel layer. The rules layer is used to parse the routing labels and accounting conditions in the accounting instructions. The ledger layer is used to associate the internal account information, accounting period, and freeze / unfreeze policies corresponding to the target role. The channel layer is used to match external settlement channel protocols.
[0087] The above settings decouple rules, ledgers, and channels. When a business needs to add or switch settlement channels, there is no need to modify the core process. Only the channel layer protocol needs to be adapted to complete the connection, reducing the cost of system expansion and migration. At the same time, the built-in account period and freeze / unfreeze management in the ledger layer, together with risk control rules, further enhances the fund governance capabilities under multi-entity collaboration. From the architectural level, it further improves the stability and flexibility of the system when facing complex scenarios.
[0088] Furthermore, when S4 masks the protocol differences between different banks and third-party channels, it uses the channel protocol adaptation module to convert the format of the billing instructions and generate a standardized billing request that meets the requirements of the target channel.
[0089] On the other hand, the present invention also provides an automated revenue sharing system for multi-role collaboration in the supply chain, comprising:
[0090] The event acquisition module is used to listen for business events, generate revenue sharing processing tasks and generate unique idempotent keys, and associate and bind the original data of the business event, the idempotent key and the version number of the currently effective rule;
[0091] The context building module is used to retrieve the raw data of business events, parse and encapsulate it into a unified context object;
[0092] The role relationship modeling module is used to maintain the role account nodes and role relationships of the platform, suppliers, channels / key accounts, fulfillment service providers, etc. using a graph model or relationship table.
[0093] The subject allocation module uses a plug-in algorithm framework to perform allocation calculations on each subject in a unified context object and generate standardized subject allocation details.
[0094] The rule orchestration engine module is used to parse the revenue sharing rules and assemble them with role account nodes to generate a revenue sharing diagram. Based on the revenue sharing diagram and standardized account allocation details, it generates an accounting execution chain and produces structured revenue sharing instructions.
[0095] The funds routing module adopts a layered and decoupled architecture to perform account mapping and routing matching for splitting instructions, determine the target account and clearing and settlement path, and shield the protocol differences between different banks and third-party channels.
[0096] The atomic ledger module is used to perform atomic accounting based on the accounting instructions and the unified context object, generate immutable atomic ledger vouchers, and form a traceable complete accounting chain;
[0097] The clearing and settlement channel adaptation module is used to asynchronously send the accounting information to the external channel and receive the execution receipt;
[0098] The reconciliation and exception handling module is used to trigger supplementary order, difference adjustment or reversal operations through reconciliation verification. When a reverse event occurs, it generates the difference accounting path based on the accounting diagram and performs rollback or difference adjustment processing, and updates the accounting vouchers.
[0099] The configuration and rule version management module is used to store revenue sharing rules, algorithm plugin configurations, and role relationship configurations, and supports rule version management and canary releases.
[0100] The audit and results output module is used to record the entire operation log and output settlement statements, reconciliation reports and audit trail logs.
[0101] The present invention also discloses a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of any of the above-mentioned automated revenue sharing methods for multi-role collaboration in the supply chain.
[0102] The technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions / computer programs to cause an intelligent control platform device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, as well as electronic devices such as computers, mobile phones, laptops, tablets, and cameras that have the aforementioned storage media.
[0103] The execution process of program data in a computer-readable storage medium can be described with reference to the above method embodiments, and will not be repeated here.
[0104] In one embodiment, after a consumer completes a mobile phone recycling transaction at a store, the order payment needs to be distributed among the platform, the recycler, and the key account (KA) channel, which falls under the recycling business scenario. The roles are the platform, the recycling entity (supplier), and the channel (KA); the accounts include recycling revenue, platform profit sharing, channel profit sharing, shipping costs, subsidies, and taxes; the process involves event collection, context construction, account allocation (recycling price per item / by weight), rule evaluation (platform / channel profit sharing tiers / thresholds), revenue sharing diagram generation, clearing, fund routing to each entity's account, and withdrawal. Channel profit sharing is credited with a delay, and after distribution, it is deposited into a bank virtual account / escrow account, with withdrawals based on payment terms / thresholds.
[0105] Specifically, the system automatically captures the "order completion" event through an event-driven architecture, triggering the revenue sharing task; the rule orchestration engine parses the role relationships and revenue sharing logic based on the configuration template, calculates the profit sharing ratio of each party, and generates a revenue sharing diagram; the revenue sharing diagram drives the accounting engine to execute fund routing, automatically matching bank supervision accounts or virtual sub-accounts and recording the funds; the system completes the writing of accounting vouchers through an atomic ledger mechanism and records the entire process transaction log; for delayed recording, threshold withdrawals, and other situations, the asynchronous clearing module schedules and executes them periodically to ensure accounting accuracy and traceability.
[0106] This embodiment comprehensively applies a technical system of ledger graph-driven, rule orchestration engine, atomic ledger, and three-layer decoupled fund routing to achieve real-time and traceable ledger distribution under multi-role collaboration.
[0107] In another embodiment, the Key Account (KA) purchases from the supplier, who receives a portion of the payment, while the other portion becomes the platform's profit share; this falls under a B2B procurement scenario. The process includes order completion, account allocation (proportionally allocated to each supplier), rule evaluation (platform profit sharing based on thresholds / tiers), generation of a revenue sharing diagram, routing, atomic posting and settlement, withdrawal, and reconciliation. Among these, payment period thresholds and credit limits are managed; reaching the threshold triggers clearing; price protection triggers difference compensation.
[0108] Specifically, the system event service captures order completion events and triggers the revenue sharing engine; the rule orchestration module matches the corresponding rule template according to the order type and automatically evaluates the profit sharing ratio and threshold; the revenue sharing graph generator maps roles and accounts to graph nodes and edge relationships and passes them to the fund routing module; the fund routing module performs the accounting and freezing operations according to the target account and payment period strategy to form atomic ledger records; the system audit service automatically generates accounting logs and discrepancy reports to provide a basis for subsequent financial audits.
[0109] This embodiment demonstrates the flexibility and adaptability of the B2B procurement model. The system can achieve configurability and scalability of multiple types of profit-sharing logic through rule parameterization.
[0110] In another embodiment, after a sales associate places an order and a C-end user completes the order, the order payment needs to be distributed among the platform, supplier, sales associate channel provider, and service provider. This falls under the scenario of private domain sales associates and C-end user orders. The roles are platform, supplier, sales associate channel provider, and service provider. The process includes transaction event capture, context construction, account allocation, rule evaluation (two-tier commission rebate for sales associates + whitelist), revenue sharing diagram generation, fund routing, atomic inflow, asynchronous inflow and outflow, and reconciliation. When a return or partial shipment occurs, a rollback of the difference in revenue sharing is triggered. Sales associate commissions are controlled through a list and a gray-scale strategy to prevent abnormal profit sharing.
[0111] Specifically, after receiving a successful private domain order event, the event engine automatically triggers a revenue sharing task; the rules engine then loads the corresponding whitelist strategy to accurately identify the exclusive revenue sharing logic of KA stores; the revenue sharing chart automatically generates an accounting execution chain based on the identification results and matches it to the corresponding bank or third-party clearing and settlement channel; after the atomic ledger module completes the writing operation of the accounting voucher, the reconciliation engine will periodically compare the channel receipts with the ledger records, and trigger necessary adjustment and reversal operations for any discrepancies; the entire revenue sharing and subsequent processing process is executed automatically by the system, and all accounting data and operation results are fully recorded in the audit log.
[0112] This embodiment demonstrates the system's flexible routing capabilities in multi-channel private domain transactions, ensuring that revenue sharing for multiple roles remains consistent and compliant under different clearing paths.
[0113] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.
Claims
1. An automated revenue sharing method for multi-role collaboration in a supply chain, characterized in that, include: S1 listens for business events through message queue tools and generates revenue sharing processing tasks; S2, retrieve the raw data of the business event, parse and encapsulate it into a unified context object; S3, combining the DSL expression parser and graph model calculation node, parses the pre-configured accounting rules and assembles them with role account nodes to generate an accounting graph. It reads the fields in the accounting processing task, matches the corresponding accounting rules, and performs allocation calculations on each subject in the unified context object through a plug-in algorithm framework to generate standardized subject allocation details. Then, based on the standardized subject allocation details and the unified context object, it generates an accounting execution chain through the accounting graph to produce structured accounting instructions. S4. A layered decoupled architecture is adopted to perform account mapping and routing matching on the revenue sharing instructions to determine the target account and settlement path. S5. Based on the accounting instruction and the unified context object, atomic accounting is performed to generate immutable atomic ledger vouchers, which can form a traceable complete accounting chain. S6, asynchronously deliver the sub-account information corresponding to the atomic ledger voucher to the external channel and receive the execution receipt, trigger the supplementary order, difference supplementation or reversal operation through reconciliation verification to maintain consistency between the account and the actual situation.
2. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 1, characterized in that, Also includes: S7. When a reverse event occurs, generate a difference accounting path based on the accounting diagram and perform rollback or supplementary processing, update accounting vouchers. The reverse event includes at least refund, price change, and partial shipment. Finally, output settlement statement, reconciliation report and audit trail log.
3. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 1, characterized in that, In S1, the business events include order creation completion, payment success, full refund, partial refund, performance confirmation, and partial performance completion. For each of the business events, a unique idempotent key is generated based on the business identifier, event type, and currently effective rule version number. The business identifier includes the order number, payment transaction number, or performance order number. The idempotent key is used to avoid duplicate execution of the split-account processing task. When executing the revenue sharing processing task generated by S1, the original data, idempotent key, and currently effective rule version number of the business event are associated and bound together, and priority identifiers are assigned to each revenue sharing processing task.
4. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 3, characterized in that, S2 further includes the following steps: S21, retrieve raw data from the business event, the raw data including data on order items, role relationships, and subject dimensions; S22, based on the preset configuration center and rule version library, the raw data pulled is subjected to field standardization processing through a dynamic loading mechanism to form standardized information; S23, the standardized information is encapsulated into a unified context object according to a preset structure. The unified context object includes at least order items, participants, subject dimensions, extended fields, version numbers, and idempotent keys. Data validation and default value strategies are executed synchronously during the encapsulation process.
5. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 4, characterized in that, S3 also includes the following steps: S311, In the plug-in algorithm framework, multiple algorithm plug-ins are pre-configured. The algorithm plug-ins include, but are not limited to, commodity price allocation plug-in, freight allocation plug-in, discount allocation plug-in, subsidy allocation plug-in and tax allocation plug-in. Each of the algorithm plug-ins is configured to be able to be expanded and hot-updated as needed. S312, Based on the subject dimension in the unified context object, match the corresponding algorithm plugin from the plug-in algorithm framework; S313, The amount of the corresponding subject is allocated and calculated through the target algorithm plugin. During the calculation process, a unified rounding rule is used to correct the error of the allocation result. S314, summarize and verify the allocation results of each subject, allocate the tail difference to the designated beneficiary according to the preset strategy or according to the accounting weight ratio of each role, and finally generate a standardized subject allocation detail; the standardized subject allocation detail shall at least include subject type, allocation amount, error correction flag, corresponding role identifier and rule version association information.
6. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 5, characterized in that, S3 also includes the following steps: S321, the revenue sharing rules are stored in a preset rule version library in the form of a visual rule tree and JSON format; it supports configuration of ratio, fixed amount, threshold, tier, whitelist, blacklist and time window strategies, and the revenue sharing rules are bound to the currently effective rule version number. S322, the revenue sharing rules are parsed into a structured rule tree using the DSL expression parser; the role account nodes and role relationships of the platform, supplier, channel / KA, and fulfillment service provider are obtained from the role relationship modeling module. S323, The structured rule tree is assembled with the role account nodes to generate a ledger graph in the form of a directed acyclic graph. The nodes of the ledger graph are configured to correspond to each role account, and the edges of the ledger graph are configured to correspond to the ledger-related attributes. The ledger-related attributes include proportion, amount, and crediting timing. S324, the pre-defined traversal strategy is used to traverse the accounting diagram, and the standardized information and standardized account allocation details in the unified context object are combined with the execution condition matching and action triggering to generate the accounting execution chain; S325, the accounting execution chain outputs a structured accounting instruction, which includes at least the target role account identifier, the corresponding account allocation amount, the accounting ratio, the entry time, the routing label, and the rule snapshot ID. The rule snapshot ID is used to associate the currently executed accounting rule version.
7. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 6, characterized in that, The layered decoupled architecture in S4 includes a rule layer, a ledger layer, and a channel layer. The rule layer is used to parse the routing tags and accounting conditions in the accounting instruction. The ledger layer is used to associate the internal account information, accounting period, and freeze / unfreeze policies corresponding to the target role. The channel layer is used to match the external settlement channel protocol.
8. The automated revenue sharing method for multi-role collaboration in the supply chain according to claim 7, characterized in that, When the S4 shields the protocol differences between different banks and third-party channels, it uses the channel protocol adaptation module to convert the format of the billing instructions and generate a standardized billing request that meets the requirements of the target channel.
9. An automated revenue-sharing system for multi-role collaboration in a supply chain, characterized in that, include: The event acquisition module is used to listen for business events, generate revenue sharing processing tasks and generate unique idempotent keys, and associate and bind the original data of the business event, the idempotent key and the version number of the currently effective rule; The context building module is used to retrieve the raw data of business events, parse and encapsulate it into a unified context object; The role relationship modeling module is used to maintain the role account nodes and role relationships of the platform, suppliers, channels / key accounts, fulfillment service providers, etc. using a graph model or relationship table. The subject allocation module uses a plug-in algorithm framework to perform allocation calculations on each subject in a unified context object and generate standardized subject allocation details. The rule orchestration engine module is used to parse the revenue sharing rules and assemble them with role account nodes to generate a revenue sharing diagram. Based on the revenue sharing diagram and standardized account allocation details, it generates an accounting execution chain and produces structured revenue sharing instructions. The funds routing module adopts a layered and decoupled architecture to perform account mapping and routing matching for splitting instructions, determine the target account and clearing and settlement path, and shield the protocol differences between different banks and third-party channels. The atomic ledger module is used to perform atomic accounting based on the accounting instructions and the unified context object, generate immutable atomic ledger vouchers, and form a traceable complete accounting chain; The clearing and settlement channel adaptation module is used to asynchronously send the accounting information to the external channel and receive the execution receipt; The reconciliation and exception handling module is used to trigger supplementary order, difference adjustment or reversal operations through reconciliation verification. When a reverse event occurs, it generates the difference accounting path based on the accounting diagram and performs rollback or difference adjustment processing, and updates the accounting vouchers. The configuration and rule version management module is used to store revenue sharing rules, algorithm plugin configurations, and role relationship configurations, and supports rule version management and canary releases. The audit and results output module is used to record the entire operation log and output settlement statements, reconciliation reports and audit trail logs.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 8.