JP4357308B2 - Parts distribution program - Google Patents

Description

  The present invention relates to a technique for distributing parts taken out by dismantling a vehicle.

In order to effectively use resources, for example, buying and selling of parts (recycled parts) taken out by dismantling a car is generally performed. For example, there is a technique for providing information on recycled parts (see, for example, Patent Document 1). That is, the center device is provided with a database function that associates vehicle identification information for identifying the vehicle configuration with list information of vehicle components, and the user device of the dismantling company can specify the vehicle identification information of the vehicle that has entered the vehicle. The component part list information is made available, and the dismantling company designates a part to be removed as a recycled part from the component part list and registers it in the center apparatus as recycled part information. The center device allows the registered recycled parts information to be seen by access from the consumers of recycled parts. Even if the dismantling company is different, by sharing information on recycled parts, accurate information is delivered to consumers, and transactions of recycled parts are activated.
JP 2002-109323 A

  However, according to such a prior art, for example, when there are a plurality of stock vehicles, it is left to the dismantling company to determine which vehicle to dismantle. Therefore, even if a certain vehicle is dismantled, parts that are not in demand from the user remain as inventory parts. On the other hand, the user has to search for a part to be purchased, and give up if there is no part that can be taken out from a vehicle that has been disassembled or that has been decided to be dismantled by a dismantling company. However, there are cases in which parts desired by the user can be taken out by dismantling a vehicle that has not yet been dismantled or whose dismantling company has not yet decided to dismantle. In other words, it is hard to say that a mechanism that enables smooth distribution is in place.

  Accordingly, an object of the present invention is to provide a novel technique for appropriately distributing parts taken out by dismantling a vehicle.

  A method according to the present invention is a parts distribution method for distributing parts taken out by dismantling a vehicle, and refers to an order data storage unit storing part order data from a user, Identifying the part order data and storing it in the storage device, the unordered part identified from the unordered part order data, and the vehicle type and the vehicle of the vehicle type stored in advance in the parts vehicle data storage unit Using the related data with the vehicle dismantling parts that can be taken out by dismantling, identify the car model whose proportion to the whole of the car dismantling parts corresponding to the unordered parts is greater than or equal to a predetermined threshold, and as the priority dismantling car model A priority dismantling vehicle type specifying step for storing in the storage device.

  In this way, by specifying a vehicle type that should be prioritized for disassembly based on unordered parts, that is, demand, appropriate parts distribution is possible. For example, the vehicle type that is in demand for all of the vehicle dismantling parts that can be taken out may be specified as the priority dismantling vehicle type. For example, the number of parts that are in demand is the total number of vehicle dismantling parts that can be taken out, for example, 8 You may make it identify the vehicle type which is more than a discount as a priority dismantling vehicle type. Further, for example, a vehicle type in which the total price of parts in demand is, for example, 80% or more of the total price of vehicle dismantling parts that can be taken out may be specified as a priority dismantling vehicle type. Points may be associated with each other, and a vehicle type in which the total points of parts in demand is, for example, 80% or more of the total points of vehicle dismantling parts that can be taken out may be specified as the priority dismantling vehicle type.

  In addition, in the preferential dismantling vehicle type specifying step, data on dismantling candidate vehicles that can take out vehicle dismantling parts corresponding to unordered parts in an inventory vehicle data storage unit in which data relating to vehicles owned by the dismantling company is stored Inventory check step for determining whether or not data is registered, and in the inventory check step, if it is determined that data on the dismantling candidate vehicle is registered, temporary reservation data of vehicle dismantling parts corresponding to unordered parts is dismantled The ratio of vehicle dismantling parts corresponding to unordered parts based on the data registered in the needs registration table, including a provisional reservation step registered in the needs registration table generated for the vehicle type identified from the candidate vehicle May be calculated.

  In this way, provisional reservation data is registered according to demand. Thereby, for example, it becomes possible to specify a vehicle type having a demand higher than a predetermined level, and for example, it is possible to notify a dismantling contractor as a vehicle type that recommends dismantling. That is, dismantling with less waste can be realized.

  In addition, in the inventory confirmation step, when the data for designating a specific vehicle type is included in the unordered parts order data, a vehicle dismantling part corresponding to the unordered part which is a vehicle of the specific car type is included. You may make it determine whether the data about the disassembly candidate vehicle which can be taken out are registered. For example, the same or compatible parts may be taken out from different vehicle types. In general, there is no particular problem even if they are handled as the same part, but when the vehicle type is specified by the user in this way, only the specified vehicle type can be a dismantling candidate vehicle. Parts can be supplied according to user needs.

  Further, in the provisional reservation step, when there are a plurality of vehicle types corresponding to the dismantling candidate vehicles, provisional reservation data may be registered for the need registration tables of all corresponding vehicle types. As noted above, it may be possible to remove the same or compatible parts from different vehicle types. If the user is not particular about which part the car is taken out from, the provisional reservation data is registered for a plurality of car types in this way, for example, the part taken out from the vehicle to be disassembled earliest is obtained. can do.

  Further, in the provisional reservation step, when there are a plurality of unordered parts corresponding to the vehicle dismantling parts of a specific vehicle type, temporary reservation data is registered in a plurality of needs registration tables for the specific vehicle type. Also good. A needs registration table is generated for each vehicle type. For example, for a vehicle type that incorporates many parts that are the same or compatible with other vehicle types, or for a popular vehicle type, multiple demands for one part are required. There may be. In such a case, it is possible to meet the demand by generating a plurality of needs registration tables for the same vehicle type.

  It is also possible to create a program for causing a computer to execute the method according to the present invention, and the program is a storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, and a hard disk. Alternatively, it is stored in a storage device. Moreover, it may be distributed as a digital signal via a network. Note that data being processed is temporarily stored in a storage device such as a computer memory.

  According to the present invention, it is possible to show a car model to be dismantled preferentially to a dismantling company, and it is possible to distribute parts appropriately according to user needs.

  A system configuration diagram according to an embodiment of the present invention is shown in FIG. For example, the network 1 that is the Internet includes, for example, one or a plurality of user terminals 3 that are personal computers, one or a plurality of used parts distribution servers 5, an A seller server 7, a B seller server 9, and a C seller server 11. Are connected by radio or wire. Note that other merchant servers (not shown) may be connected.

  The user terminal 3, the used parts distribution server 5, the A seller server 7, the B seller server 9 and the C seller server 11 are computer devices as shown in FIG. A bus (219) is connected to a drive (HDD) 205, a display control unit 207 connected to the display device 209, a drive device 213 for the removable disk 211, an input device 215, and a communication control unit 217 for connecting to a network. Yes. An application program including an operating system (OS) and a program for realizing processing in the present embodiment is stored in the HDD 205, and is read from the HDD 205 to the memory 201 when executed by the CPU 203. It is. If necessary, the CPU 203 controls the display control unit 207, the communication control unit 217, and the drive device 213 to perform necessary operations. Further, data in the middle of processing is stored in the memory 201, and if necessary, stored in the HDD 205. A program for realizing the processing in the embodiment of the present invention is stored in the removable disk 211 and distributed, for example, is received from the drive device 213 or via the network and communication control unit 217, and is installed in the HDD 205. Such a computer apparatus realizes various functions described below by organically cooperating hardware such as the CPU 203 and the memory 201 described above with the OS and necessary application programs.

  Returning to the description of FIG. 1, the used parts distribution server 5 includes an order receiving unit 51, a needs registration table management unit 52, and an allocation processing unit 53. Although these processing contents will be described later in the description of the processing flow, the order receiving unit 51 has a web server function and can be accessed from the user terminal 3 having a web browser function. Further, the allocation processing unit 53 has a mailer function, and can transmit and receive mail data between the user terminal 3 having the mailer function and each seller server. The used parts distribution server 5 is connected to a needs registration table storage unit 54, a parts vehicle DB 55, a seller DB 56, and a customer ordering DB 57.

  A merchandise DB 71 and a parts price DB 72 are connected to the A seller server 7. Similarly, a product DB 91 and a component price DB 92 are connected to the B seller server 9, and a product DB 111 and a component price DB 112 are connected to the C seller server 11.

  In the present embodiment, the seller who manages and uses each seller server is, for example, a dismantling company and a person who supplies used parts of a car. Further, the user who operates the user terminal 3 may be an individual consumer, or may be a trader such as a repair shop, a wholesale / retail store, or the like.

  FIG. 3 shows an example of the table configuration of the parts vehicle DB 55 and stored data. The example of FIG. 3 includes a vehicle type number column 300, a vehicle type name column 302, and a mounted part number column 304. In this table, for each vehicle type, the numbers of parts mounted on the vehicle of the vehicle type (removable by dismantling the vehicle of the vehicle type) are registered. According to the example shown in FIG. 3, for example, a part whose part number is “B001” can be taken out from both “multi” and “big” vehicle types.

  FIG. 4 shows an example of the table configuration of the seller DB 56 and stored data. The example of FIG. 4 includes a seller number column 400, a name column 402, a contact column 404, and a vehicle model column 406. In the seller number column 400, a number uniquely assigned to each seller is registered. In the contact column 404, an e-mail address which is a destination when notifying the seller is registered. In the owned vehicle type column 406, vehicle type numbers of vehicles owned by the seller are registered. The values in the column 406 of the owned vehicle type are updated by the manager or the like, for example, periodically or when the seller's owned vehicle type is changed. It may be automatically updated by communication between the used parts distribution server 5 and each seller server. In the present embodiment, even if the same seller has multiple kitchens of the same vehicle type, only one vehicle type number is registered for the vehicle type, but the number of vehicles owned for each vehicle type can be grasped. Data may be held in such a manner. In addition, in the example of FIG. 4, the minimum necessary items are shown, but other attributes of the seller such as the seller's address and telephone number may be registered.

  FIG. 5 shows an example of the table configuration of the customer ordering DB 57 and stored data. The example of FIG. 5 includes an order number column 500, a part number column 502, a name column 504, a contact column 506, a desired vehicle type column 508, and an ordered flag column 510. The record is generated by the order receiving unit 51 of the used parts distribution server 5 when there is a part order from the user. Further, the record is uniquely identified by the value of the order number column 500 that is automatically generated. Note that only one part number is registered in the part number column 502 of one record.

  In the contact column 506, an e-mail address which is a destination when notifying a user who is an orderer is registered. In the desired vehicle type column 508, the name of the vehicle type is registered when the user desires a part of a specific vehicle type. It may be a car model number. In the ordered flag column 510, “◯” is registered when a seller is assigned to the part order. That is, a record in which “o” is not registered in the column 510 of the ordered flag indicates that the seller is not yet assigned to the part order and the ordering process for the seller has not yet been performed.

  FIG. 6 shows an example of the configuration of the needs registration table stored in the needs registration table storage unit 54 and the stored data. The example of FIG. 6 includes a model number column 600, a part number column 602, and a registered order number column 604. This needs registration table is generated according to the parts order from the user for each vehicle type owned by the seller. FIG. 6 shows an example of the vehicle model number “S001”. Similarly, there are also needs registration tables for different vehicle models, and a plurality of needs registration tables for the same vehicle model may be generated. . When the needs registration table is generated, first, values are registered in the vehicle type number column 600 and the component number column 602 based on the component vehicle DB 55 (FIG. 3). Then, the value of the part number column 602 that matches the value of the part number column 502 of each record of the customer ordering DB 57 (FIG. 5) (excluding records where the value of the ordered flag column 510 is “◯”) is set. Identify the rows in the needs registration table you have. Then, the value of the order number column 500 of the record of the customer order DB 57 (FIG. 5) is registered in the registered order number column 604 of the specified row.

  For example, in the record in the first row in the example shown in FIG. 5, the value in the part number column 502 is “B001”. Therefore, the needs registration table is searched using this “B001”. In the example illustrated in FIG. 6, the value of the part number column 602 in the first row is “B001”, so the first row is specified. Then, “H001”, which is the value of the order number column 500 in the first row of the customer order DB 57 (FIG. 5), is registered in the column 604 of the registered order number in the first row of the needs registration table. If there is a row in which the value of the part number column 602 is “B001” in the needs registration table for different vehicle types, “H001” is also registered in the registered order number column 604 of that row. . Since the needs registration table is a temporary table for registering demand for parts that can be supplied as provisional reservation data, such duplicate registration is permitted.

  In this way, values are registered in the registered order number column 604 of the needs registration table. If a value has already been registered in the registered order number column 604 of the needs registration table, a new needs registration table is generated, and a value is stored in the registered order number column 604 of the new needs registration table. Is registered.

  FIG. 7 shows an example of the table configuration of the product DB 71 and stored data. The product DB is a DB provided for each seller, and the product DB 91 and the product DB 111 have the same table configuration. The example of FIG. 7 includes a model number column 700, a serial number column 702, and a dismantling date column 704. In the serial number column 702, serial numbers that can uniquely identify the vehicle are registered. In some cases, the seller assigns a unique number. In the dismantling date column 704, when the scheduled dismantling date of the vehicle is determined, the date is registered.

  FIG. 8 shows an example of the table configuration of the part price DB 72 and stored data. The component price DB is a DB provided for each seller, and the component price DB 92 and the component price DB 112 have the same table configuration. The example of FIG. 8 includes a part number column 800 and a price column 802. In the price column 802, the price of a part uniquely set by the seller is registered.

  Next, processing contents of the system shown in FIG. 1 will be described with reference to FIGS. 9 to 12. Here, the premise process of the process flow shown in FIG. 9 will be described. First, an order data input page is displayed on the display screen of the user terminal 3 by processing of the Web browser of the user terminal 3 and the order receiving unit 51 of the used parts distribution server 5 having a Web server function. Shall. If login is required when using the system, login processing is also performed. Then, the Web browser of the user terminal 3 accepts an order input from the user who is the orderer. Although not shown, for example, an order data input and data transmission request is accepted by a text box, an order button, or the like included in the displayed page. Then, the user terminal 3 transmits the input order data to the used parts distribution server 5. The transmitted order data includes the part number, orderer name and contact mail address. If the desired vehicle type is specified, the name of the desired vehicle type is also included. Hereinafter, description will be given in accordance with the processing steps shown in FIG.

  The order receiving unit 51 of the used parts distribution server 5 receives the order data from the user terminal 3, generates a record of the customer order DB 57 based on the order data, and stores it in the customer order DB 57 (FIG. 5) (FIG. 9: step). S1). A unique value automatically generated is registered in the order number column 500, and a value is not registered or “−” is registered in the ordered flag column 510. And the order reception part 51 determines whether the predetermined period passed (step S3). When it is determined that the predetermined period has not elapsed (step S3: No route), the process returns to step S1 to accept the next order. On the other hand, when it is determined that the predetermined period has elapsed (step S3: Yes route), the allocation processing unit 53 of the used parts distribution server 5 extracts one unprocessed record from the customer order DB 57 (step S5). An unprocessed record is a record for which the value in the column 510 of the ordered flag is not “◯”. Then, it is determined whether there is a vehicle type designation for the unprocessed record (step S7). If the vehicle type name or the vehicle type number is registered in the desired vehicle type column 508, it is determined that the vehicle type is specified. If it is not determined that the vehicle type is designated (step S7: No route), the process proceeds to the process of FIG.

  On the other hand, when it is determined that the vehicle type is specified (step S7: Yes route), the allocation processing unit 53 refers to the seller DB 56 (FIG. 4), and any seller selects a vehicle of the specified vehicle type. It is determined whether it is owned (step S9). Specifically, the value in column 406 of the owned vehicle type is checked. If the vehicle type name is registered in the desired vehicle type column 508 instead of the vehicle type number, the vehicle type number is specified based on the parts vehicle DB 55 (FIG. 3), and then the seller DB 56 is referred to.

  When it is determined that there is no designated vehicle type in the seller DB 56 (step S9: No route), the allocation processing unit 53 addresses the orderer to “no desired part” and “can be changed to another vehicle type having a compatible part?” A notification to that effect is transmitted (step S11). For example, the message “Your desired part was not found. Is it OK to use a part of another model that is compatible with the desired part?” Is displayed in the contact information of the record currently being processed in the customer order DB 57. It is transmitted to the mail address registered in the column 506 (FIG. 5). Furthermore, the allocation processing unit 53 transmits request data to all sellers (step S13). For example, the message “There was an order for the car model number S001 and the part number B002” is transmitted to all the mail addresses registered in the contact column 404 (FIG. 4) of the seller DB 56. And it transfers to the process of step S21 mentioned later.

  On the other hand, when it is determined that there is a designated vehicle type in the seller DB 56 (step S9: Yes route), the needs registration table management unit 52 of the used parts distribution server 5 performs a needs registration table update process (step S15). Although details of the needs registration table update process will be described later, the needs registration table is updated by registering values in the registered order number column 604 (FIG. 6) of the needs registration table for a specific vehicle type. Here, the needs registration table update process is performed for the vehicle type specified by the user.

  When the needs registration table update process ends, the allocation processing unit 53 determines whether or not provisional reservation data has been registered for all part numbers corresponding to the vehicle type designated by the user (step S17). That is, it is checked whether all the values in the registered order number column 604 of the needs registration table are registered. If it is not determined that provisional reservation data has been registered for all part numbers (step S17: No route), the process proceeds to step S21 described later. On the other hand, when it is determined that provisional reservation data has been registered for all the part numbers (step S17: Yes route), the allocation processing unit 53 performs a seller allocation process (step S19). Details of the seller allocation process will be described later.

  And the allocation process part 53 determines whether the process about all the unprocessed records was complete | finished (step S21). If it is not determined that the processing for all unprocessed records has been completed (step S21: No route), the process returns to step S5, and the next unprocessed record is extracted. On the other hand, when it is determined that the processing for all unprocessed records has been completed (step S21: Yes route), the allocation processing unit 53 refers to all the need registration tables stored in the need registration table storage unit 54. Then, it is determined whether there is a vehicle type for which provisional reservation data is registered for parts of a predetermined ratio (step S23). For example, it is determined whether there is a vehicle type in which the number of parts whose registered order number 604 has already been registered is, for example, 80% or more of the total number of parts corresponding to the vehicle type. Further, for example, the total price of parts for which the value of the registered order number 604 has already been registered (for example, the average value of prices at each seller) is the total price of the parts corresponding to the vehicle type (for example, the average value of prices at each seller) For example, it may be determined whether there is a vehicle type that is 80% or more. Further, for example, there is a vehicle type in which a predetermined point is associated with each component, and the total number of components for which the registered order number 604 has already been registered is, for example, 80% or more of the total points of the components corresponding to the vehicle type. You may make it determine whether there exists.

  When it is not determined that there is a vehicle type for which provisional reservation data is registered for parts of a predetermined ratio or more (step S23: No route), a series of processes in the used parts distribution server 5 is terminated. On the other hand, when it is determined that there is a vehicle type for which provisional reservation data is registered for parts of a predetermined ratio or more (step S23: Yes route), the allocation processing unit 53 performs seller allocation processing (step S25). Details of the seller allocation process will be described later. When the seller allocation process in step S25 ends, the series of processes in the used parts distribution server 5 ends.

  In this way, demand and supply are matched based on order data received within a predetermined period.

  FIG. 10 shows a processing flow after the transition through the terminal A. First, the allocation processing unit 53 of the used part distribution server 5 refers to the part vehicle DB 55 and extracts a vehicle type having a part (order part) desired by the user (FIG. 10: Step S31). Specifically, the value of the part number column 502 (FIG. 5) of the record currently being processed in the customer order DB 57 is specified, and the part mounting number 304 (FIG. 3) that matches the specified value (part number). ) Is extracted. For example, when the value of the part number 502 is “B001”, in the example shown in FIG. 3, the value of the first row and the eighth row of the part mounting number column 304 is “B001”. "S001" and "S002" are extracted.

