Inventory unit attribute adding method and device, equipment and medium

Abstract

The invention belongs to the field of research and development, and relates to an inventory unit attribute adding method, which comprises the following steps: receiving an inventory unit creation request, and obtaining an inventory unit file of an inventory type indicated by inventory type information based on the inventory type information carried by the inventory unit creation request, the inventory unit file comprises attribute configuration logic, inspection logic and necessary attribute information; creating an initial inventory unit of the inventory type based on the attribute configuration logic, the verification logic and the necessary attribute information; based on the inspection logic, inspecting the initial inventory unit, and if the inspection is passed, determining the initial inventory unit as a target inventory unit; when an attribute adding request of a target inventory unit is received, obtaining a plurality of target attributes; and adding the plurality of target attributes to the target inventory unit to obtain the target inventory unit with newly added attributes. The invention further provides a device, equipment and a medium. The method can be applied to the business field of finance and the like, and the scene adaptation capability of an inventory unit can be improved.

Description

Technical Field

[0001] This application relates to the field of human R & D technology and is applied to online processing business scenarios such as finance and e-commerce. In particular, it relates to a method, device, equipment and medium for adding attributes of stock keeping units. Background Art

[0002] In the context of the deep empowerment of the retail, e-commerce and service industries by Internet technology, the standardized configuration of goods and services has become the core infrastructure to support multi-scenario business operations. In the prior art, the configuration of stock keeping units (SKUs) usually adopts a static attribute full-configuration mode, that is, the attribute set of SKUs is predefined based on business requirements, and the linkage configuration between attributes is realized through an attribute hierarchy association mechanism. For example, in the e-commerce field, a standard SKU needs to include basic attributes (such as name, price), business attributes (such as specification parameters), and secondary and tertiary attributes derived from the basic attributes (such as color-size combinations, package combinations, etc.). During the configuration process, it is necessary to define the attributes and their association relationships item by item through hard coding or a visual interface.

[0003] The above configuration method has significant advantages in the initial stage of business. However, with the exponential growth of business volume and the increasing demand for multi-scenario coverage, the limitations of the traditional configuration mode have gradually emerged. For example, the prior art adopts a mechanism of full-attribute pre-configuration plus static verification, resulting in non-essential attributes being forced to be exposed in all business scenarios. Business personnel need to traverse redundant attributes in a non-differentiated interface, significantly increasing the operation load; the boundary between essential attributes and non-essential attributes is solidified, and it is impossible to dynamically adjust the attribute configuration strategy according to specific business scenarios, etc. There is an urgent need for a method to solve the problems of redundant SKU attribute configuration and insufficient scenario adaptation ability in the prior art. Summary of the Invention

[0004] The purpose of the embodiments of this application is to propose a method, device, computer equipment and storage medium for adding attributes of stock keeping units to solve the problems of redundant stock keeping unit attribute configuration and insufficient scenario adaptation ability in the prior art.

[0005] In a first aspect, a method for adding attributes of stock keeping units is provided, which adopts the following technical solutions:

[0006] The system receives a stock unit creation request, which carries stock type information. Based on the stock type information, it retrieves the stock unit file for the stock type indicated by the stock type information. The stock unit file includes attribute configuration logic, verification logic, and necessary attribute information. Based on the attribute configuration logic, verification logic, and necessary attribute information, it creates an initial stock unit for the stock type. Based on the verification logic, it verifies the initial stock unit. If the verification passes, the initial stock unit is determined as the target stock unit. When a request to add attributes to the target stock unit is received, multiple target attributes are retrieved. The multiple target attributes are added to the target stock unit to obtain the target stock unit after the attribute addition.

[0007] Secondly, a device for adding attributes to inventory units is provided, which adopts the following technical solution:

[0008] The first receiving module is used to receive inventory unit creation requests, which carry inventory type information.

[0009] The acquisition module is used to obtain the inventory unit file of the inventory type indicated by the inventory type information based on the inventory type information. The inventory unit file includes attribute configuration logic, verification logic and necessary attribute information.

[0010] The creation module is used to create the initial inventory unit of the inventory type based on attribute configuration logic, verification logic, and necessary attribute information;

[0011] The inspection module is used to inspect the initial inventory unit based on inspection logic. If the inspection passes, the initial inventory unit is determined as the target inventory unit.

[0012] The second receiving module is used to obtain multiple target attributes when it receives a request to add attributes to a target inventory unit.

[0013] The Add module is used to add multiple target attributes to a target inventory unit, and obtain the target inventory unit after the attributes are added.

[0014] Thirdly, a computer device is provided, which adopts the following technical solution:

[0015] The system receives a stock unit creation request, which carries stock type information. Based on the stock type information, it retrieves the stock unit file for the stock type indicated by the stock type information. The stock unit file includes attribute configuration logic, verification logic, and necessary attribute information. Based on the attribute configuration logic, verification logic, and necessary attribute information, it creates an initial stock unit for the stock type. Based on the verification logic, it verifies the initial stock unit. If the verification passes, the initial stock unit is determined as the target stock unit. When a request to add attributes to the target stock unit is received, multiple target attributes are retrieved. The multiple target attributes are added to the target stock unit to obtain the target stock unit after the attribute addition.

[0016] Fourthly, a computer-readable storage medium is provided, which adopts the following technical solution:

[0017] The system receives a stock unit creation request, which carries stock type information. Based on the stock type information, it retrieves the stock unit file for the stock type indicated by the stock type information. The stock unit file includes attribute configuration logic, verification logic, and necessary attribute information. Based on the attribute configuration logic, verification logic, and necessary attribute information, it creates an initial stock unit for the stock type. Based on the verification logic, it verifies the initial stock unit. If the verification passes, the initial stock unit is determined as the target stock unit. When a request to add attributes to the target stock unit is received, multiple target attributes are retrieved. The multiple target attributes are added to the target stock unit to obtain the target stock unit after the attribute addition.

