Cash flow processing method, device and equipment and computer program product

Abstract

The invention discloses a cash flow processing method, device and equipment and a computer program product, and the method comprises the steps: receiving transaction information based on a cash flow strategy implementation class, wherein the transaction information comprises a transaction variety; according to the transaction information, a cash flow subclass implementation class and specific operation corresponding to the transaction variety are determined based on the cash flow strategy implementation class, the cash flow subclass is implemented based on an inherited cash flow abstract parent class, and an abstract method and a template method are packaged in the parent class; instantiating the cash flow subclass to generate a cash flow subclass object; and calling a method in the cash flow subclass object to realize specific operation on the transaction variety cash flow. According to the application, a strategy mode and a template method are combined, upstream transaction information can be received, cash flow subclass instantiation can be automatically completed, and the development difficulty is reduced; customization is realized based on an abstract method, and customization requirements of different business cash flows are met; and service logic and algorithm logic are separated, so that module-level multiplexing capability is provided for subsequent iterative development.

Description

Technical Field

[0001] The present application relates to the technical field of cash flow generation, and in particular to a cash flow processing method, device and equipment, and a computer program product. Background Art

[0002] In the bank's fund management sector, each transaction is accompanied by the generation of cash flow. From the perspective of business needs, cash flow will include basic information such as the currency, amount, status, and time of the transaction. Therefore, the cash flow generated by different transaction types is also different. From the perspective of development technology, the difference in cash flow lies in parameter verification, data field encapsulation, and entity class construction according to the transaction type, while the standardized process content such as cash flow generation, modification, deletion, approval, status change, interest calculation, etc. is basically the same.

[0003] When new business types emerge, the development process becomes complicated due to multi-layer nested judgment statements, and some repetitive non-business logic codes will be superimposed on the business logic, causing inconvenience in subsequent maintenance. Summary of the invention

[0004] The embodiments of the present application provide a cash flow processing method, device and equipment, and a computer program product to reduce the difficulty of developing and maintaining cash flow module functions and improve cash flow generation efficiency.

[0005] The present application embodiment adopts the following technical solutions:

[0006] In a first aspect, an embodiment of the present application provides a cash flow processing method, the cash flow processing method comprising:

[0007] Receive transaction information based on the cash flow strategy implementation class, where the transaction information includes transaction types;

[0008] According to the transaction information, the cash flow subclass implementation class and specific operations corresponding to the transaction product are determined based on the cash flow strategy implementation class, the cash flow subclass implementation class is implemented based on the inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates abstract methods and template methods;

[0009] Instantiate the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type;

[0010] The method in the cash flow subclass object is called to implement specific operations on the cash flow corresponding to the transaction product.

[0011] Optionally, before determining the cash flow subclass implementation class and specific operation corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information, the cash flow processing method further includes:

[0012] Construct multiple cash flow subclass implementation classes based on different types of transaction information and defined inheritance relationships;

[0013] Determining the cash flow subclass implementation class and specific operations corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information includes:

[0014] According to the transaction information, a cash flow subclass implementation class and a specific operation corresponding to the transaction information are determined from a plurality of cash flow subclass implementation classes based on a cash flow strategy implementation class.

[0015] Optionally, the cash flow processing method further includes:

[0016] A mapping relationship is constructed in the memory, wherein the mapping relationship records the key-value pairs of the transaction type and the cash flow subclass implementation class;

[0017] Determining the cash flow subclass implementation class and specific operations corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information includes:

[0018] According to the transaction type, the cash flow subclass implementation class corresponding to the transaction type is determined in the mapping relationship based on the cash flow strategy implementation class.

[0019] Optionally, after constructing multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships, the cash flow processing method further includes:

[0020] Annotate and mark a plurality of cash flow subclass implementation classes;

[0021] The step of constructing a mapping relationship in memory includes:

[0022] Automatically scan each cash flow subclass implementation class based on the annotation identifier of each cash flow subclass implementation class;

[0023] The scanned cash flow subclass implementation class is added as a value to the mapping relationship to form a key-value pair of the transaction product and the cash flow subclass implementation class.

[0024] Optionally, before generating the cash flow corresponding to the transaction information according to the cash flow subclass implementation class and the cash flow abstract parent class inherited by the cash flow subclass implementation class, the cash flow processing method further includes:

[0025] Construct cash flow abstract parent class;

[0026] Abstract methods and template methods are encapsulated in the cash flow abstract parent class.

[0027] Optionally, the abstract method is used to implement customized functions, including cash flow generation, parameter verification and data encapsulation, and the template method is used to implement general functions, including cash flow modification, deletion, approval and interest calculation.

[0028] Optionally, instantiating the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type includes:

[0029] According to the transaction information, the abstract method encapsulated in the cash flow abstract parent class inherited by the cash flow subclass implementation class is rewritten to generate a cash flow subclass object corresponding to the transaction product.

[0030] In a second aspect, an embodiment of the present application further provides a cash flow processing device, the cash flow processing device comprising:

[0031] A receiving unit, configured to receive transaction information based on a cash flow strategy implementation class, wherein the transaction information includes transaction types;

[0032] A determination unit, configured to determine, according to the transaction information and based on the cash flow strategy implementation class, a cash flow subclass implementation class and a specific operation corresponding to the transaction product, wherein the cash flow subclass implementation class is implemented based on an inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates an abstract method and a template method;

