A parking lot prepayment income allocation method and device, electronic equipment and medium

By developing dynamic allocation strategies for different prepaid types, the problem of time mismatch between transaction time and renewal period is solved, enabling accurate analysis of parking lot revenue and ensuring precise calculation of costs and profits.

CN122200828APending Publication Date: 2026-06-12SHENZHEN JIESHUN SCI & TECH IND
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
SHENZHEN JIESHUN SCI & TECH IND
Filing Date
2026-02-06
Publication Date
2026-06-12

AI Technical Summary

Technical Problem

When faced with the time mismatch between transaction time and renewal period, existing technologies cannot accurately analyze the actual revenue of parking lots using the cash basis accounting method, making it difficult to accurately analyze costs and profits.

Method used

Different allocation strategies have been dynamically developed for different types of prepaid fees, including allocation by period, by payment time, by transaction, and by principal account. The allocation amount is calculated by determining the target fee type and the corresponding allocation strategy.

Benefits of technology

When faced with the time mismatch between transaction time and renewal period, it can accurately calculate the allocated amount, understand the actual revenue, and thus accurately analyze the parking lot's costs and profits.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122200828A_ABST
    Figure CN122200828A_ABST
Patent Text Reader

Abstract

The application provides a parking lot prepayment income allocation method and device, electronic equipment and medium. The method comprises the following steps: for a parking lot, determining a target charging type configured by the parking lot, determining an allocation strategy of the target charging type, allocating charging data corresponding to the allocation strategy based on the allocation strategy, and obtaining a corresponding allocation amount. The application dynamically formulates different allocation strategies for different prepayment charging types, accurately calculates the allocation amount under different allocation strategies, and can understand the actual income of the time period when facing the time mismatch problem between the transaction time and the extension period, so as to accurately analyze the cost and profit of the parking lot in combination with the actual income.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of parking operation technology, and more specifically, to a method, device, electronic device, and medium for allocating prepaid revenue from parking lots. Background Technology

[0002] Parking lot fees are a core component of modern urban management and commercial operations. They can generate profits for operators, form the cornerstone of the business model, limit disorderly and long-term parking of vehicles, effectively manage parking lot order, and improve safety.

[0003] Currently, parking lot revenue is mainly recorded on a cash basis, which allows for accurate accounting of fees collected.

[0004] However, when faced with the time mismatch between transaction time and renewal period, the cash basis accounting method has difficulty understanding the actual revenue during that period, which makes it difficult to accurately analyze costs and profits. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method, device, electronic device and medium for allocating prepaid revenue in parking lots. Different allocation strategies are dynamically formulated for different types of prepaid fees. Under different allocation strategies, the allocation amount is accurately calculated. When faced with the time mismatch between transaction time and renewal period, the actual revenue for that period can be understood. Thus, the cost and profit of the parking lot can be accurately analyzed in combination with the actual revenue.

[0006] In a first aspect, embodiments of this application provide a method for allocating prepaid parking lot revenue, the method comprising: For parking lots, determine the target charging type configured for the parking lot; wherein, the target charging type is a prepaid charging type; Determine the allocation strategy for the target fee type; wherein the allocation strategy includes at least periodic allocation, payment time allocation, per transaction allocation, and principal account allocation; The fee data corresponding to the allocation strategy is allocated based on the allocation strategy to obtain the corresponding allocation amount.

[0007] In one possible implementation, the allocation strategy is periodic allocation, which includes at least monthly allocation and daily allocation; the allocation of the chargeable data corresponding to the allocation strategy includes: Determine the periodically allocated fee data and allocate the fee data to each day; When the target charging type is a monthly card, the corresponding consumption order is determined, and the corresponding refund data is determined based on the consumption order. The charging data allocated to each day is netted based on the refund data. The refund data includes at least the refund time and the refund amount. The corresponding monthly card cancellation time is determined based on the consumption order, and the charging data allocated to each day is netted based on the monthly card cancellation time.

