JP2011059796A - Article transaction management system and article transaction management program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a mechanism for encouraging a participant to voluntarily transfer an article to the others without charge. <P>SOLUTION: An exchange ticket constituted of an expiration date and the personal identification information of an owner is registered in an exchange ticket management database 128. A CPU periodically registers the exchange ticket having each member as its owner in an exchange ticket management database 128. Also, when an instruction to hand over an article on consignment registered in a merchandise storage table 124 to a third person is input, as long as the exchange ticket within the expiration date with an assignee as its owner is registered in the exchange ticket management database 128, the CPU 11 rewrites the owner ID registered in the merchandise storage table 126 about the article with the owner ID of the assignee, and changes the owner ID registered in the exchange ticket management database 128 about the exchange ticket to the owner ID of the assignee. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to an article transaction management system and an article transaction management program for supporting a transaction for transferring the ownership of an article between individuals.

A warehouse operator is a person whose business is to store goods in a warehouse for others (Commercial Code 597).
Article). With regard to the deposits that the warehouse operator has deposited with the depositor, the depositor can trade with a third party. If the depositor who transferred the deposit to a third party instructs the warehouse operator to store the deposit for the transferee, and the third party (transferee) approves, The occupancy of the deposit will also be transferred to the assignee (Civil Code Article 184), which will also be a requirement for the delivery of goods. For this reason, in the past, it has been common for merchants to buy and sell deposits outside the warehouse, regardless of whether deposit securities or warehouse cargo (Article 598) is issued.

  On the other hand, since the warehouse business offers small goods storage services to general consumers, it is considered that the use of network technology can realize off-warehouse transactions of deposits among general consumers.

In addition, the transfer of ownership of goods is performed only by the intention of the parties (Civil Code Article 176) and does not require any occupational transfer or any other physical property act. It is also possible to transfer ownership of the goods from the assignee from the original owner to a third party while remaining with the original owner. In this case, the person who finally obtained ownership can make a delivery request for the article to the original owner who is the occupant.

JP 2008-171071 A

  Of course, goods that general consumers use for transactions are often used or hand-crafted products, and therefore do not always have universal value. However, since goods that are low in value for the owner may be beneficial to others even if they are not sold, there is a need to develop a market where goods can be transferred free of charge between general consumers.

  However, since the free transfer of goods is based on the good intentions of the transferor and the spirit of mutual assistance, it is desirable to transfer the goods to the person who really needs the goods to be transferred. It is not desirable that only those who don't offer anything, or those who want goods for the purpose of selling through their own antiquarian sales route, receive a free transfer. In the latter situation, since the transferor's good intentions and mutual support spirit are not satisfied, the transferor's willingness to transfer goods for free will decline thereafter, and as a result, there will be a market where free transfer will be conducted among general consumers. It is because it will be stagnant.

  Therefore, the subject of the present invention can promote each participant who participates in such a market to voluntarily transfer the item to another person in order to activate the market for free transfer of the item between individuals. It is to provide a mechanism.

  In the article transaction management system according to the present invention, the first storage unit in which the individual identification information of the participant is registered and the identification information and the individual identification information of the owner are registered in association with each article. A second storage unit, a third storage unit in which an electronic ticket comprising an expiration date and personal identification information of the owner is registered, an input interface for inputting information, and the first storage unit periodically For each individual identification information of each participant registered in the storage unit, the electronic identification ticket having the personal identification information as the owner's personal identification information and setting a predetermined expiration date is used. Electronic ticket issuing means for registering in a storage unit; identification information for an article to be transferred from a transferor who is an owner whose personal identification information is registered in the second storage unit to the input interface; and , Is the assignee When the other person's personal identification information is input, the assignee's personal identification information is used as the owner's personal identification information, and an electronic ticket that is still valid is registered in the second storage unit. Only when the owner's personal identification information registered in the second storage unit corresponding to the identification information of the article is changed to the assignee's personal identification information, and the third storage Changing means for changing the personal identification information of the owner of the electronic ticket stored in the section to the personal identification information of the transferor.

  In addition, the article transaction management program according to the present invention has an input interface for inputting information, and the first storage unit in which the individual identification information of the participant is registered, the identification information and the owner for each article A second storage unit that is registered in association with the personal identification information, and a computer that can access the third storage unit in which an electronic ticket including the expiration date and the personal identification information of the owner is registered The personal identification information of each participant registered in the first storage unit is periodically used as the owner's personal identification information, and a predetermined expiration date is set. The electronic ticket issuing means for registering the electronic ticket to be registered in the third storage unit, and the transfer that is the owner whose personal identification information is registered in the second storage unit in the input interface When the identification information of an article to be transferred to another person and the personal identification information of the other person who is the assignee are input, the personal identification information of the assignee is used as the owner's personal identification information and still Only when an electronic ticket within the expiration date is registered in the second storage unit, the personal identification information of the owner registered in the second storage unit corresponding to the identification information of the article And changing the personal identification information of the electronic ticket stored in the third storage unit to the personal identification information of the transferee, and changing the personal identification information of the owner of the electronic ticket stored in the third storage unit. .

  According to the present invention configured as described above, it is possible to promote each participant registered in the first storage unit so as to proceed and transfer the article to another person for free. As a result, it is possible to activate a market for transferring goods for free between individuals.

The block diagram which shows schematic structure of the network system which is embodiment of a warehouse management assistance system Table showing data structure of member management database Table showing the data structure of the owner table Table showing the data structure of the dead space table Table showing the data structure of the product storage table Table showing the data structure of the consignment request table and pick-up item request table Table showing the data structure of the exchange ticket management database Table showing the data structure of the exchange history management database Flow chart showing contents of member registration process Flow chart showing the contents of the exchange ticket issuing process Flow chart showing the contents of dead space update application processing Flow chart showing the contents of the deposit request process Flow chart showing the contents of the product registration process Flow chart showing the contents of the product registration process Flow chart showing the contents of member access processing Flow chart showing the contents of member access processing 15 is a flowchart showing the ownership change processing subroutine executed in S420 of FIG. 15 and S430 of FIG. FIG. 15 is a flowchart showing a takeover subroutine executed in S406 of FIG. Flow chart showing contents of billing process Figure showing contents of My Page screen Diagram showing the contents of the top page screen Illustration of transaction example Illustration of transaction example Illustration of transaction example Illustration of transaction example

<Premise explanation>
Hereinafter, an example of an embodiment of an article transaction management system according to the present invention will be described based on the drawings. In the example shown below, a telecommunications carrier (for example, an Internet content provider) who has signed a business consignment contract with a warehouse operator operates a warehouse management system, and through that operation, brokers the deposit contract between each customer and the warehouse contractor. This is an example of mediating transfer (sales contract, gift) of deposits between customers. However, the present invention is not limited to such a form, and the warehouse operator may operate the warehouse management system. In addition, it is assumed that a deposit agreement is concluded between the warehouse operator and the customer, but a deposit agreement is concluded between the telecommunications carrier and the customer, and the warehouse operator is re-deposited by the telecommunications carrier. And may be configured. Furthermore, the system is configured to mediate transfer between the original owner and the transferee, not for the goods deposited with the warehouse operator, but for the articles that are reserved by the original owner. Also good.

