Technical method for realizing event-driven asset interest calculation

Abstract

The invention discloses a technical method for realizing event-driven asset interest calculation, which relates to the technical field of asset interest calculation and comprises the following specific steps: step 1, scene definition; 2, performing event splitting logic; step 3, business flow; step 4, an event splitter; step 5, event pool; step 6, event calculation logic; step 7, event flow; step 8, an event calculator; and 9, calculating a result. According to the technical method for achieving event-driven asset interest calculation, calculation operation is carried out through an event splitter and an event calculator, the purpose of calculating an interest calculation result is achieved, complex businesses occur in an enterprise all the time, a large number of complex and mutually-staggered business flow lines are formed in the background, and in order to meet the requirements of internal management and external monitoring, the event-driven asset interest calculation is achieved. Various related funds involved in a business pipeline need to be subjected to interest calculation operation to form calculation result background data, and various reports are issued to meet internal and external requirements.

Description

Technical Field

[0001] The present invention relates to the technical field of asset interest calculation, and specifically to a technical method for realizing event-driven asset interest calculation. Background Art

[0002] In order to improve the internal capital utilization efficiency and returns, asset management companies require relevant operation departments to be able to apply for funds from the headquarters, and also deposit idle funds with the headquarters for centralized management of funds; during the process of capital turnover, flexible and complex business operations such as application, additional application, recovery, return, reversal, premium, etc. will be derived; and in these business operations, it is necessary to calculate the interest of the involved funds and assets in detail for internal management requirements of the company and to meet the requirements of regulatory agencies externally.

[0003] In order to improve the capital utilization efficiency and profit returns, a capital centralized management method is implemented; each relevant operation department can apply for funds from the headquarters, and can also deposit idle funds with the headquarters in a timely manner. During this process, flexible and complex business operations such as application, additional application, recovery, return, reversal, premium, etc. will be derived.

[0004] In recent years, with the development of the business and the rapid changes in the economy, the old system architecture is seriously solidified and cannot adapt to the current flexible business scenarios. Moreover, directly upgrading and transforming the original system has high costs, great difficulties, and a long cycle. Therefore, a more advanced and flexible asset interest calculation system is redesigned and developed to improve the support for the current business scenarios, as well as to improve the operation efficiency of financial personnel and the management norms of business personnel.

[0005] Specifically, the following problems exist:

[0006] 1. The application system cannot be updated immediately in terms of time, and it takes one month or even longer to update the system, seriously affecting business development and company management work;

[0007] 2. At the requirement plan level, professional personnel and those who are quite familiar with the original application system are required to sort out the requirements and organize the plan. If not careful, it may cause some related functional points to be not sorted out properly, resulting in abnormal interest calculation of the system and causing actual or indirect losses;

[0008] 3. In terms of system development and testing, it is necessary to arrange developers and testers to design the development plan and write the code, and conduct various test validations such as development testing, sit testing, uat testing, etc.;

[0009] 4. Business personnel of each institution also need to spend time explaining or training new employees on the new system and spend time adapting to the new system;

[0010] 5. Once a logic processing exception occurs in the system, when troubleshooting the problem, it may be necessary to sort out all relevant scenarios before the cause can be found for subsequent processing. Summary of the Invention

[0011] In view of the deficiencies of the prior art, the present invention provides a technical method for realizing event-driven asset interest calculation, which solves the problems raised in the above background art.

[0012] To achieve the above objectives, the present invention is realized through the following technical solutions: A technical method for realizing event-driven asset interest calculation, including the following specific steps:

[0013] Step 1: Scenario definition;

[0014] Step 2: Event splitting logic, specifically as follows:

[0015] For each defined scenario, professionals familiar with the business need to sort out and split the event logic; a scenario is split into one or more business actions according to the changes in funds or assets; several business actions in a scenario need to maintain result consistency during processing, all successful or all failed.

[0016] Step 3: Business process flow, specifically as follows:

[0017] The business and business operations occurring in the enterprise, and the internal management data are digitalized to form a business process flow, and its data is stored in the databases of each upstream business system; each business process flow represents the corresponding business meaning or management process, provided by each specific upstream business system where the business occurs, and then event splitting operations are performed according to the event splitting logic.

[0018] Step 4: Event splitter;

[0019] Step 5: Event pool, specifically as follows:

[0020] When business personnel sort out the event splitting logic, the business actions split from each scenario need to be defined in the event pool, and the event-related information is maintained in the event pool. The information specifically includes event coding, event name, event calculator, and definition information of the funds or asset attributes.

[0021] All business actions need to be operated in the event pool. A scenario is composed of multiple events, and an event is used for the combination of multiple scenarios; the addition or change of a scenario is composed of the defined event combination, or an event in the existing combined event can be adjusted.

[0022] Step 6: Event calculation logic, specifically as follows:

[0023] For each event in the event pool, business personnel need to sort out the calculation logic that affects interest calculation, and then technicians develop and edit code to implement it; when the business is adjusted, only the affected events need to be re-sorted for interest calculation and calculation logic.

[0024] Step 7: Event flow, specifically as follows:

[0025] The business flow generates business action flows through the event splitter and is converted into data and stored in the database. The event flow information includes business action information and business elements related to the business and the action. The event flow is used for subsequent event calculators to calculate interest results.

[0026] Step 8: Event calculator, specifically as follows:

[0027] Develop specific independent interest calculation code plugins through coding and attach them to the events in the event pool; when the business data of the upstream business system is split by event flow, interest calculation is performed according to the event calculator attached to the event definition in the event pool until all event flows in the scenario are calculated.

[0028] Step 9: Calculation results, specifically as follows:

[0029] The process of interest calculation by the event calculator and the final calculation results are all stored in the calculation result table.

[0030] Optionally, the scenario definition is specifically as follows:

[0031] Rely on business personnel or requirement personnel to sort out and analyze the business, and classify the same or similar businesses at the internal management and business operation levels into one category or group and define it as a scenario.

[0032] Optionally, define each business one by one, specifically including scenario coding, scenario name, event splitter, specific business scope description, and corresponding business system.

[0033] Optionally, each scenario definition specifically includes a fund application scenario, an asset accounting scenario, a fund deposit scenario, a recovery scenario, and a disposal scenario;

[0034] Each scenario represents a business operation process and is correspondingly equipped with an independent management method.

[0035] Optionally, when there are operation changes such as business adjustment, addition, or abandonment, business requirement personnel need to analyze whether the existing scenario allows the inclusion of the business. If the business cannot be included in the existing scenario, a new scenario needs to be newly defined to support the business.

[0036] Optionally, the event splitter is specifically as follows:

[0037] According to the sorted event splitting logic, select the corresponding event splitter; when the event splitter receives the business transaction from the upstream business system, split the business transaction according to the business actions in the event splitting logic sorted by the business personnel, and generate one or more event transactions corresponding to the business actions.

[0038] Optionally, the event splitter is attached to the scenario definition, and different scenario definitions correspond to different event splitters.

[0039] Optionally, when the business is adjusted or changed, if there is no new scenario added, there is no need to perform any requirement sorting, code editing, and function testing operations here.

[0040] The present invention provides a technical method for implementing event-driven asset interest calculation, which has the following beneficial effects:

[0041] This technical method for implementing event-driven asset interest calculation realizes abstracting a specific business scenario into multiple related events, and through the calculation logic registered on the events, cooperates with each other to complete business processes such as interest calculation of the specific business scenario;

[0042] If a new business scenario is added or the business scenario changes, only need to re-sort and split the business scenario into several events, and use the existing several events to complete the business process of the new business scenario; for some special business scenarios, only a small number of things (including the implementation of calculation logic) need to be added, and combined with the existing events to form a new business calculation logic; in this way, the entire system does not require additional code development or only needs to write code for the calculation logic of individual new events; greatly reducing the overall system development work and testing work of the system, significantly shortening the project cycle; even when used for a new project, only the implementation logic of some events needs to be modified, achieving the effect of using it everywhere once it is used in one place. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 It is a schematic diagram of the invention process. DETAILED DESCRIPTION OF THE INVENTION