[0018] Compared with existing technologies, the embodiments of this application have the following main advantages: Based on inventory type information, the attribute configuration logic is dynamically loaded, presenting only attributes strongly related to the current business scenario. This avoids the forced exposure of redundant attributes in the traditional full-scale pre-configuration mode, thereby significantly simplifying the user interface and reducing the risk of configuration errors due to attribute overload. Simultaneously, through the synergistic effect of necessary attribute information and verification logic, the system can automatically verify the compliance and completeness of attribute configurations, ensuring that inventory units meet business rule requirements during the creation stage and avoiding data rollback or correction in subsequent processes. Furthermore, the dynamic response capability for adding attributes allows for flexible expansion of inventory unit functionality in the later stages of business operations based on actual needs, without refactoring the underlying configuration logic, thus quickly adapting to new business scenarios or promotional activities. This solution decouples inventory unit configuration from business scenarios, significantly improving the agility and efficiency of multi-scenario business operations while ensuring data consistency. Attached Figure Description

[0019] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is an exemplary system architecture diagram to which this application can be applied;

[0021] Figure 2 A flowchart of an embodiment of the method for adding attributes of inventory units according to this application;

[0022] Figure 3 This is a schematic diagram of one embodiment of the inventory unit attribute adding device according to this application;

[0023] Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0027] like Figure 1As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0028] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0029] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc.

[0030] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0031] It should be noted that the method for adding attributes to inventory units provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the device for adding attributes to inventory units is generally set in the server / terminal device.

[0032] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0033] Continue to refer Figure 2 The diagram illustrates a flowchart of an embodiment of a service recommendation method according to this application. The method for adding attributes to an inventory unit includes the following steps:

[0034] Step S201: Receive inventory unit creation request. The inventory unit creation request carries inventory type information.

[0035] In this embodiment, the method for adding attributes to inventory units runs on an electronic device (e.g., Figure 1 The server / terminal device shown can receive inventory unit creation requests via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra wideband) connections, and other currently known or future-developed wireless connection methods.

[0036] Among them, the inventory unit creation request is a technical instruction initiated by the business system or user terminal. It originates from front-end operations (such as the product listing interface) or API interface calls, and represents the user's SKU configuration requirements for a specific inventory type (such as electronic products and clothing). It is used to trigger the back-end SKU creation process, such as "receiving the mobile SKU creation request submitted by the user through the e-commerce backend".

[0037] Among them, the inventory type information is a business identifier embedded in the inventory unit creation request. It comes from the product classification system (such as first-level category-second-level category) and represents the business type to which the SKU to be configured belongs (such as food-fresh produce). It is used to guide the system to load the corresponding configuration template. For example, "when the inventory type information is 'clothing-menswear', the system loads the menswear SKU configuration file".

[0038] Step S202: Based on the inventory type information, obtain the inventory unit file of the inventory type indicated by the inventory type information. The inventory unit file includes attribute configuration logic, verification logic, and necessary attribute information.

[0039] Among them, inventory type refers to the business category entity of goods or services, which represents a set of goods with similar attribute configuration requirements (such as home appliances, cosmetics), and is used to define the baseline logic for SKU configuration.

[0040] The inventory unit file is a collection of logical files stored in the backend configuration center. It comes from system presets or administrator configurations and represents attribute configuration templates for specific inventory types, which are used to standardize the SKU creation process.

[0041] The attribute configuration logic is defined in a set of programmable rules in the inventory unit file (e.g., SKU package), which represents the dynamic dependencies between attributes (e.g., size list update triggered after color selection) and is used to implement on-demand attribute loading.

[0042] The verification logic is a rule-based verification module embedded in the inventory unit file. It is derived from data consistency constraints or business compliance requirements, and represents the legality (e.g., price > 0) and necessity (e.g., minimum order quantity must be configured in wholesale scenarios) of attribute values ​​to ensure the validity of SKU data.

[0043] Among them, the essential attribute information is stored in the basic configuration items of the inventory unit file. It comes from the business requirements document or system design specifications and represents the set of attributes that must be configured for a specific inventory type (such as product name and inventory quantity). It is used to build the core data structure of SKU. For example, the essential attribute information for the "book" inventory type includes ISBN code and publisher information.

[0044] Step S203: Based on the attribute configuration logic, verification logic, and necessary attribute information, create the initial inventory unit for the inventory type.

[0045] The initial inventory unit is an intermediate data object dynamically generated based on the inventory unit file. It comes from the combined calculation of attribute configuration logic and necessary attribute information, and represents the unverified SKU basic structure for subsequent verification and expansion. For example, the system generates an initial SKU containing "power" and "voltage" attributes based on the home appliance SKU package.

[0046] Step S204: Based on the verification logic, the initial inventory unit is verified. If the verification passes, the initial inventory unit is determined as the target inventory unit.

[0047] Among them, verification refers to the technical verification process of the initial SKU through verification logic. It represents a dual check on the necessity and legality of attribute values ​​and is used to filter out incorrect configurations. For example, if the verification finds that the "shelf life" attribute in the SKU is empty and belongs to the "food" type, it is determined that the verification has failed.

[0048] The target inventory unit refers to a standardized SKU data entity that has passed verification. It originates from the initial SKU and is processed by verification logic. It represents a product or service configuration unit that can be put into business use to support business logic such as orders and inventory. For example, a women's clothing target SKU contains complete attributes such as color, size, and price and can be put on the shelves for sale.

[0049] Step S205: When a request to add attributes for a target inventory unit is received, multiple target attributes are obtained.

[0050] Among them, the attribute addition request refers to the technical instruction initiated by business personnel during the SKU usage phase. It originates from product operation needs (such as adding a promotional label) and represents the need for extended configuration of an existing SKU, used to dynamically optimize the SKU attribute set. For example, receiving a request from operations personnel to add the "A Activity Promotion" label.

[0051] Among them, multiple target attributes refer to the set of attributes to be configured included in the attribute addition request. These attributes are derived from business rules or user-defined attributes and represent the attribute list that needs to be added to the SKU (such as promotional labels and gift information) to expand the SKU functionality. For example, the added attributes include "discount rules" and "gift SKU code".

[0052] Step S206: Add multiple target attributes to the target inventory unit to obtain the target inventory unit with the added attributes.

