CN111833169A

CN111833169A - Ledger management method and apparatus

Info

Publication number: CN111833169A
Application number: CN202010622519.9A
Authority: CN
Inventors: 申锦涛
Original assignee: China Construction Bank Corp; CCB Finetech Co Ltd
Current assignee: China Construction Bank Corp
Priority date: 2020-07-01
Filing date: 2020-07-01
Publication date: 2020-10-27

Abstract

The invention discloses a method and a device for managing accounts in a secondary clearing way, and relates to the field of secondary clearing. One embodiment of the method comprises: receiving a separate accounting request for a signed market in a platform, and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market; determining the transaction total amount in the order record so as to reconcile the transaction total amount from the contract account of the bank collecting component into the contract account of the platform; and processing the transaction total amount by utilizing a market grade accounting strategy corresponding to the market to obtain the accounting detail. According to the implementation mode, the branch accounting task is divided into a plurality of automatic tasks, each task can process an independent event, so that the complicated and changeable branch accounting service scene can be flexibly coped with, and if new demands exist, the changes of the branch accounting service scene can be better coped with.

Description

Ledger management method and apparatus

Technical Field

The invention relates to the field of secondary clearing, in particular to a method and a device for managing a split account.

Background

And secondary clearing, namely accessing the professional market to a certificate-holding mechanism in a platform or large merchant mode, keeping the merchant settlement funds, and automatically carrying out the merchant fund clearing action. For the professional markets of various industries which do not have payment service license plates and need unified cash collection, under the requirement of the policy of the people's bank, the accounting action of the funds of the industries needs to be supervised by a third party organization (such as a bank).

When professional markets of different industries expand businesses, application scenarios of the professional markets have many differences, and the differences cause the ledger management to become extremely complex, which is generally embodied in two aspects of a receipt form and a ledger strategy. For example, the branch policies of chain convenience stores, restaurant stores and the like are relatively fixed, and only enterprise groups and shops per se can clearly receive single flow water; for large-size type outsourcing markets, the accounting strategies need to be distinguished according to the types of commodities, and the order receiving running water is concentrated according to floors or selling areas; for the online merchant platform, the billing strategy cannot be fixed, needs to be refined to a transaction level, and a single merchant receives the order in a unified way; differences such as coupons, credits, notice of arrival, confirmation of transit, automatic deductions, etc. also exist for other industries.

In the process of implementing the invention, the inventor finds that the prior art has at least the following problems:

the existing billing strategy is only set for a single market, the payment amount of a user after payment of a merchant is uniformly collected and managed by the market, the dimensionality is single, the rule is simple, the method is not universal and is lower in flexibility in the face of complex and changeable professional market application scenes of various industries.

Therefore, in order to better meet business requirements and ensure the rapid development and implementation of business, a set of multi-scene ledger management method needs to be set to provide compliant, safe, automatic and convenient financial services.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for ledger management, which can at least solve the problem that the existing ledger policy does not have universality.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a ledger management method including:

receiving a separate accounting request for a signed market in a platform, and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market;

determining the transaction total amount in the order record so as to reconcile the transaction total amount from the contract account of the bank collecting component into the contract account of the platform;

and processing the transaction total amount by utilizing a market grade accounting strategy corresponding to the market to obtain the accounting detail.

Optionally, the order record is in a leveling state;

prior to said determining the transaction total in said order record, further comprising:

according to the serial number of the market, obtaining the statement of the market in the previous time period from a bank collection component; wherein the statement of account is used for recording the payment transaction information which is paid out;

and comparing whether the transaction amounts of the same serial numbers in the statement of account and the order record are the same, if so, recording the comparison result as a flat state, otherwise, recording the comparison result as a non-flat state.

Optionally, before the processing the transaction total amount by using the market level accounting policy corresponding to the market to obtain the accounting details, the method further includes:

and responding to the type selection operation of the market, extracting and displaying a market level accounting strategy list corresponding to the market type, and taking the selected market level accounting strategy as the market level accounting strategy of the market.

Optionally, the market types include at least: the online payment e-commerce platform, the offline payment large and medium-sized novel market, the offline payment novel chain brand, the two-dimensional code order-receiving small-sized market, the offline payment large and medium-sized traditional market, the offline payment traditional chain brand, the offline payment small-sized market, the account amount-dividing variable tourism platform and the employment matching platform supporting a three-level structure.