[0033] An instantiation unit, used to instantiate the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type;

[0034] The generation unit is used to call the method in the cash flow subclass object to implement specific operations on the cash flow corresponding to the transaction product.

[0035] In a third aspect, an embodiment of the present application further provides a device, including:

[0036] A processor; and a memory arranged to store computer executable instructions, which, when executed, cause the processor to perform any of the cash flow processing methods described above.

[0037] In a fourth aspect, an embodiment of the present application further provides a computer program product, including a computer program / instruction, which implements any of the aforementioned cash flow processing methods when executed by a processor.

[0038] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: the cash flow processing method of the embodiment of the present application first receives transaction information based on the cash flow strategy implementation class, and the transaction information includes transaction types; then, according to the transaction information, the cash flow subclass implementation class and specific operations corresponding to the transaction type are determined based on the cash flow strategy implementation class, and the cash flow subclass implementation class is implemented based on the inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates abstract methods and template methods; then, the cash flow subclass implementation class is instantiated to generate a cash flow subclass object corresponding to the transaction type; finally, the method in the cash flow subclass object is called to implement the specific operation of the cash flow corresponding to the transaction type. The cash flow processing method of the embodiment of the present application adopts a cash flow module developed based on the strategy mode and template method, which can undertake the transaction information transmitted by the upstream transaction system, and automatically complete the instantiation operation of the cash flow implementation class according to the transaction information, reducing the difficulty of developers to manage the cash flow life cycle; at the same time, the customization capability is retained based on the abstract method, meeting the customization requirements of cash flow generation for different types of transactions; the business logic and algorithm logic are separated, providing module-level reuse capabilities for subsequent iterative development. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0040] Figure 1 A business process diagram of a core financial business system in an embodiment of the present application;

[0041] Figure 2 A flow chart of a cash flow processing method in an embodiment of the present application;

[0042] Figure 3 This is a schematic diagram of the implementation process of a cash flow module in an embodiment of the present application;

[0043] Figure 4 This is a structural schematic diagram of a cash flow processing device in an embodiment of the present application;

[0044] Figure 5 This is a schematic diagram of the structure of a device in an embodiment of the present application. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0046] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0047] The main technical terms involved in this application include:

[0048] 1) Strategy pattern: By encapsulating different algorithms into independent classes (i.e., strategies), customers can choose and use different strategies as needed without having to worry about the specific implementation details of the strategies. This approach not only improves the flexibility and reusability of the code, but also simplifies the management and expansion of the algorithms.

[0049] 2) Cash flow: refers to the inflow or outflow of funds in a financial transaction. Cash flow not only includes the actual transfer of funds, but also includes all the detailed information related to the funds, such as currency, amount, status and time of occurrence. In a transaction, each cash flow is formed when funds flow in or out multiple times. Multiple cash flows indicate that multiple inflows or outflows occurred in the transaction.

[0050] 3) Template pattern: a behavioral design pattern that defines the skeleton of an algorithm and leaves the specific steps to subclasses to implement. This pattern allows subclasses to redefine certain steps of the algorithm without changing the algorithm structure.

[0051] 4) Abstract class: It is an important concept in object-oriented programming. It is a class that cannot be instantiated and is mainly used to define the skeleton structure of a class. An abstract class can contain abstract methods (methods without specific implementations) and concrete methods (methods with specific implementations). The main purpose of an abstract class is to provide a common base class so that subclasses can inherit and implement its abstract methods.

[0052] 5) Inheritance: In object-oriented programming, inheritance is an important mechanism that allows a class (called a subclass or derived class) to inherit the properties and methods of another class (called a parent class or base class). Through inheritance, a subclass can obtain all non-private properties and methods of the parent class, and can add new properties and methods, or override the methods of the parent class. The main purpose of inheritance is to promote code reuse and modular design.

[0053] The cash flow processing method of this application is mainly used in the third-generation core financial business system within the bank. The project can adopt an agile development model. The first phase of the project will develop the system around four business types: foreign exchange spot, foreign exchange forward, foreign exchange swap and credit lending. Cash flow, as a record of transactions, will also serve as a reliance and important identifier for subsequent settlement and confirmation of instruction generation.

[0054] like Figure 1 As shown, a business process diagram of a core capital business system in an embodiment of the present application is provided. In the third-generation core capital system of the bank, the cash flow module will support the instructions of the receiving transaction module to modify, delete and approve the cancellation of all unsettled cash flows, and the cash flow number corresponds to the subsequent clearing module instruction number. In order to facilitate the later version backtracking and tracing, and not to generate clearing applications repeatedly, this system introduces a cash flow comparison mechanism when generating cash flow numbers in the new version, that is, the corresponding transaction ID will be recorded in the information field of the cash flow. When the transaction is modified, the transaction ID remains unchanged, but the corresponding cash flow number may change. This depends on whether the field modified by the transaction involves the core six elements of cash flow information: "cash flow type", "payment amount", "payment date", "start date", "end date" and "currency". If involved, the cash flow will be regenerated according to the current status, and the cash flow number will change accordingly. The goal of the first phase of the project will be to design the logic of cash flow generation, modification, deletion, etc. for the common characteristics and differentiated characteristics of the four business varieties.

