A method and system for early warning of official reception, a storage medium and a terminal device

Abstract

The present application belongs to the technical field of government informationization, and particularly relates to a public reception early warning method and system, a storage medium and a terminal device. The present application configures "whether a central township unit" in unit archives, configures "whether a central county area" and "city determination distance threshold" fields in district archives, and combines double-time-point GPS positioning data when a business trip unit creates a public letter and a reception unit creates an application. The present application calculates the actual spherical distance by using the Haversine formula, takes the smaller value of the district threshold of the two units as the determination standard, and realizes dynamic determination based on the cooperation of spatial distance and administrative rules. The present application effectively solves the determination deviation problem caused by complex terrain or administrative division restrictions, and significantly improves the accuracy and adaptability of public reception supervision.

Description

Technical Field

[0001] This invention belongs to the field of e-government technology, specifically relating to an early warning method, system, storage medium, and terminal equipment for official receptions. Background Technology

[0002] In current practices of official reception management, identification of same-city reception activities is typically achieved through manual approval or static system judgment based on administrative divisions. This method generally relies on whether the city or county-level region to which the unit belongs is consistent, neglecting the dynamic consideration of actual geographical distance and lacking reliable location and data storage mechanisms. Especially in complex terrain environments such as mountainous and remote areas, the distance between units within the same administrative division may be far, while units across regions may be closer due to convenient transportation, making traditional methods prone to misjudgment. Furthermore, the rigid configuration of system rules cannot flexibly adjust the judgment threshold according to policy changes or geographical characteristics, failing to meet the needs of differentiated supervision.

[0003] Therefore, the main problem with the existing technology is that it cannot effectively combine geographical distance and administrative attributes to make accurate and dynamic judgments on same-city receptions, resulting in inaccurate judgment results in complex terrain or cross-regional scenarios, which in turn affects the effectiveness of supervision of official receptions. Summary of the Invention

[0004] The purpose of this invention is to provide an early warning method, system, storage medium, and terminal device for official receptions, which effectively solves the problem of judgment bias caused by complex terrain or administrative division restrictions, and significantly improves the accuracy and adaptability of official reception supervision, thereby solving the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a method for early warning of official receptions, comprising the following steps:

[0006] Configure a field for whether a unit is a central township in the unit file, and configure a field for whether a unit is a central county or district and a field for determining the distance threshold between units within the same city in the administrative division file;

[0007] When a business traveler creates an electronic letter, the system automatically collects its GPS location information as latitude and longitude 1, and calls the blockchain interface to store the letter content and location data as evidence, generating a hash value and uploading it to the blockchain;

[0008] When the receiving unit creates a reception application form and associates it with the aforementioned electronic letter, the system automatically collects its GPS positioning information as latitude and longitude 2, and calls the blockchain interface to store the application content and positioning data, generating a hash value and uploading it to the chain;

[0009] Multi-level collaborative judgment is performed based on the information in the fields, including: if two units are in the same county and are both marked as central township units, or if they are in different counties and are both marked as central counties and are both marked as central township units, then dynamic location verification is performed; the smaller value of the distance threshold for judging the same city of the two units is taken as the actual judgment standard, and the spherical distance between latitude and longitude 1 and latitude and longitude 2 is calculated using the Haversine formula. If the calculated distance is less than or equal to the actual judgment standard, then it is judged as same city reception.

[0010] When it is determined to be a same-city reception, an early warning notice is generated, which includes the unit, district, GPS data, threshold parameters and the basis for the judgment. The notice is pushed to the regulatory terminal and the information of the early warning notice is stored on the blockchain.

[0011] Preferably, the distance threshold for determining same-city status is set to 50 kilometers by default at the city level and 30 kilometers by default at the county level.

[0012] Preferably, the method further includes: the supervisor manually adjusts the same-city determination distance threshold according to the terrain features, and expands the threshold of the city-level division to 60 kilometers in mountainous scenarios.

[0013] Preferably, the method further includes: marking the field of whether a remote township unit is a central township unit as no, and marking the field of whether a central county / district (including the municipal level) is a central county / district as yes.

[0014] Preferably, the notarization process of the official letter content and location data, and the application content and location data, is implemented through blockchain.

[0015] On the other hand, the present invention proposes an early warning system for official receptions, comprising:

[0016] The client application is used to create electronic official documents, reception application forms, and collect GPS location data.

[0017] The server is used to perform field configuration, multi-level collaborative judgment, and early warning order generation.

[0018] The regulatory end is used to receive early warning notices and supports dynamic configuration of whether a unit is a central township, whether it is a central county or district, and the distance threshold for determining whether it is in the same city;

[0019] Blockchain nodes are used to store the hash values ​​of electronic official documents, reception application forms, and early warning forms, thereby achieving data notarization and tamper-proofing.

[0020] Preferably, the client includes a client for the traveling unit and a client for the receiving unit, which can be accessed through a browser webpage, mobile application or desktop client, and supports scanning a QR code to quickly link electronic documents.

