Resource object transaction processing method, apparatus, device, and medium

Abstract

The application relates to the technical field of financial data processing, in particular to a resource object transaction processing method and device, equipment and medium, the method comprises the following steps: acquiring general time node configuration information and resource transaction time node configuration information; based on the general time node configuration information and the resource transaction time node configuration information, a multi-level transaction access calendar of a target resource object is constructed; a user transaction order is received, and an order time stamp of the user transaction order and an object identifier of the target resource object are acquired; the multi-level transaction access calendar is called, and matching query is carried out based on the object identifier of the target resource object, so that a current tradable time interval of the user transaction order is acquired; whether the order time stamp falls into the current tradable time interval is judged, and a tradability judgment result is generated, so that the hierarchical configuration and automatic derivation of the fund calendar are effectively realized, the complex open rules can be flexibly adapted, and the accuracy of transaction time judgment and the reliability of business execution are improved.

Description

Technical Field

[0001] This application generally relates to the field of financial data processing technology, and specifically to a method, apparatus, equipment and medium for processing resource object transactions. Background Technology

[0002] Different financial products have different timeframes for settlement operations. For example, different types of fund products (public funds, private funds, fixed-term funds, etc.) have different trading opening rules. Public funds are generally open for settlement operations daily, while private funds are generally open for settlement operations on a monthly, quarterly, or annual basis.

[0003] In existing financial trading systems, the time points for settlement operations of different resource products are typically managed through hard coding or decentralized configuration files. For more complex time points, such as the last trading day of each month or the Nth calendar day of each quarter, manual calculation and entry into the corresponding hard coding or configuration files are often required. This existing decentralized manual configuration method leads to frequent data consistency issues. Settlement time points may experience logical conflicts due to manual calculation errors or untimely updates, resulting in low data processing efficiency and a high configuration error rate. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a resource object transaction processing method, device, equipment and medium that effectively realizes the unified and hierarchical configuration and automated derivation of product calendars, can flexibly adapt to various complex open rules such as daily, periodic, custom and advance order submission, and significantly improve the accuracy of transaction time determination and the reliability of business execution.

[0005] In a first aspect, embodiments of this application provide a method for processing resource object transactions, including: Obtain general time node configuration information and resource transaction time node configuration information. The general time node configuration information is used to indicate the tradable operation time of resource objects within a preset period. The resource transaction time node configuration information is used to indicate the transaction access time of target resource objects. Based on the general time node configuration information and the resource transaction time node configuration information, a multi-level transaction access calendar for the target resource object is constructed. Receive user transaction orders, obtain the order timestamp of the user transaction order and the object identifier of the target resource object; The multi-level transaction access calendar is invoked, and a matching query is performed based on the object identifier of the target resource object to obtain the current tradable time interval of the user's transaction order; Determine whether the order timestamp falls within the current tradable time interval, and generate a tradability determination result for the user's transaction order.

[0006] In one embodiment, constructing a multi-level transaction access calendar for the target resource object based on the general time node configuration information and the resource transaction time node configuration information includes: Based on the general time node configuration information, the tradable operation time is determined, and the basic calendar layer within the preset period is obtained; Based on the configuration information of the basic calendar layer and the resource transaction time node, the basic transaction access window within the preset period is determined, and the transaction access calendar layer of the target resource object within the preset period is obtained. Based on the transaction access calendar layer of the target resource object and the platform transaction configuration information, the platform transaction access window within the preset period is determined, and the platform transaction calendar layer of the target resource object within the preset period is obtained.

[0007] In one embodiment, the resource transaction time node configuration information includes transaction access time information and transaction access offset information. The step of determining the basic transaction access window within the preset period based on the basic calendar layer and the resource transaction time node configuration information, and obtaining the transaction access calendar layer of the target resource object within the preset period, includes: Based on the transaction access time information, obtain the transaction opening start date and transaction opening end date of the target resource object within the preset period; Based on the basic calendar layer, the transaction opening start date, and the transaction opening end date, and according to the transaction admission offset information, the upstream opening date and the upstream order cutoff date within the preset period are determined to obtain the basic transaction admission window; By summarizing all the basic transaction access windows within the preset period, the transaction access calendar layer of the target resource object is obtained.

[0008] In one embodiment, determining the platform transaction access window within the preset period based on the transaction access calendar layer of the target resource object and the platform transaction configuration information, and obtaining the platform transaction calendar layer of the target resource object within the preset period, includes: For the upstream cut-off date in the basic transaction access window, obtain the platform order submission deadline corresponding to the upstream cut-off date based on the platform access offset information; Based on the platform order submission deadline, and combined with the upstream opening date of the basic transaction access window, the platform open transaction date corresponding to the platform order submission deadline is obtained; The platform transaction access window is determined based on the platform order submission deadline and the platform open transaction date, thus obtaining the platform transaction calendar layer.

[0009] In one embodiment, obtaining the platform order submission deadline corresponding to the upstream cut-off date based on platform access offset information for the upstream cut-off date in the basic transaction access window includes: Obtain the advance number of days and the counting unit from the platform access offset information; Using the upstream cut-off date in the basic transaction access window as the base date, the advance number of days is calculated forward according to the counting unit to obtain the platform order submission deadline corresponding to the upstream cut-off date; The counting units include calendar days, resource transaction days, or resource settlement days.

[0010] In one embodiment, the step of invoking the multi-level transaction access calendar, performing a matching query based on the object identifier of the target resource object, and obtaining the current tradable time interval of the user's transaction order includes: In the platform transaction calendar layer, obtain the target platform transaction access window corresponding to the order timestamp; Based on the object identifier of the target resource object, obtain the product configuration information of the target resource object; the product configuration information includes the critical time of division on day T; Based on the target platform's trading access window and the critical moment of day T, a current tradable time interval with left-closed and right-open structure is constructed.

[0011] Secondly, embodiments of this application provide a resource object transaction processing apparatus, comprising: The data acquisition module is used to acquire general time node configuration information and resource transaction time node configuration information. The general time node configuration information is used to indicate the tradable operation time of resource objects within a preset period. The resource transaction time node configuration information is used to indicate the transaction access time of target resource objects. The calendar generation module is used to construct a multi-level transaction access calendar for the target resource object based on the general time node configuration information and the resource transaction time node configuration information. The order receiving module is used to receive user transaction orders, obtain the order placement timestamp of the user transaction order and the object identifier of the target resource object; The interval matching module is used to call the multi-level transaction access calendar, perform matching queries based on the object identifier of the target resource object, and obtain the current tradable time interval of the user's transaction order; The time determination module is used to determine whether the order timestamp falls within the current tradable time interval and generate a tradability determination result for the user's transaction order.

