Two-stage distributed full-service chain cooperative agricultural management and control system and method

Abstract

The present application relates to the field of agricultural informatization and data processing technology, and discloses a two-level distributed full-service chain collaborative agricultural management and control system and method, which deploys edge collaborative nodes in the county area, independently runs in offline autonomous mode when the network is disconnected, and after recovery, carries out incremental synchronization and conflict resolution through three-section version marking. The present application introduces placeholder nodes and supplementary record repair mechanism in the business object hash chain, and takes the hash chain integrity verification result as the input parameter of the dynamic credit model, and constructs a cross-season feedback loop from the fund hedging result to the next season credit decision. By establishing a direct technical causal relationship between data storage and credit decision, the integrity state of the data determines the trust degree of the credit, which fundamentally solves the problems of data fault in agricultural field leading to storage chain failure, credit and data verification disconnection, and lack of linkage between credit and data verification, and is suitable for county agricultural full-industry chain digital management and control scene.

Description

Technical Field

[0001] This invention relates to the field of agricultural informatization and data processing technology, and in particular to a two-level distributed full-business chain collaborative agricultural management and control system and method. Background Technology

[0002] With the advancement of agricultural industrialization, digital management of the entire agricultural industry chain at the county level has become a trend. These systems typically cover multiple links such as agricultural input supply, planting management, and purchase settlement, involving various users such as farmers, distributors, and purchasing companies, with a large amount of data and a long chain.

[0003] Existing agricultural management systems have the following main shortcomings in practical applications: 1. Data entry at agricultural production sites relies on manual operation, and omissions and delays in supplementing agricultural records are common. Traditional hash chains or blockchain evidence storage mechanisms have stringent requirements for data integrity. The absence of a single piece of data will cause the verification of the entire chain to fail, lacking the ability to tolerate data gaps at agricultural sites.

[0004] 2. The existing credit line for sales is mainly based on farmers' transaction records and credit scores over the past few years. The credit limit is determined once at the beginning of the planting season and is not adjusted. However, the fixed credit limit cannot reflect real-time changes. Farmers' sales repayment performance in the previous season does not automatically affect their credit limit in the next quarter in the existing system. There is a lack of feedback loop between sales recovery results and credit decisions in the next quarter, resulting in insufficient timeliness and continuity of risk control. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a two-level distributed, full-business-chain collaborative agricultural management and control system and method. This system solves the problems mentioned in the background, such as the inability of business operations to proceed when the county network is interrupted and the difficulty in ensuring data consistency after recovery, the lack of a unified time-series benchmark for full-business-chain data and the lack of automatic cross-link association, and the problem that the credit line for agricultural input sales lags behind actual changes in production.

[0006] Firstly, in order to achieve the above objectives, the present invention adopts the following technical solution: A two-tiered distributed, full-business-chain collaborative agricultural management and control system, comprising: a central platform cloud server and edge collaboration nodes deployed in various counties; The edge collaboration node has a built-in local business database and data synchronization engine. When the edge collaboration node is connected to the main platform cloud server network, it asynchronously synchronizes the incremental business data generated during the network outage to the main platform cloud server with a three-segment version tag attached. The three-segment version tag consists of a county code, a locally generated timestamp, and a hash pointer pointing to the previous same source data record. Business data generated by the same business object in each business process is associated with the globally unique business code of the business object as the primary key, and hash operations are performed sequentially according to the time of business occurrence to form a hash chain of business objects. When the system detects that the business data of the business object is missing in a certain business process, a placeholder node is automatically inserted at the missing position to maintain the chain structure of the hash chain of the business object. The placeholder node carries a status flag indicating that it is to be supplemented and a time window for supplementation. When supplemented data is received within the time window, the placeholder node is replaced with the supplemented data and the hash value of the subsequent nodes is recalculated. The recalculated hash value of the tail of the chain is synchronized to the anti-tampering index table of the main platform cloud server. The edge collaboration node also has a built-in automatic fund hedging engine and a dynamic credit granting module. When a farmer initiates an application for agricultural input credit sales, the dynamic credit granting module reads the hash verification status of the planting area verification record for the current season from the hash chain of the business object corresponding to the farmer. If the hash verification status is complete and without gaps, the planting area verification data is given a full trust weight. If the hash verification status shows that there are placeholder nodes or supplementary records, the planting area verification data is given a discount trust weight. At the same time, it extracts crop growth stage data and recent meteorological monitoring data from the local business database, and calculates the dynamic credit limit for credit sales by combining the credit adjustment factor fed back from the fund hedging results of the previous season. The automatic fund hedging engine is used to retrieve the outstanding agricultural input sales records under the farmer's name when the grain purchase payment arrives in the settlement account, and deduct them one by one in the order of the sales occurrence time. After the deduction is completed, a fund hedging voucher is generated. For sales that cannot be settled in the current quarter, an overdue status is marked, and the overdue record is fed back to the dynamic credit granting module to reduce the farmer's credit adjustment factor for the next quarter.