[0021] Preferably, the server is equipped with a field configuration module, a blockchain evidence storage interface, a distance calculation engine, and an early warning push service. The distance calculation engine integrates the Haversine formula for spherical distance calculation, and the early warning push service uses a message queue to achieve multi-channel asynchronous push of SMS, APP notifications, emails, and in-site messages.

[0022] On the other hand, the present invention proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the early warning method for official receptions as described above.

[0023] On the other hand, the present invention proposes a terminal device, including a processor, a memory and a communication module. The memory stores a computer program. When the program is executed by the processor, it is used to automatically collect GPS positioning information when creating an electronic letter or reception application form, encapsulate the data in JSON format, and upload it to the server through the communication module to complete blockchain notarization.

[0024] Technical effects and advantages of the present invention: The early warning method, system, storage medium and terminal device for official reception proposed in this invention have the following advantages compared with the prior art:

[0025] This invention configures fields for "whether it is a central township unit" in the unit's file and "whether it is a central county / district" and "same-city distance threshold" in the administrative division file. It combines dual-time-point GPS positioning data from the official letter created by the traveling unit and the application created by the receiving unit, calculates the actual spherical distance using the Haversine formula, and takes the smaller of the threshold values ​​for the two units' administrative divisions as the judgment criterion. This achieves dynamic judgment based on the synergy of spatial distance and administrative rules. This method effectively solves the judgment bias problem caused by complex terrain or administrative division limitations, significantly improving the accuracy and adaptability of official reception supervision. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the structure of the terminal device of the present invention;

[0027] Figure 2 This is a flowchart of the early warning method for official receptions according to the present invention;

[0028] Figure 3 This is a block diagram of the early warning system for official receptions according to the present invention;

[0029] Figure 4 This is a layered architecture diagram of the early warning system for official receptions according to the present invention. Detailed Implementation

[0030] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The specific embodiments described herein are merely used to explain the present invention and are not intended to limit the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] This invention provides an early warning method for official receptions, comprising the following steps:

[0032] Configure a field for whether a unit is a central township in the unit file, and configure a field for whether a unit is a central county or district and a field for determining the distance threshold between units in the same city in the administrative division file; mark the field for whether a unit is a central township or district for remote township units as "no", and mark the field for whether a unit is a central county or district, including the city level, as "yes".

[0033] Specifically, a new field "Whether it is a central township unit" has been added to the unit file, with a default value of "Yes"; a new field "Whether it is a central county / district" has been added to the administrative division file, with a default value of "No". At the same time, a new field "Same city determination distance threshold" has been added, with a default value of 50 kilometers for municipal-level administrative divisions and 30 kilometers for county-level administrative divisions.

[0034] Supervisors will dynamically adjust the relevant field markings based on travel policies: marking the "Whether it is a central township unit" field for remote township units as "No", and marking the "Whether it is a central county / district" field for central counties / districts (including the city level) as "Yes". In special scenarios (such as mountainous terrain), supervisors can manually adjust the "same-city determination distance threshold" (for example, expanding the threshold for city-level districts to 60 kilometers).

[0035] When a business traveler creates an electronic letter, the system automatically collects its GPS location information as latitude and longitude 1, and calls the blockchain interface to store the letter content and location data as evidence, generating a hash value and uploading it to the blockchain;

[0036] Specifically, at point 1 (the official letter creation stage): the business trip unit creates an electronic official letter of reception through the client. The system automatically collects and uploads GPS positioning information (latitude and longitude 1) to the server. At the same time, it calls the blockchain interface to store the content of the official letter and the positioning data, generates a unique hash value and puts it on the chain.

[0037] At point 2 (reception application stage): The receiving unit creates a reception application form through the client and associates it with the reception electronic letter. At the same time, it uploads its own GPS location information (latitude and longitude 2), and calls the blockchain interface again to store the application content and location data, generate a unique hash value and put it on the chain.

[0038] When the receiving unit creates a reception application form and associates it with the aforementioned electronic letter, the system automatically collects its GPS location information as latitude and longitude 2, and calls the blockchain interface to store the application content and location data, generating a hash value and uploading it to the chain; the storage process of the letter content and location data, and the application content and location data, are all implemented through the blockchain.

[0039] Multi-level collaborative judgment is performed based on the information in the fields, including: if two units are in the same county and are both marked as central township units, or if they are in different counties and are both marked as central counties and are both marked as central township units, then dynamic location verification is performed; the smaller value of the distance threshold for judging the same city of the two units is taken as the actual judgment standard, and the spherical distance between latitude and longitude 1 and latitude and longitude 2 is calculated using the Haversine formula. If the calculated distance is less than or equal to the actual judgment standard, then it is judged as same city reception.

[0040] Furthermore, the default distance threshold for determining same-city status is set to 50 kilometers at the city level and 30 kilometers at the county level. In addition, regulators can manually adjust the same-city distance threshold based on terrain features, expanding the threshold to 60 kilometers for city-level areas in mountainous scenarios.