In order to distinguish comprehensive deposit contracts concluded through intermediary using this warehouse management system from regular deposit contracts and fixed space lending deposit contracts, we will refer to them as “volume fixed comprehensive deposit contracts”. Called.
<System configuration>
FIG. 1 is a block diagram illustrating a schematic configuration of a network system including a warehouse management system according to an embodiment. As shown in FIG. 1, this network system includes a warehouse operator terminal 2, which is a network terminal (computer) installed in a business office C of a warehouse operator, and a network terminal (computer) used by each customer. ) Is a large number (only three are shown in FIG. 1) of the user terminal 3 and the warehouse management server 1 that can communicate with each of the terminals 2 and 3 through the network (for example, the Internet) N. .

  The warehouse operator terminal 2 is a computer having a normal configuration having a network connection function, and includes a CPU 21, a hard disk 22, a printer 23, a communication adapter 24, an input device 25, and a display 26 connected to each other through a bus.

  The hard disk 22 is a storage medium that stores various programs such as an OS (Operating System) and a web browser program 221.

  The CPU 21 is a central processing unit that reads and executes each program read from the hard disk 22 (corresponding to electronic ticket issuing means and changing means).

  The input device 25 is a keyboard, pointing device, bar code reader, RF-ID reader or the like used for inputting various commands and various data to the CPU 21.

  The display 26 is an output device that displays a processing result by the CPU 21.

  The communication device 24 converts a message addressed to the warehouse management server 1 generated by the CPU 21 into communication data according to a protocol corresponding to the network N and sends it to the network N, or communication data received from the warehouse management server 1 through the network N. Is converted into a data format that can be processed by the CPU 21 and input to the CPU 21.

  The printer 23 is an output device that performs printing based on print data in accordance with an instruction from the CPU 21.

  The user terminal 3 is also a computer having a normal configuration having a network connection function, and includes a CPU 31, a hard disk 32, a communication adapter 34, an input device 35, and a display 36 connected to each other through a bus. Since each part which comprises the user terminal 3 is completely the same as the thing of the warehouse operator terminal 2, the description is abbreviate | omitted.

  The warehouse management server 1 can actually be composed of a plurality of server computers and disk devices, but in FIG. 1, it is simplified as being composed of a single server computer. That is, the warehouse management server 1 shown in FIG. 1 includes a CPU 11, a communication adapter 14, a RAM (Random Access Memory) 13, and a hard disk 12 connected to each other by a bus B.

  Among these, the CPU 110 is a central processing unit (computer) that controls the entire warehouse management server 1 and corresponds to a specifying unit and an updating unit.

  The RAM 13 is a main storage device in which a work area is expanded when the CPU 11 executes various processes.

  The communication adapter 14 is connected to a dedicated line connected to the network N directly (through a corporate LAN or router 4 (not shown)) to the network N. From the terminals 2 and 3 through the network N, the communication adapter 14 is connected. The received communication data is converted into a data format that can be processed by the CPU 11 and input to the CPU 11, or the message addressed to each terminal 2, 3 generated by the CPU 11 is converted into communication data according to the protocol for the network N, and the network It is an input interface and output device that sends to N.

  The hard disk 12 is a storage device that stores various programs and various data that are read and executed by the CPU 11.

  The various programs stored in the hard disk 12 and executed by the CPU 11 include a program (OS [Operating System], a web server program, an authentication system, etc.) normally required for the warehouse management server 1 to function as a web server device. As a commodity transaction management system that mediates the conclusion of fixed-volume, comprehensive deposit agreements between customers and warehouse operators, and the transfer of deposits between customers. A warehouse management program 121 for realizing these functions is included.

In addition, the various data stored in the hard disk 13 include the travel management program 1 described above.
21. Various databases or tables (member management database 123, owner table 124, dead space table 125, merchandise storage table 126, consignment request table / collected goods request table, which are referred to according to 21 and registered according to the warehouse management program 1) 127, an exchange ticket management database 128, an exchange history management database 129), and various screens or form data 122 are included.

  The member management database 123 has personal information (member information) for each customer (that is, a member) who has concluded a fixed volume deposit agreement with a warehouse operator through the mediation of a communication company that operates the warehouse management server 1. It is a database that has a record in which is registered. As shown in FIG. 2, each record constituting the member management database 123 includes a “name” field in which a member's real name is registered, and an “owner ID” in which a member's personal identifier (owner ID) is registered. Column, “authentication data” field in which data for acceptance such as a password is registered, “my page URL” field in which a URL (Uniform Resource Locator) of a web page (my page) generated exclusively for members is registered, "Billing information" field for registering information (for example, credit card number) on how to collect the credits generated for the member, "Address" field for registering the member's address, fixed volume type signed by the member “Monthly billing amount” field where the monthly deposit fee determined according to the contents (volume) of the contract is registered, the flag is reset every six months after the member enters into a fixed volume contract and the member concerned A "free delivery flag" field in which a flag is set when a take-off process to be described later is executed, and a delivery fee is added each time a take-off process to be described later is executed with the free delivery flag being reset. “Additional Month” column, “E-mail Address” column, etc. The portion of the hard disk 12 that stores the member management database 123 corresponds to the first storage unit.

  In the member management database 123, personal information about all members who have signed a content provision service provision contract with the communication carrier is registered, while in the owner table 124, which will be described later, registered in the member management database 123. Of the registered members, only information on members who have signed a fixed volume deposit agreement with the warehouse operator through the mediator's mediation may be registered. In that case, only the monthly fee of the content providing service is registered for the members who have not signed the fixed volume deposit contract in the monthly billing amount of the member management DB 123, and the members who have signed the fixed volume deposit contract The total amount of monthly fee and monthly deposit fee for content providing service is registered.

As shown in FIG. 3, the owner table 124 has a record for each member who has signed a fixed volume deposit agreement with the warehouse operator, and each record has an upper limit volume [unit: m ³ ] is registered in the “Contract space” field, the total volume of the deposit currently being deposited [unit:
m ³ ] is registered in the “Usage space” field, and the remaining volume obtained by subtracting the total volume of the deposits currently deposited from the upper limit volume [unit: m ³ ] is registered in the “Remaining space” field. It is a table having a record consisting of

The dead space table 125 is a table for managing the accommodation situation of each donated object for each physical storage space of each warehouse owned (owned or occupied) by the warehouse operator. Here, the physical storage space of the warehouse owned (owned or occupied) by the warehouse operator will be described. As shown in FIG. 1, the warehouse operator owns one or a plurality of warehouses. When a plurality of warehouses are held, each warehouse may be built on the same site, or may be built on a plurality of discrete sites. Each warehouse is physically limited to a plurality of spaces. In this way, each physically partitioned space is a “physical storage space”, which is a standard for dead space management. Specifically, the “physical storage space” may be defined as a room, a shelf, a locker, or a box, for example. FIG. 4 shows that a warehouse operator has two warehouses (A warehouse and B warehouse), and A warehouse has three physical storage spaces (A1-3-1, A4).
-4-2, A4-4-3) and an example of the dead space table 125 in the case where the B warehouse is composed of one physical storage space (B1-1-1).

  As shown in FIG. 4, each record of the dead space table 125 corresponds to an individual physical storage space, and a “warehouse name” column in which the name of the warehouse is described, and identification of the physical storage space, respectively. “Position No.” field where information (position number) is registered, height (X), width (Y), and depth (Z) dimensions [unit: m] of physical storage space are registered. "Space" column, where the dimensions (unit: m) of the height (X), width (Y), and depth (Z) of the space (empty space) that can be further stored in the physical storage space are registered ”Column,“ Storage method (direction) ”column that specifies the accommodation direction (in which direction) the donated object is accommodated with respect to the empty space, and“ Available space ”in which the size (unit: m) of the empty space in the storage direction is registered Columns and physical storage space The number of housing already depositary object is created from the "number of storage" column, constructed.

