Boot compensation method and device, electronic equipment and storage medium

Abstract

The application provides a startup compensation method and device, electronic equipment and a storage medium. The startup compensation method comprises the following steps: monitoring a payment task table, and determining whether the payment task table meets a compensation condition; in response to the payment task table meeting the compensation condition, obtaining payment information and arrears information of each user in the payment task table, and determining a startup task table according to the payment information and the arrears information; determining a startup mode of each user to be started according to a startup task quantity in the startup task table, and performing startup compensation on the user to be started according to the startup mode, so as to solve the technical problem that a user cannot be started in time in the prior art.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication service processing, and in particular to a start-up compensation method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the continuous expansion of user scale and market size, the number of payment start-up work orders reaches millions per day, and the start-up timeliness greatly affects user experience perception and service quality. Payment start-up delay can cause users to be unable to communicate normally and a large number of complaints and upgrades, and the user experience is poor.

[0003] The payment start-up whole process involves three stages of payment to account, business start-up work order processing and network element start-up instruction. Each stage has multiple processes and multiple interactions, which can easily cause process jamming and process stopping. The existing emergency payment start-up technology only solves the payment work order backlog of payment start-up, and the emergency start-up is not complete, and there is still abnormal start-up, and the user experience is poor. SUMMARY

[0004] The present application aims to at least solve one of the technical problems in the related art to some extent.

[0005] To this end, a first object of the present application is to provide a start-up compensation method to realize timely start-up and improve user experience.

[0006] A second object of the present application is to provide a start-up compensation device.

[0007] A third object of the present application is to provide an electronic device.

[0008] A fourth object of the present application is to provide a computer-readable storage medium.

[0009] A fifth object of the present application is to provide a computer program product.

[0010] To achieve the above objects, a first aspect of the present application provides a start-up compensation method, comprising:

[0011] monitoring a payment task table and determining whether the payment task table meets a compensation condition;

[0012] in response to the payment task table meeting the compensation condition, obtaining payment information and arrears information of each user in the payment task table, and determining a start-up task table according to the payment information and the arrears information, the start-up task table including one or more users to be started up;

[0013] determining a start-up mode of each of the users to be started up based on a start-up task amount in the start-up task table, and compensating the users to be started up according to the start-up mode.

[0014] To achieve the above object, the second aspect of the present application provides a boot compensation device, comprising:

[0015] A monitoring module is configured to monitor a payment task table and determine whether the payment task table meets a compensation condition;

[0016] A obtaining module is configured to, in response to the payment task table meeting the compensation condition, obtain payment information and arrearage information of each user in the payment task table, and determine a boot task table according to the payment information and the arrearage information, wherein the boot task table comprises one or more users to be booted;

[0017] A boot compensation module is configured to determine a boot mode of each of the users to be booted based on a boot task amount in the boot task table, and perform boot compensation on the users to be booted according to the boot mode.

[0018] To achieve the above object, the third aspect of the present application provides an electronic device, comprising a processor and a memory connected with the processor;

[0019] The memory stores computer execution instructions;

[0020] The processor executes the computer execution instructions stored in the memory to implement the method of the first aspect.

[0021] To achieve the above object, the fourth aspect of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method of the first aspect.

[0022] To achieve the above object, the fifth aspect of the present application provides a computer program product, wherein the computer program is executed by a processor to implement the method of the first aspect.

[0023] The boot compensation method, device, electronic device and storage medium provided by the present application can monitor a payment task table, determine whether a user can boot based on payment information and arrearage information when the compensation condition is met, thereby obtaining all users to be booted, ensure the rationality and accuracy of the judgment on the boot task, further determine a boot mode of the user to be booted according to a boot task amount in the boot task table, thereby performing adaptive boot compensation on the user to be booted, take corresponding boot measures for different situations, solve the problem of not timely booting the user payment, and improve the user experience.

[0024] Additional aspects and advantages of the present application will be made apparent by the following description and the accompanying drawings. BRIEF DESCRIPTION OF DRAWINGS

[0025] The above and / or additional aspects and advantages of the present application will become apparent and be made clear to those skilled in the art, which shall read the following description in conjunction with the accompanying drawings.

[0026] Figure 1 A flowchart of a boot compensation method provided by an embodiment of the present application;

[0027] Figure 2 A flowchart of another boot compensation method provided by an embodiment of the present application;

[0028] Figure 3 A logic flowchart of a boot judgment method provided by an embodiment of the present application;

[0029] Figure 4 A flowchart of another boot compensation method provided by an embodiment of the present application;

[0030] Figure 5 A flowchart of another boot compensation method provided by an embodiment of the present application;

[0031] Figure 6 A flowchart of another boot compensation method provided by an embodiment of the present application;

[0032] Figure 7 A logic block diagram of a boot compensation method provided by an embodiment of the present application;

[0033] Figure 8 A structure diagram of a boot compensation device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0034] The embodiments of the present application are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar notations represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by referring to the accompanying drawings are exemplary and are intended to explain the present application, and cannot be understood as a limitation of the present application.

[0035] The boot compensation method, device, electronic equipment and storage medium of the embodiments of the present application are described below with reference to the accompanying drawings.

[0036] The embodiments of the present application can be applied to the scenarios of payment boot of operators, payment boot of life payment or payment boot of video websites, etc. Figure 1 A flowchart of a boot compensation method provided by an embodiment of the present application. As shown in FIG. 1, the method comprises the following steps. Figure 1As shown, the method for compensating for the boot-up includes the following steps:

[0037] S101, monitor the payment task table and determine whether the payment task table meets the compensation condition.

[0038] In some implementations, the payment task table includes one or more payment tasks, each payment task corresponding to a payment behavior of a user, that is, the user will generate a corresponding payment task after payment, which can include this payment log field, user identity document (ID), payment time, payment amount, payment service and processing status. The processing status is used to reflect the state of this payment task, such as handled, unhandled, or processing error, etc.