Optionally, the processing the transaction total amount by using a market level accounting policy corresponding to the market to obtain an accounting detail includes: analyzing a flow field in an order record to obtain additional item information, preferential information and merchant information, and determining a merchant level accounting strategy corresponding to a merchant number in the merchant information;

and performing account division management on the transaction amount in the order record by utilizing the market level account division strategy and the merchant level account division strategy and combining the additional item information and the preferential information to obtain account division details of the merchant.

Optionally, before the determining the merchant level accounting policy corresponding to the merchant number in the merchant information, the method further includes: and responding to the type selection operation of the merchant, extracting and displaying a merchant level accounting strategy list corresponding to the merchant type, and taking the selected merchant level accounting strategy as the merchant level accounting strategy of the merchant.

Optionally, the performing, by using the market level accounting policy and the merchant level accounting policy, and combining the additional item information and the benefit information, accounting management on the transaction amount in the order record to obtain accounting details for the merchant includes:

if the preferential information is associated with the merchant, taking the transaction amount as a separate account amount for the merchant; or

And if the preferential information is associated with the market, taking the sum of the transaction amount and the preferential amount in the preferential information as the branch account amount of the merchant.

Optionally, the method further includes: and if the return record corresponding to the merchant exists, obtaining the return amount in the return record, and taking the difference value between the branch account amount and the return amount as the branch account amount of the merchant.

Optionally, the method further includes: if the flow field in the order record comprises an account separating date, taking the account separating date as a clearing date of the account separating amount; or

If the merchant and/or the market has already been offered or the order record has already been credited, then taking the current date as the clearing date for the credited amount; or

And calculating the accounting date by using an accounting rule, if the calculated accounting date is less than the current date, taking the current date as the clearing date of the accounting amount, and if not, taking the calculated accounting date as the clearing date of the accounting amount.

Optionally, after obtaining the itemized details of the merchants, the method further includes:

when the clearing date is reached, storing the account separating amount into a virtual account of the merchant, and updating the account balance in the virtual account;

transferring the account balance from the virtual account to a settlement account of the merchant upon reaching a predetermined point in time or upon the account balance reaching a predetermined value; wherein the virtual account and the settlement account have a binding relationship.

To achieve the above object, according to another aspect of an embodiment of the present invention, there is provided a ledger administration apparatus including:

the receiving module is used for receiving a separate accounting request of a signed market in a platform and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market;

the reconciliation module is used for determining the transaction total amount in the order record so as to reconcile the transaction total amount into a contract account of a platform from a contract account of a bank receiving component;

and the accounting module is used for processing the transaction total amount by utilizing a market grade accounting strategy corresponding to the market to obtain accounting details.

Optionally, the order record is in a leveling state;

the method further comprises an alignment module for:

Optionally, the apparatus further includes a first selecting module, configured to: and responding to the type selection operation of the market, extracting and displaying a market level accounting strategy list corresponding to the market type, and taking the selected market level accounting strategy as the market level accounting strategy of the market.

Optionally, the accounting module is configured to: analyzing a flow field in an order record to obtain additional item information, preferential information and merchant information, and determining a merchant level accounting strategy corresponding to a merchant number in the merchant information;

Optionally, the apparatus further includes a second selecting module, configured to: and responding to the type selection operation of the merchant, extracting and displaying a merchant level accounting strategy list corresponding to the merchant type, and taking the selected merchant level accounting strategy as the merchant level accounting strategy of the merchant.

Optionally, the accounting module is configured to: if the preferential information is associated with the merchant, taking the transaction amount as a separate account amount for the merchant; or

Optionally, the apparatus further includes an adjusting module, configured to: and if the return record corresponding to the merchant exists, obtaining the return amount in the return record, and taking the difference value between the branch account amount and the return amount as the branch account amount of the merchant.

Optionally, a clearing date module is further included for: if the flow field in the order record comprises an account separating date, taking the account separating date as a clearing date of the account separating amount; or

Optionally, the system further comprises a cash withdrawal module, configured to: when the clearing date is reached, storing the account separating amount into a virtual account of the merchant, and updating the account balance in the virtual account;

To achieve the above object, according to still another aspect of the embodiments of the present invention, there is provided an electronic device for ledger management.

The electronic device of the embodiment of the invention comprises: one or more processors; a storage device, configured to store one or more programs, which when executed by the one or more processors, cause the one or more processors to implement any of the above-described ledger administration methods.

