Medicine pricing method and device and computer readable storage medium

Abstract

The invention discloses a medicine pricing method and device and a computer readable storage medium, and the method comprises the steps: obtaining customer group attribute information carried by a purchase request in response to the purchase request initiated by a client for a target medicine; based on the target medicine and the customer group attribute information, step-by-step descending order matching is executed in a preset pricing rule base, the final selling price of the target medicine is determined according to a matching result, and the pricing rule base comprises a plurality of pricing rules with preset priorities; and if the execution of the step-by-step descending order matching in the preset pricing rule base is not hit, determining the final sales price of the target drug based on a preset bottom pricing mechanism. The medicine pricing method has the advantage of guaranteeing the accuracy and continuity of pricing in a complex business scene.

Description

Technical Field

[0001] This invention relates to the field of Internet data processing technology, and in particular to a drug pricing method, device, and computer-readable storage medium. Background Technology

[0002] With the development of B2B e-commerce in the pharmaceutical industry, drug procurement scenarios are becoming increasingly complex. In existing pharmaceutical e-commerce platforms, the basic pricing of drugs typically adopts a rigid matching model of "single price + sales region." That is, when a store lists a product, it can only set a uniform basic selling price and specify the geographical area where it can be sold. When a customer initiates a purchase request, the system simply determines whether the customer is located within the specified region; if so, it returns the uniform basic price.

[0003] However, this low-dimensional, rigid matching logic is ill-suited to the increasingly sophisticated operational needs of the pharmaceutical industry. On one hand, it cannot support high-dimensional manufacturer agreements (e.g., exclusive price agreements for "specific products" belonging to "specific chain pharmacies"), preventing high-priority commercial contracts from being implemented in the system. This forces businesses to face the risk of price control failure when expanding regional markets or maintaining major clients. On the other hand, the existing matching logic is typically "open-loop," lacking a flexible fault-tolerance mechanism. When new products are launched without timely regional configuration, or when customer attributes (such as newly added clinic types) do not match the preset rigid conditions, the system often creates a "pricing gap" due to the inability to match effective prices, directly disrupting the transaction process and severely impacting procurement efficiency and user experience.

[0004] Therefore, designing a pricing method that can balance high-dimensional personalized protocols with low-dimensional general strategies and ensure the continuity of price output in various complex scenarios has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a drug pricing method to address the technical problems in existing pharmaceutical e-commerce pricing technologies, such as the inability to accurately implement contracted prices due to a single matching dimension, and the pricing gaps and transaction interruptions caused by the lack of a flexible matching mechanism.

[0006] To achieve the above objectives, embodiments of this application provide a drug pricing method, including: In response to a client's purchase request for a target drug, obtain the customer group attribute information carried in the purchase request; Based on the target drug and the customer group attribute information, a descending-order matching is performed in a preset pricing rule library, and the final sales price of the target drug is determined according to the matching result. The pricing rule library includes multiple pricing rules with preset priorities. If the stepwise descending matching is not found in the preset pricing rule base, the final selling price of the target drug is determined based on the preset fallback pricing mechanism.

[0007] In one embodiment, the customer group attribute information includes at least one of customer region, customer type, customer tag, and purchase volume level.

[0008] In one embodiment, the multiple pricing rules in the pricing rule base include a specific pricing rule set and a general pricing rule set; wherein, the specific pricing rule set is configured to be defined based on a combination dimension of the target drug and the customer group attribute information; The general pricing rule set is configured to be defined based on a single dimension of the customer group attribute information; and the specific pricing rule set has a higher priority than the general pricing rule set.

[0009] In one embodiment, performing a descending-order matching process in a preset pricing rule base and determining the final selling price of the target drug based on the matching results includes: Based on the target drug and the customer group attribute information, a combined search key is constructed, and the combined search key is used to perform a specific match in the specific pricing rule set; If the specific match is found, a target pricing strategy is determined based on the matched item, and the final selling price is determined based on the target pricing strategy. If the specific match is not found, a general match is performed on the general pricing rule set, and a target pricing strategy is determined based on the matching result of the general match, and the final selling price is determined based on the target pricing strategy.

[0010] In one embodiment, the specific pricing rule set includes contract pricing rules and product strategy pricing rules arranged in descending order of preset priority; Performing a specific match using the combined search key within the specific pricing rule set, and determining the target pricing strategy based on the matched items, includes: Using the dimension features in the combined search key that correspond to the contract pricing rule, perform a first-level match with the contract pricing rule; If the first-level match is successful, then the candidate pricing strategy associated with the contract pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy. If the first-level match fails, a second-level match is performed using the dimension features in the combined search key that correspond to the product strategy pricing rule. If the secondary matching is successful, then the candidate pricing strategies associated with the product strategy pricing rules are obtained, and the target pricing strategy is determined based on the candidate pricing strategies.

[0011] In one embodiment, the general pricing rule set includes customer strategy pricing rules; Performing a general matching against the general pricing rule set, and determining the target pricing strategy based on the matching result of the general matching, includes: A single search key is constructed based on the customer group attribute information, and the single search key is matched with the customer policy rules in three levels. If the three-level matching is successful, then the candidate pricing strategy associated with the customer strategy pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy.

[0012] In one embodiment, the candidate pricing strategies include a fixed-price pricing strategy, a product price type pricing strategy, and a cost-plus pricing strategy; Determining the final selling price based on the target pricing strategy includes one of the following steps: If the target pricing strategy is the fixed price pricing strategy, then the fixed price parameter configured in the fixed price pricing strategy is parsed, and the fixed price parameter is determined as the final selling price; If the target pricing strategy is the product price type pricing strategy, then the basic price type pointed to in the product price type pricing strategy is parsed, and the basic price corresponding to the target drug under the basic price type is queried as the final selling price; If the target pricing strategy is the cost-plus pricing strategy, then the calculated cost price of the target drug is obtained, and the final selling price is calculated by combining the markup ratio configured in the cost-plus pricing strategy.

[0013] In one embodiment, during the determination of the target pricing strategy, if at least two candidate pricing strategies are identified based on the same search key, conflict arbitration logic is executed, the conflict arbitration logic including: Identify the customer group attributes on which each of the at least two candidate pricing strategies is based; Based on preset attribute priorities, the candidate pricing strategy corresponding to the highest priority customer group attribute is selected from the at least two candidate pricing strategies as the target pricing strategy.

[0014] In one embodiment, the attribute priority is configured such that customer type has a higher priority than customer region.

[0015] In one embodiment, determining the final selling price according to the target pricing strategy further includes performing price validity verification at each matching level, the price validity verification including: The provisional selling price is calculated based on the target pricing strategy. Determine whether the temporary sales price is zero; If the temporary sales price is zero, the corresponding first-level, second-level, or third-level matching result will be corrected to a no match, thereby triggering the subsequent priority matching process or triggering the fallback pricing mechanism.

[0016] In one embodiment, the contract pricing rules are configured to include specified product conditions and specified customer scope conditions; Using the dimension features in the combined search key that correspond to the contract pricing rule, a first-level matching is performed with the contract pricing rule, including: If the target drug in the combined search key matches the specified product condition, and the customer type or customer region in the combined search key matches the specified customer range condition, then the first-level match is determined to be successful.

[0017] In one embodiment, the product strategy pricing rule is configured to include specified product conditions and specified customer profile conditions; Using the dimension features in the combined search key that correspond to the product strategy pricing rule, a second-level matching is performed with the product strategy pricing rule, including: If the target drug in the combined search key matches the specified product conditions, and the customer type, customer region, and customer tag in the combined search key also match the specified customer profile conditions, then the secondary matching is determined to be successful.