[0053] In this context, "adding" refers to the technical operation of integrating multiple target attributes into a target SKU. It originates from the execution of attribute configuration logic and represents the dynamic expansion of the SKU attribute set, used to achieve full lifecycle management of the SKU. For example, the system adds the "discount rule" attribute to a home appliance SKU and triggers the associated logic to update the promotional price calculation method.

[0054] The target inventory unit after attribute addition refers to the final SKU data entity after attribute expansion. It originates from the fusion of the target SKU and the new attribute, representing a product or service configuration unit with new business capabilities to support complex business scenarios. For example, the expanded apparel SKU adds the "live stream exclusive price" attribute, allowing it to participate in limited-time discount activities.

[0055] In one example, within the fintech field, the standardized configuration of fund products needs to adapt to multiple sales channels (such as bank sales and internet wealth management platforms) and multiple business scenarios (such as initial public offering subscriptions, regular investment plans, and redemptions). This example uses fund product SKU configuration as an example to illustrate the practical application of the technical solution in this embodiment. Fund operators can initiate a "XX Hybrid Fund" SKU creation request through the bank sales platform backend, carrying inventory type information "Financial Products - Funds - Hybrid". Based on the inventory type information, the system loads the "Hybrid Fund" SKU package from the configuration center. This SKU package includes: attribute configuration logic: supporting dynamic loading of channel-specific attributes (such as configuring "sales commission rate" for bank channels and "subscription fee rate discount" for internet platforms); verification logic: including necessity rules (such as "fund code" being mandatory) and legality rules (such as "management fee rate" ≤ 2%); and necessary attribute information: including fund code, fund name, risk level, management fee rate, etc.

[0056] Next, the system dynamically generates an initial SKU based on the SKU package, loading only necessary attributes (such as fund code and name) and bank channel-specific attributes (distribution fee rate), while hiding internet platform attributes (subscription fee discount). The initial SKU is then validated based on verification logic, such as legality verification (e.g., if the management fee rate is 1.5% ≤ 2%, legality verification passes) and necessity verification (e.g., if the required fields such as fund code and name are complete, necessity verification passes). Once both verifications pass, the initial SKU is designated as the target SKU usable through bank channels. Furthermore, when the fund product is expanded to be sold on internet platforms, the system receives attribute addition requests, retrieves the target attributes "subscription fee discount" and "minimum investment amount for regular investment," and dynamically adds them to the target SKU, generating a full-featured SKU supporting multi-channel sales.

[0057] This application's embodiment dynamically loads attribute configuration logic based on inventory type information, presenting only attributes strongly relevant to the current business scenario. This avoids the forced exposure of redundant attributes in the traditional full-scale pre-configuration mode, significantly simplifying the user interface and reducing the risk of configuration errors due to attribute overload. Simultaneously, through the synergy of necessary attribute information and verification logic, the system can automatically verify the compliance and completeness of attribute configurations, ensuring that inventory units meet business rule requirements during creation and preventing data rollback or correction in subsequent processes. Furthermore, the dynamic response capability for adding attributes allows for flexible expansion of inventory unit functionality in the later stages of business operations based on actual needs, without refactoring the underlying configuration logic, thus quickly adapting to new business scenarios or promotional activities. This solution decouples inventory unit configuration from business scenarios, significantly improving the agility and efficiency of multi-scenario business operations while ensuring data consistency.

[0058] In some optional implementations of this embodiment, step 203, creating an initial inventory unit for the inventory type based on attribute configuration logic, verification logic, and necessary attribute information, specifically includes the following steps:

[0059] Based on attribute configuration logic and verification logic, a blank inventory unit of the inventory type is created; based on the necessary attribute information, the blank inventory unit is configured with attributes to obtain the initial inventory unit of the inventory type.

[0060] Among them, the blank inventory unit is an initial data container dynamically generated by the system based on the inventory type information. It comes from the initialization call of the attribute configuration logic and verification logic in the SKU package and represents an SKU entity that only contains the structural framework but has not been filled with attribute values.

[0061] Among them, attribute configuration refers to the technical operation of injecting necessary attribute information into blank inventory units. It comes from the attribute configuration logic defined in the SKU package and represents the process of dynamically filling SKU attribute values ​​according to business rules.