The product storage table 126 is a table for managing information about each deposit deposited with the warehouse operator in accordance with a fixed volume deposit contract. That is, as shown in FIG. 5, the commodity storage table 126 has a record for each received item, and each record is stored in the received item or its curing case by the warehouse operator when depositing the received item. The “stored unique ID” field in which the ID (stored unique ID) of the attached electronic tag is registered, the “type” field in which the type of the received item is registered, and the code printed on the received item (ISDN code, JAN code, Etc.), the “product name” column where the product name of the consignment is registered, the “product image” column where the product image data itself or the URL of the product image data is registered, by the depositor “Condition by declaration” field where the condition of the declared receipt is registered, and the condition evaluated by the warehouse operator inspecting the receipt at the time of deposit is registered. “Condition” column, “Owner ID” column where the personal identifier (owner ID) of the current owner of the donated item is registered, or whether the owner simply stores the donated item (“stores”) The “Product Status” field where the status (product status) is registered for whether it is being sold (“Sell”) or being transferred for free (“Give”), the owner wants to publish the donated goods (“Public”) “Public Status” column where the status (public status) is registered about whether it is desired to be private (“non-public”), the donated items are stored in the physical storage space naked In some cases, the height (X), width (Y), and depth (Z) dimensions [unit: m] of the donated object itself are registered, while the donated object is stored in a curing case and physically stored. If you are housed in a space The height of the curing Case (X), width (Y), the dimensions [Unit: m] depth (Z) is "product Size" column to be registered, the volume of depositary material [unit: m ^3] is registered “Volume” column and “Sell” column in which the sale price [unit: yen] is registered when the product status is “Sell” for the donated goods. The portion of the hard disk 12 that stores the product storage table 126 corresponds to the second storage unit.

  The deposited item request table / collected item request table 127 is a table in which the work status of the warehouse operator for each deposited item is registered. That is, as shown in FIG. 6, the deposit request table / collected item request table 127 has a record for each deposit, and each record has a personal identifier (owner) of the depositor (owner). ID) is registered in the “Owner ID” field, the “Product Name” field in which the product name of the consignment is registered, the “Condition Condition” field in which the condition of the consignment declared by the depositor is registered, and the deposit "Request date" field for registering the date (request date) on which the warehouse requested the warehouse management server 1 to be registered, and "arrival date" for registering the date (arrival date) when the deposit was received by the warehouse operator Column and a “work status” column in which work progress is registered.

The exchange ticket management database 128 is a database in which “exchange ticket” itself, which is electronic data representing the right to receive the transfer of deposits set by other people as “product status” = “I want to give”, is registered. is there. That is, as shown in FIG. 7, the exchange ticket management database 128 has a record for each exchange ticket, and each record is registered with identification information (ticket ID) for uniquely identifying the exchange ticket. "Ticket ID" field, "Nominee" field where the owner ID of the owner at the time of issuance is registered, "Owner" field where the owner ID of the current owner is registered, and the expiration date of the exchange ticket is registered From the “expiration date” column. The portion of the hard disk 12 that stores the exchange ticket management database 128 corresponds to a third storage unit.

The exchange history management database 129 is a database in which the transaction history of deposits made using exchange tickets is recorded. That is, as shown in FIG. 8, the exchange history management database 129 has a record for each transaction, and each record has a “transaction partner” column in which owner IDs of both parties of the transaction are registered. , And the “transaction” column in which the trade name of the transaction object is registered.
<Processing contents by warehouse management program>
Hereinafter, with reference to the flowcharts of FIGS. 9 to 18, the contents of processing executed by the CPU 11 according to the warehouse management program 121 will be described.
[When registering as a member]
The member registration process shown in the flowchart of FIG. 9 is a process for a customer who is not registered as a member in the member management database 123 to apply for a new fixed volume deposit contract. This member registration process starts when a member registration request message is received from the user terminal 3 that is being operated by the customer and executing the process by the web browser program 321.

  In first S001 after the start, the CPU 11 transmits the screen / form data 122 of the membership application screen to the user terminal 3 that is the message transmission source. This membership application screen includes a “name” field, a “billing information” field, an “address” field, an “e-mail address” field in the member management DB 123 shown in FIG. 2, and a “contract space” in the owner table shown in FIG. Each of the fields includes an input field corresponding to each field, and an item with a tag for transmitting a message having information input to each input field as a parameter to the warehouse management server 1.

  In step S002, the CPU 11 waits for the message from the user terminal 3 and receives the message. In step S003, the CPU 11 generates an owner ID, a my page URL, and authentication data. Further, the CPU 11 determines the monthly billing amount based on the value of “contract space” included in the message.

  In the next S004, the CPU 11 registers member information including each parameter (excluding the contract space) in the message received in S002 and information generated and determined in S003 in the member management database 123.

  In the next S005, the CPU 11 adds a new record based on the contract space value in the message received in S002 and the owner ID generated in S002.

In the next S006, the CPU 11 generates a new ticket ID and registers a new record for the ticket ID in the exchange ticket management database 128. At this time, the CPU 11 stores the owner ID generated in S003 in the “name” column and “owner” column of the new record, and the date one month after the processing point in the “expiration date” column. Write each one. When S006 is completed, the CPU 11 ends the member registration process.
[Issue exchange ticket]
The exchange ticket issuing process shown in FIG. 10 is a process as electronic ticket issuing means for newly issuing one exchange ticket for each member for each predetermined period.

  The exchange ticket issuing process is automatically executed, for example, every month. The period of this exchange ticket issuing process is preferably the same as the validity period initially set in the exchange ticket, but the former may be longer than the latter.

  In the first S 801 after the start, the CPU 11 generates a new ticket ID for each owner ID of each member registered in the member management database 123.

In next step S802, for each member owner ID, the CPU 11 sets the owner ID as a value in the “name holder” column and the “owner” column, and sets the ticket ID generated in S801 in the “ticket ID” column. A new record to be registered is registered in the new exchange ticket management database 128. At this time, the CPU 11 writes the date after a predetermined period (for example, one month later) from the time of processing in the “expiration date” column of each new record. When S802 is completed, the CPU 11 ends the exchange ticket issuing process.
[When applying for dead space update]
The dead space renewal application process shown in FIG. 11 depends on circumstances other than the fixed volume deposit contract mediated by the carrier, and the storage situation of the donated items in each physical storage space of each warehouse held by the warehouse operator. This is a process for reflecting the fact in the dead space table 125 when the fluctuation occurs. This dead space update application process is performed when the CPU 11 of the warehouse management server 1 that has received the dead space application message from the warehouse operator terminal 2 executing the process by the web browser program 221 has succeeded in the predetermined authentication process. To start.

  In the first S101 after the start, the CPU 11 transmits the screen / form data 122 of the application screen to the warehouse operator terminal 2 that is the message transmission source. In this application screen, several input fields for specifying how the storage space of which physical storage space of which warehouse has changed (expanded or reduced), and input in each input field An item with a tag that causes the warehouse management server 1 to transmit a message having the information as a parameter to the warehouse management server 1 is included.