[0018] In one embodiment, the customer strategy pricing rule is configured to include a specified region condition and a specified group type condition; Perform a three-level match between the single search key and the customer strategy pricing rules, including: If the customer region in the single search key matches the specified region condition, and the customer type or customer tag in the single search key matches the specified group type condition, then the three-level match is determined to be successful.

[0019] In one embodiment, determining the final selling price of the target drug based on a preset safety net pricing mechanism includes: Obtain the calculated cost price of the target drug and the preset guaranteed markup ratio; The final selling price is calculated based on the following formula: Final selling price = calculated cost price × (1 + guaranteed markup percentage).

[0020] In one embodiment, prior to responding to a purchase request initiated by a client for the target drug, the method further includes: A basic price database is established, which stores the price value of each drug under different basic price types, wherein the basic price types include at least one of pharmacy price, clinic price, chain store price and membership price.

[0021] To achieve the above objectives, embodiments of this application also propose a drug pricing device, including a memory, a processor, and a drug pricing program stored in the memory and executable on the processor. When the processor executes the drug pricing program, it implements the drug pricing method as described in any of the above embodiments.

[0022] To achieve the above objectives, embodiments of this application also propose a computer-readable storage medium storing a drug pricing program, which, when executed by a processor, implements the drug pricing method as described in any of the preceding claims.

[0023] The drug pricing method provided in this application has the following beneficial effects: 1. Achieved precise implementation of high-dimensional business contracts and personalized strategies: By adopting a "hierarchical descending order matching" mechanism and constructing a "specific pricing rule set" based on "combined search keys (target drug + customer group attributes)," and setting its priority higher than general rules based on only a single dimension, this application can precisely converge the granularity of pricing rules to a strong association combination of "designated product" and "designated customer," thereby achieving mandatory priority execution of manufacturer contract prices (such as special prices in designated regional chain stores) or store precision marketing strategies. This overcomes the shortcomings of the traditional "single price + fixed region" model, which cannot support complex agreements and leads to the failure of high-value contracts. It achieves effective coverage of "universal strategies" by "exclusive contracts," thereby protecting the core business interests of merchants and the execution of market expansion strategies.

[0024] 2. Eliminates pricing gaps and ensures the continuity and closed loop of the transaction process: By adopting a preset "safety net pricing mechanism" and connecting its logic to the end of the hierarchical matching process, i.e., triggering when neither specific matching nor general matching is found; this application can dynamically generate the final sales price in real time based on the "calculated cost price" and "safety net markup ratio", thereby overcoming the defect of existing technologies that cause "pricing gaps" and thus transaction interruptions when encountering new product listings without configured rules or customer attributes not matching preset conditions. It achieves a logical closed loop where the system is always "available for sale" regardless of the input drug or customer combination, thereby significantly improving order conversion rate and customer purchasing experience while ensuring basic profit.

[0025] 3. Resolves pricing conflicts under multiple concurrent rules, ensuring the uniqueness and optimality of price output: By adopting "multi-strategy conflict arbitration logic" and introducing "customer group attribute priority (e.g., customer type > customer region)" as the arbitration benchmark, this application can automatically identify and lock the strategy with higher commercial weight in complex scenarios where a single transaction hits multiple pricing rules simultaneously (e.g., the customer belongs to both a certain region and a certain chain institution). This overcomes the defects of pricing ambiguity or system errors caused by overlapping customer attributes, realizes the automation and determinism of pricing decisions, thereby reducing the cost of manual intervention and reducing after-sales disputes caused by price chaos.

[0026] 4. Improved efficiency and flexibility of general strategy adaptation: By adopting "hybrid logic verification (region + type / tag)" or "single search key" matching in the general matching process, this application can quickly distribute universal benefits (such as storewide member prices) that lack product dimensions to a wide range of customers who match the profile. This overcomes the inefficiency of repeatedly configuring general rules for each product, achieving efficient operation and maintenance of "one-time configuration, storewide effect", and thus significantly shortening the pricing maintenance time for merchants. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0028] Figure 1 This is a modular structure diagram of an embodiment of the drug pricing device of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the drug pricing method of the present invention.

[0029] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0030] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0031] To better understand the above technical solutions, exemplary embodiments of this disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of this disclosure to those skilled in the art.

[0032] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The quantifier "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of "first," "second," and "third," etc., does not indicate any order and can be interpreted as names.

[0033] like Figure 1 As shown, Figure 1 This is a schematic diagram of the hardware operating environment server 1 (also called drug pricing equipment) involved in the embodiment of the present invention.

[0034] The server in this embodiment of the invention includes devices with display functions such as "Internet of Things devices", smart air conditioners, smart lights, smart power supplies with network connectivity, AR / VR devices with network connectivity, smart speakers, autonomous vehicles, PCs, smartphones, tablets, e-book readers, and portable computers.

[0035] like Figure 1 As shown, the server 1 includes: a memory 11, a processor 12, and a network interface 13.

[0036] The memory 11 includes at least one type of readable storage medium, such as flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 11 can be an internal storage unit of the server 1, such as the hard disk of the server 1. In other embodiments, the memory 11 can also be an external storage device of the server 1, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the server 1.

[0037] Furthermore, the memory 11 may include both internal storage units of the server 1 and external storage devices. The memory 11 can be used not only to store application software and various types of data installed on the server 1, such as the code of the drug pricing program 10, but also to temporarily store data that has been output or will be output.

[0038] In some embodiments, processor 12 may be a central processing unit (CPU), controller, microcontroller, microprocessor or other data processing chip, used to run program code stored in memory 11 or process data, such as executing drug pricing program 10.

[0039] The network interface 13 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface), which is typically used to establish communication connections between the server 1 and other electronic devices.

[0040] The network can be the Internet, a cloud network, a Wi-Fi network, a Personal Area Network (PAN), a Local Area Network (LAN), and / or a Metropolitan Area Network (MAN). Various devices in the network environment can be configured to connect to the communication network according to various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, at least one of the following: Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE 802.11, Li-Fi, 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access points (APs), device-to-device communication, cellular communication protocols, and / or Bluetooth communication protocols, or combinations thereof.

[0041] Optionally, the server may also include a user interface, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an OLED (Organic Light-Emitting Diode) touchscreen, etc. The display may also be referred to as a screen or display unit, used to display information processed in server 1 and to display a visual user interface.

[0042] Figure 1 Only server 1, which includes components 11-13 and drug pricing program 10, is shown. Those skilled in the art will understand that... Figure 1 The structure shown does not constitute a limitation on server 1 and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0043] In this embodiment, the processor 12 can be used to call the drug pricing program stored in the memory 11 and perform the following operations: In response to a client's purchase request for a target drug, obtain the customer group attribute information carried in the purchase request; Based on the target drug and the customer group attribute information, a descending-order matching is performed in a preset pricing rule library, and the final sales price of the target drug is determined according to the matching result. The pricing rule library includes multiple pricing rules with preset priorities. If the stepwise descending matching is not found in the preset pricing rule base, the final selling price of the target drug is determined based on the preset fallback pricing mechanism.