[0012] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in embodiments of this application.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in embodiments of this application.

[0014] Fifthly, embodiments of this application provide a computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the method described in embodiments of this application.

[0015] The resource object transaction processing method provided in this application first acquires two types of data: general time node configuration information and resource transaction time node configuration information. It then aggregates and manages the tradable time rules shared by all resource categories and the transaction access rules specific to each product, eliminating the need for fragmented and independent maintenance of various date data and achieving unified management of the product calendar. Next, it constructs a multi-level transaction access calendar using the two types of configuration information: general time node configuration data carrying general time limit requirements and resource transaction time node configuration information carrying personalized open constraints. This multi-level structure allows for the decomposition of calendar data according to rule hierarchical relationships, and can adapt to multiple open periods through parameter configuration. For various business processes, such as multi-caliber advance order cutoff, compatibility with diverse open rules such as daily, periodic, custom, and advance order submission can be achieved simply by adjusting configuration parameters. During the order processing stage, after obtaining the order placement timestamp and resource object identifier corresponding to the order, the pre-built multi-level transaction access calendar is accurately retrieved based on the object identifier, and a dedicated tradable time range is matched. The complete range is used as the judgment benchmark to verify the order placement timestamp. Compared with scattered date judgment methods, the standardized time range formed by the unified calendar system can effectively reduce judgment errors, improve the accuracy of transaction time judgment from the data source and judgment logic levels, and thus improve the reliability of overall business execution.

[0016] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0017] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 The implementation environment architecture diagram of the resource object transaction processing method provided in the embodiments of this application is shown; Figure 2 This invention illustrates an overall architecture diagram of a calendar system in an implementation environment provided by an embodiment of this application; Figure 3 A flowchart illustrating a resource object transaction processing method provided in an embodiment of this application is shown. Figure 4 This illustration shows a transaction timing and cycle diagram provided in an embodiment of this application; Figure 5 This invention provides a schematic diagram of the structure of a resource object transaction processing apparatus according to an embodiment of the present application. Figure 6 A schematic diagram of the structure of a computer system suitable for implementing an electronic device or server according to embodiments of this application is shown. Detailed Implementation

[0018] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] In existing financial trading systems, the timeframes at which different resource objects can be traded often vary significantly. For example, taking fund products as an example, different products such as public funds, private funds, and periodically open-ended funds have significantly different trading opening rules. Some products are open for subscription and redemption daily, while others are open monthly, quarterly, or annually. Still others require orders to be submitted a certain number of calendar days or trading days in advance, as required by the fund company. The compliant conduct of these transactions relies on the coordinated operation of accurate trading calendars, settlement calendars, opening cycles, and order cut-off rules, placing high demands on the uniformity of the calendar system, the flexibility of the rules, and the accuracy of transaction time determination.

[0021] Currently, most fund transactions employ independent and decentralized calendar processing methods, maintaining separate transaction dates, settlement dates, opening dates, and cut-off dates. Calendar data and opening rules are independent of each other, making it difficult to achieve integrated configuration and automated calculation. Regarding the support capabilities for opening rules, existing technologies typically only support fixed opening cycles such as monthly, quarterly, and yearly configurations, lacking extended capabilities such as weekly opening, opening on the Nth trading day, and custom date opening. They also fail to systematically support complex business scenarios based on advance order submissions in different counting units, making it difficult to cover the differentiated rule requirements of all types of funds. In the transaction execution stage, existing technologies mostly only perform date-level opening judgments, lacking a mechanism to determine the tradable time interval down to the timestamp. This makes it impossible to determine in real-time and accurately whether the current time falls within the fund's legal and valid tradable time period when a user places an order, easily leading to inaccurate opening judgments and incorrect order attribution to day T, affecting the accuracy of transaction execution and business stability.

[0022] For the specific implementation environment of the resource object transaction processing method proposed in this application, please refer to [link / reference needed]. Figure 1 . Figure 1 The implementation environment architecture diagram of the resource object transaction processing method provided in the embodiments of this application is shown.

[0023] like Figure 1 As shown, the implementation environment architecture includes: user terminal 101, resource trading platform server 102, and resource data server 103; where resources specifically refer to financial products, including funds, such as public funds, private funds, and periodically open funds, which are the applicable processing objects of this method.

[0024] User terminal 101 is used to run the resource trading client or trading page, providing users with an interactive interface for subscribing to and redeeming various resource objects. It is used to receive trading orders submitted by users and display the tradable status of each resource object, the trading time range, and order result feedback. User terminal 101 can be a desktop computer, laptop computer, smartphone, tablet computer, super mobile personal computer, netbook, personal digital assistant, etc., but is not limited to these devices.

[0025] The resource trading platform server 102 is connected to the user terminal 101 and the resource data server 103 respectively. The resource trading platform server 102 is used to execute the resource object trading processing method proposed in the embodiments of this application. Based on the user's trading order, order timestamp, target resource object identifier, and multi-level trading access calendar, it determines the current tradable time interval and completes the tradability determination.

[0026] Resource data server 103 is used to maintain and provide general time node configuration information, resource transaction time node configuration information, product configuration information, and multi-level transaction access calendar related data, supporting the resource transaction platform server to complete calendar construction and transaction time determination for each resource object.

[0027] The resource trading platform server 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud computing, cloud storage, network services, middleware services, security services, CDN and big data services.

[0028] The resource trading platform server 102 is directly or indirectly connected to the user terminal 101 and the resource data server 103 via wired or wireless communication. Optionally, the aforementioned wireless or wired network uses standard communication technologies and / or protocols. The network is typically the Internet, but can also be any network, including but not limited to any combination of local area networks, metropolitan area networks, wide area networks, mobile networks, private networks, or virtual private networks.

[0029] To support the generation and operation of a multi-level transaction access calendar, the overall architecture of the calendar system in this implementation environment is as follows: Figure 2 As shown, it consists of three parts: rule configuration, calendar generation, and business invocation. The rule configuration layer writes and maintains configuration information such as resource transaction time node configuration information, resource transaction time node configuration information, and platform transaction configuration information through the web interface. Based on the above configuration information, the calendar generation engine obtains a multi-level transaction access calendar, and then automatically constructs the tradable time interval for the resource object by combining the product configuration information of the resource object. The generated tradable time interval ultimately provides query and invocation services for upstream businesses, and provides standardized data support for resource object transaction processing.