[0062] In one example, a business operations staff member initiates a SKU creation request for "Smart Robotic Vacuum Cleaner X100" through the online e-commerce platform backend, carrying the inventory type information "Home Appliances - Smart Cleaning Equipment". Based on the inventory type information, the system loads the "Smart Cleaning Equipment" SKU package from the configuration center. This SKU package includes: attribute configuration logic (supporting dynamic attribute loading by channel, e.g., "Logistics Template" needs to be configured for online channels, and "Store Inventory" needs to be configured for offline channels); verification logic (including necessity rules (e.g., "Model" is mandatory) and validity rules (e.g., "Battery Life" must be a positive number); and necessary attribute information (including model, brand, base price, etc.). Based on the attribute configuration and verification logic, the system generates a blank inventory unit containing only metadata, such as SKU number and creation timestamp, without loading any business attributes. The system then fills in the blank inventory unit with the necessary attribute information (model, brand, etc.) to generate the initial SKU. For example, it fills in attributes such as "Model = X100" and "Brand = Company A", while hiding offline channel-specific attributes (e.g., "Store Inventory"). Next, the logic was used to verify the initial SKU: Validity: The battery life of "120 minutes" was a positive number, so it passed; Necessity: Required fields such as model and brand were complete, so it passed. This was ultimately determined as the target SKU usable on online channels.

[0063] This application's embodiment can create blank inventory units based on attribute configuration and verification logic, achieving lightweight initialization of the SKU structure and avoiding the pre-loading of redundant attributes in traditional static configuration. Subsequently, the blank units are precisely filled with necessary attribute information, ensuring that only attributes strongly relevant to the current business scenario are loaded, preventing unnecessary attributes from interfering with the user interface. Furthermore, real-time intervention of the verification logic ensures the compliance of attribute configuration and avoids data rollback in subsequent processes. This technical feature deeply decouples the SKU configuration process from business scenarios, reducing system resource consumption and configuration error rates, and providing scalable technical support for multi-scenario business operations.

[0064] In some optional implementations, the verification logic includes necessity rules and legality rules. Step S204 involves verifying the initial inventory units based on the verification logic, specifically including the following steps:

[0065] Based on the necessity rule, the necessary attributes required for the initial inventory unit are determined; each attribute of the initial inventory unit is examined item by item to determine whether each attribute of the initial inventory unit contains all the necessary attributes; if it does, the attribute values ​​of each attribute of the initial inventory unit are validated for legality; if the attribute values ​​of each attribute of the initial inventory unit satisfy the legality rule, the validation passes, otherwise the validation fails.

[0066] Among them, the necessity rules originate from the verification logic module in the inventory unit file, representing the mandatory constraints of SKU attribute configuration, and are used to define the set of attributes that an SKU must include in different business scenarios. Its core function is to ensure the integrity of SKU data and avoid business logic errors caused by missing attributes.

[0067] The legality rules are derived from the verification logic module in the inventory unit file. They represent the format, value range, and business logic constraints of SKU attribute values, and are used to ensure that the attribute values ​​comply with system and business rules.

[0068] Among them, the necessary attributes are dynamically parsed and generated by the necessity rules, representing the set of attribute items that the SKU must configure in different business scenarios. They are derived from the synergistic effect of the attribute configuration logic and the necessity rules defined in the inventory unit file.

[0069] Among them, legality verification refers to the technical process of verifying SKU attribute values ​​item by item based on legality rules. It originates from the execution of the verification logic module in the inventory unit file and represents the operation of verifying the format, value range and business logic compliance of attribute values.

[0070] In one example, in the electronics retail sector, SKUs need to be compatible with multiple sales channels (such as online stores and offline stores) and multiple business models (such as regular sales, promotional activities, and pre-sales). This embodiment uses smartphone SKU configuration as an example to illustrate the practical application of the technical solution in this embodiment. After receiving the "Smartphone A100" SKU creation request, the system loads the "Electronic Products" inventory unit file and parses the necessity rules as follows: General necessary attributes: model, brand, base price, inventory quantity; Channel-specific necessary attributes: online channels must include "logistics template", offline channels must include "store inventory"; Business scenario-specific necessary attributes: promotional SKUs must include "promotional price" and "discount effective time". Based on the current channel (online store) and business scenario (regular sales), the system determines the necessary attributes of the current SKU as: model, brand, base price, inventory quantity, and logistics template. The system checks the completeness of the initial SKU's attributes item by item: Check if the "model" attribute exists: exists, value is "A100"; Check if the "brand" attribute exists: exists, value is "Company X"; Check if the "logistics template" attribute exists: exists, value is "standard express". If any required attribute is missing (e.g., "Base Price" is not configured), the validation fails immediately. Next, the complete attribute set is validated for validity: "Base Price" must be a positive number with two decimal places; "Inventory Quantity" must be a non-negative integer; and "Logistics Template" must be a predefined enumerated value (e.g., "Standard Express" or "Next Day Delivery"). Validation results: "Base Price = 2999.00" conforms to the rules; "Inventory Quantity = 500" conforms to the rules; and "Logistics Template = Standard Express" conforms to the rules. If an attribute value is invalid (e.g., "Inventory Quantity = -10"), the validation fails.

[0071] This application's embodiments can dynamically parse the necessary attribute set of the initial SKU based on necessity rules, realizing on-demand attribute loading and avoiding resource waste caused by redundant verification. Item-by-item attribute integrity verification ensures the minimum completeness of SKU data, reducing the data integrity error rate. Legality verification further ensures the business compliance of attribute values, preventing illegal data from entering subsequent processes. Through the synergistic effect of necessity rules and legality rules, highly reliable technical support is provided for multi-scenario business operations.

[0072] In some optional implementations, step S205, when a request to add an attribute of a target inventory unit is received, involves obtaining multiple target attributes, specifically including the following steps:

[0073] When a request to add an attribute for a target inventory unit is received, the attribute addition page for the target inventory unit is displayed, which includes an attribute selection control. When a trigger operation on the attribute selection control is detected, the attribute list is displayed, and in response to an attribute selection operation on the attribute list, multiple target attributes are retrieved.

[0074] The attribute addition page originates from the user interface within the dynamic expansion mechanism of target inventory units, representing a dedicated operation interface for adding attributes during the SKU configuration process. For example, in an e-commerce SKU management system, when a user needs to add a "color variant" attribute to the "Smartphone" SKU, the system provides an entry point for adding the attribute through this page.

[0075] The attribute selection control originates from the interactive component design of the attribute addition page, representing a graphical operation element used to trigger the display of the attribute list. For example, on the SKU attribute addition page, the attribute selection control can be designed as an "Add Attribute" button or a drop-down menu. When the user clicks this control, the system dynamically loads a list of candidate attributes matching the current SKU type.

[0076] The triggering operation originates from the user's interaction with the attribute addition page, representing a specific action performed by the user on the attribute selection control through an input device (such as a mouse or touchscreen). For example, the user clicks the "Add Attribute" button or long-presses the control to trigger a drop-down menu. The system listens for this operation event, dynamically generates an attribute list, and renders it to the page.

[0077] The attribute list originates from the dynamic data display module triggered by the attribute selection control, representing a set of expandable candidate attributes for the current SKU type. For example, on the "Electronic Products" SKU attribute addition page, the attribute list includes predefined attribute items such as "Warranty Period," "Accessories List," and "Energy Efficiency Rating."

[0078] The attribute selection operation originates from the user's interaction with the attribute list, representing the user's action of selecting a target attribute from the candidate attribute set. For example, the user selects attributes such as "packaging specifications" or "storage conditions" from the attribute list by checking, clicking, or swiping. After the system responds to this operation, it marks the selected attribute as the target attribute and prepares to add it to the target SKU.

[0079] In one example, a user initiates a request to add attributes for the "Smartphone X200" through the SKU management backend. Upon receiving the request, the system locates the target SKU and loads its associated attribute addition page. This page contains attribute selection controls (such as an "Add Attribute" button) and a list of existing attributes for the current SKU (such as "Model," "Price," and "Inventory"). When the user clicks an attribute selection control, the system detects the triggered operation and dynamically generates an attribute list based on the SKU type (electronic product) and the current business scenario (online marketplace). For example, it might display the following candidate attributes: Color Variation: Supports multi-color SKU configurations (such as "Black," "Silver"); Accessory Bundles: Bundled sales of headphones, power banks, etc.; Warranty Service: Extended warranty options (such as "2-Year Full Warranty"); Energy Efficiency Rating: Compliant with national energy efficiency standards. The user selects "Color Variation" and "Accessory Bundles" from the attribute list by checking the boxes. The system responds to the attribute selection operation and retrieves the target attribute set.

[0080] In this embodiment, upon receiving an attribute addition request, the system automatically loads the attribute addition page for the target SKU and provides an intuitive extension entry through an attribute selection control, avoiding direct user manipulation of the underlying data. After the operation is triggered, the system dynamically generates an attribute list based on the SKU type, achieving accurate matching of the attribute candidate set. Users can obtain target attributes in batches through attribute selection, allowing the system to add multiple attributes to the SKU in parallel, replacing the redundant process of configuring single attributes one by one in the traditional approach.

[0081] In some optional implementations, step S206, adding multiple target attributes to the target inventory unit to obtain the target inventory unit with the added attributes, specifically includes the following steps:

[0082] Perform attribute conflict detection on multiple target attributes and historical attributes already configured for the target inventory unit; if no attribute conflict exists, add multiple target attributes to the target inventory unit to obtain the target inventory unit with the added attributes.

[0083] Among them, historical attributes are derived from the set of attributes configured in the target inventory unit, representing the attributes and their configuration values ​​that the SKU has stored before the attribute addition request is initiated.

[0084] The attribute conflict detection mechanism originates from the validation phase of the attribute addition process, representing the verification process for the compatibility between the target attribute and historical attributes. Its core function is to ensure the logical consistency of the SKU attribute set. For example, it detects whether the "color variant" attribute conflicts with the historical attribute "single color," or whether the "discount rate" attribute logically contradicts the historical attribute "original price."

[0085] In one example, a user initiates a request to add attributes for "Men's T-shirt (Basic)" through the SKU management system. Upon receiving the request, the system locates the target SKU and loads its configured historical attributes (e.g., "Color = White", "Size = M / L", "Material = 100% Cotton"). The user selects to add the target attributes "Color Variant = Black / Gray" and "Promotional Tag = New Arrival". The system performs conflict detection between the target attributes and historical attributes: Rule 1: If the historical attribute "Color" is configured as a single value (e.g., "White"), the added "Color Variant" must ensure its value is not duplicated with "Color". The system detects that "White" and "Black / Gray" are not duplicated, and determines there is no conflict. Rule 2: If the historical attribute "Material = 100% Cotton", adding "Special Treatment = Waterproof Coating" requires checking material compatibility. Since this example does not involve special treatment attributes, no conflict is triggered. Rule 3: If the historical attribute "Promotional Tag = New Arrival" is configured, adding "Promotional Bundle = Buy One Get One Free" requires checking whether the promotional rules are mutually exclusive. The system determines that the two are logically independent and there is no conflict. After confirming there are no attribute conflicts, the system merges the target attributes into the target SKU, generating expanded SKU data. For example, if the original SKU only supports a single color "white", the expanded version adds "color variant = black / gray" and supports multi-dimensional combinations such as "promotional label = new product" and "promotional bundle = buy one get one free", meeting the online multi-color SKU promotion needs.

[0086] Upon receiving a request to add an attribute, this embodiment automatically cross-validates the target attribute with the historical attributes of the target SKU. Combined with predefined conflict rules in the inventory unit file, it accurately identifies potential contradictions between attributes. This mechanism reduces the SKU attribute configuration error rate, avoids inventory management chaos caused by attribute conflicts (such as duplicate promotions and invalid categories), and supports the secure reuse of the same SKU template in multiple business scenarios, improving system development efficiency.

[0087] In some optional implementations, the step "Perform attribute conflict detection on multiple target attributes and historical attributes configured for target inventory units" specifically includes the following steps:

[0088] Obtain attribute conflict rules from the inventory unit file; based on the attribute conflict rules, determine whether there are attribute conflicts between each target attribute and between each target attribute and historical attributes.

[0089] The attribute conflict rules are derived from a predefined set of rules in the inventory unit file, representing a set of rules for determining whether there are logical contradictions or data duplications between attributes. For example, it may stipulate that the attributes "color" and "pattern" must be mutually exclusive (because some products require a choice between color and pattern). The system uses this rule to determine whether there is a conflict between the target attribute and historical attributes.

[0090] In one example, a user initiates a request to add attributes for a "smartphone (flagship model)" through the SKU management system. The system loads the historical attributes already configured for the target SKU (such as "Model = X100", "Color = Starry Black", "Warranty Period = 1 Year", "Inventory Quantity = 100 Units"). The user selects to add the target attributes "Package Combination = Headphones + Power Bank" and "Extended Warranty Service = 2 Years". The system loads the following conflict rules from the inventory unit file: Rule 1: If "Warranty Period" is already configured in the historical attributes, adding "Extended Warranty Service" requires checking whether its value is greater than the historical attribute value (e.g., when "Warranty Period = 1 year", the optional value range for "Extended Warranty Service" is "1 year / 2 years / 3 years"); Rule 2: If "Sales Mode = Single Unit Sales" is in the historical attributes, adding "Package Combination" requires checking whether it is mutually exclusive with the historical attributes (e.g., when "Package Combination" needs to be configured with "Multi-device Bundling", it needs to conflict with the logic of "Single Unit Sales"); Rule 3: If the value range of the newly added attribute "Color Variant" overlaps with the historical attribute "Color" (e.g., "Color = Starry Sky Black" and "Color Variant = Starry Sky Black / Moonlight White"), the system needs to determine whether to allow expansion (in this example, "Color" and "Color Variant" can coexist, but it must be ensured that the values ​​are not repeated). The system performs cross-validation of target and historical attributes based on conflict rules in the inventory unit file: Validation result 1: The historical attribute "Warranty period = 1 year" and the newly added attribute "Extended warranty service = 2 years" comply with rule 1 (value range compatibility) and have no conflict; Validation result 2: The historical attribute "Sales mode = Single unit sale" and the newly added attribute "Package combination = Mobile phone + Headphones" comply with rule 2 (multiple sales modes can be configured) and have no conflict; Validation result 3: The newly added attribute "Color variant = Starry Black / Moonlight Silver" and the historical attribute "Color = Starry Black" comply with rule 3 (values ​​are not repeated) and have no conflict. After confirming no attribute conflicts, the system merges the target attribute into the target SKU, generating expanded SKU data. For example, the original SKU only supports a single color "Starry Black" and "1-year warranty period," while the expanded version adds "Color variant = Moonlight Silver," "Package combination," and "Extended warranty service = 2 years," enabling multi-dimensional attribute configuration and meeting the needs of multiple online and offline scenarios.

[0091] This application embodiment can extract predefined conflict rules from the inventory unit file after receiving an attribute addition request, and cross-validate the target attribute with historical attributes based on the rules. Through this mechanism, the system can intercept invalid attribute combinations in real time, avoid logical contradictions caused by human configuration oversights, and reduce the SKU attribute configuration error rate.

[0092] In some optional implementations, after the step "Perform attribute conflict detection on multiple target attributes and historical attributes configured for target inventory units", the following steps are also included:

[0093] If an attribute conflict exists, attribute conflict information is sent to the processing terminal to correct multiple target attributes based on the attribute conflict information.

[0094] In this context, the processing terminal refers to the device (such as a PC or mobile terminal) or system that receives attribute conflict information and performs correction operations. For example, an administrator's computer terminal or mobile device.

[0095] Among them, the attribute conflict information comes from the output of the attribute conflict detection and represents the specific type and location of the attribute conflict. For example, when a new "accessory combination" attribute is added, if a "bundled product" already exists in the historical attributes and the two are logically conflicting (such as both pointing to the same accessory), the attribute conflict information generated by the system will clearly indicate the conflicting attribute and the rule basis.

[0096] In one example, a user initiates a request to add attributes for "Air Conditioner (Energy Saving Model)" through the SKU management system. The system loads the historical attributes already configured for the target SKU (such as "Model Number").

[0097] =KFR-35GW", "Color = White", "Warranty Period = 1 Year", "Sales Mode = Single Unit Sale") The user selects to add the target attributes "Package Combination = Air Conditioner + Installation Service" and "Extended Warranty Service = 3 Years". The system performs attribute conflict detection and finds the following conflicts: Conflict 1: The historical attribute "Sales Mode = Single Unit Sale" and the newly added attribute "Package Combination" are logically mutually exclusive because "Package Combination" requires the "Multi-device Bundling" mode to be configured; Conflict 2: The historical attribute "Warranty Period = 1 Year" and the newly added attribute "Extended Warranty Service = 3 Years" have conflicting value ranges because the inventory unit document stipulates that the maximum value of "Extended Warranty Service" cannot exceed "Warranty Period + 2 Years" (i.e., the maximum value is 3 years, but it needs to be verified whether it is logically compatible with the historical attribute). After the system determines that there are attribute conflicts, The system sends conflict information to the processing terminal, which may include: conflict type (logical mutual exclusion / value domain contradiction); conflict attribute pairs ("sales mode" and "package combination", "warranty period" and "extended warranty service"); and correction suggestions (such as "change 'sales mode' to 'package sales'" and "adjust 'extended warranty service' to '2 years'"). Users correct the target attributes based on the conflict information (e.g., change "sales mode" to "package sales" and adjust "extended warranty service" to "2 years"). After the system re-verifies and passes the verification, the corrected attributes are merged into the target SKU, generating expanded SKU data. For example, if the original SKU only supports "single unit sales" and "1-year warranty period", the correction adds "package combination" and "extended warranty service = 2 years" to meet the needs of multiple online and offline scenarios.

[0098] In this embodiment, when the system detects a conflict between a target attribute and historical attributes, it sends detailed information to the processing terminal, including the conflict type, the conflicting attribute pair, and correction suggestions, thereby guiding the user to quickly locate the root cause of the problem. Standardized feedback of conflict information reduces the user's understanding cost, supports non-technical personnel to independently complete attribute corrections, and achieves automated error correction and efficient iteration of SKU attribute expansion.

[0099] It should be emphasized that, in order to further ensure the privacy and security of the aforementioned inventory type information, attribute configuration logic, verification logic, necessary attribute information, and multiple target attributes, the aforementioned inventory type information, attribute configuration logic, verification logic, necessary attribute information, and multiple target attributes can also be stored in a blockchain node.

[0100] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0102] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0103] Further reference Figure 3 As a response to the above Figure 2The implementation of the method shown in this application provides an embodiment of an attribute-adding device for inventory units, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0104] like Figure 4 As shown, the inventory unit attribute adding device 400 of this embodiment includes: a first receiving module 401, an acquisition module 402, a creation module 403, a verification module 404, a second receiving module 405, and an adding module 406. Wherein:

[0105] The first receiving module 401 is used to receive an inventory unit creation request, which carries inventory type information.

[0106] The acquisition module 402 is used to acquire the inventory unit file of the inventory type indicated by the inventory type information based on the inventory type information. The inventory unit file includes attribute configuration logic, verification logic and necessary attribute information.

[0107] Create module 403 to create the initial inventory unit of the inventory type based on attribute configuration logic, verification logic and necessary attribute information;

[0108] The inspection module 404 is used to inspect the initial inventory unit based on the inspection logic. If the inspection passes, the initial inventory unit is determined as the target inventory unit.

[0109] The second receiving module 405 is used to obtain multiple target attributes when it receives a request to add attributes of a target inventory unit;

[0110] Add module 406 to add multiple target attributes to the target inventory unit and obtain the target inventory unit after the attributes are added.

[0111] In this embodiment, attribute configuration logic is dynamically loaded based on inventory type information, presenting only attributes strongly relevant to the current business scenario. This avoids the forced exposure of redundant attributes in the traditional full-scale pre-configuration mode, significantly simplifying the user interface and reducing the risk of configuration errors due to attribute overload. Simultaneously, through the synergy of necessary attribute information and verification logic, the system can automatically verify the compliance and completeness of attribute configurations, ensuring that inventory units meet business rule requirements during creation and preventing data rollback or correction in subsequent processes. Furthermore, the dynamic response capability for adding attributes allows for flexible expansion of inventory unit functionality in the later stages of business operations based on actual needs, without refactoring the underlying configuration logic, thus quickly adapting to new business scenarios or promotional activities. This solution decouples inventory unit configuration from business scenarios, significantly improving the agility and efficiency of multi-scenario business operations while ensuring data consistency.