Then, the allocation processing unit 53 refers to the seller DB 56 (FIG. 4), and determines whether any seller owns the extracted vehicle type (vehicle type having the ordered part) (step S33). When it is determined that there is no vehicle type (hereinafter referred to as a compatible vehicle type) having the ordered parts in the seller DB 56 (step S33: No route), the allocation processing unit 53 notifies the orderer that “there is no corresponding part”. Is sent (step S35). For example, the mail address registered in the contact column 506 (FIG. 5) of the record currently being processed in the customer ordering DB 57 with the message “The part you want is currently out of stock.” Send to. Furthermore, the allocation processing unit 53 transmits request data to all sellers (step S37). For example, the message “There was an order for part number B001” is transmitted to all the mail addresses registered in the contact column 404 (FIG. 4) of the seller DB 56. And a process transfers to the process of step S21 (FIG. 9 ) via the terminal C. FIG.

On the other hand, when it is determined that there is a compatible vehicle type in the seller DB 56 (step S33: Yes route), the allocation processing unit 53 identifies one of the compatible vehicle types (step S39). And the needs registration table management part 52 performs a needs registration table update process about the specified compatible vehicle type (step S41). Details of the needs registration table update process will be described later. When the needs registration table update process ends, the allocation processing unit 53 determines whether or not provisional reservation data has been registered for all the part numbers corresponding to the specified compatible vehicle type (step S43). That is, it is checked whether all the values in the registered order number column 604 of the needs registration table are registered. When it is determined that provisional reservation data has been registered for all part numbers (step S43: Yes route), the allocation processing unit 53 performs seller allocation processing (step S45). Details of the seller allocation process will be described later. And a process transfers to the process of step S21 (FIG. 9 ) via the terminal C. FIG. On the other hand, when it is not determined that provisional reservation data has been registered for all part numbers (step S43: No route), the allocation processing unit 53 determines whether the processing for all compatible vehicle types has been completed (step S47). . If it is not determined that the process for all compatible vehicle types has been completed (step S47: No route), the process returns to step S39, and one next compatible vehicle type is identified. On the other hand, when it is determined that the process for all compatible vehicle types has been completed (step S47: Yes route), the process proceeds to the process of step S21 (FIG. 9 ) via the terminal C.

  In this way, the process when the vehicle type is not specified by the user is performed.

  Details of the needs registration table update process (step S15 (FIG. 9) and step S41 (FIG. 10)) will be described with reference to FIG. First, as a premise of the needs registration table update process, the vehicle type and the user's desired (ordered) parts are specified one by one. Then, the needs registration table management unit 52 of the used parts distribution server 5 refers to the needs registration table storage unit 54 and determines whether there is a needs registration table for the specified vehicle type (FIG. 11: step S51). When it is determined that there is no need registration table for the specified vehicle type (step S51: No route), the process proceeds to step S55 described later. On the other hand, when it is determined that there is a needs registration table for the specified vehicle type (step S51: Yes route), the needs registration table management unit 52 registers registration orders corresponding to the user's desired parts in the needs registration table. It is determined whether the value in the number column 604 has already been registered (step S53). That is, it is confirmed whether or not a provisional reservation has already been made for the user's desired part by another order. If it is determined that the value in the registered order number column 604 corresponding to the user's desired part has already been registered (step S53: Yes route), the needs registration table management unit 52 newly generates a needs registration table. Then, a value (value in the order number column 500 of the customer order DB 57) is registered in the registered order number column 604 of the corresponding part row (step S55). In the new needs registration table, values are registered in the model number column 600 and the part number column 602 (FIG. 6) based on the specified model number and the data stored in the parts vehicle DB 55 (FIG. 3). In addition, no value is registered in the registered order number column 604 or “−” is registered. Then, the process returns to the original process. On the other hand, when it is determined that the value in the column 604 of the registered order number corresponding to the user's desired part has not yet been registered (step S53: No route), the needs registration table management unit 52 applies the corresponding registration table. The needs registration table is updated by registering a value (value in the order number column 500 of the customer order DB 57) in the registered order number column 604 of the part row to be processed (step S57). Then, the process returns to the original process.

  In this way, the needs registration table update process is performed, and temporary reservation data is registered for the user's desired parts.

  Details of the seller allocation process (step S19 (FIG. 9), step S25 (FIG. 9), and step S45 (FIG. 10)) will be described with reference to FIG. First, the allocation processing unit 53 of the used parts distribution server 5 determines whether there is one type of vehicle currently specified (FIG. 12: step S71). The seller allocation process in step S19 (FIG. 9) and step S45 (FIG. 10) is started with one specified vehicle type, and the seller allocation process in step S25 (FIG. 9) is specified. It starts with one or more types of vehicles.

  When it is determined that the specified vehicle type is one type (step S71: Yes route), the process proceeds to step S79 described later. At this time, a need registration table that satisfies the determination condition of the step immediately before the seller allocation process (step S17 (FIG. 9), step S23 (FIG. 9) or step S43 (FIG. 10)) is specified. In the case of the seller allocation process in step S25 (FIG. 9), even if the specified vehicle type is one type, there are a plurality of needs registration tables that satisfy the determination condition in step S23 (FIG. 9) for that vehicle type. May exist. In such a case, for example, the needs registration table generated earliest is specified.

  On the other hand, when it is determined that the specified vehicle type is not one type (step S71: No route), the allocation processing unit 53 determines whether there is a vehicle type designated by the user as the desired vehicle type (step S73). . Specifically, for each row of the needs registration table, the customer order DB 57 (FIG. 5) is referred to based on the value of the registered order number column 604 (FIG. 6), and a check is made as to whether the vehicle model name is registered in the desired vehicle type column 508. To do.

  When it is determined that there is a vehicle type designated by the user as the desired vehicle type (step S73: Yes route), the allocation processing unit 53 identifies one need registration table of the most frequently designated vehicle type (step S73). S75). When there are a plurality of needs registration tables for the most desired and designated vehicle types, for example, the needs registration table generated earliest is specified. Then, the process proceeds to step S79 described later. On the other hand, when it is determined that there is no vehicle type designated by the user as the desired vehicle type (step S73: No route), the allocation processing unit 53 has a needs registration table for a vehicle type in which the seller has the most vehicles. Is identified (step S77). When the seller DB 56 does not include data on the number of vehicles as in the example shown in FIG. 4, the allocation processing unit 53 acquires the number data with reference to the product DB of each seller server. There are also cases in which each merchant server is inquired. In addition, when there are a plurality of needs registration tables for a vehicle type in which the seller has the most vehicles, for example, the earliest need registration table is specified.

  Then, the allocation processing unit 53 determines whether there are a plurality of sellers who own the vehicle type corresponding to the identified needs registration table (step S79). The determination is made with reference to the column 406 (FIG. 4) of the owned vehicle type in the seller DB 56. When it is determined that there are not a plurality of sellers who own the vehicle type corresponding to the identified needs registration table (step S79: No route), that is, when the sellers can be narrowed down to one person or one dealer, the allocation process The unit 53 transmits an order notification to the seller (step S81). The notification to the seller may be performed using e-mail as described above, for example. Specifically, based on the specified needs registration table, notification data including the vehicle type and the order part number is generated and transmitted. And it transfers to the process of step S91 mentioned later.

  On the other hand, when it is determined that there are a plurality of sellers who own the vehicle type corresponding to the identified needs registration table (step S79: Yes route), the allocation processing unit 53 has a vehicle whose scheduled dismantling date has been determined. (Step S83). Specifically, the disassembly date data (value in disassembly date column 704 (FIG. 7)) of the vehicle corresponding to the specified vehicle type is acquired with reference to the product DB of each seller server. There are also cases in which each merchant server is inquired. When it is determined that there is a vehicle whose scheduled dismantling date has been determined (step S83: Yes route), the allocation processing unit 53 transmits an order notification to the seller having the vehicle whose scheduled dismantling date is the earliest (step S83). S85). And it transfers to the process of step S91 mentioned later.

  On the other hand, when it is determined that there is no vehicle for which the scheduled dismantling date has been determined (step S83: No route), the allocation processing unit 53 has already been provisionally reserved (registered order number column) in the identified needs registration table. Based on the part number (the order number is registered in 604 (FIG. 6)), the parts price DB of each seller server is searched (step S87). There are also cases in which each merchant server is inquired. Then, the allocation processing unit 53 identifies the seller with the lowest total price of the tentatively reserved parts, and transmits an order notification to the seller (step S89).

  Then, the allocation processing unit 53 registers “O” in the column 510 of the ordered flag in the record corresponding to the order data for which the order notification has been made among the records stored in the customer order DB 57 (FIG. 5). . Furthermore, the allocation processing unit 53 clears all the need registration tables (step S93). Then, the process returns to the original process.

  In this way, the seller allocation process is performed. Thereby, an appropriate seller can be specified according to the order (reservation) situation.

  As described above, by executing the processing as described with reference to FIGS. 9 to 12, it is possible to appropriately distribute parts according to demand. In the present embodiment, since all the need registration tables are cleared in step S93 (FIG. 12), for example, even when there are a plurality of need registration tables that satisfy the condition of step S23 (FIG. 9), all of them are once cleared. It is supposed to be. Therefore, when there are a plurality of needs registration tables that satisfy the condition of step S23 (FIG. 9), after the elapse of a predetermined period (see step S3 (FIG. 9)), the needs registration table is generated again and based on the needs registration table. Processing is executed. Therefore, when there are a plurality of need registration tables that satisfy the condition of step S23 (FIG. 9), the process may return to step S5 (FIG. 9) after the seller allocation process in step S25 (FIG. 9). . Similarly, when there are a plurality of need registration tables that satisfy the condition of step S23 (FIG. 9), not all the need registration tables are cleared in step S93 (FIG. 12), but the need registration tables that have already been ordered. Alternatively, only the provisional reservation data registered in the other needs registration table overlapping with the needs registration table may be cleared and the process may return to step S23 (FIG. 9).

  Further, for example, order data that is not processed for a relatively long period of time, such as one week or one month, is separately extracted, and the request data is notified to all sellers or sellers having vehicles that can take out the ordered parts. It may be. In this case, items such as the order date are provided in the customer order DB 57 (FIG. 5).

  Although one embodiment of the present invention has been described above, the present invention is not limited to this. For example, the table configurations shown in FIGS. 3 to 8 are examples, and other configurations may be adopted as long as similar data is stored, and items are added or deleted as necessary. May be. Moreover, the functional block configuration of the used parts distribution server 5 shown in FIG. 1 is an example, and may differ from the actual program module configuration. Each device may be configured by a plurality of servers and computers. The functional block diagram of the computer shown in FIG. 2 is also an example, and may be different from the actual hardware configuration. The processing flows shown in FIGS. 9 to 12 are also examples, and the processing order may be changed within a range in which similar processing results are obtained, and steps may be added or deleted as necessary.

  Although the embodiment has been described using an example applied to a used part of a vehicle, it is also possible to apply the technology according to the present invention to various other parts distribution systems, such as a part of a personal computer. .