[0030] In addition, to support the configuration, maintenance and management of multi-level transaction access calendars, this implementation environment also includes a resource calendar configuration backend. The resource calendar configuration backend is deployed on the fund trading platform server 102 or a separate configuration management server to provide visualized calendar configuration and rule management functions. Specifically, it includes functional modules such as open rule configuration, resource calendar management, individual calendar management, virtual calendar management and change application management, and supports the creation, editing, querying, batch maintenance, change verification and approval control of calendar rules.

[0031] Among them, the open rule configuration is used to visually set the configuration information of resource transaction time nodes, including but not limited to the transaction open cycle type of resource objects, the rules for determining the transaction open day, the processing strategy for non-trading days, and the rules for advance order cut-off.

[0032] Resource calendar management is used to view, edit, and download the real and virtual calendars of various resource objects.

[0033] Individual calendar management is used to maintain public date information such as market closure days and resource company-specific holidays.

[0034] Virtual calendar management is used to enable pre-generated calendars for funds that have not obtained an official calendar.

[0035] Change request management is used to streamline the process of modifying, taking effect, and tracking calendar configurations.

[0036] Through the above configuration functions, the basic calendar layer, upstream calendar layer, platform transaction calendar layer and public auxiliary calendar can be uniformly configured, automatically calculated and centrally managed, further ensuring the standardization, flexibility and traceability of the multi-level transaction access calendar generation, and providing stable and accurate data support for the resource trading platform server 102 to determine the transaction time cycle.

[0037] The resource object transaction processing method proposed in this application can be implemented by a resource object transaction processing device, which can be deployed on a user terminal or a fund trading platform server.

[0038] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, the method may include more or fewer operation instruction steps based on conventional methods or without inventive effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0039] It should be noted that the acquisition or use of data in the embodiments of this application requires the user's consent. The relevant data can only be obtained after the user's authorization and permission, and the acquisition or use of the data complies with the laws and regulations of the relevant regions.

[0040] Please refer to Figure 3 , Figure 3 A flowchart illustrating a resource object transaction processing method provided in an embodiment of this application is shown. Figure 3 As shown, the method includes: Step 201: Obtain general time node configuration information and resource transaction time node configuration information.

[0041] Two types of configuration information are obtained: The first type is general time node configuration information, which is used to indicate the tradable operation time of resource objects within a preset period. The preset period is a pre-set time range, which can be set to annual, semi-annual, quarterly or custom time intervals. It is used to limit the effective range of calendar generation and date calculation. The corresponding tradable operation time can include basic data such as tradable date and settlement date.

[0042] Among them, the tradable date refers to the date on which users are allowed to initiate normal transaction operations such as subscription and redemption. The configuration content used to determine the tradable date includes information related to the transaction date and / or non-transaction date. The settlement date refers to the date on which funds can be cleared and resource objects can be delivered after the transaction is completed. The configuration content used to determine the settlement date includes information related to the settlement date and / or non-settlement date.

[0043] The second category is resource transaction time node configuration information. This configuration is used to indicate the transaction access time of the target resource object. The corresponding resource transaction time node configuration information is a set of rules for determining the transaction opening time, processing logic and order cut-off requirements of the resource object. Specifically, it includes but is not limited to: opening cycle type, rules for determining the opening day, non-trading day processing strategy, order cut-off rules in advance, and real-time order cut-off time.

[0044] General time node configuration information is the basis for defining the time nodes when resource objects can be traded; resource transaction time node configuration information is the core basis for calculating the time nodes when specific resource objects can be traded (such as calculating the start date and end date of the transaction) and determining the transaction time. Together, they provide a unified and clear calculation standard for the subsequent generation of multi-level transaction access calendars.

[0045] Step 202: Based on the general time node configuration information and the resource transaction time node configuration information, construct a multi-level transaction access calendar for the target resource object.

[0046] The time base range for delivery operations, such as the tradable date and settlement date corresponding to the resource object, is defined by the general time node configuration information. Then, the aforementioned time base range is constrained by the resource transaction time node configuration information to generate a multi-level transaction access calendar.

[0047] This step separates and hierarchically configures the general benchmark trading access rules (such as general time node configuration information) from the specific trading access rules (such as resource trading time node configuration information) for resource objects of specific categories. It eliminates the need to maintain multiple independent dates separately. By simply changing the parameters of different trading access rules, it can adapt to the trading operation scenarios corresponding to various resource objects, improving the efficiency of setting up the settlement operation time node configuration and the flexibility of rule adaptation. The generated multi-level trading access calendar facilitates the rapid location of the corresponding level data based on the resource object identifier and the accurate calculation of the exclusive tradable time interval. It abandons the crude single-day comparison mode, which can effectively reduce the error of transaction time verification and ensure the accuracy and reliability of order access judgment results.

[0048] In this embodiment, there is no limitation on the number of levels or the specific level type of the constructed multi-level transaction access calendar. It can be set according to the actual application needs, such as setting a two-level calendar structure or adding virtual calendars, individual calendars and other additional levels.

[0049] In order to separate the general benchmark transaction access rules, the specific transaction access rules for resource objects of specific categories, and the platform transaction access rules corresponding to the trading platform, and to realize the hierarchical automatic calculation of transaction time nodes and the diversification of the settings for resource object delivery operation time nodes, in one embodiment, a multi-level transaction access calendar can be constructed, which includes a basic calendar layer, a transaction access calendar layer, and a platform transaction calendar layer.

[0050] Specifically, step 102 can be performed according to the following steps: Step 21, determine the tradable operation time based on the general time node configuration information to obtain the basic calendar layer within the preset period; Step 22, determine the basic transaction access window within the preset period based on the basic calendar layer and the resource transaction time node configuration information to obtain the transaction access calendar layer of the target resource object within the preset period; Step 23, determine the platform transaction access window within the preset period based on the transaction access calendar layer of the target resource object and the platform transaction configuration information to obtain the platform transaction calendar layer of the target resource object within the preset period.

[0051] The general time node configuration information indicates the tradable operation time of resource objects within a preset period. Based on the unified delivery time requirements of all categories of resource objects recorded in the general time node configuration information, the tradable date and settlement date of all categories of resource objects within the corresponding preset period are calculated and summarized to form the basic calendar layer.

[0052] The basic calendar layer is used to determine the legal / compliant date range for resource object transactions and fund clearing and settlement, indicating that working days within the preset period are the time for tradable operations, eliminating interference from non-trading days and non-settlement days, ensuring that all upper-level calculations are carried out based on the same set of standard dates, and achieving unified control of the benchmark time.