In step S102, the CPU 11 waits for the message from the warehouse operator terminal 2 and receives the message. In step S103, according to the parameters in the message, the “accommodable space” for the corresponding physical space in the dead space table 125. Update the registration contents in the column and the registration contents in the “free space” column. When S103 is completed, the CPU 11 ends the dead space update application process.
[At the time of deposit request]
The deposit request processing shown in the flowchart of FIG. 12 is performed by a member of the warehouse management company before the member registered in the member management database 123 sends a certain deposit to the warehouse operator (mailing or transporting). This is a process for requesting a depositor to make a deposit. In this deposit request processing, the CPU 11 of the warehouse management server 1 that has received the deposit request message from the user terminal 3 that is operated by the member and that is executing the processing by the web browser program 321 operates the user terminal 3. The process starts when a predetermined authentication process for the owner ID transmitted from the person is successful.

  In the first step S201 after the start, the CPU 11 transmits the screen / form data 122 of the deposit request screen to the user terminal 3 that is the message transmission source. In the deposit request screen, input fields corresponding to the “owner ID” field, the “product name” field, and the “condition by application” field of the deposit request table / collected goods request table 127 shown in FIG. In addition, an item with a tag for transmitting a message having the information input in each input field as a parameter to the warehouse management server 1 is included.

When the CPU 11 waits for the message from the user terminal 3 in the next S202 and receives the message, in S203, each parameter in the message received in S202 is registered and “work status” = “new”. Are registered in the consignment item request table / collected item request table 127. When S203 is completed, the CPU 11 ends the member registration process.
[When registering products]
In the product registration process shown in the flowcharts of FIG. 13 and FIG. 14, the person in charge of the warehouse operator who has received the deposit sent (mailed or transported) from the member registers the information on the deposit in the product storage table 126. It is processing to do. Prior to this processing, the person in charge of the warehouse salesperson must confirm the owner's ID of the member written on the cover sheet or delivery slip for the depositing member to send the deposit to the warehouse salesperson in accordance with the rules agreed in advance. The deposit is taken out of the packaging for delivery, and stored in a curing case as necessary. An electronic tag (RF-) is attached to the outer surface of the deposit (when the curing case is not used) or the outer surface of the curing case. ID).

  The product registration process is performed when the CPU 11 of the warehouse management server 1 that has received the product registration request message from the warehouse operator terminal 2 that is executing the process by the web browser program 221 has succeeded in the predetermined authentication process. To start.

  In the first S301 after the start, the CPU 11 tries to acquire the owner ID of the member. For example, when the owner ID is included in the product registration request message, the owner ID is extracted from the message. In other cases, the CPU 11 may respond to the transmission screen of the owner ID to the warehouse operator terminal 2 and receive the owner ID returned by the function of the transmission screen. Thus, CPU11 which succeeded in acquisition of owner ID advances a process to S302.

  In S302, the CPU 11 searches the consignment item request table / collected item request table 127, and extracts a record including the owner ID acquired in S301 and “work status” = “new”. At this time, if the requesting member executes the deposit request process for a plurality of deposits, a plurality of records are extracted.

  In next step S <b> 303, the CPU 11 transmits the screen / form data 122 of the arrival date registration screen to the warehouse operator terminal 2. In this arrival date registration screen, the product names in each record extracted in S302 are listed, and an option button for selecting which of the product names corresponds to registration of deposits is included. An item with a tag that causes the warehouse management server 1 to send a message having the deposit arrival date input field, the product name selected by the option button, and the deposit arrival date input in the input field as a parameter, include.

  In step S304, the CPU 11 waits for the message from the user terminal 3, and proceeds to step S305 when receiving the message.

  In S305, the CPU 11 retrieves a record including the product name in the message received in S304 from the consigned item request table / collected item request table 127, and sets the value of the “work status” column in the retrieved record to “inspection”. Change to “Medium”.

In next step S <b> 306, the CPU 11 transmits the screen / form data 122 of the product registration screen to the warehouse operator terminal 2. In this arrival date registration screen, input fields (“condition by declaration” field, “product status” field, “publication status” field, “position number”) corresponding to each field of the product storage table 126 shown in FIG. Column, “sale price” column), and an item with a tag that causes the warehouse management server 1 to send a message using information input in each input column as a parameter. Note that the value of the “product name” field in the record searched in S305 may be initially set in the “product name” input field. In the warehouse operator terminal 2 that has received the screen / form data 122 of the product registration screen, the person in charge reads the ID (stored unique ID) of the electronic tag attached to the donated item or its curing case, and the screen Enter in the corresponding input field. If the ISBN code is attached to the donated item, the ISBN data DB 41 is accessed, the product name and product image corresponding to the ISBN are read, and the ISBN code, product name and product image are input correspondingly on the screen. Fill in the fields. If the JAN code is printed on the donated object, the JAN data DB 42 is accessed, the product name and product image corresponding to the JAN code are read, and the JAN code, product name and product image are displayed on the screen. Enter in the input field. Further, the person in charge measures the height (X), width (Y), and depth (Z) dimensions of the donated object or its curing case, and inputs them into the corresponding input field on the screen. In addition, the person in charge evaluates the type and condition of the received item, and inputs them in the “type” and “condition at the time of inspection” fields. After the above, when the person in charge operates the transmission item in the screen, the CPU 21 of the warehouse operator terminal 2 transmits a message including data input in each input field to the warehouse management server 1.

  In step S307, the CPU 11 waits for the message from the warehouse operator terminal 2 and receives the message. In step S308, the CPU 11 searches the owner table 124 and reads a record including the owner ID acquired in step S301.

  In the next step S309, the CPU 11 calculates the volume (received item volume) calculated based on the height (X), width (Y), and depth (Z) values of the “product size” in the data received in S307. However, it is checked whether or not the remaining space in the record read from the owner table 124 is exceeded in S308. If the former is less than or equal to the latter, the process proceeds to S312.

  On the other hand, if the former exceeds the latter, in S310, the CPU 11 determines the contract space value and the remaining space in the record until the remaining space in the record extracted in S308 is equal to or greater than the donated volume. Increase the value by the unit amount. And CPU11 advances a process to S311 at the time of the former becoming more than the latter.

  In S <b> 311, the CPU 11 increases the value of the “Monthly charge” column in the record including the owner ID acquired in S <b> 301 in the member management database 123 by an amount corresponding to the increase in the contract space in S <b> 310. When S311 is completed, the CPU 11 advances the process to S312.

  In S312, the CPU 11 searches the dead space table 125, and the space indicated by the height (X), width (Y), and depth (Z) dimensions registered in the “storage space” column is S307. Based on whether or not to include the space indicated by the height (X), width (Y), and depth (Z) dimensions of the “product size” in the data received in the above, or a case for curing it Check if there is a storage space that is at least the size of the storage space. If there is a storable space that is equal to or larger than the size of the donated item or its curing case, the CPU 11 advances the process to step S316.