[0007] Secondly, in order to achieve the above objectives, the present invention adopts the following technical solution: A two-tiered distributed, full-business-chain collaborative agricultural management and control method includes the following steps: S1: The main platform deploys edge collaboration nodes for each county. The edge collaboration nodes independently run the data collection, storage and business processing functions of the entire agricultural business chain in the county. When connected to the main platform network, the incremental business data generated during the network outage is asynchronously synchronized to the main platform cloud server with a three-segment version tag attached. S2: Within each county, business data generated by the same business object in each business process are associated with the globally unique business code of the business object as the primary key, and hash operations are performed sequentially according to the time of business occurrence to form a hash chain of business objects; when a missing data is detected in a certain process, a placeholder node is automatically inserted to maintain the continuity of the chain structure. The placeholder node carries a status flag indicating that it is to be supplemented and a time window for supplementation; when supplemented data is received, the placeholder node is replaced and the hash value of subsequent nodes is recalculated, and the updated chain tail hash value is synchronized to the anti-tampering index table of the main platform; S3: When a farmer initiates an application for agricultural input credit sales, the hash verification status of the current season's planting area verification record is read from the hash chain of the business object corresponding to the farmer. If it is complete and without gaps, it is given a full trust weight. If there are placeholder nodes or supplementary records, it is given a discount trust weight. Combined with crop growth stage data, recent meteorological monitoring data and credit adjustment factors fed back from the previous season's capital hedging results, the dynamic credit limit for credit sales is calculated. S4: When the farmer's grain purchase payment arrives in the settlement account, retrieve the outstanding agricultural input credit sales records and deduct them one by one in chronological order of occurrence to generate a fund offset voucher; mark the credit sales that cannot be settled in the current quarter as overdue and feed the overdue records back to step S3 to reduce the farmer's credit adjustment factor for the next quarter.

[0008] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention enables county-level edge collaboration nodes with built-in local business databases to operate independently in offline autonomous mode when the network is down, ensuring uninterrupted on-site business. After the connection is restored, incremental data is asynchronously synchronized and conflicts are automatically resolved through a three-stage version tagging system, avoiding data errors caused by manual data entry.

[0009] 2. This invention uses placeholder nodes and a data replenishment and repair mechanism to automatically insert placeholder nodes into the hash chain when missing data is detected in the business process, so as to maintain the continuity of the chain structure. It allows data to be replenished within a set time window and the hash value to be recalculated after replacing the placeholder nodes. This enables the hash chain to adapt to the real environment of missing and replenishing data in agricultural production sites, and avoids the vulnerability of traditional hash chains where the entire verification fails due to a single point of missing data.

[0010] 3. This invention directly uses the integrity verification result of the business object hash chain as the input parameter of the dynamic credit granting model. It introduces the hash chain integrity discount coefficient δ into the credit limit calculation. By establishing a direct technical causal relationship between data storage and credit granting decision, the integrity status of the data determines the degree of trust in the credit granting, fundamentally changing the defect of the existing system where credit granting and data verification are disconnected.

[0011] 4. This invention establishes a dynamic credit granting model driven by multi-dimensional real-time production data, which incorporates the actual planting area of ​​farmers in the current season, crop growth stage, and meteorological disaster risk into the credit limit calculation; this mechanism forms a cross-quarter adaptive closed loop, enabling the system to have the ability to self-adjust based on historical repayment behavior, effectively protecting the funds of agricultural input dealers. Attached Figure Description