[0053] The basic transaction access window is the effective transaction period range defined based on the transaction access time corresponding to the target resource object and the tradable operation time in the basic calendar layer; the transaction access calendar layer is the collection of all basic transaction access windows corresponding to the target resource object within a preset period.

[0054] Based on the basic calendar layer, and combined with the resource transaction time node configuration information of the exclusive transaction access rules representing specific categories of resource objects, under the constraints of the basic calendar layer, the basic transaction access window for the target resource object is determined, and the transaction access calendar layer is generated by statistically analyzing the basic transaction access window.

[0055] Taking a fund product as an example, the transaction access calendar layer represents the open dates for subscription and redemption allowed by the fund product. It accurately reflects the time node corresponding to the transaction access time of the fund product itself within the preset period. It is different from the tradable operation time of the basic calendar layer and reflects the time node corresponding to the transaction access time of the fund product.

[0056] For example, the basic calendar layer is used to indicate the working days within a preset period as the time for tradable operations. Suppose that the resource trading time node configuration information of a fund product indicates that the fund product opens for subscription and redemption once a month, and the trading period is fixed from the 5th to the 15th of each month. Based on the tradable operation time corresponding to the basic calendar layer, the time node corresponding to the trading access time of the target resource object can be determined based on the tradable operation time (i.e., working days) within the 5th to the 15th of each month. This yields the basic trading access window. Then, all basic trading access windows within the preset period are counted to generate the trading access calendar layer.

[0057] Based on the transaction access calendar layer, the platform transaction access time corresponding to the platform dimension can be calculated by combining the platform transaction configuration information, the platform transaction access window can be determined, and the platform transaction access window can be statistically analyzed to generate the platform transaction calendar layer.

[0058] The platform transaction calendar layer represents the final timeframe at which target resource objects, both for the trading platform and the user, can be traded. This includes the platform's order cutoff date (when it stops accepting orders) and the opening date (when it begins accepting orders), serving as the ultimate basis for determining transaction time. The platform transaction access window, built upon the basic transaction access window and incorporating platform transaction access rules such as platform access offset information, generates a complete time range for the platform to accept transaction orders.

[0059] Continuing with the previous example, the basic trading access window for this fund is the working days from the 5th to the 15th of each month. According to the platform's trading offset rules, for the platform's trading access window in June, the platform starts accepting trading orders on May 16th and stops accepting trading orders on June 15th. This time period is the platform's trading access window for June. All orders accepted by the platform within this window are accounted for in the June platform trading access window.

[0060] This method generates a unified basic calendar layer using common time node configuration information, establishing a consistent benchmark for tradable and settlement dates for all resource objects. This enables centralized management of transaction access rules, avoiding issues of duplicate calculations and inconsistent standards. Secondly, a transaction access calendar layer is generated on top of the basic calendar layer, incorporating resource transaction time node configuration information. This decouples the benchmark transaction access rules from the specific transaction access rules for individual resource objects, allowing for flexible adaptation to differentiated transaction access times for different resource objects. Adjustments to specific transaction access rules do not require changes to the underlying benchmark transaction access rules. Finally, a platform transaction calendar layer is generated based on the transaction access calendar layer and platform transaction configuration information. This further connects to the transaction control requirements corresponding to the platform's transaction access rules, covering all time constraints. The overall architecture features a clear hierarchical division, with transaction access rules at different levels stored in separate partitions and taking effect independently. The transaction access calendar layers for different categories of resource objects can support various transaction access cycle modes, such as daily, weekly, monthly, quarterly, annual, and custom date opening, through configurable specific transaction access rules, without requiring separate calendar structures for different transaction access cycle modes. The platform's transaction calendar layer supports various order submission requirements, including advance date of the calendar day, advance date of the transaction day, and advance date of settlement. Diverse opening and closing logics are both rule-based and parameterized, and built into the hierarchical generation process, enabling the same calendar system to adapt to the differentiated rules of different resource objects. Simultaneously, the built-in rules support combined use and superimposed calculations; for example, it can be configured to open on the Nth trading day of each month + postpone to the next trading day if it's not a trading day + close 3 trading days in advance. The multi-level structure allows rules to be executed sequentially: first determining the opening day, then calculating the closing day, and finally determining the deadline. The rules do not conflict with each other. This combinable and superimposed rule execution method enables the calendar system to handle complex business scenarios that traditional technologies cannot support, demonstrating strong adaptability.

[0061] Different resource objects have different personalized rules such as transaction opening periods and order cut-off time offsets. In this embodiment, the resource transaction time node configuration information is further subdivided into two categories: transaction access time information and transaction access offset information. Based on the transaction access time information and transaction access offset information, the calculation of the transaction access window and the construction of the transaction access calendar layer are completed step by step.

[0062] Specifically, step 22, based on the configuration information of the basic calendar layer and resource transaction time nodes, determines the basic transaction access window within a preset period, and obtains the transaction access calendar layer of the target resource object within the preset period. This can be performed according to the following steps: Step 221, based on the transaction access time information, obtain the transaction opening start date and transaction opening end date of the target resource object within the preset period; Step 222, based on the basic calendar layer, the transaction opening start date, and the transaction opening end date, and according to the transaction access offset information, determine the upstream opening date and upstream cut-off date within the preset period, and obtain the basic transaction access window; Step 223, summarize all basic transaction access windows within the preset period to obtain the transaction access calendar layer of the target resource object.

[0063] The transaction access time information stores configuration data for the transaction access cycle rules corresponding to the target resource object. This includes, but is not limited to, the transaction access cycle mode and the start and end dates of the cycle under the corresponding transaction access cycle mode. It is used to define the transaction access cycle of the target resource object (e.g., daily, weekly, monthly, semi-annually), providing the original time boundary benchmark for the transaction access cycle. For example, in the resource transaction time node configuration information of a fund product, if the transaction access cycle mode is monthly, and the start and end dates are the 5th and 15th respectively, it means that the fund product opens for subscription and redemption once a month, with the trading period fixed from the 5th to the 15th of each month.

[0064] Specifically, after obtaining the transaction access time information, the transaction access period corresponding to the target resource object within a preset period can be determined based on the transaction access cycle mode and the cycle start and end times within that mode. The transaction opening start and end dates for each cycle are also determined accordingly. Continuing with the example of the aforementioned fund product, based on the tradable operation time corresponding to the basic calendar layer, each month within the preset period can be defined as a transaction access cycle, with the transaction opening start and end dates for each cycle being the 5th and 15th of that cycle, respectively.