To achieve the above object, according to a further aspect of the embodiments of the present invention, there is provided a computer-readable medium having stored thereon a computer program which, when executed by a processor, implements any of the ledger management methods described above.

According to the scheme provided by the invention, one embodiment of the invention has the following advantages or beneficial effects: a ledger management method suitable for multiple scenes is designed, a changeable ledger strategy of a market and a merchant can be efficiently corresponded, user butt joint is simple, flexibility of service adaptation is guaranteed, quick development and realization are achieved, and intellectualization, instantaneity and practicability of ledger management are improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

fig. 1 is a schematic main flow chart of a ledger management method according to an embodiment of the present invention;

fig. 2 is a flow chart diagram of an alternative ledger administration method according to an embodiment of the present invention;

FIG. 3 is a flow diagram illustrating an alternative ledger administration method according to an embodiment of the present invention;

fig. 4 is a schematic diagram of main blocks of a ledger administration apparatus according to an embodiment of the present invention;

FIG. 5 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

FIG. 6 is a schematic block diagram of a computer system suitable for use with a mobile device or server implementing an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Referring to fig. 1, a main flowchart of a ledger administration method according to an embodiment of the present invention is shown, which includes the following steps:

s101: receiving a separate accounting request for a signed market in a platform, and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market;

s102: determining the transaction total amount in the order record so as to reconcile the transaction total amount from the contract account of the bank collecting component into the contract account of the platform;

s103: and processing the transaction total amount by utilizing a market grade accounting strategy corresponding to the market to obtain the accounting detail.

In the above embodiment, the billing policy is usually present as a part of a certain product function in step S101. The professional market settlement platform (platform for short) in the scheme manages the separate account requirements of various markets, and the premise is that the markets complete registration/signing operation in the platform, and at least one merchant exists under each market, such as catering shops and clothes selling shops under large-size type undersize markets.

The account separation triggering action of a market in the platform can be triggered by clicking of a user or can be triggered by timing of the platform. The core of the accounting is a batch running automatic task, namely, accounting is performed on all the receipts in the previous time period (such as 12 hours, 24 hours and the like, which are described in units of days), then the funds to be accounted are collected, and the accounting operation is performed according to an accounting strategy defined by a user.

The core of batch running lies in the generation and checking of general ledgers, or the large-scale transaction, such as settlement, promotion, collection and payment, etc., or the generation of reports, water flow data, etc. That is, the number of times of settlement per day and the settlement time point are generally about 10 to 12 points. Since the receipt system and person clearing typically occurs in the morning of the second day, on a daily basis, the run batch auto task may be set at 8 o 'clock on the second day to initiate processing of the previous day's transaction.

Each market in the platform has a respective number, and the account of the market on the previous day can be obtained from the bank acquiring component by scanning/inquiring the number of the market; wherein, the statement of account records all the payment transaction information which is paid out in the previous day.

It should be noted that the scheme depends on an external third party to complete the bill collection operation, the statement is stored in the bank bill collection component, but not in the bill collection component in the market in the existing scheme, so that the requirement on the market bill collection is reduced, and the universality of the scheme is improved.

The obtained market statements on the previous day are stored in a text format under the conditions of.

The task uses basic methods such as filelnputstream in java and the like to read the obtained statement and store the statement in a database, namely a statement receiving statement list, simultaneously stores order information in an order component in a platform in the previous day into a platform statement list, then carries out matching verification on the transaction amount of fields with the same serial number in the two lists, and records the statement as a flat state if the transaction amount is the same, otherwise records the uneven state.

In addition, a serial number field for a single order record may not exist for a query in the statement or order information. For the problems of unevenness, more receipts, more platforms and the like, operation and maintenance personnel can be reminded of checking in an alarm mode, for example, automatic short message sending reminding.

For step S102, for the order record of the "platform reconciliation detail table" with the matching result being in the flat state in the last automatic task, the transaction amount in the record is started to be obtained, and the transaction amount is adjusted from the contract account of the bank reconciliation component to the contract account of the platform.

For step S103, in order to support flexible account splitting operation of each business, the present solution subdivides the account splitting scene into the following four angles:

1. multi-tier hierarchical accounting rules

Market level billing rules, merchant level billing rules, and custom level billing rules are currently supported. The market level accounting rule and the merchant level accounting rule need to be used together, the rule is matched from the dimensionality of a market merchant, the market level is shared by the whole market and is low in priority, and the merchant level is exclusive to a certain merchant in the market and is high in priority. The custom billing rules are mutually exclusive with the market/merchant billing rules, and each billing rule has its specific number, which is bound for each transaction from the time of the consumer's payment.