[0044] Based on the hardware architecture of the aforementioned drug pricing equipment, an embodiment of the drug pricing method of this invention is proposed. The drug pricing method of this invention aims to solve the technical problems in existing pharmaceutical e-commerce pricing technologies, such as the inability to accurately implement contracted prices due to a single matching dimension, and the pricing gaps and transaction interruptions caused by the lack of a flexible matching mechanism.

[0045] Reference Figure 2 , Figure 2 This is an embodiment of the drug pricing method of the present invention, which is applied to a pharmaceutical procurement e-commerce platform and includes the following steps: S10. In response to a purchase request initiated by the client for the target drug, obtain the customer group attribute information carried in the purchase request.

[0046] In this embodiment, step S10 is the triggering point and data preparation stage of the entire pricing process. Specifically, when a user selects a drug and attempts to obtain a price or submit an order through the client of a pharmaceutical procurement e-commerce platform (such as a mobile APP, mini-program, PC webpage, or ERP interface), the client will initiate an API call request (i.e., the procurement request) based on the HTTPS protocol to the server. The data body or header of this procurement request carries a product ID (SKU ID) to uniquely identify the target drug and an identity credential (such as UserToken or Customer ID) to identify the current procurement entity.

[0047] Upon receiving a purchase request, the server retrieves the purchasing entity's profile data at the current transaction moment based on identity credential parsing or from a pre-built customer profile database (Customer Profile DB), thereby constructing customer group attribute information. This customer group attribute information is a key index parameter used for subsequent multi-dimensional matching in the pricing rule base, and it is encapsulated in a structured data format (such as JSON objects or XML fields).