[0065] Among them, the upstream open date refers to the time node in each transaction access period within the preset period when resource object transaction operations can be carried out, and the upstream cut-off date refers to the time node in each transaction access period within the preset period when resource object transaction operations are stopped. The transaction access offset information is a time correction configuration parameter superimposed on the basic transaction cycle rules. It includes the correction offset corresponding to the transaction opening start date and the transaction opening end date. It is used to calculate the upstream opening date and upstream order cut-off date corresponding to the upstream business link based on the basic transaction cycle rules, and generate a basic transaction access window that adapts to the business process.

[0066] Specifically, after determining the start and end dates of the trading opening for each trading access period within the preset period, the upstream opening date and upstream cut-off date are calculated based on the correction date offset indicated by the trading access offset information. This avoids conflicts between the start and end dates of the trading opening for each trading access period and the tradable operation time indicated by the basic calendar layer. As a result, a basic trading access window corresponding to each trading access period is formed, realizing the extended calculation from the basic trading time to the upstream control time.

[0067] For example, it can be determined whether the trading opening deadline within the trading admission period is the tradable operation time indicated by the basic calendar layer. If so, the trading opening deadline is directly determined as the upstream order cutoff date. If not, the trading opening deadline is modified based on the transaction correction offset indicated by the trading admission offset information to determine the upstream order cutoff date.

[0068] Using the correction offset indicated by the trading access offset information as a forward offset of 1 calendar day, the trading opening deadline within this trading access period, such as May 15th, is not a tradable operation time indicated by the basic calendar layer. It can be used as the upstream order cutoff date, shifted forward 1 calendar day from the trading opening deadline date based on the correction offset indicated by the trading access offset information. It is understood that if the shifted date is still not a tradable operation time, the shift will be repeated until it falls within a tradable operation time; the specific strategy is defined by the trading access offset information.

[0069] After determining the start and end dates of the trading opening, which are corrected by the trading opening offset information and correspond to the trading access period, the opening dates of each upstream entity within the trading access period and the corresponding upstream cut-off date can be determined based on the corrected start and end dates of the trading opening. This yields the basic trading access window corresponding to the trading access period. All basic trading access windows within the preset period are then integrated to form a complete trading access calendar layer.

[0070] For example, a fund product presets the official trading opening start date as day T and the end date as day T-5 within a trading period. After verifying the validity of the date by combining the basic calendar layer, the offset rule corresponding to the trading access offset information is used to extend forward by two trading days, resulting in the upstream opening date as day T-2 and the upstream order cut-off date as day T-7. This constitutes a single basic trading access window. By summarizing all similar windows within the period, the corresponding trading access calendar layer for the fund can be generated.

[0071] This embodiment separates the resource transaction time node configuration information into two independent configuration parameters: transaction access time information and transaction access offset information. These parameters are used to perform two calculations: defining the transaction access cycle and calculating the upstream time offset. Step 221 defines the transaction access cycle based on the transaction access time information, and step 222 calculates the upstream date offset based on the transaction access offset information. This allows for separate configuration, modification, and maintenance of the two types of rule parameters without requiring changes to the other type of parameter, reducing the difficulty of rule adjustments and the risk of errors in manual calculations. Furthermore, it enables independent calculations based on parameters such as the differentiated opening periods for different target resource objects, accurately generating a basic transaction access window with exclusive transaction access rules for each resource object. This ensures the accuracy and rigor of the calculated upstream opening date and upstream cut-off date, and is compatible with diverse business scenarios such as daily opening, periodic opening, custom opening, and multi-caliber offset cut-off, significantly improving the scenario compatibility of the entire multi-level transaction access calendar construction solution.

[0072] In actual fund and other resource trading businesses, the platform also has independent requirements for order acceptance and transaction time limit control. The upstream cut-off date on the product side cannot be directly equated with the platform's final order acceptance time limit. In order to connect the exclusive transaction access rules with the platform transaction access rules and accurately calculate the platform's exclusive transaction time period, this embodiment further proposes a method for generating a platform transaction calendar layer. Step 23: Based on the transaction access calendar layer of the target resource object and the platform transaction configuration information, determine the platform transaction access window within a preset period to obtain the platform transaction calendar layer of the target resource object within the preset period. Specifically, it can be executed according to the following steps: Step 231: For the upstream cut-off date in the basic transaction access window, obtain the platform order submission deadline corresponding to the upstream cut-off date based on the platform access offset information; Step 232: Based on the platform order submission deadline, combine the upstream opening date of the basic transaction access window to obtain the platform open transaction date corresponding to the platform order submission deadline; Step 233: Determine the platform transaction access window based on the platform order submission deadline and the platform open transaction date to obtain the platform transaction calendar layer.

[0073] Among them, the platform access offset information refers to the independent time correction configuration parameter superimposed on the upstream cut-off date of the basic transaction access window and used for the conversion of the platform's order acceptance time limit. It is included in the platform transaction configuration information and is used to convert the platform's order submission deadline based on the upstream cut-off date in the basic transaction access window, providing the offset calculation basis for the generation of the platform's transaction access window.

[0074] Specifically, step 231 uses the upstream cut-off date within the basic transaction access window as the calculation basis, and combines it with the platform access offset information to calculate the corresponding platform order submission deadline, completing the conversion from the product-side cut-off time to the platform order acceptance deadline; step 232 uses the platform order submission deadline as the benchmark, and combines it with the upstream opening date of the basic transaction access window corresponding to the transaction access cycle, according to the platform transaction access rules, to obtain the start date of the platform's official opening of transactions in the corresponding transaction access cycle, thus obtaining the platform's open transaction date; step 233 combines the obtained platform open transaction date and platform order submission deadline to define the platform transaction access window corresponding to the transaction access cycle, and integrates them to form the final platform transaction calendar layer.

[0075] For example: If the upstream order cutoff date for a certain fund product in the transaction access cycle is day T, after conversion based on the platform access offset information, the platform order submission deadline is determined to be day (T-1). Based on this deadline, combined with the upstream opening date of the corresponding basic transaction access window in the transaction access cycle, and according to the platform transaction access rules, if we advance one upstream opening day, we find that the platform's open trading date is day (T-2). Thus, the platform transaction access window is determined to be from day (T-2) to day T. After summarizing the transaction access windows of each platform, the corresponding platform transaction calendar layer can be generated.