On the other hand, if there is no storable space larger than the size of the donated item or its curing case, the CPU 11 stores the screen / form data 122 of the warning screen indicating that a new space should be secured in S314. After transmitting to the salesperson terminal 2, the process returns to S313. The person in charge who sees the warning screen displayed on the display 26 by the web browser program 221 executed by the CPU 21 of the warehouse operator terminal 2 sorts out any physical storage space, thereby freeing up space. And the dead space update application process shown in FIG. 11 is executed. As a result, since the size of the storage space registered in the dead space table 125 for the physical storage space is enlarged, in the second and subsequent processing of S313, the size is larger than the size of the donated object or its curing case. There is a possibility that it is determined that there is a space that can be stored.

  In S315, the CPU 11 checks whether or not there are a plurality of physical storage spaces having a storage space that is equal to or larger than the size of the donated item or its curing case. If there is only one such physical storage space, the CPU 11 proceeds directly to S317. If there are a plurality of such physical storage spaces, the CPU 11 determines in S316 the physical storage space with the smaller size of the storage space. After selecting “position No.”, the process proceeds to S317.

  In S317, the CPU 11 stores the “accommodable space” field in the dead space table 125 (the “accommodable space” field in the record corresponding to the physical storage space determined to be only one in S315, or in S316. The height (X) and width (Y) of the “product size” in the data received in S307 are the dimensions registered in the “storage space” column in the record corresponding to the selected “position No.”. ) And depth (Z) are reduced by the space indicated.

  In next step 318, the CPU 11 adds the height (X) and width of the “product size” in the data received in S307 to the value of the “use space” column in the record read from the owner table 124 in S308. The volume calculated based on the values of (Y) and depth (Z) (donated volume) is added, and the received volume is subtracted from the value in the “remaining space” column.

  In next S319, the CPU 11 determines each parameter in the data received in S307, the physical storage space position No. determined in S313 that there is a storage space that is equal to or larger than the size of the donated object or its curing case. . (When there are a plurality of such physical storage spaces, the position number selected in S316), the value in the “condition by application” column in the record extracted in S302, product status = storage (initial value), A new record in which “public status = non-public” is registered is added to the product storage table 126.

  In the next 320, the CPU 11 determines the position No. of the physical storage space determined in S313 that there is a storage space that is larger than the size of the donated object or its curing case. (When there are a plurality of such physical storage spaces, the position number selected in S316) is returned to the warehouse operator terminal 2. That is, S320 corresponds to an output unit that outputs the specific information of the physical storage space specified by the specifying unit.

  The position number displayed on the display 26 by the web browser program 221 being executed by the CPU 21 of the warehouse operator terminal 2. The person in charge who saw the position No. The donated material is stored in an empty space in the physical storage space indicated by.

In the next S321, the CPU 11 changes the value of the “work status” column in the record retrieved from the deposit request table / collected goods request table 127 in S305 to “stored”. When S321 is completed, the CPU 11 ends the product registration process.
[When accessing members]
The member access processing shown in the flowcharts of FIGS. 15 and 16 is performed from the user terminal 3 operated by any member, the URL of the user's My Page (FIG. 21), the URL of the top page (21), and the page to be sold Or a message specifying the URL of the page to be received is received by the warehouse management server 1, and the CPU 11 of the warehouse management server 1 performs a predetermined authentication process for the owner ID transmitted from the operator of the user terminal 3. Start if successful.

  In the first S401 after the start, the CPU 11 identifies the type of the requested page based on the URL specified in the received message.

  When it is determined in S401 that a My Page has been requested (that is, when the My Page URL registered in the member management database 123 corresponding to the authenticated member owner ID is specified in the message). In S402, the CPU 11 generates screen data of an authenticated member-dedicated My Page (see FIG. 20). That is, the CPU 11 reads the screen / form data 122 of My Page, reads the top nine records including the owner ID of the authenticated member from the product storage table 126, and reads “product image” in the read record. The image data registered in the column is linked to the “own archive” column in the screen data, and the value 101 in the “type” column, the value 102 in the “product name” column, “product status” in each read record "Value" 103, "sale price" field value 104 (only for records for which product status = "sell"), "public status" field value 105 (product status = "storage" record) Is added to the “list in archive” column in the above screen data. The value 103 in the “product status” column is set as a button for transmitting a status change request message for sequentially changing the value 103 in the “product status” column to the warehouse management server 1 each time it is clicked. The value 104 in the “sale price” column is displayed in a text box that causes the warehouse management server 1 to transmit a status change request message whose input content is the change request value when the change button 107 is operated. Further, the value 105 in the “public status” column is set as a button for transmitting a status change request message for sequentially changing the value in the “public status” column to the warehouse management server 1 each time it is clicked. In addition, in the “list in the archive” field on the My Page, “collection” that causes the warehouse management server 1 to transmit a receipt request message including the storage unique ID of the corresponding donation as a parameter corresponding to each donation. A button 106 is included. In addition, the CPU 11 reads out information (contents of the exchange ticket) of all records in which the owner ID of the authenticated member takes the value of the “owner” column from the exchange ticket management database 128, and reads the contents of the read exchange ticket as Write in the “Exchange Ticket” field in the above screen data. Also, in My Page, a search field 107 for sending an update request message specifying the keyword entered in the text box as a search condition to the warehouse management server 1 and an update request message specifying the selected genre as a search condition Is included in the genre field 108 for transmitting to the warehouse management server 1. In addition, in My Page, a message specifying the URL of the top page, a message specifying the URL of the page to be sold, a message specifying the URL of the page to be listed, a message specifying the URL of My Page, and the URL of the page to be exchanged Each of the tabs 109 for transmitting a message designating to the warehouse management server 1 is included. The CPU 11 responds to the user terminal 2 that is the message transmission source with the screen data of the My Page generated as described above.

  In S403, the CPU 11 checks whether or not a status request message has been received from the user terminal 3 that has transmitted the message. If not received, the process proceeds directly to S405. If received, the product is stored in S404. After changing the value of the “product status” column, “publication status” column or “selling price” column for the donated item requested to be changed in the status change request message in the table 126, the processing is performed in step S405. Proceed to

  In S405, the CPU 11 checks whether or not a collection request message has been received from the user terminal 3 that is the message transmission source. If it has not been received, the process proceeds directly to S407. If it has been received, the process will be described later in S406. After executing the takeover process, the process proceeds to S407.

  In S407, the CPU 11 checks whether or not an update request message has been received from the user terminal 3 that is the message transmission source. If it has not been received, the process directly returns to S403. If it has been received, the product is stored in S408. Based on the top nine records, which are the results of sorting the records including the owner ID of the authenticated member in the table 126 according to the search condition specified in the update request message, “My Library” in the screen data of My Page The field and the “list in the archive” field are updated, and the screen data of the updated My Page is transmitted to the user terminal 3 that is the message transmission source, and then the process returns to S403.

  When determining in S401 that the top page is requested, the CPU 11 generates screen data of the top page (FIG. 21) in S409. That is, the CPU 11 reads the screen / form data 122 of the top page, and also reads and reads nine records from the top of all the records set to “public status” = “public” from the product storage table 126. The image data registered in the “product image” field in the record is linked to the “new arrival frame” field in the screen data. The top page includes a search field 107, a genre field 108, and tabs 109, as with the My Page. The CPU 11 responds the screen data of the top page generated as described above to the user terminal 2 that is the message transmission source.

  In next S410, the CPU 11 checks whether or not an update request message has been received from the user terminal 3 that is the message transmission source. If not received, the process directly returns to S410. If received, in S411, Based on the top nine records, which are the results of sorting records set to “public status” = “public” in the product storage table 126 according to the search conditions specified in the update request message, The “new arrival introduction frame” field is updated, and the screen data of the updated top page is transmitted to the user terminal 3 that is the message transmission source, and then the process returns to S410.

  If it is determined in S401 that a page to be sold is requested, the CPU 11 generates screen data of the page to be sold in S412. In other words, the CPU 11 reads the screen / form data 122 of the page to be sold (the layout is the same as that of the top page), and at the top of all records set to “product status” = “sell”. The individual records are read from the product storage table 126, and the image data registered in the “product image” column in the read record is linked to the center column of the screen data. For the link to the image data set in the screen data of the page to be sold, when the image data is clicked, a product selection message with the stored unique ID corresponding to the image data as a parameter is sent to the warehouse management server 1. An anchor tag to be transmitted is set. In addition, the page to be sold includes a search field 107, a genre field 108, and tabs 109, as in the case of my page. The CPU 11 responds to the user terminal 2 of the message transmission source with the screen data of the selling page generated as described above.

  In S413, the CPU 11 checks whether or not a product selection request message has been received from the user terminal 3 that has transmitted the message. If not received, the process proceeds to S414.

  In S414, the CPU 11 checks whether or not the update request message has been received from the user terminal 3 that is the message transmission source. If not, the process directly returns to S413. If it has been received, in S416, the product Screen data of the page to sell based on the top nine records that are the result of sorting records set to “product status” = “sell” in the storage table 126 according to the search conditions specified in the update request message Is updated, the screen data of the page to be sold after the update is transmitted to the user terminal 3 that is the message transmission source, and then the process returns to S413.

  On the other hand, when it is determined in S413 that the product selection request message has been received (that is, when the deposit identification information is input), the CPU 11 stores the received selection request message as a parameter in S417. The owner ID and the product name corresponding to the unique ID are read from the product storage table 126, the email address corresponding to the read owner ID is read from the member management database 123, and the product name is addressed to the read email address. A message (acknowledgment confirmation message) is transmitted to confirm whether to accept or reject the sale of the deposit.

  In the next S418, the CPU 11 waits for a response to the acceptance confirmation message, and if there is a response to reject, the CPU 11 reads the screen / form data 122 of the warning screen displaying the rejection in S419, After the data is sent to the user terminal 2 as the page request source, the process returns to S413.

  On the other hand, if it is determined in S418 that there is a response to accept, the CPU 11 determines the person (assignee) indicated by the authenticated owner ID (that is, the input member identification information) and the deposit. Assuming that a sales contract has been established with the owner, the owner change process is executed in S420.

  FIG. 17 is a flowchart showing the owner change processing subroutine executed in S420. In the first step S501 after entering this subroutine, the CPU 11 registers the value of the “owner ID” column in the record corresponding to the transfer object to be transferred in the product storage table 126 in the member management database 123 for the transferee. In addition to changing to the owner ID, the value of the “product status” field in the record is initialized to “storage”, and the value of the “public status” field is initialized to “private”.

  In the next step S502, the CPU 11 uses the value in the “use space” column registered in the owner table 124 for the transferor and the high registered in the “product size” column in the product storage table 126 for the transfer object. The volume calculated based on the respective dimensions of length (X), width (Y), and depth (Z) is reduced, and the volume is added to the value in the “remaining space” column.

  In the next step S503, the CPU 11 sets the value of the “remaining space” column registered in the owner table 124 for the transferee to the value registered in the “product size” column of the product storage table 126 for the transfer object. It is checked whether or not the volume is greater than or equal to the volume calculated based on the dimensions of length (X), width (Y), and depth (Z). If the former is greater than or equal to the latter, the CPU 11 advances the process directly to S506.

  On the other hand, if it is determined in S503 that the former is less than the latter, the CPU 11 determines in S504 that the value of the “remaining space” column registered in the owner table 124 for the transferee is the above transfer target. The contract space value and the remaining space value in the record are increased by the unit amount until the volume of the donated object is exceeded. And CPU11 advances a process to S505, when the former becomes more than the latter.

  In S505, the CPU 11 increases the value registered in the “Monthly charge” column of the member management database 123 for the assignee by an amount corresponding to the increase in the contract space in S504. When S505 is completed, the CPU 11 advances the process to S506.