(Appendix 1)
A parts distribution program for distributing parts taken out by dismantling a vehicle,
Referring to an order data storage unit storing part order data from the user, identifying unordered part order data, and storing it in a storage device;
Related data of unordered parts specified from the unordered parts order data and vehicle dismantling parts that are stored in advance in the parts vehicle data storage unit and can be taken out by disassembling the vehicles of the relevant car types And a vehicle disassembly part corresponding to the unordered part, a vehicle type whose ratio to the whole is equal to or greater than a predetermined threshold, and a priority dismantling vehicle type specifying step for storing in the storage device as a priority dismantling vehicle type;
Parts distribution program that causes computers to execute.

(Appendix 2)
The priority dismantling vehicle type specifying step includes
Inventory check for determining whether or not data on dismantling candidate vehicles from which vehicle dismantling parts corresponding to the unordered parts can be taken out is registered in an inventory vehicle data storage unit in which data relating to vehicles owned by the dismantling company is stored Steps,
When it is determined in the inventory checking step that data on the dismantling candidate vehicle is registered, provisional reservation data of the vehicle dismantling part corresponding to the unordered part is set to a vehicle type specified from the dismantling candidate vehicle. Including a provisional reservation step to be registered in the generated needs registration table,
The part distribution program according to claim 1, wherein a ratio of vehicle dismantling parts corresponding to the unordered parts to the whole is calculated based on data registered in the needs registration table.