[0076] This method combines exclusive transaction access rules, platform access offset information, and platform transaction rules to extrapolate platform time periods. It reuses existing platform access offset information for conversion, eliminating the need to repeatedly configure the offset rules corresponding to the platform access offset information and reducing redundant parameter settings. At the same time, it extrapolates dates based on resource transaction days, automatically avoiding interference from non-transaction days, and sequentially determines the start and end nodes of platform transactions and defines the access window, which can reduce the probability of time determination errors.

[0077] To further improve the accuracy and versatility of the cut-off date calculation and to make the calculation process compatible with counting rules of different business scopes, in one embodiment, the platform order submission deadline in step 231 can be calculated in the following way: obtain the advance number of days and the counting unit in the platform access offset information; take the upstream cut-off date in the basic transaction access window as the base date, and calculate the advance number of days according to the counting unit to obtain the platform order submission deadline corresponding to the upstream cut-off date; wherein, the counting unit includes calendar days, resource transaction days or resource settlement days.

[0078] This method incorporates the counting unit as a configurable parameter into the calculation logic, rather than fixing a single calculation caliber. This allows the same calculation process to be compatible with various business calibers. For example, a public fund uses the fund trading day as the order cutoff counting unit and requires orders to be submitted 3 fund trading days in advance. The system can directly select this counting unit and the number of days to complete the calculation. A private fund requires orders to be submitted 5 calendar days in advance, and only needs to switch the counting unit to calculate accurately. Another fund product uses the fund settlement date as the basis and requires orders to be submitted 2 fund settlement days in advance. Similarly, accurate calculation can be achieved by selecting the corresponding unit. In addition, for non-daily open products such as monthly, quarterly, and custom open products, this method can still independently calculate the platform order submission deadline based on the corresponding upstream opening date and different counting units, without modifying the core logic throughout the process, thus adapting to the complex order cutoff scenarios of all types of funds.

[0079] In addition, the multi-level transaction access calendar of this application may also include a public auxiliary calendar layer, which is used to support the generation, maintenance and expansion of the basic calendar layer, and may specifically include individual calendars, real calendars and virtual calendars.

[0080] Among these, some calendars are public market calendars used to maintain high-frequency public dates such as market closure days and fund company-specific holidays. These can be merged into the trading and settlement calendars of various funds to achieve unified maintenance and reuse of public dates. The real calendar is constructed based on the official trading and settlement calendars actually provided by fund companies or trading markets, serving as the authoritative date basis for online formal trading, order attribution (T-day), and fund clearing and settlement. The virtual calendar is a pre-launch trading and settlement calendar automatically generated according to preset default rules before obtaining the official annual calendar from fund companies. It provides date support during product launch preparation, rule configuration, and system testing phases, ensuring that business processes can be started in advance without relying on the official calendar release schedule. By introducing the above-mentioned public auxiliary calendars, this application can achieve flexible generation, authoritative verification, and pre-emptive availability of the basic calendar, further improving the completeness, universality, and scenario coverage of the multi-level trading access calendar, making calendar configuration and date calculation more efficient, standardized, and reliable.

[0081] Step 203: Receive user transaction orders and obtain the order timestamp of the user transaction order and the object identifier of the target resource object.

[0082] After a user initiates a transaction order for a target resource object (such as a fund) through the front-end transaction interface, the system receives and parses the transaction order, extracts and generates an order timestamp corresponding to the order submission time from the order information, and extracts an object identifier to uniquely identify the target resource object, thus obtaining the core elements for order determination. The order timestamp is used to accurately mark the specific time of order submission, serving as the time basis for subsequent determination of whether it falls within the current tradable time range; the object identifier is used to uniquely distinguish different resource objects, ensuring that subsequent retrieval of the multi-level transaction access calendar and product configuration information corresponding to the resource object is accurate based on this identifier.

[0083] Step 204: Invoke the multi-level transaction access calendar, perform a matching query based on the object identifier of the target resource object, and obtain the current tradable time interval of the user's transaction order.

[0084] The current tradable time interval includes the valid submission period for orders of different order types, i.e., the valid trading time range. Using the object identifier of the target resource object as an index, a query request is initiated in the multi-level transaction access calendar, which includes the basic calendar layer, the transaction access calendar layer, and the platform transaction calendar layer. Based on the object identifier of the target resource object, data matching is completed, and combined with the time data corresponding to each level of the calendar and the preset time rules, the tradable time interval corresponding to the current user's transaction order is directly determined, and the valid submission period for different order types is distinguished.

[0085] Among them, the multi-level transaction access calendar provides a unified and standardized date benchmark and calculation basis for determining the tradable time interval. The object identifier of the target resource object is used to realize the accurate association between the multi-level transaction access calendar and the corresponding resource product, ensuring that the finally determined tradable time interval is consistent with the exclusive transaction access rules of the target resource object.

[0086] Step 205: Determine whether the order timestamp falls within the current tradable time range, and generate the tradability judgment result of the user's transaction order.

[0087] The order timestamp is the precise moment when the user submitted the order. The current tradable time interval includes the valid submission periods for orders of different order types. After obtaining the current tradable time interval, it can be determined whether the time corresponding to the order timestamp is within the coverage of the current tradable time interval. Based on the determination result and the order type of the user's transaction order, a tradability judgment result is generated to characterize whether the transaction meets the time requirements. For example, if the current tradable time interval includes the valid submission periods for orders of the real-time order type, and the user's transaction order type is a real-time order, the tradability judgment result of the user's transaction order can be determined as not allowing the order to be placed. At the same time, a transaction order of the reservation order type can be generated based on the user's transaction order.

[0088] For example, the system first determines that the current period is June 2026. Combining the platform's transaction calendar and product configuration information, it determines that the current tradable time range for a real-time order is from 09:00 on June 25, 2026 to 15:00 on June 25, 2026. If the user submits an order with a timestamp of 16:01 on June 25, 2026, the system compares this timestamp with the current tradable time range. It finds that this time exceeds the upper limit of the range and does not fall within the current tradable time range. Based on this, a judgment result is generated, rejecting the real-time order submission. Simultaneously, according to the exclusive transaction access rules, this order may be marked as a reservation order for the next period.

[0089] Traditional solutions often suffer from problems such as ambiguous transaction time boundaries, coupling of T-day division rules with calendar configuration, and inconsistent start and end time definitions, leading to deviations in determining tradable time intervals and failing to meet the stringent requirements of fund subscription and redemption businesses for time precision and rule consistency. To improve the accuracy and standardization of time determination, in one embodiment, the process of determining the current tradable time interval of a user's transaction order can be performed according to the following steps: In the platform's transaction calendar layer, obtain the target platform transaction access window corresponding to the order timestamp; obtain the product configuration information of the target resource object based on the object identifier of the target resource object; the product configuration information includes the T-day division threshold time; construct the current tradable time interval with a left-closed and right-open structure based on the target platform transaction access window and the T-day division threshold time.

