Market transaction management system and market transaction management method

Abstract

To assist with logistics operations in a commodity trading management system in a market where commodities are circulated. [Solution] A market transaction management system that manages information regarding commodity transactions in the market is characterized in that for each transaction in which the user viewing the screen is the seller, information is generated to display a logistics status screen so that commodity details indicating the contents of the commodity that is the subject of the transaction, destination information indicating the destination to which the commodity that is the subject of the transaction will be moved, current location information indicating where the commodity that is the subject of the transaction is currently located, and movement check information indicating that the commodity that is the subject of the transaction has been moved to the destination are displayed.

Description

[Technical Field]

[0001] The present invention relates to a market transaction management system and a market transaction management method. [Background technology]

[0002] In fresh produce wholesale markets, a huge amount of transactions take place every day, but the reality is that these transactions are still managed manually using analog methods.As a method for automating transactions in fresh produce wholesale markets, a system has been proposed that manages information on products received by wholesalers, updates information on the owner of each product at each stage, such as brokerage and wholesale, and updates inventory when products are shipped out (see, for example, Patent Document 1).

[0003] In addition, in a management system for commodity trading in a market where commodities are circulated in a scattered manner, a method has been proposed that makes it possible to grasp the distribution patterns of commodities that are circulated in a scattered manner by including an identifier for identifying a transaction related to the purchase of the commodity as information regarding the commodity transaction (see, for example, Patent Document 2). [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2008-117410 [Patent Document 2] Patent No. 7383241 Summary of the Invention [Problem to be solved by the invention]

[0005] According to the system described in Patent Document 1, the ownership of products arriving at the market is rewritten, making it possible to ascertain who has become the owner of each product as a result of a transaction. However, as a result of the ownership being rewritten, it is not possible to ascertain the transaction process after the fact. According to the system described in Patent Document 2, it is possible to ascertain the transaction process of circulating products after the fact, but does not take into consideration the logistics of products in accordance with completed transactions.

[0006] The present invention has been made in consideration of the above circumstances, and has as its object to assist the logistics of goods in a commodity trading management system in a market where goods are circulated from one place to another. [Means for solving the problem]

[0007] In order to solve the above-mentioned problems, one aspect of the present invention is a market transaction management system that manages information related to commodity transactions in a market, the system including: a transaction information storage unit that stores information related to commodity transactions; an input screen information providing unit that provides information for displaying an information input screen that accepts input of information to be stored in the transaction information storage unit; a transaction information processing unit that processes information related to transactions stored in the transaction information storage unit based on information input on the information input screen; and a logistics status screen information providing unit that provides information for displaying a logistics status screen that shows the logistics status of the traded commodity based on the information stored in the transaction information storage unit, and the transaction information storage unit stores, for each transaction, a transaction identifier that identifies the transaction, a product identifier that identifies the seller of the commodity, and a transaction status information providing unit that provides information for displaying a logistics status screen that shows the logistics status of the traded commodity. The logistics status screen information providing unit stores, in association with each other, a seller identifier that identifies the item that is the subject of the transaction, a buyer identifier that identifies the buyer of the item, transaction details that are information about the content of the transaction, a parent transaction identifier that identifies the transaction when the seller purchased the item that is the subject of the transaction, and movement check information that indicates that the item that is the subject of the transaction has been moved to a destination, and is characterized in that, for each transaction in which the user viewing the screen is the seller, the unit generates information for displaying the logistics status screen so that the product details that indicate the content of the item that is the subject of the transaction, the movement destination information that indicates the destination to which the item that is the subject of the transaction will be moved, current location information that indicates where the item that is the subject of the transaction is currently located, and the movement check information are displayed. [Effects of the Invention]

[0008] According to the present invention, it is possible to assist the logistics of goods in a management system for goods transactions in a market where goods are circulated from one place to another. [Brief explanation of the drawings]

[0009] [Figure 1] 1 is a diagram showing the overall configuration of a system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a diagram illustrating a hardware configuration of an information device included in the system according to the embodiment of the present invention. [Figure 3]FIG. 2 is a block diagram showing a functional configuration of a service server according to the embodiment of the present invention. [Figure 4] 3A and 3B are diagrams illustrating examples of user information and company information according to an embodiment of the present invention. [Figure 5] FIG. 10 is a diagram showing an example of transaction information according to an embodiment of the present invention. [Figure 6] FIG. 2 is a block diagram illustrating a functional configuration of a user terminal according to an embodiment of the present invention. [Figure 7] FIG. 10 is a sequence diagram showing an information registration operation in the system according to the embodiment of the present invention; [Figure 8] FIG. 10 is a diagram showing an example of an information registration screen according to an embodiment of the present invention. [Figure 9] 10 is a flowchart illustrating an operation for generating a product name option list according to an embodiment of the present invention. [Figure 10] FIG. 10 is a diagram showing how information is extracted when generating a product name option list according to an embodiment of the present invention. [Figure 11] FIG. 10 is a diagram showing options for product names on an information registration screen according to an embodiment of the present invention. [Figure 12] FIG. 10 is a diagram showing the relationship between information on a parent transaction and transaction information when new transaction information is registered according to an embodiment of the present invention. [Figure 13] FIG. 10 is a diagram showing an example of registered information when a plurality of units of records are registered according to an embodiment of the present invention. [Figure 14] FIG. 10 is a diagram showing an example of a sales data list display screen according to an embodiment of the present invention. [Figure 15] FIG. 10 is a diagram showing an example of a purchase data list display screen according to an embodiment of the present invention. [Figure 16] FIG. 10 is a diagram showing an example of a transaction list display screen according to an embodiment of the present invention. [Figure 17] 10 is a flowchart illustrating a generation operation of a transaction list display screen according to an embodiment of the present invention. [Figure 18] FIG. 10 is a diagram showing an example of a purchase data list display screen according to an embodiment of the present invention. [Figure 19]FIG. 10 is a diagram showing an example of a transaction list display screen according to an embodiment of the present invention. [Figure 20] FIG. 10 is a diagram showing an example of a purchase amount post-designation screen according to an embodiment of the present invention. [Figure 21] FIG. 10 is a diagram showing an example of a seller shipping list screen according to an embodiment of the present invention and the relationship of information for configuring the screen. [Figure 22] 10A and 10B are diagrams illustrating an example of a receipt list screen according to an embodiment of the present invention and the relationship between pieces of information for configuring the screen. [Figure 23] FIG. 10 is a diagram showing an example of a message screen according to an embodiment of the present invention. [Figure 24] FIG. 10 is a sequence diagram showing a generation operation of transaction information by a message function according to an embodiment of the present invention. [Figure 25] 10A and 10B are diagrams illustrating examples of information exchanged during the process of generating transaction information using a message function according to an embodiment of the present invention. [Figure 26] FIG. 10 is a sequence diagram showing an operation of generating transaction information by message transfer according to an embodiment of the present invention. [Figure 27] FIG. 10 is a diagram showing an example of a message screen according to an embodiment of the present invention. [Figure 28] 10A and 10B are diagrams illustrating examples of information exchanged during the process of generating transaction information using a message function according to an embodiment of the present invention. [Figure 29] FIG. 10 is a diagram showing the relationship of information in generating transaction information by message transfer according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. In this embodiment, a market transaction management system that manages product buying and selling information in a fresh food market will be described. In a system that manages such a transaction form in which products are circulated between multiple traders from upstream to downstream, the gist of this embodiment is to enable retrospective understanding of the flow of transactions and to enable management of the logistics of the products that are the subject of transactions.

[0011] Fig. 1 is a diagram showing the overall configuration of a system according to this embodiment. As shown in Fig. 1, the market trading management system according to this embodiment includes a service server 1 that provides services in the system, and a plurality of user terminals 2a to 2g (hereinafter collectively referred to as "user terminals 2") used by each user of the system.

[0012] As shown in Figure 1, users of this system are traders who buy and sell goods in the wholesale market. In Figure 1, from upstream to downstream in the transaction, these are producers / shippers, wholesalers, brokers, restaurants, retailers, etc. This is a typical configuration in a wholesale market, and there are also cases where a transport company is involved between each of the traders shown in Figure 1, or where each trader is separated into multiple layers. In the example of Figure 1, a transport company that delivers goods between brokers and restaurants / retailers is shown. Service server 1 and user terminals 2a to 2g are connected to network A such as the Internet and are able to communicate with each other.

[0013] The service server 1 is a server managed by the operator of this system, and provides a function to provide a GUI (Graphical User Interface) when using this system from a user terminal 2, and a function to accept and record buying and selling information entered at each user terminal 2. The user terminal 2 is an information processing terminal such as a smartphone, tablet, laptop PC, or desktop PC, and is an electronic device used by a user of this system.

[0014] Fig. 2 is a diagram showing the hardware configuration of information devices such as the service server 1 and user terminal 2 included in the system according to this embodiment. The system according to this embodiment can be realized by the hardware configuration of a general information processing device, and as shown in Fig. 2, a CPU (Central Processing Unit) 10, RAM (Random Access Memory) 20, ROM (Read Only Memory) 30, Storage 40, and I / F 50 are connected via a bus 80. A display 60 and an operation unit 70 are also connected to the I / F 50.

[0015] The CPU 10 is a computing means that controls the operation of the entire information device. The RAM 20 is a volatile storage medium that allows high-speed reading and writing of information and is used as a working area when the CPU 10 processes information. The ROM 30 is a read-only nonvolatile storage medium that stores programs such as firmware. The storage 40 is a nonvolatile storage medium that allows reading and writing of information and stores the OS (Operating System), various control programs, application programs, etc., and is typically a hard disk drive (HDD) or solid state drive (SSD).

[0016] The I / F 50 connects the bus 80 to various hardware components, networks, etc., and controls them. The display 60 is a visual user interface. The operation unit 70 is a user interface that allows the user to input information into the information device, such as a keyboard, mouse, various hard buttons, and a touch panel. Note that since the service server 1 is operated as a server, the user interfaces such as the display 60 and operation unit 70 can be omitted.

[0017] In such a hardware configuration, programs stored in ROM 30, Storage 40, or other storage media (not shown) are read into RAM 20, and the CPU 10 performs calculations in accordance with these programs, thereby implementing software functions. The combination of the software functions thus configured and the hardware constitutes functional blocks that realize the functions of the devices that make up the market trading management system according to this embodiment.

[0018] Next, the functional configuration of the service server 1 according to this embodiment will be described with reference to Fig. 3. As shown in Fig. 3, the service server 1 according to this embodiment includes a request processing unit 101, a trader information processing unit 102, a trader information storage unit 103, a transaction information processing unit 104, and a transaction information storage unit 105. Based on the hardware configuration described in Fig. 2, a software program for realizing the functional configuration shown in Fig. 3 is used as a market transaction management program.

[0019] The request processing unit 101 responds to requests by performing various processes in accordance with requests from applications running on the user terminal 2. The supplier information processing unit 102 performs processes such as registering information in the supplier information storage unit 103, searching for information, and extracting information under the control of the request processing unit 101. The supplier information storage unit 103 stores information on supplier companies that are users of this system and information on their personnel.

[0020] The transaction information processing unit 104 performs processes such as registering information in the transaction information storage unit 105, searching for and extracting information, etc., under the control of the request processing unit 101. The transaction information storage unit 105 stores the details of transactions carried out by users of the system and the parties involved in the transactions, as well as information indicating the relationships between the transactions and information regarding the logistics of the products that are the subject of the transactions.

[0021] 4(a) and (b) are diagrams showing the contents of one record of information stored in the contractor information storage unit 103, with FIG. 4(a) showing user information and FIG. 4(b) showing company information. That is, the contractor information storage unit 103 functions as a user information storage unit and a company information storage unit. As shown in FIG. 4(a), the user information according to this embodiment includes information such as "user ID," "password," "name of person in charge," "company ID," "contact information," "receiving location," and "job in charge." The "user ID" is a user identifier that identifies a user who uses this system. The "password" is authentication information for the user to log in to this system.

[0022] "Person in charge name" is text information indicating the name of the user using this system. "Company ID" is an identifier indicating the company to which the user belongs, but is left blank for users using the system as individuals. "Contact information" is the user's contact information for this system, such as address, telephone number, and email address. "Pickup location" is information indicating where the item should be delivered within the market if the user purchases something at the market, such as information indicating the area to which the user is assigned within the market, the pickup location for the package, or the parking location for the delivery vehicle. "Job position" is information indicating the role the user plays at the market, and contents such as "delivery" and "sales" are saved.

[0023] As shown in FIG. 4(b), the company information according to this embodiment includes information on "company ID," "password," "company name," "contact information," and "industry." The "company ID" is an identifier for identifying a user using this system, and corresponds to the "affiliated company ID" in FIG. 4(a). The "password" is authentication information for logging into this system using the "company ID" of the record. The "company name" is text information indicating the name or trade name of the company in the record. The "contact information" is contact information for the company, such as the address, telephone number, and email address. The "industry" is information indicating the role the company plays in the market, and information such as "wholesale," "brokerage," and "transportation" is stored. The company information may also specify a "receiving location," just like the user information. In addition to this information, the company information may also include the registration number of the qualified invoice issuer.

[0024] Fig. 5 is a diagram showing the contents of one record of transaction information stored in transaction information storage unit 105. As shown in Fig. 5, the transaction information storage unit according to this embodiment includes information such as "transaction ID," "buyer ID," "seller ID," "person in charge," "product code," "product name," "specifications," "place of origin," "quantity," "weight," "unit price," "consumption tax rate," "transaction date and time," "parent transaction ID," "transfer confirmation," "loading confirmation," "receipt confirmation," "remarks," "sales completion," and "purchase transfer completion."

[0025] "Transaction ID" is a transaction identifier that identifies each transaction information record. "Buyer ID" is a buyer identifier that identifies the trader who purchased the product in the transaction, and corresponds to the "User ID" in Figure 4. "Seller ID" is a seller identifier that identifies the trader who sold the product in the transaction, and corresponds to the "User ID" in Figure 4.

[0026] "Name of person in charge" is the name of the person in charge at the trader who purchased the product in the transaction. "Product code" is a code number assigned to the product sold in the transaction, and is used, for example, to distinguish between products of the same type but with different specifications. "Product name" is the name of the product sold in the transaction. In addition, the name of the person in charge who sold the product in the transaction may also be included.

[0027] "Specifications" is information indicating the specifications of the product bought and sold in the transaction. For example, in the case of peaches, this is indicated by grades such as "excellent," "excellent," or "good," and sizes such as "4L," "3L," or "2L."

[0028] "Place of origin" is information indicating the place of origin of the goods bought and sold in the transaction. "Quantity" is information indicating the number of goods bought and sold in the transaction. "Weight" is information indicating the weight of the goods bought and sold in the transaction. "Unit price" is information indicating the price per specified weight or number of goods bought and sold in the transaction. "Consumption tax rate" is information indicating the consumption tax rate applied to the transaction. Information such as "product name", "specifications", "place of origin", "quantity", "weight", and "unit price" is used as information about the transaction details.

[0029] "Transaction date and time" is information indicating the date and time the transaction took place. "Parent transaction ID" is a parent transaction identifier that indicates the purchase transaction of the goods sold in that transaction, i.e., the parent transaction, and corresponds to the "Transaction ID" of the parent transaction. "Movement confirmation" is check information that indicates whether the goods sold in that transaction have been moved to the buyer's receiving location. "Loading confirmation" is check information that indicates whether the goods have been loaded onto a vehicle, such as a truck, which is a transport vehicle used to transport the goods sold in that transaction. In other words, the "loading confirmation" information is used as loading check information.

[0030] "Receipt confirmation" is check information that indicates whether the goods sold in the transaction have been confirmed as received at the buyer's receiving location. "Notes" is text information that can be freely entered in the transaction. "Sales completed" is check information that indicates that sales of the goods purchased in the transaction have ended. "Purchase movement completed" is check information that indicates that the goods have been moved in the purchase transaction of the goods sold in the transaction. Information on "movement confirmation," "loading confirmation," "receive confirmation," and "purchase movement completed" is used as product movement information, which is information regarding the movement status of the goods.

[0031] Next, the functional configuration of the user terminal 2 according to this embodiment will be described with reference to Fig. 6. As shown in Fig. 6, in the user terminal 2 according to this embodiment, a market sales management application 200 operates to provide functions corresponding to this system.

[0032] 2, the market sales management application 200 is configured by loading software programs for configuring the market sales management application 200 into the RAM 20 and having the CPU 10 perform calculations in accordance with the programs. The market sales management application 200 according to this embodiment is a web application. That is, the user terminal 2 accesses the service server 1 via a web browser installed on the user terminal 2, and the program for configuring the market sales management application 200 is downloaded to the user terminal 2 as website information, and the market sales management application 200 is configured in the user terminal 2 in accordance with the program.

[0033] 6, the market sales management application 200 includes an operation reception unit 201, a display processing unit 202, and an information communication unit 203. The operation reception unit 201 receives user operations on the operation unit 70 of the user terminal 2 via the I / F 50. The display processing unit 202 controls the display of the GUI of the market sales management application 200 based on the user operation content acquired by the operation reception unit 201 and information acquired from the service server 1. The information communication unit 203 exchanges information with the service server 1 depending on the operating state of the market sales management application 200.

[0034] Next, the operation of registering new transaction information in the transaction information storage unit 105 of the service server 1 in the system according to this embodiment will be described with reference to Fig. 7. Fig. 7 is a sequence diagram showing the operation of registering new transaction information in this system.

[0035] 7, first, the seller's user terminal 2a accesses the service server 1 via the function of a web browser, and the GUI of the market sales management application 200 is displayed on the Display 60 (S701). In S701, login processing is performed by authentication using a user identifier such as an email address included in the "user ID" or "contact information" information, and a "password."

[0036] Then, the operation reception unit 201 receives the operation content performed by the user on the operation unit 70, and in response, the information communication unit 203 acquires information from the service server 1, and based on that information, the display processing unit 202 controls the GUI of the market sales management application 200, thereby displaying a transaction information registration screen.

[0037] 8(a) and (b) are diagrams showing screens for registering selling data (hereinafter referred to as "selling data registration screens") among the GUIs of the market sales management application 200. As shown in FIG. 8(a), the selling data registration screen in this system includes input fields for inputting each piece of information described in FIG. 5. In addition, the selling data registration screen in this system includes functions for assisting the input of information in each input field. The screens shown in FIGS. 8(a) and (b) are used as information input screens for accepting input of information to be stored in the transaction information storage unit 105.

[0038] For example, the input field labeled "Company" in Figure 8(a) is an input field for specifying the trader who will purchase the product in the transaction. This input field allows free input or selection from displayed options, and the "Company Names" of records stored in the trader information storage unit 103 of the service server 1 are displayed as options. Each of the company name options is associated with a "User ID" shown in Figure 4, and when a company name is selected, the associated "User ID" is automatically selected as information to be entered.

[0039] In addition, the input field labeled "Product Name" in Figure 8(a) is an input field for specifying the product to be bought and sold in the transaction. This input field is also multiple-choice, and the product names of products that the seller has already purchased are displayed as options. The function for displaying these product name options will now be described.

[0040] The options for "Product Name" in FIG. 8(a) use a list generated based on the "Product Name" of the transaction information stored in the transaction information storage unit 105. This list is generated in the screen information generation process in S701 in FIG. 7. The screen information generation process in S701 in FIG. 7 will be described in detail with reference to FIG. 9.

[0041] 9, first, the request processing unit 101 of the service server 1 receives an authentication request including a user ID and password from the user terminal 2 requesting screen display (S901). Then, the merchant information processing unit 102 refers to the merchant information storage unit 103 based on the received user ID and password, confirms that the user ID and password match, and performs authentication processing (S902).

[0042] If the result of S902 is that the specified user ID does not exist in the vendor information storage unit 103, or the password associated with the specified user ID does not match the specified password, and so on, and authentication fails (S902 / NO), the request processing unit 101 notifies the user terminal 2 that made the authentication request of an error (S906) and terminates the processing.

[0043] On the other hand, if the authentication is successful (S902 / YES), the transaction information processing unit 104, under the control of the request processing unit 101, extracts from the transaction information storage unit 105 a record whose authenticated user ID is the "buyer ID" (S903). Figure 10 is a diagram conceptually showing the process of extracting information in the transaction information storage unit 105 using the "buyer ID" as a key. In the example of Figure 10, records whose "product code", "product name", and "specification" are "***, peach (Yume Mizuki), ** kg / ** pieces" and "***, Kyoho, ** kg / ** pieces", respectively, are extracted.

[0044] When the records are extracted in this manner, the request processing unit 101 extracts information on the "transaction ID," "product code," "product name," "place of origin," and "specifications" from the extracted records, and generates a list of options for the "product name" shown in FIG. 8(a) (S904). Then, the request processing unit 101 transmits information on the GUI of the market sales management application 200 in the user terminal 2 and information on the list generated in S904 to the user terminal 2 as a response to the authentication request (S905), and ends the processing. That is, here, the request processing unit 101 functions as an input screen information providing unit that provides information for displaying the screens shown in FIGS. 8(a) and 8(b) and options in the "product name" input field, which will be described later.

[0045] By this processing, information on options for the "Product Name" input field shown in FIG. 8(a) is generated, and the GUI displayed on the user terminal 2 displays the products that the logged-in user has already purchased as options. FIG. 11 is a diagram showing the display mode of the options for the "Product Name" input field shown in FIG. 8(a). As shown in FIG. 11, the list generated by the processing in FIG. 9 is displayed as options.

[0046] 9, the login process and the process of generating a choice list for the "product name" input field are described as a series of processes, but S902 and S903 do not necessarily have to be consecutive processes and may be executed at different times. In this case, in the user terminal 2, an operation to display the selling data registration screen is performed with the login operation already performed, and the user terminal 2 requests screen information from the service server 1. At that time, the logged-in user ID is notified, and the service server 1 executes the processes from S903 onwards.

[0047] This function allows users who want to sell products to easily select and enter products to sell from among the products they have already purchased. As shown in Figure 10, when generating the option list, the "transaction ID" information is also extracted and included as information in the list, but it is not included in the information presented to the user, as shown in Figure 11.

[0048] When the user performs a selection operation on such an option, the operation receiving unit 201 receives the operation content, and the selected information is automatically entered into the "product name", "place of origin", and "standard" shown in Fig. 8(a) through processing by the display processing unit 202. Note that in the examples of Fig. 8(a) and Fig. 11, an example has been described in which the information on "product name", "place of origin", and "standard" are selected all at once in the "product name" input field, but it is also possible to select the information individually in each input field, and options can be generated by processing similar to that described above.

[0049] Returning to the explanation of the screen in Figure 8(a), as shown in Figure 8(a), the sales data registration screen displays buttons for "adding" or "deleting" a "unit." If you tap or click the button labeled "add," input fields for "quantity" and "weight" will be added, as shown in Figure 8(b), allowing you to enter multiple "quantities" and "weights."

[0050] This additional unit function is in line with the actual situation at wholesale markets. For example, when products such as peaches or Kyoho grapes are packed and sold in boxes, the weight of each box may vary. In such cases, when trading multiple boxes at once, the screen in Figure 8(a) requires that the weight of multiple boxes be calculated and entered, but by using the screen in Figure 8(b), the information for each box can be entered individually.

[0051] Returning to the explanation of the operation of the system in Fig. 7. In this way, when information is entered on the screen shown in Fig. 8(a) and an operation such as tapping or clicking is performed on the "Raise Invoice" button, the information communication unit 203 transmits the information entered on the screen together with a request to register transaction information to the service server 1 (S702). Note that the input items on the selling data registration screen shown in Figs. 8(a) and (b) are examples, and input fields other than those shown in Figs. 8(a) and (b), such as "Remarks," may also be provided.

[0052] The information sent in S702 includes the information entered on the screen shown in Fig. 8(a) as described above, but the information included by selecting the "Product Name" field also includes the "Product Code" and "Product Name" shown in Fig. 11, as well as the "Transaction ID" information as shown in Fig. 10. The information also includes the user ID authenticated in the login process of S701, i.e., the logged-in user ID.

[0053] In the service server 1 that has received the transaction information registration request, the request processor 101 receives the information, the transaction information processor 104 registers the information in the transaction information storage unit 105 under the control of the request processor 101, and the request processor 101 performs response processing to the user terminal 2 (S703). In the information registration processing of S703, in addition to the information entered on the screen shown in Figure 8(a), the user ID whose login has been authenticated is registered as a "seller ID." In other words, here, the transaction information processor 104 functions as a transaction information storage processor.

[0054] In addition, the user ID associated with the company name selected from the company options is registered as the "buyer ID." Furthermore, the transaction ID included in the list selected in the product name selection is registered as the "parent transaction ID." The date and time when the information registration is requested is registered as the "transaction date and time." Figure 12 shows the relationship between the record newly registered in the processing of S703 and the record corresponding to the parent transaction.

[0055] As shown in Figure 12, the "Transaction ID" in the parent transaction record is registered as the "Parent Transaction ID" of the newly registered record. Furthermore, the "Buyer ID" in the parent transaction record is the same as the "Seller ID" of the newly registered record. Furthermore, if "Transfer Confirmation" is checked in the parent transaction record, "Purchase Transfer Completed" will also be checked in the newly registered record. In addition, the "Product Code," "Product Name," and "Place of Origin" will also be the same. The "Specifications" will also generally be the same, but there may be cases where the specification information differs between the time of purchase and the time of sale, such as when the purchased item is cut up and sold.

[0056] As explained in Figure 8(b), when multiple "quantity" and "weight" are registered in one sales data registration, each piece of information is registered as an individual record as shown in Figure 13, but the same "transaction ID" is assigned. The reason why the same transaction ID is assigned will be explained later.

[0057] The response information sent to the user terminal 2 in S703 includes a list of the results of extracting records whose user ID is the "seller ID" and whose date information in the "transaction date and time" is the current day after the information is registered in the transaction information storage unit 105. As a result, the user terminal 2 that received the response displays a screen showing a list of the selling data registered on the current day as a processing result screen indicating that the information registration has been completed (S704).

[0058] Fig. 14 is a diagram showing an example of a sales data list screen displayed in the process of S704. As shown in Fig. 14, on the sales data list screen, the information included in each record, such as "product", "place of origin", "quantity", "weight", and "unit price", is displayed together by company name corresponding to each buyer ID.

[0059] This completes the registration process of new data in the system. Users who have purchased or stocked the product can then access the system and view the purchase data list screen to confirm the results of the transaction (S705). Figure 15 shows an example of the purchase data list screen displayed in S705.

[0060] When the user terminal 2 requests the service server 1 to display a buying data list screen, the service server 1 extracts records from the data stored in the transaction information storage unit 105, in which the user ID notified along with the request is the "buyer ID" and the date information in the "transaction date and time" is the current day, and transmits the extracted list to the user terminal 2. As a result, on the user terminal 2 that receives the list from the service server 1, a screen showing a list of buying data registered on the current day is displayed, as shown in FIG.

[0061] In this way, this system stores all transactions that have been completed in the market. A distinctive feature of this system is the existence of a "parent transaction ID." In a system where goods are traded and distributed in various ways, from producers and shippers to wholesalers, from wholesalers to brokers, and from brokers to restaurants and retailers, the system records the upstream transactions of each transaction and includes information on logistics such as "movement confirmation" and "loading confirmation," making it possible to realize a variety of functions.

[0062] FIG. 16 is a diagram showing an example of a transaction list screen, one of the screens that can be displayed using the "parent transaction ID" in this system. The transaction list screen in this system displays a comparison of the purchase and sales volumes of products purchased by each user, as well as the inventory volume obtained by subtracting the sales volume (selling volume) from the purchase volume (buying volume). In other words, the transaction list screen shown in FIG. 16 is used as a transaction volume display screen. By checking this transaction list display screen, each user can prevent themselves from failing to sell purchased products or accidentally entering into transactions for more than their inventory.

[0063] Fig. 17 is a flowchart showing the operation of the service server 1 when it receives a request for a transaction list display screen from the user terminal 2. As a prerequisite for the operation shown in Fig. 17, the user terminal 2 of the requesting user notifies the service server 1 of the user ID along with a request to display the transaction list display screen.

[0064] In the service server 1, which receives a request to display the transaction list display screen and notification of the user ID, the information is passed from the request processing unit 101 to the transaction information processing unit 104, and the transaction information processing unit 104 extracts information from the transaction information memory unit 105 based on the notified "user ID" (S1701).

[0065] In the processing of S1701, the transaction information processing unit 104 extracts data in which the "buyer ID" is the notified "user ID" and the "transaction date and time" is the current day from the data stored in the transaction information storage unit 105. The data extracted in S1701 is data on transactions in which the user purchased goods on that day, i.e., purchase transaction data, and the processing of S1701 is a process for extracting the purchase amount of the goods.

[0066] After extracting the information in this manner, the transaction information processing unit 104 selects each of the extracted data in turn and repeatedly performs a process for generating a comparison screen as shown in Fig. 15 (hereinafter referred to as the "comparison information generation process"). Therefore, as a process for determining whether to repeat the process, the transaction information processing unit 104 checks whether any of the extracted data remains that has not yet been selected as a target for the comparison information generation process (S1702).

[0067] If there is still unselected data (S1702 / YES), the transaction information processing unit 104 selects one of the unselected data and references its "transaction ID" (S1703). Then, the transaction information processing unit 104 extracts a record whose "parent transaction ID" is the "transaction ID" referenced in S1703 from the data stored in the transaction information storage unit 105 (S1704). The data extracted in S1704 is data on the sale of the product purchased in the transaction indicated by the "transaction ID" referenced in S1703, i.e., sales transaction data, and the processing of S1704 is processing to extract the sales volume of the product.

[0068] The transaction information processing unit 104 extracts the sales transaction data for the selected purchase transaction, and then refers to the "weight" and "unit price" of the extracted sales transaction data to tally up the "weight" and the sales amount by multiplying the "weight" by the "unit price" (S1705). This calculates the total quantity and total sales amount of the selected purchased product.

[0069] In the case where there are multiple records assigned with the "transaction ID" referenced in S1703 according to the aspects described in FIG. 8(b) and FIG. 13, in S1705 the transaction information processing unit 104 tallies the "weight" of the multiple records and tallies the sales amount by multiplying the "weight" by the "unit price." The results of this tallying become the "purchase amount (yen)" and the "purchase quantity (kg)." However, the tallying may be performed independently for each record and displayed as different records on the screen shown in FIG. 16.

[0070] Then, the transaction information processing unit 104 extracts and stores information to be displayed on the transaction list display screen for the selected purchased product as shown in Figure 16, namely, "product name", "place of origin", "purchase price (yen)", "purchase quantity (kg)", "sale price (yen)", "sale quantity (kg)", and "sale end" (S1706). In addition, in S1706, the transaction information processing unit 104 calculates and stores the inventory quantity by subtracting the "sale quantity (kg)" from the "purchase quantity (kg)".

[0071] Note that the inventory information shown in FIG. 16 is calculated each time by subtracting the "purchase amount (kg)" from the "sale amount (kg)," but it may also be included as "inventory amount" data in the transaction information shown in FIG. 5. In this case, the value of "inventory amount" when new transaction information is registered in S703 is equal to the "weight" of that transaction information. In addition, when new transaction information is registered in S703, the "inventory amount" of the transaction information corresponding to the parent transaction is updated by subtracting the "weight" of the newly registered transaction information.

[0072] The transaction information processing unit 104 repeats the processes of S1703 to S1706 until there are no more records extracted by the process of S1701 (S1702 / YES), and when there are no more unselected records (S1702 / NO), it generates screen information for displaying the transaction list display screen shown in Fig. 16 based on the information stored by the process of S1706, transmits it to the requesting user terminal 2 (S1707), and terminates the process. In this way, the transaction information processing unit 104 functions as a transaction volume display screen generation unit.

[0073] By this process, the system completes the process of generating screen information for the transaction list display screen, and a screen such as that shown in FIG. 16 is displayed on the user terminal 2. The display shown in FIG. 16 makes it possible to objectively check the purchase and sales volumes, and also to directly grasp the inventory volume. The GUI allows the user to check the "Sold Out" item. When the user determines that all purchased products have been sold, they can update the "Sold Out" check box and remove the product from the list in the product name list generation process described in FIG. 9.

[0074] Alternatively, if the calculated inventory amount is zero, the "Sold Out" box may be automatically checked. In this case, when the transaction information processing unit 104 calculates the inventory amount in S1706, if the calculation result is zero, it checks the "Sold Out" data and updates the information so that the box is checked if it is not checked.

[0075] As described above, when the "sales completed" check box is checked on the user terminal 2, the user terminal 2 notifies the service server 1 of a request to update the checked status of "sales completed" together with the "transaction ID" of the target record (the transaction ID selected in S1703). In the service server 1 that receives this notification, the transaction information processing unit 104 extracts a record from the transaction information storage unit 105 based on the notified "transaction ID" and updates the check box of "sales completed" for the extracted record.

[0076] Next, we will explain the functions of this system that correspond to the special transaction forms in wholesale markets. In general commodity transactions, the buyer selects the product to be purchased and conveys their intention to purchase to the seller, and the transaction is concluded when the seller agrees to the sale. In contrast to this, in wholesale markets, there are cases where the upstream side of the transaction requests the downstream side to sell a specific product. We will explain the function that corresponds to such cases (hereinafter referred to as the "sales request function").

[0077] In transactions using the sales request function described above, the seller of the product also inputs information about the product to be sold on the screens shown in Figures 8(a) and 8(b). However, among the information that should be input, the "unit price" information is left blank. As a result, on the purchase data list display screen, as shown in Figure 18, the "unit price" is displayed as undetermined, and the transaction is highlighted by a diagonal line in the figure to objectively show that the transaction is a sales request from the seller.

[0078] When a downstream trader who has received a sales request and purchased the product carries out a transaction for such a sales request transaction, the product is displayed on the transaction list display screen described in Fig. 16 in the same way as other normal products. Fig. 19 is a diagram showing an example of a transaction list display screen when a sales request transaction product is displayed. As shown in Fig. 19, on the transaction list display screen that includes a sales request transaction product, the sales request transaction product is highlighted in the same way as in Fig. 18.

[0079] The highlighting shown in Figures 18 and 19 is realized by the transaction information processing unit 104, which generates display information in the service server 1 in response to a request from the user terminal 2. When generating display information for the purchase data list display screen or the transaction list display screen, the transaction information processing unit 104 generates display information so that records related to sales request transactions, i.e., records with blank purchase amounts, are highlighted. Such a display can be realized, for example, by setting a style sheet for the web source that constitutes the screen.

[0080] For such sales request transactions, the buying and selling traders must discuss the blank sales amount (the "unit price" on the record) and enter the information later to complete the pending transaction. By tapping or clicking on the sales request transaction record highlighted on the screens shown in Figures 18 and 19, a screen for specifying the purchase amount later (hereinafter referred to as the "purchase amount later specification screen") as shown in Figure 20 will be displayed.

[0081] 20, the purchase amount post-sale specification screen displays information indicating the target transaction, such as "company," "product," "place of origin," and "purchase amount," as well as input fields for "unit price," "total amount," "consumption tax rate," and "amount including tax." When the user inputs information on the screen shown in FIG. 20 and then presses the "OK" button, the operation reception unit 201 in the market sales management application 200 of the user terminal 2 recognizes the operation, and the information communication unit 203 transmits the input information to the service server 1 along with a request to register the information.

[0082] In the service server 1 that has received the information registration request, the request processing unit 101 accepts the request, and based on the information included in the request, the transaction information processing unit 104 updates the target record stored in the transaction information storage unit 105. Through this processing, the sales request transaction is completed.

[0083] Next, we will explain the functions of this system related to the logistics of goods that are the subject of transactions. As explained in Figure 1, in the market, sales are carried out between various businesses, such as producers / shippers, wholesalers, brokers, restaurants, retailers, etc., and the sold goods are then handed over from the seller to the buyer. When goods are moved, for example, in the case of a sale within the market from a wholesaler to a broker, there are various ways in which the wholesaler (seller) may move the goods to the location of the broker (buyer), or the broker (buyer) may pick up the goods.

[0084] In addition, when a transaction is made between a broker and a restaurant or retail store, the restaurant or retail store (the buyer) may transport the purchased goods using its own transportation means, or the seller may arrange for the goods to be delivered to the restaurant or retail store. As such, the movement of goods varies depending on the situation on-site, making it prone to human error. To resolve such situations, the system has a function to assist in the logistics of the goods that are the subject of a transaction, based on the transaction information stored in the transaction information storage unit 105.

[0085] FIG. 21 is a diagram showing an example of a screen (hereinafter referred to as a "seller delivery list screen") that displays a list of products that a seller must deliver to a buyer, among the logistics support functions according to this embodiment, and the relationship between the information that constitutes this screen. In FIG. 21, an example is shown in which the user of user terminal 2c shown in FIG. 1, i.e., a wholesaler, is the seller and the broker is the buyer, and the seller delivers the products to the buyer's receiving location. The same applies to cases in which the user of user terminal 2e, i.e., a broker, is the seller and a restaurant or retail store is the buyer, and the seller delivers the products to a designated truck.

[0086] The seller delivery list screen shown in FIG. 21 is a logistics status screen that shows the logistics status of a product, and is provided by the request processing unit 101 in response to a request from a user. In other words, the request processing unit 101 functions as a logistics status screen information provider. To display the screen shown in FIG. 21, the user terminal 2, while logged in to the service server 1, sends a display request for the seller delivery list screen to the service server 1. As a result, as shown in (1) in the figure, the transaction information processing unit 104 first searches for transaction information based on the user ID of the logged-in user, extracts records where the "seller ID" matches and where "transfer confirmation" is unchecked, and the request processing unit 101 generates display information for the product details of the traded product, such as "product name," "specification," "place of origin," "quantity," and "weight," as shown in (2) in the figure.

[0087] In (1), in addition to checking that "Movement Confirmation" is unchecked, it is also possible to combine checking that "Receipt Confirmation" is unchecked and that "Loading Confirmation" is unchecked, or to make a judgment based on these OR conditions or AND conditions. Also, the screen shown in Figure 21 may be permitted only when the "Job" in the user information of the logged-in user is in charge of logistics such as "Delivery." This makes it possible to increase the integrity and confidentiality of information while maintaining its availability.

[0088] Next, as shown in (3) in the figure, the trader information processing unit 102 searches for user information based on the "buyer ID" for each record extracted in the search in (1) and extracts records with a matching "user ID," and the request processing unit 101 generates information for displaying the "receipt location" information as the "destination" as shown in (4) in the figure. That is, the information on the buyer's "receipt location" is used as the destination information. In the case of user terminal 2c shown in FIG. 1, this "receipt location" is the area within the market of the buyer, the broker, and in the case of user terminal 2e, it is the parking lot for trucks that deliver goods to restaurants and retail stores.

[0089] Next, as shown in (5) in the figure, the trader information processing unit 102 searches for company information based on the "affiliated company ID" of the record extracted in the search in (3) and extracts records with matching "company IDs," and the request processing unit 101 generates information to display the "company name" information as "buyer name," as shown in (6) in the figure.

[0090] The "current location" shown in Figure 21 is information indicating the location within the market where the product that is the subject of the transaction is currently located. In principle, it is under the seller's control, and the "receiving location" in the seller's user information is displayed as the "current location." In other words, the seller's "receiving location" is usually used as the current location information. On the other hand, in the situation of buying and selling in the market, there are cases where the transaction has been concluded but the product has not yet been moved, and the "current location" is not under the seller's jurisdiction. In such cases, the product transporter will be unable to find the product that should be transported, which will hinder their work.

[0091] This state can be confirmed by the value of "Purchase Transfer Completed" in the transaction information of the target. In other words, if the value of "Purchase Transfer Completed" is checked, the product is already under the seller's control, and the "Current Location" shown in Figure 21 will be the "Receipt Location" in the seller's user information. On the other hand, if it is not checked, the product is not yet under the control of the seller of that transaction, and the "Current Location" display shown in Figure 21 will not be the "Receipt Location" in the seller's user information.

[0092] In such cases, the present system can trace back transactions of scattered goods using the "parent transaction ID," enabling it to track the current location of goods whose movement has not yet been completed, i.e., goods whose "Purchase Movement Completed" value is unchecked. In such cases, as shown in (7) in the figure, the transaction information processing unit 104 searches for transaction information based on the "parent transaction ID" of the record extracted in the search (1) and extracts records with matching "transaction IDs." If the "Movement Confirmation" or "Receipt Confirmation" of that record is unchecked, it is confirmed that the goods have not yet been moved. In this way, whether or not the movement of goods in a purchase transaction for a product to be sold is incomplete can be confirmed based on the value of the "Movement Confirmation" or "Receipt Confirmation" in the purchase transaction, which is based on the parent transaction ID. However, in this embodiment, by including a "Purchase Movement Completed" field in each record of transaction information, if the movement has been completed, it is possible to confirm without tracing back the purchase transaction based on the parent transaction ID.

[0093] In this case, as shown in (8) in the figure, the trader information processing unit 102 searches for user information based on the "seller ID" of that record and extracts records with a matching "user ID," and the request processing unit 101 generates information for displaying the "receipt location" information as the "current location," as shown in (9) in the figure. In other words, in this case, the "receipt location" of the seller in the parent transaction is used as the current location information.

[0094] In this way, it is possible to confirm whether the movement of the product is complete based on the "movement confirmation" and "receipt confirmation" in the parent transaction. Therefore, although (7) to (9) in Figure 21 have been explained as an example of citing the seller's "receiving location" in the transaction one level upstream, if the movement of the product is not complete, it is possible to go back further in the purchase transaction to confirm the current location of the product based on the check status of "purchase movement completion" in the transaction information going back one level based on the parent transaction ID.

[0095] The seller's delivery list screen is displayed in this way, allowing the seller in charge of transporting the goods to carry out the delivery work while checking the screen.The GUI also allows the user to add checks to the items in each record of the "Transportation Check".

[0096] When a user performs an operation to check the "Transfer Check" field on the seller delivery list screen shown in Fig. 21, the user terminal 2 notifies the service server 1 of an identifier indicating that the "Transfer Check" field has been checked, along with a "Transaction ID" indicating the target record. Upon receiving this notification, the service server 1 passes the information from the request processing unit 101 to the transaction information processing unit 104, which extracts the record of the notified "Transaction ID" and updates the "Transfer Confirmation" check information as shown in (10) in the figure. In other words, the "Transfer Confirmation" information is used as transfer check information, and the "Transfer Check" field in Fig. 21 is used as a transfer check operation unit.

[0097] When the "Transfer Confirmation" check information is updated in this way, if there is downstream transaction information that treats the transaction as a purchase transaction, the "Purchase Transfer Completion" information in that downstream transaction information must be updated. Therefore, the transaction information processing unit 104 that updated the "Transfer Confirmation" check information extracts transaction information whose "Transaction ID" in the updated transaction information is the "Parent Transaction ID," as shown in (11) in the figure, and updates the "Purchase Transfer Completion" information in the extracted transaction information. This allows the current location information of the product, realized by the "Purchase Transfer Completion" item described above, to be accurately maintained.

[0098] Figure 22 is a diagram showing an example of a screen (hereinafter referred to as a "receipt list screen") that displays a list of products to be received by a buyer, and the relationship between the information that constitutes that screen, among the logistics support functions according to this embodiment. Figure 22 shows an example of a transaction in which the users of the user terminals 2f and 2g shown in Figure 1, i.e., the broker, are the sellers and the restaurant / retailer are the buyers.

[0099] 22, when the user terminal 2 is logged in to the service server 1, it sends a request to display the receipt list screen to the service server 1. As a result, as shown in (1) in the figure, the transaction information processing unit 104 first searches for transaction information based on the user ID of the logged-in user and extracts records where the "buyer ID" matches and where "loading confirmation" and "receipt confirmation" are unchecked, and the request processing unit 101 generates display information for the contents of the traded products, such as "product name," "specification," "place of origin," "quantity," and "weight," as shown in (2) in the figure.

[0100] Next, as shown in (3) in the figure, the merchant information processing unit 102 searches for user information based on the "seller ID" for each record extracted in the search of (1) and extracts records with a matching "user ID." Next, as shown in (4) in the figure, the merchant information processing unit 102 searches for company information based on the "affiliated company ID" of the record extracted in the search of (3) and extracts records with a matching "company ID." The request processing unit 101 then generates information for displaying the "company name" information as the "seller name," as shown in (5) in the figure.

[0101] The receipt list screen displayed in this way allows the buyer to check whether the product has been delivered or not. The GUI also allows the user to add checks to the "Loading Check" and "Receipt Check" record items.

[0102] When the user performs an operation to check the "Loading check" and "Receipt check" columns on the receipt list screen shown in Fig. 22, the user terminal 2 notifies the service server 1 of an identifier indicating that the "Loading check" and "Receipt check" have been checked, along with a "transaction ID" indicating the target record. Upon receiving this notification, the service server 1 passes the information from the request processing unit 101 to the transaction information processing unit 104, which extracts the record of the notified "transaction ID" and updates the check information for "Loading check" and "Receipt check" as shown in (6) and (7) in the figure.

[0103] The user of user terminal 2f shown in Figure 1 is a transporter who transports cargo between brokers and restaurants / retailers. Therefore, when a cargo arrives at the truck he drives and loading is completed, he checks the "Loading Check." This allows the transporter to use the receipt list screen to avoid leaving any cargo behind. Therefore, the screen shown in Figure 22 may be permitted only when the "job title" in the user information of the logged-in user is a person in charge of logistics such as "delivery" or "transport." This increases the integrity and confidentiality of information while maintaining its availability.

[0104] On the other hand, as the name suggests, the "receipt check" is check information that verifies that the product has been received by the buyer, and the user of the system at the restaurant or retail store operates the user terminal 2g to perform the "receipt check" operation as described above. This makes it possible to confirm receipt of the ordered product and check for any omissions in delivery.

[0105] Next, we will explain the function of this system, which generates transaction information through one-to-one message exchanges between users. This system has a function for exchanging messages between users, such as between a wholesaler and a broker, or between a broker and a restaurant or retailer, as shown in Figure 1. While the message function is common, one of the features of this system is that transaction information shown in Figure 5 is generated in response to the exchanges on the message screen and stored in transaction information storage unit 105.

[0106] FIG. 23(a) is a diagram showing an example of a message screen in this system, showing a state in which a message saying "Purchase information for *month* date will be sent" has already been sent. Information for displaying such a message screen is provided by the request processing unit 101 of the service server 1 in response to a request from the user terminal 2. In other words, the request processing unit 101 functions as a message screen information providing unit. As with a general message function, a field for inputting a message to be sent is provided at the bottom of the screen, but on the message screen in this system, as shown in FIG. 23(a), it is possible to switch from the message input field to a field for inputting product guide information for introducing products.

[0107] As shown in Fig. 23(a), in product guide information input field 231, which is a field for inputting product guide information, products that have already been purchased by the user sending the message are displayed as options. Regarding the function of displaying options, a list of options is generated by the same process as that of S903 to S905 described in Fig. 9. Also, a field for inputting the unit price of sales is provided, and the user inputs the unit price of sales in this field.

[0108] Fig. 24 is a sequence diagram showing the operation of generating transaction information using the message function in this system. In the example of Fig. 24, a case will be described in which transaction information is generated by exchanging messages between user terminal 2b of a wholesaler user and user terminal 2d of a brokerage user shown in Fig. 1. As shown in Fig. 24, when product guide information input field 231 is displayed on the message screen of user terminal 2b, a selection list is generated (S2401) by processing similar to the processing of S903 to S905 in Fig. 9 as described above.

[0109] On the message screen of user terminal 2b on which the selection list has been generated, the user selects a product from the list and operates the send button, causing user terminal 2b to send a product information message (hereinafter referred to as a "product information message") to service server 1. Figure 25(a) is a diagram showing the contents of the information sent in S2402. As shown in Figure 25(a), the information sent in S2402 includes the following information: "message header information," "source user ID," "destination user ID," "parent transaction ID," and "unit price."

[0110] The message header information shown in Figure 25(a) is information that includes an identifier that indicates that it is a message or a product guide. The "parent transaction ID" is the transaction ID of the purchase transaction of the product selected from the list in the product guide information input field 231 described above. This makes it possible to notify the details of the product to be guided by referencing the transaction information shown in Figure 5 based on the parent transaction ID, but information on the product details themselves, such as "Product: Peach, Origin: Kofu..." shown in Figure 23(a), may also be included in the information of the message being exchanged. The "unit price" is the unit price set by the user, and includes not only the price but also information on the unit that determines the unit price, such as the "yen / kg" portion.

[0111] In the service server 1 that has received the information message from user terminal 2b, the transaction information processing unit 104 searches the transaction information storage unit 105 based on the parent transaction ID as described above to obtain the product details from the target transaction information, and the request processing unit 101 notifies the destination user terminal 2d of the information message based on the destination user ID (S2403). When the user displays the message screen on user terminal 2d in response to the notification, a product information message 232 is displayed, as shown in Figure 23(b).

[0112] As shown in Fig. 23(b), the product information message 232 displays not only the product details such as "Product: Peach, Origin: Kofu...", but also unit price information, an order quantity specification field 232a, and an order button for confirming the order. That is, on the message screen of the user who has received the product information message, an order operation section for processing an order for the product that has been displayed is displayed in association with the information message. This order quantity specification field 232a functions as an order quantity input section for inputting the order quantity of the product.

[0113] The unit of measure to the right of the order quantity specification field 232a is displayed based on the unit price information. The order quantity entered in the order quantity specification field 232a has an upper limit based on the "inventory quantity" described above, and an order cannot be placed for an amount exceeding the inventory quantity. The user of the user terminal 2d specifies the order quantity by entering information in the order quantity specification field 232a included in the product guide information message 232 shown in FIG. 23(b), and places an order for the guided product by operating the confirm button. This causes the user terminal 2d to send an order message to the service server 1 (S2404).

[0114] In S2404, the user terminal 2d requests information on the stock quantity of the target product from the service server 1, and sends an order message only if the input order quantity does not exceed the stock quantity, and if the order quantity exceeds the stock quantity, displays an error message and updates the information on the upper limit of the order quantity to be input in the order quantity specification field 232a described above. This makes it possible to prevent orders that exceed the stock quantity.

[0115] Figure 25(b) is a diagram showing the contents of the information transmitted in S2404. As shown in Figure 25(b), the information transmitted in S2404 includes information on "order quantity" in addition to the information contained in the information message. As with the information message, information on the product contents themselves may also be included. In addition, the message header information includes information indicating that it is product ordering information.

[0116] Upon receiving the order message from user terminal 2d, service server 1 obtains the details of the product through processing similar to that of S2403, and the request processing unit 101 notifies user terminal 2b, the destination, of the order message based on the destination user ID (S2405). When the user displays the message screen on user terminal 2b in response to the notification, an order message 233 is displayed, as shown in Fig. 23(c). As shown in Fig. 23(c), order message 233 displays product information, unit price information, order quantity information entered by the orderer, and a confirm button for confirming the order.

[0117] The user of user terminal 2b accepts the order by operating the Confirm button included in the order message 233 shown in Fig. 23(c). This causes user terminal 2d to send an order message to the service server 1 (S2406). The content of the information sent in S2406 is the same as that shown in Fig. 25(b), except that the content of the "message header" is an identifier indicating that this is an order confirmation.

[0118] Upon receiving the order message from user terminal 2b, service server 1 obtains the details of the product through processing similar to that of S2403, and the request processing unit 101 notifies user terminal 2d, the destination, of the order message based on the destination user ID (S2407). When the user displays a message screen on user terminal 2d in response to the notification, an order confirmation message is displayed, as shown in FIG. 23(d). Furthermore, after notifying the order message, transaction information processing unit 104 of service server 1 generates transaction information (S2408). Note that the example of FIG. 24 illustrates a case in which the order is confirmed by order confirmation at user terminal 2b and transaction information is generated in S2408, but the order may also be confirmed and transaction information generated at the stage when the order message is sent in S2404.

[0119] The information required to generate the transaction information shown in Fig. 5 is all determined in the exchanges of S2402 to S2406 and is included in the information shown in Fig. 25(b), and the transaction information processing unit 104 generates the transaction information based on that information. This processing makes it possible to generate transaction information via the message function without disrupting the state in which transactions of products circulating in a dotted line are associated from upstream to downstream using the "parent transaction ID."

[0120] In the examples of Figures 23 and 24, only the case where a product information message is generated by selecting from a list of already purchased products in the product information input field 231 is described as an example. This makes it possible to generate transaction information based on the association of upstream to downstream transactions using the "parent transaction ID," as described above. Alternatively, product information may be generated by freely entering information in the product information input field 231. In this case, by exchanging the entered information without using the "parent transaction ID," transaction information is generated that does not specify a "parent transaction ID." Furthermore, the aspects described in Figures 18 to 20 make it possible to subsequently realize association using the "parent transaction ID."

[0121] 23 and 24 show an example of one-to-one message exchange between users, as shown by the destination user ID and source user ID in Fig. 25. In this case, only users who are logged in to the system using the destination user ID and source user ID can view and exchange messages. In addition, the "company ID" shown in Fig. 4(b) may be specified as the destination user ID and source user ID. In this case, any user with a matching "affiliated company ID" shown in Fig. 4(a) can view the message.

[0122] 23 and 24, an example was explained in which an order is placed for a product introduced by a message, but in the case of a broker, for example, there are cases in which the product introduced by the wholesaler is forwarded to a retail store, etc. Such a case will be described with reference to FIG.

[0123] Fig. 26 is a sequence diagram showing the operation when introducing a product by forwarding a message. In the example of Fig. 26, a product is first introduced by a message from a user terminal 2b of a wholesaler to a user terminal 2d of a broker, and the broker, having received the message, forwards the introduction message to a user terminal 2g of a retail store.

[0124] As shown in Fig. 26, first, a request to send an information message is sent from the wholesaler's user terminal 2b to the broker's user terminal 2d (S2601), and the service server 1, having received the message request, notifies the broker's user terminal 2d, which is the destination, of the message (S2602). As a result, a message such as that shown in Fig. 27(a) is displayed on the broker's user terminal 2d. The information sent here is the same as that shown in Fig. 25(a).

[0125] As shown in Figure 27(a), the information message 271 received by the broker's user terminal 2d includes an inventory quantity display field 271a that displays the inventory quantity of the notified product, a forwarding destination selection field 271b that selects an address to forward the information message to, and a unit price setting field 271c that sets the unit price to be offered to the forwarding destination. As described in the inventory quantity display in Figure 16, the inventory quantity displayed in the inventory display field 271a may be calculated and displayed by subtracting the purchase quantity and sale quantity in the purchase transaction of the product, or information provided as an item in the transaction information shown in Figure 5 may be displayed. Furthermore, the information in the inventory display field 271a is updated and displayed in real time as the user terminal 2 exchanges information with the system server 1.

[0126] When a forwarding destination is selected in the forwarding destination selection field 271b shown in Figure 27(a), a unit price is set in the unit price setting field 271c, and the "Forward" button is operated, the user terminal 2d forwards the message by sending a message transmission request addressed to the user terminal 2g of the retailer set as the forwarding destination (S2603). That is, the forwarding destination selection field 271b, the unit price setting field 271c, and the "Forward" button function as a forwarding operation unit, and the forwarding destination selection field 271b functions as a forwarding destination specification field. Figure 28(a) is a diagram showing the content of the information transmitted here.

[0127] The information sent in S2603 is a forwarding message, but it has the nature of an information message from the wholesaler to the retailer. Therefore, the basic information contained therein is the same as that shown in Figure 25(a), and the message header information includes a value indicating that it is information regarding forwarding. On the other hand, at the stage of S2603, the transaction between the wholesaler and the retailer has not yet been concluded, so the "parent transaction ID" is a value indicating "undecided." In addition, the information regarding the information related to the forwarding source includes the "grandparent transaction ID," which is the parent transaction ID of the information from the wholesaler to the retailer, and information regarding the "unit price" in that information.

[0128] The service server 1, which has received the message transmission request from the user terminal 2d, notifies the user terminal 2g, which has been set as the destination, of the message (S2604). As a result, a message such as that shown in FIG. 27(b) is displayed on the user terminal 2g of the retailer.

[0129] 27(b), the user of the user terminal 2g performs an order operation in the same manner as in S2404, and an order message is sent (S2605). The order message sent in S2606 is the information contained in the guidance message transferred in S2603, to which information on "order quantity" has been added, as shown in FIG. 28(b).

[0130] The service server 1, which receives the order message in response to the forwarding notice, generates transaction information in accordance with the received message (S2606). The message in S2605 is an order from the retailer to the broker, but at this stage the broker's purchase has not yet been confirmed. Therefore, in S2606, the service server 1 generates transaction information regarding the order from the broker to the wholesaler, in addition to transaction information regarding the order from the retailer to the broker.

[0131] Figure 29 is a diagram showing how transaction information is generated in S2606. As shown in Figure 29, in service server 1 that receives the message in S2605, transaction information processing unit 104 searches for transaction information stored in transaction information storage unit 105 based on the "grandparent transaction ID" included in the received message as shown in (1) in the figure, and extracts transaction information on the purchase transaction with the wholesaler that sent the information message in S2601. Information on product details such as "product name," "specifications," and "place of origin" included in the extracted information is used in newly generated transaction information.

[0132] The transaction information processing unit 104 uses the product content information contained in the extracted transaction information to generate a transaction information record for sales from the wholesaler to the broker and a transaction information record for sales from the broker to the retailer. As shown in (2) in the figure, the "transaction ID" of the transaction information record for the wholesaler's purchase is set as the "parent transaction ID" in the transaction information record for sales from the wholesaler to the broker. Also, as shown in (3) in the figure, the "unit price" associated with the "grandparent transaction ID" contained in the message information is set as the "unit price" in the transaction information record for sales from the wholesaler to the broker.

[0133] Furthermore, as shown in (4) in the figure, the transaction information processing unit 104 sets the "transaction ID" in the transaction information record of the sale from the wholesaler to the broker as the "parent transaction ID" in the transaction information record of the sale from the broker to the retailer. Also, as shown in (5) in the figure, the "unit price" associated with the "parent transaction ID" included in the message information is set as the "unit price" in the transaction information record of the sale from the broker to the retailer.

[0134] Then, as shown in (6) in the figure, the transaction information processing unit 104 sets the "order quantity" included in the message information as the "weight" in the two newly generated transaction information records. This process completes the transaction information generation process in S2606 in Figure 26. With this configuration, it is possible to forward the information to the retailer about a product that has been introduced to a broker by a wholesaler, even if the broker has not yet confirmed the purchase, and to smoothly complete the transaction without breaking the association of the transaction information using the "parent transaction ID."

[0135] After completing the generation of the transaction information, the service server 1 sends an order message to each of the user terminals 2b and 2d. Here, the order message sent to the user terminal 2d is the order from the user terminal 2g, and the order message sent to the user terminal 2b is the order from the user terminal 2d. This completes the order processing using the forwarded message.

[0136] As explained above, in the system according to this embodiment, in market transactions in which goods are circulated among multiple traders from upstream to downstream, each transaction is recorded as a single record, and each record also records a "parent transaction ID," which is information indicating the transaction one step upstream of the product being traded, i.e., the transaction related to the purchase of that product.

[0137] The seller delivery list screen shown in Fig. 21 and the receipt list screen shown in Fig. 22 can assist in the distribution of products that are the subject of a transaction, contributing to the smooth running of operations in the market. In particular, the seller delivery list screen makes it possible to determine the current location of products in the market based on the "parent transaction ID" and logistics flag information such as "movement confirmation" and "receipt confirmation" when the distribution of products in upstream transactions is not yet complete, thereby contributing to reducing the burden on logistics personnel.

[0138] In addition, the message-based transaction information generation function described in Figures 23 and 24 enables transactions to be concluded quickly through message exchanges, while maintaining the association of transaction relationships from upstream to downstream using the "parent transaction ID" that is the premise of this system.

[0139] In addition to the characteristic functions mentioned above, the functions of this system also include the ability to issue invoices and delivery notes. Such functions can be realized based on the information stored in this system, as shown in Figure 5. For example, if transactions are aggregated by month and invoices are to be issued, invoices can be easily generated by extracting records where the "Buyer ID" matches the company to be invoiced and the year and month of the "Transaction Date and Time" matches the month of the invoice.

[0140] To generate such an invoice, the user operates the GUI on the user terminal 2 to specify the company to be billed and the year and month to generate the invoice, and the operation reception unit 201 on the user terminal 2 receives the operation content, and the information communication unit 203 sends a request to generate an invoice to the service server 1. In the service server 1 that has received the request from the user terminal 2, the request processing unit 101 receives the request and passes the information to the transaction information processing unit 104.

[0141] The transaction information processor 104, which receives information from the request processor 101, extracts information stored in the transaction information storage unit 105 based on the specified information, aggregates and lists the information, and generates display information for displaying an invoice. Once the transaction information processor 104 has generated the invoice display information, the request processor 101 transmits the information to the requesting user terminal 2. This displays the invoice on the user terminal 2, making it possible to send it to the invoice recipient company based on the buyer ID or print it out on paper. In addition, since all transaction information is recorded, it is also possible to automatically issue documents such as general ledgers, balance sheets, cash flow statements, and profit and loss statements.

[0142] Furthermore, in the operation of this system, there is a process to extract records using a user ID as a key, such as S903 in Figure 9 and S1701 in Figure 17. This means that only the transaction information of the user who has logged in to use this system is referenced. On the other hand, in addition to logging in with a user ID, logging in to use this system can also be done with a company ID, as shown in Figure 4(b).

[0143] In such cases, in each process, records are extracted based on the user IDs of all users belonging to the company. For example, in S1701 of FIG. 17, in addition to the records whose "Buyer ID" is the currently logged-in "Company ID," all "User IDs" of records whose "Affiliated Company ID" matches the currently logged-in "Company ID" among the user information described in FIG. 4(a) are obtained, and records in which all obtained "User IDs" match the "Buyer ID" are also extracted. This allows a user who logs in with a company ID to understand the transactions of all users belonging to the company. This function of referencing transaction information of affiliated users by logging in with a company ID is also applicable to subsequent embodiments. [Explanation of symbols]

[0144] 1 Service Server 2, 2a, 2b, 2c, 2d User terminal 3 Store communication device 10 CPU 20 RAM 30 ROM 40 HDD 50 Interfaces 60 LCD 70 Operation section 80 Bus 90 Short-range communication antenna 101 Request Processing Unit 102 Business Information Processing Department 103 Vendor information storage unit 104 Transaction information processing unit 105 Transaction information storage unit 200 Market Sales Management App 201 Operation reception section 202 Display processing unit 203 Ministry of Information and Communications 231 Product information input field 232 Product information message 233 Order Message 271 Product information message

Claims

1. A market transaction management system that manages information about commodity transactions in a market, a transaction information storage unit that stores information regarding product transactions; an input screen information providing unit that provides information for displaying an information input screen that accepts input of information to be stored in the transaction information storage unit; a transaction information processing unit that processes information about the transaction stored in the transaction information storage unit based on the information input on the information input screen; a distribution status screen information providing unit that provides information for displaying a distribution status screen showing the distribution status of the traded goods based on the information stored in the transaction information storage unit; a user information storage unit that stores information about a user who uses the system, the user information storage unit storing a user identifier that identifies the user and information about a receiving location where the user receives the product purchased by the user in association with the user identifier; The transaction information storage unit stores, for each transaction, a transaction identifier for identifying the transaction, a seller identifier for identifying the seller of the product, a buyer identifier for identifying the buyer of the product, transaction details which are information about the content of the transaction, a parent transaction identifier for identifying the parent transaction which is the transaction when the seller purchases the product that is the subject of the transaction, and product movement information which is information about the movement status of the product that is the subject of the transaction, in association with each other; The product transfer information includes transfer confirmation information indicating that the product subject to the transaction has been transferred to a transfer destination according to the transaction, The logistics status screen information providing unit extracting from the transaction information storage unit information relating to a transaction in which the user viewing the screen is a seller and the product that is the subject of the transaction has not yet been moved to a destination according to the transaction; determining whether the product to be traded has been moved to the seller of the transaction based on the extracted information on the transaction; If the result of the determination is that the product to be traded has been moved to the seller of the trade, a seller identifier of the seller of the trade is identified; If the result of the determination is that the product that is the subject of the transaction has not yet been moved to the seller of the transaction, information about the parent transaction of the transaction is extracted based on the parent transaction identifier to determine whether the product that is the subject of the transaction for the parent transaction has been moved to the seller of the transaction, and by repeating the determination about the parent transaction based on the parent transaction identifier until it is determined that the product that is the subject of the transaction has been moved to the seller of the transaction, one seller identifier is identified; generating, in the user information storage unit, current location information indicating a location where the product is currently located based on information of a receiving location associated with the user identified by the specified seller identifier; A market transaction management system that generates information for displaying the distribution status screen so that the current location information is displayed for each transaction.

2. The commodity movement information includes purchase movement completion information indicating that the commodity that is the subject of the transaction has been moved to the commodity seller, The market transaction management system according to claim 1, characterized in that the logistics status screen information providing unit determines whether the goods subject to the transaction have been moved to the seller of the transaction based on the purchase movement completion information.

3. The market transaction management system described in claim 1, characterized in that when determining whether the product subject to the transaction has been moved to the seller of the transaction, the logistics status screen information providing unit extracts information about the parent transaction of the transaction based on the parent transaction identifier and makes a determination based on the movement confirmation information in the parent transaction.

4. The product movement information includes receipt confirmation information indicating that the buyer in the transaction has received the product that is the subject of the transaction, The market transaction management system described in claim 1, characterized in that when determining whether the product subject to the transaction has been moved to the seller of the transaction, the logistics status screen information providing unit extracts information regarding the parent transaction of the transaction based on the parent transaction identifier and makes a determination based on the receipt confirmation information in the parent transaction.

5. the logistics status screen information providing unit generates information for displaying the logistics status screen so that a transfer check operation unit, which is an operation unit for a user to specify that the product that is the subject of the transaction has been transferred to a transfer destination, is displayed; 2. A market trading management system as described in claim 1, characterized in that the trading information processing unit receives information on operations performed on the movement check operation unit and updates the movement confirmation information among the information stored in the trading information storage unit.

6. The product movement information includes purchase movement completion information indicating that the product that is the subject of the transaction has been moved to the seller in the transaction, The market transaction management system described in claim 5, characterized in that the transaction information processing unit receives information on operations performed on the transfer check operation unit, updates the transfer confirmation information among the information stored in the transaction information storage unit, and updates purchase transfer completion information in the information of transactions to which the transaction identifier of the transaction for which the transfer confirmation information has been updated is associated as a parent transaction identifier.

7. The commodity movement information includes loading check information indicating that the commodity has been loaded onto a transport vehicle that delivers the commodity that is the subject of the transaction, The logistics status screen information providing unit extracting from the transaction information storage unit information relating to a transaction in which the user viewing the screen is a buyer and the product to be traded has not yet been loaded onto a transport vehicle; 2. The market transaction management system according to claim 1, wherein information for displaying the distribution status screen is generated so that the loading check information is displayed for each extracted transaction.

8. A market transaction management method for managing information regarding commodity transactions in a market by an information processing system, comprising: the information processing system provides information for displaying an information input screen that accepts input of information to be stored in a transaction information storage unit that stores information related to product transactions; The information processing system processes the information relating to the transaction stored in the transaction information storage unit based on the information input on the information input screen, and in so doing, stores in the transaction information storage unit, in association with each other, for each transaction, a transaction identifier that identifies the transaction, a seller identifier that identifies the seller of the product, a buyer identifier that identifies the buyer of the product, transaction details that are information relating to the content of the transaction, a parent transaction identifier that identifies the parent transaction that is the transaction when the seller purchased the product that is the subject of the transaction, and product movement information that includes movement confirmation information that is information relating to the movement status of the product that is the subject of the transaction and indicates that the product that is the subject of the transaction has been moved to a movement destination according to the transaction, The information processing system provides information for displaying a distribution status screen showing the distribution status of the traded commodity based on the information stored in the transaction information storage unit, and at that time, extracting from the transaction information storage unit information relating to a transaction in which the user viewing the screen is a seller and the product that is the subject of the transaction has not yet been moved to a destination according to the transaction; determining whether the product to be traded has been moved to the seller of the transaction based on the extracted information on the transaction; If the result of the determination is that the product to be traded has been moved to the seller of the trade, a seller identifier of the seller of the trade is identified; If the result of the determination is that the product that is the subject of the transaction has not yet been moved to the seller of the transaction, information about the parent transaction of the transaction is extracted based on the parent transaction identifier to determine whether the product that is the subject of the transaction for the parent transaction has been moved to the seller of the transaction, and by repeating the determination about the parent transaction based on the parent transaction identifier until it is determined that the product that is the subject of the transaction has been moved to the seller of the transaction, one seller identifier is identified; a user information storage unit that stores information about a user using the system, the user identifier identifying the user and information about a receiving location where the user will receive the purchased product in association with each other, and generates current location information indicating a location where the product is currently located based on the receiving location information associated with the user identified by the seller identifier specified by the determination; A market transaction management method, characterized in that information for displaying the logistics status screen is generated so that the current location information is displayed for each transaction.

Images