[0055] Subsequent iterations will be based on the first phase of the project to modify and add requirements, involving more than 20 types of transactions. In order to enable the system to quickly adapt to changing needs, this application uses strategy patterns and template methods to reduce code redundancy, simplify judgment logic and instantiation processes, and automatically create corresponding cash flow entity classes based on upstream module parameters, thereby improving the clarity and maintainability of the project architecture.

[0056] At present, there is no public application solution for the strategy mode and template method in the cash flow generation module of the bank's fund asset management system. So, taking the development of a cash flow module service as an example, we need to provide a unified interface for other internal projects so that cash flow module services of different trading products can be initiated. Although the specific implementation details of these trading products are different, we hope to be able to handle similar cash flow management operations at a high level while retaining the independence of the interface capabilities of each trading product. In this way, each trading product can be independently developed and maintained without affecting the stability and flexibility of the overall system.

[0057] In order to achieve the above functions, traditional solutions often need to create a unified processing interface for receiving upstream instructions, and use a large number of if-else judgment statements to divide the conditions, such as judging the transaction type, whether cash flow is generated, whether the cash flow is in a modifiable state, etc. It also includes instantiation of different classes according to business needs; conversion of data structures according to different message sources; writing business logic unique to each business type, calling different downstream interfaces, etc.

[0058] Since the types of transactions in the fund asset management sector are very complex, including dozens of businesses such as foreign exchange, local currency, bonds, etc., and the cash flow version management mechanism has been introduced, the cash flow number may change in different states and when different fields are modified. The generation of the new version of the cash flow also requires the judgment of many conditions. Taking foreign exchange transactions as an example, spot transactions will generate two cash flows in opposite directions each time, while swap transactions will generate four cash flows in different directions. The transaction start date, end date, transaction amount, transaction direction and other fields in different cash flows will be different. For the cash flow during the duration, if the traditional multi-layer if-else judgment statement method is used, although it is simple, intuitive and easy to develop quickly, there will be at least the following technical problems:

[0059] 1) With the increase of functions in the later stage, the judgment logic will become very complicated, and the main problems will be code redundancy and high maintenance cost;

[0060] 2) Multi-layer judgment statements make it more difficult to write unit tests and improve coverage;

[0061] 3) When adding a new business type, developers need to read the code of the original function and disassemble the code functions. It is difficult to reuse repeated logic, resulting in poor reusability.

[0062] Based on this, this application mainly solves the following technical problems:

[0063] 1) For businesses with complex fund management systems, the traditional flat development method will stack multiple layers of if-else statements, resulting in unclear project architecture and complex code;

[0064] 2) After modifying the cash flow, it is impossible to automatically determine whether a new cash flow is generated;

[0065] 3) The business logic and algorithm logic of the cash flow module cannot be separated, which is not conducive to later maintenance and expansion;

[0066] 4) When adding a new transaction type, the corresponding cash flow entity class cannot be automatically loaded according to the parameters;

[0067] 5) When adding new trading products, repeated code logic is not easy to reuse, resulting in a lot of code redundancy;

[0068] 6) There is no way to automatically control the types of cash flows that can be loaded, and it can only be done manually.

[0069] In view of the above technical problems, the present application embodiment provides a cash flow processing method, such as Figure 2 As shown, a flow chart of a cash flow processing method in an embodiment of the present application is provided, and the cash flow processing method at least includes the following steps S210 to S240:

[0070] Step S210, receiving transaction information based on the cash flow strategy implementation class, wherein the transaction information includes transaction types.

[0071] Combination Figure 3 , a schematic diagram of the implementation process of a cash flow module in an embodiment of the present application is provided. The cash flow processing method of the embodiment of the present application can be executed by a developed cash flow module. The cash flow module of the present application is mainly developed based on the strategy mode and the template method. The cash flow module implements the CashFlowStrategy strategy implementation class, which is used as the entry of the cash flow module, and the logic of the entire cash flow module is written into the method interface of this strategy class.

[0072] When processing cash flow, the cash flow strategy implementation class can receive transaction information from the upstream transaction module. Transaction information can include key fields such as transaction type (such as foreign exchange spot transaction, swap transaction), transaction date, transaction amount, transaction direction, etc.

[0073] Step S220, according to the transaction information, based on the cash flow strategy implementation class, determine the cash flow subclass implementation class and specific operations corresponding to the transaction product, the cash flow subclass implementation class is implemented based on the inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates abstract methods and template methods.

[0074] Based on the cash flow strategy implementation class, the corresponding cash flow subclass implementation class and specific operations (such as adding, deleting, modifying, etc.) can be dynamically selected according to the transaction type field in the transaction information. The cash flow subclass implementation class can be regarded as the class used to ultimately realize cash flow generation. By dynamically selecting the corresponding cash flow subclass implementation class and specific operations based on the cash flow strategy implementation class, the mapping relationship between hard-coded transaction types and cash flow subclasses can be avoided, improving the scalability of the system.

[0075] The cash flow subclass implementation class of the embodiment of the present application is implemented based on the cash flow abstract parent class inherited by the subclass, and the cash flow abstract parent class encapsulates abstract methods and template methods. The abstract method can be implemented by the specific cash flow subclass according to the needs to customize the business process or function to meet the customized needs of generating cash flow for different types of transactions. The template method provides a set of general processing procedures, which can implement standard business processes or functions through subclasses without modifying the parent class code, realize the reuse of repeated code logic, and reduce code redundancy.

