WO2016169429A1 - 物流资源协同关系信息处理方法及装置 - Google Patents

物流资源协同关系信息处理方法及装置 Download PDF

Info

Publication number
WO2016169429A1
WO2016169429A1 PCT/CN2016/079229 CN2016079229W WO2016169429A1 WO 2016169429 A1 WO2016169429 A1 WO 2016169429A1 CN 2016079229 W CN2016079229 W CN 2016079229W WO 2016169429 A1 WO2016169429 A1 WO 2016169429A1
Authority
WO
WIPO (PCT)
Prior art keywords
relationship
type
collaborative
database table
variable
Prior art date
Application number
PCT/CN2016/079229
Other languages
English (en)
French (fr)
Inventor
陈岳阳
王远
康军卫
丁德兵
姜浩
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2016169429A1 publication Critical patent/WO2016169429A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management

Definitions

  • the present application relates to the field of logistics information processing technology, and in particular, to a logistics resource coordination relationship information processing method and apparatus.
  • the types of goods can relate to people's daily life. All aspects of the product, including household appliances, furniture and other categories of goods. For such products, due to their large size, heavy weight, and easy damage, how to store and distribute goods is a key issue.
  • some electric city merchants of e-commerce platforms can place their household appliances in the warehouse provided by the platform (for example, the second type of warehouse resources, that is, the household warehouse, each warehouse With its own distribution coverage, the warehouse provided by the platform generally includes multiple warehouses distributed in different physical locations, such as Beijing warehouse, Hangzhou warehouse, Shanghai warehouse, and so on.
  • merchants may also have their own logistics resources, such as self-built warehouses, etc.
  • a merchant may use both the warehouse provided by the platform and its own warehouse (for the convenience of description, the warehouse provided by the platform is called the second type. "Warehouse resources", the merchant's own warehouse is called “first type of warehouse resources"), and so on.
  • some trading platforms will introduce the platform supply chain, from sales forecasting to procurement planning, to warehousing planning, to Transfer the plan, complete the final plan execution, and so on.
  • the multi-party collaboration is more complicated, for example, the distribution ratio of a certain supplier's goods in each second type of warehouse resources, and the fact that a certain supplier's goods are in a warehouse of the second type of warehouse resources.
  • the plan is determined through a series of complex synergies, which bring complexity to the system design.
  • the merchant After selecting a Shenzhen warehouse and a Dongguan warehouse for a certain product, the merchant generally prepares the goods in each warehouse according to a pre-established sales plan in various places.
  • Dongguan is closer to Shenzhen, and Dongguan warehouse can complete the replenishment to Shenzhen warehouse within one day. Therefore, if the warehouse resources of this relationship can be more reasonable The utilization will increase the utilization of resources and avoid the problems of inventory backlog caused by excessive replenishment of a warehouse.
  • the platform supply chain needs to provide a plan collaboration plan for the merchants, and the essence of the plan synergy is based on the underlying data and multi-party collaborative rules to form a final implementation plan.
  • each business scenario will have its own basic data and multi-party coordination rules.
  • the basic data includes: C2B futures deposit order, inventory distribution of the second type of warehouse resources of commodities.
  • the collaborative relationship includes: a sinking relationship between the second type of warehouse resources (such as sinking from the A warehouse to the B warehouse), a storage capacity area that the supplier can use in the second type of warehouse resources, and the supplier's The proportion of the goods in the second type of warehouse resources, etc.
  • Business scenario 2 Developed a multi-level warehouse supply chain solution.
  • the basic data includes: sales forecast data, current inventory in various distribution data, etc.;
  • the synergy relationship includes: the distribution ratio relationship of a certain commodity between two warehouses, the storage capacity area that the supplier can use in the second type of warehouse resource, and the commodity of the supplier in the second type warehouse The stock ratio of resources and so on.
  • the application provides a logistics resource coordination relationship information processing method and device, which can improve the scalability of the system.
  • a logistics resource collaborative relationship information processing method pre-defining a collaborative relationship represented by the following metadata: a collaborative relationship type, an associated relationship variable type, and an associated collaborative subject type; the relationship variable is used to express synergistic Content, the collaborative subject is a participant of the collaborative relationship;
  • the method includes:
  • the instantiated data includes a relationship variable value and a collaborative subject value.
  • a logistics resource collaborative relationship information processing device pre-defining a collaborative relationship, the collaborative relationship being represented by the following metadata: a collaborative relationship type, an associated relationship variable type, and an associated collaborative subject type; the relationship variable is used to express synergistic Content, the collaborative subject is a participant of the collaborative relationship;
  • the device includes:
  • a type information providing unit configured to provide the defined collaborative relationship type information
  • the receiving unit is configured to receive the type of the target collaborative relationship selected by the user, and the instantiated data submitted for the target collaborative relationship, and save the data in the form of a database table; the instantiated data includes a relationship variable value and a collaborative subject value.
  • the present application discloses the following technical effects:
  • a configurable model based on metadata can be constructed.
  • the base code part does not need to be modified, nor does it need to publish a new program, thus improving the scalability of the system.
  • it is also able to support the expression of complex synergistic relationships.
  • FIG. 2 is a schematic diagram of an index model provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram of another index model provided by an embodiment of the present application.
  • FIG. 4 is a schematic diagram of still another index model provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of an apparatus provided by an embodiment of the present application.
  • the core domain model of the platform supply chain planning system in the embodiment of the present application may be constructed as:
  • a set of models is abstracted for the scenario of supply chain collaboration, and the model can be extended by data initialization to express various synergistic relationships in a consistent manner.
  • the model can be extended by data initialization to express various synergistic relationships in a consistent manner.
  • the embodiment of the present application can construct a scalable platform supply chain planning system, wherein the collaborative relationship expression is a core module of the system.
  • the collaborative relationship expression is a core module of the system.
  • the merchant can instantiate the synergy according to their own needs and characteristics of the goods.
  • these instantiated data can be used as the basis for execution of various plan execution engines, used by the scheduled execution engine, and provide data support for the decision of the execution engine.
  • Collaborative relationship type It can be understood as a collaborative context. Why do participants in multiple supply chains need to work together to solve a business problem? For example, multiple suppliers need to use a certain warehouse, but the available area of the warehouse is certain, so multiple suppliers have a competitive relationship with the use of a certain warehouse, which is a kind of synergy.
  • the collaborative relationship in the above example can be named as: "compartment area competition synergy”. It is a type of synergy.
  • Collaborative relationship variable type The relationship variable expresses the synergy between the collaborative subject and the collaborative participant (non-subject) in the collaborative scenario. Still taking the above area competition synergy as an example, the area of the warehouse expresses the synergy between the collaborators, so the warehouse area is the synergistic relationship variable. It is called a variable because it is not a fixed value. Different warehouses can be used by different businesses. The same warehouse, at different times. The area of use that can be provided is also different, so the available area of the warehouse is a synergistic variable.
  • various synergistic relationships can be expressed by a combination of the above several key elements, which is the essence of the synergistic relationship, and therefore, the above key elements can be used as metadata of various synergistic relationships.
  • metadata After abstracting the above metadata, it can be used to express various synergistic relationships.
  • how many kinds of synergies the system supports can be configured by the programmer, that is, the designer of the system.
  • the initialization of this data can be defined as the design period or the definition period, and then each merchant can be based on the already defined synergy relationship. Instantiate the data.
  • the developer of the system defines a matching relationship between the first type of warehouse resource and the second type of warehouse resource on the inventory allocation of a certain commodity based on the model, but specifically which merchant and which second type warehouse Resources, which products are not known at this stage, can be instantiated, each merchant can set the ratio between different first type warehouse resources and second type warehouse resources according to their own products. relationship.
  • the expression of the synergy can be divided into two phases: the definition phase and the instantiation phase.
  • the definition stage the synergy relationship can be described from the level of the type. Take the warehouse coordination as an example. At this time, only the warehouse and the distribution have a synergistic relationship, but which one is associated with which one, and the definition is not reflected. This needs to be done in the instantiation phase.
  • modeling can be performed through four database tables (because the collaborative principal type may appear multiple times in multiple collaborative relationship definitions). Therefore, the collaborative principal type is separately modeled, respectively, referred to as a first database table, a second database table, a third database table, and a fourth database table, wherein the first database table is used to define the relationship type information, and the second The database table is used to define the collaborative body type information, the third database table is used to define the relationship variable type information associated with each collaborative relationship type, and the fourth database table is used to define the collaborative body type information associated with each collaborative relationship type.
  • the structure of the first database table can be as shown in Table 1 below:
  • Relationship type ID (relation_type_id) relationship name (relation_name) relationship type name (relation_type) relationship type description
  • the number of entries is determined by the number of defined collaborative relationships. In general, How many kinds of synergies are defined, how many entries are saved in the first database table, and when a new collaboration relationship is needed, an entry is added to the first database table to describe the newly added Type information for system relationships.
  • the synergy type information can be expressed by the relationship type ID, the relationship type name, and the like.
  • the collaborative relationship type information can also be expressed in other ways.
  • the structure of the second database table can be as shown in Table 2 below:
  • Body type ID (participant_type_id)
  • the second database table is a global table and can be used for various possibilities.
  • the execution entity is listed in the second database table.
  • a specific collaborative entity can be expressed by referring to the record in the second database table.
  • the collaborative subject type information can be expressed by the subject type ID, the subject type name, and the like. Of course, in practical applications, the collaborative subject type information can also be expressed in other ways.
  • the structure of the third database table can be as shown in Table 3 below:
  • a collaborative relationship may correspond to one or more entries in the second database table.
  • the collaborative relationship with the relationship type ID of 1 corresponds to two relational variables named 1 and 2.
  • the relationship variable type information in the third database table may include the variable type ID and the variable type name, etc. Similarly, in practical applications, the relationship variable type information may also be expressed in other ways.
  • the structure of the third database table can be as shown in Table 4 below:
  • Body type ID reference (participant_type_
  • the collaborative principal established in the second database table is a global collaborative principal, so it is also possible to associate the collaborative principal with a specific collaborative relationship. Similar to the third database table, each time a type of collaborative relationship is defined, a new entry can be added in the fourth database table to describe the collaborative body of the collaborative relationship, wherein a collaborative relationship generally involves more A collaborative entity, therefore, in the fourth database table, the same collaborative relationship may correspond to multiple data entries, respectively, for describing various collaborative entities in the collaborative relationship.
  • the collaborative body type information in the fourth database table may be represented by referring to the body type ID in the second database table, and the collaborative relationship type information may be referred to by the relationship type ID of the first database. Form to represent.
  • the fourth database table can also define the retrieval order of various collaborative subjects under the same collaborative relationship, and is used for the establishment of the subsequent index model. This part will be described in detail later.
  • the home appliance system adopts the unified warehouse allocation mode, that is, the front-end saleable inventory and the back-end second-type warehouse resource physical inventory are bound, and the merchant goods do not enter the first Before the second type of warehouse resource, the front end shows that it is not for sale.
  • the replenishment period is about 1-2 days. Therefore, a feasible way of controlling goods is for this type of goods.
  • some of the goods are placed in their own first type of warehouse resources for sale, so that some non-selling goods merchants can replenish the second type of warehouse resources with less than the sales forecast inventory, which can ensure that there is no shortage of goods, and It can avoid the inventory backlog caused by overfilling the second type of warehouse resources.
  • the synergistic relationship can be first defined in the system.
  • the first step is to register this synergy in the first database table, as shown in Table 5 below:
  • Relationship type ID (relation_type_id) relationship name (relation_name) relationship type name (relation_type) relationship type description
  • a collaborative relationship variable is defined in the third database table.
  • the relationship variable type includes the sales ratio of the first type of warehouse resource to the second type of warehouse resource, as shown in Table 6 below:
  • the ratio of the first type of warehouse resource to the sales volume of a second type of warehouse resource for example, a value of 0.5 means that half of the goods are stored in the first type of warehouse resource Float
  • Body type ID reference (participant_type_
  • an embodiment of the present application provides a method for processing logistics resource coordination relationship information, which may include the following steps:
  • various defined collaborative relationship information may be published through an online system. For example, information such as names of various collaborative relationships may be displayed in a user interface through a list or the like, and A description of information such as the role of various synergistic relationships can be provided. This way, merchants can view various Synergistic relationship type information, combined with your own needs, select one or some of the synergistic relationships for instantiation.
  • S102 Receive a type of the target collaborative relationship selected by the user, and the instantiated data submitted for the target collaborative relationship, and save the data in a form of a database table; the instantiated data includes a relationship variable value and a collaborative subject value;
  • the user here mainly refers to the merchant user or the seller user.
  • the article is described as “merchant”.
  • the system may provide the collaborative subject type and the relationship variable type associated with the type of the collaborative relationship to the merchant, for example, in the case of defining the collaborative relationship according to the foregoing database tables.
  • the system may query the foregoing table 3 according to the type of the collaborative relationship, determine the type of the relationship variable associated with the type of the collaborative relationship, query the foregoing Table 4 and Table 2, and determine the type of the collaborative subject associated with the type of the collaborative relationship,
  • the merchant can fill in the specific instantiation data and submit, wherein the instantiated data includes the relationship variable value and the collaborative subject value.
  • the instantiated data submitted by the merchant when the instantiated data submitted by the merchant is received, it can still be saved in the form of a database table.
  • the collaborative relationship type, the collaborative subject value, and the relationship variable value can still be saved in different database tables.
  • a fifth database table may be provided, which is used to save the type of the target collaborative relationship selected by the user, and provides a sixth database table, which is used to save the subject type identifier and the collaborative subject value of the target collaborative relationship, and provides a seventh database table, and saves the target.
  • a plurality of entries are saved in Table 8 above, and each time a merchant selects a type of collaborative relationship for instantiation, an entry is added to the table 8.
  • the collaborative relationship type id referenced therein is determined according to the records in Table 1, that is, the type of the target collaborative relationship in the fifth database table is represented by referring to the relationship type ID in the first database table.
  • the collaborative principal of the target collaborative relationship may be instantiated, which may be saved in Table 9 below:
  • the product HP_01 whose supplier is identified as GYS_01 needs to use a synergy relationship with type id 1 between the first type of warehouse resource SJC_01 and the second type of warehouse resource RRSC_01.
  • the body type identifier in the sixth database table may be represented by referring to the body type ID in the second database table, and the relationship id refers to the record in the fifth relationship table.
  • the collaborative relationship variable can also be instantiated. Specifically, it can be saved in the form of Table 10 below:
  • variable type identifier in the seventh database table may be represented by referring to a variable type ID in the third database table.
  • the above models the real collaborative business scenarios, and save the corresponding values in the form of database tables to complete the instantiation of the model.
  • various execution engines in the system can retrieve the instantiation data to provide a basis for specific decisions.
  • there may be more than one planning engine for example, including the C2B futures deposit order to determine the replenishment and transfer planning engine of the merchant, the warehousing and transfer planning engine based on the rookie warehouse system for the general logistics solution of the merchant, based on the rookie The planning engine of the logistics system of the warehouse system and the first type of warehouse resource system, the planning engine for replenishing the rookie warehouse system based on the first type of warehouse resource system, and the like.
  • S103 Establish an index of the instantiated data corresponding to the target collaborative relationship based on the Key-Value model, and load the index into the cache, where the key is established by combining the type of the target collaborative relationship with the associated collaborative subject value to associate the relationship variable The value is Value, so that the execution engine retrieves the instantiation through the index when performing the plan collaboration The value of the relationship variable in the data.
  • the definition of the collaborative relationship and the instantiated data can be written into the cache after the system is started and a new collaborative relationship is saved, so that the execution engine can
  • the specific synergistic data is read from the cache without having to read and write the database every time, which can improve the processing efficiency.
  • the execution time of loading the data in the database table into the cache may be various, for example, it may be loaded at system startup, or may be reloaded when a new collaborative relationship is established in the system, etc. .
  • the embodiment of the present application may also convert the collaborative relationship stored in the database table into a stored expression based on the key-value mode, wherein Key is established by combining the type of the target collaborative relationship with the associated collaborative subject value, and the associated relationship variable value is Value.
  • the retrieval model can be as shown in FIG. 2 . In this way, when the execution engine performs the plan collaboration, the index value of the instantiation data in the instantiated data can be retrieved through the index, thereby providing a basis for the specific execution.
  • Step 1 Search the fifth database table to determine the type of the target collaborative relationship
  • Step 2 Retrieving the sixth database table according to the type of the target collaborative relationship, and determining the collaborative entity value corresponding to the target collaborative relationship;
  • Step 3 Combine the type of the target collaborative relationship and the collaborative subject value into a Key
  • the step 3 may specifically include:
  • each subject type id is a collaborative body of 1, 2, 3, and 4, and the search order is 1, 2, 3, and 4, respectively, and when the key in the search model is combined, the subject can be followed.
  • the order in which the type id is 1, 2, 3, 4 is sorted.
  • Step 4 Retrieving the seventh database table, determining the variable type ID and the relationship variable value corresponding to the target collaboration relationship;
  • Step 5 Retrieving the third database table according to the variable type ID, and determining a variable corresponding to the relationship type ID type name;
  • Step 6 Combine the variable type name and the relationship variable value into Value.
  • the KV retrieval model based on the collaborative relationship stored in the database table is given above, and how to retrieve the actual retrieval image based on the data of the definition period and the instantiation period.
  • the definition of the retrieval interface model of the execution engine is given below.
  • the input information may include: a collaborative relationship type and a collaborative principal name value pair, so that the return value obtained by the execution engine is: List (list) type, list
  • Each element in the map is a map with a synergistic variable key-value.
  • One or more values may exist in the list. The case of multiple values is a one-to-many synergy relationship.
  • the retrieval process can include the following steps:
  • Step 1 Detect the collaborative relationship type id (relation_type_id) from the first database table according to the relationship type (relation_type);
  • Step 2 Retrieving the order of the values of the collaborative subjects in the search from the fourth database table according to the relation_type_id;
  • Step 3 Combine the retrieved key according to the input collation name value pair and the collation subject value in the search order;
  • Step 4 Search based on the combined key, and return to retrieve the corresponding data, the data is a map pair with the collaborative relationship variable as the key and the collaborative relationship variable as the value. If the data cannot be retrieved, there may be a problem with the entered query criteria.
  • the definition period, the instantiation period, and the KV search model of the collaborative relationship are described above. Two other examples will be given below to illustrate that the collaborative relationship model in the embodiment of the present application can support a more complex model scenario.
  • it may be a warehouse coordination relationship, wherein one warehouse resource may correspond to multiple distribution resources, and each distribution resource has a priority (real business may also need to cooperate with other business rules to coordinate), only given here How to define a one-to-many synergy based on the model.
  • Step 1 Register the collaboration relationship in the first database table, as shown in Table 11:
  • Relationship type ID (relation_type_id) relationship name (relation_name) relationship type name (relation_type) relationship type description
  • Step 2 Define the synergy variable in the third database table. Since in the warehouse coordination relationship, the goods of one warehouse can be distributed by multiple distribution resources, the warehouse coordination relationship is one-to-many. In order to express the one-to-many relationship, a system built-in collaborative variable can be introduced: The parent collaborative relationship (parent_relation_id), when specifically instantiated, a collaborative relationship can point to another collaborative relationship through the variable, so that a list of relational variables can be formed. Therefore, the relationship variable types include the distribution resource code, the delivery priority, and the parent collaboration relationship identifier, as shown in Table 12:
  • the ratio of the first type of warehouse resource to the sales volume of a second type of warehouse resource for example, a value of 0.5 means that half of the goods are stored in the first type of warehouse resource Float
  • Step 3 Associate the collaborative subject with the type of the collaborative relationship in the fourth database table.
  • the associated collaborative principal types include warehouse resources, as shown in Table 13:
  • Body type ID reference (participant_type_
  • the distribution resources as the synergistic relationship participants do not appear in the collaborative subject, because the actual relationship in the retrieval needs is: find the warehouse according to the warehouse resources.
  • the distribution resource corresponding to the resource so the distribution resource is a cooperative supporting role, which appears in the definition of the collaborative relationship variable.
  • Step 1 Define an instance of a collaborative relationship type in the fifth data table, as shown in Table 14:
  • Step 2 Define the specific instantiation value of the collaborative subject in the sixth database table.
  • the collaborative principal identifier value given in the example is the primary key value of each basic data in the actual business, and may be a meaningless self-growth integer. Or other numerical definitions. As shown in Table 15:
  • Step 3 Define a specific instantiation value of the relationship variable in the seventh database table. Specifically, a distribution resource corresponding to the second type of warehouse resource may be set, and a priority selected when the distribution resource is actually selected, as shown in Table 16:
  • synergy relationship 3 points to the synergy relationship 2 through the parent relationship variable
  • synergy relationship 4 also points to the synergy relationship 2 through the parent relationship variable
  • the collaboration Relationships 2, 3, and 4 are parent-child relationships, where synergy relationship 2 is parent coordination relationship, and coordination relationship 3, 4 is child synergy relationship.
  • the delivery priority of the synergy relationship 2 is 1, the delivery priority of the synergy relationship 3 is 2, and the delivery priority of the synergy relationship 4 is 3.
  • the order of transfer between different warehouse resources For example, the order of transfer between different warehouse resources.
  • the transfer line of a certain item is A warehouse - B warehouse - C warehouse, the following example will demonstrate how to express this relationship in the collaborative relationship model.
  • Step 1 Register the collaboration relationship in the first database table, as shown in Table 17:
  • Relationship type ID (relation_type_id) relationship name (relation_name) relationship type name (relation_type) relationship type description
  • Step 2 Define the collaborative relationship variables in the third database table, including the pre-collaborative relationship identifier, the post-collaborative relationship identifier, the transfer source bin, and the transfer destination bin. As shown in Table 18:
  • Step 3 Associate the collaborative entity with the collaborative relationship type in the fourth database table, and the collaborative entity includes the supplier and the goods.
  • Table 19 As shown in Table 19:
  • Body type ID reference (participant_type_
  • the supplier and the goods are the synergistic protagonists, and the actual demand is to query the order of the transfer of a certain supplier's goods.
  • Step 1 Define an instance of a collaborative relationship type in the fifth data table, as shown in Table 20:
  • Step 2 Define the specific instantiation value of the collaborative subject in the sixth database table.
  • the collaborative principal identifier value given in the example is the primary key value of each basic data in the actual business, and may be a meaningless self-growth integer. Or other numerical definitions. As shown in Table 21:
  • Step 3 Define a specific instantiation value of the relationship variable in the seventh database table. As shown in Table 22:
  • the data instantiated above expresses that the routing route of the product HP_01 of the supplier GYS_01 is RRSC_01 RRSC_02 RRSC_03, and the constructed KV storage image is as shown in FIG. 4 .
  • the embodiment of the present application further provides a logistics resource collaborative relationship information processing device, in which the collaborative relationship is defined in advance, and the collaborative relationship is as follows
  • the metadata represents: a collaborative relationship type, an associated relationship variable type, an associated collaborative subject type; the relationship variable is used to express collaborative content, and the collaborative subject is a participant of the collaborative relationship;
  • the apparatus may include:
  • a type information providing unit 501 configured to provide the defined collaborative relationship type information
  • the receiving unit 502 is configured to receive a type of the target collaborative relationship selected by the user, and the instantiated data submitted for the target collaborative relationship, and save the data in a form of a database table; the instantiated data includes a relationship variable value and a collaborative subject value.
  • the device may further include:
  • An index establishing unit configured to establish an index of the instantiated data corresponding to the target collaborative relationship based on the Key-Value model, and load the index into the cache, where the key is established by combining the type of the target collaborative relationship with the associated collaborative subject value,
  • the associated relationship variable value is Value, so that the execution engine retrieves the value of the relationship variable in the instantiated data through the index when performing the planned collaboration.
  • the type of synergy relationship includes a matching relationship between different types of warehouse resources
  • the relationship variable type includes a sales ratio of the first type of warehouse resource to the second type of warehouse resource
  • the collaborative subject type includes: a supplier, a first type of warehouse resource, a second type of warehouse resource, and a commodity.
  • the type of synergy relationship includes a warehouse coordination relationship between a warehouse resource and a distribution resource;
  • the relationship variable type includes a distribution resource code, a delivery priority, and a parent collaborative relationship identifier
  • the collaborative principal type includes a warehouse resource.
  • the index establishing unit is specifically configured to:
  • the relationship variable value associated with the target collaborative relationship is added to the relationship variable value list associated with the parent collaborative relationship, and the combined relationship variable value list is added. Is the Value in the Key-Value model.
  • the type of synergy relationship includes a transfer order relationship between different warehouse resources
  • the relationship variable type includes a pre-collaborative relationship identifier, a post-collaborative relationship identifier, a transfer source bin, and a transfer destination bin;
  • the collaborative body type includes a supplier and a good.
  • the device further includes:
  • a first data table providing unit configured to provide a first database table, where the first database table is used to define collaboration relationship type information
  • a second data table providing unit configured to provide a second database table, where the second database table is used to define collaborative body type information
  • a third data table providing unit configured to provide a third database table, where the third database table is used to define relationship variable type information associated with each collaborative relationship type;
  • a fourth data table providing unit configured to provide a fourth database table, where the fourth database table is used to define collaborative body type information associated with each collaborative relationship type.
  • the device further includes:
  • a fifth data table providing unit configured to provide a fifth database table, where the fifth database table is configured to save a type of the target collaborative relationship selected by the user;
  • a sixth data table providing unit configured to provide a sixth database table, where the sixth database table is used to save the subject type identifier and the collaborative subject value of the target collaborative relationship;
  • a seventh data table providing unit configured to provide a seventh database table, where the seventh database table is used to save the variable type identifier of the target collaborative relationship and the relationship variable value.
  • the collaborative relationship type information in the first database table includes a relationship type ID and a relationship type name
  • the collaborative subject type information in the second database table includes a body type ID and a body type name
  • the third database table The relationship variable type information includes a variable type ID and a variable type name
  • the collaborative body type information in the fourth database table is represented by referring to a form of the body type ID in the second database table;
  • the type of the target collaborative relationship in the fifth database table is represented by referring to the relationship type ID in the first database table;
  • the body type identifier in the sixth database table is represented by referring to a form of a body type ID in the second database table;
  • variable type identifier in the seventh database table is represented by referring to a variable type ID in the third database table.
  • the index establishing unit includes:
  • a type determining subunit configured to retrieve the fifth database table, and determine a type of the target collaborative relationship
  • a collaborative body value determining subunit configured to retrieve the sixth database table according to a type of the target collaborative relationship, and determine a collaborative subject value corresponding to the target collaborative relationship
  • a key combination subunit configured to combine the type of the target collaborative relationship and the collaborative subject value into a Key
  • a relationship variable information determining subunit configured to retrieve the seventh database table, and determine a variable type ID and a relationship variable value corresponding to the target collaborative relationship;
  • variable type name determining subunit configured to retrieve the third database table according to the variable type ID, and determine a variable type name corresponding to the relationship type ID;
  • a value combination subunit for combining the variable type name and the relationship variable value into a Value A value combination subunit for combining the variable type name and the relationship variable value into a Value.
  • the fourth database table further defines search order information of each collaborative subject type in the same collaborative relationship type;
  • the Key combination subunit includes:
  • a search order determining subunit configured to retrieve the fourth database table according to the type of the target collaborative relationship, and determine search order information of each subject type associated with the target collaborative relationship type
  • a sorting subunit configured to sort each collaborative subject value according to the retrieval order
  • a combination subunit configured to combine the type of the target collaborative relationship and the sorted collaborative subject value into a Key.
  • the device may further include:
  • An extracting unit configured to extract a collaborative relationship type and a collaborative principal name value pair from the retrieval request when receiving a retrieval request of an execution engine
  • a type id determining unit configured to retrieve a collaborative relationship type id from the first database table according to a collaborative relationship type
  • a sequence determining unit configured to retrieve, from the fourth database table, an order in which the values of the collaborative agents are retrieved according to the collaborative relationship type id;
  • a retrieval unit is configured to perform retrieval based on the combined key and return to retrieve corresponding data.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product in essence or in the form of a software product, which may be stored in a storage medium such as a ROM/RAM or a disk. , an optical disk, etc., includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present application or portions of the embodiments.
  • a computer device which may be a personal computer, server, or network device, etc.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种物流资源协同关系信息处理方法及装置，其中，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；所述方法包括：提供已定义的协同关系类型信息（S101）；接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值（S102）。应用所述方法，能够支持复杂的协同关系的表达，并提高系统的可扩展性。

Description

物流资源协同关系信息处理方法及装置
本申请要求2015年04月21日递交的申请号为201510190780.5、发明名称为“物流资源协同关系信息处理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及物流信息处理技术领域，特别是涉及物流资源协同关系信息处理方法及装置。
背景技术
随着电子商务交易平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取自己所需的商品，商品的种类可以涉及到人们日常生活的方方面面，其中包括家用电器、家具等类目的商品。对于这类商品而言，由于具有体积大、重量大、易损坏等特点，如何进行商品的仓储以及配送是一个关键性的问题。
为了提高消费者对大家电等商品的购物体验，有些电商平台的电器城商家可以将大家电商品入驻到平台提供的仓库(例如第二类型仓库资源，也就是大家电仓库，每个仓库都有自己的配送覆盖范围)，平台提供的仓库一般包括分布在不同物理位置的多个仓库，例如，北京仓、杭州仓、上海仓，等等。另外，商家还可能有自己的物流资源，例如，自建的仓库等等，一个商家可能会同时使用平台提供的仓库以及自己的仓库(为便于描述，将平台提供的仓库称为“第二类型仓库资源”，将商家自己的仓库称为“第一类型仓库资源”)，等等。
为了帮助商家合理的在体系内管理库存(包括商品的入库、补货、铺货等问题)，有些交易平台会引入平台供应链，涉及从销售预测开始到采购计划、到入库计划、到调拨计划、到完成最后的计划执行，等等。其中的多方协同会比较复杂，例如，某个供货商某个商品在各个第二类型仓库资源之间的分配比例关系、某个供货商某个商品在第二类型仓库资源某个仓库内的使用面积、某个供货商跟另外一个供货商在某个第二类型仓库资源中的竞争关系，等等。但是，计划又是通过一系列复杂的协同关系确定出来的，这些错综复杂的协同，给系统设计带来了复杂性。
例如，商家在针对某商品选择了深圳仓以及东莞仓之后，一般会根据预先制定的在各地的销售计划，向在各个仓进行备货。但深圳仓与东莞仓之间还具有一定的协同关系：东莞距离深圳较近，东莞仓在一天之内就可以完成向深圳仓的补货，因此，如果能够将这种关系的仓库资源更合理的利用，将会提高资源的利用率，也避免出现某仓库由于过量补货而导致的库存积压等问题。
为此，平台供应链需要为商家提供计划协同方案，计划协同的本质根据基础数据和多方协同规则去形成一份最终执行的计划的过程。但是，每个业务场景都会有自己的基础数据和多方协同的规则。例如：
业务场景1：针对C2B(消费者对企业，一般是先有消费者需求产生而后有企业生产)期货预售订单下沉供应链方案。
(1)基础数据包括：C2B的期货定金订单、商品的第二类型仓库资源的库存分布等。
(2)协同关系包括：第二类型仓库资源之间下沉关系(如从A仓下沉到B仓)、该供货商在第二类型仓库资源可使用的库容面积、该供货商的该商品在第二类型仓库资源的库存比例等。
业务场景2：制定的多级仓供应链方案。
(1)基础数据包括：销售预测数据、当前库存在各种的分布数据等；
(2)协同关系包括：某个商品在某两个仓之间的分配比例关系、该供货商在第二类型仓库资源可使用的库容面积、该供货商的该商品在第二类型仓库资源的库存比例等等。
现有技术中，通过为每种业务独立开发一套计划协同方案来支持业务的发展，每一套计划协同逻辑中涵盖了对应业务的基础数据和协同方案。但是，现实的供应链协同中充斥着各种协同关系，例如cdc仓与dc仓存在着调拨关系，商家入仓时与日日顺的收货能力存在协同关系，某个区域如果我们限制某个类目的商品在某个销售时间区间不允许过度铺货，那么商家在某个区域的某个类目的铺货又存在竞争关系，等等。有些协同关系现在已经清楚，但是有更多的协同关系暂时无法预知。因此，现有技术的做法是：每发现一种协同关系，建立一个数据表进行存储。在平台供应链的早期，业务种类少，现有的方案是合理的。但随着供应链业务场景的不断发展，各种供应链场景不断增多，供应链中的协同关系也越来越复杂，现有的方案的不足也逐渐暴露出来。
例如，为每种业务独立开发计划协同方案的方式研发周期长，维护成本高，资源浪费严重，难以支撑业务的快速发展。当若干业务并行发展时，这种缺陷就更加显而易见。
再者，业务演进过程中，可能不断变更的业务需求，对系统变更的挑战，现有方案 中一旦某种计划协同方案部署完毕则难以扩展，需要修改源码后重新部署，因此，这种模式难以满足业务的进化需求。
另外，对于还未发生的可以预见协同关系无法快速表达，在业务需求发生时需要重新建立数据库表进行代码开发，因此效率低下。
总之，如何降低平台供应链计划系统开发和维护成本，支持业务的快速发展，成为需要本领域技术人员解决的技术问题。
发明内容
本申请提供了物流资源协同关系信息处理方法及装置，能够提高系统的可扩展性。
本申请提供了如下方案：
一种物流资源协同关系信息处理方法，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；
所述方法包括：
提供已定义的协同关系类型信息；
接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。
一种物流资源协同关系信息处理装置，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；
所述装置包括：
类型信息提供单元，用于提供已定义的协同关系类型信息；
接收单元，用于接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，可以构建一个基于元数据的可配置的模型，在产生新的需求时，只需要按照模型添加新的定义，可以快速承载平台供应链中计划协同所需要的各种因素，基础代码部分则不需要修改，也不需要发表新的程序，因此提高了系统的可扩展性。并且，也能够支持复杂协同关系的表达。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的方法的流程图；
图2是本申请实施例提供的索引模型示意图；
图3是本申请实施例提供的另一索引模型示意图；
图4是本申请实施例提供的再一索引模型示意图；
图5是本申请实施例提供的装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
在传统的供应链协同计划系统中，是针对各种协同场景，每产生一个需求，就进行一次编程实现，然后发表程序，而在本申请实施例中，旨在构建一个基于元数据的可配置的模型，在产生新的需求时，只需要按照模型添加新的定义，基础代码部分则不需要修改，也不需要发表新的程序。
基于上述考虑，在具体实现时，本申请实施例中的平台供应链计划系统的核心领域模型可以构建为：
供应链协同计划＝协同流程+协同基础数据+协同关系+协同规则
因此，只要能够抓住构建供应链协同计划的各个子要素的本质，进行抽象建模，建立一套稳定的可扩展的模型，那么就可以基于这套模型“以不变应万变”，灵活表达各种供应链协同场景。
在上述模型中，关于协同流程表达，业界已经有了各种成熟的流程产品，例如，可以采用TbBpm来实现流程建模，等等。关于协同基础数据表达，现有技术也有了成熟的 资源中心来支撑，协同规则部分有成熟的规则引擎，因此本申请实施例的重点在于如何为协同关系进行建模。
也就是说，在本申请实施例中，是针对供应链协同这个场景，抽象出来一套模型，这个模型可以通过数据初始化进行扩展，以一种一致的方式来表达各种协同关系。这样当有新的需求时，只需要在现有的软件中，进行元数据的扩展，而不需要进行新的代码编写，便可以支撑一种新的协同关系。
从产品层面而言，本申请实施例可以构建一个具有可扩展性的平台供应链计划系统，其中，协同关系表达是这个系统的一个核心模块。对于商家来说，看到的是一个在线的系统，这个系统内置了很多种协同关系的表达，商家可以根据自己的需求、商品的特点等，对其中的协同关系进行实例化。进而，这些实例化数据，就可以用作各种计划执行引擎的执行依据，被计划执行引擎检索使用，并为计划执行引擎的决策提供数据支持。
其中，关于协同关系建模，在本申请实施例中，首先可以抽象出如下几种关键要素：
(1)协同关系类型：可以理解为协同上下文，多个供应链的参与者为什么要协同，要解决一个什么样的业务问题。例如：多个供货商都需要使用某个仓库，但是仓库可用面积一定，因此多个供货商就某个仓库的使用存在竞争关系，这便是一种协同关系。在定义协同关系类型时，可以为每种类型的协同关系取一个名字，通过这个名字来标识该种协同关系，如前述例子中的协同关系，可以取名为：“仓面积竞争协同”，这便是一种协同关系类型。
(2)协同主体类型：既然谈到协同，那么很显然协同关系的参与者必然要多于一种，这里谈到的协同参与者不一定是人，可能是其它的可协调的元素。当然，协同参与者未必都是协同主体，例如：现实中的一个仓，可以根据sku(Stock Keeping Unit，库存量单位)不同，选择不同的配送公司，存在一种仓配协同关系，在这个场景里，仓和sku作为协同主体，而配送公司就不是协同主体，因为现实需求为：给出仓和sku找出采用哪个配送公司来配送，显然仓和sku一定的情况下，配送公司是可能随着商务合作关系进行改变的。因此，判断一个协同关系的参与者中谁是协同主体的方法可以为：用来定位协同关系的协同参与者为协同主体，否则就不是协同主体。
(3)协同关系变量类型：关系变量表达了在协同场景下，协同主体与协同参与者(非主体)就什么进行协同，也就是协同的内容。仍然以上面的面积竞争协同为例，仓的面积表达了协同者之间就什么进行协同，因此仓面积就是协同关系变量。之所以称为变量，是因为它并非定值，不同的仓库能够供商家使用的面积是不同的，同一个仓，在不同时 间段，能够提供的使用面积也是不同的，因此仓库可用面积为协同关系变量。
这样，各种协同关系都可以通过上述几种关键要素的组合进行表达，这就是协同关系的本质，因此，上述关键要素就可以作为各种协同关系的元数据。在抽象出上述元数据之后，就可以用于表达各种协同关系。其中，系统支持多少种协同关系可以是由程序员也就是系统的设计者来进行配置的，这个数据的初始化可以定义为设计期或者定义期，然后每个商家可以基于已经定义好的协同关系在进行数据的实例化。以配比协同关系为例：系统的开发者基于模型定义了第一类型仓库资源与第二类型仓库资源就某个商品的库存分配存在配比关系，但是具体是哪个商家、哪个第二类型仓库资源、哪个商品，在这个阶段是不知道的，接下来就可以进行实例化，每个商家都可以根据自己的商品设置在不同的第一类型仓库资源与第二类型仓库资源之间的配比关系。
也就是说，可以将协同关系的表达分为两个阶段：定义阶段与实例化阶段。在定义阶段，可以从类型的级别描述协同关系，以仓配协同为例，此时只指出了仓与配存在协同关系，但是具体是哪个仓与哪个配有协同关系，在定义阶段并没有体现，这个需要在实例化阶段完成。
其中，关于协同关系的定义阶段，可以有多种实现方式，例如，在一种实现方式下，可以通过四个数据库表进行建模(因为协同主体类型可能在多个协同关系定义中多次出现，因此将协同主体类型单独建模)，分别称为第一数据库表、第二数据库表、第三数据库表以及第四数据库表，其中，第一数据库表用于定义协同关系类型信息，第二数据库表用于定义协同主体类型信息，第三数据库表用于定义各协同关系类型关联的关系变量类型信息，第四数据库表用于定义各协同关系类型关联的协同主体类型信息。例如，第一数据库表的结构可以如以下表1所示：
表1
关系类型ID(relation_type_id)关系名称(relation_name)关系类型名称(relation_type)  关系类型描述
(relation_desc)
Figure PCTCN2016079229-appb-000001
该第一数据库表中，条目的数量是由定义的协同关系的数量决定的，一般情况下， 定义了多少种协同关系，该第一数据库表中就会保存多少个条目，当需要新增一种协同关系时，该第一数据库表中就会新增一个条目，用于描述该新增的系统关系的类型信息。在上述表1中，协同关系类型信息可以由关系类型ID以及关系类型名称等来表达。当然，在实际应用中，协同关系类型信息也可以通过其他方式表达。
第二数据库表的结构可以如以下表2所示：
表2
主体类型ID(participant_type_id)
(主键)  主体类型名称
(participant_type)
主体类型描述
(participant_desc)
Figure PCTCN2016079229-appb-000002
由于在一个系统中，协同主体的数量一般是有限并且固定的，同一协同主体可能会出现在不同类型的协同关系中，因此，该第二数据库表是一个全局的表，可以对各种可能的执行主体罗列在该第二数据库表中，在定义具体的协同关系时，可以通过引用该第二数据库表中的记录来表达具体的协同主体。在上述表2中，协同主体类型信息可以由主体类型ID以及主体类型名称等来表达。当然，在实际应用中，协同主体类型信息也可以通过其他方式表达。
第三数据库表的结构可以如以下表3所示：
表3
关系变量ID
Figure PCTCN2016079229-appb-000003
Figure PCTCN2016079229-appb-000004
每定义一种类型的协同关系，如果该协同关系需要用到某变量，就可以在该第二数据库表中添加新的条目，其中，一种协同关系可能会使用一个或多个变量，因此，一种协同关系在该第二数据库表中可能会对应一个或多个条目。例如，在上述表3中，关系类型ID为1的协同关系，对应着名称为1、2的两个关系变量。关于第三数据库表中的关系变量类型信息，如表3所示，可以包括变量类型ID以及变量类型名称等，类似的，在实际应用中，关系变量类型信息也可以通过其他方式表达。
第三数据库表的结构可以如以下表4所示：
表4
主体类型ID引用(participant_type_
id)  关系类型id引用
(relation_type_
id)  主体类型id引用
(participant_
id)  检索顺序
(retrieval_order)
Figure PCTCN2016079229-appb-000005
在第二数据库表中建立的协同主体为全局的协同关系主体，因此还可以要将协同主体与具体的协同关系建立关联。与第三数据库表类似，每定义一种类型的协同关系，都可以在第四数据库表中添加新的条目，用于描述该协同关系的协同主体，其中，一种协同关系一般会涉及到多种协同主体，因此，在第四数据库表中，同一种协同关系可能会对应多个数据条目，分别用于描述该协同关系中的各种协同主体。例如，在上表4中表达的含义为：在协同关系类型id＝1的协同关系上下文中，有协同主体id＝1，2，3的三 个协同主体参与。
另外，如表4所示，第四数据库表中的协同主体类型信息可以通过引用第二数据库表中的主体类型ID的形式表示，协同关系类型信息可以通过引用第一数据库表彰的关系类型ID的形式来表示。另外，该第四数据库表中还可以定义出同一种协同关系下，各种协同主体的检索顺序，以用于后续索引模型的建立，关于这部分内容，在后文中会有详细介绍。
为了更清晰的理解上述协同关系定义过程，下面以协同配比关系为例进行介绍。
协同配比关系的业务背景：为了实现对货品的强管控，大家电体系采用统仓统配模式，即前端可销库存与后端第二类型仓库资源实物库存绑定，在商家货品没有入第二类型仓库资源之前，前端显示不可销售。但有部分大的商家，在线下有着强大的仓资源，且商家部分仓离第二类型仓库资源比较近，补货周期大约在1-2天，因此一种可行的货品管控方式是针对这类大商家的部分区域，部分货物放到自己的第一类型仓库资源销售，这样对部分非畅销商品商家就可以对第二类型仓库资源补充少于销售预测的库存，既可保证不缺货，又能避免因为对第二类型仓库资源补过量的货，造成库存积压。以上业务需求产生了一种商品铺货的配比关系，在实际进行供应链协同计算时，就可以首先在系统中定义出这种协同关系。
具体的定义过程如下：
第一步，在第一数据库表中注册这种协同关系，如以下表5所示：
表5
关系类型ID(relation_type_id)关系名称(relation_name)关系类型名称(relation_type)  关系类型描述
(relation_desc)
1 PBGX 0(单值关系)配比关系
第二步，在第三数据库表中定义协同关系变量，在该协同关系中，关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比，如以下表6所示：
表6
关系变量ID
Figure PCTCN2016079229-appb-000006
Figure PCTCN2016079229-appb-000007
1 1 share_ration第一类型仓库资源对某个第二类型仓库资源销量的占比，例如值为0.5表示一半的货品存放在第一类型仓库资源Float
浮点型
第三步：在第四数据库表中将协同主体与协同关系建立关联，在该协同关系中，关联的协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品，如以下表7所示：
表7
主体类型ID引用(participant_type_
id)  关系类型id引用
(relation_type_
id)  主体类型id引用
(participant_
id)  检索顺序
(retrieval_order)
Figure PCTCN2016079229-appb-000008
以上是根据业务需求，抽象定义了一种配比关系，该定义过程即描述为定义阶段，因此上述的定义只从类型的角度定义协同关系，之后就可以进入协同关系的实例化阶段，以及后续的建立索引的阶段。
参见图1，本申请实施例提供了一种物流资源协同关系信息处理方法，该方法可以包括以下步骤：
S101：提供已定义的协同关系类型信息；
在定义了各种协同关系之后，可以将定义好的各种协同关系信息通过在线系统进行公布，例如，可以将各种协同关系的名称等信息，通过列表等形式展示在用户界面中，并且还可以提供关于各种协同关系的作用等信息的描述。这样，商家可以通过查看各种 协同关系类型信息，并结合自己的需求，选择其中某种或者某些协同关系进行实例化。
S102：接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值；
这里的用户主要是指商家用户或者卖家用户，为便于描述，本文中均描述为“商家”。商家在选中了某类型的协同关系后，系统可以将与该类型的协同关系关联的协同主体类型、关系变量类型提供给商家，例如，在如前述各数据库表进行协同关系的定义的情况下，系统可以根据该协同关系的类型，查询前述表3，确定出与该类型的协同关系关联的关系变量类型，查询前述表4以及表2，确定出与该类型的协同关系关联的协同主体类型，进而，商家就可以填入具体的实例化数据并提交，其中，实例化数据就包括关系变量值以及协同主体值。具体实现时，在接收到商家提交的实例化数据时，仍然可以通过数据库表的形式进行保存。
其中，在通过数据库表的形式保存实例化数据时，仍然可以将协同关系类型、协同主体值、关系变量值分别在不同的数据库表中保存。例如，可以提供第五数据库表，用于保存用户选中的目标协同关系的类型，提供第六数据库表，用于保存目标协同关系的主体类型标识及协同主体值，提供第七数据库表，保存目标协同关系的变量类型标识以及关系变量值。
为便于理解，下面结合具体的例子进行介绍。假设某商家选择了前述例子中的配比关系这一协同关系，则首先可以通过表8保存这一协同关系类型。
表8
协同关系id
(relation_id)  协同关系类型id引用
(relation_type_id)
1 1
随着商家对实例化数据的提交，上述表8中会保存多个条目，商家每选择一个类型的协同关系进行实例化时，该表8中就会新增一个条目。其中引用的协同关系类型id，是根据表1中的记录确定的，也就是说，第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示。
在商家为该选择的目标协同关系提交了协同主体值时，可以对该目标协同关系的协同主体进行实例化，具体可以在以下表9中进行保存：
表9
序列id关系id引用
(relation_id)  协同主体类型id引用
(participant_type_id)  协同主体标识
(participant_identity)
Figure PCTCN2016079229-appb-000009
也就是说，供应商标识为GYS_01的货品HP_01，需要在第一类型仓库资源SJC_01与第二类型仓库资源RRSC_01之间，使用类型id为1的协同关系。其中，第六数据库表中的主体类型标识可以通过引用第二数据库表中的主体类型ID的形式表示，关系id引用的是第五关系表中的记录。
另外，还可以实例化协同关系变量，具体的，可以通过以下表10的形式进行保存：
表10
序列id协同关系id引用(relation_id)  关系变量id引用
(relation_var_id)  关系变量值(relation_var_value)
1 1 1 0.5
上述表10中给出关系变量的值为0.5表示，针对货品HP_01，在第一类型仓库资源与第二类型仓库资源的销售分配比例为各占50％。其中，第七数据库表中的变量类型标识可以通过引用所述第三数据库表中的变量类型ID的形式表示。
以上分别从定义期与实例化的角度，对现实的协同业务场景进行了建模，并通过数据库表的形式保存相应的值，完成了模型的实例化。在保存之后，系统中的各种执行引擎就可以通过检索这些实例化数据，来为具体的决策提供依据。其中，计划引擎可能会有多个，例如，包括基于C2B期货定金订单来决定商家的补货和调拨计划引擎、基于菜鸟仓体系给商家通用的物流解决方案的入库和调拨计划引擎、基于菜鸟仓体系和第一类型仓库资源体系的物流解决方案的计划引擎、基于第一类型仓库资源体系就近补货给菜鸟仓体系的计划引擎，等等。
S103：基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化 数据中的关系变量值。
为了便于各种执行引擎对协同关系定义以及实例化数据的使用，可以系统启动时和新建立一个协同关系保存后，将协同关系的定义以及实例化数据写入缓存中，这样，执行引擎就可以从缓存中读取具体的协同关系数据，而不必每次都进行数据库的读写操作，可以提高处理效率。
其中，将数据库表中的数据加载到缓存中的执行时间可能会有多种，例如，可以是在系统启动时加载，或者，还可以是在系统中新建一种协同关系时重新加载，等等。
为了能够方便执行引擎检索协同关系，本申请实施例在将协同关系数据加载到缓存的过程中，还可以将存储在数据库表里的协同关系表达，转换成基于key-value模式的存储表达，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，例如，检索模型可以如图2所示。这样，执行引擎在执行计划协同时，就可以通过这种索引检索出实例化数据中的关系变量值，进而为具体的执行提供依据。
其中，如果数据库表的结构如前文表1至表10所示，则具体在基于Key-Value模型建立目标协同关系对应的实例化数据的索引检索时，可以包括以下步骤：
步骤一：检索第五数据库表，确定目标协同关系的类型；
步骤二：根据目标协同关系的类型检索所述第六数据库表，确定目标协同关系对应的协同主体值；
步骤三：将目标协同关系的类型以及所述协同主体值组合为Key；
其中，如果第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息，则该步骤三具体可以包括：
根据目标协同关系的类型，检索第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；
按照该检索顺序，将各个协同主体值进行排序；
将目标协同关系的类型以及排序后的协同主体值组合为Key
例如，在前述表7中，各主体类型id为1、2、3、4的协同主体，检索顺序分别为1、2、3、4，则在组合检索模型中的key时，就可以按照主体类型id为1、2、3、4的顺序进行排序。
步骤四：检索第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；
步骤五：根据变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量 类型名称；
步骤六：将变量类型名称与关系变量值组合为Value。
以上给出了基于数据库表存储的协同关系建立的KV检索模型，以及如何根据定义期与实例化期的数据，建立实际的检索映像，下面给出执行引擎的检索接口模型定义。
在按照如上方式建立了检索模型后，执行引擎在需要检索时，输入的信息可以包括：协同关系类型、协同主体名值对，这样，执行引擎得到的返回值为：List(列表)类型，列表里的每个元素为以协同关系变量key-value的map，列表中可能存在一个或者多个值，多个值的情况为一对多协同关系。
这样，在系统接收到一个检索请求之后，检索的过程就可以包括以下步骤：
步骤一：根据协同关系类型(relation_type)从第一数据库表查出协同关系类型id(relation_type_id)；
步骤二：根据relation_type_id从第四数据库表中检索出协同主体的值在检索中的排列顺序；
步骤三：根据输入的协同主体名值对和协同主体值在检索中的排列顺序，组合检索的key；
步骤四：基于组合出的key进行检索，并返回检索出相应的数据，数据为一个以协同关系变量为key，协同关系变量的值为value的map对。如果检索不出数据，说明输入的查询条件可能存在问题。
以上对协同关系的定义期、实例化期以及KV检索模型进行了介绍，下面将给出另外两组例子，来说明本申请实施例中的协同关系模型能够支撑更为复杂的模型场景。
例一：一对多协同关系
例如，可以是仓配协同关系，其中，一个仓库资源可以对应多个配送资源，每个配送资源有一个优先级(现实业务中可能还需要结合其它的业务规则来进行协同)，这里只给出如何基于模型定义出一对多的协同关系。
定义阶段：
步骤一：在第一数据库表中注册这种协同关系，如表11所示：
表11
关系类型ID(relation_type_id)关系名称(relation_name)关系类型名称(relation_type)  关系类型描述
(relation_desc)
1 PBGX 0(单值关系)配比关系
2 CPXTGX 1(父子关系)仓配协同关系
步骤二：在第三数据库表中定义协同关系变量。由于在仓配协同关系中，一个仓库的货物可以由多个配送资源来配送，因此仓配协同关系为一对多，为了便于表达该一对多的关系，可以引入一个系统内置的协同变量：父协同关系(parent_relation_id)，具体进行实例化时，一个协同关系可以通过该变量指向另一个协同关系，这样便可以形成一个关系变量的列表。因此，关系变量类型包括配送资源编码、配送优先级、父协同关系标识，如表12所示：
表12
关系变量ID
Figure PCTCN2016079229-appb-000010
1 1 share_ration第一类型仓库资源对某个第二类型仓库资源销量的占比，例如值为0.5表示一半的货品存放在第一类型仓库资源Float
浮点型
Figure PCTCN2016079229-appb-000011
步骤三：在第四数据库表中将协同主体与协同关系类型建立关联。关联的协同主体类型包括仓库资源，如表13所示：
表13
主体类型ID引用(participant_type_
id)  关系类型id引用
(relation_type_
id)  主体类型id引用
(participant_
id)  检索顺序
(retrieval_order)
Figure PCTCN2016079229-appb-000012
需要说明的是，在上述协同类型定义中，关于仓配协同，作为协同关系参与者的配送资源并没有出现在协同主体中，因为实际的关系检索中的需要为：根据仓库资源找出这个仓库资源对应的配送资源，因此配送资源为协同配角，出现在协同关系变量的定义中。
实例化阶段：
步骤一：在第五数据表中定义一个协同关系类型的实例，如表14所示：
表14
协同关系id
(relation_id)  协同关系类型id引用
(relation_type_id)
Figure PCTCN2016079229-appb-000013
步骤二：在第六数据库表中定义协同主体的具体实例化值，例子中给出的协同主体标识值在实际业务中，为各个基础数据的主键值，可能是无意义的自增长整型或者其它的数值定义。如表15所示：
表15
序列id关系id引用
(relation_id)  协同主体类型id引用
(participant_type_id)  协同主体标识
(participant_identity)
Figure PCTCN2016079229-appb-000014
Figure PCTCN2016079229-appb-000015
步骤三：在第七数据库表中定义关系变量的具体实例化值。具体的，可以设置一个第二类型仓库资源对应的配送资源，和实际选用这些配送资源的时候选择的优先级，如表16所示：
表16
序列id协同关系id引用(relation_id)  关系变量id引用
(relation_var_id)  关系变量值(relation_var_value)
Figure PCTCN2016079229-appb-000016
通过上述表16中的第6行以及第9行可见，协同关系3通过父关系变量指向了协同关系2，协同关系4也通过父关系变量也指向了协同关系2，这也就意味着，协同关系2、3、4之间为父子关系，其中协同关系2为父协同关系，协同关系3、4为子协同关系。另外，通过第4行以及第7行可见，协同关系2的配送优先级为1，协同关系3的配送优先级为2，协同关系4的配送优先级为3。
后续在建立KV检索模型时，如果一个协同关系有parent_relation_id关系变量值，那么在构建自己的检索关系后，还要把构建形成的关系变量值加入到其父协同关系的对于的列表里。如图3所示，同时可以看出，一对多的协同关系中，多个协同关系的协同关系类型与协同主体是相同的，因此形成的协同KV映像里，key值的多少等同于协同主体的个数。
例二：序列协同关系
例如，不同仓库资源之间的调拨顺序关系。在仓库资源的网络调拨过程中，假定存在这种场景，某个货品的调拨线路为A仓—B仓—C仓，下面的例子将演示如何在协同关系模型中对这种关系进行表达。
定义阶段：
步骤一：在第一数据库表中注册这种协同关系，如表17所示：
表17
关系类型ID(relation_type_id)关系名称(relation_name)关系类型名称(relation_type)  关系类型描述
(relation_desc)
3 DBSXGX 2(序列关系)调拨顺序关系
步骤二：在第三数据库表中定义协同关系变量，包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓。如表18所示：
表18
关系变量ID
Figure PCTCN2016079229-appb-000017
步骤三：在第四数据库表中将协同主体与协同关系类型建立关联，协同主体包括供应商以及货品。如表19所示：
表19
主体类型ID引用(participant_type_
id)  关系类型id引用
(relation_type_
id)  主体类型id引用
(participant_
id)  检索顺序
(retrieval_order)
Figure PCTCN2016079229-appb-000018
本例中，以供应商和货品为协同主角，实际的需求为查询某个供应商的某个货品的调拨顺序。
实例化阶段：
步骤一：在第五数据表中定义一个协同关系类型的实例，如表20所示：
表20
协同关系id
(relation_id)  协同关系类型id引用
(relation_type_id)
5 3
6 3
步骤二：在第六数据库表中定义协同主体的具体实例化值，例子中给出的协同主体标识值在实际业务中，为各个基础数据的主键值，可能是无意义的自增长整型或者其它的数值定义。如表21所示：
表21
序列id关系id引用
(relation_id)  协同主体类型id引用
(participant_type_id)  协同主体标识
(participant_identity)
Figure PCTCN2016079229-appb-000019
步骤三：在第七数据库表中定义关系变量的具体实例化值。如表22所示：
表22
序列id协同关系id引用(relation_id)  关系变量id引用
(relation_var_id)  关系变量值(relation_var_value)
Figure PCTCN2016079229-appb-000020
以上实例化的数据表达了供应商GYS_01的货品HP_01的调拨路线为RRSC_01 RRSC_02 RRSC_03，构建的KV存储映像如图4所示。
与本申请实施例提供的物流资源协同关系信息处理方法相对应，本申请实施例还提供了一种物流资源协同关系信息处理装置，在该装置中，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；
参见图5，所述装置可以包括：
类型信息提供单元501，用于提供已定义的协同关系类型信息；
接收单元502，用于接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。
具体实现时，该装置还可以包括：
索引建立单元，用于基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化数据中的关系变量值。
其中：
所述协同关系类型包括不同类型仓库资源之间的配比关系；
所述关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比；
所述协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品。
所述协同关系类型包括仓库资源与配送资源之间的仓配协同关系；
所述关系变量类型包括配送资源编码、配送优先级、父协同关系标识；
所述协同主体类型包括仓库资源。
具体的，所述索引建立单元具体用于：
如果某目标协同关系的实例化数据中包含父协同关系标识，则将该目标协同关系关联的关系变量值，加入到其父协同关系关联的关系变量值列表中，以组合后的关系变量值列表为Key-Value模型中的Value。
其中：
所述协同关系类型包括不同仓库资源之间的调拨顺序关系；
所述关系变量类型包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓；
所述协同主体类型包括供应商以及货品。
在协同关系定义阶段，所述装置还包括：
第一数据表提供单元，用于提供第一数据库表，所述第一数据库表用于定义协同关系类型信息；
第二数据表提供单元，用于提供第二数据库表，所述第二数据库表用于定义协同主体类型信息；
第三数据表提供单元，用于提供第三数据库表，所述第三数据库表用于定义各协同关系类型关联的关系变量类型信息；
第四数据表提供单元，用于提供第四数据库表，所述第四数据库表用于定义各协同关系类型关联的协同主体类型信息。
在协同关系实例化阶段，所述装置还包括：
第五数据表提供单元，用于提供第五数据库表，所述第五数据库表用于保存用户选中的目标协同关系的类型；
第六数据表提供单元，用于提供第六数据库表，所述第六数据库表用于保存目标协同关系的主体类型标识及协同主体值；
第七数据表提供单元，用于提供第七数据库表，所述第七数据库表用于保存目标协同关系的变量类型标识以及关系变量值。
其中，所述第一数据库表中的协同关系类型信息包括关系类型ID以及关系类型名称，所述第二数据库表中的协同主体类型信息包括主体类型ID以及主体类型名称，所述第三数据库表中的关系变量类型信息包括变量类型ID以及变量类型名称，所述第四数据库表中的协同主体类型信息通过引用所述第二数据库表中的主体类型ID的形式表示；
所述第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示；
所述第六数据库表中的主体类型标识通过引用所述第二数据库表中的主体类型ID的形式表示；
所述第七数据库表中的变量类型标识通过引用所述第三数据库表中的变量类型ID的形式表示。
所述索引建立单元包括：
类型确定子单元，用于检索所述第五数据库表，确定目标协同关系的类型；
协同主体值确定子单元，用于根据目标协同关系的类型检索所述第六数据库表，确定所述目标协同关系对应的协同主体值；
Key组合子单元，用于将所述目标协同关系的类型以及所述协同主体值组合为Key；
关系变量信息确定子单元，用于检索所述第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；
变量类型名称确定子单元，用于根据所述变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量类型名称；
Value组合子单元，用于将所述变量类型名称与关系变量值组合为Value。
所述第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息；所述Key组合子单元包括：
检索顺序确定子单元，用于根据所述目标协同关系的类型，检索所述第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；
排序子单元，用于按照所述检索顺序，将各个协同主体值进行排序；
组合子单元，用于将所述目标协同关系的类型以及排序后的协同主体值组合为Key。
另外，该装置还可以包括：
提取单元，用于接收到执行引擎的检索请求时，从所述检索请求中提取出协同关系类型以及协同主体名值对；
类型id确定单元，用于根据协同关系类型从所述第一数据库表检索出协同关系类型id；
顺序确定单元，用于根据协同关系类型id从所述第四数据库表中检索出协同主体的值在检索中的排列顺序；
检索Key确定单元，用于根据输入的协同主体名值对以及协同主体值在检索中的排 列顺序，组合检索的key；
检索单元，用于基于组合出的key进行检索，并返回检索出相应的数据。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的物流资源协同关系信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (24)

  1. 一种物流资源协同关系信息处理方法，其特征在于，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；
    所述方法包括：
    提供已定义的协同关系类型信息；
    接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。
  2. 根据权利要求1所述的方法，其特征在于，还包括：
    基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化数据中的关系变量值。
  3. 根据权利要求1或2所述的方法，其特征在于：
    所述协同关系类型包括不同类型仓库资源之间的配比关系；
    所述关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比；
    所述协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品。
  4. 根据权利要求1或2所述的方法，其特征在于：
    所述协同关系类型包括仓库资源与配送资源之间的仓配协同关系；
    所述关系变量类型包括配送资源编码、配送优先级、父协同关系标识；
    所述协同主体类型包括仓库资源。
  5. 根据权利要求4所述的方法，其特征在于，所述基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，包括：
    如果某目标协同关系的实例化数据中包含父协同关系标识，则将该目标协同关系关联的关系变量值，加入到其父协同关系关联的关系变量值列表中，以组合后的关系变量值列表为Key-Value模型中的Value。
  6. 根据权利要求1或2所述的方法，其特征在于：
    所述协同关系类型包括不同仓库资源之间的调拨顺序关系；
    所述关系变量类型包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓；
    所述协同主体类型包括供应商以及货品。
  7. 根据权利要求1或2所述的方法，其特征在于，在协同关系定义阶段，所述方法还包括：
    提供第一数据库表，所述第一数据库表用于定义协同关系类型信息；
    提供第二数据库表，所述第二数据库表用于定义协同主体类型信息；
    提供第三数据库表，所述第三数据库表用于定义各协同关系类型关联的关系变量类型信息；
    提供第四数据库表，所述第四数据库表用于定义各协同关系类型关联的协同主体类型信息。
  8. 根据权利要求7所述的方法，其特征在于，在协同关系实例化阶段，所述方法还包括：
    提供第五数据库表，所述第五数据库表用于保存用户选中的目标协同关系的类型；
    提供第六数据库表，所述第六数据库表用于保存目标协同关系的主体类型标识及协同主体值；
    提供第七数据库表，所述第七数据库表用于保存目标协同关系的变量类型标识以及关系变量值。
  9. 根据权利要求8所述的方法，其特征在于，所述第一数据库表中的协同关系类型信息包括关系类型ID以及关系类型名称，所述第二数据库表中的协同主体类型信息包括主体类型ID以及主体类型名称，所述第三数据库表中的关系变量类型信息包括变量类型ID以及变量类型名称，所述第四数据库表中的协同主体类型信息通过引用所述第二数据库表中的主体类型ID的形式表示；
    所述第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示；
    所述第六数据库表中的主体类型标识通过引用所述第二数据库表中的主体类型ID的形式表示；
    所述第七数据库表中的变量类型标识通过引用所述第三数据库表中的变量类型ID的形式表示。
  10. 根据权利要求9所述的方法，其特征在于，所述基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，包括：
    检索所述第五数据库表，确定目标协同关系的类型；
    根据目标协同关系的类型检索所述第六数据库表，确定所述目标协同关系对应的协同主体值；
    将所述目标协同关系的类型以及所述协同主体值组合为Key；
    检索所述第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；
    根据所述变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量类型名称；
    将所述变量类型名称与关系变量值组合为Value。
  11. 根据权利要求10所述的方法，其特征在于，所述第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息；所述将所述目标协同关系的类型以及所述协同主体值组合为Key，包括：
    根据所述目标协同关系的类型，检索所述第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；
    按照所述检索顺序，将各个协同主体值进行排序；
    将所述目标协同关系的类型以及排序后的协同主体值组合为Key。
  12. 根据权利要求11所述的方法，其特征在于，还包括：
    接收到执行引擎的检索请求时，从所述检索请求中提取出协同关系类型以及协同主体名值对；
    根据协同关系类型从所述第一数据库表检索出协同关系类型id；
    根据协同关系类型id从所述第四数据库表中检索出协同主体的值在检索中的排列顺序；
    根据输入的协同主体名值对以及协同主体值在检索中的排列顺序，组合检索的key；
    基于组合出的key进行检索，并返回检索出相应的数据。
  13. 一种物流资源协同关系信息处理装置，其特征在于，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；
    所述装置包括：
    类型信息提供单元，用于提供已定义的协同关系类型信息；
    接收单元，用于接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。
  14. 根据权利要求13所述的装置，其特征在于，还包括：
    索引建立单元，用于基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化数据中的关系变量值。
  15. 根据权利要求13或14所述的装置，其特征在于：
    所述协同关系类型包括不同类型仓库资源之间的配比关系；
    所述关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比；
    所述协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品。
  16. 根据权利要求13或14所述的装置，其特征在于：
    所述协同关系类型包括仓库资源与配送资源之间的仓配协同关系；
    所述关系变量类型包括配送资源编码、配送优先级、父协同关系标识；
    所述协同主体类型包括仓库资源。
  17. 根据权利要求16所述的装置，其特征在于，所述索引建立单元具体用于：
    如果某目标协同关系的实例化数据中包含父协同关系标识，则将该目标协同关系关联的关系变量值，加入到其父协同关系关联的关系变量值列表中，以组合后的关系变量值列表为Key-Value模型中的Value。
  18. 根据权利要求13或14所述的装置，其特征在于：
    所述协同关系类型包括不同仓库资源之间的调拨顺序关系；
    所述关系变量类型包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓；
    所述协同主体类型包括供应商以及货品。
  19. 根据权利要求13或14所述的装置，其特征在于，在协同关系定义阶段，所述装置还包括：
    第一数据表提供单元，用于提供第一数据库表，所述第一数据库表用于定义协同关系类型信息；
    第二数据表提供单元，用于提供第二数据库表，所述第二数据库表用于定义协同主体类型信息；
    第三数据表提供单元，用于提供第三数据库表，所述第三数据库表用于定义各协同关系类型关联的关系变量类型信息；
    第四数据表提供单元，用于提供第四数据库表，所述第四数据库表用于定义各协同关系类型关联的协同主体类型信息。
  20. 根据权利要求19所述的装置，其特征在于，在协同关系实例化阶段，所述装置还包括：
    第五数据表提供单元，用于提供第五数据库表，所述第五数据库表用于保存用户选中的目标协同关系的类型；
    第六数据表提供单元，用于提供第六数据库表，所述第六数据库表用于保存目标协同关系的主体类型标识及协同主体值；
    第七数据表提供单元，用于提供第七数据库表，所述第七数据库表用于保存目标协同关系的变量类型标识以及关系变量值。
  21. 根据权利要求20所述的装置，其特征在于，所述第一数据库表中的协同关系类型信息包括关系类型ID以及关系类型名称，所述第二数据库表中的协同主体类型信息包括主体类型ID以及主体类型名称，所述第三数据库表中的关系变量类型信息包括变量类型ID以及变量类型名称，所述第四数据库表中的协同主体类型信息通过引用所述第二数据库表中的主体类型ID的形式表示；
    所述第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示；
    所述第六数据库表中的主体类型标识通过引用所述第二数据库表中的主体类型ID的形式表示；
    所述第七数据库表中的变量类型标识通过引用所述第三数据库表中的变量类型ID的形式表示。
  22. 根据权利要求21所述的装置，其特征在于，所述索引建立单元包括：
    类型确定子单元，用于检索所述第五数据库表，确定目标协同关系的类型；
    协同主体值确定子单元，用于根据目标协同关系的类型检索所述第六数据库表，确定所述目标协同关系对应的协同主体值；
    Key组合子单元，用于将所述目标协同关系的类型以及所述协同主体值组合为Key；
    关系变量信息确定子单元，用于检索所述第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；
    变量类型名称确定子单元，用于根据所述变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量类型名称；
    Value组合子单元，用于将所述变量类型名称与关系变量值组合为Value。
  23. 根据权利要求22所述的装置，其特征在于，所述第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息；所述Key组合子单元包括：
    检索顺序确定子单元，用于根据所述目标协同关系的类型，检索所述第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；
    排序子单元，用于按照所述检索顺序，将各个协同主体值进行排序；
    组合子单元，用于将所述目标协同关系的类型以及排序后的协同主体值组合为Key。
  24. 根据权利要求23所述的装置，其特征在于，还包括：
    提取单元，用于接收到执行引擎的检索请求时，从所述检索请求中提取出协同关系类型以及协同主体名值对；
    类型id确定单元，用于根据协同关系类型从所述第一数据库表检索出协同关系类型id；
    顺序确定单元，用于根据协同关系类型id从所述第四数据库表中检索出协同主体的值在检索中的排列顺序；
    检索Key确定单元，用于根据输入的协同主体名值对以及协同主体值在检索中的排列顺序，组合检索的key；
    检索单元，用于基于组合出的key进行检索，并返回检索出相应的数据。
PCT/CN2016/079229 2015-04-21 2016-04-14 物流资源协同关系信息处理方法及装置 WO2016169429A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510190780.5A CN106156971B (zh) 2015-04-21 2015-04-21 物流资源协同关系信息处理方法及装置
CN201510190780.5 2015-04-21

Publications (1)

Publication Number Publication Date
WO2016169429A1 true WO2016169429A1 (zh) 2016-10-27

Family

ID=57142870

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/079229 WO2016169429A1 (zh) 2015-04-21 2016-04-14 物流资源协同关系信息处理方法及装置

Country Status (2)

Country Link
CN (1) CN106156971B (zh)
WO (1) WO2016169429A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111062661A (zh) * 2019-12-10 2020-04-24 北京云杉信息技术有限公司 一种基于销量预测的库容分配方法及装置
CN113283831A (zh) * 2021-05-07 2021-08-20 云南电网有限责任公司曲靖供电局 一种基于周期检查库存补货策略的安全库存控制方法

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107832998A (zh) * 2017-11-07 2018-03-23 中国移动通信集团湖北有限公司 移动通信供应商协同平台生产备货及物流可视化系统及方法
CN109902982B (zh) * 2017-12-08 2022-04-12 北京京东尚科信息技术有限公司 用于输出信息的方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093388A1 (en) * 2001-11-15 2003-05-15 Brian Albright Automated product sourcing from multiple fulfillment centers
CN101206729A (zh) * 2006-12-22 2008-06-25 深圳富泰宏精密工业有限公司 库存管理系统
US20080235147A1 (en) * 2007-03-19 2008-09-25 Jarl Jensen System and method for facilitation of shipping from multiple merchandise vendors
CN101496041A (zh) * 2006-02-10 2009-07-29 亚马逊科技公司 用于向商家提供库存执行服务的计算机实现的登记
CN103793803A (zh) * 2014-01-02 2014-05-14 远光软件股份有限公司 一种库存管理方法、服务器及系统
CN103914763A (zh) * 2014-01-16 2014-07-09 浙江中烟工业有限责任公司 一种三库协同管理的卷烟物流系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100967442B1 (ko) * 2007-12-04 2010-07-01 주식회사 티맥스 소프트 통합 상품 관리 시스템
CN101236568A (zh) * 2008-02-29 2008-08-06 上海大学 一种动态数据库构建方法
CN101826087B (zh) * 2009-03-02 2012-12-19 中兴通讯股份有限公司 编码信息数据的配置装置、方法
CN101815003A (zh) * 2010-02-23 2010-08-25 浪潮通信信息系统有限公司 全业务融合网络统一资源模型
CN103186620A (zh) * 2011-12-31 2013-07-03 上海可鲁系统软件有限公司 一种cim模型映射方法
CN103886004B (zh) * 2013-11-29 2017-06-09 北京吉威时代软件股份有限公司 一种资料型数据建模处理方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030093388A1 (en) * 2001-11-15 2003-05-15 Brian Albright Automated product sourcing from multiple fulfillment centers
CN101496041A (zh) * 2006-02-10 2009-07-29 亚马逊科技公司 用于向商家提供库存执行服务的计算机实现的登记
CN101206729A (zh) * 2006-12-22 2008-06-25 深圳富泰宏精密工业有限公司 库存管理系统
US20080235147A1 (en) * 2007-03-19 2008-09-25 Jarl Jensen System and method for facilitation of shipping from multiple merchandise vendors
CN103793803A (zh) * 2014-01-02 2014-05-14 远光软件股份有限公司 一种库存管理方法、服务器及系统
CN103914763A (zh) * 2014-01-16 2014-07-09 浙江中烟工业有限责任公司 一种三库协同管理的卷烟物流系统

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111062661A (zh) * 2019-12-10 2020-04-24 北京云杉信息技术有限公司 一种基于销量预测的库容分配方法及装置
CN113283831A (zh) * 2021-05-07 2021-08-20 云南电网有限责任公司曲靖供电局 一种基于周期检查库存补货策略的安全库存控制方法
CN113283831B (zh) * 2021-05-07 2024-01-26 云南电网有限责任公司曲靖供电局 一种基于周期检查库存补货策略的安全库存控制方法

Also Published As

Publication number Publication date
CN106156971A (zh) 2016-11-23
CN106156971B (zh) 2020-04-14

Similar Documents

Publication Publication Date Title
Zhu et al. A systematic review and future directions of the sharing economy: business models, operational insights and environment-based utilities
Zhang et al. UniBench: a benchmark for multi-model database management systems
Bereznoy Changing competitive landscape through business model innovation: The new imperative for corporate market strategy
WO2023045176A1 (zh) 电商多种市场供需高效精准融合智能化系统、方法和装置
WO2016169429A1 (zh) 物流资源协同关系信息处理方法及装置
Zhang et al. Learning to select supplier portfolios for service supply chain
CN111192161A (zh) 电力市场交易对象推荐方法、装置
Hu et al. Alibaba vehicle routing algorithms enable rapid pick and delivery
Hartono et al. Implementation of digital marketing strategies through social media marketing, supply chain management and online sales of bill chilly product
CN104951948A (zh) 基于分布式事务协调与控制的b2b2c电商平台
Chang et al. Identifying the key success factors of F&B sharing services: new insights from a multiple-phase decision-making model
CN117522242A (zh) 物流管理方法、装置、设备及存储介质
Shuxiang Application of Hadoop cloud platform based on soft computing in financial accounting budget control
Wei et al. Design thinking and cloud manufacturing: a study of cloud model sharing platform based on separated data log
Antonov et al. Formation of Clusters in Mono Towns Located in Areas of Priority Socioeconomic Development
Xia et al. Supplier Recommendation Method Based on Semantic Matching and Bipartite Graph Network Collaborative Filtering Algorithm
Wenhong The Study of JD Logistics Mode Based on “Internet+”
Wiratanaya et al. Selection of beef production systems in Bali: An analytical network with BOCR approach
Popov et al. Modelling Evolution of Institutional Invention Cycle
Shen et al. A study of new E-commerce logistics mode based on cloud computing technology
Feng et al. Research on tourism marketing based on community e-commerce
Goel et al. A distributed ledger based cyber-physical architecture to enforce social contracts: paper cup recycling
Wang et al. Research on the Innovation Closed-loop Internet Financial Service Model of Traditional Industry
Bukhari Efficiency and Effectiveness of Supply Chain
Dong et al. An Analysis of the Prospects of New-type E-commerce Enterprises

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16782576

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16782576

Country of ref document: EP

Kind code of ref document: A1