[0090] By defining the overall date range using the platform's transaction access window and then further refining it to specific times by overlaying the T-day threshold, the system achieves precision down to the hour, minute, and second level. Combined with a left-closed, right-open interval format, this precisely aligns with the exclusive transaction access rules that require transactions to take effect and close on time, effectively avoiding ambiguity in time boundary determination. Furthermore, calendar period data and product configuration information such as the T-day threshold are stored separately, rather than being uniformly fixed in the calendar data. Instead, the calendar service queries the T-day threshold configured for fund listing in real time when constructing time boundaries. This decouples and manages calendar data, product parameters, and exclusive transaction access rules, significantly improving the accuracy, configurability, and system compatibility of time interval construction.

[0091] For example, when a user initiates a transaction order, the system first matches the order's timestamp in the platform's transaction calendar layer to find the corresponding target platform transaction access window, which is from May 4th to May 5th, 2026. Then, it retrieves the product configuration information through the identifier of the resource object and finds that the critical time for dividing day T is 09:30:00. Combining the access window and the critical time, a left-closed, right-open tradable time interval is finally constructed: May 4th, 2026 09:30:00 ≤ Transaction Time < May 5th, 2026 09:30:00. This is used as the time basis for order validity verification. If the real-time order timestamp is within the interval, the real-time order is allowed, and the subsequent risk control and order placement process continues. If it is not within the interval, it can determine whether a reservation order can be placed or indicate that the transaction is not allowed. In the event of a scenario such as the one-time fundraising ending, it can return that the current period does not exist, and the caller is prohibited from placing an order.

[0092] like Figure 4The diagram illustrates the transaction timeline and cycle, showcasing the timeline logic for determining the validity of user orders. Centered on a horizontal timeline, it is divided into four levels from top to bottom: order type, platform and upstream key nodes, natural day, and open cycle. In this application, the current period is defined as the time interval from the end time of the previous real-time order to the end time of the current real-time order, where customer orders within this interval belong to the same upstream open day. The initial phase includes the following key elements: upstream open date (the date on which the fund company can accept orders), platform order deadline (the deadline for submitting orders to the fund company based on the fund company's order deadline requirements, plus internal buffer time, and is the order day T), platform open date (the date on which customers can place real-time orders or reservation orders take effect), real-time order start time (real_time_order_begin_ts, the starting second-level timestamp of real-time orders that can be placed in this period, left-closed), and real-time order end time (real_time_order_end_ts, the ending second-level timestamp of real-time orders that can be placed in this period, right-open).

[0093] In the business timeline, user orders are categorized into three types based on submission time: pre-orders, reserved orders, and real-time orders. Corresponding to different stages in the preceding period, key nodes include the start time of the open period, the start time of real-time orders, and the end time of real-time orders, clearly defining the valid submission boundaries for each type of order. Simultaneously, key nodes such as the platform's open day and pre-open day, and the upstream's subscription day and redemption day, are coordinated through a multi-level transaction access calendar, forming a one-to-one mapping with calendar days and open periods. This ensures the consistency of the timeline between user order submission, platform rule execution, and upstream clearing. Based on this timeline logic, this method can automatically determine the tradability of funds by comparing the user's order timestamp with the tradable time interval, ensuring the standardization and accuracy of the transaction process.

[0094] It should be noted that although the operation of the method of the present invention is described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed in order to achieve the desired result.

[0095] Figure 5 A schematic diagram of the structure of a resource object transaction processing apparatus provided in an embodiment of this application is shown.

[0096] like Figure 5 As shown, the resource object transaction processing device 10 includes: The data acquisition module 11 is used to acquire general time node configuration information and resource transaction time node configuration information. The general time node configuration information is used to indicate the tradable operation time of resource objects within a preset period, and the resource transaction time node configuration information is used to indicate the transaction access time of target resource objects.

[0097] The calendar generation module 12 is used to construct a multi-level transaction access calendar for the target resource object based on general time node configuration information and resource transaction time node configuration information.

[0098] The order receiving module 13 is used to receive user transaction orders and obtain the order placement timestamp and the object identifier of the target resource object.

[0099] The interval matching module 14 is used to call the multi-level transaction access calendar, perform matching queries based on the object identifier of the target resource object, and obtain the current tradable time interval of the user's transaction order.

[0100] The time judgment module 15 is used to determine whether the order timestamp falls within the current tradable time range and generate the tradability judgment result of the user's transaction order.

[0101] In some embodiments, the calendar generation module 12 is specifically used to: determine the tradable operation time based on general time node configuration information to obtain a basic calendar layer within a preset period; determine the basic transaction access window within a preset period based on the basic calendar layer and resource transaction time node configuration information to obtain a transaction access calendar layer for the target resource object within a preset period; and determine the platform transaction access window within a preset period based on the transaction access calendar layer for the target resource object and platform transaction configuration information to obtain a platform transaction calendar layer for the target resource object within a preset period.

[0102] In some embodiments, the calendar generation module 12 is further configured to: obtain the transaction opening start date and transaction opening end date of the target resource object within a preset period based on the transaction access time information; determine the upstream opening date and upstream cut-off date within the preset period based on the basic calendar layer, the transaction opening start date and the transaction opening end date, and according to the transaction access offset information, to obtain the basic transaction access window; and summarize all basic transaction access windows within the preset period to obtain the transaction access calendar layer of the target resource object.

[0103] In some embodiments, the calendar generation module 12 is further configured to: obtain the platform order submission deadline corresponding to the upstream cut-off date in the basic transaction access window based on the platform access offset information; obtain the platform open transaction date corresponding to the platform order submission deadline by taking the platform order submission deadline as a benchmark and combining it with the upstream open date in the basic transaction access window; determine the platform transaction access window based on the platform order submission deadline and the platform open transaction date to obtain the platform transaction calendar layer.

[0104] In some embodiments, the calendar generation module 12 is specifically used to: obtain the advance days and counting unit in the platform access offset information; take the upstream cut-off date in the basic transaction access window as the base date, and calculate the advance days according to the counting unit to obtain the platform order submission deadline corresponding to the upstream cut-off date; the counting unit includes natural days, resource transaction days or resource settlement days.

[0105] In some embodiments, the interval matching module 14 is specifically used to: obtain the target platform transaction access window corresponding to the order timestamp in the platform transaction calendar layer; obtain the product configuration information of the target resource object according to the object identifier of the target resource object; the product configuration information includes the critical time of dividing T day; and construct the current tradable time interval that is left-closed and right-open based on the target platform transaction access window and the critical time of dividing T day.

[0106] It should be understood that the modules or modules described in the resource object transaction processing device 10 are related to the reference. Figure 3 The steps in the described method correspond accordingly. Therefore, the operations and features described above for the method also apply to the resource object transaction processing apparatus 10 and its included modules, and will not be repeated here. The resource object transaction processing apparatus 10 can be pre-implemented in the browser or other security applications of an electronic device, or it can be loaded into the browser or its security applications of an electronic device through download or other means. The corresponding modules in the resource object transaction processing apparatus 10 can cooperate with the modules in the electronic device to implement the solutions of the embodiments of this application.

[0107] The division of modules or units mentioned in the detailed description above is not mandatory. In fact, according to the embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0108] The following is for reference. Figure 6 , Figure 6 A schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application is shown. like Figure 6 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for the system's operating instructions. CPU 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0109] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet. A drive 510 is also connected to I / O interface 505 as needed. A removable medium 511, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 510 as needed so that computer programs read from it can be installed into storage section 508 as needed.