[0048] In some embodiments of this application, the customer group attribute information is configured to include, but is not limited to, at least one of the following dimensions: Client Region: refers to the administrative division to which the client's registered business address or delivery address is located, such as "Guangdong Province - Guangzhou City - Tianhe District"; Client Type: This refers to the nature or business type of a client's operations within the pharmaceutical distribution chain. In this application, client business types specifically include pharmacies (independent pharmacies), clinics (including community health service stations), medical institutions (such as public / private hospitals), and distributors (commercial companies). Client Label: Refers to a characteristic identifier assigned to a customer based on their historical behavior or qualification certification. In this application, the client characteristic label specifically includes a chain certification label (indicating whether the customer belongs to a pharmaceutical chain headquarters) and a membership level label (such as gold member, highly active user, used to identify the customer's loyalty or contribution). Purchase Volume Level: This refers to the quantity scale in this purchase request (e.g., "single order > 100 boxes") or the customer's historical average monthly purchase amount level (e.g., "monthly purchase > 100,000 yuan"), which is used to trigger the volume-based tiered pricing logic.

[0049] For example, consider a chain pharmacy in Guangdong (named "XXX Pharmacy") initiating a purchase request for "Cold Relief Granules (target drug)". When the purchasing agent of "XXX Pharmacy" clicks to place an order on the client, the server executes step S10, and the obtained customer group attribute information is structured into a feature vector or data object in the following form: { "Region": "Guangdong", "Type": "Pharmacy", "Tags": ["Chain_Certified", "Gold_Member"], "Volume_Level": "Lvl_1"}. At this point, the system has completed the extraction of all the context information required for pricing, providing standardized input data for constructing a search key and performing progressively descending matching using this information in subsequent step S20.

[0050] S20. Based on the target drug and the customer group attribute information, perform a descending-order matching in a preset pricing rule library, and determine the final sales price of the target drug according to the matching result, wherein the pricing rule library includes multiple pricing rules with preset priorities.

[0051] After the necessary data preparation is completed in step S10, step S20, as the decision-making stage of this application, aims to locate the only effective rule that best suits the current transaction scenario from a massive number of pricing rules through an orderly logical screening mechanism.

[0052] In this embodiment, the "preset pricing rule base" is a logical collection stored in a server-side database (such as MySQL, Redis, or a NoSQL database). This rule base stores several pre-configured pricing rules. Each pricing rule contains at least two core fields: 1. Triggering Condition Field: Used to define the scope of scenarios to which this rule applies (e.g., which drugs, regions, or types of customers). 2. Priority Identifier Field: Used to quantify the weight of this rule in conflict arbitration (e.g., Priority_Level = 1, 2, 3..., the smaller the value, the higher the priority). It should be noted that the "preset priority" is predetermined by the system based on business logic (e.g., business contracts take precedence over internal operations, specific assignments take precedence over general strategies), ensuring the logical orderliness of the rule base.

[0053] Based on this, the "gradual descending order matching" executed by the system is a serial retrieval or logical judgment process with "short-circuit" characteristics. The specific implementation logic is as follows: The system takes the target drug (such as product ID) and customer group attribute information obtained in step S10 as input parameters, and sequentially traverses or retrieves each pricing rule according to the descending order of the preset priority in the pricing rule library (i.e., starting from the highest priority).

[0054] During the retrieval process for each priority level, the system determines whether the current input parameters meet the triggering conditions set by the pricing rules for that priority level: If a match is found: meaning the input parameters fully satisfy the conditions of a high-priority rule, the system immediately terminates the search process for subsequent low-priority rules (i.e., "short-circuiting") and directly locks onto the matching rule. Subsequently, the system parses the pricing logic encapsulated in the matching rule (such as specific numerical values ​​or calculation formulas) to determine the final selling price.

[0055] If no match is found: meaning that none of the rules under the current priority apply, the system will automatically "downgrade" and enter the rule retrieval process of the next lower priority until a matching rule is found or all rules have been traversed.

[0056] Understandably, through this hierarchical descending matching mechanism, this application can ensure that pricing rules with higher commercial value or stronger binding force are always prioritized in complex business scenarios, thus avoiding interference from low-dimensional rules on high-dimensional contracts.

[0057] In some embodiments of this application, in order to resolve the contradiction between "single dimension" and "unable to implement contract price" in the prior art, the system logically divides the preset pricing rule base into two subsets with a strict hierarchical relationship: a specific pricing rule set and a general pricing rule set.

[0058] Specifically, the specific pricing rule set is a high-priority set of rules configured to be defined based on a "combination dimension," meaning each rule must be bound to both a specific drug ID and a specific set of customer group attributes. Its business essence is "exclusive pricing for specific products."

[0059] The universal pricing rule set is a low-priority set of rules configured to be defined based on a "single dimension," meaning that rules are only bound to customer group attributes and are not limited to specific drug IDs (or apply to all drugs with maintained base prices in the store). Its business essence is "universal pricing for a specific customer group."

[0060] Furthermore, the specific pricing rule set has a higher global priority than the general pricing rule set. This means that during iteration, the system always checks the specific pricing rule set completely first. Only after all specific pricing rule sets are not matched will the system proceed to check the general pricing rule set. This implies that if a special agreement exists for the drug (such as a manufacturer's contract), the system will prioritize executing that agreement, thereby overriding the store's general discounting strategy.

[0061] Based on the above architecture, the "step-by-step descending order matching" described in step S20 is specifically expanded into the following sub-steps (S21-S23): S21. Construct a combined search key based on the target drug and the customer group attribute information, and use the combined search key to perform a specific match in the specific pricing rule set.

[0062] In this step, the system first performs a "high-dimensional search". Specifically, the server concatenates or combines the unique identifier of the target drug (such as SKUID) determined in step S10 with customer group attribute information (such as Region ID + Type ID) to construct a composite search key.

[0063] The system then uses this combined search key to initiate a query within a specific pricing rule set. This process aims to precisely identify the existence of a strong correlation rule between a "specific product and a specific customer group."

[0064] For example, if the target drug is "Product A" and the customer is "a chain pharmacy in Guangdong," the system constructs a combined search key as {SKU: "Item_A", Attrs: ["Guangdong", "Chain_Pharmacy"]}. The system searches within a specific rule set to determine if there are records that exactly match this key value.

[0065] In some embodiments, in order to balance the mandatory nature of commercial contracts (broad coverage) and the precision of store operations (fine granularity), in some embodiments of this application, the specific pricing rule set is internally divided into two subsets with preset priorities: higher priority contract pricing rules and lower priority product strategy pricing rules.

[0066] S22. If the specific match is found, a target pricing strategy is determined based on the matched item, and the final sales price is determined based on the target pricing strategy.

[0067] If step S21 successfully retrieves a match (i.e., a hit) within the specific pricing rule set, this indicates that the current transaction involves a high-priority contract or special strategy (such as a manufacturer's contract price or a store promotional price). At this point, the system immediately performs the following operations: 1. Locking strategy: Read the pricing logic encapsulated in the matched item and determine it as the target pricing strategy.

[0068] 2. Calculate the price: Execute this strategy (e.g., directly return the contract price "3 yuan").

[0069] 3. Termination process (short-circuit mechanism): The system will no longer perform subsequent searches for the general pricing rule set (i.e., skip S23).

[0070] For example, in the case above, if the system finds that "Product A - Guangdong customer" has a "contract price of 3 yuan", it will directly output 3 yuan, regardless of whether the customer is still entitled to the general discount of "20% off", thus ensuring the manufacturer's absolute right to execute the contract price.

[0071] Specifically, based on the specific pricing rule set architecture of higher-priority contract pricing rules and lower-priority product strategy pricing rules, step S22 is refined into the following sub-steps S221 to S224: S221. Using the dimension features in the combined search key that correspond to the contract pricing rule, perform a first-level match with the contract pricing rule.

[0072] First, the system executes a first-level matching process based on the contract pricing rules.

[0073] In some embodiments, contract pricing rules are configured to include specified product conditions and specified customer scope conditions. Since contract pricing is typically designed to protect the rights and interests of customers in specific regions or of specific types, its matching logic is designed to be a more inclusive "logical OR" operation.

[0074] Specifically, the system parses the combined search key constructed in step S21, extracts the target drug identifier, customer type, and customer region features, and performs verification according to the following logic: 1. Product consistency check: Determine whether the target drug in the combined search key is consistent with the specified product conditions in the rules; if they are inconsistent, the first-level matching will fail directly.

[0075] 2. Customer scope verification (logical OR): If the products are consistent, then further determine whether there is any customer type or customer area in the combined search key that is consistent with the specified customer scope condition.

[0076] For example, a contractual rule is set as "Product A + (Guangdong region OR chain pharmacy)". If the customer is a "single pharmacy in Guangdong", although it is not a chain, it meets the regional condition, and the logical check passes; if the customer is a "chain pharmacy in Guangxi", although it is not in Guangdong, it meets the type condition, and the logical check also passes.

[0077] It is worth noting that, in this embodiment, even if the above logical verification passes (i.e., attribute matching), the system does not directly determine that the first-level match "hit," but further performs price validity verification to prevent transaction anomalies caused by configuration errors (such as the price being misconfigured as 0). The verification process is as follows: 1. Calculate the temporary price: Based on the contract pricing rules that have passed the current logical verification, calculate the temporary sales price; 2. Zero-price determination: Determine whether the temporary sales price is zero; 3. Result correction: If the temporary sales price is greater than zero, the first-level match is determined to be a successful match and the process proceeds to step S222; if the temporary sales price is zero, the system considers the rule configuration invalid and forcibly corrects the result of the first-level match to "missed", thereby triggering the subsequent priority matching process (i.e., jumping to step S223).

[0078] In other embodiments, manufacturer agreements may have stricter exclusivity. In this case, the first-level matching is configured to perform a logical AND check. Specifically, the system determines that the target drug in the combined search key matches the specified product conditions, and that the customer type and customer region also match the specified customer range conditions. For example, the contract rules stipulate that "a special price of 3 yuan is only offered to chain pharmacies in Guangdong." In this case, if the customer is only a "single pharmacy in Guangdong" or a "chain pharmacy in Guangxi," the first-level matching will fail.

[0079] In some other embodiments, the contract pricing rules may be bound to only a single-dimensional strong constraint. Specifically, the system may only verify the customer region (ignoring type) or only verify the customer type (ignoring region). If the single-dimensional match is successful, a first-level match is considered to have been achieved.

[0080] S222. If the first-level match is successful, the candidate pricing strategy associated with the contract pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy.

[0081] Specifically, the system confirms a first-level match only if the customer attribute logic validation passes and the price validity validation passes. At this point, the system obtains the candidate pricing strategy (such as a fixed-price pricing strategy) associated with the contract pricing rule, determines it as the target pricing strategy, calculates the final sales price accordingly, and terminates the subsequent matching process (i.e., steps S223 and thereafter are no longer executed).

[0082] S223. If the first-level match fails, then the second-level match is performed using the dimension features in the combined search key that correspond to the product strategy pricing rule.

[0083] If a first-level match fails due to attribute mismatch or a price of zero, the system automatically downgrades to a second-level match process based on the product's pricing strategy rules, using the combined search keys.

[0084] In some embodiments, the product strategy pricing rules are configured to include specified product conditions and specified customer profile conditions. Since product strategies are typically used for targeted marketing in stores, their matching logic is designed as a high-precision logical AND operation.

[0085] Specifically, the system performs the verification according to the following logic: 1. Product consistency verification: Determine whether the target drug is consistent.

[0086] 2. Customer Profile Validation (Logical AND): If the products match, further determine whether the customer type, customer region, and customer tags in the combined search key simultaneously match the specified customer profile conditions. The logical validation only passes when all three are completely and irreplaceable.

[0087] For example, a certain strategy rule is set as "Product A + (Guangdong region AND chain pharmacies AND Gold Member)". If the customer only meets the requirements of "Guangdong" and "chain", but lacks the "Gold Member" label, the logic validation will fail.

[0088] Similarly, the second-level matching also includes a price validity verification step: 1. Calculate the temporary price: Based on the product strategy pricing rules that have passed the current logical verification, calculate the temporary selling price; 2. Zero-price determination: Determine whether the temporary sales price is zero; 3. Result Correction: If the temporary sales price is greater than zero, the secondary matching is determined to be a successful match, and the process proceeds to step S224; if the temporary sales price is zero, the system considers the rule configuration invalid and forcibly corrects the result of the secondary matching to "missed," thereby triggering the subsequent priority matching process (i.e., jumping to step S23). This correction action will cause the entire specific matching process to be determined as "missed," thereby triggering the subsequent general matching for the general pricing rule set (i.e., step S23) or ultimately triggering the fallback pricing mechanism.

[0089] In other embodiments, stores may wish to expand their promotional reach, in which case a "partial matching" logic can be used. Specifically, the product strategy pricing rules set N dimension conditions (such as type, region, tags, and purchase quantity). The system determines whether the number of dimensions that meet the conditions in the combined search key reaches a preset threshold (such as "meets any 2 conditions"). If the number of met conditions is greater than or equal to the preset threshold, then a secondary match is determined to have occurred. For example: the strategy requires "Guangdong + chain + gold member". The threshold is set to 2. If the customer is "a chain pharmacy in Guangdong (regular member)", meeting 2 conditions, a match is determined.

[0090] In some embodiments, the system executes a "weighted scoring" logic. Specifically, the rules assign different weight scores to each dimension (e.g., 30 points for region matching, 20 points for type matching, and 50 points for tag matching). The system calculates the total matching score based on the combined search key; if the total score exceeds the passing threshold (e.g., 60 points), a secondary match is determined to have been achieved. This is suitable for fuzzy matching or recommendation-based pricing scenarios.

[0091] S224. If the secondary matching is successful, obtain the candidate pricing strategy associated with the product strategy pricing rule, and determine the target pricing strategy based on the candidate pricing strategy.

[0092] Specifically, if both the logic verification and price verification of the secondary matching pass, the system determines that the secondary matching is successful, obtains the corresponding candidate pricing strategy, determines the target pricing strategy based on the candidate pricing strategy, calculates the final price, and terminates the matching process.

[0093] S23. If the specific match is not found, perform a general match for the general pricing rule set, determine the target pricing strategy based on the matching result of the general match, and determine the final sales price based on the target pricing strategy.

[0094] When the specific matching (including first-level and second-level matching) in steps S21 and S22 fails to match a valid rule (for example, the drug has neither a manufacturer's contract price nor a store promotion strategy for a specific product), the system will automatically perform a "dimensionality reduction" operation and enter the general matching process for the general pricing rule set.

[0095] In this embodiment, the general pricing rule set includes several customer strategy pricing rules. These rules are configured to define universal pricing logic (such as "member price" or "uniform price increase in a certain region") based solely on customer group attributes (such as region, type, and tag), without being bound to specific drug IDs.

[0096] In some embodiments, step S23 specifically includes the following sub-steps S231-S233: S231. Construct a single search key based on the customer group attribute information.

[0097] The system first performs "dimensionality reduction" on the input search criteria. Specifically, the system removes the "target drug" dimension and retains only the customer group attribute information (including customer region, customer type, and customer tags) obtained in step S10, thereby constructing a single search key. This single search key represents the customer's "profile features" and is used to find the general benefits that customer enjoys within the store.

[0098] S232. Perform a three-level matching between the single search key and the customer policy rule.

[0099] The system uses this single search key to traverse the customer strategy pricing rules in the general pricing rule set. Since general strategies typically combine "basic thresholds" and "specific preferential treatment," in the preferred embodiment of this application, the three-level matching is configured to perform "hybrid logic verification": 1. Regional Threshold Validation (Basic Conditions): First, determine whether the customer region in a single search key is consistent with the specified regional conditions in the rule (e.g., the rule only applies to "East China Region"). 2. Identity Preferential Verification (Logical OR): If the regions are consistent, further determine whether any of the customer types or customer tags in the single search key are consistent with the specified group type conditions in the rules.

[0100] For example, a general rule is set to "for clinics or distributors in Hunan Province". If the customer is a "single pharmacy in Hunan Province", the verification will fail because the product type does not match, even though the region is met; if the customer is a "clinic in Hunan Province", the verification will pass.

[0101] In addition, to prevent pricing anomalies caused by general rule configuration errors (such as the referenced "basic price type" not maintaining a value), the system must perform price validity verification after determining that the attribute logic validation has passed. This price validity verification step includes: 1. Calculate the temporary price: Based on the customer policy pricing rules that have passed the current logical verification, calculate the temporary sales price; 2. Zero-price determination: Determine whether the temporary sales price is zero; 3. Result Correction: If the temporary sales price is greater than zero, the three-level matching is determined to be officially hit, and the process proceeds to step S233; if the temporary sales price is zero, the system considers the rule configuration invalid, and the result of the three-level matching is forcibly corrected to "missed". The system will ultimately determine that step S23 is not hit, thereby triggering the system's last line of defense - the fallback pricing mechanism.

[0102] In other embodiments that emphasize refined, tiered management, the three-level matching in step S23 is configured to perform a logical AND check. In this mode, general pricing rules are typically targeted at very specific customer groups (e.g., a specific general price for "chain pharmacies in Guangdong that are gold members").

[0103] Specifically, the system determines whether the customer region, customer type, and customer tags in a single search key simultaneously match all preset conditions in the rules. If the rules define conditions in three dimensions, all three customer attributes must be met for the attribute validation to pass. Similarly, even if the attributes match perfectly, if the calculated temporary sales price is zero, the system forcibly corrects the result to a miss, triggering a fallback mechanism. This model is suitable for precise pricing of "high-value general groups," preventing ordinary customers from "free-riding" on general discounts.

[0104] In some computationally limited or rule-structured embodiments, the third-level matching in step S23 is configured to perform "intra-dimensional degradation" verification. In this mode, general matching is no longer a "one-size-fits-all" approach, but rather attempts are made following a preset dimensional order.

[0105] Specifically, the system first uses only "customer type" to match general rules; if a match is found and the price is valid, it returns the result directly. If the type does not match, it uses "customer region" to match; if a match is found and the price is valid, it returns the result. If neither of these matches, it uses "customer tag" to match. In each of these attempts, once an attribute match is successful, a zero-price check is immediately performed. If the price is 0, it is considered a mismatch for that dimension, and the system automatically downgrades to the next dimension for further attempts. This approach implicitly resolves rule conflicts and simplifies subsequent arbitration logic by directly hard-coding priorities (e.g., type > region > tag) during the retrieval phase.

[0106] S233. If the three-level matching is successful, the candidate pricing strategy associated with the customer strategy pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy.

[0107] When a level 3 match is successful (i.e., the attributes match and the price is valid), the system obtains the candidate pricing strategies associated with the rule and determines the target pricing strategy based on the candidate pricing strategies.

[0108] It is worth noting that the system may face a situation of "multiple rules concurrently" during the process of determining the target pricing strategy from the candidate pricing strategies. If at least two candidate pricing strategies are identified based on the same search key—for example, when performing secondary matching, the target drug simultaneously matches a rule defined based on "customer region (e.g., Sichuan)" and a rule defined based on "customer type (e.g., chain pharmacies)"—then, in order to ensure the uniqueness of the price output, the system will execute conflict arbitration logic.

[0109] Specifically, the conflict arbitration logic includes the following steps: S110. Identifying the source of attributes: The system first identifies the customer group attributes on which each of the at least two candidate pricing strategies is based. That is, the system backtracks to determine which dimension of the customer's characteristics was matched for each strategy to trigger it (for example, strategy A was triggered because it matched "Sichuan", and strategy B was triggered because it matched "chain pharmacies").

[0110] S120. Priority-based selection: Based on preset attribute priorities, select the candidate pricing strategy corresponding to the highest priority customer group attribute from the at least two candidate pricing strategies as the target pricing strategy.

[0111] In a preferred embodiment of this application, the attribute priority is configured as: Customer Type > Customer Region.

[0112] For example, suppose the customer is a "chain pharmacy located in Sichuan". The system has two valid rules for this drug: Rule A sets a "cost-plus pricing strategy" based on "Sichuan region", and Rule B sets a "fixed-price pricing strategy" based on "chain pharmacy". During conflict arbitration, the system identifies Rule B as based on "customer type" and Rule A as based on "customer region". Since "customer type" has higher priority than "customer region", the system will determine Rule B to win and set its associated fixed-price pricing strategy as the final target pricing strategy. This logic ensures that more commercially valuable customer identity characteristics (such as chain certification) take precedence over geographical location characteristics in pricing power.

[0113] Furthermore, the candidate pricing strategies in this application include fixed-price pricing strategies, product price type pricing strategies, and cost-plus pricing strategies. These are encapsulated into different types of strategy objects or configuration data packages at the system level.

[0114] Once the aforementioned steps (such as S22, S23, etc.) have determined a unique target pricing strategy from the candidate pricing strategies, the system will enter the price calculation and execution phase. The system first parses the strategy type identifier of the target pricing strategy and triggers one of the following three parallel processing logics based on the type identifier: Branch 1: Implement a fixed-price pricing strategy: If the system identifies the target pricing strategy as a fixed-price pricing strategy, it indicates that the strategy aims to sever the dynamic link between drug prices and costs or market fluctuations, implementing strong intervention pricing. Under this branch, the system performs the following operations: 1. Parameter parsing: The system directly reads the Fixed_Price_Value field encapsulated in the strategy object, which is the fixed price parameter.

[0115] 2. Assignment Output: The system does not perform any additional database queries or calculations, but directly assigns the parsed values ​​to the final sales price variable.

[0116] For example, suppose a rule is matched in the secondary matching for "Sichuan region - clinics", and the determined target pricing strategy is a fixed price pricing strategy with an internal configuration parameter of 9.00. The system directly parses this parameter and determines the final selling price to be 9.00 yuan.

[0117] Branch Two: Implement Product Price Type Pricing Strategy: If the system identifies the target pricing strategy as a product price type pricing strategy, it indicates that the strategy aims to reference the store's pre-maintained standard pricing system (such as pharmacy prices, member prices, etc.). Under this branch, the system performs the following operations: 1. Resolve pointer: The system reads the Reference_Type_ID field encapsulated in the strategy object to obtain the underlying price type it points to (e.g., "Member Price" or "Chain Price").

[0118] 2. Secondary query: The system uses the "target drug ID" and the parsed "basic price type" as the combined index key to search the preset basic price database.

[0119] 3. Price Extraction: The system retrieves the specific price value returned by the query and uses it as the final selling price.

[0120] For example, suppose a pharmacy (chain pharmacy) initiates a purchase, and the system matches a general strategy that points to "member price". The system parses Type="Member_Price" and then queries the basic price database for the corresponding "member price" field for that drug (let's say it's 4 yuan). The system ultimately determines the selling price to be 4.00 yuan.

[0121] Branch 3: Implement Cost-Plus Pricing Strategy: If the system identifies the target pricing strategy as a cost-plus pricing strategy, indicating that the strategy aims to ensure a specific profit margin, dynamic calculation logic will be executed. Under this branch, the system will perform the following operations: 1. Obtain input data: Cost data: The system calls the interface of the commodity center to obtain the current accounting cost price C of the target drug.

[0122] 2. Bonus Parameter: The bonus ratio R configured in the policy object is parsed by the system.

[0123] 3. Execute the calculation formula: The system calls the preset calculation engine to calculate the final sales price P_final according to the following formula: P_final = C × (1 + R), where the calculation result is usually standardized according to preset rounding rules (such as keeping two decimal places and rounding up).

[0124] For example, suppose the strategy targeting "highly active users in Jiangsu province" is successful, with a bonus ratio R = 10%. The system obtains the calculated cost price of the drug, C = 2.00 yuan. The system calculates P_final = 2.00 × (1 + 0.10) = 2.20 yuan. Therefore, the final selling price is determined to be 2.20 yuan.

[0125] Specifically, in one embodiment of this application, the strategy types associated with each matching level are configured differently based on the strength of the constraints in the business scenario.

[0126] Specifically, the strategy types associated with each matching level and their specific application scenarios are as follows: 1. First-level matching (for contract pricing rules): The candidate pricing strategy associated with a primary match is typically a fixed-price pricing strategy. This is determined by the strong contractual nature of the manufacturer's contract, which aims to ensure that the absolute value agreed upon in the agreement must be strictly implemented for specific contracted customers, regardless of fluctuations in market costs.

[0127] For example, a manufacturer signs a strategic agreement with the platform to "open up the Guangdong market," stipulating that "Product A will be priced at 3.00 yuan for all types of customers in Guangdong or national chain pharmacies." In this case, if the customer is a "single pharmacy in Guangdong," although not a chain, it meets the "Guangdong" regional condition, resulting in a first-level match. The system directly calls the associated fixed-price strategy, locking in a final selling price of 3.00 yuan, thus ensuring the accurate implementation of the manufacturer's contracted price.

[0128] 2. Secondary matching (for product strategy pricing rules): The candidate pricing strategies associated with the secondary matching can be any one of the following: fixed-price pricing strategy, product price type pricing strategy, and cost-plus pricing strategy. This reflects the high flexibility of store operations, enabling the adaptation of different marketing objectives based on refined customer profiles.

[0129] Example of pricing strategy when a second-level match is hit: Case A (Competitor Sniping - Fixed Price): To counter competitors in the Sichuan region, the store sets the rule "Product A + Sichuan Region + Clinic = 9.00 yuan". When a clinic in the Sichuan region initiates a purchase, all three conditions are met simultaneously, resulting in a secondary matching match. The system executes the fixed-price strategy, outputting 9.00 yuan.

[0130] Case B (Chain Store Maintenance - Reference Base Price): To maintain relationships with major clients, the store sets the rule "Product A + Chain Pharmacy = Member Price". When the "Chain Pharmacy" purchases Product A, the match is successful. The system executes the product price type strategy, referencing Product A's "Member Price" (e.g., 4.00 yuan) as the selling price.

[0131] Case C (Supply Guarantee / New Product - Cost-Plus): The store targets a specific high-cost customer segment, setting the rule "Product A + Jiangsu Region + Highly Active Users = 10% Add-on to Calculated Cost Price". When a customer matching all of the above profiles makes a purchase, the system matches the customer. The system executes the cost-plus strategy, calculating based on the cost of Product A (e.g., 2.00 yuan): 2.00 × (1 + 10%) = 2.20 yuan.

[0132] 3. Three-tier matching (based on customer strategy pricing rules): The candidate pricing strategies associated with three-level matching are typically product price type pricing strategies or cost-plus pricing strategies. Due to the lack of a strong dimension of "target drug," general rules focus more on referencing the basic price system or setting a uniform profit margin to achieve "one-time configuration, effective throughout the store."

[0133] Example of pricing strategy when a level 3 match is achieved: Case A (Regional Pricing - Reference Base Price): The store sets a general rule: "Hunan Region + Individual Pharmacy = Reference Clinic Price". When an "individual pharmacy in Hunan" purchases any product without a special strategy (such as product B), although there is no rule specifically for product B, the general rule is applied. The system executes the product price type strategy, querying the "clinic price" (e.g., 6.00 yuan) of product B as the final selling price.

[0134] Case B (Channel Pricing - Cost Plus): The store sets a general rule: "Hunan region + chain pharmacies = calculated cost price plus 10%". When a "chain pharmacy in Hunan" purchases product B, this rule is triggered. The system executes the cost plus strategy, calculating the selling price based on the cost of product B.

[0135] As can be seen from the above examples, this application utilizes different levels of matching logic (broad / strict / hybrid) combined with diverse pricing strategies (fixed / reference / additional pricing) to perfectly cover all business scenarios, from "strong contract implementation" to "precision marketing" and "universal benefits." Of course, the design of this application is not limited to this. In other embodiments, first-level matching can also be associated with cost-plus pricing strategies (e.g., an agreement to supply goods long-term at "5% above the calculated cost price"); similarly, second-level and third-level matching can also be associated with other custom candidate pricing strategies based on the actual B2B business model, and this application does not impose any restrictions on this.

[0136] S30. If the step-by-step descending matching is not found in the preset pricing rule base, the final sales price of the target drug is determined based on the preset fallback pricing mechanism.

[0137] After completing step S20 (including S21-S23), if the system reports that neither specific matching nor general matching has been successful (e.g., the target drug is a newly launched product that has not yet been configured with any contract or promotion rules; or the customer belongs to a new type of remote area not covered by the system), or if the matching result is corrected to a failure due to the failure of "price validity verification" (price is zero) in the aforementioned matching steps, the system will trigger the preset fallback pricing mechanism.

[0138] The mechanism was designed to address the transaction interruption problem caused by "pricing gaps" in existing technologies, ensuring that the system can always output a valid price that is not empty, regardless of the input drug or customer combination.

[0139] In some embodiments, step S30 is specifically expanded into the following sub-steps S31-S32: S31. Obtain the calculated cost price of the target drug and the preset guaranteed markup ratio.

[0140] The system first retrieves the calculated cost price (denoted as C) of the target drug at the current transaction time from the basic commodity database. This calculated cost price is usually derived by the ERP system based on the drug's purchase price, warehousing costs, etc.

[0141] At the same time, the system reads the global parameter configuration at the store level to obtain the preset bottom-line bonus ratio (denoted as R). This ratio is set by the merchant based on their expected minimum profit margin (e.g., 20% or 50%).

[0142] For example, suppose a chain clinic in Xinjiang initiates a purchase of "Drug A". Since no rules are configured for this region, all preceding matches fail. The system executes S31, retrieves the calculated cost price of Drug A, C = 2.00 yuan, and the store's set bottom-line markup ratio R = 50%.

[0143] S32. Calculate the final sales price based on the following formula: The system calls the calculation engine and substitutes the parameters obtained in step S31 into the preset cost-plus formula to perform the calculation: Final selling price (P) = Calculated cost price (C) × (1 + Guarantee markup percentage (R)).

[0144] The calculation result is the system-generated safety net price. In practical applications, the system can also standardize the calculation result according to preset decimal processing rules (such as rounding to two decimal places).

[0145] For example, the system calculates P = 2.00 × (1 + 0.50) = 3.00 yuan. Finally, the system determines 3.00 yuan as the final selling price for the transaction and returns it to the client.

[0146] It is worth noting that although the above embodiments use a "proportional markup" approach, in other embodiments, the catch-all pricing mechanism can also use a "fixed amount markup" approach (i.e., P = C + fixed amount), or use the "market suggested retail price" as the catch-all price. These alternative solutions can also achieve the technical effect of "eliminating pricing gaps" and all fall within the protection scope of the catch-all mechanism of this application.

[0147] By executing step S30, this application has fully realized the closed loop of the entire chain from "high-dimensional contract matching" to "low-dimensional general matching" and then to "cost-backed calculation", completely eliminating the risk of order loss caused by missing rule configuration.

[0148] In some embodiments, before responding to a client's purchase request for the target drug (i.e., performing step S10), the drug pricing method of this application further includes a preliminary data preparation step S01: S01. Establish a basic price database, which stores the price value of each drug under different basic price types.

[0149] In this embodiment, step S01 is typically completed by the store administrator or operations personnel in the merchant backend management system of the e-commerce platform. The system provides a visual price maintenance interface, allowing users to enter the corresponding multi-dimensional basic price for each listed drug (SKU) and persistently store this data in the basic price database.

[0150] Specifically, the basic price database is designed as a multidimensional mapping table structure, which uses "unique drug identifier (SKU ID)" and "basic price type (Price Type)" as a combined primary key to index a unique "price value (PriceValue)".

[0151] The basic price type is a standard price anchor point preset by the system to adapt to different customer groups, including but not limited to at least one of the following types: Pharmacy price: Standard wholesale price applicable to ordinary independent pharmacies; Clinic Price: A special price applicable to community health service stations or private clinics; Chain price: The basic price agreed upon by large chain pharmacies; Member price: A discounted price applicable to paid platform members or high-level customers.

[0152] For example, taking the product "Cold Relief Granules (Item A)" as an example, its calculated cost price is 2 yuan. In step S01, the store administrator enters the basic price matrix of the product in the background, and the system stores it as the following records: Item A - Pharmacy Price: 5.00 yuan; Item A - Clinic Price: 6.00 yuan; Item A - Chain Store Price: 7.00 yuan; Item A - Member Price: 4.00 yuan.

[0153] By establishing the aforementioned basic price database, the system provides the necessary data support for the "product price type pricing strategy" involved in subsequent steps (such as S22 and S23). When a subsequent pricing strategy (such as a general strategy) indicates "selling at the member price," the system can directly index the specific value of "4.00 yuan" based on this database, thereby achieving a rapid conversion from "abstract strategy" to "specific price."

[0154] In summary, the drug pricing method provided in this application has the following beneficial effects: 1. Achieved precise implementation of high-dimensional business contracts and personalized strategies: By adopting a "hierarchical descending order matching" mechanism and constructing a "specific pricing rule set" based on "combined search keys (target drug + customer group attributes)," and setting its priority higher than general rules based on only a single dimension, this application can precisely converge the granularity of pricing rules to a strong association combination of "designated product" and "designated customer," thereby achieving mandatory priority execution of manufacturer contract prices (such as special prices in designated regional chain stores) or store precision marketing strategies. This overcomes the shortcomings of the traditional "single price + fixed region" model, which cannot support complex agreements and leads to the failure of high-value contracts. It achieves effective coverage of "universal strategies" by "exclusive contracts," thereby protecting the core business interests of merchants and the execution of market expansion strategies.

[0155] 2. Eliminates pricing gaps and ensures the continuity and closed loop of the transaction process: By adopting a preset "safety net pricing mechanism" and connecting its logic to the end of the hierarchical matching process, i.e., triggering when neither specific matching nor general matching is found; this application can dynamically generate the final sales price in real time based on the "calculated cost price" and "safety net markup ratio", thereby overcoming the defect of existing technologies that cause "pricing gaps" and thus transaction interruptions when encountering new product listings without configured rules or customer attributes not matching preset conditions. It achieves a logical closed loop where the system is always "available for sale" regardless of the input drug or customer combination, thereby significantly improving order conversion rate and customer purchasing experience while ensuring basic profit.

[0156] 3. Resolves pricing conflicts under multiple concurrent rules, ensuring the uniqueness and optimality of price output: By adopting "multi-strategy conflict arbitration logic" and introducing "customer group attribute priority (e.g., customer type > customer region)" as the arbitration benchmark, this application can automatically identify and lock the strategy with higher commercial weight in complex scenarios where a single transaction hits multiple pricing rules simultaneously (e.g., the customer belongs to both a certain region and a certain chain institution). This overcomes the defects of pricing ambiguity or system errors caused by overlapping customer attributes, realizes the automation and determinism of pricing decisions, thereby reducing the cost of manual intervention and reducing after-sales disputes caused by price chaos.

[0157] 4. Improved efficiency and flexibility of general strategy adaptation: By adopting "hybrid logic verification (region + type / tag)" or "single search key" matching in the general matching process, this application can quickly distribute universal benefits (such as storewide member prices) that lack product dimensions to a wide range of customers who match the profile. This overcomes the inefficiency of repeatedly configuring general rules for each product, achieving efficient operation and maintenance of "one-time configuration, storewide effect", and thus significantly shortening the pricing maintenance time for merchants.

[0158] Furthermore, this invention also proposes a computer-readable storage medium, which can be any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, etc. The computer-readable storage medium includes a drug pricing program 10. The specific implementation of the computer-readable storage medium of this invention is largely the same as the specific implementation of the drug pricing method and server 1 described above, and will not be repeated here.

[0159] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0160] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0161] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0162] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0163] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0164] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A drug pricing method applied to a pharmaceutical procurement e-commerce platform, characterized in that, The drug pricing methods include: In response to a client's purchase request for a target drug, obtain the customer group attribute information carried in the purchase request; Based on the target drug and the customer group attribute information, a descending-order matching is performed in a preset pricing rule library, and the final sales price of the target drug is determined according to the matching result. The pricing rule library includes multiple pricing rules with preset priorities. If the stepwise descending matching is not found in the preset pricing rule base, the final selling price of the target drug is determined based on the preset fallback pricing mechanism.