[0076] Step S230, instantiating the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type.

[0077] The cash flow subclass implementation class corresponding to the transaction information determined in the above steps is automatically instantiated, that is, a cash flow subclass object is created for subsequent generation of specific cash flows.

[0078] Step S240, calling the method in the cash flow subclass object to implement specific operations on the cash flow corresponding to the transaction type.

[0079] After obtaining the cash flow subclass object, the cash flow subclass object contains the specific logic for generating cash flow. By calling the relevant methods in this cash flow subclass object and passing in the transaction information as a parameter, the relevant methods automatically generate cash flow objects according to the specific business logic of the cash flow subclass object based on the specific fields in the transaction information (such as transaction amount, transaction direction, transaction date, etc.), thereby realizing specific operations on the cash flow of the transaction product.

[0080] When transaction information is modified, the cash flow subclass object can automatically determine whether the cash flow needs to be regenerated based on the modified specific field information.

[0081] The cash flow processing method of the embodiment of the present application adopts a cash flow module developed based on the strategy pattern and template method, which can accept the transaction information transmitted by the upstream transaction system, and automatically complete the instantiation operation of the cash flow implementation class according to the transaction information, thereby reducing the difficulty for developers to manage the cash flow life cycle; at the same time, it retains the customization capability based on the abstract method, and meets the customization requirements of cash flow generation for different types of transactions; it separates the business logic and the algorithm logic, and provides module-level reuse capability for subsequent iterative development.

[0082] In some embodiments of the present application, before determining the cash flow subclass implementation class and the specific operation corresponding to the transaction variety based on the cash flow strategy implementation class according to the transaction information, the cash flow processing method also includes: constructing multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships; determining the cash flow subclass implementation class and the specific operation corresponding to the transaction variety based on the cash flow strategy implementation class according to the transaction information includes: determining the cash flow subclass implementation class and the specific operation corresponding to the transaction information among the multiple cash flow subclass implementation classes based on the cash flow strategy implementation class according to the transaction information.

[0083] Continue to refer Figure 3 Before actually generating cash flow, it is necessary to build multiple cash flow subclass implementation classes based on different types of transaction information and defined inheritance relationships. These subclass implementation classes are extended based on the cash flow abstract parent class, and each subclass implements specific cash flow generation logic for a specific type of transaction information.

[0084] For example, for foreign exchange spot transactions, there can be a ForexSpotCashFlow subclass; for swap transactions, there can be a SwapCashFlow subclass. These subclasses all inherit from the cash flow abstract parent class and implement the abstract methods and template methods defined in the parent class.

[0085] When receiving transaction information, the cash flow strategy implementation class will dynamically select the corresponding cash flow subclass implementation class based on the transaction type field in the transaction information (such as "foreign exchange spot transaction", "swap transaction", etc.). This selection process is carried out in multiple cash flow subclass implementation classes that have been built. The cash flow strategy implementation class will traverse these subclass implementation classes, find the subclass that matches the transaction type in the transaction information, and determine it as the cash flow subclass implementation class that processes the transaction information.

[0086] By building multiple cash flow subclass implementation classes and dynamically selecting the corresponding subclass based on transaction information, new transaction types and cash flow generation logic can be easily added. When a new transaction type needs to be supported, just create a new cash flow subclass implementation class and add it to the system, which improves the scalability of the system. Since each cash flow subclass implementation class is customized for a specific type of transaction information, it is possible to generate cash flow records that conform to specific business logic based on different transaction types. This flexibility enables the system to adapt to various complex business scenarios.

[0087] In some embodiments of the present application, the cash flow processing method also includes: constructing a mapping relationship in memory, the mapping relationship recording the key-value pairs of transaction types and cash flow subclass implementation classes; determining the cash flow subclass implementation class corresponding to the transaction type based on the cash flow strategy implementation class according to the transaction information, and the specific operation includes: determining the cash flow subclass implementation class corresponding to the transaction type in the mapping relationship based on the cash flow strategy implementation class according to the transaction type.

[0088] Continue to refer Figure 3 In order to efficiently determine the corresponding cash flow subclass implementation class based on transaction information, the embodiment of the present application constructs a mapping relationship in memory. This mapping relationship can be stored in the JVM memory and is a key-value pair structure, where the key corresponds to the transaction type and the value is the cash flow subclass implementation class corresponding to the transaction type. By storing the key-value pairs of transaction types and cash flow subclass implementation classes through mapping relationships, when receiving upstream transaction information, the corresponding cash flow subclass implementation class can be quickly found in the mapping relationship according to the transaction type in the transaction information.

[0089] The above process is completed through the cash flow strategy implementation class. The cash flow strategy implementation class can be regarded as an intermediate layer, which is responsible for parsing transaction information and searching in the mapping relationship according to the transaction type.

[0090] By building a mapping relationship, you can quickly find the corresponding cash flow subclass implementation class according to the transaction type. This design greatly improves the search efficiency, reduces the system response time, and improves the user experience. The design of the mapping relationship allows the system to easily add or delete the corresponding relationship between the transaction type and the cash flow subclass implementation class. When you need to support new transaction types, you only need to add new key-value pairs in the mapping relationship, which enhances the flexibility and scalability of the system and enables it to better adapt to the development and changes of the business.