[0044] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments.

[0045] Please refer to Figure 1 , the present invention provides a technical solution: a technical method for implementing event-driven asset interest calculation, including the following specific steps:

[0046] Step 1: Scenario definition, specifically as follows:

[0047] Business personnel or requirement personnel who are familiar with the business organize and analyze, classify the same or similar businesses at the internal management and business operation levels into one category or group, and abstractly define them as a scenario. Define these businesses and directly maintain the corresponding information in the 'Scenario Definition', including scenario code, scenario name, event splitter, specific business scope description, corresponding business system, etc. For example, for each scenario definition such as fund application scenario, asset accounting scenario, fund deposit scenario, recovery scenario, disposal scenario, etc., they can all represent a complete business operation and correspond to a set of internal management methods. When there are changes such as business adjustment, addition or abandonment, business requirement personnel need to analyze whether the existing scenarios can include this business. If a small amount of business cannot be included in the existing scenarios, a new scenario needs to be defined to support this business;

[0048] Step 2: Event splitting logic, which is as follows:

[0049] For each defined scenario, professional personnel who are familiar with the business need to sort out the logic of splitting events in this scenario. Split a scenario into one or more business actions (events) according to the changes in funds or assets. For example, in the fund application scenario, the business actions involving fund changes include the reduction of the amount in the applied-for account of the head office and the increase of the amount in the account where the branch applies for funds. In the asset accounting scenario, it involves both asset and fund change actions, such as the reduction of the account amount where the branch applies for funds and the increase of the physical assets of the branch. Some scenarios involve fewer business actions, while some scenarios involve more and more complex business actions. When specifically splitting different scenarios, the requirements of the company's internal management also need to be considered for splitting business actions, and even vice versa, adjusting the company's internal management methods to make them more reasonable. For several business actions in a scenario, the results should be consistent when being processed, either all successful or all failed;

[0050] Step 3: Business process flow, which is as follows:

[0051] The businesses and business operations that occur in the enterprise, and the internal management data are digitalized to form a business process flow. These data are stored in the databases of various upstream business systems. Each business process flow represents the corresponding business meaning or management process, which is provided by each specific upstream business system where the business occurs, and then used by this solution to automatically split subsequent events according to the event splitting logic;

[0052] Step 4: Event splitter, which is as follows:

[0053] According to the sorted event splitting logic, corresponding event splitters are developed by technical personnel. When the time splitter receives the business transaction flow from the upstream business system, it automatically splits the business transaction flow according to the business actions in the event splitting logic sorted by business personnel, generating one or more event flows corresponding to the business actions. The event splitter is attached to the scenario definition, and different scenario definitions correspond to different event splitters. When the business is adjusted or changed, as long as it does not involve the addition of new scenarios, there is no need to perform any operations such as requirement sorting, code editing, and function testing here;

[0054] Step Five: Event Pool, specifically as follows:

[0055] When business personnel sort out the event splitting logic, the business actions (events) split from each scenario need to be defined in the event pool, and the event-related information is maintained in the event pool. These information include definition information such as event codes, event names, event calculators, and fund or asset attributes. All business actions are maintained here. One scenario may be composed of multiple events, and one event may be used in the combination of multiple scenarios. The addition or change of scenarios may be composed of using the defined events, or adjusting one of the existing combined events. It is equivalent to modular processing, restricting the impact brought by business changes to one or several events, and not causing too much impact on the overall business operation and management on a large scale;

[0056] Step Six: Event Calculation Logic, specifically as follows:

[0057] For each event (business action) in the event pool, business personnel need to sort out the calculation logic that affects interest calculation, and then technical personnel develop and edit the code to implement it. Because the calculation logic for each event is relatively clear and single, when the business is adjusted, only the interest calculation logic of the events that need to be affected needs to be re-sorted, restricting the impact scope to a small range and not affecting most business operations and management;