[0008] In one possible implementation, determining the periodically allocated billing data and allocating the billing data to each day includes: If the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; The daily charges are netted based on the refund order data.

[0009] In one possible implementation, the allocation strategy is monthly allocation, and the allocation of the charging data to each day includes: Determine the renewal period corresponding to the charging data and the total number of days in the renewal period, and calculate the daily charging responsibility based on the charging data and the total number of days; Based on the daily charging responsibilities, the monthly charging data for the renewal period is obtained, and the monthly charging data is allocated to each day.

[0010] In one possible implementation, the allocation strategy is per-use allocation; the allocation of the charging data corresponding to the allocation strategy includes: Based on the aforementioned charging data, a target order is determined, and the per-order consumption record for the target order on that day is also determined. The corresponding allocated amount is calculated based on the per-purchase consumption flow of the target order on that day, and the amount is netted out to the same day when the allocated amount is used up.

[0011] In one possible implementation, the allocation strategy is to allocate fees based on the principal account; the allocation of fee data corresponding to the allocation strategy includes: The target principal account is determined based on the fee data, and the corresponding target amount is determined based on the target principal account; wherein, the target principal account is an account with a balance on the previous day or an account initialized on the current day; The daily spending amount for the target principal account is calculated based on the target amount in the target principal account.

[0012] In one possible implementation, the allocation strategy is to allocate fees based on payment time; the allocation of the fee data corresponding to the allocation strategy includes: Determine the charging cycle and payment time for the aforementioned charging data; The fee data is distributed across each day of the fee cycle according to the payment time.

[0013] Secondly, embodiments of this application also provide a parking lot prepaid revenue sharing device, the device comprising: The determination module is used to determine the target charging type configured for the parking lot; wherein the target charging type is a prepaid charging type; A matching module is used to determine the allocation strategy for the target charge type; wherein the allocation strategy includes at least periodic allocation, payment time allocation, per transaction allocation, and principal account allocation. The allocation module is used to allocate the charging data corresponding to the allocation strategy based on the allocation strategy to obtain the corresponding allocation amount.

[0014] In one possible implementation, the allocation strategy is periodic allocation, which includes at least monthly allocation and daily allocation; the allocation module is specifically used for: Determine the periodically allocated fee data and allocate the fee data to each day; When the target charging type is a monthly card, the corresponding consumption order is determined, and the corresponding refund data is determined based on the consumption order. The charging data allocated to each day is netted based on the refund data. The refund data includes at least the refund time and the refund amount. The corresponding monthly card cancellation time is determined based on the consumption order, and the charging data allocated to each day is netted based on the monthly card cancellation time.

[0015] In one possible implementation, the amortization module is specifically used for: If the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; The daily charges are netted based on the refund order data.

[0016] In one possible implementation, the allocation strategy is monthly allocation, and the allocation module is specifically used for: Determine the renewal period corresponding to the charging data and the total number of days in the renewal period, and calculate the daily charging responsibility based on the charging data and the total number of days; Based on the daily charging responsibilities, the monthly charging data for the renewal period is obtained, and the monthly charging data is allocated to each day.

[0017] In one possible implementation, the allocation strategy is per-event allocation; the allocation module is specifically used for: Based on the aforementioned charging data, a target order is determined, and the per-order consumption record for the target order on that day is also determined. The corresponding allocated amount is calculated based on the per-purchase consumption flow of the target order on that day, and the amount is netted out to the same day when the allocated amount is used up.

[0018] In one possible implementation, the allocation strategy is to allocate based on the principal account; the allocation module is specifically used for: The target principal account is determined based on the fee data, and the corresponding target amount is determined based on the target principal account; wherein, the target principal account is an account with a balance on the previous day or an account initialized on the current day; The daily spending amount for the target principal account is calculated based on the target amount in the target principal account.