(Appendix 3)
In the inventory confirmation step,
When the unordered parts order data includes data specifying a specific vehicle type, the dismantling candidate vehicle that is a vehicle of the specific vehicle type and can take out the vehicle dismantling parts corresponding to the unordered parts The part distribution program according to appendix 2, characterized in that it is determined whether or not the data about is registered.

(Appendix 4)
In the provisional reservation step,
3. The parts distribution program according to claim 2, wherein when there are a plurality of vehicle types corresponding to the dismantling candidate vehicles, the provisional reservation data is registered for the need registration tables of all corresponding vehicle types.

(Appendix 5)
In the provisional reservation step,
The part distribution according to claim 2, wherein when the unordered parts order data includes data specifying a specific vehicle type, the provisional reservation data is registered in the need registration table of the specific vehicle type. program.

(Appendix 6)
In the provisional reservation step,
The provisional reservation data is registered in a plurality of needs registration tables for the specific vehicle type when there are a plurality of unordered parts corresponding to vehicle dismantling parts of a specific vehicle type. Parts distribution program.

(Appendix 7)
The priority dismantling vehicle type specifying step includes
The part distribution program according to supplementary note 2, further comprising a step of transmitting data relating to the unordered part to a dismantling contractor when it is determined in the inventory checking step that data regarding the dismantling candidate vehicle is not registered.