[0039] It can be understood that the payment task table is a table that is updated and generated in real time. When a user generates a payment behavior, the payment task can be updated to the payment task table. In some implementations, when the payment task is completed, that is, after the user successfully pays, the payment task in the payment task table is updated to handled.

[0040] In some implementations, when there is a backlog of payment tasks in the payment task table, it will cause the payment behavior of the user to be unable to be fed back in time, so that the user's payment cannot be credited in time, thereby affecting the user's boot-up. At this time, the user needs to be compensated for boot-up to improve the timeliness of the user's boot-up, so it can be determined whether the amount of payment tasks in the payment task table meets the compensation condition. When the payment task table meets the compensation condition, the user in the payment task table needs to be compensated for boot-up.

[0041] In some implementations, the compensation condition can be a preset upper limit of the amount of payment tasks. When the payment task table meets the compensation condition, that is, the amount of payment tasks in the payment task table is greater than the upper limit of the amount of payment tasks, the user may not be able to boot up in time, and needs to be compensated for boot-up.

[0042] In some implementations, the compensation condition can also be a payment process exception. When the payment process is abnormal, the payment task in the payment task table cannot be credited, so compensation for boot-up needs to be performed.

[0043] S102, in response to the payment task table meeting the compensation condition, obtaining the payment information and the arrears information of each user in the payment task table, and determining a boot-up task table according to the payment information and the arrears information.

[0044] When the payment task table meets the compensation condition, i.e., the compensation processing needs to be performed on the users in the payment task table, the payment information and the arrearage information of each user in the payment task table are acquired. It can be understood that if the payment task table does not meet the compensation condition, i.e., there is no task backlog in the payment task table, the payment tasks can be processed in sequence to realize the booting of the user.

[0045] In some implementations, the payment information of each user can be identified in the payment task table according to the user ID, and each user can have one or more payment tasks.

[0046] Optionally, the arrearage information of the user, such as the arrearage amount of the user in each month in history and the arrearage amount of the user in the current month, can be acquired from the database. The arrearage amount of the user in each month in history can be recorded in the database after the end of each month, and thus can be read from the general database. The arrearage amount of the user in the current month can be read from the in-memory database, such as the Microsoft Database (MDB), due to the time limitation.

[0047] Further, based on the payment information and the arrearage information of the user, a booting task table is determined, which includes one or more users to be booted; it can be understood that when the user has an arrearage, the arrearage can be compensated by payment, so as to restore the normal use of the account, i.e., when the payment amount is greater than the arrearage amount, the user can be restored to use, i.e., the user can be booted, and the user is taken as a user to be booted, and all the users to be booted constitute the booting task table.

[0048] In some implementations, since there can be multiple payment tasks of a user in the payment task table, all the payment tasks of each user in the payment task table can be summarized to obtain the total payment amount of the user. When the total payment amount is greater than or equal to the arrearage amount, it indicates that the payment amount of the user can offset the arrearage amount, and there can be a balance, and thus the user can be booted, and the user is determined to be a user to be booted.

[0049] In some implementations, the payment service of the user can also be distinguished, such as a broadband service, a call service, or a television service, etc. The payment amounts of different payment services are summarized to obtain the total payment amount of the corresponding service, and the total payment amount of the corresponding service is compared with the corresponding arrearage amount to determine whether the payment amount of the user can offset the arrearage amount of the corresponding service; if the payment amount can offset the arrearage amount of the corresponding service, the user can be booted, and the user is determined to be a user to be booted.

[0050] S103, determine the boot mode of each user to be booted based on the amount of boot tasks in the boot task table, and perform boot compensation on the user to be booted according to the boot mode.

[0051] It can be understood that the boot task table is a boot task of a user to be booted, and the boot task table can include one or more boot tasks, and each boot task can include a corresponding user to be booted and a time when the boot task is generated.

[0052] In some implementations, if the amount of boot tasks in the boot task table is large, the boot task backlog can also occur, which can cause the boot task of the user to be booted to be unable to be executed in time, the boot of the user to be not in time, and thus the user experience to be affected.

[0053] Optionally, the amount of boot tasks in the boot task table can be counted, and when the amount of boot tasks is large, batch processing of the boot task in the boot task table can be performed to avoid the boot of the user to be not in time. In some implementations, a boot task threshold can be set, and when the amount of boot tasks is greater than the boot task threshold, it indicates that the amount of boot tasks is large, and thus the boot mode of the user to be booted in the boot task table can be determined to be batch booting to ensure the use of basic functions by the user; correspondingly, if the amount of boot tasks is less than or equal to the boot task threshold, it indicates that the amount of boot tasks is within the processing capacity at this time, and the boot mode of the user to be booted is sequential booting, that is, the boot compensation processing is performed in turn according to the generation time of the boot task.

[0054] In some implementations, in order to ensure the timeliness of the boot of the user, the generation time of the task of the user to be booted can also be limited, for example, in batch booting, only the user to be booted whose task generation time is within 8 hours is compensated, to avoid the backlog of time being too long so that the user to be booted no longer meets the boot condition, causing false booting; the user to be booted whose task generation time is more than 8 hours can be re-booted to determine whether it still meets the boot condition.

[0055] It can be understood that batch booting is a choice when there is a backlog of users to be booted, and thus batch booting can only restore the basic functions of the user, such as the functions of calling and receiving information, and other additional functions of the user to be booted can be restored when the backlog of boot tasks is gradually processed; sequential booting is boot compensation for boot tasks in turn, and thus sequential booting can restore all functions corresponding to the user.

[0056] In this embodiment, by monitoring the payment task table, when the payment task table meets the compensation condition, the payment information and the arrears information of the user are acquired to determine whether the user can offset the arrears, so as to determine whether the user is a user to be started that can be started, thereby acquiring all the start task tables, ensuring the rationality and accuracy of the judgment of the start task to be started, further acquiring the start task quantity in the start task table, and determining the start mode of the user to be started according to the start task quantity, so as to perform different start compensation on the user to be started, avoid the long waiting time and the start not in time of the user due to the task backlog, and improve the user experience.