[0019] In one possible implementation, the allocation strategy is to allocate payments based on payment time; the allocation module is specifically used for: Determine the charging cycle and payment time for the aforementioned charging data; The fee data is distributed across each day of the fee cycle according to the payment time.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the parking lot prepaid revenue sharing method as described in any of the first aspects.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the parking lot prepaid revenue sharing method described in any of the first aspects.

[0022] This application provides a method, apparatus, electronic device, and medium for allocating prepaid revenue in parking lots. For a parking lot, it determines the target charging type configured for the parking lot, determines the allocating strategy for the target charging type, and allocates the corresponding charging data based on the allocating strategy to obtain the corresponding allocated amount. This application dynamically formulates different allocating strategies for different prepaid types, accurately calculating the allocated amount under different allocating strategies. When facing time mismatch issues between transaction time and renewal period, it can understand the actual revenue for that period, thereby enabling accurate analysis of parking lot costs and profits based on actual revenue.

[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a flowchart of a parking lot prepaid revenue sharing method provided according to an embodiment of this application; Figure 2 This is a diagram illustrating the process of monthly apportionment of prepaid parking lot revenue. Figure 3 This is a diagram illustrating the daily allocation process of prepaid parking lot revenue. Figure 4 This is a schematic diagram illustrating the process of allocating prepaid revenue from parking lots according to payment time. Figure 5 This is a schematic diagram illustrating the process of allocating prepaid revenue from parking lots on a per-trip basis. Figure 6 This is a diagram illustrating the process of allocating prepaid revenue from parking lots to the principal account. Figure 7 This is a schematic diagram of the structure of the parking lot prepaid revenue sharing device provided in the embodiments of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0027] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0029] Considering that parking lot fees are a core component of modern urban management and commercial operations, they can generate profits for operators, form the cornerstone of the business model, limit disorderly and long-term parking of vehicles, effectively manage parking lot order, and improve safety.

[0030] Currently, parking lot revenue is primarily recorded using the cash basis of accounting, which allows for accurate tracking of fees collected. However, when faced with time mismatches between transaction times and renewal periods, the cash basis method struggles to determine the actual revenue for a given period, making accurate cost and profit analysis difficult.

[0031] To address this issue, this application provides a method, apparatus, electronic device, and medium for allocating prepaid revenue for parking lots. Different allocation strategies are dynamically formulated for different types of prepaid fees, and the allocation amount is accurately calculated under different allocation strategies. When faced with time mismatch issues between transaction time and renewal period, the actual revenue for that period can be understood, thereby enabling accurate analysis of parking lot costs and profits based on actual revenue.

[0032] Figure 1 This is a flowchart of a parking lot prepaid revenue sharing method provided according to an embodiment of this application. For example... Figure 1 As shown in the embodiments of this application, the parking lot prepaid revenue sharing method may specifically include: S101. For parking lots, determine the target charging type for the parking lot configuration.

[0033] S102. Determine the apportionment strategy for the target charge type.

[0034] S103. Based on the allocation strategy, the charging data corresponding to the allocation strategy is allocated to obtain the corresponding allocation amount.

[0035] The above-mentioned parking lot prepaid revenue allocation method dynamically formulates different allocation strategies for different prepaid types. Under different allocation strategies, the allocation amount is accurately calculated. When facing the time mismatch problem between transaction time and renewal period, the actual revenue of that period can be understood. Thus, the parking lot's cost and profit can be accurately analyzed in combination with the actual revenue.

[0036] The exemplary steps described above in the embodiments of this application are illustrated below with specific examples: S101, for parking lots, determine the target charging type for the parking lot configuration.

[0037] In this embodiment, the target charging type is a prepaid charging type, such as a monthly pass or merchant top-up. The target charging type for parking lot configuration is determined for subsequent processing. For example, ... Figures 2-6 As shown.

[0038] S102, Determine the allocation strategy for the target charge type.

[0039] In this embodiment of the application, the allocation strategy includes at least periodic allocation, allocation according to payment time, allocation by transaction, and allocation by principal account. Periodic allocation includes at least monthly allocation and daily allocation. The allocation strategy corresponding to the target fee type in step S101 is determined for subsequent processing. For example, ... Figures 2-6 As shown, different charging strategies are matched and determined.