(Appendix 8)
Referring to an inventory vehicle data storage unit in which data relating to vehicles owned by the dismantling company is stored, the dismantling company that owns the vehicle corresponding to the priority dismantling vehicle type stored in the storage device is specified, and the unordered parts The parts distribution program according to appendix 1, further causing the computer to execute a dismantling contractor determination step of associating the dismantling contractor with the dismantling contractor and storing the dismantling contractor in the ordering data storage unit as ordering data.

(Appendix 9)
The dismantling company determination step includes
When there are a plurality of priority dismantling vehicle types, refer to the stock vehicle data storage unit in which data related to designation of a specific vehicle type included in the unordered parts order data and data related to vehicles owned by the dismantling company are stored The part distribution program according to supplementary note 8, including a step of specifying one type of vehicle based on at least one of the number of vehicle stocks specified by vehicle type.

(Appendix 10)
The dismantling company determination step includes
When there are a plurality of dismantling contractors who own vehicles corresponding to the priority dismantling vehicle type stored in the storage device, it is specified by referring to an inventory vehicle data storage section in which data relating to vehicles owned by the dismantling contractor is stored. The step of identifying one dismantling contractor based on at least one of the planned dismantling date of the vehicle and the total order price calculated based on the part price data for each dismantling contractor stored in the parts price storage unit The parts distribution program according to appendix 8, including