In step S506, the CPU 11 sets the value registered in the “use space” column registered in the owner table 124 for the transferee and the height registered in the “product size” column in the product storage table 126 for the transfer object to be transferred ( The volume calculated based on each dimension of X), width (Y), and depth (Z) is added, and the volume is subtracted from the value in the “remaining space” column. S5
When 06 is completed, the CPU 11 completes the ownership change processing subroutine and returns the processing to the main routine.

  In the main routine of FIG. 15 in which the process is returned, the CPU 11 executes the settlement process in S421 after the completion of S420. That is, in the case where a page to be sold is requested in S401, the selling price registered in the “selling price” column of the product storage table 126 for the transferred donation is changed to “additional amount of the month” in the member management database 123 for the transferee. In addition to adding to the value registered in the column, processing for transferring the selling price to the transferor is executed using the charging means registered in the “Billing Information” column of the member management database 123 for the transferor. When completing S421, the CPU 11 returns the process to S413.

  If it is determined in S401 that the page to be raised is requested, the CPU 11 generates screen data for the page to be raised in S422. That is, the CPU 11 reads the screen / form data 122 of the page to be raised (its layout is the same as that of the top page) and nine records from the top among all the records set to “product status” = “give”. Is read from the product storage table 126, and the image data registered in the “product image” column in the read record is linked to the center column of the screen data. In addition, when the image data is clicked, a product selection message using the stored unique ID corresponding to the image data as a parameter is transmitted to the warehouse management server 1 for the link to the image data set in the screen data of the page to be listed. An anchor tag to be set is set. In addition, the page to be listed includes a search column 107, a genre column 108, and tabs 109, as in the case of my page. The CPU 11 responds to the user terminal 2 of the message transmission source with the screen data of the page generated as described above.

  In S423, the CPU 11 checks whether or not a product selection request message has been received from the user terminal 3 that is the message transmission source. If not received, the process proceeds to S424.

  In S424, the CPU 11 checks whether or not an update request message has been received from the message transmission source user terminal 3. If not, the CPU 11 returns the process directly to S423, and if received, the product in S425. Based on the top 9 records that are the result of sorting records set to “product status” = “raise” in the storage table 126 according to the search conditions specified in the update request message, Is updated, the screen data of the page to be updated after the update is transmitted to the user terminal 3 that is the message transmission source, and the process returns to S423.

  On the other hand, when it is determined in S423 that the product selection request message has been received (that is, when the deposit identification information is input), the CPU 11 refers to the exchange ticket management database 128 and authenticates in S426. It is checked whether or not a replacement ticket is registered in which the owner ID is the value in the “owner” field and the date described in the “expiration date” field is after the current date . If there is no corresponding electronic ticket, the CPU 11 ends the member access processing. On the other hand, an exchange ticket is registered in which the authenticated owner ID is the value of the “owner” column and the date described in the “expiration date” column is after the current date. In the case (that is, when the member operating the user terminal 3 has an exchange ticket within the expiration date), the CPU 11 advances the process to S427.