[0041] When it is determined to be a same-city reception, an early warning notice is generated, which includes the unit, district, GPS data, threshold parameters and the basis for the judgment. The notice is pushed to the regulatory terminal and the information of the early warning notice is stored on the blockchain.

[0042] For example, scenario 1: Reception within the same county / district:

[0043] 1. Obtain information on the county / district (district) where the receiving unit and the receiving unit are located, as well as the "whether it is a central township unit" field mark in the unit's file.

[0044] 2. If both units are located in the same county or district and are both marked as "central township units", then dynamic location verification will be performed.

[0045] For example, scenario 2: Reception between different counties within the same region:

[0046] 1. Obtain information on the county / district where the receiving unit and the receiving unit are located, as well as the "whether it is a central township / town unit" field mark in the unit's file, and at the same time obtain the "whether it is a central county / district" field mark in the two counties / districts.

[0047] 2. If both counties / districts are marked as "central counties / districts", and both the receiving unit and the receiving unit are marked as "central township units", then dynamic location verification will be initiated.

[0048] Furthermore, the system employs dynamic location verification (differentiated threshold judgment): if the administrative rule verification passes, the system will query the "same-city judgment distance threshold" (default value: 50 kilometers for city level, 30 kilometers for county level, manual adjustment is supported) for the districts where the receiving unit and the receiving unit are located. The threshold selection logic is: take the smaller value between the thresholds for the districts where the receiving unit and the receiving unit are located as the actual judgment standard to ensure a more stringent judgment.

[0049] The system uses the Haversine formula to calculate the spherical distance between the location at which the reception letter was created (latitude and longitude 1) and the location at which the reception application was submitted (latitude and longitude 2). If the calculated distance is less than or equal to the actual judgment threshold (i.e., the smaller of the zoning thresholds for the receiving unit and the receiving unit), it is determined to be a reception within the same city; otherwise, no warning is triggered.

[0050] The early warning generation and push mechanism is as follows: The system generates an early warning notice only when both administrative rule verification and dynamic location verification pass, and pushes it to the regulatory personnel's terminal, while simultaneously storing it on the blockchain. The early warning notice information includes the receiving and receiving units, the administrative division, the application number, the time, GPS data, threshold parameters, and the basis for judgment.

[0051] On the other hand, the present invention proposes an early warning system for official receptions, comprising:

[0052] The client application is used to create electronic official documents, reception application forms, and collect GPS location data.

[0053] The server is used to perform field configuration, multi-level collaborative judgment, and early warning order generation.

[0054] The regulatory end is used to receive early warning notices and supports dynamic configuration of whether a unit is a central township, whether it is a central county or district, and the distance threshold for determining whether it is in the same city;

[0055] Blockchain nodes are used to store the hash values ​​of electronic official documents, reception application forms, and early warning forms, thereby achieving data notarization and tamper-proofing.

[0056] The client includes clients for the traveling unit and clients for the receiving unit, which can be accessed via browser web pages, mobile applications or desktop clients, and can also be quickly linked to electronic documents by scanning QR codes.

[0057] The server is equipped with a field configuration module, a blockchain evidence storage interface, a distance calculation engine, and an early warning push service. The distance calculation engine integrates the Haversine formula for spherical distance calculation, and the early warning push service uses a message queue to achieve multi-channel asynchronous push of SMS, APP notifications, emails, and in-site messages.

[0058] In addition, the early warning system further includes:

[0059] Initialization module: Used to configure the unit / district field and the distance threshold for same-city determination;

[0060] Location acquisition module: Dual-time GPS acquisition and blockchain evidence storage unit;

[0061] Judgment Calculation Module: Integrates administrative rule engine and dynamic distance calculation unit;

[0062] Warning generation module: Generates warning information and pushes it through multiple channels.

[0063] In addition, the aforementioned components, during execution, are also used to implement other steps of the aforementioned early warning method for official receptions, as follows:

[0064] This application provides an early warning method for official receptions, such as... Figure 1 As shown. In the implementation environment, this method establishes a two-way communication architecture between server 110 and terminal 120 via IP network or cellular mobile network. The number of terminals and servers is unlimited. Terminal 120 can be a single or multiple devices, covering various types such as personal computers, laptops, smartphones, PDAs, tablets, and portable wearable devices. Server 110 can be implemented as a standalone computer server, virtual host, shared host, or a server cluster consisting of multiple servers. Terminal 120 includes three types of operating terminals: client terminals for the business travel unit, client terminals for the receiving unit, and monitoring terminals. Server 110 centrally deploys the field configuration module, blockchain evidence storage interface, distance calculation engine, and early warning generation and push service. The system implementation process is divided into three core stages:

[0065] Phase 1: System Initialization and Dynamic Configuration: Supervisors log in to server 110 via terminal 120 to complete basic parameter configuration. First, a new field, "Whether it is a central township unit," is added to the unit file table, with a default value of "Yes." Simultaneously, a new field, "Whether it is a central county / district" (default value "No") and a "Same-city distance threshold" field are added to the administrative division file table (default 50 km for city-level units, 30 km for county-level units). For specific application scenarios, the system provides a dynamic adjustment mechanism: supervisors can mark the "Whether it is a central township unit" field for remote township units as "No," and mark the "Whether it is a central county / district" field for central counties / districts (including the city level) as "Yes." Furthermore, in complex scenarios such as mountainous terrain, supervisors can manually increase the "Same-city distance threshold" (e.g., adjusting the city-level threshold to 60 km).