[0091] In some embodiments of the present application, after constructing multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships, the cash flow processing method also includes: annotating and identifying the multiple cash flow subclass implementation classes; constructing a mapping relationship in memory includes: automatically scanning each cash flow subclass implementation class based on the annotation identification of each cash flow subclass implementation class; adding the scanned cash flow subclass implementation class as a value to the mapping relationship to form a key-value pair of the transaction product and the cash flow subclass implementation class.

[0092] Continue to refer Figure 3After building the cash flow subclass implementation class, you can use the @Component or @Service annotation to identify these subclasses. @Component and @Service are annotations in the Spring framework that are used to mark a class as a component or service in the Spring container. These annotations not only provide class metadata, but also enable the Spring container to automatically scan and register these classes at startup for management.

[0093] When the project starts, you can automatically scan the cash flow subclass implementation classes that have been annotated based on the @Component or @Service annotations. This process is usually completed by the component scanning mechanism of the Spring framework, which searches for classes with these annotations under the specified package path and registers them as beans in the Spring container. Of course, in addition to scanning when the project starts, you can also re-scan when the cash flow subclass implementation class changes.

[0094] After scanning all cash flow subclass implementation classes with annotations, add them to the mapping relationship as the values ​​corresponding to the transaction types according to the annotation information and business logic of these classes.

[0095] By introducing the @Component or @Service annotation to identify the cash flow subclass implementation class and combining it with the component scanning mechanism and mapping relationship of the Spring framework, the flexibility and scalability of cash flow processing are improved, the configuration and dependency management are simplified, the maintainability of the system is improved, and complex business logic is supported.

[0096] In some embodiments of the present application, before generating the cash flow corresponding to the transaction information according to the cash flow subclass implementation class and the cash flow abstract parent class inherited by the cash flow subclass implementation class, the cash flow processing method also includes: constructing a cash flow abstract parent class; encapsulating abstract methods and template methods in the cash flow abstract parent class.

[0097] Continue to refer Figure 3 Before building a cash flow subclass implementation class, you need to build an AbstractCashFlowService cash flow abstract parent class. This parent class is the basis of the entire cash flow processing system. It defines some basic rules and methods that need to be followed in the cash flow processing process. By building such a parent class, you can ensure that all cash flow subclass implementation classes follow the same interface and specifications, thereby achieving unified management and maintenance of the code.

[0098] AbstractCashFlowService is used to distinguish transaction types, operation methods, etc. according to the input parameters in the main process, and provide non-abstract template methods to constrain the basic functions of subclasses and standardize standard processes, such as completing operations such as cash flow deletion and approval. At the same time, AbstractCashFlowService also defines special methods that need to be customized, such as generation, parameter verification, data encapsulation, etc. as abstract types to ensure that different subclasses can be rewritten as needed during implementation.

[0099] The embodiment of the present application encapsulates abstract methods and template methods in the cash flow abstract parent class to support the reuse of similar business logic for different transaction types, without having to build a corresponding algorithm flow for each business type. This achieves the separation of business logic and algorithm logic, makes the code clearer and easier to manage, and reduces maintenance costs.

[0100] In addition, since abstract methods and template methods have been defined in the cash flow abstract parent class, developers only need to focus on the cash flow generation logic of specific transaction types without having to write the entire cash flow processing flow from scratch, which greatly improves development efficiency.

[0101] In some embodiments of the present application, the abstract method is used to implement customized functions, including cash flow generation, parameter verification and data encapsulation, and the template method is used to implement general functions, including cash flow modification, deletion, approval and interest calculation.

[0102] Continue to refer Figure 3 , abstract methods are designed to implement customized functions such as cash flow generation, parameter verification, and data encapsulation. These functions are closely related to specific business scenarios and can be customized according to different transaction types, business requirements, user preferences, etc. Abstract methods are defined in abstract classes or interfaces for cash flow processing. They do not implement specific logic, but provide a framework or contract, requiring subclasses or implementation classes to implement these methods according to specific business needs.

[0103] Template methods are used to implement common functions such as cash flow modification, deletion, approval, and interest calculation. These functions are common in multiple cash flow processing scenarios, so they can be abstracted into common logic. Template methods are usually defined in a parent class or base class that contains specific logic, and call one or more abstract methods to complete part of the logic. By implementing these abstract methods, subclasses can customize the behavior of template methods while retaining some of the common logic.

[0104] In an actual cash flow processing system, abstract methods and template methods can be used in combination, that is, a general cash flow processing flow is provided through the template method, and abstract methods are called at key steps, allowing subclasses to provide customized implementations based on specific needs.

[0105] By abstracting common functions into template methods and calling abstract methods in them, the common cash flow processing logic can be reused while allowing subclasses to provide customized implementations. This reduces duplicate code, improves code maintainability and scalability, enables the system to flexibly adapt to different business scenarios, meets diverse user needs, simplifies the development process, and improves development efficiency.

[0106] In some embodiments of the present application, instantiating the cash flow subclass implementation class to generate the cash flow subclass object corresponding to the transaction type includes: rewriting the abstract method encapsulated in the cash flow abstract parent class inherited by the cash flow subclass implementation class according to the transaction information, and generating the cash flow subclass object corresponding to the transaction type.