2. Multiple account amount rules

The calculation rule of the account amount is supported according to the fixed amount, the fixed proportion (for example, the market is drawn to 5 percent), the fixed amount and the fixed proportion

3. Multiple billing mode rules

Providing turnover plate type and roller type split account modes

4. Multiple billing time rules

Providing modes of daily, monthly, month end, delay accounting, user active triggering accounting and the like

As can be seen from the above, the accounting policy includes an accounting rule, an amount rule, a mode rule, and a time rule. Some merchants may not set the merchant high-level accounting policy, so that the total transaction amount corresponding to the merchant can be processed through the market level accounting policy of the market to obtain the accounting amount of the merchant, and the specific accounting manner refers to the description shown in fig. 3, which is not described herein again.

The data structure of the branch account rule is designed as follows:

in order to realize the function of triggering the account separation by the user, direct connection interfaces such as a goods arrival notice and the like are further arranged in the scheme, so that the user can bring the account separation date of a certain order to T +1 day ahead, but the scheme is only suitable for a bottom-of-pocket account separation strategy at present. For example, if the ledger date of an order is T +20 and the user initiates a confirmation receipt of the order on day T +2, the ledger date will change from the original T +20 to day T + 3. The interface design is as follows:

input interface

Output interface

In the method provided by the embodiment, in order to improve the availability and reliability of the automatic accounting task, after the accounting operation for the market is triggered, the corresponding order record can be automatically acquired and the accounting can be automatically performed, and the adopted market level accounting strategy is preset by the user and is simple to operate.

Referring to fig. 2, a schematic flow chart of an optional ledger management method according to an embodiment of the present invention is shown, including the following steps:

s201: responding to the type selection operation of the market, extracting and displaying a market level accounting strategy list corresponding to the market type, and taking the selected market level accounting strategy as the market level accounting strategy of the market;

s202: receiving a separate accounting request for a signed market in a platform, and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market;

s203: determining the transaction total amount in the order record so as to reconcile the transaction total amount from the contract account of the bank collecting component into the contract account of the platform;

s204: and processing the transaction total amount by utilizing a market grade accounting strategy corresponding to the market to obtain the accounting detail.

In the above embodiment, for the steps S202 to S204, reference may be made to the descriptions of the steps S101 to S103 shown in fig. 1, and details are not repeated here.

In the above embodiment, for step S201, multiple sets of basic industry templates are preset in the present solution, so as to define the form of the professional market user docking as multiple sets of parameters according to the current status of the bank receiving system, and obtain, in combination with the branch account related parameters:

1) the type of the merchant receiving the order: network special commercial tenant, entity commercial tenant;

2) the butt joint type is as follows: system interaction and non-system interaction;

3) the cashier mode comprises: single counter cashier, multiple counter centralized cashier, multiple counter dispersed cashier

4) The payment method comprises the following steps: h5, App, Internet bank, PC cashier, intelligent payment POS, code scanning box and dynamic code

5) Whether refund: whether or not

6) Whether the sub-order is supported: whether or not

Due to the fact that the parameters are numerous, in order to reduce selection anxiety of the user, the behavior habits of the docked user are preferentially analyzed, the user is divided into 9 types, meanwhile, 9 sets of basic industry templates are defined, the user can sign a contract simply and conveniently in a one-button mode according to the type brief introduction, and meanwhile the user is supported to customize and modify the templates to conduct personalized customization.

1. Online e-commerce payment platform, such as take-out platform and network retail platform

Fixing options: network special merchant + system interaction + single counter cashier + H5\ App \ online cashier \ PC cashier

Optional variables: marketing activities such as refund, sub-order, on-line contract, automatic payment and consumption ticket

2. Novel large and medium-sized shopping malls, e.g. shopping malls and supermarkets, paid offline

Fixing options: network special merchant + system interaction + multi-counter centralized cashier + intelligent payment POS \ code scanning box \ dynamic code

3. Paying off new chain brands, e.g. convenience stores, restaurant chains

Fixing options: network special merchant + system interaction + multi-counter machine dispersed cash collection + code box scanning \ dynamic code

4. Two-dimensional code order-receiving small market, such as stall and dish market