[0012] Figure 1 This is the overall architecture diagram of the two-level distributed full-business chain collaborative agricultural management and control system proposed in this invention; Figure 2 This is a functional module diagram of the edge collaborative node of the two-level distributed full-business chain collaborative agricultural management and control system proposed in this invention. Figure 3 This is a flowchart of the placeholder node insertion and supplementary recording repair process of the fault-tolerant hash chain of the two-level distributed full-business chain collaborative agricultural management and control system and method proposed in this invention. Figure 4 This is a flowchart illustrating the relationship between hash chain integrity verification and credit decision-making in the dynamic credit granting process of the two-level distributed full-business chain collaborative agricultural management and control system and method proposed in this invention. Figure 5 This is a schematic diagram of the automatic fund hedging and cross-seasonal credit feedback closed loop of the two-level distributed full-business chain collaborative agricultural management and control system and method proposed in this invention. Detailed Implementation

[0013] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0014] Example 1, please refer to Figures 1 to 5 This is the first embodiment of the present invention, which provides a specific implementation method for the offline autonomous operation mechanism and fault-tolerant hash chain of edge collaborative nodes in a two-level distributed full-business chain collaborative agricultural management and control system.

[0015] The central platform cloud server is deployed in a provincial or regional data center and establishes communication connections with edge collaboration nodes in various counties via the Internet. The central platform cloud server maintains the central platform cloud database and tamper-proof index table, and provides global business scheduling, data aggregation and monitoring functions.

[0016] Edge collaboration nodes are deployed in the computer rooms of agricultural authorities or township service centers in each county. Each edge collaboration node uses industrial control computers or edge server hardware, configured with a processor with no less than four cores and more than 8GB of memory. The edge collaboration node has the following built-in functional components: a local business database, used to store all business data of the entire agricultural business chain in the county; and a data synchronization engine, used to manage data synchronization, conflict detection and conflict resolution between the edge collaboration node and the cloud server of the main platform.

[0017] Each county deploys multiple types of end-to-end data acquisition terminals, which communicate with edge collaboration nodes within the county via local area networks or mobile communication networks. These terminals include farmer mobile terminals, agricultural input sales terminals, field operation recording terminals, purchase and weighing terminals, and warehouse management terminals. When entering data, each terminal uses the local system clock of the edge collaboration node as the time base for timestamp calibration, ensuring consistent timeline arrangement of data across all terminals within the same county.

[0018] The data synchronization engine within the edge collaboration node continuously monitors the network connection status with the central platform cloud server during operation. The data synchronization engine sends heartbeat signals to the central platform cloud server at a preset detection cycle, and determines that the network connection is interrupted if it fails to receive a response multiple times.

[0019] At this point, the data synchronization engine automatically switches the edge collaborative nodes to offline autonomous mode. In offline autonomous mode, the edge collaborative nodes continue to process all local business operations such as agricultural input sales, field records, and purchase weighing normally. All business data is written normally to the local business database, and the data synchronization engine sets the synchronization status of each data record written during the network outage to "pending synchronization".

[0020] Once the data synchronization engine detects that the network connection with the central platform cloud server has been restored, it automatically initiates the data synchronization process. The synchronization engine queries all data records marked as pending synchronization in the local business database, sorts them in ascending order by timestamp, and uploads them sequentially to the central platform cloud server through an encrypted channel. Each uploaded data record is accompanied by a three-part version tag, which consists of the county code, the timestamp when the data record was generated locally at the edge collaboration node, and a hash pointer pointing to the previous data record generated by the same business object.

[0021] After receiving the synchronized data, the cloud server of the main platform searches for existing source data records in the cloud database according to the county code and business object code. If they do not exist, they are determined to be new data and written directly; if they exist, the hash pointer field in the three-segment version marker of the two records is compared.

[0022] If the hash pointers are different, the data is determined to be independent data generated by the same business object in different business processes, and all of them are retained. If the hash pointers are the same, the data content is further compared: if they are completely identical, it is determined to be a duplicate upload, which is discarded by the cloud and a confirmation is sent; if the content is different, it is determined to be a conflict, and the later timestamp is used to overwrite the earlier record. The result of conflict resolution is written to the conflict log table for auditing and traceability.