[0058] Step Seven: Event Flow, specifically as follows:

[0059] The business action flow generated by the business transaction flow through the event splitter is finally converted into data and stored in the database. These event flow information includes business action (event) information and all business elements related to this action of this business. These event flows are used for the subsequent event calculator to calculate the interest calculation result;

[0060] Step Eight: Event Calculator, specifically as follows:

[0061] The event calculator will be a technical staff who, through the organized time calculation logic, codes and develops specific interest calculation code plugins, which are attached to the events in the event pool. When the business data of the upstream business system is split into event flows, the interest calculation is performed according to the event calculator attached to the event definition in the event pool. When all the event flows in the scenario are calculated, the final required interest calculation results are all completed accordingly;

[0062] Step Nine: Calculation Results, which are as follows:

[0063] The process and final results of the event calculator's interest calculation are stored in the calculation result table, including both the final required interest calculation results and the process display of how this result is calculated step by step. This result can be used by UFIDA internally for daily management and management method gap filling, and various reports can also be generated for partners or shareholders to view detailed daily business data, and various reporting data required by regulatory agencies can also be generated.

[0064] Example One: When an existing business changes, the personnel familiar with the business only need to analyze whether the original scenario definition needs to be adjusted; if no adjustment is required, then no operation needs to be done for this change; if adjustment is required, then organize the event splitting logic, the calculation adjustment logic of the involved events, and how the relevant event calculation logic should be adjusted accordingly. Then, the developer only needs to edit the event splitting logic and event calculation logic of this scenario, and the test only needs to test the changed events, with less development and test workload;

[0065] Example Two: When a new business occurs, the personnel familiar with the business only need to analyze whether the existing scenario can include this type of business; if it can be included, then no operation needs to be done for this change; if it cannot be included, then new scenario definitions and event splitting logics need to be added. All use the existing events in the event pool to combine this new scenario, or in the case where some events are not suitable, a new scenario can be combined with most of the existing events and a small number of newly added events; the developer only needs to write code and test the newly added event splitting logic and newly added event calculation logic, greatly reducing the development and test workload and shortening the update time of the application system;

[0066] Conclusion: Through this technical solution, when the business changes, we only need to place the requirements, development, and testing resources in four areas: scenario definition, event splitting logic, event pool, and event calculation logic; there is no need to be very familiar with the entire system, only the business needs to be familiarized; moreover, the newly modified areas are basically isolated from the original logic and do not affect each other, greatly reducing the workload of development and testing; also, for the training of new functions, there is no need for a full-system training, only a local small training of the modified part is required; generally speaking, this technical solution can quickly respond to business changes, local code changes and testing can be carried out for development and testing, and business users can also easily familiarize themselves with the new functions, thus quickly completing the update and normal use of the application system.

[0067] Embodiment 3: Taking a certain asset management company as an example, the core scenarios and events are sorted and divided as follows:

[0068]

[0069]

[0070] Based on the needs of the company's internal management in terms of assets and funds, the scenarios and events are divided into two lines: the asset side and the funds side, and the changes in assets and funds are decomposed in detail respectively; generally, the frequency of scenario changes is very low, and the frequency of event changes is slightly higher. Therefore, under this technical solution, when the business changes, the system technical work mainly focuses on the development and testing of the event calculator corresponding to the newly added events. The calculation logic of each event calculator is relatively simple, and it does not require a large amount of testing resources during testing, and the testing process can also be greatly simplified;

[0071] For the development of the event calculator, code development is carried out according to the event calculation logic sorted out by the business personnel. It only needs to implement the interestDayIntTask method in the parent class AbstractCa l I ntereServi ce, and there is no need to understand the specific business, only the calculation logic needs to be implemented.