2. The drug pricing method as described in claim 1, characterized in that, The customer group attribute information includes at least one of the following: customer region, customer type, customer tag, and purchase volume level.

3. The drug pricing method as described in claim 1, characterized in that, The pricing rule base includes multiple pricing rule sets, such as specific pricing rule sets and general pricing rule sets; among them... The specific pricing rule set is configured to be defined based on a combination of the target drug and the customer group attribute information; The general pricing rule set is configured to be defined based on a single dimension of the customer group attribute information; and The specific pricing rule set has a higher priority than the general pricing rule set.

4. The drug pricing method as described in claim 3, characterized in that, Perform a descending-order matching process within a pre-defined pricing rule base, and determine the final selling price of the target drug based on the matching results, including: Based on the target drug and the customer group attribute information, a combined search key is constructed, and the combined search key is used to perform a specific match in the specific pricing rule set; If the specific match is found, a target pricing strategy is determined based on the matched item, and the final selling price is determined based on the target pricing strategy. If the specific match is not found, a general match is performed on the general pricing rule set, and a target pricing strategy is determined based on the matching result of the general match, and the final selling price is determined based on the target pricing strategy.

5. The drug pricing method as described in claim 4, characterized in that, The specific pricing rule set includes contract pricing rules and product strategy pricing rules arranged in descending order of preset priority; Performing a specific match using the combined search key within the specific pricing rule set, and determining the target pricing strategy based on the matched items, includes: Using the dimension features in the combined search key that correspond to the contract pricing rule, perform a first-level match with the contract pricing rule; If the first-level match is successful, then the candidate pricing strategy associated with the contract pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy. If the first-level match fails, a second-level match is performed using the dimension features in the combined search key that correspond to the product strategy pricing rule. If the secondary matching is successful, then the candidate pricing strategies associated with the product strategy pricing rules are obtained, and the target pricing strategy is determined based on the candidate pricing strategies.