[0023] In terms of data tamper-proofing and evidence preservation, the system adopts a fault-tolerant hash chain mechanism. When a business object is created in the system for the first time, the system generates a globally unique business code for that business object. This code consists of a county code, a business object type code, a creation date, and a sequence number. Once generated, it is permanently bound to the business object. In subsequent business processes such as sowing, fertilizing, applying pesticides, harvesting, quality inspection, weighing, purchasing, drying, and warehousing, each terminal uses this globally unique business code as the primary key for association when entering relevant data for that business object.

[0024] The system hashes the business data records of each stage sequentially according to the time sequence of business occurrences, forming a hash chain of business objects. Let R_i be the data record generated by a business object in the i-th business stage. This record contains the business object code, stage name, operation timestamp, and key business parameters. After concatenating this record with the hash value of the previous stage, the hash value of the current stage is calculated using the national cryptographic SM3 hash algorithm: H_i = SM3(R_i || H_{i-1}). The predecessor hash value of the first stage is taken as the globally unique business code of the business object itself.

[0025] Data entry in agricultural production sites relies on manual operation. There are situations where data is not entered in time at a certain stage and is only entered after the data is entered in a later stage. If a traditional strict hash chain mechanism is used, the absence of data at one stage will cause the verification of all subsequent hash values ​​to fail.

[0026] To address this issue, this system introduces a placeholder node mechanism. When the system detects that a business object skips a step in a pre-defined business process sequence and directly generates data for subsequent steps, the system automatically creates a placeholder node at the missing position. The hash value of the placeholder node is calculated as: H_place = SM3(Placeholder || Business Object Code || Missing Step Identifier || H_{i-1}), where Placeholder is a pre-defined placeholder identifier (with the fixed string "PLACEHOLDER_NODE"), and the missing step identifier indicates which business process is missing. The placeholder node acts as a valid intermediate node in the hash chain, ensuring that the hash calculation for subsequent steps can proceed normally and maintaining the continuity of the chain structure.

[0027] Placeholder nodes carry two key attributes: a pending data entry status flag and a allowed data entry time window. The pending data entry status flag is initially set to "pending data entry," indicating that the business data corresponding to this node has not yet been actually entered. The allowed data entry time window is set according to the nature of the missing process: for time-sensitive agricultural operations such as fertilization and pesticide application, the window is set to 7 days; for basic data such as planting area verification, the window is set to 30 days; and for general field records, the window is set to 14 days.

[0028] When agricultural technicians supplement the missing business data through the field operation record terminal within the allowed supplementary recording time window, the system matches the supplementary data with the placeholder node (based on the business object code and the missing link identifier).

[0029] After a successful match, the system generates a formal hash value using the supplementary data to replace the placeholder node's hash value. Starting from that node, the system recalculates the hash values ​​of all subsequent nodes along the hash chain. Since the hash values ​​of subsequent nodes in the hash chain depend on the hash values ​​of preceding nodes, after a placeholder node is replaced, the hash values ​​of all subsequent nodes must be recalculated until the end of the chain.

[0030] After recalculation, the system synchronizes the updated chain tail hash value to the anti-tampering index table on the main platform's cloud server and updates the placeholder node status to "added". Simultaneously, the system records the timestamp of the addition operation, the operator's identity, and the hash value changes before and after the addition in the audit log.

[0031] If no supplementary data is received within the allowed supplementary data window, the placeholder node status marker will automatically change to "overdue and not supplemented". The system will generate a data integrity alarm for the business object, indicating that there is a permanent missing data in the entire business chain of the business object; the placeholder node status marker corresponding to the business object in the anti-tampering index table will be updated to "overdue and not supplemented" simultaneously.

[0032] The anti-tampering index table is stored in the cloud database of the main platform. Each index record contains the business object code, the chain tail hash value, the generation timestamp of the chain tail hash value, the most recent verification timestamp, and the placeholder node status identifier. The cloud server of the main platform periodically traverses the anti-tampering index table, recalculates the chain tail hash value of each business object hash chain, and compares it with the record value in the index table. If they are inconsistent, an anti-tampering alarm is triggered. For records with the placeholder node status identifier "pending supplementation" and the current time has exceeded the allowed supplementation time window, a data missing alarm is generated. For records with the placeholder node status identifier "overdue and not supplemented", a permanent data missing alarm is generated.

[0033] Example 2, please refer to Figure 1 , Figure 2 and Figure 4This is the second embodiment of the present invention. Unlike the previous embodiment, this embodiment provides a specific implementation method for hash chain integrity verification and dynamic credit limit calculation in the dynamic credit granting module.