[0112] In one embodiment, the creation module 403 includes:

[0113] Create a submodule to create blank inventory units of inventory types based on attribute configuration logic and verification logic;

[0114] The configuration submodule is used to configure the attributes of blank inventory units based on necessary attribute information to obtain the initial inventory units of the inventory type.

[0115] This application's embodiment can create blank inventory units based on attribute configuration and verification logic, achieving lightweight initialization of the SKU structure and avoiding the pre-loading of redundant attributes in traditional static configuration. Subsequently, the blank units are precisely filled with necessary attribute information, ensuring that only attributes strongly relevant to the current business scenario are loaded, preventing unnecessary attributes from interfering with the user interface. Furthermore, real-time intervention of the verification logic ensures the compliance of attribute configuration and avoids data rollback in subsequent processes. This technical feature deeply decouples the SKU configuration process from business scenarios, reducing system resource consumption and configuration error rates, and providing scalable technical support for multi-scenario business operations.

[0116] In one embodiment, the inspection module 404 includes:

[0117] The determination submodule is used to determine the necessary attributes required for the initial inventory unit based on necessity rules;

[0118] The judgment submodule is used to check each attribute of the initial inventory unit one by one to determine whether each attribute of the initial inventory unit contains all the necessary attributes.

[0119] The validation submodule, if included, performs validity validation on the attribute values ​​of each attribute of the initial inventory unit.