In S427, the CPU 11 reads the owner ID and product name corresponding to the storage unique ID included as parameters in the selection request message received in S426 from the product storage table 126, and the e-mail address corresponding to the read owner ID. Is read from the member management database 123, and a message (acknowledgment confirmation message) for confirming whether to approve or reject free transfer of the deposit indicated by the product name is transmitted to the read e-mail address.

  In the next S428, the CPU 11 waits for a response to the consent confirmation message, and if there is a response to reject, in S429, the CPU 11 reads the screen / form data 122 of the warning screen displaying the rejection, After transmitting to the user terminal 2 that is the page request source, the process returns to S423.

  On the other hand, if it is determined in S428 that there is a response to accept, the CPU 11 determines the person (assignee) indicated by the authenticated owner ID (that is, the input member identification information) and the deposit. In step S430, the owner change process is executed on the assumption that a gift contract is established with the owner. That is, the CPU 11 executes an owner change processing subroutine shown in FIG.

  In the next S431, the CPU 11 refers to the exchange ticket management database 128, sets the authenticated owner ID as the value of the “owner” column, and the date described in the “expiration date” column is the current year. Among the exchange tickets after the month and day, the ticket whose date described in the “expiration date” column is closest to the current date is identified.

  In the next S432, the CPU 11 determines whether or not the exchange ticket specified in S431 is unused based on whether or not the value in the “name holder” field matches the value in the “owner” field. to decide. If the exchange ticket has already been used (when the value in the “name holder” field does not match the value in the “owner” field), the CPU 11 advances the process directly to step S434. On the other hand, when the exchange ticket is unused (when the value in the “name holder” field matches the value in the “owner” field), the CPU 11 in S433 identifies the exchange ticket specified in S431. The value of the “expiration date” column registered in the exchange ticket management database 128 is changed to the date of a later time point (a time point after a predetermined period from the expiration date before the change, for example, a time point after 2 months). change. When S433 is completed, the CPU 11 advances the process to S434.

  In S434, the CPU 11 rewrites the value of the “owner” column registered in the exchange ticket management database 128 for the exchange ticket specified in S431 to the owner ID read from the product storage table 126 in S427. That is, as the burden of transferring the deposit, the ownership of the exchange ticket is transferred from the depositee to the depositor.

  It should be noted that the above-described processes of S426, S430, S433, and S434 are the same as the identification information of the article transferred from the transferor who is the owner whose personal identification information is registered in the second storage unit, and the transfer. When the personal identification information of the other person who is a person is input, the personal identification information of the transferee is used as the owner's personal identification information, and an electronic ticket that is still valid is registered in the second storage unit Only when the personal identification information of the owner registered in the second storage unit corresponding to the identification information of the article is changed to the personal identification information of the assignee, and the third storage unit Corresponds to a changing means for changing the personal identification information of the owner of the electronic ticket stored in the table to the personal identification information of the transferor.

  In the next 435, a new record is added to the exchange history management database 129, and the authenticated owner ID and the owner ID read from the product storage table 126 in S427 are written in the “partner” column of the new record. , The product name read from the product storage table 126 in S427 is written in the “transaction” column of the new record. When S435 is completed, the CPU 11 returns the process to S423.

Next, the takeover process executed in S406 when the original depositor or its assignee operates a takeover button 106 on the My Page for a certain deposit will be described. FIG.
These are the flowcharts which show the taking process subroutine performed in S406. In the first step S601 after entering this subroutine, the CPU 11 sets the value in the “work status” column in the record for the deposit corresponding to the receipt request message received in S405 in the deposit request table / collection request table 127. , Change to “Requesting collection”.

  In the next step S602, the CPU 11 reads out a record including the storage unique ID included as a parameter in the receipt request message received in step S405 from the product storage table 126 and registers it in the “product size” column in the read record. Member management database 123 corresponding to the total volume calculated based on the height (X), width (Y) and depth (Z) dimensions, and the value of “owner ID” in the record The home delivery fee is calculated by referring to a home delivery fee table (not shown) based on the registered address. Then, the CPU 11 transmits screen data for displaying the calculated delivery fee on the display 36 to the user terminal 3 that is the message transmission source.

  In next step S603, the CPU 11 reads a record including the authenticated member owner ID from the member management database 123, and checks the value of the “free delivery completed flag” in the read record. If the “free delivery completed flag” is set, the CPU 11 proceeds to step S606 after resetting the flag in step S605. On the other hand, if the “free delivery completed flag” is reset, the CPU 11 adds the delivery fee calculated in S602 to the value in the “additional amount for the current month” column in the record in S604, Advances to S606.

  In S606, the CPU 11 stores the name and address registered in the member management database 123 corresponding to the authenticated member owner ID, the storage unique ID included as a parameter in the receipt request message received in S405, The product name and position No. registered in the product storage table 126 in association with the storage unique ID. Based on the above, the delivery slip data is generated, and the generated delivery slip data is transmitted to the warehouse operator terminal 2. In the warehouse operator terminal 2 that has received the delivery slip data, the printer 23 prints the delivery slip based on the delivery slip data.

  In next step S607, the CPU 11 determines whether the position No. Are registered in the “product size” column of the product storage table 126 in association with the storage unique IDs in the dimensions stored in the “accommodable space” column and “empty space” column of the dead space table 125. The height (X), the width (Y), and the depth (Z) are expanded by the space indicated by each dimension.

  In the next step S608, the CPU 11 uses the “use space” column value registered in the owner table 124 corresponding to the authenticated owner ID of the member to determine the “product” in the product storage table 126 for the transfer object. The volume calculated based on the dimensions of height (X), width (Y) and depth (Z) registered in the “size” column is reduced, and the above volume is added to the value in the “remaining space” column. .

  In the next S609, the CPU 11 sets the value in the “work status” column in the record for the deposit corresponding to the receipt request message received in S405 in the receipt request / collection request table 127 to “shipped”. Change to

  In next step S610, the CPU 11 deletes the record including the storage unique ID included as a parameter in the collection request message received in step S405 from the commodity storage table 126. When S610 is completed, the CPU 11 yields a take-up process subroutine and returns the process to the main routine of FIG.

The above-described S607, S608, and S610 are collected by the owner whose identification information is registered in the third storage object corresponding to the deposit among the deposits registered in the third storage unit. When the identification information of the deposit is to be entered, the physical storage space specified by the specific information registered in the third storage unit for the deposit is registered in the first storage unit. The size of the empty space is expanded by an amount corresponding to the space specified by the size of the deposit registered in the third storage unit, and the deposit is registered in the third storage unit. The free volume registered in the second storage unit for the owner specified by the identification information is calculated based on the dimensions registered in the third storage unit for the deposit. Is added to volume is, the updating means deletes the information about the deposit registered in the third storage unit, corresponding.
[Billing process]
The billing process shown in the flowchart of FIG. 19 is a process that is automatically executed to calculate the amount charged for each member on the closing date of each month.

  In the first S701 after the start, the CPU 11 refers to the member management database 123, and for each member, displays the amount registered in the “Monthly billing amount” column and the amount registered in the “Current month additional amount” column. Calculate the monthly billing amount by adding up.