[0107] Continue to refer Figure 3 , since the transaction information sent from the upstream transaction module can be uniformly instantiated as the required subclass of the AbstractCashFlowService abstract parent class in the CashFlowStrategy strategy implementation class according to different transaction types, these subclasses can use the previously defined interest trial calculation, calculation, cash flow approval, and transaction modification cash flow regeneration method set according to the characteristics of object-oriented programming. On the other hand, due to the differences in data fields of different transaction types, the abstract methods reserved by the parent class can be rewritten in these subclass implementations to complete the specific transaction data assembly method and the construction of transaction data transmission bodies and other customized functions, so as to facilitate the subsequent generation of the required number of specific cash flows.

[0108] In order to facilitate the understanding of the above embodiments, further examples are given to illustrate the generation of foreign exchange spot transaction cash flow as an example: the foreign exchange spot cash flow subclass implementation class FxSpotServiceImpl is defined in advance to inherit from the AbstractCashFlowService abstract parent class, and annotations are added to it.

[0109] When a transaction occurs, the transaction module pushes the transaction message to the cash flow module based on the actual transaction type.

[0110] The CashFlowService strategy implementation class of this application, as the main process of the entire module, will automatically scan the annotated FxSpotServiceImpl subclass and add the subclass as a value to the mapping relationship.

[0111] The information passed in by the transaction is used as the key to find the corresponding foreign exchange spot transaction subclass value in the relationship mapping table to perform the automatic instantiation process.

[0112] During instantiation, common algorithm processes such as modification and approval will be inherited. However, specific logic methods such as parameter verification, data encapsulation, data transmission field conversion, etc. are abstract when the parent class is defined, so they will also be rewritten when defining the spot transaction subclass to achieve customization.

[0113] After instantiation, the CashFlowService strategy implementation class will enter the corresponding spot strategy branch according to the incoming foreign exchange spot status value, advance the main process, that is, complete specific operations such as generation and modification, and finally generate foreign exchange spot transaction cash flow.

[0114] In summary, the key points of this application are mainly:

[0115] 1) Supports automatic generation of transaction type enumeration class and cash flow abstract class mapping table based on different transaction types through annotations;

[0116] 2) Support automatic instantiation of corresponding cash flow entity classes based on transaction parameters;

[0117] 3) Support predefined template methods such as cash flow generation, modification, deletion, interest calculation, etc., and encapsulate the algorithm into an independent interface for calling;

[0118] 4) Support non-template methods such as custom parameter verification, data encapsulation, special functions, etc.;

[0119] 5) Support the separation of business logic and algorithm logic, so that the cash flow module has good maintainability and scalability. In the later iterations, you only need to focus on the development of special business logic, and the public algorithm logic can be reused;

[0120] 6) Supports automatic determination of whether cash flow needs to be regenerated after transaction modification.

[0121] The cash flow processing method of this application has achieved at least the following technical effects:

[0122] This application uses the strategy mode and template method to develop the cash flow module, and builds a framework for the bank's capital asset management sector to manage the entire cash flow life cycle. This framework can achieve the following: accepting transaction information transmitted by the upstream transaction system, and automatically completing the creation, modification, deletion, and approval revocation of cash flow entity classes according to data fields; automatically injecting the corresponding cash flow classes that need to be instantiated according to the business type, reducing the difficulty for developers to manage the cash flow life cycle; separating business logic and algorithm logic, providing module-level reuse capabilities for subsequent iterative development, while retaining customization capabilities and simplifying project architecture and development processes. It is specifically reflected in the following aspects:

[0123] 1) By separating business logic and algorithm logic, the coupling and redundancy of project codes are reduced, thereby improving the maintainability of the cash flow module in the later iterations of agile development projects and improving the development efficiency and scalability of projects with different trading products.

[0124] 2) The loadable cash flow entity classes can be dynamically controlled through annotations and inheritance mechanisms according to business needs, meeting the cash flow processing needs of different business scenarios.

[0125] 3) Implement a strategy to automatically generate cash flow entity classes based on parameters, simplifying development difficulty.

[0126] 4) For the management of new cash flow entity classes, developers only need to rewrite parameter verification and data assembly methods without having to worry about basic functions such as generation, cancellation, and modification, which improves code reusability and development efficiency.

[0127] The present application also provides a cash flow processing device 400, such as Figure 4 As shown, a schematic diagram of the structure of a cash flow processing device in an embodiment of the present application is provided, wherein the cash flow processing device 400 includes: a receiving unit 410, a determining unit 420, an instantiation unit 430 and a generating unit 440, wherein:

[0128] A receiving unit 410 is used to receive transaction information based on the cash flow strategy implementation class, where the transaction information includes transaction types;

[0129] A determination unit 420 is used to determine, according to the transaction information and based on the cash flow strategy implementation class, a cash flow subclass implementation class and a specific operation corresponding to the transaction product, wherein the cash flow subclass implementation class is implemented based on an inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates an abstract method and a template method;

[0130] An instantiation unit 430, used to instantiate the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type;

[0131] The generation unit 440 is used to call the method in the cash flow subclass object to implement specific operations on the cash flow corresponding to the transaction type.