[0040] S103, Based on the allocation strategy, the charging data corresponding to the allocation strategy is allocated to obtain the corresponding allocation amount.

[0041] In this embodiment of the application, the charging data for the allocation strategy is determined, and the charging data corresponding to the allocation strategy is allocated and calculated to obtain the allocated amount. For example, as Figures 2-6 As shown.

[0042] In some implementations, when the allocation strategy is periodic allocation, the periodic allocation of fee data is determined, and the fee data is allocated to each day. When the target fee type is a monthly card, the corresponding consumption order is determined, and the corresponding refund data is determined based on the consumption order. The fee data allocated to each day is then netted based on the refund data. The corresponding monthly card cancellation time is determined based on the consumption order, and the fee data allocated to each day is then netted based on the monthly card cancellation time. The refund data includes at least the refund time and the refund amount.

[0043] Therefore, when allocating revenue by period, by performing periodic allocation and netting calculations based on whether the fee type is a monthly pass, the allocated amount can be calculated more accurately by period, allowing for a better understanding of the actual revenue for that period.

[0044] Optionally, when determining the periodically allocated fee data and allocating it to each day, if the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; the fee data allocated to each day is then netted based on the refund order data. The refund order data includes the refund time and refund amount.

[0045] Therefore, when allocating fees on a periodic basis, for non-monthly card types, the fee data allocated to each day is netted based on the refund order data associated with the order number of the consumption order, so as to calculate the allocated amount more accurately and understand the actual income for that period.

[0046] It should be noted that when the allocation strategy is monthly allocation, when allocating the billing data to each day, the renewal period corresponding to the billing data and the total number of days in the renewal period are determined. Based on the billing data and the total number of days, the daily billing responsibility is calculated. Based on the daily billing responsibility, the monthly billing data in the renewal period is obtained, and the monthly billing data is allocated to each day. For example, if a monthly card of 600 yuan is paid on January 1, 2025, and the renewal period is from January 25, 2025 to March 24, 2025, assuming that each month has only 30 days, then the total number of days in the renewal period from January 25, 2025 to March 24, 2025 is 60 days. Therefore, the daily billing responsibility is 600 / 60 = 10 days. Thus, the billing data for January (6 days) is 60 days, the billing data for February (30 days) is 300 yuan, and the billing data for March (24 days) is 240 yuan.

[0047] Therefore, when allocating fees monthly, the daily fee responsibilities are calculated based on the fee data and the total number of days. The monthly fee data for the renewal period is then obtained based on the daily fee responsibilities. By allocating the monthly fee data to each day, the monthly fee amount can be accurately calculated, and the actual income for that period can be further understood.

[0048] It should also be noted that when the allocation strategy is daily allocation, the billing period for the billing data is determined, and the billing data is allocated to each day within that period. For example, ... Figure 3As shown, when the charging strategy is monthly amortization, the monthly amortization data is found based on the different target charging types of the parking lot's projects. The charging data is then allocated to each month according to the responsibilities and obligations, and further allocated to each day according to the actual number of days in each month. For example, if a monthly card of 600 yuan is paid on January 1, 2025, and the renewal period is from January 25, 2025 to March 24, 2025, the responsibilities and obligations calculation results in: 60 yuan for January, with 7 days in January, so the daily amortization is 60 / 7 yuan. If the division is not exact, it is rounded up, and the difference is included on the last day; 300 yuan for February, with 28 days in total, so the daily amortization is 300 / 28 yuan. If the division is not exact, it is rounded up, and the difference is included on the last day; 240 yuan for March, with 24 days in total, so the daily amortization is 10 yuan. When the charging strategy is to allocate the cost per day, the amount of the charge data is directly allocated to each day according to the actual number of days. For example, a monthly card of 600 yuan is directly divided by the total number of days in the renewal period from January 25, 2025 to March 24, 2025 to get the daily allocated amount.