[0120] The "satisfaction" submodule is used to ensure that if the attribute values ​​of each attribute of the initial inventory unit meet the validity rules, the verification passes; otherwise, the verification fails.

[0121] This application's embodiments can dynamically parse the necessary attribute set of the initial SKU based on necessity rules, realizing on-demand attribute loading and avoiding resource waste caused by redundant verification. Item-by-item attribute integrity verification ensures the minimum completeness of SKU data, reducing the data integrity error rate. Legality verification further ensures the business compliance of attribute values, preventing illegal data from entering subsequent processes. Through the synergistic effect of necessity rules and legality rules, highly reliable technical support is provided for multi-scenario business operations.

[0122] In one embodiment, the second receiving module 405 includes:

[0123] The page display submodule is used to display the attribute addition page for the target inventory unit when a request to add an attribute for the target inventory unit is received. The attribute addition page includes an attribute selection control.

[0124] The list display submodule is used to display a list of properties when a trigger operation is detected for the property selection control, and to retrieve multiple target properties in response to a property selection operation for the property list.

[0125] In this embodiment, upon receiving an attribute addition request, the system automatically loads the attribute addition page for the target SKU and provides an intuitive extension entry through an attribute selection control, avoiding direct user manipulation of the underlying data. After the operation is triggered, the system dynamically generates an attribute list based on the SKU type, achieving accurate matching of the attribute candidate set. Users can obtain target attributes in batches through attribute selection, allowing the system to add multiple attributes to the SKU in parallel, replacing the redundant process of configuring single attributes one by one in the traditional approach.

[0126] In one embodiment, module 406 is added, including:

[0127] The detection submodule is used to perform attribute conflict detection on multiple target attributes and historical attributes configured for target inventory units;

[0128] Add a submodule to add multiple target attributes to the target inventory unit if there are no attribute conflicts, and obtain the target inventory unit after the attributes are added.

[0129] Upon receiving a request to add an attribute, this embodiment automatically cross-validates the target attribute with the historical attributes of the target SKU. Combined with predefined conflict rules in the inventory unit file, it accurately identifies potential contradictions between attributes. This mechanism reduces the SKU attribute configuration error rate, avoids inventory management chaos caused by attribute conflicts (such as duplicate promotions and invalid categories), and supports the secure reuse of the same SKU template in multiple business scenarios, improving system development efficiency.

[0130] In one embodiment, the detection submodule is further configured to obtain attribute conflict rules from the inventory unit file; and based on the attribute conflict rules, determine whether there are attribute conflicts between each target attribute and between each target attribute and historical attributes.

[0131] This application embodiment can extract predefined conflict rules from the inventory unit file after receiving an attribute addition request, and cross-validate the target attribute with historical attributes based on the rules. Through this mechanism, the system can intercept invalid attribute combinations in real time, avoid logical contradictions caused by human configuration oversights, and reduce the SKU attribute configuration error rate.

[0132] In one embodiment, the detection submodule is further configured to send attribute conflict information to the processing terminal if an attribute conflict exists, so as to correct multiple target attributes based on the attribute conflict information.

[0133] In this embodiment, when the system detects a conflict between a target attribute and historical attributes, it sends detailed information to the processing terminal, including the conflict type, the conflicting attribute pair, and correction suggestions, thereby guiding the user to quickly locate the root cause of the problem. Standardized feedback of conflict information reduces the user's understanding cost, supports non-technical personnel to independently complete attribute corrections, and achieves automated error correction and efficient iteration of SKU attribute expansion.

[0134] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0135] Computer device 4 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0136] Computer devices can include desktop computers, laptops, handheld computers, and cloud servers. These devices allow for human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0137] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may also include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for adding attributes of inventory units. In addition, the memory 61 may also be used to temporarily store various types of data that have been output or will be output.

[0138] In some embodiments, processor 62 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. This processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, processor 62 is used to execute computer-readable instructions stored in memory 61 or to process data, such as computer-readable instructions for executing a method to add attributes to inventory units.

[0139] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 6 and other electronic devices.