[0034] The edge collaboration node has a built-in dynamic credit granting module. When a farmer applies for agricultural input credit at an agricultural input sales terminal, this module automatically initiates the credit limit calculation process. The dynamic credit granting module first reads the hash verification status of the current season's planting area verification record from the hash chain of the business object corresponding to the farmer. The hash verification process is as follows: starting from the hash value at the tail of the chain of the business object, it traces backward along the hash chain node by node, recalculating the hash value of each node and comparing it with the value stored on the chain. If all nodes match and no placeholder nodes are found, the hash verification status is determined to be "complete and without gaps".

[0035] If a placeholder node is found during the comparison process (regardless of whether its status is "pending supplementation" or "supplemented"), the hash verification status is determined to be "placeholder node exists". If the placeholder node has been replaced but the system has recorded a supplementation operation trace in the audit log, the hash verification status is determined to be "supplementation trace exists".

[0036] The dynamic credit granting module determines the hash chain integrity discount coefficient δ based on the hash verification status: δ = 1.0 when the chain is complete and without any gaps; δ is 0.5-0.8 when there are placeholder nodes (to be supplemented), with the specific value determined by the degree of impact of the missing link corresponding to the placeholder node on the credit granting decision—δ is 0.5 when there is missing planting area verification data, and 0.8 when there is missing general agricultural operation records; δ is 0.7-0.9 when there are supplementary recording traces, with the specific value determined by the number of days between the time of supplementary recording and the original time that should have been recorded, δ is 0.9 when the delay is no more than 3 days, δ is 0.8 when the delay is 3 to 7 days, and δ is 0.7 when the delay is more than 7 days.

[0037] The dynamic credit granting module simultaneously extracts the current crop growth stage data and recent meteorological monitoring data of the county from the local business database. The growth stage is automatically determined based on the crop's sowing date and the standard effective accumulated temperature for each growth stage, and is divided into four stages: seedling stage, jointing stage, heading stage, and maturity stage. The meteorological monitoring data includes the types, levels, and impact ranges of meteorological disaster warnings issued by the meteorological department.

[0038] In addition, the dynamic credit granting module reads the farmer's current credit adjustment factor φ from the credit management database; the initial value of the credit adjustment factor is 1.0 at the beginning of the new quarter, and the value ranges from 0.3 to 1.0; if there are overdue records in the previous quarter's fund hedging results, the credit adjustment factor has been reduced according to the proportion of overdue amount to total credit sales.

[0039] The dynamic credit line D is calculated as follows: D = D_base × α × β × γ × δ × φ; where D_base is the base credit line, determined based on the farmer's average annual transaction volume over the past three years and their most recent credit score. The system has a pre-set table of base credit lines corresponding to different transaction volume and credit score levels; α is the area adjustment coefficient, which is the ratio of the currently verified planting area to the farmer's average planting area over the past three years. When the ratio exceeds the range of 0.5 to 1.5, Boundary values ​​are used; β is the growth stage coefficient, taken as 0.6 for seedling stage, 0.8 for jointing stage, 1.0 for heading stage, and 1.2 for maturity stage; γ is the meteorological risk coefficient, γ=1-λ×P, where λ is the meteorological disaster warning level coefficient (λ=0 for no warning, λ=0.1 for yellow warning, λ=0.2 for orange warning, and λ=0.3 for red warning), and P is the historical average yield reduction rate of this level of disaster for this crop in the county over the past ten years; δ is the hash chain integrity discount coefficient, and its value is determined as described above. φ is the credit adjustment factor, determined by the funding hedging results of the previous season.

[0040] The core logic behind setting the growth stage coefficient β is that the adjustment of the credit limit is not only based on the level of repayment risk, but also needs to comprehensively consider the actual needs of farmers for agricultural inputs at that stage; although the seedling stage (β=0.6) is the stage with the highest repayment risk, the demand for agricultural inputs is also relatively limited at this time - mainly seeds, base fertilizer and a small amount of pesticides, and the credit limit can be controlled at a lower level to meet production needs; during the jointing stage (β=0.8), the crop enters a rapid vegetative growth stage, and the demand for topdressing and pest and disease control increases, so the credit limit is appropriately increased; during the heading stage (β=1.0), it is a critical node for the transition from vegetative growth to reproductive growth, and the demand for agricultural inputs is close to the peak, so the credit limit returns to the benchmark level; during the maturity stage (β=1.2), although the crop is about to be harvested, this is the stage where farmers' capital needs are most concentrated - the costs of mechanical harvesting, temporary labor, and drying all need to be paid in a short period of time.