Fixing options: network special merchant + non-system interaction + multi-counter centralized cash register + static code

Optional variables: automatic payment

5. Paying offline to large and medium-sized traditional markets, e.g. scenic spots

Fixing options: entity merchant + system interaction + multi-counter centralized cash collection + POS card swiping/code scanning

Optional variables: marketing activities such as refund, online signing, automatic payment and consumption ticket

6. Paying-off tradition chain brands, e.g. chain stores

Fixing options: solid merchant + system interaction + multi-counter dispersed cashier + POS card swiping/code scanning

7. Paying off-line for small markets, e.g. food cities, payment terminals

Fixing options: solid merchant + non-system interaction + multi-counter machine dispersed cash collection + POS card swiping/code scanning

Optional variables: marketing activities such as automatic payment and consumption ticket

8. Tourism platforms with variable account amounts, e.g. short rents, hotels

Fixing options: in-transit mode + system interaction

Optional variables: marketing activities such as merchant type, system interaction, cash register mode, automatic payment and consumption ticket

9. Matching platforms for supporting tertiary structure, e.g. human resources service enterprises

Fixing options: linked downswing + network special merchant + system interaction + single counter cash registering + H5\ App \ online silver \ PC cash registering

Therefore, when a user signs a market in the platform, the user needs to select the type of the market, and the platform pops up and displays a market level accounting strategy list corresponding to the type so that the user can select options. In addition, the user may edit the billing policy, for example, the fixed options described above are not user-adjustable, but in alternative variables the user may select the configuration.

The method provided by the embodiment presets a plurality of sets of basic industry templates, defines the butt joint form of professional market users as a plurality of sets of parameters, sets fixed options and selectable variables for each branch strategy, and enables the users to be configured in a self-adaptive manner so as to adapt to changeable service scenes.

Referring to fig. 3, a schematic flow chart of another optional ledger management method according to the embodiment of the present invention is shown, including the following steps:

s301: receiving a separate accounting request for a signed market in a platform, and acquiring an order record of the market in a previous time period from a payment order component according to the number of the market;

s302: determining the transaction total amount in the order record so as to reconcile the transaction total amount from the contract account of the bank collecting component into the contract account of the platform;

s303: analyzing a flow field in an order record to obtain additional item information, preferential information and merchant information, and determining a merchant level accounting strategy corresponding to a merchant number in the merchant information;

s304: performing account division management on the transaction amount in the order record by utilizing the market level account division strategy and the merchant level account division strategy and combining the additional item information and the preferential information to obtain account division details of the merchant;

s305: when the clearing date is reached, storing the account separating amount into a virtual account of the merchant, and updating the account balance in the virtual account;

s306: transferring the account balance from the virtual account to a settlement account of the merchant upon reaching a predetermined point in time or upon the account balance reaching a predetermined value; wherein the virtual account and the settlement account have a binding relationship.

In the above embodiment, for steps S301 and S302, reference may be made to the description of steps S101 and S102 shown in fig. 1, and details are not repeated here.

In the above embodiment, in addition to the market-level accounting policy, the merchant-level accounting policy in the market needs to be considered in the accounting in the step S303 and the step S304. The merchant level accounting policy selection mode is similar to the market level accounting policy selection mode, and details are not repeated here.

The day-end clearing automatic task is used for processing the order record with the comparison result being flat, and generating an account detail according to an account division rule, wherein the step rule is as follows:

1) payment order processing rules: and scanning the payment order data meeting the conditions (the online banking flow state is finished, the clearing state is initial, the accounting state is the guarantee ledger accounting success/non-accounting, the market number and the transaction date are less than the current day).

2) Analyzing the compressed field: and analyzing the compression fields of the payment flow, acquiring additional item information, preferential information (such as coupons, red packages and full subtractions) and participant information (generally merchant information), and preparing data for creating branch account details and clearing details.

3) Creating branch account details: and analyzing the compressed field, acquiring the participant information, and generating the account detail according to the participant information.

i, calculating the account amount:

the credit amount is equal to the payment amount of the consumer plus the preferential amount (the consumption coupon amount plus the integral amount plus the red packet amount).