In the next step S702, the CPU 11 executes a process of charging the current monthly billing amount calculated in step S701 using the “billing information” registered in the member management database 123 for each member. When S702 is completed, the CPU 11 ends the accounting process.
<Action>
The flow of the deposit transaction using the exchange ticket in the present embodiment configured as described above will be described.

  FIG. 22 is a flowchart showing how deposits (α, β) are traded among three members (A, B, C), and FIGS. It is the schematic which shows the principal part of the content of the content of a member's my page, the goods storage table 126, the exchange ticket management database 128, and the exchange history management database 129. However, in each figure, in order to facilitate understanding, the name of the member is written instead of the owner ID.

  Before the transaction shown in FIG. 22 is performed, as shown in FIG. 23, in the commodity storage table 126, the deposit α is owned by Mr. A, and the deposit β is owned by Mr. C. γ is registered as the property of Mr. B, respectively. Also, in the exchange ticket management database 128, there are exchange tickets due for the end of July, with Mr. B as the owner and owner, and exchange tickets due for the end of July, with Mr. B as the owner and owner, respectively. It is registered. In addition, information is not yet registered in the exchange history management database 129. Therefore, deposit A is displayed on A's My Page, but no exchange ticket is displayed. In addition, the deposit γ and one exchange ticket are displayed on B's My Page. In addition, deposit C and one exchange ticket are displayed on C's My Page.

  Under the above circumstances, Mr. B and Mr. C each have a replacement ticket, so the deposit that the other party has set for the product status = “Give” can be taken over. Since we don't have a replacement ticket, even if someone wants a deposit that has the item status = "Give", it cannot be transferred.

23, when Mr. A's deposit α is found on the page given by Mr. B (S423) and the transfer is accepted by Mr. A (S428), the deposit is as shown in FIG. α moves to Mr. B (owner changes to Mr. B) (S430), and in exchange, the exchange ticket in the name of Mr. B moves to Mr. A (owner changes to Mr. A) (S434).
). At this time, since the holder and owner of the exchange ticket transferred to Mr. A were the same person (Mr. B), it can be seen that the exchange ticket was unused. Therefore, at the time of relocation, the expiration date of the exchange ticket is extended by two months to the end of September (S433). In addition, the fact that the deposit α has been transferred from Mr. A to Mr. B is recorded in the exchange history management database 129 (S435).

  Since Mr. A has obtained an exchange ticket by the above transaction, the deposit that the other party has set to the product status = “give up” can be transferred using this exchange ticket.

  Therefore, Mr. A can apply for the transfer of deposit β owned by Mr. C found on the page (S423, S427), and if accepted by Mr. C (S428), as shown in FIG. Deposit β moved to Mr. A (owner changed to Mr. A) (S430), and exchange ticket in the name of Mr. B owned by Mr. A moved to Mr. C (owner changed to Mr. C) (S434). At this time, since the right holder (Mr. B) and the owner (Ms. A) before the transfer of the replacement ticket transferred to Mr. C were different persons, it can be seen that the replacement ticket was not unused. Therefore, at the time of relocation, the expiration date of the exchange ticket is not re-extended and remains the end of September. Further, the fact that the deposit [beta] has been transferred from Mr. C to Mr. A is recorded in the exchange history management database 129 (S435).

  As a result of the above transaction, there are two exchange tickets owned by Mr. C. Therefore, it becomes possible to receive two deposits set by the other person with the product status = “give”. However, since each exchange ticket has an expiration date, it is necessary for the other party to take over the deposit for which the product status is set to “raise” before each exchange ticket expires. As a result, the distribution of exchange tickets is promoted.

  On the other hand, Mr. A and Mr. B have lost their exchange tickets, so if someone else wants a deposit that has the product status set to “Give”, you can choose one of your own deposits. You need to get a replacement ticket by transferring it to someone else. Therefore, each member is encouraged to provide his / her own deposit for free transfer. However, since one exchange ticket is newly issued within one month, even if the deposits that can be provided for free transfer are not owned, it is not excluded from the free transfer market.

  As described above, according to the present embodiment, each member is encouraged to move forward by himself / herself and transfer the self-owned donation to another person free of charge. Therefore, the market for free transfer of donated goods outside the warehouse is activated.

1 warehouse management server 2 warehouse operator terminal 3 user terminal 11 CPU
12 Hard Disk 121 Warehouse Management Program 123 Member Management Database 124 Owner Table 125 Dead Space Table 126 Product Storage Table 128 Exchange Ticket Management Database

Claims (6)

An article transaction management system for supporting a service for transferring ownership of an article between the owner of the article and a third party,
A first storage unit in which the personal identification information of the participant is registered;
For each article, a second storage unit in which the identification information and the personal identification information of the owner are registered in association with each other;
A third storage unit in which an electronic ticket including an expiration date and personal identification information of the owner is registered;
An input interface through which information is entered;
An electronic device in which, for each participant's personal identification information registered in the first storage unit, the personal identification information is used as the owner's personal identification information and a predetermined expiration date is set. Electronic ticket issuing means for registering a ticket in the third storage unit;
In the input interface, the identification information of the article transferred from the transferor who is the owner whose personal identification information is registered in the second storage unit to the other person, and the personal identification of the other person who is the transferee When the information is input, only when the assignee's personal identification information is the owner's personal identification information and an electronic ticket that is still valid is registered in the second storage unit. The personal identification information of the owner registered in the second storage unit corresponding to the identification information of the article is changed to the personal identification information of the assignee and is stored in the third storage unit An article transaction management system comprising: changing means for changing the personal identification information of the owner of the electronic ticket to the personal identification information of the transferor. 2. The article transaction management system according to claim 1, wherein the electronic ticket issuing means sets a time after a predetermined period from the time when the electronic ticket is issued as an expiration date of the electronic ticket. In the case where the personal identification information of the owner of an electronic ticket is changed to the personal identification information of the transferor, the changing means changes the personal identification information of the owner of the electronic ticket for the first time. 2. The commodity transaction management system according to claim 1, wherein the expiration date of the ticket is changed to a later time. 4. The article transaction management system according to claim 3, wherein, when changing the expiration date of the electronic ticket to a later time, the changing means changes the expiration date before the change to a time after a predetermined period. The electronic ticket registered in the third storage unit includes the personal identification information of the owner at the time of issuance in addition to the personal identification information of the owner at the present time,
The changing means changes the expiration date of the electronic ticket to a later time when the personal identification information of the owner at the time of issuance included in the electronic ticket matches the personal identification information of the owner at the present time. The commodity transaction management system according to claim 3. An article transaction management program that supports a service for transferring ownership of an article between the owner of the article and a third party,
A first storage unit in which personal identification information of participants is registered, and the identification information and the personal identification information of the owner are associated with each other and registered for each article. A computer capable of accessing the second storage unit, and the third storage unit in which an electronic ticket comprising the expiration date and the personal identification information of the owner is registered,
An electronic device in which, for each participant's personal identification information registered in the first storage unit, the personal identification information is used as the owner's personal identification information and a predetermined expiration date is set. Electronic ticket issuing means for registering a ticket in the third storage unit; and
In the input interface, the identification information of the article transferred from the transferor who is the owner whose personal identification information is registered in the second storage unit to the other person, and the personal identification of the other person who is the transferee When the information is input, only when the assignee's personal identification information is the owner's personal identification information and an electronic ticket that is still valid is registered in the second storage unit. The personal identification information of the owner registered in the second storage unit corresponding to the identification information of the article is changed to the personal identification information of the assignee and is stored in the third storage unit An article transaction management program that functions as changing means for changing personal identification information of an owner of the electronic ticket to personal identification information of the transferor.

Images