[0041] At the same time, the yield of mature crops is basically determined and the quality can be visually assessed, the source of repayment is the clearest, and the repayment risk is the lowest. Based on the dual consideration of "lowest risk and most urgent need", it is reasonable to give a credit line higher than the benchmark value to mature crops.

[0042] The meteorological risk coefficient γ is calculated using the formula γ=1-λ×P, where P is the historical average yield reduction rate, representing the historical average yield reduction ratio of this level of meteorological disaster for this crop in the county over the past ten years; the value range of P is [0,1]. When this level of disaster has never caused yield reduction in historical records, P=0; when this level of disaster has caused complete crop failure in the past, P=1.0.

[0043] When P exceeds the range of [0,1]—for example, in the event of extreme production reduction data or inconsistent statistical methods—the system automatically truncates P to the range of [0,1] to ensure that γ is always non-negative and does not exceed 1.0; when λ=0 (no meteorological disaster warning), regardless of the value of P, γ is always equal to 1.0, and the meteorological risk coefficient does not reduce the credit limit.

[0044] The system continuously updates farmers' planting area verification data, crop growth stage data, and recent meteorological monitoring data. Whenever any of the above data or hash chain integrity verification status changes, the dynamic credit module automatically recalculates the credit limit of the farmers who have been granted credit. The new limit takes effect immediately. If the recalculated limit is lower than the amount of credit the farmer has already used, the farmer will not be able to continue to purchase agricultural materials on credit until the excess amount is settled.

[0045] Example 3, please refer to Figure 1 , Figure 2 and Figure 5 This is the third embodiment of the present invention. Unlike the previous embodiments, this embodiment provides a specific implementation method for the automatic deduction mechanism of the automatic fund hedging engine and the cross-seasonal credit feedback closed loop.

[0046] The edge collaboration nodes have a built-in automatic fund hedging engine. When farmers transport their harvested grain to the purchasing station for sale, the purchasing and weighing terminal records the farmer's identity, grain variety, weighing weight, and quality inspection grade, calculates the total purchase price, and generates a purchase record. The purchase payment is then transferred to the farmer's county-level purchasing settlement account via bank transfer system.

[0047] Once the automatic fund hedging engine detects that the farmer's purchase payment has arrived in the settlement account, it automatically initiates the hedging process. The engine retrieves all outstanding agricultural input credit sales records under the farmer's name from the local business database, arranging them in chronological order of the credit sales. Following this order, the engine deducts the principal amount of each credit sales from the purchase payment one by one. After each deduction is completed, the engine generates a fund hedging voucher, which records the corresponding credit sales record number, deduction amount, deduction time, purchase record number, and operation serial number. After all deductions are completed, the engine transfers the remaining amount of the purchase payment to the farmer's personal bank settlement account.

[0048] If the total purchase amount is insufficient to cover all outstanding credit sales, the engine will deduct the amount sequentially according to the time sequence until the purchase amount is exhausted. For any outstanding credit sales balance that cannot be covered, the engine will mark it as overdue and generate an overdue record. The overdue record includes the farmer code, overdue amount, overdue credit sales record number, overdue time, and total credit sales amount for the current quarter.

[0049] Overdue records are fed back to the dynamic credit granting module in real time. The dynamic credit granting module calculates the reduction of the credit adjustment factor based on the ratio of the overdue amount in the overdue record to the total amount of credit sales in the current quarter.

[0050] The adjustment rules are as follows: for overdue rates not exceeding 10%, the credit adjustment factor will be lowered to 0.9; for overdue rates between 10% and 30%, it will be lowered to 0.7; for overdue rates between 30% and 50%, it will be lowered to 0.5; and for overdue rates exceeding 50%, it will be lowered to 0.3, and the farmer will be placed on a list of key monitoring farmers. The lowered credit adjustment factor will directly affect the calculation of the farmer's dynamic credit limit for the next planting season.