[0057] Figure 2 Another flowchart of a start compensation method provided by the embodiments of the present application is shown in FIG. 6. As shown in FIG. 6, the method comprises the following steps. Figure 2

[0058] S201, monitoring the payment task table, and determining whether the payment task table meets the compensation condition.

[0059] In some implementations, the unprocessed payment task quantity and the error task quantity in the payment task table can be acquired; it is determined whether the payment task table has a payment process exception; and in response to at least one condition being met, that the payment process exception exists, the payment task quantity is greater than a first preset number, and the error task quantity is greater than a second preset number, it is determined that the payment task table meets the compensation condition.

[0060] It can be understood that when the unprocessed payment task quantity in the payment task table is greater than the first preset number, it means that the unprocessed payment task quantity is too large, which can cause the problem that the user waits for a long time before starting, and therefore the user can be compensated for starting. For example, if the first preset number is 500, when the payment task quantity in the payment task table is greater than 500, it is determined that the payment task table meets the compensation condition.

[0061] In some implementations, the payment start process is usually performed by a business operation support system (BOSS), and the error task refers to a payment task that fails to be processed by the BOSS system, for example, a payment task that fails to be processed due to network reasons, data errors, or system busy, etc. When the error task quantity is greater than the second preset number, it means that the error task quantity is large, and the system can have related exceptions, and therefore the user can be compensated for starting. For example, if the second preset number is 300, when the error task quantity in the payment task table is greater than 300, it is determined that the payment task table meets the compensation condition.

[0062] ​Optionally, the number of tasks for each error type can also be obtained. If the number of tasks for any error type exceeds a second preset number, it indicates that a large number of payment tasks are experiencing that error type, resulting in payment anomalies, and users need to be compensated upon system restart. For example, assuming the second preset number is 300, if the number of tasks with the same error type in the payment task table exceeds 300, it is determined that the payment task table meets the compensation conditions.

[0063] In some implementations, payment process anomalies refer to process anomalies caused by BOSS system malfunctions. These anomalies may result in users' payments not being credited, failure to trigger overdue payment cancellation, or failure to generate startup tasks. Therefore, when process anomalies occur, startup compensation analysis can be performed on users. In other words, when payment process anomalies exist, it is determined that the payment task table meets the compensation conditions.

[0064] In this application embodiment, the implementation method of step S201 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0065] S202, in response to the payment task table meeting the compensation conditions, retrieve the payment information and arrears information of each user in the payment task table.

[0066] In this application embodiment, the implementation method of step S202 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0067] S203, obtain the user's service suspension type, virtual prepaid information in payment information, and historical and current month's arrears in arrears information.

[0068] Optionally, the user's service suspension type can include suspension due to unpaid fees and suspension due to exceeding credit limits. Suspension due to unpaid fees refers to the user's service suspension status caused by historical unpaid fees from the previous month or earlier. In this case, the service can be restored as long as the historical unpaid fees are settled. Suspension due to exceeding credit limits can be single suspension, double suspension, or pre-cancellation due to unpaid fees. That is, the user's service suspension status is caused by unpaid fees exceeding the single suspension overdraft limit, double suspension overdraft limit, or unpaid fees from 3 months ago. In this case, the historical unpaid fees and the current month's unpaid fees need to be settled.

[0069] In some implementations, "single suspension" means restricting outgoing dialing while maintaining normal incoming dialing; "double suspension" means restricting both outgoing dialing and incoming dialing; and "pre-cancellation" means pre-cancelling a user's account.

[0070] Optionally, the arrears information may include information such as the current month's arrears, historical arrears, arrears period, and user ID. Therefore, the historical arrears and current month's arrears of each user can be determined based on the user's arrears information.

[0071] In some implementations, virtual pre-deposited information refers to virtually crediting the user's payment amount. Since unprocessed payment tasks refer to user payment actions that have not been credited to the account, when determining whether a user can power on the device, it can be assumed that the user's payment amount has been virtually credited to the account. The virtual credit amount can then be used to determine whether it can offset the user's outstanding fees, thus meeting the power-on conditions.

[0072] Optionally, the virtual pre-deposit information may include user ID, user virtual pre-deposit amount, single payment amount, etc. The user virtual pre-deposit amount is the payment amount of the user in the payment task table. The payment amount of all unprocessed payment tasks of the user is summarized to obtain the user's virtual pre-deposit amount.

[0073] S204 determines whether a user meets the power-on conditions based on the user's suspension type, virtual prepaid information, historical arrears, and current month's arrears, and designates users who meet the power-on conditions as users to be powered on, thereby determining the power-on task table.

[0074] Optionally, a payment receipt table can be obtained, and the amount already received in the virtual pre-deposited information can be determined based on the payment receipt table. In other words, the payment receipt table is obtained to determine whether the user's payment task is already in the payment receipt table. If the user's payment task is already in the payment receipt table, it means that the payment task has been processed, and the amount of the payment task is recorded as the amount already received.

[0075] In some implementations, each payment task can correspond to a transaction record field. The transaction record field can uniquely identify the payment task. Therefore, by checking whether the payment receipt table and the payment task table have the same transaction record field, it can be determined whether the payment task has been received.

[0076] Furthermore, the received amount is deducted from the virtual prepaid amount in the virtual prepaid information to obtain the real-time virtual prepaid amount. Since the virtual prepaid amount is a sum of all user payments, the received amount needs to be removed to determine the user's outstanding amount as the real-time virtual prepaid amount. Understandably, when a user's received amount changes, the user's monthly arrears will also be updated in real-time in the in-memory database. Therefore, when determining whether to power on the device based on the current month's arrears, the received amount in the virtual prepaid amount is first deducted, and then the current month's arrears are compared and analyzed with historical arrears.