(Appendix 11)
A parts distribution method for distributing parts taken out by dismantling a vehicle,
Referring to an order data storage unit storing part order data from the user, identifying unordered part order data, and storing it in a storage device;
Related data of unordered parts specified from the unordered parts order data and vehicle dismantling parts that are stored in advance in the parts vehicle data storage unit and can be taken out by disassembling the vehicles of the relevant car types And identifying a vehicle type in which the proportion of the vehicle dismantling parts corresponding to the unordered parts is greater than or equal to a predetermined threshold value, and storing it in the storage device as a priority dismantling vehicle type;
A parts distribution method executed by a computer.

(Appendix 12)
A parts distribution device for distributing parts taken out by dismantling a vehicle,
Means for referring to an order data storage unit storing part order data from a user, identifying unordered parts order data, and storing the data in a storage device;
Related data of unordered parts specified from the unordered parts order data and vehicle dismantling parts that are stored in advance in the parts vehicle data storage unit and can be taken out by disassembling the vehicles of the relevant car types A vehicle disassembly part corresponding to the unordered part, a vehicle type whose ratio to the whole is equal to or greater than a predetermined threshold, and storing in the storage device as a priority dismantling vehicle type;
A parts distribution apparatus.

1 is a system configuration diagram according to an embodiment of the present invention. It is a figure which shows the outline | summary of the functional block of the computer in embodiment of this invention. It is a figure which shows an example of components vehicle DB table. It is a figure which shows an example of a seller DB table. It is a figure which shows an example of a customer order DB table. It is a figure which shows an example of a needs registration table. It is a figure which shows an example of goods DB table. It is a figure which shows an example of components price DB table. It is a figure which shows the 1st part of the processing flow in one embodiment of this invention. It is a figure which shows the 2nd part of the processing flow in one embodiment of this invention. It is a figure which shows the processing flow of a needs registration table update process. It is a figure which shows the processing flow of a seller allocation process.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Network 3 User terminal 5 Used parts distribution server 7 A seller server 9 B seller server 11 C seller server 51 Order reception part 52 Needs registration table management part 53 Provision processing part 54 Needs registration table storage part 55 Parts vehicle DB 56 Seller DB
57 Customer Order DB
71, 91, 111 Product DB
72, 92, 112 Parts price DB