[0110] Specifically, according to embodiments of this application, the above reference flow Figure 3 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined in the system of this application.

[0111] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0113] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor can be described as including an acquisition module, a determination module, an update module, a matching module, and a recommendation module. The names of these units or modules do not necessarily limit the specific unit or module itself; for example, an acquisition module can also be described as acquiring virtual resource requirement information input by the user.

[0114] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments, or may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the resource object transaction processing method described in this application.

[0115] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A method for processing resource object transactions, characterized in that, include: Obtain general time node configuration information and resource transaction time node configuration information. The general time node configuration information is used to indicate the tradable operation time of resource objects within a preset period. The resource transaction time node configuration information is used to indicate the transaction access time of target resource objects. Based on the general time node configuration information and the resource transaction time node configuration information, a multi-level transaction access calendar for the target resource object is constructed. Receive user transaction orders, obtain the order timestamp of the user transaction order and the object identifier of the target resource object; The multi-level transaction access calendar is invoked, and a matching query is performed based on the object identifier of the target resource object to obtain the current tradable time interval of the user's transaction order; Determine whether the order timestamp falls within the current tradable time interval, and generate a tradability determination result for the user's transaction order.

2. The resource object transaction processing method according to claim 1, characterized in that, The step of constructing a multi-level transaction access calendar for the target resource object based on the general time node configuration information and the resource transaction time node configuration information includes: Based on the general time node configuration information, the tradable operation time is determined, and the basic calendar layer within the preset period is obtained. Based on the configuration information of the basic calendar layer and the resource transaction time node, the basic transaction access window within the preset period is determined, and the transaction access calendar layer of the target resource object within the preset period is obtained. Based on the transaction access calendar layer of the target resource object and the platform transaction configuration information, the platform transaction access window within the preset period is determined, and the platform transaction calendar layer of the target resource object within the preset period is obtained.

3. The resource object transaction processing method according to claim 2, characterized in that, The resource transaction time node configuration information includes transaction access time information and transaction access offset information. The step of determining the basic transaction access window within the preset period based on the basic calendar layer and the resource transaction time node configuration information, and obtaining the transaction access calendar layer for the target resource object within the preset period, includes: Based on the transaction access time information, obtain the start date and end date of the transaction opening for the target resource object within the preset period; Based on the basic calendar layer, the transaction opening start date, and the transaction opening end date, and according to the transaction admission offset information, the upstream opening date and the upstream order cutoff date within the preset period are determined to obtain the basic transaction admission window; By summarizing all the basic transaction access windows within the preset period, the transaction access calendar layer of the target resource object is obtained.

4. The resource object transaction processing method according to claim 3, characterized in that, The step of determining the platform transaction access window within the preset period based on the transaction access calendar layer of the target resource object and the platform transaction configuration information, and obtaining the platform transaction calendar layer of the target resource object within the preset period, includes: For the upstream cut-off date in the basic transaction access window, obtain the platform order submission deadline corresponding to the upstream cut-off date based on the platform access offset information; Based on the platform order submission deadline, and combined with the upstream opening date of the basic transaction access window, the platform open transaction date corresponding to the platform order submission deadline is obtained; The platform transaction access window is determined based on the platform order submission deadline and the platform open transaction date, thus obtaining the platform transaction calendar layer.

5. The resource object transaction processing method according to claim 4, characterized in that, The method for obtaining the platform order submission deadline corresponding to the upstream cut-off date in the basic transaction access window, based on the platform access offset information, includes: Obtain the advance number of days and the counting unit from the platform access offset information; Using the upstream cut-off date in the basic transaction access window as the base date, the advance number of days is calculated forward according to the counting unit to obtain the platform order submission deadline corresponding to the upstream cut-off date; The counting units include calendar days, resource transaction days, or resource settlement days.

6. The resource object transaction processing method according to claim 4 or 5, characterized in that, The step of invoking the multi-level transaction access calendar, performing a matching query based on the object identifier of the target resource object, and obtaining the current tradable time interval of the user's transaction order includes: In the platform transaction calendar layer, obtain the target platform transaction access window corresponding to the order timestamp; Based on the object identifier of the target resource object, obtain the product configuration information of the target resource object; the product configuration information includes the critical time of division on day T; Based on the target platform's trading access window and the critical moment of day T, a current tradable time interval with left-closed and right-open structure is constructed.

7. A resource object transaction processing device, characterized in that, include: The data acquisition module is used to acquire general time node configuration information and resource transaction time node configuration information. The general time node configuration information is used to indicate the tradable operation time of resource objects within a preset period. The resource transaction time node configuration information is used to indicate the transaction access time of target resource objects. The calendar generation module is used to construct a multi-level transaction access calendar for the target resource object based on the general time node configuration information and the resource transaction time node configuration information. The order receiving module is used to receive user transaction orders, obtain the order placement timestamp of the user transaction order and the object identifier of the target resource object; The interval matching module is used to call the multi-level transaction access calendar, perform matching queries based on the object identifier of the target resource object, and obtain the current tradable time interval of the user's transaction order; The time determination module is used to determine whether the order timestamp falls within the current tradable time interval and generate a tradability determination result for the user's transaction order.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the resource object transaction processing method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the resource object transaction processing method as described in any one of claims 1-6.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the resource object transaction processing method of any one of claims 1-6.

Images