[0077] Optionally, the real-time virtual prepaid amount includes a virtual basic prepaid amount and a virtual special prepaid amount. The virtual basic prepaid amount refers to the fee paid by the user for basic functions, such as call charges, while the virtual special prepaid amount is the fee paid by the user for special functions, such as television services and broadband services. In some implementations, the user's virtual prepaid information may also include a virtual special identifier to distinguish different special services and clarify the destination of the user's payment task.

[0078] Furthermore, the system obtains the user's total virtual basic prepaid amount and virtual special prepaid amount that can be offset, the user's historical arrears and current month's arrears, the total prepaid amount is all the amount that the user's payment can offset, and the total arrears is all the user's arrears. When the user's payment is sufficient to offset the arrears, the system can be turned on for the user.

[0079] In some implementations, if the service suspension type is "suspension due to unpaid fees," the user is deemed to meet the activation conditions when their virtual basic prepaid amount is greater than or equal to their historical unpaid fees, or when their total prepaid amount is greater than or equal to their historical unpaid fees. In other words, when a user's service is suspended due to unpaid fees, the user is deemed to meet the activation conditions when their virtual basic prepaid amount is greater than or equal to their historical unpaid fees, or when their total prepaid amount is greater than or equal to their historical unpaid fees—that is, when the sum of the user's virtual basic prepaid amount and virtual special prepaid amount that can be offset against the historical unpaid fees is greater than or equal to their historical unpaid fees.

[0080] In some implementations, it can be determined whether the user's virtual basic prepaid amount is greater than or equal to the historical arrears. If the virtual basic prepaid amount is less than the historical arrears, it can be determined whether the user's total prepaid amount is greater than or equal to the historical arrears. If the user's total prepaid amount is greater than or equal to the historical arrears, then the user meets the conditions for powering on. If the user's total prepaid amount is less than the historical arrears, then the user does not meet the conditions for powering on.

[0081] In some implementations, if the suspension type is "over-credit suspension," the user is deemed to meet the restart conditions when the user's virtual basic prepaid amount is greater than or equal to the total outstanding fees, or when the user's total prepaid amount is greater than or equal to the total outstanding fees. In other words, when a user's service is suspended due to "over-credit," the user is deemed to meet the restart conditions when the user's virtual basic prepaid amount is greater than or equal to the total outstanding fees, or when the user's total prepaid amount is greater than or equal to the total outstanding fees, that is, when the sum of the user's virtual basic prepaid amount and virtual special prepaid amount that can be offset is greater than or equal to the total outstanding fees.

[0082] In some implementations, it is also possible to first determine whether the user's virtual basic prepaid amount is greater than or equal to the total outstanding amount. If the virtual basic prepaid amount is less than the total outstanding amount, it is determined whether the user's total prepaid amount is greater than or equal to the total outstanding amount. If the user's total prepaid amount is greater than or equal to the total outstanding amount, then the user meets the power-on conditions. If the user's total prepaid amount is less than the total outstanding amount, then the user does not meet the power-on conditions.

[0083] In other implementations, if the user's service is suspended for reasons other than unpaid fees or exceeding credit limits (meaning the user is neither suspended for unpaid fees nor exceeding credit limits), then the user is determined not to meet the activation requirements. See [link to relevant documentation] for details. Figure 3 This is a logical diagram illustrating whether the user meets the boot conditions.

[0084] S205, based on the number of startup tasks in the startup task table, determines the startup mode of each user to be started, and performs startup compensation for the user to be started according to the startup mode.

[0085] In this application embodiment, the implementation method of step S205 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0086] In this embodiment, the payment task table is judged to meet the compensation conditions by the amount of payment tasks, the amount of error tasks, and the processing progress. This allows for timely handling of payment backlogs or abnormal situations. Virtual pre-deposit information is obtained through user payment information. Based on the user's suspension type, real-time virtual pre-deposit amount, and outstanding amount, it is determined whether the user meets the power-on conditions. This provides a more comprehensive control over whether users are eligible for power-on. By using virtual pre-deposit information, users waiting to be powered on are identified as early as possible for subsequent power-on compensation, reducing user power-on waiting time and ensuring timely handling of payment task backlogs or processing abnormalities.

[0087] Figure 4 This is a schematic flowchart illustrating another power-on compensation method provided in an embodiment of this application. Figure 4 As shown, the method includes:

[0088] S401, monitor the payment task list and determine whether the payment task list meets the compensation conditions.

[0089] In this application embodiment, the implementation method of step S401 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0090] S402, in response to the payment task table meeting the compensation conditions, obtains the payment information and arrears information of each user in the payment task table, and determines the power-on task table based on the payment information and arrears information.

[0091] In this application embodiment, the implementation method of step S402 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0092] S403, in response to the fact that the number of boot tasks in the boot task table is greater than the third preset number, obtain the first boot task within a preset time in the boot task table, and perform batch booting on the first boot task.

[0093] In some implementations, when boot process issues prevent boot tasks from being completed in a timely manner, resulting in a backlog of boot tasks, the boot tasks are extracted and processed directly to avoid a poor user experience caused by delayed booting, prioritizing the user's basic functions such as calls, messages, and internet access.

[0094] Optionally, a third preset quantity can be set. When the number of startup tasks in the startup task table exceeds the third preset quantity, it is determined that there are too many startup tasks in the startup task table, that is, a backlog of startup tasks. In this case, the first startup task is extracted from the startup task table for batch startup. For example, if the third preset quantity is 500, when the number of startup tasks in the startup task table exceeds 500, it is considered that there are too many startup tasks in the startup task table, that is, a backlog of startup tasks.

[0095] In some implementations, boot tasks within a preset time frame can be extracted from the boot task table as the first boot task. This ensures the timeliness of the boot task and avoids incorrect boots caused by changes in the boot task due to excessive time. For example, boot tasks generated within 8 hours can be used as the first boot task. The task generation time is the time when the boot task for the user to be booted is updated in the boot task table after the user is identified as the user to be booted. This prevents incorrect boots caused by changes in the user's status due to excessive waiting time.