6. The drug pricing method as described in claim 5, characterized in that, The general pricing rule set includes customer strategy pricing rules; Performing a general matching against the general pricing rule set, and determining the target pricing strategy based on the matching result of the general matching, includes: A single search key is constructed based on the customer group attribute information, and the single search key is matched with the customer policy rules in three levels. If the three-level matching is successful, then the candidate pricing strategy associated with the customer strategy pricing rule is obtained, and the target pricing strategy is determined based on the candidate pricing strategy.

7. The drug pricing method as described in claim 6, characterized in that, The candidate pricing strategies include fixed-price pricing strategy, product price type pricing strategy, and cost-plus pricing strategy; Determining the final selling price based on the target pricing strategy includes one of the following steps: If the target pricing strategy is the fixed price pricing strategy, then the fixed price parameter configured in the fixed price pricing strategy is parsed, and the fixed price parameter is determined as the final selling price; If the target pricing strategy is the product price type pricing strategy, then the basic price type pointed to in the product price type pricing strategy is parsed, and the basic price corresponding to the target drug under the basic price type is queried as the final selling price; If the target pricing strategy is the cost-plus pricing strategy, then the calculated cost price of the target drug is obtained, and the final selling price is calculated by combining the markup ratio configured in the cost-plus pricing strategy.