[0066] The second phase involves dual-timepoint data collection and notarization: The data collection process covers two key time points. Time point 1 (official letter creation) is initiated by the business trip unit via terminal 120. The system automatically acquires GPS location information (latitude and longitude 1), encapsulates the official letter content and location data into JSON format, calls the blockchain interface of server 110 to complete notarization, generates a unique hash value, and uploads it to the blockchain. Time point 2 (reception application) is triggered when the receiving unit associates the electronic official letter with the creation of an application form. The system collects the receiving unit's GPS location information (latitude and longitude 2), encapsulates the application content and location data, and similarly notarizes it through the blockchain interface to generate a hash value and upload it to the blockchain. These two notarization operations ensure the traceability of the entire process for the official letter and application form. In addition, the C# code example for blockchain notarization covers logic such as data encapsulation, hash calculation, and interface calls.

[0067] using System;

[0068] using System.Security.Cryptography;

[0069] using System.Text;

[0070] using System.Net.Http;

[0071] using Newtonsoft.Json;

[0072] / / Data model class

[0073] public class DocumentData

[0074] {

[0075] public string Content { get; set;} / / Content of official letter / application form

[0076] public LocationInfo Location { get; set;} / / GPS location information

[0077] }

[0078] public class LocationInfo

[0079] {

[0080] public double Latitude { get; set;} / / Latitude

[0081] public double Longitude { get; set;} / / Longitude

[0082] }

[0083] / / Blockchain evidence storage service class

[0084] public class BlockchainService

[0085] {

[0086] private readonly string _blockchainUrl = "https: / / api.blockchain.gov / v1 / Evidence interface"; / / Blockchain interface address

[0087] private readonly HttpClient _httpClient = new HttpClient();

[0088] / / General evidence storage method

[0089] public string StoreDocument(DocumentData document, string documentType)

[0090] {

[0091] try

[0092] {

[0093] / / 1. Package JSON data

[0094] string jsonData = JsonConvert.SerializeObject(document);

[0095] / / 2. Calculate hash value

[0096] string hash = CalculateSHA256(jsonData);

[0097] / / 3. Construct request body

[0098] var request = new

[0099] {

[0100] data = jsonData,

[0101] hash = hash,

[0102] documentType = documentType, / / "Official Letter" or "Application Form"

[0103] timestamp = DateTime.UtcNow

[0104] };

[0105] / / 4. Call the blockchain interface

[0106] var response = _httpClient.PostAsJsonAsync(_blockchainUrl,request).Result;

[0107] response.EnsureSuccessStatusCode();

[0108] / / 5. Return the evidence hash

[0109] return hash;

[0110] }

[0111] catch (Exception ex)

[0112] {

[0113] / / Exception handling

[0114] throw new ApplicationException($"Blockchain notarization failed:{ex.Message}");

[0115] }

[0116] }

[0117] / / SHA256 hash calculation method

[0118] private string CalculateSHA256(string input)

[0119] {

[0120] using (SHA256 sha256 = SHA256.Create())

[0121] {

[0122] byte[] bytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(input));

[0123] StringBuilder builder = new StringBuilder();

[0124] foreach (byte b in bytes)

[0125] {

[0126] builder.Append(b.ToString("x2"));

[0127] }

[0128] return builder.ToString();

[0129] }

[0130] }

[0131] }

[0132] / / Example usage (corresponding to calls at two different times)

[0133] public class Program

[0134] {

[0135] public static void Main()

[0136] {

[0137] var blockchainService = new BlockchainService();

[0138] / / Point in time 1: Official letter creation and preservation

[0139] var officialDocument = new DocumentData

[0140] {

[0141] Content = "Official letter regarding business trip for Project XX",

[0142] Location = new LocationInfo { Latitude = xxxx, Longitude =xxxxx}

[0143] };

[0144] string docHash = blockchainService.StoreDocument(officialDocument, "Official Letter");

[0145] / / Point 2: Receiving application for evidence storage

[0146] var application = new DocumentData

[0147] {

[0148] Content = "XX Unit Reception Application Form",

[0149] Location = new LocationInfo { Latitude = xxxx, Longitude =xxxx}

[0150] };

[0151] string appHash = blockchainService.StoreDocument(application,"Application Form");

[0152] Console.WriteLine($"Document Hash: {docHash}");

[0153] Console.WriteLine($"Application Single Certificate Hash: {appHash}");

[0154] }

[0155] };

[0156] Phase 3: Multi-level collaborative judgment and early warning mechanism

[0157] Server 110 implements a dual verification mechanism: first, it performs administrative rule verification, covering two scenarios: reception within the same county / district and reception across counties / districts.