The calculation mode is carried out on the premise that the market provides preferential information, and due to factors such as activities of professional market users, the amount of money of a certain order comprises the order receiving amount paid by a consumer, the market red packet amount and the consumption coupon amount, wherein the red packet amount is acquired from an account of a market party when the money is divided at the end of a day, namely, funds to be divided except the order receiving amount are collected into a contract account of the platform. For example, a certain commodity is sold for 100 yuan, the market provides preferential information of 100 yuan minus 10 yuan, the actual payment of the user is 90 yuan, but the actual merchant needs to collect 100 yuan, and the remaining 10 yuan needs to be acquired from the account of the market.

However, in the case that the merchant provides the preference information, the payment amount of the consumer is directly used as the branch account amount. For example, the full 100 minus 10 units of offer information described above is provided by the merchant and the marketplace is not involved in the offer.

And thirdly, calculating the accounting amount according to the total accounting amount and the accounting rule when the amount of the participator is empty.

And fourthly, if the account distributor has partial refund, the account distributing amount is equal to the original account distributing amount-partial refund amount.

ii calculating the accounting date:

the payment running water is divided into accounts in advance on the same day, and the clearing date is the current date.

And transmitting the accounting date of the payment flow, wherein the clearing date is the accounting date transmitted by the payment flow.

And thirdly, if the merchant of the account distributor has already been contracted, clearing date is the current date.

If the market has been cleared, the clearing date is the current date.

And fifthly, calculating the accounting date according to the accounting rule if the conditions are not met.

Sixthly, comparing all the calculated branch dates with the current date, and if the calculated branch dates are smaller than the current date, judging the branch dates to be the current date.

In addition, if the merchant has a refund order, the account amount needs to be adjusted, specifically, refund information is inquired, a refund flow compression field is analyzed, and refund information and participant refund information with a reduced item are constructed. For example, if the originally calculated credit amount is 100 yuan, but the refund amount of a refund order is 50 yuan, 100-50 yuan is taken as the credit amount actually credited to the merchant.

In addition, a list of subtractions can be created: analyzing the compressed field to obtain additional item information, wherein the type of the additional item is a subtraction item, and a subtraction item list is generated by the additional item with the linkage deduction account number; if the partial refund exists in the reduction item of the payment running water, the sum of the reduction item detail is the original reduction item sum-the partial refund reduction item sum.

For steps S305 and S306, by the current automatic task, all funds to be credited are already collected into the contract account of the platform, but the attributions of the funds to be credited are the respective merchants, so a virtual account needs to be set for each merchant in advance to record the funds to be credited into the respective virtual accounts. At the moment, a batch accounting mode can be adopted, and accounting speed is increased.

Summarizing the clearing details of successful bookkeeping to generate to-be-booked information; and performing cash withdrawal processing on the data of which the clearing date is less than or equal to the current date. The available balances in each virtual account are inquired (the available dates of some balances are after the current date), and then the available balances are transferred to a settlement account appointed by a merchant, so that the automatic daily cash-up task is realized.

According to the method provided by the embodiment, the branch accounting task is divided into a plurality of automatic tasks, each task can process independent events, so that the complicated and changeable branch accounting service scene can be flexibly coped with, and if new demands exist, the changes of the branch accounting service scene can be better coped with.

Referring to fig. 4, a schematic diagram of main modules of an account management apparatus 400 according to an embodiment of the present invention is shown, including:

a receiving module 401, configured to receive a separate accounting request for a signed market in a platform, and obtain, according to a number of the market, an order record of the market in a previous time period from a payment order component;

an reconciliation module 402, configured to determine a total transaction amount in the order record, so as to reconcile the total transaction amount from a contract account of a bank collecting component into a contract account of a platform;

and an accounting module 403, configured to process the transaction total amount by using a market level accounting policy corresponding to the market, so as to obtain accounting details.

In the implementation device of the invention, the order record is in a leveling state;

the method further comprises an alignment module 404 (not shown) for:

The apparatus further includes a first selection module 405 (not shown) for:

In the device for implementing the invention, the market types at least comprise: the online payment e-commerce platform, the offline payment large and medium-sized novel market, the offline payment novel chain brand, the two-dimensional code order-receiving small-sized market, the offline payment large and medium-sized traditional market, the offline payment traditional chain brand, the offline payment small-sized market, the account amount-dividing variable tourism platform and the employment matching platform supporting a three-level structure.

In the implementation apparatus of the present invention, the accounting module 403 is configured to:

analyzing a flow field in an order record to obtain additional item information, preferential information and merchant information, and determining a merchant level accounting strategy corresponding to a merchant number in the merchant information;

The apparatus further includes a second selection module 406 (not shown) for:

and responding to the type selection operation of the merchant, extracting and displaying a merchant level accounting strategy list corresponding to the merchant type, and taking the selected merchant level accounting strategy as the merchant level accounting strategy of the merchant.

The apparatus further includes an adjusting module 407 (not shown) for:

and if the return record corresponding to the merchant exists, obtaining the return amount in the return record, and taking the difference value between the branch account amount and the return amount as the branch account amount of the merchant.

The inventive implementation also includes a clearing date module 408 (not shown) for:

if the flow field in the order record comprises an account separating date, taking the account separating date as a clearing date of the account separating amount; or

The apparatus further includes a presentation module 409 (not shown) for:

In addition, the detailed implementation of the device in the embodiment of the present invention has been described in detail in the above method, so that the repeated description is not repeated here.

Fig. 5 illustrates an exemplary system architecture 500 to which embodiments of the invention may be applied.

As shown in fig. 5, the system architecture 500 may include

terminal devices

501, 502, 503, a network 504, and a server 505 (by way of example only). The network 504 serves to provide a medium for communication links between the

terminal devices

501, 502, 503 and the server 505. Network 504 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

501, 502, 503 to interact with a server 505 over a network 504 to receive or send messages or the like. Various communication client applications can be installed on the

terminal devices

501, 502, 503.

The

terminal devices

501, 502, 503 may be various electronic devices having display screens and supporting web browsing, and the server 505 may be a server providing various services.

It should be noted that the method provided by the embodiment of the present invention is generally executed by the server 505, and accordingly, the apparatus is generally disposed in the server 505.

It should be understood that the number of terminal devices, networks, and servers in fig. 5 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 6, a block diagram of a computer system 600 suitable for use with a terminal device implementing an embodiment of the invention is shown. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 6, the computer system 600 includes a Central Processing Unit (CPU)601 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage section 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the system 600 are also stored. The CPU 601, ROM 602, and RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

The following components are connected to the I/O interface 605: an input portion 606 including a keyboard, a mouse, and the like; an output portion 607 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 608 including a hard disk and the like; and a communication section 609 including a network interface card such as a LAN card, a modem, or the like. The communication section 609 performs communication processing via a network such as the internet. The driver 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 610 as necessary, so that a computer program read out therefrom is mounted in the storage section 608 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 609, and/or installed from the removable medium 611. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 601.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor comprises a receiving module, an adjusting module and a separating module. The names of these modules do not in some cases constitute a limitation on the module itself, for example, the ledger module may also be described as a "ledger administration module".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:

According to the technical scheme of the embodiment of the invention, a multi-scene account division management method is designed, the multi-change account division strategy of markets and merchants can be efficiently corresponded, the user butt joint is simple, the flexibility of service adaptation and the quick development and realization are ensured, and the intellectualization, the real-time performance and the practicability of account division management are improved. The system provides 'unified collection and downward ledger' service for market managers/peaceful partners, meets the requirements of supervision departments on preventing potential transaction information tampering and fund usage moral risks, and can guarantee the rights and benefits of consumers and maintain economic and social stability.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A ledger administration method, characterized by comprising:

2. The method of claim 1, wherein the order record is in a Pair-level state;

3. The method of claim 1, wherein prior to said processing said transaction total with a market level accounting policy corresponding to said market for accounting details, further comprising:

4. The method of claim 3, wherein the market types include at least: the online payment e-commerce platform, the offline payment large and medium-sized novel market, the offline payment novel chain brand, the two-dimensional code order-receiving small-sized market, the offline payment large and medium-sized traditional market, the offline payment traditional chain brand, the offline payment small-sized market, the account amount-dividing variable tourism platform and the employment matching platform supporting a three-level structure.

5. The method of claim 1, wherein processing the transaction total with a market level accounting policy corresponding to the market to obtain an accounting detail comprises:

6. The method of claim 5, wherein prior to the determining a merchant level billing policy corresponding to a merchant number in the merchant information, further comprising:

7. The method of claim 5, wherein the using the market level billing policy and the merchant level billing policy, in combination with the additional item information and the benefit information, to perform billing management on the transaction amount in the order record to obtain billing details for the merchant comprises:

8. The method of claim 7, further comprising:

9. The method of claim 7, further comprising:

10. The method of claim 9, further comprising, after said obtaining the itemized details for the merchant:

11. A ledger administration apparatus, characterized by comprising:

12. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-10.

13. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-10.