[0049] To continue, for example, such as Figure 3 As shown, when determining whether the fee type is a monthly card, the refund data is found based on the monthly card order (i.e., the consumption order with the fee type of monthly card). The refund time and refund amount are netted. For example, if a refund of 50 yuan is issued on March 1st, the revenue from March 2nd to March 24th will be zero. On March 1st, the netting amount will be 240 - 50 = 190 yuan. Next, the monthly card cancellation time is found based on the monthly card service. The netting amount is then calculated within the monthly card cancellation time. For example, in the case of the above monthly allocated fee data, if the monthly card is cancelled on March 1st, then all amounts after March 1st will be charged as 240 yuan, and no further amounts will be calculated and added to the account.

[0050] Optionally, if the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; the fee data allocated to each day is netted based on the refund order data. The refund order data includes the refund time and refund amount.

[0051] For example, such as Figures 2-3 As shown, when the fee type is not a monthly card, the refund order data associated with the consumption order number is used to net out the refund time and refund amount.

[0052] In some implementations, when the allocation strategy is per-transaction allocation, the target order is determined based on the charging data, and the per-transaction consumption flow for the target order on that day is determined; the corresponding allocation amount is calculated based on the per-transaction consumption flow for the target order on that day, and the amount is netted out to the current day when the allocation amount is used up. The target order is either an order with a balance from the previous day or an order paid on the current day.

[0053] For example, such as Figure 4As shown, when the allocation strategy is per-use allocation, the per-use allocation data is found according to the different charging types of the project. Orders with balances from the previous day or orders paid on the current day are identified. Finally, the allocation amount is calculated based on the per-use consumption flow of the order on the current day, and the difference is rounded up to the current day when the allocation amount is used up.

[0054] Therefore, when allocating on a per-transaction basis, the allocated amount is calculated based on the per-transaction consumption flow of the target order on that day, and the difference is rolled over to the same day when the allocated amount is used up. This allows for accurate daily allocation of the allocated amount and understanding of the actual revenue for that period.

[0055] In some implementations, when the allocation strategy is based on the principal account, the target principal account is determined based on the fee data when allocating the fees, and a corresponding target amount is determined based on the target principal account. The daily consumption amount for the target principal account is calculated based on the target amount of the target principal account. The target principal account is either an account with a balance from the previous day or an account initialized on the current day. The target amount for an account with a balance from the previous day includes the previous period's balance, the recharge amount, and the daily consumption amount. The target amount for an account initialized on the current day includes the initial amount, the recharge amount, and the daily consumption amount.

[0056] For example, such as Figure 5 As shown, when the allocation strategy is allocation by principal account, the fee data allocated by principal account is found according to different fee types of the project. The accounts with a balance on the previous day or the accounts initialized on the current day are found. The allocation and balance are calculated based on the previous period balance, recharge amount, and current consumption amount in the accounts with a balance on the previous day (or the allocation and balance are calculated based on the initial amount, recharge amount, and current consumption amount in the accounts initialized on the current day). The daily consumption amount of the account is found, and the allocation amount is finally determined.

[0057] Therefore, when allocating expenses based on the principal, the target amount for the day's consumption can be calculated based on the account with a balance from the previous day or the account initialized on the current day. This allows for accurate calculation of the allocated amount based on the principal, enabling an understanding of the actual income for that period.

[0058] In some implementations, when the allocation strategy is to allocate based on payment time, the billing period and payment time of the billing data are determined when allocating the billing data; and the billing data is allocated to each day of the billing period according to the payment time.

[0059] For example, such as Figure 6 As shown, when the allocation strategy is based on payment time, the fee data allocated by payment time is found according to the different fee types of the project, and the amount of the fee data is allocated to each day according to the payment time.

[0060] Therefore, when allocating fees by payment time, the fee data is allocated to each day of the fee cycle according to the payment time. This allows for accurate calculation of the allocated amount based on the payment time, enabling an understanding of the actual revenue for that period.