[0158] In scenarios involving reception within the same county or district, the system queries the county or district where both units are located and whether they are designated as "central township units". If both are marked as "yes", the system proceeds to the dynamic location verification stage.

[0159] In cross-county / district reception scenarios, the system simultaneously queries the "whether it is a central county / district" flag of both counties / districts and the "whether it is a central township / unit" flag of both units. If both the county / district and the unit are marked as "yes", location verification is triggered.

[0160] During the dynamic positioning verification phase, the system uses the smaller of the threshold values ​​for the areas where the receiving unit and the received unit are located as the actual judgment criterion, and calls the Haversine formula to calculate the spherical distance. An example of the calculation formula code is as follows (C#):

[0161] public static double CalculateDistance(double lat1, double lon1,double lat2, double lon2)

[0162] {

[0163] const double R = 6371.0; / / Earth's radius (km)

[0164] var lat1Rad = lat1 * Math.PI / 180;

[0165] var lon1Rad = lon1 * Math.PI / 180;

[0166] var lat2Rad = lat2 * Math.PI / 180;

[0167] var lon2Rad = lon2 * Math.PI / 180;

[0168] var dLon = lon2Rad - lon1Rad;

[0169] var dLat = lat2Rad - lat1Rad;

[0170] var a = Math.Sin(dLat / 2) * Math.Sin(dLat / 2) +

[0171] Math.Cos(lat1Rad) * Math.Cos(lat2Rad) *

[0172] Math.Sin(dLon / 2) * Math.Sin(dLon / 2);

[0173] var c = 2 * Math.Asin(Math.Sqrt(a));

[0174] return R * c; / / Returns the calculated distance

[0175] };

[0176] In this system, parameters lat1 and lon1 represent the latitude and longitude of time point 1, respectively, while parameters lat2 and lon2 represent the latitude and longitude of time point 2. When the calculated distance is less than or equal to the set threshold, the system determines it to be a same-city reception. After double verification, the warning generation module will automatically generate a warning form containing unit information, district, GPS data, threshold parameters, and judgment criteria. The hash value of the warning form will be stored on the blockchain for evidence, and simultaneously pushed to the regulatory and business terminals.

[0177] The technical solution of this invention operates through the coordinated operation of four modules: an initialization module deployed on server 110, providing a field configuration interface and a threshold adjustment interface; a positioning and acquisition module integrated into terminal 120, which realizes data acquisition and storage through H5 positioning or a built-in GPS chip and blockchain SDK; a judgment and calculation module built into server 110, including an administrative rule engine and a distance calculation engine; and an early warning generation module that supports multi-channel push notifications such as SMS, APP, email, and in-site messages. The program execution flow stored in the computer-readable storage medium is as follows: field initialization, dual-time point data acquisition and storage, administrative rule verification, dynamic distance calculation, and early warning information generation.

[0178] In one embodiment, such as Figure 2 As shown, an early warning method for official receptions is provided. This method is applied to... Figure 1 Taking server 110 and terminal 120 as examples, the following steps are included:

[0179] Step 210: Field Initialization and Dynamic Adjustment

[0180] Supervisors log in to server 110 via the supervisory terminal. First, they add a field to the unit file table: "Is it a central township unit?" (default value: "Yes"). Then, they add a field to the administrative division file table: "Is it a central county / district?" (default value: "No") and a "same-city distance threshold" (default 50 km for city-level units, 30 km for county-level units). For special scenarios, the system supports a dynamic adjustment mechanism: supervisors can mark the "Is it a central township unit?" field for remote township units as "No", and the "Is it a central county / district?" field for central counties / districts (including city-level units) as "Yes". In complex scenarios such as mountainous terrain, they can manually increase the "same-city distance threshold" (e.g., adjust the city-level threshold to 60 km). All configuration data is synchronized to the configuration center on server 110 via database transactions.

[0181] Step 220: Dual-time GPS positioning data collection and storage

[0182] The data acquisition process involves two key moments:

[0183] Point 1 (Letter Creation): When the business trip unit creates an electronic letter through the client, terminal 120 automatically collects GPS positioning information (latitude and longitude 1), encapsulates the letter content and positioning data into JSON format, calls the blockchain interface of server 110 for notarization, and uploads it to the blockchain after generating a unique hash value.

[0184] Point 2 (Reception Application): When the receiving unit creates an application form in conjunction with the electronic letter, Terminal 120 automatically collects its own GPS location information (latitude and longitude 2), encapsulates the application content and location data into JSON format, and calls the blockchain interface again for notarization and generates a hash value for on-chain storage. These two notarization operations ensure the traceability of the entire process of the letter and application form, and the data hash value is synchronously stored to the blockchain node.

[0185] Step 230: Multi-level collaborative judgment and early warning

[0186] Server 110 implements a dual verification mechanism:

[0187] 1. Verification of administrative rules

[0188] Scenario 1 (Reception in the same county / district): Query the county / district where the two units are located and whether they are central township / town units. If both are marked as "yes", then proceed to dynamic location verification.

[0189] Scenario 2 (Cross-county reception): Query whether the two counties / districts are central counties / districts and whether the two units are central township units. If both the county / district and the unit are marked as "yes", then trigger location verification.

[0190] 2. Dynamic positioning verification

[0191] The system uses the smaller of the threshold values ​​for the receiving unit and the district where the receiving unit is located as the actual criterion, and calls the Haversine formula to calculate the spherical distance (see the aforementioned embodiment for code examples). When the calculated distance is less than or equal to the actual threshold, it is determined to be a same-city reception.

[0192] 3. Early Warning Generation and Push Notification

[0193] After successful dual verification, server 110 will automatically generate an early warning notice containing unit information, administrative division, GPS data, and threshold parameters. The hash value of the early warning notice will be stored on the blockchain and pushed to the regulatory and business terminals via a message queue, supporting multiple channels such as SMS, APP, email, and in-system messages.

[0194] In one embodiment, such as Figure 3 As shown, an early warning system for official receptions is provided. This system is applied to... Figure 1Taking server 110 and terminal 120 as examples, the system includes an initialization module 310, a positioning and acquisition module 320, a judgment and calculation module 330, and an early warning generation module 340. These modules work together to achieve full-process control of official receptions. Specific functions are as follows:

[0195] Initialization module 310:

[0196] Deployed on server 110, it provides a field configuration interface and a dynamic adjustment interface, supporting supervisors to perform the following operations:

[0197] Add a new field "Whether it is a central township unit" (default value "Yes") to the unit file table;

[0198] Add the fields "Whether it is a central county / district" (default value "no") and "Same city determination distance threshold" to the administrative division archive table (default 50 kilometers for city level, default 30 kilometers for county level);

[0199] For special scenarios (such as remote towns, central counties, and mountainous terrain), manual adjustment of field tags and threshold parameters is supported, and the adjusted data is synchronized to the configuration center through database transactions.

[0200] Location acquisition module 320: Integrated into terminal 120 (client of the business trip unit / client of the receiving unit), it achieves dual-time point data acquisition and evidence storage through H5 or built-in GPS chip and blockchain SDK collaboration.

[0201] Point 1 (Letter Creation): Automatically obtain GPS positioning information (latitude and longitude 1), encapsulate the letter content and positioning data into JSON format, call the blockchain interface of server 110 to complete the notarization, and generate a unique hash value to be uploaded to the chain.

[0202] Time point 2 (receiving application): Automatically obtain GPS location information (latitude and longitude 2), encapsulate the application content and location data, call the blockchain interface again for evidence storage, and generate a hash value to be uploaded to the chain.

[0203] This module supports an offline caching mechanism, ensuring that data can be temporarily stored locally in the event of network failure and automatically re-uploaded once the network is restored.

[0204] Calculation module 330:

[0205] Deployed on server 110, it has a built-in administrative rule engine and distance calculation engine, and performs dual verification logic:

[0206] Administrative rule verification:

[0207] In the same county / district scenario: query the county / district where the two units are located and the "whether it is a central township / town unit" flag. If both are marked as "yes", then trigger location verification.

[0208] Cross-county / district scenario: Query whether the two counties / districts are central counties / districts and whether the two units are central township / units. If both the county / district and the unit are marked as "yes", then trigger location verification.

[0209] Dynamic positioning verification:

[0210] The smaller of the threshold values ​​for the receiving unit and the district where the receiving unit is located is taken as the actual judgment standard.

[0211] The Haversine formula is used to calculate the spherical distance. If the calculated distance is less than or equal to the actual threshold, it is determined to be a same-city reception.

[0212] The early warning generation module 340, deployed on server 110, supports multi-channel early warning push. After successful dual verification, it automatically generates an early warning form containing unit information, administrative division, GPS data, and threshold parameters, and stores the hash value on the blockchain for evidence. Asynchronous push is achieved through a message queue, supporting multiple channels such as SMS, APP, email, and in-system messaging to ensure that regulatory and business terminals receive early warning information in real time. In addition, it provides an interface for viewing early warning form details, supporting the retrieval of historical early warning records by unit, time, administrative division, and other dimensions.

[0213] In one embodiment, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, it enables the processor to perform the steps of the aforementioned official reception early warning method. The steps of the official reception early warning method referred to herein may be the specific steps of the official reception early warning method mentioned in the above embodiments.

[0214] In another embodiment, an implementation method for an early warning system for official receptions is introduced. This system comprises a client, a server, a monitoring terminal, and blockchain nodes. Through multi-terminal collaboration, it achieves intelligent management and control of the entire official reception process. The processor first performs field initialization and dynamic adjustment operations, adding relevant fields and setting default values ​​in unit and district files to support supervisors in adjusting field markers and judgment thresholds according to actual scenarios.

[0215] Subsequently, the system enters the dual-time-point GPS positioning data collection phase, collecting positioning data at the time of official document creation and the time of reception application, and completing data storage through a blockchain interface. In the multi-level collaborative judgment stage, the processor performs dual verification by combining administrative rules and dynamic positioning information: first, it determines whether a same-city reception scenario is triggered based on zoning attributes and field markers, and then verifies the actual spatial relationship through threshold comparison and distance calculation.

[0216] Finally, when both verifications pass, the system automatically generates an early warning message and completes the on-chain evidence storage, while simultaneously pushing it to regulatory and business terminals through multiple channels. Specific implementation details are as follows:

[0217] like Figure 4 As shown, the system adopts a layered architecture design:

[0218] Client 410: Covers both business travelers' and host organizations' clients, supporting three forms: browser H5 webpage, mobile application (iOS / Android / HarmonyOS), and desktop client program. After user login authentication, an encrypted communication channel is established with the server.

[0219] Server 420: Deploys field configuration modules, blockchain evidence storage interfaces, distance calculation engines, and early warning push services, while also providing user login authentication interfaces and persistent data storage capabilities.

[0220] Regulatory Terminal 440: Supports browser web pages, mobile applications and desktop client programs, and interacts with the server through an independent permission system to realize the reception of early warning information and dynamic adjustment of system parameters.

[0221] Blockchain 430: A consortium blockchain composed of multiple nodes that stores the hash values ​​of official documents, application forms, warning forms, and location data, ensuring that the data is tamper-proof and traceable.

[0222] In terms of client-side functionality, the client is divided into two roles: the traveling unit and the receiving unit. The specific functions are as follows:

[0223] 1. Official letter creation (for business trips)

[0224] Users fill in electronic letter information through the client, and the system automatically calls the terminal's GPS module to collect location data (latitude and longitude 1). The client encapsulates the letter content and location data into JSON format and uploads it to the server via HTTPS protocol. After successful upload, the client receives the blockchain notarization hash value returned by the server and associates it with the letter number.

[0225] 2. Application Form Creation (Receiving Unit)

[0226] Users create reception application forms by linking electronic official documents through the client application. The system automatically collects the GPS location data (latitude and longitude) of the receiving unit. The client encapsulates the application content and location data into JSON format, uploads it to the server, and receives the hash value of the blockchain-stored evidence. The client also supports scanning QR codes to quickly link official documents; the QR code content mainly includes the official document number.

[0227] In terms of server functionality implementation, the server, as the core of the system, deploys the following key modules:

[0228] 1. Field Configuration Module

[0229] This module provides a RESTful API interface, supporting the regulatory end to initialize and dynamically adjust fields in unit files and administrative division files. The unit files now include the field "Whether it is a central township unit" (default value is "Yes"), and the administrative division files now include the field "Whether it is a central county / district" (default value is "No") and the "same-city distance threshold" (50 km for city-level units, 30 km for county-level units). Configuration data is synchronized to the configuration center via database transactions to ensure data consistency across multiple nodes.

[0230] 2. Blockchain Evidence Storage Interface

[0231] It integrates a blockchain SDK to provide notarization services for official letters, application forms, and early warning notices. Each notarization generates a unique hash value and is synchronized to the blockchain node via a P2P protocol to ensure data immutability.

[0232] 3. Distance Calculation Engine

[0233] The engine incorporates the Haversine formula to calculate spherical distances (see the code example in the previous embodiment), and supports dynamic threshold comparison. It employs an asynchronous computation mode, effectively avoiding performance bottlenecks in high-concurrency scenarios.

[0234] 4. Early warning push service

[0235] Early warnings are pushed asynchronously using a message queue, supporting multiple channels including SMS, app notifications, email, and in-app messages. The pushed content includes the organization name, administrative division, GPS data, threshold parameters, and evidence hash values, ensuring information traceability.

[0236] The regulatory interface is implemented, serving as the system management entry point and providing the following functions:

[0237] 1. Early warning information management

[0238] It receives real-time alerts pushed by the server and supports filtering and exporting by unit, time, and region. It provides an interface for viewing alert details, displaying the storage hash value and location data of official letters and application forms.

[0239] 2. System parameter adjustment

[0240] It supports dynamically modifying the "Whether it is a central township unit" field marker in unit files and the "Whether it is a central county / district" field marker in administrative division files. It provides a threshold adjustment interface, supporting the setting of "same-city judgment distance threshold" according to city-level and county-level administrative division types, and can be manually expanded in special scenarios (such as adjusting to 60 kilometers in mountainous terrain).

[0241] 3. User permission management

[0242] The system employs a Role-Based Access Control (RBAC) model, differentiating between three roles: supervisors, users from visiting organizations, and users from receiving organizations. Permission configuration data is stored in a database, supporting integration with third-party authentication systems.

[0243] The blockchain node implementation adopts a consortium blockchain architecture, jointly maintained by multiple independent organizations, and its specific functions are as follows:

[0244] 1. Data storage and evidence

[0245] The system receives official letters, application forms, warning notices, and location data uploaded from the server, calculates their hash values, and packages them onto the blockchain. Each block contains a timestamp, the hash value of the previous block, and a list of transaction data hash values, ensuring that the chain-like data structure is immutable.

[0246] 2. Data Validation

[0247] A hash value query interface is provided, supporting the verification of whether data has been tampered with through hash values. Regulatory authorities can call this interface to verify the authenticity of the evidence storage hash values ​​in warning notices.

[0248] System workflow example:

[0249] 1. Supervisors log in to the server through the supervisory terminal to complete field initialization and threshold settings.

[0250] 2. When a customer is on a business trip, they can create an electronic letter through the client. The client automatically collects GPS location data and uploads it to the server. The server then calls the blockchain interface to store the evidence and returns a hash value.

[0251] 3. The receiving unit creates an application form by associating the official letter with the client. The client automatically collects GPS location data and uploads it to the server. The server then calls the blockchain interface again for evidence storage.

[0252] 4. The server performs administrative rule verification and dynamic location verification. If both verifications pass, an early warning notice is generated, and the hash value is stored on the blockchain as evidence and pushed to the regulatory end through a message queue.

[0253] 5. Regulators can view the details of warning notices through the regulatory terminal and adjust system parameters to optimize the judgment logic.

[0254] In summary, this invention, through the marking of "whether it is a central township unit" and "whether it is a central county / district" fields and the function of manually adjusting thresholds, supports personalized configurations for special scenarios such as remote areas and mountainous regions (e.g., extending the city-level threshold to 60 kilometers in mountainous areas), effectively solving the problem of rigid rules in traditional systems. This invention, through the deep integration of technical means and regulatory rules, provides an intelligent, precise, and reliable solution for the supervision of official receptions, demonstrating significant technological progress and practical value.

[0255] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for early warning of official receptions, characterized in that, Includes the following steps: Configure a field for whether a unit is a central township in the unit file, and configure a field for whether a unit is a central county or district and a field for determining the distance threshold between units within the same city in the administrative division file; When a business traveler creates an electronic letter, the system automatically collects its GPS location information as latitude and longitude 1, and calls the blockchain interface to store the letter content and location data as evidence, generating a hash value and uploading it to the blockchain; When the receiving unit creates a reception application form and associates it with the aforementioned electronic letter, the system automatically collects its GPS positioning information as latitude and longitude 2, and calls the blockchain interface to store the application content and positioning data, generating a hash value and uploading it to the chain; Multi-level collaborative judgment is performed based on the information in the fields, including: if two units are in the same county and are both marked as central township units, or if they are in different counties and are both marked as central counties and are both marked as central township units, then dynamic location verification is performed; the smaller value of the distance threshold for judging the same city of the two units is taken as the actual judgment standard, and the spherical distance between latitude and longitude 1 and latitude and longitude 2 is calculated using the Haversine formula. If the calculated distance is less than or equal to the actual judgment standard, then it is judged as same city reception. When it is determined to be a same-city reception, an early warning notice is generated, which includes the unit, district, GPS data, threshold parameters and the basis for the judgment. The notice is pushed to the regulatory terminal and the information of the early warning notice is stored on the blockchain.

2. The early warning method for official receptions according to claim 1, characterized in that: The distance threshold for determining same-city status is set to 50 kilometers by default at the city level and 30 kilometers by default at the county level.

3. The early warning method for official receptions according to claim 1, characterized in that: Also includes: Supervisors manually adjust the distance threshold for determining same-city status based on terrain features, expanding the threshold for city-level districts to 60 kilometers in mountainous scenarios.

4. The early warning method for official receptions according to claim 1, characterized in that: Also includes: Mark the field "Whether it is a central township unit" for remote township units as "No", and mark the field "Whether it is a central county / district unit" for central counties / districts including the city level as "Yes".

5. The early warning method for official receptions according to claim 1, characterized in that: The process of storing the official letter content and location data, as well as the application content and location data, is all implemented through blockchain.

6. An early warning system for implementing the method of any one of claims 1-5 for official receptions, characterized in that, include: The client application is used to create electronic official documents, reception application forms, and collect GPS location data. The server is used to perform field configuration, multi-level collaborative judgment, and early warning order generation. The regulatory end is used to receive early warning notices and supports dynamic configuration of whether a unit is a central township, whether it is a central county or district, and the distance threshold for determining whether it is in the same city; Blockchain nodes are used to store the hash values ​​of electronic official documents, reception application forms, and early warning forms, thereby achieving data notarization and tamper-proofing.

7. The early warning system for official receptions according to claim 6, characterized in that: The client includes clients for the traveling unit and clients for the receiving unit, and supports access via browser web pages, mobile applications or desktop clients, and supports scanning QR codes to quickly link electronic official documents.

8. The early warning system for official receptions according to claim 6, characterized in that: The server is equipped with a field configuration module, a blockchain evidence storage interface, a distance calculation engine, and an early warning push service. The distance calculation engine integrates the Haversine formula for spherical distance calculation, and the early warning push service uses a message queue to achieve multi-channel asynchronous push of SMS, APP notifications, emails, and in-site messages.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the early warning method for official receptions as described in any one of claims 1 to 5.

Images