[0051] At the start of the new quarter, if a farmer has an overdue payment record in the previous quarter and the credit adjustment factor has been reduced, the system will enter a credit repair observation period. If the farmer settles all outstanding payments on time in this quarter (with no new overdue payments), the credit adjustment factor will be increased by 0.1 in the next quarter. If there are no overdue payments for two consecutive quarters, the factor will be increased by another 0.1, and so on, until it returns to 1.0. If an overdue payment occurs again during the repair period, the credit adjustment factor will be reduced again according to the overdue payment ratio.

[0052] This cross-seasonal closed-loop mechanism of "credit granting → credit sales → acquisition → hedging → overdue feedback → credit reduction → repayment repair → credit restoration" deeply couples the results of fund hedging with credit decisions in the time dimension, enabling the system to adaptively adjust credit based on historical repayment behavior.

[0053] During the overall operation of the system, each county-level edge collaborative node is independently responsible for business processing and local data storage within its own county. The central platform cloud server maintains a complete copy of the network data by receiving incremental synchronization data uploaded by each edge collaborative node, and based on this data, provides provincial or regional agricultural authorities with regulatory functions such as total business volume statistics, transaction trend analysis, fund dynamic monitoring, and risk warning.

[0054] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A two-level distributed, full-business-chain collaborative agricultural management and control system, characterized in that: include: The main platform consists of cloud servers and edge collaboration nodes deployed in various counties; The edge collaboration node has a built-in local business database and data synchronization engine. When the edge collaboration node is connected to the main platform cloud server network, it asynchronously synchronizes the incremental business data generated during the network outage to the main platform cloud server with a three-segment version tag attached. The three-segment version tag consists of a county code, a locally generated timestamp, and a hash pointer pointing to the previous same source data record. Business data generated by the same business object in each business process is associated with the globally unique business code of the business object as the primary key, and hash operations are performed sequentially according to the time of business occurrence to form a hash chain of business objects. When the system detects that the business data of the business object is missing in a certain business process, a placeholder node is automatically inserted at the missing position to maintain the chain structure of the hash chain of the business object. The placeholder node carries a status flag indicating that it is to be supplemented and a time window for supplementation. When supplemented data is received within the time window, the placeholder node is replaced with the supplemented data and the hash value of the subsequent nodes is recalculated. The recalculated hash value of the tail of the chain is synchronized to the anti-tampering index table of the main platform cloud server. The edge collaboration node also has a built-in automatic fund hedging engine and a dynamic credit module. When a farmer initiates an application for agricultural input credit sales, the dynamic credit module reads the hash verification status of the planting area verification record of the current season from the hash chain of the business object corresponding to the farmer, extracts crop growth stage data and recent meteorological monitoring data from the local business database, and calculates the dynamic credit limit for credit sales by combining the credit adjustment factor fed back from the fund hedging results of the previous season. The automatic fund hedging engine is used to retrieve the outstanding agricultural input sales records under the farmer's name when the grain purchase payment arrives in the settlement account, and deduct them one by one in the order of the sales occurrence time. After the deduction is completed, a fund hedging voucher is generated. For sales that cannot be settled in the current quarter, an overdue status is marked, and the overdue record is fed back to the dynamic credit granting module to reduce the farmer's credit adjustment factor for the next quarter.

2. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, When the data synchronization engine detects a network connection interruption with the main platform cloud server, it switches the edge collaborative node to offline autonomous mode, continues to write business data into the local business database, and marks the incremental business data generated during the network outage as pending synchronization. After the network is restored, the data is uploaded sequentially in ascending order of the timestamps in the three-segment version marking.

3. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 2, characterized in that, When performing synchronization, the data synchronization engine compares the hash pointer in the three-segment version marker of each data record arriving at the main platform cloud server with the latest hash pointer of the existing data record of the same source in the cloud. If the pointers are different, it is determined to be new data and written directly. If the pointers are the same and the data content is consistent, it is determined to be a duplicate upload and discarded. If the pointers are the same but the data content is different, it is determined to be a conflict and the later timestamp is used to overwrite.

4. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, If the hash verification status is complete and without gaps, the planting area verification data is given a full trust weight; if the hash verification status is that there are placeholder nodes or supplementary records, the planting area verification data is given a discounted trust weight.

5. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, The hash chain of the business object is constructed as follows: Let the data record generated by a certain business object O in the i-th business step be R_i, and its hash value H_i = Hash(R_i || H_{i-1}), where H_{i-1} is the hash value of the previous step, and Hash adopts the national cryptographic SM3 algorithm; the hash value of the tail of the chain of the business object is the hash value corresponding to the last step, and the hash value of the placeholder node H_place = Hash(Placeholder || business object code || missing step identifier || H_{i-1}).

6. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, Each index record in the anti-tampering index table includes the business object code, the chain tail hash value, the generation timestamp of the chain tail hash value, the most recent verification timestamp, and the placeholder node status identifier. The cloud server of the main platform periodically traverses the anti-tampering index table and generates a data missing alarm for records whose placeholder node status identifier is pending supplementation and exceeds the allowed supplementation time window.

7. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, The full-service chain data acquisition terminals include farmer mobile terminals, agricultural input sales terminals, field operation recording terminals, purchase weighing terminals, and warehouse management terminals. They are connected to the edge collaboration nodes in the county through a local area network or mobile communication network. When each terminal enters data, it uses the local system clock of the edge collaboration node as the time reference for timestamp calibration.

8. The two-level distributed full-business-chain collaborative agricultural management and control system according to claim 1, characterized in that, After receiving the overdue records from the previous quarter's fund hedging results, the dynamic credit granting module will reduce the farmer's credit adjustment factor according to the proportion of overdue amount to total credit sales. The higher the overdue proportion, the greater the reduction. After the start of the new quarter, the credit adjustment factor will gradually recover as the farmer makes timely repayments for the number of consecutive quarters.

9. A two-level distributed full-business-chain collaborative agricultural management method, applied to the system according to any one of claims 1 to 8, characterized in that, Includes the following steps: S1: The main platform deploys edge collaboration nodes for each county. The edge collaboration nodes independently run the data collection, storage and business processing functions of the entire agricultural business chain in the county. When connected to the main platform network, the incremental business data generated during the network outage is asynchronously synchronized to the main platform cloud server with a three-segment version tag attached. S2: Within each county, business data generated by the same business object in each business process are associated with the globally unique business code of the business object as the primary key, and hash operations are performed sequentially according to the time of business occurrence to form a hash chain of the business object. When missing data is detected in a certain link, a placeholder node is automatically inserted to maintain the continuity of the chain structure. The placeholder node carries a status flag indicating that the data is to be supplemented and a time window for supplementation. When supplemented data is received, the placeholder node is replaced and the hash value of the subsequent nodes is recalculated. The updated chain tail hash value is synchronized to the anti-tampering index table of the main platform. S3: When a farmer initiates an application for agricultural input credit sales, the hash verification status of the current season's planting area verification record is read from the hash chain of the business object corresponding to the farmer. If it is complete and without gaps, it is given a full trust weight. If there are placeholder nodes or supplementary records, it is given a discount trust weight. Combined with crop growth stage data, recent meteorological monitoring data and credit adjustment factors fed back from the previous season's capital hedging results, the dynamic credit limit for credit sales is calculated. S4: When the farmer's grain purchase payment arrives in the settlement account, retrieve the outstanding agricultural input credit sales records and deduct them one by one in chronological order of occurrence to generate a fund offset voucher; mark the credit sales that cannot be settled in the current quarter as overdue and feed the overdue records back to step S3 to reduce the farmer's credit adjustment factor for the next quarter.

10. The agricultural management and control method based on two-level distributed full-business chain collaboration according to claim 9, characterized in that, In step S3, the dynamic credit limit D is calculated as follows: D = D_base × α × β × γ × δ × φ; Where D_base is the base credit limit, determined based on the farmer's historical average annual transaction amount and credit score; α is the area adjustment coefficient, which is the ratio of the currently verified planting area to the farmer's historical average planting area; β is the growth stage coefficient, which is determined according to the current growth stage of the crop: 0.6 for seedling stage, 0.8 for jointing stage, 1.0 for heading stage, and 1.2 for maturity stage; γ is the meteorological risk coefficient; δ is the hash chain integrity discount coefficient, which is 1.0 when the hash chain of the business object corresponding to the verified planting area data is complete and without gaps, δ is 0.5-0.8 when there are placeholder nodes, and δ is 0.7-0.9 when there are supplementary records; and φ is the credit adjustment factor.

Images