[0096] Optionally, the power-on task may include a user ID, task generation time, and power-on type. The power-on type may include one-way power-on and two-way power-on, that is, enabling the outgoing dial-up function, enabling the incoming dial-up function, or enabling both the outgoing dial-up and incoming dial-up functions.

[0097] After obtaining the first boot task from the boot task table, if the boot mode of the first boot task is determined to be batch boot, the boot task can be directly sent to the network element to boot up, enabling the user's basic functions such as calls, messages, and internet access, so as to ensure the availability of the user's basic functions and improve the user experience.

[0098] S404, in response to the number of boot tasks in the boot task table being less than or equal to a third preset number, boot tasks in the boot task table are booted sequentially.

[0099] Understandably, when the number of startup tasks is less than or equal to the third preset number, it indicates that there is no backlog of startup tasks in the startup task table. Therefore, the startup tasks in the startup task table can be started sequentially, that is, the startup tasks in the startup task table are processed one by one, and the user is started according to the startup type in the startup task to restore all functions of the user.

[0100] In some implementations, in order to promptly determine whether there is a backlog of startup tasks in the startup task table, a scan can be performed every 3 minutes to determine and judge the number of startup tasks in the startup task table; in other embodiments, the scan time can be adjusted, for example, a scan can be performed every 5 minutes or every 10 minutes.

[0101] S405 provides startup compensation to users based on their startup mode.

[0102] In some implementations, users can be screened before booting up to compensate them, in order to prevent them from shutting down again after meeting the boot conditions. If the user is then booted up again in this case, it may cause boot chaos.

[0103] Optionally, a shutdown task table can be obtained, which includes shutdown users and shutdown times; duplicate users in the shutdown task table and the power-on task table can be identified, and the task generation time and shutdown time of the duplicate users in the power-on task table and the shutdown task table can be obtained respectively; in response to the task generation time being earlier than the shutdown time, it can be determined that the duplicate user should not be powered on.

[0104] Understandably, the shutdown task table includes one or more shutdown tasks. The purpose of shutdown tasks is to process user shutdowns. If there is a backlog of tasks in both the startup task table and the shutdown task table, it may lead to frequent and chaotic startup and shutdown processes for users, resulting in a poor user experience. Therefore, if there are duplicate users in the shutdown task table and the startup task table, and the startup task of the duplicate user was generated earlier than the shutdown time, then the duplicate user will not be processed.

[0105] For example, suppose user A appears in both the startup task list and the shutdown task list. User A's task in the startup task list is generated at 11:00, and the shutdown time (generated time) in the shutdown task list is 12:00. If user A is powered on while processing the backlog of tasks in the startup task list, user A will be shut down again when the shutdown task list reaches user A's shutdown task. This will cause user A to experience startup and shutdown in a short period of time, reducing the user experience.

[0106] In some implementations, boot tasks can also be marked with fields in the boot task table. For example, processed boot tasks can be marked as 2, unprocessed boot tasks can be marked as 1, and newly added unprocessed boot tasks can be marked as empty, so as to distinguish all boot tasks.

[0107] After filtering out the users in the startup task table who do not need to be processed, the remaining users who need to be started are compensated for startup according to the startup type and startup mode in their corresponding startup tasks to ensure that users who meet the startup requirements can start up normally.

[0108] In this embodiment, after identifying users to be powered on, the backlog of power-on tasks is resolved and processed. When there are many power-on tasks, batch power-on is used to prioritize the use of basic functions for users. Furthermore, when powering on a user, it is determined whether the user will be shut down again to avoid disordered shutdowns. This ensures the timely power-on of users while avoiding blind power-on. It provides good handling measures when processing the backlog of power-on tasks, reducing the user complaint rate and the labor cost of handling complaints.

[0109] Figure 5 This is a schematic flowchart illustrating another power-on compensation method provided in an embodiment of this application. Figure 5 As shown, the method includes:

[0110] S501 monitors the payment task list and determines whether the payment task list meets the compensation conditions.

[0111] In this application embodiment, the implementation method of step S501 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0112] S502, in response to the payment task table meeting the compensation conditions, obtains the payment information and arrears information of each user in the payment task table, and determines the power-on task table based on the payment information and arrears information.

[0113] In this application embodiment, the implementation method of step S502 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0114] S503 determines the boot mode of each user to be booted based on the number of boot tasks in the boot task table, and performs boot compensation for the user to be booted according to the boot mode.

[0115] In this application embodiment, the implementation method of step S503 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0116] S504, obtain the first user who has a balance after payment and whose device is not turned on.

[0117] When obtaining users who meet the requirements for power-on and performing power-on compensation, the power-on task may be lost due to abnormal processing of the power-on network element or abnormal process interaction, resulting in some users being missed during the power-on compensation process. Therefore, all processed users can be filtered to find users who failed to power on and power them on again.

[0118] Optionally, all processed historical payment tasks and the second users corresponding to the historical payment tasks can be obtained within a preset time period. In this embodiment, the preset time period can be 2 hours, that is, all processed historical payment tasks within the past 2 hours and the second users corresponding to all historical payment tasks can be obtained. The second users are the users who have payment amounts.

[0119] Furthermore, based on the payment information in the historical payment tasks, the third user with a balance after payment is identified among the second users. It is understood that the payment information includes the payment amount of the second user. Therefore, it can be determined whether the second user has a balance based on the payment amount and the actual amount owed by the second user. The second user with a balance is then converted into the third user.

[0120] It is understandable that users with a balance after payment have met the conditions for powering on. Therefore, the third user should be a user who has already powered on. If there are still users who have stopped using the third user, then the third user may be a user who was missed during the power-on process. It is necessary to determine whether the third user needs to be powered on again. Therefore, in this embodiment, users who have stopped using the third user are filtered out to obtain the first user. The first user is the user who has a balance after payment but has not powered on.