8. The drug pricing method according to any one of claims 4 to 7, characterized in that, In determining the target pricing strategy, if at least two candidate pricing strategies are identified based on the same search key, conflict arbitration logic is executed, which includes: Identify the customer group attributes on which each of the at least two candidate pricing strategies is based; Based on preset attribute priorities, the candidate pricing strategy corresponding to the highest priority customer group attribute is selected from the at least two candidate pricing strategies as the target pricing strategy.

9. The drug pricing method as described in claim 8, characterized in that, The attribute priority is configured such that customer type has a higher priority than customer region.

10. The drug pricing method according to any one of claims 4 to 7, characterized in that, Determining the final sales price based on the target pricing strategy further includes performing price validity verification at each matching level, the price validity verification including: The provisional selling price is calculated based on the target pricing strategy. Determine whether the temporary sales price is zero; If the temporary sales price is zero, the corresponding first-level, second-level, or third-level matching result will be corrected to a no match, thereby triggering the subsequent priority matching process or triggering the fallback pricing mechanism.

11. The drug pricing method as described in claim 5, characterized in that, The contract pricing rules are configured to include specified product conditions and specified customer scope conditions; Using the dimension features in the combined search key that correspond to the contract pricing rule, a first-level matching is performed with the contract pricing rule, including: If the target drug in the combined search key matches the specified product condition, and the customer type or customer region in the combined search key matches the specified customer range condition, then the first-level match is determined to be successful.