[0132] In some embodiments of the present application, the cash flow processing device 400 also includes: a first construction unit, which is used to construct multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships before determining the cash flow subclass implementation class and specific operations corresponding to the transaction variety based on the cash flow strategy implementation class according to the transaction information; the determination unit is specifically used to: determine the cash flow subclass implementation class and specific operations corresponding to the transaction information among the multiple cash flow subclass implementation classes based on the cash flow strategy implementation class according to the transaction information.

[0133] In some embodiments of the present application, the cash flow processing device 400 also includes: a second construction unit, used to construct a mapping relationship in the memory, wherein the mapping relationship records the key-value pairs of the transaction type and the cash flow subclass implementation class; the determination unit is specifically used to: according to the transaction type, determine the cash flow subclass implementation class corresponding to the transaction type in the mapping relationship based on the cash flow strategy implementation class.

[0134] In some embodiments of the present application, the cash flow processing device 400 also includes: an annotation unit, which is used to annotate and identify multiple cash flow subclass implementation classes after constructing multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships; the second construction unit is also used to: automatically scan each cash flow subclass implementation class based on the annotation identification of each cash flow subclass implementation class; add the scanned cash flow subclass implementation class as a value to the mapping relationship to form a key-value pair of the transaction product and the cash flow subclass implementation class.

[0135] In some embodiments of the present application, the cash flow processing device 400 also includes: a third construction unit, used to construct a cash flow abstract parent class before generating the cash flow corresponding to the transaction information based on the cash flow subclass implementation class and the cash flow abstract parent class inherited by the cash flow subclass implementation class; an encapsulation unit, used to encapsulate abstract methods and template methods in the cash flow abstract parent class.

[0136] In some embodiments of the present application, the abstract method is used to implement customized functions, including cash flow generation, parameter verification and data encapsulation, and the template method is used to implement general functions, including cash flow modification, deletion, approval and interest calculation.

[0137] In some embodiments of the present application, the instantiation unit 430 is specifically used to: rewrite the abstract method encapsulated in the cash flow abstract parent class inherited by the cash flow subclass implementation class according to the transaction information, and generate a cash flow subclass object corresponding to the transaction product.

[0138] It can be understood that the above-mentioned cash flow processing device can implement each step of the cash flow processing method provided in the above-mentioned embodiment. The relevant explanations about the cash flow processing method are applicable to the cash flow processing device and will not be repeated here.

[0139] Figure 5 Schematic diagram of the structure of a device in the embodiment of the present application. Figure 5 As shown, the device includes one or more processors (or processing units), may further include one or more memories coupled to the processors, and may further include a communication module coupled to the processors.

[0140] The communication module can be used to communicate with other devices or apparatuses, such as the transmission or reception of data and / or signals. The communication module can have at least one communication module for communication. The communication module can include any interface necessary for communicating with other devices. Exemplarily, the communication module can be a transceiver, a circuit, a bus, a module, or other types of communication modules.

[0141] The processor may include, but is not limited to, at least one of the following: a general-purpose computer, a special-purpose computer, a microcontroller, a digital signal controller (DSP), or one or more of a controller-based multi-core controller architecture. The device may have multiple processors, such as application-specific integrated circuit chips, which are time-dependent and synchronized with a clock of a main processor.

[0142] The memory may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, at least one of the following: read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, hard disk, compact disc (CD), digital video disc (DVD), or other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, at least one of the following: random access memory (RAM), or other volatile memories that do not persist during the duration of a power outage.

[0143] The computer program includes computer executable instructions executed by an associated processor. The program can be stored in ROM. The processor can perform any suitable actions and processes by loading the program into RAM.

[0144] The possible implementation of the present application can be implemented by means of a program, so that the communication device can perform any process discussed in the above embodiments. The possible implementation of the present application can also be implemented by hardware or by a combination of software and hardware.

[0145] In some embodiments, the program may be tangibly contained in a computer-readable storage medium, which may be included in the device (such as in a memory) or other storage device accessible by the device. The program may be loaded from the computer-readable storage medium to the RAM for execution. The computer-readable storage medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0146] The present application embodiment also provides a computer-readable storage medium, on which computer instructions or program codes are stored, and when the processor runs the instructions or the program codes, the processor executes the methods and functions involved in any of the above embodiments. Computer-readable media can be any tangible medium containing or storing programs for or related to instruction execution systems, devices or equipment. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or devices, or any suitable combination thereof. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media integrations. More detailed examples of computer-readable storage media include electrical connections with one or more wires, magnetic media (e.g., disks, floppy disks, hard disks, tapes, magnetic storage devices), optical media (e.g., optical storage devices, DVDs), semiconductor media (e.g., solid-state hard drives), random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), or any suitable combination thereof, etc.

[0147] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The embodiment of the present application also provides at least one computer program product tangibly stored on a non-temporary computer-readable storage medium. The computer program product includes one or more computer executable instructions, such as instructions included in a program module, which are executed in a device on a real or virtual processor of the target to perform the process, method and function involved in any of the above embodiments. When the computer program instruction is loaded and executed on a computer, a process or function according to an embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instruction can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instruction can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center.