[0121] It should be noted that the suspended users among the third-party users refer to those whose status is suspended due to exceeding credit limit or being suspended due to unpaid fees.

[0122] S505 filters the first user according to the boot task table to obtain the target users to be booted that are not included in the boot task table.

[0123] To avoid duplicate checks, the boot task table can be queried to identify target users awaiting boot who are not currently listed. It's understood that users in the boot task table are those awaiting boot; therefore, if a user is listed, further checks are unnecessary. However, if the user is not listed, they may have been missed during boot, requiring further analysis of these target users not included in the boot task table.

[0124] S506 configures the virtual pre-stored information of the target user, determines whether the target user meets the boot conditions based on the virtual pre-stored information of the target user, and performs boot compensation for the target user who meets the boot conditions.

[0125] In some implementations, the virtual prepaid information of the target user can be manually configured. For example, the real-time virtual prepaid amount can be configured to be 0 yuan. Based on the real-time virtual prepaid amount, it is determined whether the target user meets the power-on conditions. That is, it is determined whether the virtual prepaid amount of the target user can offset the historical arrears. By judging the power-on conditions, it is determined whether the target user needs to be powered on. Thus, the target users who meet the power-on conditions are given precise power-on compensation again, so as to realize the power-on of all users.

[0126] In this embodiment, after determining the user to be powered on, to address the issue of lost power-on tasks due to process interaction or power-on anomalies, the system identifies the missed target users by filtering processed payment tasks, configures the virtual pre-stored information of the target users, and performs a power-on judgment, thereby triggering the power-on of the target users again, achieving accurate power-on for all users and improving the robustness of the payment power-on system.

[0127] Figure 6 This is a schematic flowchart illustrating a power-on compensation method provided in an embodiment of this application. Figure 6 As shown, the method includes:

[0128] S601 monitors the payment task list and determines whether the payment task list meets the compensation conditions.

[0129] In this application embodiment, the implementation method of step S601 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0130] S602, in response to the payment task table meeting the compensation conditions, retrieves the payment information and arrears information of each user in the payment task table.

[0131] In this application embodiment, the implementation method of step S602 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0132] S603 retrieves the user's service suspension type, virtual prepaid information from payment information, and historical and current month's arrears from arrears information.

[0133] In this application embodiment, the implementation method of step S603 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0134] S604 determines whether a user meets the power-on conditions based on the user's suspension type, virtual prepaid information, historical arrears, and current month's arrears, and designates users who meet the power-on conditions as users to be powered on, thereby determining the power-on task table.

[0135] In this application embodiment, the implementation method of step S604 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0136] S605, in response to the number of boot tasks in the boot task table being greater than the third preset number, obtains the first boot task within a preset time in the boot task table, and performs batch booting on the first boot task.

[0137] In this application embodiment, the implementation method of step S605 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0138] S606, in response to the number of boot tasks in the boot task table being less than or equal to a third preset number, sequentially boots the boot tasks in the boot task table.

[0139] In this application embodiment, the implementation method of step S606 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0140] S607 provides startup compensation to users based on their startup mode.

[0141] In this application embodiment, the implementation method of step S607 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0142] S608, the first user with a balance after payment and who has not turned on the device.

[0143] In this application embodiment, the implementation method of step S608 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0144] S609 filters the first user based on the boot task table to obtain the target users to be booted that are not included in the boot task table.

[0145] In this application embodiment, the implementation method of step S609 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0146] S610 configures the virtual pre-stored information of the target user, determines whether the target user meets the boot conditions based on the virtual pre-stored information of the target user, and performs boot compensation for the target user who meets the boot conditions.

[0147] In this application embodiment, the implementation method of step S610 can be implemented in any of the various embodiments of this disclosure, and no limitation is made here, nor will it be described in detail.

[0148] In this embodiment, by monitoring the payment task table and judging whether the payment task table meets the compensation conditions based on the payment task volume, error task volume, and processing progress, it is possible to promptly handle payment backlogs or abnormal situations. The system obtains user payment and arrears information to determine if a user can offset their arrears, thus identifying whether the user is a user waiting to be powered on. When there are many power-on tasks, batch power-on prioritizes ensuring users' basic functionalities. Furthermore, when powering on users waiting to be powered on, the system checks whether the user will be shut down again to avoid disordered shutdowns. This ensures timely power-on for users while avoiding blind power-on, improving user experience. This embodiment also addresses the problem of lost power-on tasks due to process interaction or power-on anomalies. By filtering processed payment tasks to identify missed target users, configuring virtual pre-stored information for target users, and performing power-on checks, the system can re-trigger power-on for target users, achieving accurate power-on for all users and improving the robustness of the payment power-on system.

[0149] Figure 7 This is a logic block diagram of a power-on compensation method provided in an embodiment of this application. Figure 7 As shown, when there is a backlog of payments in the payment task table, the system uses virtual pre-stored information and outstanding payment information to determine whether the system needs to be powered on, resulting in a power-on task table consisting of users waiting to be powered on. Power-on compensation is then provided to these users. When there is a backlog in the power-on task table, the power-on mode is determined based on the number of power-on tasks in the table, and power-on compensation is provided based on this mode. When an anomaly occurs during power-on of a network element, resulting in missed users, the system filters out target users and obtains virtual pre-stored information. Power-on determination is then performed again based on this virtual pre-stored information, thus ensuring accurate power-on.

[0150] To achieve the above embodiments, this application also proposes a power-on compensation device.

[0151] Figure 8 This is a schematic diagram of a power-on compensation device provided in an embodiment of this application. Figure 8 As shown, the power-on compensation device 800 includes:

[0152] The monitoring module 801 is used to monitor the payment task table and determine whether the payment task table meets the compensation conditions.