12. The drug pricing method as described in claim 5, characterized in that, The product strategy pricing rules are configured to include specified product conditions and specified customer profile conditions; Using the dimension features in the combined search key that correspond to the product strategy pricing rule, a second-level matching is performed with the product strategy pricing rule, including: If the target drug in the combined search key matches the specified product conditions, and the customer type, customer region, and customer tag in the combined search key also match the specified customer profile conditions, then the secondary matching is determined to be successful.

13. The drug pricing method as described in claim 6, characterized in that, The customer strategy pricing rules are configured to include specified regional conditions and specified group type conditions; Perform a three-level match between the single search key and the customer strategy pricing rules, including: If the customer region in the single search key matches the specified region condition, and the customer type or customer tag in the single search key matches the specified group type condition, then the three-level match is determined to be successful.

14. The drug pricing method as described in claim 1, characterized in that, Based on a pre-set safety net pricing mechanism, the final selling price of the target drug is determined, including: Obtain the calculated cost price of the target drug and the preset guaranteed markup ratio; The final selling price is calculated based on the following formula: Final selling price = calculated cost price × (1 + guaranteed markup percentage).

15. The drug pricing method as described in claim 1, characterized in that, Prior to responding to a client's purchase request for the target drug, the method further includes: A basic price database is established, which stores the price value of each drug under different basic price types, wherein the basic price types include at least one of pharmacy price, clinic price, chain store price and membership price.

16. A drug pricing device, characterized in that, The device includes a memory, a processor, and a drug pricing program stored in the memory and executable on the processor, wherein the processor, when executing the drug pricing program, implements the drug pricing method as described in any one of claims 1-15.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a drug pricing program, which, when executed by a processor, implements the drug pricing method as described in any one of claims 1-15.

Images