[0072] The above is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention, according to the technical solution of the present invention and its inventive concept, makes equivalent substitutions or changes, and all should be covered by the protection scope of the present invention.

Claims

1. A technical method for realizing event-driven asset interest calculation, characterized in that: The specific steps include: Step 1: Scenario definition; Step 2: Event splitting logic, as follows: For each defined scenario, professionals familiar with the business need to organize and split the logic of the events; split a scenario into one or more business actions according to the changes in funds or assets; when processing several business actions in a scenario, the results must be consistent, and all of them must succeed or fail; Step 3: Business flow, as follows: The business, business operations and internal management of an enterprise are digitized to form business flow, and its data is stored in the databases of various upstream business systems. Each business flow represents the corresponding business meaning or management process, which is provided by the upstream business systems where specific business occurs, and then the event splitting operation is performed according to the event splitting logic. Step 4: Event splitter; Step 5: Event pool, as follows: When business personnel organize the event splitting logic, the business actions split from each scenario need to be defined in the event pool, and event-related information needs to be maintained in the event pool. The information specifically includes the event code, event name, event calculator, and definition information of funds or asset attributes; All business actions must be performed in the event pool. A scenario is composed of multiple events, and an event is used to combine multiple scenarios. The addition or change of a scenario can be done by combining defined events or adjusting one of the existing combined events. Step 6: Event calculation logic, as follows: For each event in the event pool, business personnel need to sort out the calculation logic that affects the interest calculation, and then the technical staff will develop and edit the code to implement it. When the business is adjusted, it is only necessary to re-sort the interest calculation and calculation logic of the affected events. Step 7: Event flow, as follows: The business flow is converted into data and stored in the database through the business action flow generated by the event splitter. Its event flow information contains business action information and business elements related to the business and action. Its event flow is used for the subsequent event calculator to calculate the interest calculation results. Step 8: Event calculator, as follows: Develop a code plug-in for specific independent interest calculation and attach it to the events in the event pool. When the business data of the upstream business system is split into event streams, the interest calculation is performed according to the event calculator attached to the event definition in the event pool until all event streams in the scenario are calculated. Step 9: Calculate the results as follows: The interest calculation process of the event calculator and the final calculation results are stored in the calculation result table.

2. A technical method for realizing event-driven asset interest calculation according to claim 1, characterized in that: The scenario definition is as follows: Relying on business personnel or demand personnel to organize and analyze the business, the same or similar businesses at the internal management and business operation levels are classified into one category or one group and defined as a scenario.

3. A technical method for realizing event-driven asset interest calculation according to claim 2, characterized in that: The services are defined one by one, including scenario code, scenario name, event splitter, specific business scope description, and corresponding business system.

4. A technical method for realizing event-driven asset interest calculation according to claim 3, characterized in that: Each of the above scenario definitions specifically includes fund application scenario, asset account creation scenario, fund deposit scenario, recovery scenario, and disposal scenario; Each scenario represents a business operation process and has an independent management method corresponding to it.

5. A technical method for realizing event-driven asset interest calculation according to claim 4, characterized in that: When there are operational changes such as business adjustment, addition or abandonment, business demand personnel need to analyze whether the business is allowed to be included in the existing scenario. If the business cannot be included in the existing scenario, a new scenario needs to be defined to support the business.

6. A technical method for realizing event-driven asset interest calculation according to claim 1, characterized in that: The event splitter is as follows: According to the sorted event splitting logic, the corresponding event splitter is selected; when the time splitter receives the business flow of the upstream business system, it splits the business flow according to the business actions in the event splitting logic sorted by the business personnel to generate one or more event flows corresponding to the business actions.

7. A technical method for realizing event-driven asset interest calculation according to claim 6, characterized in that: The event splitter is attached to the scene definition, and different scene definitions correspond to different event splitters.

8. A technical method for realizing event-driven asset interest calculation according to claim 7, characterized in that: When the business is adjusted or changed, if it does not involve new scenarios, there is no need to perform any requirements sorting, code editing and functional testing operations here.

Images