[0153] The acquisition module 802 is used to acquire the payment information and arrears information of each user in the payment task table in response to the payment task table meeting the compensation conditions, and to determine the power-on task table based on the payment information and arrears information. The power-on task table includes one or more users to be powered on.

[0154] The power-on compensation module 803 is used to determine the power-on mode of each user to be powered on based on the number of power-on tasks in the power-on task table, and to perform power-on compensation for the user to be powered on according to the power-on mode.

[0155] Furthermore, in one possible implementation of this application embodiment, the monitoring module 801 includes:

[0156] Retrieve the number of unprocessed payment tasks and error-reported tasks from the payment task table;

[0157] If there is an abnormal payment process in the payment task table, and at least one of the following conditions is met: the number of payment tasks is greater than a first preset number, and the number of error-reporting tasks is greater than a second preset number, the payment tasks in the payment task table are determined to meet the compensation conditions.

[0158] Furthermore, in one possible implementation of this application embodiment, the acquisition module 802 includes:

[0159] Get the user's shutdown type;

[0160] Retrieve virtual prepaid information from payment information and historical and current month's arrears from arrears information;

[0161] Based on the user's suspension type, virtual prepaid information, historical arrears, and current month's arrears, determine whether the user meets the power-on conditions, and designate users who meet the power-on conditions as users awaiting power-on.

[0162] Furthermore, in one possible implementation of this application embodiment, the acquisition module 802 includes:

[0163] Obtain the payment receipt report, and determine the amount already received in the virtual pre-deposit information based on the payment receipt report;

[0164] The real-time virtual pre-deposit amount is obtained by deducting the amount already received from the virtual pre-deposit amount in the virtual pre-deposit information;

[0165] Based on the type of service interruption, real-time virtual prepaid amount, historical arrears, and current month's arrears, determine whether the user meets the conditions for service activation.

[0166] Furthermore, in one possible implementation of this application embodiment, the acquisition module 802 includes:

[0167] Obtain the user's total virtual basic prepaid amount and virtual special prepaid amount offset by the prepaid amount, the user's historical arrears and current month's arrears.

[0168] If the suspension type is suspension due to overdue payment, the user is deemed to meet the conditions for powering on when the user's virtual basic prepaid amount is greater than or equal to the historical overdue amount, or when the user's total prepaid amount is greater than or equal to the historical overdue amount.

[0169] If the service suspension type is over-credit suspension, the user is deemed to meet the service activation conditions when the user's virtual basic prepaid amount is greater than or equal to the total outstanding amount, or when the user's total prepaid amount is greater than or equal to the total outstanding amount.

[0170] If the user's service is suspended for reasons other than unpaid fees or exceeding credit limits, it is determined that the user does not meet the conditions for reactivation.

[0171] Furthermore, in one possible implementation of this application embodiment, the power-on compensation module 803 includes:

[0172] In response to the number of startup tasks exceeding the third preset number, the system retrieves the first startup task within a preset time period from the startup task table and performs batch startup on the first startup task to restore the user's basic functions.

[0173] If the number of startup tasks is less than or equal to the third preset number, the startup tasks in the startup task table will be started sequentially to restore all user functions.

[0174] Furthermore, in one possible implementation of this application embodiment, the power-on compensation module 803 further includes:

[0175] Retrieve the shutdown task table, which includes the users and times of shutdown.

[0176] Identify duplicate users in the shutdown task table and the startup task table, and obtain the task generation time and shutdown time of the duplicate users in the startup task table and the shutdown task table respectively;

[0177] If the task generation time is earlier than the downtime, the system will determine that duplicate users will not be powered on.

[0178] Furthermore, in one possible implementation of this application embodiment, the device 800 further includes:

[0179] The first user who has a balance after payment and whose device is not turned on;

[0180] Based on the boot task list, the first user is filtered to obtain the target users to be booted who are not included in the boot task list;

[0181] Configure the virtual pre-stored information of the target user, and determine whether the target user meets the boot conditions based on the virtual pre-stored information of the target user, and perform boot compensation for the target user who meets the boot conditions.

[0182] Furthermore, in one possible implementation of this application embodiment, the device 800 includes:

[0183] Get all processed historical payment tasks and the second user corresponding to the historical payment tasks within a preset time period;

[0184] Identify the third user among the second users who has a balance after making payment based on payment information from historical payment tasks;

[0185] Filter the users who are offline from the third user group to get the first user.

[0186] It should be noted that the foregoing explanation of the power-on compensation method embodiment also applies to the power-on compensation device of this embodiment, and will not be repeated here.

[0187] In this embodiment, by monitoring the payment task table, when the payment task table meets the compensation conditions, the user's payment information and arrears information are obtained to determine whether the user can offset the arrears, thereby determining whether the user is a user waiting to be powered on. This allows for the acquisition of all power-on task tables, ensuring the rationality and accuracy of the judgment on power-on tasks. Furthermore, the power-on task volume in the power-on task table is obtained, and the power-on mode of the users waiting to be powered on is determined based on the power-on task volume. This allows for different power-on compensation for users waiting to be powered on, avoiding excessively long waiting times and untimely power-on due to task backlog, and improving the user experience.

[0188] To implement the above embodiments, this application also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0189] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0190] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0191] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0192] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0193] This application is intended to provide an implementation scheme for users to selectively prevent the use or access to their personal information data. Specifically, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information is de-identified to protect user privacy.