[0061] The parking lot prepaid revenue allocation method provided in this application determines the target charging type for the parking lot, establishes an allocation strategy for the target charging type, and allocates the corresponding charging data based on the allocation strategy to obtain the corresponding allocated amount. This parking lot prepaid revenue allocation method dynamically formulates different allocation strategies for different prepaid types, accurately calculates the allocated amount under different allocation strategies, and can understand the actual revenue for a given period when dealing with time mismatches between transaction time and renewal period. This allows for accurate analysis of parking lot costs and profits by combining actual revenue data.

[0062] Figure 7 This is a schematic diagram of the structure of the parking lot prepaid revenue sharing device provided in the embodiments of this application; as shown below. Figure 7 As shown, the parking lot prepaid revenue sharing device 700 of this application embodiment may specifically include: The determination module 701 is used to determine the target charging type configured for the parking lot; wherein the target charging type is a prepaid charging type.

[0063] Matching module 702 is used to determine the allocation strategy for the target charge type; wherein the allocation strategy includes at least periodic allocation, payment time allocation, per transaction allocation, and principal account allocation.

[0064] The apportionment module 703 is used to apportion the charging data corresponding to the apportionment strategy based on the apportionment strategy to obtain the corresponding apportionment amount.

[0065] In one possible implementation, the allocation strategy is periodic allocation, which includes at least monthly allocation and daily allocation; the allocation module is specifically used for: Determine the periodically allocated fee data and allocate the fee data to each day; When the target fee type is a monthly card, the corresponding consumption order is determined, and the corresponding refund data is determined based on the consumption order. The fee data allocated to each day is then netted based on the refund data. The refund data includes at least the refund time and the refund amount. The corresponding monthly card cancellation time is determined based on the consumption order, and the fee data allocated to each day is then netted based on the monthly card cancellation time.

[0066] In one possible implementation, the amortization module is specifically used for: If the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; the fee data allocated to each day is netted based on the refund order data.

[0067] In one possible implementation, the allocation strategy is monthly allocation, and the allocation module is specifically used for: Determine the renewal period and the total number of days in the renewal period corresponding to the billing data, and calculate the daily billing responsibility based on the billing data and the total number of days; Based on the daily charging responsibilities, the monthly charging data for the renewal cycle is obtained, and the monthly charging data is allocated to each day.

[0068] In one possible implementation, the allocation strategy is per-event allocation; the allocation module is specifically used for: The target order is determined based on the charging data, and the per-use consumption flow of the target order on the same day is determined; the corresponding allocated amount is calculated based on the per-use consumption flow of the target order on the same day, and the amount is netted to the same day when the allocated amount is used up.

[0069] In one possible implementation, the allocation strategy is to allocate based on the principal account; the allocation module is specifically used for: The target principal account is determined based on the fee data, and the corresponding target amount is determined based on the target principal account; wherein, the target principal account is an account with a balance on the previous day or an account initialized on the current day; The daily spending amount for the target principal account is calculated based on the target amount in the target principal account.

[0070] In one possible implementation, the allocation strategy is to allocate payments based on payment time; the allocation module is specifically used for: Determine the billing cycle and payment time for the data. The billing data is distributed across each day of the billing cycle based on the payment time.

[0071] The parking lot prepaid revenue sharing device provided in this application determines the target charging type configured for the parking lot, determines the sharing strategy for the target charging type, and shares the charging data corresponding to the sharing strategy to obtain the corresponding sharing amount. This parking lot prepaid revenue sharing device dynamically formulates different sharing strategies for different prepaid types, accurately calculates the sharing amount under different sharing strategies, and can understand the actual revenue for a given period when facing time mismatch issues between transaction time and renewal period. Therefore, it can accurately analyze the parking lot's costs and profits by combining actual revenue.