[0148] The present application embodiment also proposes a computer program product, including a computer program or instruction, when the computer program or instruction is run on a computer, the computer is made to perform the process, method and function in the above-mentioned embodiment. Usually, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or realize specific abstract data types. In various embodiments, the functions of program modules can be combined or divided between program modules as needed. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0149] In general, various embodiments of the present application may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be performed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that the boxes, devices, systems, techniques, or methods described herein may be implemented as, for example, non-limiting examples, hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof.

[0150] It should be noted that although the embodiments of the present application are described above in conjunction with the accompanying drawings, the above embodiments are not independent of each other, and they can also be combined to obtain other embodiments. The division of the modes, situations, categories and embodiments in the embodiments of the present application is only for the convenience of description and should not constitute a special limitation. The features in the various modes, categories, situations and embodiments can be combined with each other in a logical manner. The various implementation methods of the present application can be combined arbitrarily to achieve different technical effects. The embodiments of the present application no longer list various combinations.

[0151] In addition, although the operation of the method of the present disclosure is described in a particular order in the accompanying drawings, this does not require or imply that these operations must be performed in this particular order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flow chart can change the order of execution. Additionally or alternatively, some steps can be omitted, multiple steps can be combined into one step for execution, and / or one step can be decomposed into multiple steps for execution. It should also be noted that the features and functions of two or more devices according to the present disclosure can be embodied in one device. Conversely, the features and functions of a device described above can be further divided into being embodied by multiple devices.

[0152] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0153] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A cash flow processing method, characterized in that: The cash flow processing method includes: Receive transaction information based on the cash flow strategy implementation class, where the transaction information includes transaction types; According to the transaction information, the cash flow subclass implementation class and specific operations corresponding to the transaction product are determined based on the cash flow strategy implementation class, the cash flow subclass implementation class is implemented based on the inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates abstract methods and template methods; Instantiate the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type; The method in the cash flow subclass object is called to implement specific operations on the cash flow corresponding to the transaction product.

2. The cash flow processing method according to claim 1, characterized in that: Before determining the cash flow subclass implementation class and specific operation corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information, the cash flow processing method further includes: Construct multiple cash flow subclass implementation classes based on different types of transaction information and defined inheritance relationships; Determining the cash flow subclass implementation class and specific operations corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information includes: According to the transaction information, a cash flow subclass implementation class and a specific operation corresponding to the transaction information are determined from a plurality of cash flow subclass implementation classes based on a cash flow strategy implementation class.

3. The cash flow processing method according to claim 2, characterized in that: The cash flow processing method further includes: A mapping relationship is constructed in the memory, wherein the mapping relationship records the key-value pairs of the transaction type and the cash flow subclass implementation class; Determining the cash flow subclass implementation class and specific operations corresponding to the transaction product based on the cash flow strategy implementation class according to the transaction information includes: According to the transaction type, the cash flow subclass implementation class corresponding to the transaction type is determined in the mapping relationship based on the cash flow strategy implementation class.

4. The cash flow processing method according to claim 3, characterized in that: After constructing multiple cash flow subclass implementation classes according to different types of transaction information and defined inheritance relationships, the cash flow processing method further includes: Annotate and mark a plurality of cash flow subclass implementation classes; The step of constructing a mapping relationship in memory includes: Automatically scan each cash flow subclass implementation class based on the annotation identifier of each cash flow subclass implementation class; The scanned cash flow subclass implementation class is added as a value to the mapping relationship to form a key-value pair of the transaction product and the cash flow subclass implementation class.

5. The cash flow processing method according to claim 1, characterized in that: Before generating the cash flow corresponding to the transaction information according to the cash flow subclass implementation class and the cash flow abstract parent class inherited by the cash flow subclass implementation class, the cash flow processing method further includes: Construct cash flow abstract parent class; Abstract methods and template methods are encapsulated in the cash flow abstract parent class.

6. The cash flow processing method according to claim 1, characterized in that: The abstract method is used to implement customized functions, including cash flow generation, parameter verification and data encapsulation. The template method is used to implement common functions, including cash flow modification, deletion, approval and interest calculation.

7. The cash flow processing method according to any one of claims 1 to 6, characterized in that: The instantiation of the cash flow subclass implementation class to generate the cash flow subclass object corresponding to the transaction type includes: According to the transaction information, the abstract method encapsulated in the cash flow abstract parent class inherited by the cash flow subclass implementation class is rewritten to generate a cash flow subclass object corresponding to the transaction product.

8. A cash flow processing device, characterized in that: The cash flow processing device comprises: A receiving unit, configured to receive transaction information based on a cash flow strategy implementation class, wherein the transaction information includes transaction types; A determination unit, configured to determine, according to the transaction information and based on the cash flow strategy implementation class, a cash flow subclass implementation class and a specific operation corresponding to the transaction product, wherein the cash flow subclass implementation class is implemented based on an inherited cash flow abstract parent class, and the cash flow abstract parent class encapsulates an abstract method and a template method; An instantiation unit, used to instantiate the cash flow subclass implementation class to generate a cash flow subclass object corresponding to the transaction type; The generation unit is used to call the method in the cash flow subclass object to implement specific operations on the cash flow corresponding to the transaction product.

9. A device comprising: processor; and a memory arranged to store computer executable instructions, which, when executed, cause the processor to perform the cash flow processing method of any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instructions are executed by a processor, the cash flow processing method according to any one of claims 1 to 7 is implemented.

Images