[0194] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0195] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0196] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0197] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0198] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0199] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0200] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0201] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A power-on compensation method, characterized in that, include: Monitor the payment task list and determine whether the payment task list meets the compensation conditions; In response to the payment task table meeting the compensation conditions, the payment information and arrears information of each user in the payment task table are obtained; Obtain the user's shutdown type; Obtain the virtual prepaid information from the payment information and the historical and current month's arrears from the arrears information; Obtain the payment receipt report, and determine the amount already received in the virtual pre-deposit information based on the payment receipt report; The real-time virtual pre-deposit amount is obtained by subtracting the amount already received from the virtual pre-deposit amount in the virtual pre-deposit information; Based on the shutdown type, the real-time virtual prepaid amount, the historical arrears, and the current month's arrears, it is determined whether the user meets the power-on conditions, and users who meet the power-on conditions are designated as users awaiting power-on; wherein, all the users awaiting power-on constitute a power-on task table; Based on the number of startup tasks in the startup task table, the startup mode of each user to be powered on is determined, and startup compensation is performed on the user to be powered on according to the startup mode. The real-time virtual prepaid amount includes a virtual basic prepaid amount and a virtual special prepaid amount. The suspension types include suspension due to overdue payments and suspension due to exceeding credit limits. The process of determining whether the user meets the activation conditions based on the suspension type, the real-time virtual prepaid amount, the historical overdue payments, and the current month's overdue payments includes: Obtain the total amount of virtual basic prepaid amount and virtual special prepaid amount that can be offset by the user, and the total amount of the user's historical arrears and current month's arrears; If the suspension type is suspension due to overdue payment, the user is determined to meet the power-on conditions when the user's virtual basic prepaid amount is greater than or equal to the historical overdue payment, or when the user's total prepaid amount is greater than or equal to the historical overdue payment. If the suspension type is a credit limit suspension, the user is determined to meet the power-on conditions when the user's virtual basic prepaid amount is greater than or equal to the total amount of outstanding fees, or when the user's prepaid amount is greater than or equal to the total amount of outstanding fees. If the user's service is suspended for reasons other than unpaid fees or exceeding credit limits, then the user does not meet the conditions for reactivation.

2. The method according to claim 1, characterized in that, Determining whether the payment task sheet meets the compensation conditions includes: Obtain the number of unprocessed payment tasks and the number of error-reported tasks in the payment task table; If the payment task table is found to have an abnormal payment process, and at least one of the following conditions is met: the payment process is abnormal, the number of payment tasks is greater than a first preset number, and the number of error-reporting tasks is greater than a second preset number, the payment task table is determined to meet the compensation conditions.

3. The method according to claim 1, characterized in that, The boot modes include sequential boot and batch boot. Determining the boot mode for each user to be booted based on the number of boot tasks in the boot task table includes: In response to the fact that the number of startup tasks exceeds a third preset number, the system obtains the first startup task within a preset time period from the startup task table, and performs batch startup on the first startup task to restore the user's basic functions. In response to the number of startup tasks being less than or equal to a third preset number, the startup tasks in the startup task table are sequentially powered on to restore all functions of the user.

4. The method according to claim 3, characterized in that, Before performing power-on compensation on the user waiting to power on according to the power-on mode, the following steps are also included: Obtain the shutdown task table, which includes the users and shutdown times; Identify duplicate users in the shutdown task table and the startup task table, and obtain the task generation time and shutdown time of the duplicate users in the startup task table and the shutdown task table, respectively; In response to the task being generated earlier than the downtime, it is determined that the duplicate user should not be powered on.

5. The method according to any one of claims 1-4, characterized in that, After performing power-on compensation on the user waiting to be powered on according to the power-on mode, the method further includes: The first user who has a balance after payment and whose device is not turned on; The first user is filtered according to the boot task table to obtain the target users to be booted who are not included in the boot task table; Configure the virtual pre-stored information of the target user, and determine whether the target user meets the boot conditions based on the virtual pre-stored information of the target user, and perform boot compensation for the target user who meets the boot conditions.

6. The method according to claim 5, characterized in that, The first user who has a balance after payment and whose device is not turned on includes: Obtain all processed historical payment tasks within a preset time period and the second user corresponding to each historical payment task; Based on the payment information in the historical payment tasks, identify the third user among the second users who has a balance after payment; The first user is obtained by filtering out the users who are out of service from the third user group.

7. A power-on compensation device, characterized in that, include: The monitoring module is used to monitor the payment task table and determine whether the payment task table meets the compensation conditions. The acquisition module is used to acquire the payment information and arrears information of each user in the payment task table in response to the payment task table meeting the compensation conditions; Obtain the user's shutdown type; Obtain the virtual prepaid information from the payment information and the historical and current month's arrears from the arrears information; Obtain the payment receipt report, and determine the amount already received in the virtual pre-deposit information based on the payment receipt report; The real-time virtual pre-deposit amount is obtained by subtracting the amount already received from the virtual pre-deposit amount in the virtual pre-deposit information; Based on the shutdown type, the real-time virtual prepaid amount, the historical arrears, and the current month's arrears, it is determined whether the user meets the power-on conditions, and users who meet the power-on conditions are designated as users awaiting power-on; wherein, all the users awaiting power-on constitute a power-on task table; The power-on compensation module is used to determine the power-on mode of each user to be powered on based on the number of power-on tasks in the power-on task table, and to provide power-on compensation to the user to be powered on according to the power-on mode. The real-time virtual prepaid amount includes a virtual basic prepaid amount and a virtual special prepaid amount; the suspension types include suspension due to arrears and suspension due to exceeding credit limits; the acquisition module is also used for: Obtain the total amount of virtual basic prepaid amount and virtual special prepaid amount that can be offset by the user, and the total amount of the user's historical arrears and current month's arrears; If the suspension type is suspension due to overdue payment, the user is determined to meet the power-on conditions when the user's virtual basic prepaid amount is greater than or equal to the historical overdue payment, or when the user's total prepaid amount is greater than or equal to the historical overdue payment. If the suspension type is a credit limit suspension, the user is determined to meet the power-on conditions when the user's virtual basic prepaid amount is greater than or equal to the total amount of outstanding fees, or when the user's prepaid amount is greater than or equal to the total amount of outstanding fees. If the user's service is suspended for reasons other than unpaid fees or exceeding credit limits, then the user does not meet the conditions for reactivation.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-6.

Images