[0072] like Figure 8As shown in the embodiment of this application, an electronic device 800 includes a processor 801, a memory 802, and a bus. The memory 802 stores machine-readable instructions that can be executed by the processor 801. When the electronic device is running, the processor 801 communicates with the memory 802 via the bus. The processor 801 executes the machine-readable instructions to perform the steps of the parking lot prepaid revenue sharing method described above.

[0073] Specifically, the memory 802 and processor 801 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 801 runs the computer program stored in the memory 802, it can execute the above-mentioned parking lot prepaid revenue sharing method.

[0074] Corresponding to the above-described parking lot prepaid revenue sharing method, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the above-described parking lot prepaid revenue sharing method.

[0075] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0076] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0078] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the deployment methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0079] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for allocating prepaid revenue from parking lots, characterized in that, The method includes: For parking lots, determine the target charging type configured for the parking lot; wherein, the target charging type is a prepaid charging type; Determine the allocation strategy for the target fee type; wherein the allocation strategy includes at least periodic allocation, payment time allocation, per transaction allocation, and principal account allocation; The fee data corresponding to the allocation strategy is allocated based on the allocation strategy to obtain the corresponding allocation amount.

2. The method according to claim 1, characterized in that, The allocation strategy is periodic allocation, which includes at least monthly allocation and daily allocation; the allocation of the charging data corresponding to the allocation strategy includes: Determine the periodically allocated fee data and allocate the fee data to each day; When the target charging type is a monthly card, the corresponding consumption order is determined, and the corresponding refund data is determined based on the consumption order. The charging data allocated to each day is netted based on the refund data. The refund data includes at least the refund time and the refund amount. The corresponding monthly card cancellation time is determined based on the consumption order, and the charging data allocated to each day is netted based on the monthly card cancellation time.

3. The method according to claim 2, characterized in that, The process of determining the periodically allocated fee data and allocating the fee data to each day includes: If the target fee type is not a monthly card, the associated refund order data is determined based on the order number of the consumption order; The daily charges are netted based on the refund order data.

4. The method according to claim 2, characterized in that, The allocation strategy is monthly allocation, and the allocation of the charging data to each day includes: Determine the renewal period corresponding to the charging data and the total number of days in the renewal period, and calculate the daily charging responsibility based on the charging data and the total number of days; Based on the daily charging responsibilities, the monthly charging data for the renewal period is obtained, and the monthly charging data is allocated to each day.

5. The method according to claim 1, characterized in that, The allocation strategy is per-use allocation; the allocation of the charging data corresponding to the allocation strategy includes: Based on the charging data, a target order is determined, and the per-order consumption flow of the target order for that day is determined; The corresponding allocated amount is calculated based on the per-purchase consumption flow of the target order on that day, and the amount is netted out to the same day when the allocated amount is used up.

6. The method according to claim 1, characterized in that, The allocation strategy is to allocate fees based on the principal account; the allocation of fees corresponding to the allocation strategy includes: The target principal account is determined based on the fee data, and the corresponding target amount is determined based on the target principal account; wherein, the target principal account is an account with a balance on the previous day or an account initialized on the current day; The daily spending amount for the target principal account is calculated based on the target amount in the target principal account.

7. The method according to claim 1, characterized in that, The allocation strategy is based on payment time; the allocation of the fee data corresponding to the allocation strategy includes: Determine the charging cycle and payment time for the aforementioned charging data; The fee data is distributed across each day of the fee cycle according to the payment time.

8. A parking lot prepaid revenue sharing device, characterized in that, The device includes: The determination module is used to determine the target charging type configured for the parking lot; wherein the target charging type is a prepaid charging type; A matching module is used to determine the allocation strategy for the target charge type; wherein the allocation strategy includes at least periodic allocation, payment time allocation, per transaction allocation, and principal account allocation. The allocation module is used to allocate the charging data corresponding to the allocation strategy based on the allocation strategy to obtain the corresponding allocation amount.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the parking lot prepaid revenue sharing method as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the parking lot prepaid revenue sharing method as described in any one of claims 1 to 7.