[0140] This application's embodiment dynamically loads attribute configuration logic based on inventory type information, presenting only attributes strongly relevant to the current business scenario. This avoids the forced exposure of redundant attributes in the traditional full-scale pre-configuration mode, significantly simplifying the user interface and reducing the risk of configuration errors due to attribute overload. Simultaneously, through the synergy of necessary attribute information and verification logic, the system can automatically verify the compliance and completeness of attribute configurations, ensuring that inventory units meet business rule requirements during creation and preventing data rollback or correction in subsequent processes. Furthermore, the dynamic response capability for adding attributes allows for flexible expansion of inventory unit functionality in the later stages of business operations based on actual needs, without refactoring the underlying configuration logic, thus quickly adapting to new business scenarios or promotional activities. This solution decouples inventory unit configuration from business scenarios, significantly improving the agility and efficiency of multi-scenario business operations while ensuring data consistency.

[0141] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the above-described method for adding attributes to inventory units.

[0142] This application's embodiment dynamically loads attribute configuration logic based on inventory type information, presenting only attributes strongly relevant to the current business scenario. This avoids the forced exposure of redundant attributes in the traditional full-scale pre-configuration mode, significantly simplifying the user interface and reducing the risk of configuration errors due to attribute overload. Simultaneously, through the synergy of necessary attribute information and verification logic, the system can automatically verify the compliance and completeness of attribute configurations, ensuring that inventory units meet business rule requirements during creation and preventing data rollback or correction in subsequent processes. Furthermore, the dynamic response capability for adding attributes allows for flexible expansion of inventory unit functionality in the later stages of business operations based on actual needs, without refactoring the underlying configuration logic, thus quickly adapting to new business scenarios or promotional activities. This solution decouples inventory unit configuration from business scenarios, significantly improving the agility and efficiency of multi-scenario business operations while ensuring data consistency.

[0143] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of this application.

[0144] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

[0145] The software tools or components not belonging to our company that appear in the embodiments of this application are merely examples and do not represent actual use.

Claims

1. A method for adding attributes to inventory units, characterized in that, Includes the following steps: Receive an inventory unit creation request, the inventory unit creation request carrying inventory type information; Based on the inventory type information, obtain the inventory unit file of the inventory type indicated by the inventory type information, wherein the inventory unit file includes attribute configuration logic, verification logic, and necessary attribute information; Based on the attribute configuration logic, the verification logic, and the necessary attribute information, an initial inventory unit for the inventory type is created. Based on the aforementioned verification logic, the initial inventory unit is verified. If the verification passes, the initial inventory unit is determined as the target inventory unit. When a request to add attributes for the target inventory unit is received, multiple target attributes are obtained; Add the multiple target attributes to the target inventory unit to obtain the target inventory unit with the added attributes.

2. The method according to claim 1, characterized in that, The step of creating the initial inventory unit of the inventory type based on the attribute configuration logic, the verification logic, and the necessary attribute information specifically includes: Based on the attribute configuration logic and the verification logic, a blank inventory unit of the inventory type is created; Based on the necessary attribute information, the blank inventory unit is configured with attributes to obtain the initial inventory unit of the inventory type.

3. The method according to claim 1, characterized in that, The verification logic includes necessity rules and legality rules; The step of verifying the initial inventory unit based on the verification logic specifically includes: Based on the aforementioned necessity rules, the necessary attributes required for the initial inventory unit are determined; Each attribute of the initial inventory unit is examined item by item to determine whether each attribute of the initial inventory unit contains all the necessary attributes; If included, the attribute values ​​of each attribute of the initial inventory unit are validated for legality. If the attribute values ​​of each attribute of the initial inventory unit satisfy the validity rules, the verification passes; otherwise, the verification fails.

4. The method according to claim 1, characterized in that, The step of obtaining multiple target attributes when receiving a request to add attributes for the target inventory unit specifically includes: When a request to add attributes for the target inventory unit is received, an attribute addition page for the target inventory unit is displayed, the attribute addition page including an attribute selection control; When a trigger operation is detected for the attribute selection control, an attribute list is displayed, and in response to an attribute selection operation for the attribute list, multiple target attributes are obtained.

5. The method according to claim 1, characterized in that, The step of adding the multiple target attributes to the target inventory unit to obtain the target inventory unit after attribute addition specifically includes: Perform attribute conflict detection on the multiple target attributes and the historical attributes configured for the target inventory unit; If there are no attribute conflicts, the multiple target attributes are added to the target inventory unit to obtain the target inventory unit with the added attributes.

6. The method according to claim 5, characterized in that, The step of performing attribute conflict detection on the multiple target attributes and the historical attributes configured for the target inventory unit specifically includes: Obtain attribute conflict rules from the inventory unit file; Based on the attribute conflict rules, it is determined whether there are attribute conflicts between each target attribute and between each target attribute and historical attributes.

7. The method according to claim 5, characterized in that, Following the step of performing attribute conflict detection on the plurality of target attributes and the historical attributes configured for the target inventory unit, the method further includes: If an attribute conflict exists, attribute conflict information is sent to the processing terminal to correct the multiple target attributes based on the attribute conflict information.

8. A device for adding attributes to inventory units, characterized in that, include: The first receiving module is used to receive an inventory unit creation request, wherein the inventory unit creation request carries inventory type information. The acquisition module is used to acquire, based on the inventory type information, an inventory unit file for the inventory type indicated by the inventory type information, wherein the inventory unit file includes attribute configuration logic, verification logic, and necessary attribute information; A creation module is used to create an initial inventory unit for the inventory type based on the attribute configuration logic, the verification logic, and the necessary attribute information. The inspection module is used to inspect the initial inventory unit based on the inspection logic. If the inspection passes, the initial inventory unit is determined as the target inventory unit. The second receiving module is used to obtain multiple target attributes when it receives a request to add attributes to the target inventory unit; An add module is used to add the multiple target attributes to the target inventory unit, resulting in the target inventory unit with the added attributes.

9. A computer device, characterized in that, It includes a memory and a processor, the memory storing computer-readable instructions, and the processor executing the computer-readable instructions to implement the steps of the method for adding attributes to inventory units as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, implement the steps of the method for adding attributes to an inventory unit as described in any one of claims 1 to 7.

Images