Claims (5)

A parts distribution program for distributing parts taken out by dismantling a vehicle,
Computer
The unprocessed orders stored in the customer order database that stores the data of the parts related to the orders are processed in the needs registration table storage unit in which the data of the vehicle dismantling parts that can be taken out from the vehicle is stored for each vehicle type. Means for registering in association with a vehicle dismantling part corresponding to a part related to the order;
From the needs registration table storage unit, a vehicle type in which a ratio of the number of the vehicle dismantling parts with which the order is associated with the total number of the vehicle dismantling parts of one vehicle type is a predetermined value or more is specified, and the vehicle type of the specified vehicle type In the data, the seller database in which the data of the seller and the vehicle type data of the vehicle owned by the seller are stored in association with each other is searched, and the seller who owns the vehicle of the specified vehicle type is specified. Provision processing section
Parts distribution program characterized by functioning as A parts distribution program for distributing parts taken out by dismantling a vehicle,
Computer
The unprocessed orders stored in the customer order database that stores the data of the parts related to the orders are processed in the needs registration table storage unit in which the data of the vehicle dismantling parts that can be taken out from the vehicle is stored for each vehicle type. Means for registering in association with a vehicle dismantling part corresponding to a part related to the order;
For the vehicle type having the vehicle dismantling part associated with the order in the needs registration slip storage unit, each vehicle dismantling part of the vehicle dismantling part is stored from the part price database in which the part data and the price of the part are stored in association with each other The price is extracted, the vehicle type in which the ratio of the total price of the vehicle dismantling part with which the order is associated with the total price of the vehicle dismantling part of one car type is a predetermined value or more is specified, and the data of the specified car type And searching the seller database in which the data of the seller and the vehicle type data of the vehicle owned by the seller are stored in association with each other, and the provision for specifying the seller who owns the vehicle of the specified vehicle type Processing part
Parts distribution program characterized by functioning as If there are a plurality of the specified sellers, search the product database in which the vehicle type data and the disassembly date data of the vehicle of the vehicle type are stored in association with the specified vehicle type data. The dismantling date data of the vehicle of the selected car type is specified for each of the sellers, and the allocation processing unit is caused to function so as to specify the seller with the earliest dismantling date from among the plurality of sellers
The parts distribution program according to claim 1 or 2, characterized in that A parts distribution method for distributing parts taken out by dismantling a vehicle,
Computer
The unprocessed orders stored in the customer order database that stores the data of the parts related to the orders are processed in the needs registration table storage unit in which the data of the vehicle dismantling parts that can be taken out from the vehicle is stored for each vehicle type. Registering in association with a vehicle dismantling part corresponding to a part related to the order;
Identifying a vehicle type in which a ratio of the number of the vehicle dismantling parts with which the order is associated with a total number of the vehicle dismantling parts of one vehicle type is a predetermined value or more from the needs registration table storage unit;
Search the seller database in which the data of the seller and the data of the vehicle type of the vehicle owned by the seller are stored in association with the data of the specified vehicle type, and own the vehicle of the specified vehicle type An allocation step to identify the merchant to
The parts distribution method characterized by performing. A parts distribution method for distributing parts taken out by dismantling a vehicle,
Computer
The unprocessed orders stored in the customer order database that stores the data of the parts related to the orders are processed in the needs registration table storage unit in which the data of the vehicle dismantling parts that can be taken out from the vehicle is stored for each vehicle type. Registering in association with a vehicle dismantling part corresponding to a part related to the order;
For the vehicle type having the vehicle dismantling part associated with the order in the needs registration slip storage unit, each vehicle dismantling part of the vehicle dismantling part is stored from the part price database in which the part data and the price of the part are stored in association with each other Extracting a price and identifying a vehicle type in which a ratio of a total price of the vehicle dismantling parts with which the order is associated with a total price of the vehicle dismantling parts of one vehicle type is a predetermined value or more;
Search the seller database in which the data of the seller and the data of the vehicle type of the vehicle owned by the seller are stored in association with the data of the specified vehicle type, and own the vehicle of the specified vehicle type An allocation step to identify the merchant to
The parts distribution method characterized by performing.

Images