WO2023181140A1 - 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法 - Google Patents

市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法 Download PDF

Info

Publication number
WO2023181140A1
WO2023181140A1 PCT/JP2022/013325 JP2022013325W WO2023181140A1 WO 2023181140 A1 WO2023181140 A1 WO 2023181140A1 JP 2022013325 W JP2022013325 W JP 2022013325W WO 2023181140 A1 WO2023181140 A1 WO 2023181140A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
information
product
identifier
user
Prior art date
Application number
PCT/JP2022/013325
Other languages
English (en)
French (fr)
Inventor
邦仁 藤原
Original Assignee
株式会社藤海産
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社藤海産 filed Critical 株式会社藤海産
Priority to PCT/JP2022/013325 priority Critical patent/WO2023181140A1/ja
Priority to JP2023553515A priority patent/JP7383241B1/ja
Publication of WO2023181140A1 publication Critical patent/WO2023181140A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present invention relates to a market transaction management system, a market transaction management program, and a market transaction management method.
  • Patent Document 1 According to the system described in Patent Document 1, by rewriting the owners of products that arrive on the market, it becomes possible to know who owns each product as a result of a transaction. However, as the owner is rewritten, it is not possible to understand the transaction process after the fact.
  • the present invention has been made in consideration of the above-mentioned circumstances, and its purpose is to grasp the process of trading of circulating products after the fact in a product transaction management system in a market where products are circulated from time to time.
  • one aspect of the present invention is a market transaction management system that manages information related to product transactions in a market
  • the system includes a transaction information storage unit that stores information related to product transactions, and a transaction information storage unit that stores information related to product transactions; an input screen information providing section that provides information for displaying an information input screen that accepts input of information to be stored in the storage section; and an input screen information providing section that provides information for displaying an information input screen that accepts input of information to be stored in the storage section; and a transaction information storage processing unit that stores transaction information, and the transaction information storage unit stores, for each transaction, a transaction identifier that identifies the transaction, a seller identifier that identifies the seller of the product, and a seller identifier that identifies the buyer of the product.
  • a buyer identifier for identification, transaction details that are information regarding the contents of the transaction, and a parent transaction identifier for identifying the transaction when the seller purchases the product to be traded are stored in association with each other.
  • FIG. 1 is a diagram showing the overall configuration of a system according to an embodiment of the present invention.
  • 1 is a diagram showing a hardware configuration of information equipment included in a system according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing the functional configuration of a service server according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing an example of user information and company information according to an embodiment of the present invention. It is a figure showing an example of transaction information concerning an embodiment of the present invention.
  • FIG. 2 is a block diagram showing the functional configuration of a user terminal according to an embodiment of the present invention. It is a sequence diagram showing information registration operation in a system according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing an example of an information registration screen according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating an operation of generating a product name option list according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing a manner of extracting information when generating a product name option list according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating options for product names on the information registration screen according to the embodiment of the present invention. It is a diagram showing the relationship of information with a parent transaction when transaction information according to an embodiment of the present invention is newly registered.
  • FIG. 6 is a diagram showing an example of registration information when a plurality of records are registered according to an embodiment of the present invention. It is a figure showing an example of a sale data list display screen concerning an embodiment of the present invention.
  • FIG. 1 It is a figure showing an example of a purchase data list display screen concerning an embodiment of the present invention. It is a figure showing an example of a transaction list display screen concerning an embodiment of the present invention. It is a flowchart showing the generation operation of the transaction list display screen according to the embodiment of the present invention. It is a figure showing an example of a purchase data list display screen concerning an embodiment of the present invention. It is a figure showing an example of a transaction list display screen concerning an embodiment of the present invention. It is a figure showing an example of a purchase amount post-designation screen concerning an embodiment of the present invention. It is a figure showing an example of a transaction list display screen concerning an embodiment of the present invention. FIG.
  • FIG. 6 is a diagram illustrating rules for the display format of buying amounts and selling amounts on a transaction list display screen according to an embodiment of the present invention. It is a figure showing an example of average yield rate information concerning an embodiment of the present invention. It is a figure showing an example of a yield rate time series display screen concerning an embodiment of the present invention.
  • 3 is a flowchart showing a product list generation operation according to an embodiment of the present invention. It is a diagram showing an overview of a store entry management function according to an embodiment of the present invention.
  • FIG. 2 is a block diagram showing the functional configuration of a user terminal according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing an example of user information and company information according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing an example of store entry information according to an embodiment of the present invention.
  • FIG. 3 is a sequence diagram showing store entry management operations according to an embodiment of the present invention.
  • 12 is a flowchart illustrating an operation for generating an option list in a buyer column according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating the execution results of a query for generating an option list for a buyer column according to an embodiment of the present invention. It is a figure which shows the example of a display of the options of a buyer column based on embodiment of this invention. It is a figure showing an example of transaction information concerning an embodiment of the present invention.
  • FIG. 2 is a sequence diagram illustrating an order processing operation according to an embodiment of the present invention.
  • FIG. 3 is a diagram showing the relationship between transaction information of an order source and transaction information of an order source when transaction information that is order information according to an embodiment of the present invention is registered. It is a figure showing an example of an inventory allocation screen concerning an embodiment of the present invention. FIG. 3 is a diagram illustrating an example of inventory allocation information according to an embodiment of the present invention.
  • Embodiment 1 Embodiments of the present invention will be described below with reference to the drawings.
  • a market transaction management system that manages product purchase and sale information in a fresh food trading market will be described.
  • this embodiment provides a function that allows the flow of transactions to be grasped after the fact. This is the gist of the matter.
  • FIG. 1 is a diagram showing the overall configuration of a system according to this embodiment.
  • the market trading management system includes a service server 1 that provides services in the system, and a plurality of user terminals 2a to 2d (hereinafter generally referred to as (referred to as "user terminal 2").
  • users who use this system are traders who buy and sell products in the wholesale market. These include businesses, restaurants, and retail stores.
  • This format is a typical format in the wholesale market, and there are cases where a transporter is placed between each of the traders shown in FIG. 1, and where each trader is divided into multiple levels.
  • the service server 1 and user terminals 2a to 2d are connected to a network A such as the Internet, and can communicate with each other.
  • the service server 1 is a server managed by the operating entity of this system, and has the function of providing a GUI (Graphical User Interface) when using this system from the user terminal 2, and the buying and selling information input on each user terminal 2. Provides a function to accept and record.
  • the user terminal 2 is an information processing terminal such as a smartphone, tablet, notebook PC, or desktop PC, and is an electronic device used by a user who uses this system.
  • FIG. 2 is a diagram showing the hardware configuration of information devices such as the service server 1 and the user terminal 2 included in the system according to the present embodiment.
  • the system according to this embodiment can be realized by the hardware configuration of general information processing equipment, and as shown in FIG.
  • a hard disk drive (HDD) 40 and an I/F 50 are connected via a bus 80.
  • an LCD (Liquid Crystal Display) 60 and an operation unit 70 are connected to the I/F 50.
  • the CPU 10 is a calculation means and controls the operation of the entire information device.
  • the RAM 20 is a volatile storage medium in which information can be read and written at high speed, and is used as a work area when the CPU 10 processes information.
  • the ROM 30 is a read-only nonvolatile storage medium, and stores programs such as firmware.
  • the HDD 40 is a nonvolatile storage medium in which information can be read and written, and stores an OS (Operating System), various control programs, application programs, and the like.
  • the I/F 50 connects and controls the bus 80 and various hardware, networks, and the like.
  • LCD 60 is the visual user interface.
  • the operation unit 70 is a user interface such as a keyboard, a mouse, various hard buttons, a touch panel, etc. through which the user inputs information to the information device. Note that since the service server 1 is operated as a server, user interfaces such as the LCD 60 and the operation unit 70 can be omitted.
  • the service server 1 includes a request processing section 101, a vendor information processing section 102, a vendor information storage section 103, a transaction information processing section 104, and a transaction information storage section 105.
  • a software program for realizing the functional configuration shown in FIG. 3 is used as a market transaction management program.
  • the request processing unit 101 performs various processes in response to requests from applications running on the user terminal 2 and responds to the requests.
  • the vendor information processing section 102 performs processing such as registering information in the vendor information storage section 103 and searching and extracting information under the control of the request processing section 101.
  • the vendor information storage unit 103 stores information on vendor companies that are users of this system and information on their personnel.
  • the transaction information processing unit 104 performs processing such as registering information in the transaction information storage unit 105 and searching and extracting information under the control of the request processing unit 101.
  • the transaction information storage unit 105 stores information indicating the relationship between each transaction, in addition to the content and subject of the transaction conducted by the user of this system.
  • FIGS. 4(a) and 4(b) are diagrams showing the contents of one record of information stored in the vendor information storage unit 103, where FIG. 4(a) is user information and FIG. Information is shown respectively.
  • the user information includes information such as "user ID”, “password”, “person in charge”, “company ID”, “contact information”, and "receipt location”. include.
  • “User ID” is a user identifier that identifies a user who uses this system.
  • Password is authentication information for the user to log into this system.
  • "Person in charge name” is character information indicating the name of the user who uses this system.
  • "Affiliated company ID” is an identifier indicating the company to which the user belongs, but is left blank in the case of a user who uses the system as an individual.
  • Contact is the contact information of the user of this system, such as address, telephone number, email address, etc.
  • "Receiving location” is information that indicates where the user will deliver the item in the market when he or she buys it. For example, the user's assigned pickup location in the market or the location of the delivery vehicle. This is a parking place.
  • the company information includes information of "company ID”, "password”, "company name”, and "contact information”.
  • “Company ID” is an identifier for identifying a user who uses this system, and corresponds to "affiliated company ID” in FIG. 4(a).
  • the "password” is authentication information for logging into this system using the "company ID” of the record.
  • "Company name” is character information indicating the name and trade name of the company of the record.
  • Contact information is contact information for the company, such as address, phone number, and email address. Note that a "receipt location" may be specified for company information as well as for user information.
  • FIG. 5 is a diagram showing the contents of one record of transaction information stored in the transaction information storage unit 105.
  • the transaction information storage unit includes "transaction ID”, “buyer ID”, “seller ID”, “person in charge name”, “product code”, “product name”, “ Information on “Standards”, “Country of Origin”, “Quantity”, “Weight”, “Unit Price”, “Consumption Tax Rate”, “Transaction Date and Time”, “Parent Transaction ID”, “Receipt Confirmation”, “Remarks” and “Sold Out” including.
  • Transaction ID is a transaction identifier that identifies each transaction information record.
  • the "buyer ID” is a buyer identifier that identifies the trader who sold the product in the transaction, and corresponds to the "user ID” in FIG. 4.
  • the “seller ID” is a seller identifier that identifies the merchant who purchased the product in the transaction, and corresponds to the "user ID” in FIG. 4.
  • the "person in charge name” is the name of the person in charge of the vendor who purchased the product in the transaction.
  • a “product code” is a code number given to a product bought or sold in a transaction, and is used to identify fish of the same species but with different specifications.
  • Product name is the name of the product bought and sold in the transaction.
  • Standard is information that indicates the standard of the product bought and sold in the transaction. For example, for fish such as sardines, it is indicated by the weight per predetermined number of fish, such as "**kg/**fish". . In addition, in the case of tuna, it is a number that indicates the part such as “No. 1" to “No. 4", and in the case of shrimp, it is a number that indicates the part of the body, such as "16-20", “21-25", “26-30”, etc. It is indicated by the number of tails.
  • Oil is information indicating the origin of the product bought and sold in the transaction.
  • Quantity is information indicating the number of products (number of items) bought and sold in the transaction.
  • Weight is information indicating the weight of the product bought and sold in the transaction.
  • Unit price is information indicating the price per predetermined weight of the product bought and sold in the transaction.
  • Consption tax rate is information indicating the consumption tax rate applied to the transaction. Information such as “product name”, “standard”, “place of origin”, “quantity”, “weight”, and “unit price” is used as information on transaction details.
  • Transaction date and time is information indicating the date and time when the transaction was performed.
  • the "parent transaction ID” is a parent transaction identifier indicating a purchasing transaction of the product bought and sold in the transaction, that is, the parent transaction, and corresponds to the "transaction ID.”
  • “Receipt confirmation” is check information indicating whether or not the goods purchased and sold in the transaction have been received and confirmed at the buyer's receiving location.
  • "Remarks” is character information that can be freely input during transactions.
  • “Sale Ended” is check information indicating that the sale of the product purchased through the transaction has ended.
  • the market sales management application 200 is configured by reading software programs for configuring the market sales management application 200 into the RAM 20, and having the CPU 10 perform calculations according to those programs.
  • the market sales management application 200 according to this embodiment is a web application. That is, when the user terminal 2 accesses the service server 1 via the web browser installed on the user terminal 2, a program for configuring the market sales management application 200 is downloaded to the user terminal 2 as website information. , the market sales management application 200 is configured on the user terminal 2 according to the program.
  • the market sales management application 200 includes an operation reception section 201, a display processing section 202, and an information communication section 203.
  • the operation reception unit 201 receives a user's operation 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's operation details acquired by the operation reception unit 201 and the information acquired from the service server 1.
  • the information communication unit 203 exchanges information with the service server 1 according to the operating state of the market sales management application 200.
  • FIG. 7 is a sequence diagram showing the operation of newly registering transaction information in this system.
  • the seller's user terminal 2a accesses the service server 1 via the web browser function, and the GUI of the market sales management application 200 is displayed on the LCD 60 (S701).
  • login processing is performed by authentication using a user identifier such as an e-mail address included in the "user ID" or "contact” information and a "password.”
  • the operation reception unit 201 receives the operation contents of the operation unit 70 by the user, the information communication unit 203 acquires information from the service server 1 in response to the operation, and the display processing unit 202 uses the market sales management application 200 based on the information.
  • the GUI By controlling the GUI, a transaction information registration screen is displayed.
  • FIGS. 8A and 8B are diagrams showing a screen for registering sell data (hereinafter referred to as a "sell data registration screen") of the GUI of the market sales management application 200.
  • the selling data registration screen in this system includes input fields for inputting each piece of information explained in FIG. 5.
  • the sales data registration screen in this system includes a function to assist in inputting information in each input field.
  • the screens shown in FIGS. 8(a) and 8(b) are used as information input screens for accepting input of information to be stored in the transaction information storage unit 105.
  • the input field displayed as "Company” in FIG. 8(a) is an input field for specifying the trader who will purchase the product in the transaction.
  • this input field in addition to free input, it is also possible to select from displayed options, and the "company name" of the record stored in the vendor information storage unit 103 of the service server 1 is displayed as an option.
  • Each company name option is associated with a "user ID” shown in Figure 4, and when a company name is selected, the "user ID" associated with it is automatically selected as information to be input. .
  • the input field displayed as "product name” in FIG. 8(a) is an input field for specifying the product to be bought and sold in the transaction.
  • This input field is also selective, and the product names of products that the seller has already purchased are displayed as options. This function to display product name options will be explained.
  • a list generated based on the "product name” of the transaction information stored in the transaction information storage unit 105 is used. This list is generated in the screen information generation process in S701 of FIG. With reference to FIG. 9, details of the screen information generation process in S701 of FIG. 7 will be described.
  • the request processing unit 101 of the service server 1 first receives an authentication request including a user ID and password from the user terminal 2 requesting screen display (S901). Then, the vendor information processing unit 102 refers to the vendor 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).
  • the request processing unit 101 notifies the user terminal 2 that made the authentication request of the error (S906) and ends the process.
  • FIG. 10 is a diagram conceptually showing the process of extracting information using the "buyer ID” as a key in the transaction information storage unit 105.
  • “product code”, “product name”, and “standard” are "***, sardine, **kg/** tail", "***, tuna, No. 1", and " ***, shrimp, 16-20'' is extracted.
  • the request processing unit 101 extracts the information of "transaction ID”, “product code”, “product name”, “production area”, and “standard” from the extracted records, A list is generated for the "product name” options shown in FIG. 8(a) (S904). Then, the request processing unit 101 transmits the GUI information of the market sales management application 200 on the user terminal 2 and the list information generated in S904 to the user terminal 2 as a response to the authentication request (S905), and ends the process. . 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).
  • FIG. 11 is a diagram showing a display mode of options in the input column for "product name” shown in FIG. 8(a). As shown in FIG. 11, the list generated by the process of FIG. 9 is displayed as options.
  • the login process and the process of generating the option list for the "Product Name" input field have been described as a series of processes, but the process between S902 and S903 is not necessarily continuous, and there may be a time lag.
  • the user terminal 2 performs an operation to display the sales data registration screen with the login operation already performed, and the user terminal 2 requests the service server 1 for screen information.
  • the service server 1 executes the processes from S903 onwards.
  • the operation reception unit 201 receives the operation content, and the display processing unit 202 processes the selected information to display the "product name", "product name”, etc. shown in FIG. "Country of origin” and "Standard" are automatically entered.
  • the display processing unit 202 processes the selected information to display the "product name", "product name”, etc. shown in FIG. "Country of origin” and "Standard" are automatically entered.
  • FIG. 8(a) and FIG. 11 an example was explained in which the information of "Product Name", “Production Area”, and “Standard” are selected all at once in the input field of "Product Name”. , it is also possible to make individual selections in each input field, and options can be generated by the same process as above.
  • buttons for "add” or “delete” a "unit” are displayed on the selling data registration screen.
  • buttons for “Add” or “delete” a "unit” are displayed on the selling data registration screen.
  • input fields for "Quantity” and “Weight” are added as shown in Figure 8(b), and multiple "Quantity” and “Weight” input fields are added. It becomes possible to input.
  • the information transmitted in S702 includes the information input on the screen shown in FIG. 8(a) as described above, but the information included by selecting the "Product Name” column is the "Product Code” shown in FIG. ",” and “product name,” as well as “transaction ID” information as shown in FIG. 10. It also includes the user ID authenticated in the login process of S701, that is, the logged-in user ID.
  • the request processing section 101 receives the information, the transaction information processing section 104 registers the information in the transaction information storage section 105 under the control of the request processing section 101, and processes the request.
  • the unit 101 performs response processing for the user terminal 2 (S703).
  • the login-authenticated user ID is registered as the "seller ID.” That is, here, the transaction information processing section 104 functions as a transaction information storage processing section.
  • FIG. 12 is a diagram showing the relationship between the record newly registered in the process of S703 and the record corresponding to the parent transaction.
  • the "transaction ID” in the record of the parent transaction is registered as the “parent transaction ID” of the newly registered record.
  • the "buyer ID” in the parent transaction record is the same as the “seller ID” in the newly registered record.
  • the "product code”, "product name”, and "place of origin” will also be the same.
  • the “standards” are basically the same, the information on the standards may differ between the time of purchase and the time of sale, such as when purchasing items are cut up and sold.
  • the user ID is the "seller ID” and the date information of the "transaction date and time” is included.
  • a screen showing a list of selling data registered on that day is displayed as a processing result screen indicating that information registration has been completed (S704).
  • FIG. 14 is a diagram showing an example of the sell data list screen displayed in the process of S704.
  • FIG. 14 on the selling data list screen, among the information included in each record, "product", “production area”, “quantity”, “weight”, “unit price”, “location”, “Delivery status” information is displayed together for each company name corresponding to each buyer ID.
  • the "location” information is the “receiving location” information explained in FIG. 4.
  • FIG. 15 is a diagram showing an example of the purchase data list screen displayed in S705.
  • the service server 1 selects the user ID notified along with the request from among the data stored in the transaction information storage unit 105.
  • a list is sent to the user terminal 2, in which records are extracted that have the "buyer ID” and the date information of the "transaction date and time” is the current day.
  • a screen showing a list of buying data registered on that day is displayed as shown in FIG. 14.
  • the "Delivery status" item is a GUI that allows the user to add a check. For example, a user who makes purchases in an actual market purchases necessary products at various locations and stores. The products are then delivered from each store to a designated collection point and loaded into a vehicle. At that time, by checking the "Delivery status" item on the purchase data list display screen shown in Figures 14 and 15, you can check whether all sold products have been delivered or all purchased products have been delivered. can.
  • the user terminal 2 informs the service server 1 that the "Delivery Status" column has been checked.
  • a "transaction ID” indicating the target record is notified.
  • 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 the record of the notified “transaction ID” and Update the "Status" check information.
  • the seller of the item may operate the item on the sales data list display screen explained in Figure 14 to check it, or both the seller and the buyer of the item may check the item. It may also be checked. This makes it possible to check whether the seller has delivered the product and whether the buyer has received the product.
  • the "Delivery status" item is shown as check data, but if the data is to be checked by both the buyer and seller as described above, it may be written as two-digit binary data, for example. , can be realized as one item by setting the state checked by the buyer as "10", the state checked by the seller as "01”, and the state checked by both parties as "11".
  • FIG. 16 is a diagram showing an example of a transaction list screen among the screens that are possible using the "parent transaction ID" in this system.
  • the transaction list screen in this system On the transaction list screen in this system, the purchase amount and sales amount of the products purchased by each user are compared and displayed. That is, the transaction list screen shown in FIG. 16 is used as the transaction amount display screen.
  • each user can prevent the purchase of products from being sold out or from erroneously concluding a transaction for more than the amount in stock.
  • FIG. 17 is a flowchart showing the operation of the service server 1 that receives a request for a transaction list display screen from the user terminal 2.
  • 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.
  • the information is passed from the request processing unit 101 to the transaction information processing unit 104, and the transaction information processing unit 104 Information is extracted from the transaction information storage unit 105 based on the ID" (S1701).
  • the transaction information processing unit 104 selects data in which the “buyer ID” is the notified “user ID” and the “transaction date and time” is the current day among the data stored in the transaction information storage unit 105. Extract.
  • the data extracted in S1701 is data on transactions in which the user purchased products on that day, that is, purchase transaction data, and the process in S1701 is a process for extracting the amount of products purchased.
  • the transaction information processing unit 104 After extracting the information in this way, the transaction information processing unit 104 selects each piece of extracted data in order and performs processing to generate a comparison screen as shown in FIG. 15 (hereinafter referred to as "comparison information generation processing"). ) repeatedly. Therefore, as a process for determining repetition, the transaction information processing unit 104 checks whether there is any remaining data that has not been selected as a target for comparison information generation processing among the extracted data (S1702).
  • the transaction information processing unit 104 selects one of the unselected data and refers to 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 among the data stored in the transaction information storage unit 105 (S1704).
  • the data extracted in S1704 is data on the sale of the purchased product in the transaction indicated by the "transaction ID” referenced in S1703, that is, sales transaction data, and the process in S1704 is a process for extracting the sales amount of the product. be.
  • the transaction information processing unit 104 that has extracted the sales transaction data for the selected purchase transaction refers to the "weight” and “unit price” of the extracted sales transaction data, totals the "weight”, and adds the "unit price” to the "weight”.
  • the multiplied sales amount is totaled (S1705). As a result, the total amount and total sales amount of the selected purchased product are calculated.
  • the transaction information processing unit 104 displays the information displayed on the transaction list display screen as shown in FIG. Information such as “sales amount (yen),” “sales amount (kg),” and “sales end” is extracted and stored (S1706).
  • the transaction information processing unit 104 repeats the processes of S1703 to S1706 until there are no records extracted by the process of S1701 (S1702/YES), and when there are no unselected records (S1702/NO), the records are stored by the process of S1706. Based on the information obtained, screen information for displaying the transaction list display screen shown in FIG. 16 is generated and transmitted to the requesting user terminal 2 (S1707), and the process ends. In this way, the transaction information processing section 104 functions as a transaction amount display screen generation section.
  • FIG. 16 A screen as shown in FIG. 16 is displayed on the user terminal 2.
  • a display like the one shown in FIG. 16 makes it possible to objectively check the purchase amount and sales amount.
  • the "sold out” item is a GUI that allows the user to add a check mark.
  • the user terminal 2 sends a request to the service server 1 to update the "Sales Ended” check status by checking the "Transaction ID” of the target record. " (transaction ID selected in S1703).
  • the transaction information processing unit 104 extracts a record from the transaction information storage unit 105 based on the notified “transaction ID” and checks whether the extracted record is “sold out”. Update.
  • the vendor who sells the product inputs information about the product to be sold on the screens shown in FIGS. 8(a) and 8(b).
  • the "unit price” information is entered blank.
  • the "unit price” is displayed as undetermined, and as shown with diagonal lines in the figure, the transaction is not being accepted by the seller. The transaction is highlighted so that it can be objectively understood that the transaction is based on a sales request.
  • FIG. 19 is a diagram showing an example of a transaction list display screen when products for sales request transactions are displayed. As shown in FIG. 19, on the transaction list display screen that includes the products of the sales request transaction, the products of the sales request transaction are highlighted in the same way as in FIG.
  • the highlighted display as shown in FIGS. 18 and 19 is realized by the transaction information processing unit 104 that generates display information in the service server 1 in response to a request from the user terminal 2.
  • the transaction information processing unit 104 When the transaction information processing unit 104 generates display information for the purchase data list display screen or the transaction list display screen, the record related to the sales request transaction, that is, the record in which the purchase amount is blank, is highlighted.
  • Generate display information Such a display can be realized, for example, by setting a style sheet of a web source that configures the screen.
  • the buying side and the selling side discuss the sales amount (the "unit price” on the record) that is blank, and enter the information after the fact to clear the undetermined state.
  • the transaction needs to be completed.
  • a screen hereinafter referred to as " ⁇ Purchase amount post-specification screen'' will be displayed.
  • the request processing unit 101 receives the request, and the transaction information processing unit 104 searches the target record stored in the transaction information storage unit 105 based on the information included in the request. Update. Through such processing, the sales request transaction is completed.
  • each transaction is recorded as one record in a market transaction in which a product is circulated between multiple traders from upstream to downstream.
  • a "parent transaction ID" which is information indicating a transaction one upstream of the product to be traded, that is, a transaction related to the purchase of that product, is recorded.
  • the functions of this system include the function of issuing invoices and statements of delivery.
  • Such functionality can be implemented based on information stored in the system as shown in FIG. For example, if you want to issue an invoice by aggregating transactions by month, create a record where the "buyer ID" matches the billing company and the year and month of "transaction date and time” matches the billing month. It is possible to easily generate a bill by extracting the information.
  • the operation reception unit 201 on the user terminal 2 After receiving the operation details, the information communication unit 203 transmits a bill generation request to the service server 1.
  • the request processing section 101 receives the request and passes the information to the transaction information processing section 104.
  • the transaction information processing section 104 which has received the information from the request processing section 101, extracts the information stored in the transaction information storage section 105 based on the specified information, performs aggregation and listing, and displays the invoice. Generate display information for When the transaction information processing unit 104 generates bill display information, the request processing unit 101 transmits the information to the user terminal 2 that made the request. As a result, the invoice is displayed on the user terminal 2, and can be sent to the billing company based on the buyer ID or output as paper by printing it out.
  • records are extracted for the user IDs of all users belonging to that company.
  • the user IDs of all users belonging to that company For example, in S1701 of FIG. 17, in addition to a record whose "buyer ID" is the "company ID” of the logged-in company, in addition to the record whose "company ID” of the user information explained in FIG. 4(a) is "the logged-in company ID”. All "user IDs” of records that match the "company ID” are acquired, and records where all the acquired "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 that company. The function of referring to the transaction information of the affiliated user by logging in with the company ID is the same in the subsequent embodiments as well.
  • Embodiment 2 functions implemented on the transaction list display screen described with reference to FIG. 16 will be explained in consideration of the actual situation at the site.
  • a purchase amount (kg) and a sale amount (kg) can be displayed in a comparative manner.
  • a list of transactions will be displayed when the purchased items are sold out.
  • the "buying amount (kg)” and “selling amount (kg)” displayed on the screen should match.
  • FIG. 21 is a diagram showing an example of a transaction list display screen according to the present embodiment.
  • the display unit of "sales volume” is in a format that corresponds to the sales format of each product, and the yield rate calculated in that transaction for each product and the yield rate of the product as a whole are shown.
  • the "yield rate/average” item is displayed to compare and display the average value of the yield rate.
  • Information for displaying the screen shown in FIG. 21 is generated by the transaction information processing unit 104 similarly to FIG. 16. That is, the transaction information processing section 104 functions as a yield rate calculation section.
  • the "quantity” may not be recorded at the time of purchase.
  • shrimp are traded by weight in purchasing transactions, and the number of shrimp per predetermined weight is stored as a "standard”. Therefore, in the example of FIG. 21, the expected number of fish to be purchased calculated from the "standard” information and the "weight” information is displayed as "40 (fish)".
  • the "sales amount” is “6 (kg) + 38 (tails)"
  • the "weight” and “number” are aggregated and displayed.
  • the records extracted in S1704 of FIG. 17 include records in which "weight” is blank and records in which it is not.
  • both "quantity” and “weight” are selected as the “purchasing quantity” to be compared, and if "quantity” is blank, the expected quantity may be calculated from “standard” and "weight”. The same is true.
  • FIG. 22 is a diagram showing the display format rules for each product as shown in FIG. 21.
  • the rules shown in FIG. 22 are stored in the transaction information processing unit 104. Such display selection for each product is executed in S1705 of the process described in FIG. 17.
  • the transaction information processing unit 104 that extracted the sales data in S1704 selects the display format of "buying amount” and "selling amount” on the transaction list display screen according to the rules shown in FIG.
  • the transaction information processing unit 104 calculates the yield rate in S1705.
  • the amount is simply calculated by dividing the "selling amount” by the “buying amount.”
  • the transaction information processing unit 104 calculates the respective yield rates and adds them up.
  • the transaction information storage unit 105 stores average yield rate information (hereinafter referred to as "average yield rate information") for each product and each standard.
  • FIG. 23 is a diagram illustrating an example of average yield rate information according to this embodiment. As shown in FIG. 23, the average yield rate information according to this embodiment includes information on "product", “standard”, “average yield rate”, and "number of samples”. That is, here, the transaction information storage section 105 functions as an average yield rate storage section.
  • the "average yield rate” is information indicating the average value of the yield rates calculated in the system so far. This allows the average value of the yield rate of products traded via this system to be grasped. Further, the "number of samples” is a value indicating the number of data used to calculate the "average yield rate” at that point.
  • the transaction information processing unit 104 extracts a record that matches the "product" and "standard” of the record being processed, that is, the record selected in S1703, from the average yield rate information, and " to get. Then, in S1706, information for displaying the contents as shown in FIG. 21 is stored. Through such processing, screen information for displaying a transaction list display screen as shown in FIG. 21 is generated.
  • the user who has sold all of the respective products operates the check box for "Sales Ended” on the screen shown in FIG. 21. Then, the yield rate information is updated along with the update of "Sales Ended" in the transaction information storage unit 105 described in the first embodiment.
  • the transaction information processing unit 104 performs an update process for the yield rate information in addition to the above-described "sales end" check update process.
  • the transaction information processing unit 104 first extracts the record of the notified "transaction ID" from the transaction information storage unit 105, and stores it in association with the notified yield rate. Therefore, the transaction information storage unit 105 according to the present embodiment includes yield rate information in addition to the information shown in FIG.
  • the transaction information processing unit 104 performs the process of updating the average yield rate information shown in FIG. 23.
  • the transaction information processing unit 104 acquires the "product" and "standard” from the record of the notified "transaction ID”, and selects records that match each other as the average yield rate information shown in FIG. 23. Extract from. Then, assuming the "number of samples" of the extracted records as n, the updated yield rate is calculated using the following equation (1), and the "average yield rate" is updated, and the "number of samples” is incremented.
  • the yield rate of each transaction information stored in the transaction information storage unit 105 and the information on the average yield rate shown in FIG. 23 are updated.
  • the user can compare and check the yield rate of each product and the average yield rate using a screen as shown in FIG. 21.
  • FIG. 24 is a diagram showing an example of a yield rate time-series display screen (hereinafter referred to as a "yield rate time-series display screen") according to the present embodiment.
  • a line graph with the vertical axis as the yield rate (%) and the horizontal axis as the transaction date and time shows the results that match a specific combination of "product" and "standard”.
  • the "yield rate” of records is displayed in chronological order. Further, as shown in FIG. 23, the stored average yield rate is displayed as a broken line.
  • the screen shown in FIG. 24 is displayed on the user terminal 2 based on screen display information generated by the service server 1.
  • the service server 1 generates screen display information for displaying the screen shown in FIG. 24 in response to a request from the user terminal 2.
  • the request from the user terminal 2 to the service server 1 includes information indicating that it is a request to generate display information for the yield rate time series display screen shown in FIG. 24, as well as the "user ID" of the requester, the user. Contains information such as "product name” and "standard”. That is, when requesting display information on the yield rate time series display screen, the user specifies at least "product name” and "standard” and performs the request operation.
  • the transaction information processing unit 104 creates a record in which the notified "user ID” matches the "buyer ID” and the notified "product name” and “standard” match. is extracted from the transaction information storage unit 105.
  • the transaction information processing unit 104 refers to the "transaction date and time” and "yield rate” of the records thus extracted, and generates information for displaying a graph as shown in FIG. 24.
  • the transaction information processing unit 104 refers to the average yield rate information based on the notified "product” and “standard”, extracts matching records, and extracts the "average yield rate” of the corresponding "product” and “standard”. Get “rate”. As a result, information for displaying the broken line shown in FIG. 24 is generated.
  • the screen shown in FIG. 24 allows the user to grasp the "yield rate" of the products purchased by the user in chronological order for each "product" and "standard.”
  • the yield rate decreases around timing t1 .
  • the buying amount and selling amount are compared on the transaction list display screen. It becomes possible to display.
  • Embodiment 3 a real-time information reflection function of the product list on the sales data registration screen described in FIGS. 9 to 11 and an additional function related to registration of transaction information in FIGS. 8(a) and 8(b) will be described.
  • the products displayed in front of the store are sold and the products are handed over once the sale is completed, so the products are reliably delivered to the buyers.
  • the sales contract is made first, and the product is sometimes delivered afterwards. Therefore, immediately after a transaction is concluded, there will be products left on site, and unless the products are reliably reserved for each sales contract, there is a possibility that more products will be sold than the amount purchased.
  • FIG. 25 is a flowchart showing details of the process of S904 in FIG.
  • Embodiment 1 the case where information is extracted from all the records extracted by the process of S903 and a list is generated in S904 has been described as an example.
  • records to be included in the list are selected from among the records extracted in the process of S903.
  • the transaction information processing unit 104 performs processing by sequentially referring to the records extracted in S903. Therefore, first, it is checked whether any unselected data remains among the extracted data (S2501). If there is still unselected data (S2501/YES), the transaction information processing unit 104 selects one of the unselected data (S2502), and checks whether "sale ended" has been checked (S2503). ).
  • the transaction information processing unit 104 excludes the selected record from the list (S2504), and repeats the process in S2501.
  • the transaction information processing unit 104 refers to the "transaction ID" of the selected record and enters the data stored in the transaction information storage unit 105. Among them, records with matching "parent transaction ID” are extracted (S2505).
  • the record extracted in S2505 is a record indicating a transaction in which a product purchased through the transaction of the record selected in S2502 was sold.
  • the transaction information processing unit 104 totalizes the sales amount by referring to the "number” and "weight” of the extracted records (S2506).
  • the process of S2506 is basically a process of summing up "weight”, but as explained in the second embodiment, "weight" information may not be input in a sales transaction. Therefore, in S2506, the transaction information processing unit 104 appropriately selects a sales amount aggregation method according to the rules as explained in FIG. 22.
  • the transaction information processing unit 104 that has aggregated the sales amount checks the purchase amount based on the record selected in S2502, and compares it with the aggregation result in S2506 (S2507).
  • the transaction information processing unit 104 basically refers to the "weight”, but may refer to the "number” depending on the tally result in S2507, or may refer to the "quantity" calculated from the "standard” and "weight”. Use the expected number of pieces.
  • the transaction information processing unit 104 displays only records other than those excluded from the list, that is, records that are determined to be still in stock.
  • a product list is generated as in S904 of 9 (S2508), and the process ends. Through this process, the selection list of products shown in Figures 8(a) and (b) is generated in a timely manner according to the sales status of purchased products, and products that have already been sold out are not erroneously traded. You can prevent this from happening.
  • the product list information includes information such as "transaction ID”, “product code”, “product name”, “place of origin”, and "standard”.
  • the system further includes the above-mentioned “inventory amount information”.
  • “inventory information” associated with the product name is referenced and compared with the information input in "weight.”
  • Embodiment 4 a function for assisting input in the "buyer" field on the sell data registration screen shown in FIGS. 8(a) and 8(b) will be described.
  • One of the features of this system is that buyers and sellers are identified by IDs in recording transaction information, as explained in FIG. 12 and the like. Therefore, when registering information on the sales data registration screen shown in FIGS. 8(a) and 8(b), it is necessary to accurately specify the user who is purchasing the product using the "buyer" column.
  • the input in the "buyer” field prohibits the user from freely inputting information, and the information has already been registered in the user information and company information in the vendor information storage unit 103 of the service server 1, as shown in FIGS. 4(a) and (b). It is preferable to use a multiple-choice format with the information listed as options. However, as the number of registered user information and company information increases, the number of options also increases. When there are a huge number of options, it is inconvenient for the user to have to search for a buyer from among the huge number of options.
  • the present embodiment addresses such problems by detecting when a buyer visits the store of each trader conducting transactions in the market, and when each store registers transaction information as a seller.
  • the system assists the selection of "buyers” by preferentially displaying users whose visits to the store are detected as options for "buyers.”
  • FIG. 26 is a diagram showing the store visit detection function according to this embodiment.
  • a store communication device 3 is installed in each store to detect the terminal of a user who is a buyer. That is, the store communication device 3 functions as a store entry recognition section.
  • the store communication device 3 according to the present embodiment is a small information processing terminal having a Bluetooth function and a network communication function, and has a hardware configuration similar to the configuration described in FIG. 2. Furthermore, by installing software on the user terminal 2 used by a user at the store, the user terminal 2 can be made to function as the store communication device 3.
  • the user terminal 2 of the user visiting the store has the same configuration as the embodiment described above except that it has a short-range communication antenna 90 as shown in FIG. communicate.
  • the store communication device 3 recognizes that the user terminal 2 has entered the store through short-range communication with the user terminal 2 using the Bluetooth function, and transmits store entry information to the service server 1 via the network A.
  • FIGS. 28(a) and 28(b) are diagrams showing examples of user information and company information stored in the vendor information storage unit 103 of the service server 1 according to the present embodiment.
  • the user information and company information according to this embodiment include information on "terminal identifier" in addition to the contents explained in FIGS. 4(a) and 4(b). include.
  • This "terminal identifier" is information that can uniquely identify the user terminal 2 and is information that the store communication device 3 can acquire from the user terminal 2 via Bluetooth communication, and is typically a MAC (Media Access Control) address is used.
  • MAC Media Access Control
  • the vendor information processing unit 102 registers the information in the vendor information storage unit 103, and in the process of exchanging the information, by acquiring the MAC address of the terminal used by the user, as shown in FIG. "terminal identifier" is registered.
  • the vendor information processing unit 102 acquires the MAC address of the terminal used by the user and compares it with the "terminal identifier" associated with the logged-in user ID. do. As a result, if the two are different, the vendor information processing unit 102 stores the acquired MAC address as a "terminal identifier" in association with the user information or company information of the user who has additionally logged in. This makes it possible to identify the user based on the "terminal identifier" even if the user uses multiple terminals.
  • terminal identifier can be associated with multiple different user IDs.
  • FIGS. 29(a) and 29(b) are diagrams showing examples of store entry information according to the present embodiment
  • FIG. 29(a) shows information transmitted by the store communication device 3 to the service server 1
  • FIG. b) is a diagram showing the contents of one record of the entry information table stored in the vendor information storage unit 103 in the service server 1.
  • FIG. 30 is a sequence diagram showing the store entry detection process according to this embodiment.
  • terminal identifier Users shopping around in the market where this system has been introduced carry a user terminal 2 with the functions described in FIG. 27, and as described in FIGS. is registered in the vendor information storage unit 103 of the service server 1 as a "terminal identifier.”
  • the store communication device 3 installed in each store included in the market constantly detects terminals using the Bluetooth function, and when the user terminal 2 enters the communication range, it detects the user terminal 2 via the Bluetooth function. At the same time, the MAC address of the user terminal 2 is acquired as a terminal identifier (S3001).
  • pairing may be required between the store communication device 3 and the user terminal 2 in advance for the process of S3001.
  • each user can pair the store communication device 3 with his or her own user terminal 2 at a store that he or she frequently uses, so that from the next time onwards, he or she can pair the store communication device 3 with his or her own user terminal 2 without having to perform any pairing operations.
  • the process of S3001 is automatically executed by simply visiting a store with the .
  • the store communication device 3 that has acquired the terminal identifier from the user terminal 2 sets the preset user ID or company ID of the store as the "store entry ID,” and the acquired terminal identifier as the "entering person identifier,” and stores the current information. It is sent to the service server 1 along with the time (S3002). This "store entry ID" is used as a store identifier. As a result, the information shown in FIG. 29(a) is transmitted to the service server 1.
  • the service server 1 that has received the information shown in FIG. Search for "terminal identifier”. Then, the user ID of the user information extracted as a result of the search or the company ID of the company information is acquired as a "store entry ID”, and the user enters the store with the "store entry ID” and "store entry date and time” received in S3002. It is stored in the vendor information storage unit 103 as an information table (S3003). As a result, the information shown in FIG. 29(b) is recorded in the service server 1.
  • the information shown in FIG. 29(b) makes it clear who entered the store ("store entry ID”), where ("store entry ID”), and when ("store entry date and time”). Based on such circumstances, the gist of the present embodiment is to adjust the option list in the "buyer" column when registering information on the selling data registration screen shown in FIGS. 8(a) and 8(b).
  • the vendor information processing unit 102 is configured to input the seller's user ID and store entry screen. Generate a list of options for the "buyer" column based on the information table.
  • FIG. 31 is a flowchart showing the processing.
  • FIG. 31 shows a case where the user terminal 2 requests the service server 1 for screen information of the "selling data registration screen” in a state where the login process has already been performed.
  • the request processing unit 101 in the service server 1 receives a request for screen information for the “selling data registration screen” from the user terminal 2 (S3101)
  • the vendor information processing unit 102 sends a message to the vendor information storage unit 103 regarding the “buyer”
  • a query is executed to generate a column option list (S3102).
  • the query executed in S3102 first extracts the "user ID” and "person in charge” from the user information, extracts the “company ID” and “company name” from the company information, and extracts the "user ID” and "company ID” from the company information. ", "person in charge name” and "company name” are concatenated to create a table whose contents are "user name/company name” and “user ID/company ID” (hereinafter referred to as “user/company concatenation table”). generate.
  • the "store entry ID" in the store entry information table is searched based on the user ID notified at the time of the request.
  • a record whose "store entry ID” is the store that requested the "sales data registration screen” is extracted.
  • the record of the user/company concatenation table whose "enterer ID” of the record extracted in this way matches the "user ID/company ID” it is associated with that "enterer ID”. Associate the date and time of entry. This results in a table configuration as shown in FIG. 32.
  • the items are rearranged in descending order so that blank columns are placed later in the order for "date and time of store entry.”
  • users/companies are sorted in the order in which they recently entered the store that requested the "sales data registration screen", and users/companies that do not have entry information are postponed.
  • the vendor information processing unit 102 generates the execution result of such a query as an option list in the "buyer" column (S3103), and ends the process.
  • the operation shown in FIG. 31 is a process executed when requesting screen information for the "sell data registration screen", and when generating the screen information for the "sell data registration screen", the process is performed as described in the first embodiment.
  • the process in FIG. 9 is also executed.
  • the "buyer” options on the "selling data registration screen” are sorted in the order of new arrivals to the target store, as shown in Figure 33. will be displayed. Therefore, users on the seller's side who register transaction information can easily select buyers who are in the store and are displayed with priority, without having to search for the target buyer from a huge number of registered users/companies. It becomes possible.
  • the Bluetooth function is used as a mechanism for detecting entry into a store.
  • This is a function that is naturally implemented in mobile terminals such as general smartphones, and is effective in that it can be easily realized and disseminated.
  • Communication function may also be used. This is possible because the mechanism is not much different from the above, only the Bluetooth function is replaced with the NFC function.
  • each store is presented with a sticker, signboard, etc. printed with an image code encoded with the store's ID and a URL (Uniform Resource Locator) that provides web access for notification of entry.
  • a URL Uniform Resource Locator
  • a user visiting the store reads the code with a camera mounted on his or her user terminal 2 to access the encoded URL on the web.
  • This web access is a web access for notifying the service server 1 of entering the store (hereinafter referred to as "store entry notification web access"), and the user ID or company ID of each store is will be notified.
  • the service server 1 that has received the store entry notification web access from the user terminal 2 returns a login screen to the user terminal 2 in order to request the user terminal 2 to log in.
  • the user ID or company ID of the user who is the buyer is notified to the service server 1, and information as shown in FIG. 29(b) is recorded in the service server 1.
  • this last login process will be omitted and the user ID or company ID that has already been logged in will be notified from the user terminal 2 to the service server 1. be able to.
  • the image code may be presented by the user terminal 2 of the user who is the buyer, and read by a camera installed in a terminal installed at the store (hereinafter referred to as the "store entry management terminal"). It is possible to obtain similar effects.
  • the user ID or company ID of the user is encoded in the image code presented by the user terminal 2 of the user who is the buyer.
  • a user who enters a store uses the GUI function of this system to display on the screen a code in which his or her logged-in user ID or company ID is encoded.
  • a function can be realized by the request processing unit 101 of the service server 1 generating screen information in response to a request from the user terminal 2 and sending it back to the user terminal 2.
  • it can also be realized by the function of a program such as JavaScript that is downloaded and operated on the user terminal 2 side without communication with the service server 1.
  • the store entry management terminal decodes the read code and sends the user ID or company ID obtained to the store registered in advance. This information is sent to the service server 1 along with the user ID or company ID of the store as store entry information. As a result, information as shown in FIG. 29(b) is recorded in the service server 1, and the same effect as described above can be obtained.
  • Embodiment 5 In Embodiments 1 to 4, an example has been described in which a product to be sold is selected from among products whose purchase has already been confirmed at an upstream vendor, and transaction information is input. On the other hand, in the actual situation of transactions, there are cases in which a downstream vendor informs in advance of a transaction reservation or a desire to sell, that is, places an order for a product for which the upstream vendor has not yet confirmed its purchase.
  • transaction information is not stored in the transaction information storage unit 105 for products whose purchase is not confirmed at the upstream vendor, so even if the order details are recorded as transaction information, the upstream vendor of the product It is not possible to specify the "parent transaction ID" that specifies the purchasing transaction. In this embodiment, such an aspect will be explained.
  • FIG. 34 is a diagram showing the contents of one record of transaction information stored in the transaction information storage unit 105 according to the present embodiment.
  • the transaction information according to this embodiment includes information on an "order flag” and an "order source ID” in addition to the content described in FIG.
  • the "order flag” is an identifier indicating that the transaction information record is order information, that is, a request for a product from a downstream vendor to an upstream vendor.
  • the "order source ID” is the opposite of the "parent transaction ID” explained in Embodiment 1, and is used when the transaction information record is order information, and further based on the order received from the downstream vendor. In the case of order information for issuing an order to an upstream vendor, this information specifies the transaction information record of the order information received from the downstream vendor. Since orders are often placed to upstream vendors for products of the same type and standard received from multiple downstream vendors, multiple "order source IDs" may be specified as shown in Figure 34. is common.
  • FIG. 35 is a sequence diagram showing the order information processing operation according to this embodiment.
  • a retail store orders a product from a broker, and based on the order, the broker issues an order to a large wholesaler.
  • the retail store operates the user terminal 2d to register order information.
  • FIG. 36 is a diagram showing an example of an order data registration screen according to this embodiment.
  • the order data registration screen includes input fields for inputting transaction information similar to the sell data registration screen explained in FIGS. 8(a) and 8(b), but The major difference is that it specifies the seller rather than the buyer.
  • a request for registering order information is sent from the user terminal 2d to the service server 1. (S3501).
  • transaction information is recorded in the transaction information storage unit 105 by the transaction information processing unit 104 in the service server 1. That is, the transaction information processing section 104 functions as an order reception processing section.
  • the user ID or company ID that logged in when the screen of FIG. 36 was displayed is registered as the "buyer ID” and the "order flag" is registered in an on state.
  • the ordering vendor has not yet allocated inventory and the "parent transaction ID" is undetermined, so it is left blank. be registered.
  • FIG. 37 is a diagram showing an order data list display screen according to this embodiment.
  • the user terminal 2c of the broker which is the vendor specified as the order destination in the order information, sends a request for screen information and a logged-in user ID or company ID to the service server 1 according to the user's operation. It is displayed by doing so (S3502).
  • the transaction information processing unit 104 processes data in which the user ID notified with the request matches the "buyer ID” and the "order flag” is on.
  • the screen information is extracted and displayed collectively for each "seller ID” as shown in FIG. 37.
  • the request processing unit 101 transmits the screen information generated in this way to the requesting user terminal 2c.
  • the broker After confirming the order in this way, the broker places an order to an upstream vendor to secure inventory based on the received order. At this time, if there are orders for the same product from multiple different vendors with the same origin and standard, it is possible to place the orders all at once. Therefore, on the screen shown in FIG. 37, the user selects, by tapping or clicking, an order record that will be the source of an order to be sent to a further upstream vendor. The selected record is clearly displayed on the GUI, such as by being displayed in reverse color, but a check box or the like for selection may also be provided.
  • the user inputs information and taps the "Register” button in the same manner as in S3501, and the user terminal 2c requests the service server 1 to register the order information. It is transmitted (S3503).
  • the service server 1 is notified of the transaction ID of the order record selected on the screen shown in FIG. 37, along with the user ID or company ID used for login.
  • transaction information is recorded in the transaction information storage section 105 by the transaction information processing section 104 in the service server 1.
  • the transaction ID of the original order record is recorded as the "order source ID.”
  • the transaction information processing unit 104 extracts the record of the "transaction ID” that matches the "order source ID". This record is the record of the order source, and as described above, the "parent transaction ID” is blank. The transaction information processing unit 104 writes the "transaction ID” assigned to the newly added record into the "parent transaction ID” of the record thus extracted, and updates the parent transaction ID (S3504).
  • FIG. 38 shows transaction information for an order from a retail store to a wholesaler registered in S3501 (hereinafter referred to as "primary order”) and transaction information for an order from a broker to a wholesaler registered in S3503 (hereinafter referred to as "primary order”).
  • FIG. 38 the "seller ID” of the primary order is the same as the “buyer ID” of the secondary order, and the “transaction ID” of the primary order is specified as the “order source ID” of the secondary order. Further, the "order source ID” of the primary order is blank.
  • the "transaction ID" for which the secondary order is issued and numbered is written as the "parent transaction ID" of the primary order.
  • the connection relationship of transaction information which is one of the gist of this system. Note that by registering the "parent transaction ID", it is assumed that the transaction information has been processed as an order, and the "order flag" may be turned off. As a result, it is no longer displayed on the screen shown in FIG. 37.
  • the order information by the middleman is registered in this way, the order information can be confirmed on the order data list display screen of the large wholesaler specified as the order destination in the order information.
  • the user terminal 2b of the large wholesaler which is the vendor specified as the order destination in the order information, sends a request for screen information and the logged-in user ID or company ID to the service server 1 in accordance with the user's operation.
  • an order data list display screen is displayed on the large wholesaler's user terminal 2b as in FIG. 37 (S3505).
  • the ordering function according to this embodiment is based on the premise that a retail store or restaurant places an order in order to secure in advance the products that will be needed from the next day onward.
  • transaction information for products delivered from producers/purchasers to large wholesalers is generally filed on the previous day. Therefore, at the timing when an order is placed from a broker to a large wholesaler, the sale from the producer/purchaser to the large wholesaler is generally confirmed and the transaction information is stored in the transaction information storage unit 105.
  • large wholesalers can handle inventory reservations.
  • FIG. 39 is a diagram showing an example of the inventory allocation screen according to the present embodiment.
  • the order information selected on the screen shown in FIG. 37 when requesting the inventory allocation screen is extracted and displayed.
  • a list of products corresponding to the order information is displayed, and a list of transaction information in which the user ID or company ID of the user (in this case, a major wholesaler) is the "buyer ID" is displayed.
  • a screen like the one shown in FIG. 39 is realized by the service server 1 extracting information from the transaction information storage unit 105 in response to a request received from the user terminal 2b in S3506.
  • the large wholesaler operates the user terminal 2b, selects the inventory to be allocated for the displayed order information from the transaction information displayed as "corresponding inventory”, and taps the "Confirm” button. do.
  • the user terminal 2b requests the service server 1 to register inventory allocation (S3507).
  • FIG. 40 is a diagram showing an example of information (hereinafter referred to as "inventory allocation information") transmitted from the user terminal 2b to the service server 1 in response to the inventory allocation registration request in S3507.
  • the inventory allocation information includes a "target order information transaction ID" which is a transaction ID of transaction information as order information included in the "order information” list in FIG. It includes an "inventory allocation target transaction ID” which is a transaction ID of transaction information for which inventory is allocated.
  • the parent transaction ID is updated by writing (S3508).
  • actual inventory is allocated to orders placed in order from the downstream side, such as retail store, brokerage, and wholesaler, and order processing is completed.
  • the premise is that in a system where the transaction flow is recorded by specifying the upstream transaction ID from the downstream transaction information using the "parent transaction ID,” an order is placed from the downstream side to the upstream vendor. However, it becomes possible to record the transaction flow using the "parent transaction ID".
  • the extraction condition for the corresponding inventory list is transaction information in which the user ID or company ID of the vendor who allocates inventory (large wholesaler in the above case) is the "buyer ID", and the order
  • transaction information selected as information and the "product" match are extracted. This is just an example, and since inventory is actually allocated according to the production area and standards specified in the order, "production area” and “standards” may also be used as extraction conditions.
  • the "transaction date and time” may be used as a condition for the order date and time, or records with a "sales end” flag may be excluded.
  • the ordering side may issue order information with a range of amounts, and the order receiving side may determine the amount within that range.
  • Service server 2a, 2b, 2c, 2d User terminal 3 Store communication device 10 CPU 20 RAM 30 ROMs 40 HDD 50 I/F 60 LCD 70 Operation section 80 Bus 90 Near field communication antenna 101 Request processing section 102 Vendor information processing section 103 Vendor information storage section 104 Transaction information processing section 105 Transaction information storage section 200 Market sales management application 201 Operation reception section 202 Display processing section 203 Information communication Department

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握すること 【解決手段】市場における商品の取引に関する情報を管理する市場取引管理システムであって、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする。

Description

市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法
　本発明は、市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法に関する。
　生鮮卸売市場においては、日々膨大な量の取引が行われるが、その取引の管理は未だアナログな手作業で行われているのが実情である。生鮮卸売市場における取引を自動化する方法として、卸売業者に入庫した商品を情報管理し、仲買、仲卸等のそれぞれの段階でそれぞれの商品の所有者の情報を更新し、出庫により在庫を更新するシステムが提案されている（例えば、特許文献１参照）。
特開２００８－１１７４１０号公報
　特許文献１に記載のシステムによれば、市場に入荷した商品についての所有者が書き換えられることにより、取引の結果としてそれぞれの商品を所有することとなった者を把握することが可能となる。しかしながら、所有者が書き換えられる結果、取引の過程を事後的に把握することはできない。
　本発明は、上記実情を考慮してなされたものであり、商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握することを目的とする。
　上記課題を解決するために、本発明の一態様は、市場における商品の取引に関する情報を管理する市場取引管理システムであって、商品の取引に関する情報を記憶する取引情報記憶部と、前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部とを含み、前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする。
　本発明によれば、商品が転々流通する市場における商品取引の管理システムにおいて、流通する商品の取引の過程を事後的に把握することができる。
本発明の実施形態に係るシステムの全体構成を示す図である。 本発明の実施形態に係るシステムに含まれる情報機器のハードウェア構成を示す図である。 本発明の実施形態に係るサービスサーバの機能構成を示すブロック図である。 本発明の実施形態に係るユーザ情報および企業情報の例を示す図である。 本発明の実施形態に係る取引情報の例を示す図である。 本発明の実施形態に係るユーザ端末の機能構成を示すブロック図である。 本発明の実施形態に係るシステムにおける情報登録動作を示すシーケンス図である、 本発明の実施形態に係る情報登録画面の例を示す図である。 本発明の実施形態にかかる商品名の選択肢リストを生成する動作を示すフローチャートである。 本発明の実施形態にかかる商品名の選択肢リストを生成する際の情報の抽出態様を示す図である。 本発明の実施形態に係る情報登録画面における商品名の選択肢の態様を示す図である。 本発明の実施形態に係る取引情報が新たに登録される際の親取引との情報の関係を示す図である。 本発明の実施形態に係る複数単位のレコードが登録される場合の登録情報の例を示す図である。 本発明の実施形態に係る売りデータ一覧表示画面の例を示す図である。 本発明の実施形態に係る買いデータ一覧表示画面の例を示す図である。 本発明の実施形態に係る取引一覧表示画面の例を示す図である。 本発明の実施形態に係る取引一覧表示画面の生成動作を示すフローチャートである。 本発明の実施形態に係る買いデータ一覧表示画面の例を示す図である。 本発明の実施形態に係る取引一覧表示画面の例を示す図である。 本発明の実施形態に係る買い額事後指定画面の例を示す図である。 本発明の実施形態に係る取引一覧表示画面の例を示す図である。 本発明の実施形態に係る取引一覧表示画面における買い量および売り量の表示形式のルールを示す図である。 本発明の実施形態に係る平均歩留まり率情報の例を示す図である。 本発明の実施形態に係る歩留まり率時系列表示画面の例を示す図である。 本発明の実施形態に係る商品リストの生成動作を示すフローチャートである。 本発明の実施形態に係る入店管理機能の概観を示す図である。 本発明の実施形態に係るユーザ端末の機能構成を示すブロック図である。 本発明の実施形態に係るユーザ情報および企業情報の例を示す図である。 本発明の実施形態に係る入店情報の例を示す図である。 本発明の実施形態に係る入店管理動作を示すシーケンス図である。 本発明の実施形態に係る買い手欄の選択肢リストの生成動作を示すフローチャートである。 本発明の実施形態に係る買い手欄の選択肢リスト生成のためのクエリの実行結果を示す図である。 本発明の実施形態に係る買い手欄の選択肢の表示例を示す図である。 本発明の実施形態に係る取引情報の例を示す図である。 本発明の実施形態に係る本発明の実施形態に係る注文処理の動作を示すシーケンス図である。 本発明の実施形態に係る注文データ登録画面の例を示す図である。 本発明の実施形態に係る注文データ一覧表示画面の例を示す図である。 本発明の実施形態に係る注文情報である取引情報が登録される際の注文元の取引情報との情報の関係を示す図である。 本発明の実施形態に係る在庫引当画面の例を示す図である。 本発明の実施形態に係る在庫引当情報の例を示す図である。
実施の形態１．
　以下、図面を参照して、本発明の実施形態を説明する。本実施形態では、生鮮食品の取引市場にて商品の売買情報を管理する市場取引管理システムについて説明する。そのような、上流側から下流側に複数の業者間を商品が転々と流通していく取引形態を管理するシステムにおいて、取引の流れを事後的に把握可能な機能を提供することが本実施形態に係る要旨である。
　図１は、本実施形態に係るシステムの全体構成を示す図である。図１に示すように、本実施形態に係る市場売買管理システムは、システムにおいてサービスを提供するサービスサーバ１と、システムを利用するそれぞれのユーザが利用する複数のユーザ端末２ａ～２ｄ（以降、総じて「ユーザ端末２」とする）とを含む。
　図１に示すように、本システムを利用するユーザは、卸売市場において商品を売買する業者であり、図１においては取引の上流側から下流側に向かって生産・仕入れ業者、大卸業者、仲買業者および飲食店や小売店等である。この形態は卸売市場における代表的な形態であり、図１に示すそれぞれの業者の間に輸送業者が入る場合や、それぞれの業者が複数の階層に別れている場合などもある。サービスサーバ１およびユーザ端末２ａ～２ｄはインターネット等のネットワークＡに接続されており、互いに通信可能である。
　サービスサーバ１は、本システムの運営主体が管理するサーバであり、ユーザ端末２から本システムを利用する際のＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）の提供機能や、各ユーザ端末２において入力される売買の情報を受け付けて記録する機能を提供する。ユーザ端末２は、スマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の情報処理端末であり、本システムを利用するユーザが使用する電子機器である。
　図２は、本実施形態に係るシステムに含まれるサービスサーバ１、ユーザ端末２等の情報機器のハードウェア構成を示す図である。本実施形態に係るシステムは一般的な情報処理機器のハードウェア構成によって実現可能であり、図２に示すように、ＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）１０、ＲＡＭ（Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｍｅｍｏｒｙ）２０、ＲＯＭ（Ｒｅａｄ　Ｏｎｌｙ　Ｍｅｍｏｒｙ）３０、ＨＤＤ（Ｈａｒｄ　Ｄｉｓｋ　Ｄｒｉｖｅ）４０およびＩ／Ｆ５０がバス８０を介して接続されている。また、Ｉ／Ｆ５０にはＬＣＤ（Ｌｉｑｕｉｄ　Ｃｒｙｓｔａｌ　Ｄｉｓｐｌａｙ）６０および操作部７０が接続されている。
　ＣＰＵ１０は演算手段であり、情報機器全体の動作を制御する。ＲＡＭ２０は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、ＣＰＵ１０が情報を処理する際の作業領域として用いられる。ＲＯＭ３０は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。ＨＤＤ４０は、情報の読み書きが可能な不揮発性の記憶媒体であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）や各種の制御プログラム、アプリケーション・プログラム等が格納される。
　Ｉ／Ｆ５０は、バス８０と各種のハードウェアやネットワーク等を接続し制御する。ＬＣＤ６０は視覚的ユーザインタフェースである。操作部７０は、キーボード、マウス、各種のハードボタン、タッチパネル等、ユーザが情報機器に情報を入力するためのユーザインタフェースである。尚、サービスサーバ１は、サーバとして運用されるため、ＬＣＤ６０や操作部７０等のユーザインタフェースは省略可能である。
　このようなハードウェア構成において、ＲＯＭ３０やＨＤＤ４０若しくは図示しない他の記憶媒体に格納されたプログラムがＲＡＭ２０に読み出され、ＣＰＵ１０がそれらのプログラムに従って演算を行うことによりソフトウェアの機能が構成される。このようにして構成されたソフトウェアの機能と、ハードウェアとの組み合わせによって、本実施形態に係る市場売買管理システムを構成する各機器の機能を実現する機能ブロックが構成される。
　次に、本実施形態に係るサービスサーバ１の機能構成について図３を参照して説明する。図３に示すように、本実施形態に係るサービスサーバ１は、要求処理部１０１、業者情報処理部１０２、業者情報記憶部１０３，取引情報処理部１０４および取引情報記憶部１０５を含む。図２で説明したハードウェア構成を前提として、図３に示すような機能構成を実現するためのソフトウェア・プログラムが、市場取引管理プログラムとして用いられる。
　要求処理部１０１は、ユーザ端末２において動作するアプリケーションの要求に応じて様々な処理を行い要求に応答する。業者情報処理部１０２は、要求処理部１０１の制御に従って業者情報記憶部１０３への情報の登録や情報の検索、抽出等の処理を行う。業者情報記憶部１０３は、本システムのユーザである業者企業の情報やその担当者の情報を記憶している。
　取引情報処理部１０４は、要求処理部１０１の制御に従って取引情報記憶部１０５への情報の登録や情報の検索、抽出等の処理を行う。取引情報記憶部１０５は、本システムのユーザによって行われる取引の内容や取引の主体に加えて、それぞれの取引の関係性を示す情報を記憶している。
　図４（ａ）、（ｂ）は、業者情報記憶部１０３が記憶している情報の１レコード分の内容を示す図であり、図４（ａ）がユーザ情報、図４（ｂ）が企業情報をそれぞれ示す。図４（ａ）に示すように本実施形態にかかるユーザ情報は"ユーザＩＤ"、"パスワード"、"担当者名"、"所属企業ＩＤ"、"連絡先"、"受領場所"の情報を含む。"ユーザＩＤ"は、本システムを利用するユーザを識別するユーザ識別子である。"パスワード"は、そのユーザが本シスステムにログインするための認証情報である。
　"担当者名"は、本システムを利用するユーザの名称を示す文字情報である。"所属企業ＩＤ"は、そのユーザが所属する企業を示す識別子であるが、個人としてシステムを利用するユーザの場合には空欄となる。"連絡先"は、住所、電話番号、メールアドレス等、本システムのユーザの連絡先である。"受領場所"は、そのユーザが市場で物を買った場合に、その物を市場内で届ける先を示す情報であり、例えばそのユーザが市場において割り当てられている荷物の集荷場所や運搬車の駐車場所である。
　また、図４（ｂ）に示すように、本実施形態に係る企業情報は、"企業ＩＤ"、"パスワード"、"企業名"、"連絡先"の情報を含む。"企業ＩＤ"は、本システムを利用するユーザを識別する識別子であり、図４（ａ）の"所属企業ＩＤ"に対応する。"パスワード"は、そのレコードの"企業ＩＤ"を用いて本システムにログインするための認証情報である。"企業名"は、そのレコードの企業の名称、屋号を示す文字情報である。"連絡先"は、住所、電話番号、メールアドレス等、その企業の連絡先の情報である。なお、企業情報もユーザ情報と同様に"受領場所"が指定されても良い。
　図５は、取引情報記憶部１０５が記憶している取引情報の１レコード分の内容を示す図である。図５に示すように、本実施形態にかかる取引情報記憶部は、"取引ＩＤ"、"買い手ＩＤ"、"売り手ＩＤ"、"担当者名"、"商品コード"、"商品名"、"規格"、"産地"、"個数"、"重量"、"単価"、"消費税率"、"取引日時"、"親取引ＩＤ"、"受領確認"、"備考"および"販売終了"の情報を含む。
　"取引ＩＤ"は、それぞれの取引情報のレコードを識別する取引識別子である。"買い手ＩＤ"は、その取引において商品を販売した側の業者を識別する買い手識別子であり、図４の"ユーザＩＤ"に対応する。"売り手ＩＤ"は、その取引において商品を購入した側の業者を識別する売り手識別子であり、図４の"ユーザＩＤ"に対応する。
　"担当者名"は、その取引において商品を購入した側の業者の担当者名である。"商品コード"は、その取引において売買された商品に付与されるコード番号であり、同種で規格の異なる魚の識別などに用いられる。"商品名"は、その取引において売買された商品の名称である。
　"規格"は、その取引において売買された商品の規格を示す情報であり、例えばイワシのような魚であれば「＊＊ｋｇ／＊＊尾」というように所定の尾数あたりの重量で示される。その他、マグロであれば、「１番」～「４番」といった部位を示す番号であり、海老であれば「１６－２０」「２１－２５」「２６－３０」といったように所定の重量あたりの尾数で示される。
　"産地"は、その取引において売買された商品の産地を示す情報である。"個数"はその取引において売買された商品の個数（尾数）を示す情報である。"重量"は、その取引において売買された商品の重量を示す情報である。"単価"は、その取引において売買された商品の所定の重量あたりの価格を示す情報である。"消費税率"は、その取引において適用される消費税の税率を示す情報である。"商品名"、"規格"、"産地"、"個数"、"重量"、"単価"等の情報が取引内容の情報として用いられる。
　"取引日時"は、その取引が行われた日時を示す情報である。"親取引ＩＤ"は、その取引において売買された商品の仕入れ取引、即ち親取引を示す親取引識別子であり、"取引ＩＤ"に対応する。"受領確認"は、その取引において売買された商品が買い手の受領場所において荷受け確認されたか否かを示すチェック情報である。"備考"は、取引において自由に入力される文字情報である。"販売終了"は、その取引によって仕入れられた商品の販売が終了したことを示すチェック情報である。
　次に、図６を参照して本実施形態にかかるユーザ端末２の機能構成について説明する。図６に示すように、本実施形態にかかるユーザ端末２においては、市場販売管理アプリ２００が動作することによって本システムに対応する機能が提供される。
　市場販売管理アプリ２００は、図２において説明したように、市場販売管理アプリ２００を構成するためのソフトウェア・プログラムがＲＡＭ２０に読み出され、ＣＰＵ１０がそれらのプログラムに従って演算を行うことにより構成される。本実施形態にかかる市場販売管理アプリ２００はウェブアプリケーションである。すなわち、ユーザ端末２にインストールされているウェブブラウザを介してユーザ端末２がサービスサーバ１にアクセスすることによりウェブサイトの情報として市場販売管理アプリ２００を構成するためのプログラムがユーザ端末２にダウンロードされ、そのプログラムに従ってユーザ端末２において市場販売管理アプリ２００が構成される。
　図６に示すように、市場販売管理アプリ２００は操作受付部２０１、表示処理部２０２および情報通信部２０３を含む。操作受付部２０１は、ユーザ端末２の操作部７０に対するユーザの操作をＩ／Ｆ５０を介して受け付ける。表示処理部２０２は、操作受付部２０１が取得したユーザの操作内容や、サービスサーバ１から取得した情報に基づいて市場販売管理アプリ２００のＧＵＩの表示を制御する。情報通信部２０３は、市場販売管理アプリ２００の動作状態に応じてサービスサーバ１との間で情報をやり取りする。
　次に、本実施形態にかかるシステムにおいて、サービスサーバ１の取引情報記憶部１０５に新たに取引情報が登録される動作について図７を参照して説明する。図７は、本システムにおいて新たに取引情報が登録される動作を示すシーケンス図である。
　図７に示すように、まずは売り手側のユーザ端末２ａがウェブブラウザの機能を介してサービスサーバ１にアクセスすることにより、市場販売管理アプリ２００のＧＵＩがＬＣＤ６０に表示される（Ｓ７０１）。Ｓ７０１においては、"ユーザＩＤ"若しくは"連絡先"の情報に含まれるメールアドレス等のユーザの識別子と、"パスワード"による認証によりログイン処理が行われる。
　そして、ユーザによる操作部７０に対する操作内容を操作受付部２０１が受け付け、それに応じて情報通信部２０３がサービスサーバ１から情報を取得し、その情報に基づいて表示処理部２０２が市場販売管理アプリ２００のＧＵＩを制御することにより、取引情報の登録画面が表示される。
　図８（ａ）、（ｂ）は、市場販売管理アプリ２００のＧＵＩのうち、売りデータを登録するための画面（以降、「売りデータ登録画面」とする）を示す図である。図８（ａ）に示すように、本システムにおける売りデータ登録画面は、図５において説明した各情報を入力するための入力欄を含む。また、本システムにおける売りデータ登録画面には、それぞれの入力欄における情報の入力を補助するための機能が含まれる。図８（ａ）、（ｂ）に示す画面が、取引情報記憶部１０５に記憶させるための情報の入力を受け付ける情報入力画面として用いられる。
　例えば、図８（ａ）において"企業"と表示されている入力欄は、取引において商品を購入する側の業者を指定する入力欄である。この入力欄は自由入力の他、表示される選択肢から選択することも可能であり、サービスサーバ１の業者情報記憶部１０３に記憶されているレコードの"企業名"が選択肢として表示される。それぞれの企業名の選択肢には、図４に示す"ユーザＩＤ"が関連付けられており、企業名が選択されると自動的にそれに関連付けられた"ユーザＩＤ"も入力対象の情報として選択される。
　また、図８（ａ）において"商品名"と表示されている入力欄は、取引において売買される商品を指定する入力欄である。この入力欄も選択式であり、売り手側が既に購入している商品の商品名が選択肢として表示される。この商品名の選択肢の表示機能について説明する。
　図８（ａ）の"商品名"の選択肢は、取引情報記憶部１０５に記憶されている取引情報の"商品名"に基づいて生成されたリストが用いられる。このリストは、図７のＳ７０１における画面情報の生成処理において生成される。図９を参照して、図７のＳ７０１における画面情報の生成処理の詳細について説明する。
　図９に示すように、まずはサービスサーバ１の要求処理部１０１が、画面表示を要求するユーザ端末２からユーザＩＤおよびパスワードを含む認証要求を受信する（Ｓ９０１）。すると業者情報処理部１０２は、受信されたユーザＩＤおよびパスワードに基づいて業者情報記憶部１０３を参照し、ユーザＩＤおよびパスワードの一致を確認して認証処理を行う（Ｓ９０２）。
　Ｓ９０２の結果、指定されたユーザＩＤが業者情報記憶部１０３に存在しない、若しくは指定されたユーザＩＤに関連付けられたパスワードが指定されたパスワードと一致しない等、認証に失敗した場合（Ｓ９０２／ＮＯ）、要求処理部１０１は認証要求を行ったユーザ端末２に対してエラーを通知して（Ｓ９０６）処理を終了する。
　他方、認証が正常に行われた場合（Ｓ９０２／ＹＥＳ）、取引情報処理部１０４は、要求処理部１０１の制御に従い、認証されたユーザＩＤが"買い手ＩＤ"であるレコードを取引情報記憶部１０５から抽出する（Ｓ９０３）。図１０は、取引情報記憶部１０５において"買い手ＩＤ"をキーとして情報を抽出する処理を概念的に示す図である。図１０の例においては、"商品コード"、"商品名"、"規格"がそれぞれ「＊＊＊、イワシ、＊＊ｋｇ／＊＊尾」、「＊＊＊、マグロ、１番」、「＊＊＊、海老、１６－２０」であるレコードが抽出されている。
　このようにレコードが抽出されると、要求処理部１０１は、抽出されたレコードのうち"取引ＩＤ"、"商品コード"、"商品名"、"産地"、"規格"の情報を抽出し、図８（ａ）に示す"商品名"の選択肢のためのリストとして生成する（Ｓ９０４）。そして、要求処理部１０１は、ユーザ端末２における市場販売管理アプリ２００のＧＵＩの情報およびＳ９０４において生成したリストの情報を、認証要求に対する応答としてユーザ端末２に送信し（Ｓ９０５）、処理を終了する。即ち、ここでは要求処理部１０１が、図８（ａ）、（ｂ）に示す画面を表示するための情報を提供する入力画面情報提供部として機能する。
　このような処理により、図８（ａ）に示す"商品名"の入力欄の選択肢の情報が生成され、ユーザ端末２において表示されたＧＵＩにおいては、ログインしたユーザが既に仕入れている商品が選択肢として表示される事となる。図１１は、図８（ａ）に示す"商品名"の入力欄の選択肢の表示態様を示す図である。図１１に示すように、図９の処理により生成されたリストが選択肢として表示される。
　図９においてはログイン処理および"商品名"の入力欄の選択肢リストの生成処理を一連の処理として説明したが、Ｓ９０２とＳ９０３との間は必ずしも連続した処理ではなく、タイムラグがあっても良い。その場合、ユーザ端末２においては、既にログイン操作が行われた状態で、売りデータ登録画面を表示するための操作が行われ、ユーザ端末２がサービスサーバ１に対して画面情報を要求する。その際にログイン済みのユーザＩＤが通知され、サービスサーバ１においてＳ９０３以降の処理が実行される。
　このような機能により、商品を売るユーザは、既に仕入れている商品の中から販売対象の商品を容易に選択して入力することができる。尚、図１０に示すように、選択肢リストの生成に際しては、"取引ＩＤ"の情報も抽出され、リストの情報として含まれているが、図１１に示すようにユーザに提示する情報には含まれない。
　このような選択肢に対してユーザが選択操作を行うと操作受付部２０１がその操作内容を受け付け、表示処理部２０２の処理により、選択された情報が図８（ａ）に示す"商品名"、"産地"、"規格"に自動的に入力される。なお、図８（ａ）および図１１の例においては、"商品名"、"産地"、"規格"の情報を"商品名"の入力欄で一括して選択する態様を例として説明したが、それぞれの入力欄で個別に選択する態様も可能であり、上記と同様の処理により選択肢を生成する事ができる。
　図８（ａ）の画面の説明に戻る。図８（ａ）に示すように、売りデータ登録画面には「単位」を「追加」若しくは「削除」するためのボタンが表示されている。「追加」と表示されたボタンをタップやクリック等で操作すると、図８（ｂ）に示すように"個数"および"重量"の入力欄が追加され、複数の"個数"および"重量"を入力することが可能となる。
　この単位の追加機能は卸売市場の現場における実情に即したものである。例えば、「イワシ」、「サンマ」等の商品が箱詰めにされて箱単位で売られている場合において、それぞれの箱の重量が異なる場合がある。そのような場合において複数の箱を一度に取引する場合に、図８（ａ）の画面では複数の箱の重量を計算して入力する必要があるが、図８（ｂ）の画面とすることにより、複数の箱の情報をそれぞれ個別に入力することができる。
　図７のシステムの動作の説明に戻る。このようにして図８（ａ）に示す画面で情報が入力され、「起票」ボタンに対してタップ、クリック等の操作が行われると、情報通信部２０３がサービスサーバ１に対して取引情報の登録要求と供に画面上で入力された情報を送信する（Ｓ７０２）。なお、図８（ａ）、（ｂ）に示す売りデータ登録画面における入力項目は一例であり、"備考"等、図８（ａ）、（ｂ）に示す以外の入力欄を設けても良い。
　Ｓ７０２において送信される情報には、上述した通り図８（ａ）に示す画面において入力された情報が含まれるが、"商品名"の欄の選択により含まれる情報は図１１に示す"商品コード"、"商品名"の他、図１０に示すように"取引ＩＤ"の情報も含まれる。また、Ｓ７０１のログイン処理において認証されたユーザＩＤ、すなわちログイン済ユーザＩＤも含まれる。
　取引情報の登録要求を受けたサービスサーバ１においては、要求処理部１０１が情報を受信し、取引情報処理部１０４が要求処理部１０１の制御に従って取引情報記憶部１０５に情報を登録し、要求処理部１０１がユーザ端末２に対して応答処理を行う（Ｓ７０３）。Ｓ７０３の情報登録処理においては、図８（ａ）に示す画面において入力されたそれぞれの情報の他、ログイン認証されたユーザＩＤが"売り手ＩＤ"として登録される。即ち、ここでは取引情報処理部１０４が、取引情報記憶処理部として機能する。
　また、企業の選択肢において選択された企業名に関連付けられたユーザＩＤが、"買い手ＩＤ"として登録される。更に、商品名の選択において選択されたリストに含まれる取引ＩＤが、"親取引ＩＤ"として登録される。そして、情報登録が要求された時の日時が"取引日時"として登録される。図１２は、Ｓ７０３の処理において新たに登録されるレコードと、親取引に該当するレコードとの関係を示す図である。
　図１２に示すように、親取引のレコードにおける"取引ＩＤ"が、新規に登録されるレコードの"親取引ＩＤ"として登録される。また、親取引のレコードにおける"買い手ＩＤ"は、新規に登録されるレコードの"売り手ＩＤ"と共通する。その他、"商品コード"、"商品名"、"産地"も同一となる。"規格"も基本的には同一となるが、仕入れたものを切り分けて販売する場合等、仕入れ時と販売時で規格の情報が異なる場合もある。
　なお、図８（ｂ）において説明したように、一度の売りデータの登録において複数の"個数"、"重量"を登録した場合、それぞれの情報は図１３に示すように個別のレコードとして登録されるが、"取引ＩＤ"には同一のＩＤが付される。この同一の取引ＩＤが付される理由については後述する。
　Ｓ７０３においてユーザ端末２に送信される応答の情報には、取引情報記憶部１０５に情報が登録された後に、そのユーザＩＤが"売り手ＩＤ"であり、かつ"取引日時"のうち日付の情報が当日であるレコードを抽出した結果のリストが含まれる。その結果、応答を受信したユーザ端末２においては、情報登録が完了された事を示す処理結果の画面として、当日に登録された売りデータの一覧を示す画面が表示される（Ｓ７０４）。
　図１４は、Ｓ７０４の処理において表示される売りデータの一覧画面の例を示す図である。図１４に示すように、売りデータの一覧画面においては、それぞれのレコードに含まれる情報のうち、"商品"、"産地"、"個数"、"重量"、"単価"、"場所"、"配送状況"の情報が、それぞれの買い手ＩＤに対応する企業名ごとにまとめて表示される。なお、"場所"の情報は、図４において説明した"受領場所"の情報である。
　このような処理により本システムにおける新規データの登録処理が完了する。これにより、商品を買った側、仕入れた側のユーザは、システムにアクセスして買いデータの一覧画面を表示することにより、取引の結果を確認することができる（Ｓ７０５）。図１５は、Ｓ７０５において表示される買いデータ一覧画面の例を示す図である。
　ユーザ端末２からサービスサーバ１に対して買いデータ一覧画面の表示が要求されると、サービスサーバ１は、取引情報記憶部１０５に記憶されたデータのうち、要求と供に通知されたユーザＩＤが"買い手ＩＤ"であり、かつ"取引日時"のうち日付の情報が当日であるレコードを抽出したリストをユーザ端末２に送信する。その結果、サービスサーバ１からリストを受信したユーザ端末２においては、当日に登録された買いデータの一覧を示す画面が図１４のように表示される。
　図１４、図１５に示す買いデータ一覧表示画面において、"配送状況"の項目はユーザによってチェックを追加することが可能なＧＵＩとなっている。例えば、実際の市場において仕入れを行う側のユーザは、様々な場所、店舗で必要な商品を購入する。そして、定められた集荷場所にそれぞれの店舗から商品を届けてもらって車などに積み込む。その際、図１４、図１５に示す買いデータ一覧表示画面において"配送状況"の項目を確認することで、販売した商品をすべて届け終えたか、購入した商品がすべて届いているかを確認することができる。
　ユーザが図１５に示すような画面において"配送状況"の欄にチェックを付けるための操作を行うと、ユーザ端末２からサービスサーバ１に対して、"配送状況"にチェックが付されたことを示す識別子とともに、対象となるレコードを示す"取引ＩＤ"が通知される。その通知を受けたサービスサーバ１においては、要求処理部１０１から取引情報処理部１０４に情報が受け渡され、取引情報処理部１０４が、通知された"取引ＩＤ"のレコードを抽出して"配送状況"のチェック情報を更新する。
　なお、"配送状況"の項目については、商品を売った側が図１４において説明した売りデータ一覧表示画面において操作してチェックを付ける態様でも良いし、商品を売った側、買った側の双方がチェックを付ける態様でも良い。これにより、売った側が商品を届けたか否か、買った側が商品を受領したか否かをそれぞれ確認することが可能となる。
　なお、図１４、図１５において"配送状況"の項目はチェックデータとして示されているが、上記の通り買い手、売り手の双方がチェックを付けるデータとする場合、例えば２桁の２進数のデータとし、買い手がチェックした状態を「１０」、売り手がチェックした状態を「０１」、双方がチェックした状態を「１１」とすることにより一項目として実現可能である。
　このように、本システムにおいては市場において成立した取引がすべて記憶されていくこととなる。その中で特徴となるのが"親取引ＩＤ"の存在である。生産者や漁業者から大卸業者へ、大卸業者から仲買業者へ、仲買業者から飲食店や小売店へと点々と取引されて流通していく仕組みのなかで、それぞれの取引の上流側の取引が記録されていることにより様々な機能を実現することが可能となる。
　図１６は、本システムにおいて"親取引ＩＤ"を利用して可能となる画面のうち、取引一覧画面の例を示す図である。本システムにおける取引一覧画面においては、それぞれのユーザが仕入れた商品について仕入れ量と販売量とが比較して表示される。即ち、図１６に示す取引一覧画面が、取引量表示画面として用いられる。このような取引一覧表示画面を確認することにより、それぞれのユーザは仕入れた商品の売り漏れや、在庫以上の取引を誤って締結してしまうことを防ぐことができる。
　図１７は、ユーザ端末２から取引一覧表示画面の要求を受けたサービスサーバ１の動作を示すフローチャートである。図１７に示す動作の前提として、要求元であるユーザのユーザ端末２からサービスサーバ１に対して、取引一覧表示画面の表示要求とともにユーザＩＤが通知される。
　取引一覧表示画面の表示要求およびユーザＩＤの通知を受けたサービスサーバ１においては、要求処理部１０１から取引情報処理部１０４に情報が受け渡され、取引情報処理部１０４が、通知された"ユーザＩＤ"に基づいて取引情報記憶部１０５から情報を抽出する（Ｓ１７０１）。
　Ｓ１７０１の処理において取引情報処理部１０４は、取引情報記憶部１０５が記憶しているデータのうち"買い手ＩＤ"が通知された"ユーザＩＤ"であり、且つ"取引日時"が当日であるデータを抽出する。Ｓ１７０１において抽出されるデータが、そのユーザがその日に商品を仕入れた取引のデータ、すなわち仕入れ取引データであり、Ｓ１７０１の処理が商品の仕入れ量を抽出する処理である。
　このようにして情報を抽出すると、取引情報処理部１０４は、抽出されたデータそれぞれを順番に選択し、図１５に示すような比較画面を生成するための処理（以降、「比較情報生成処理」とする）を繰り返し行う。そのため取引情報処理部１０４は、繰り返しを判断するための処理として、抽出されたデータのうち、比較情報生成処理の対象としてまだ選択していないデータが残っているか確認する（Ｓ１７０２）。
　未選択のデータがまだある場合（Ｓ１７０２／ＹＥＳ）、取引情報処理部１０４は、未選択データの１つを選択し、その"取引ＩＤ"を参照する（Ｓ１７０３）。そして、取引情報処理部１０４は、取引情報記憶部１０５が記憶しているデータのうち"親取引ＩＤ"がＳ１７０３において参照した"取引ＩＤ"であるレコードを抽出する（Ｓ１７０４）。Ｓ１７０４において抽出されるデータが、Ｓ１７０３において参照された"取引ＩＤ"が示す取引において仕入れられた商品を販売したデータ、すなわち販売取引データであり、Ｓ１７０４の処理が商品の販売量を抽出する処理である。
　選択中の仕入れ取引に対する販売取引データを抽出した取引情報処理部１０４は、抽出した販売取引データの"重量"、"単価"を参照し、"重量"の集計および"重量"に"単価"を乗じた販売額の集計を行う（Ｓ１７０５）。これにより、選択中の仕入れ商品を販売した合計量および合計の販売額が算出される。
　なお、図８（ｂ）および図１３において説明した態様により、Ｓ１７０３において参照した「取引ＩＤ」が付与されたレコードが複数ある場合、Ｓ１７０５において取引情報処理部１０４は、その複数のレコードの"重量"の集計および"重量"に"単価"を乗じた販売額の集計を行う。この集計結果が"買い額（円）"および"買い量（ｋｇ）"となる。
　そして取引情報処理部１０４は、選択中の仕入れ商品について図１５に示すように取引一覧表示画面に表示させる情報、すなわち"商品名""産地""買い額（円）""買い量（ｋｇ）""売り額（円）""売り量（ｋｇ）""販売終了"の情報を抽出して記憶する（Ｓ１７０６）。
　取引情報処理部１０４は、Ｓ１７０１の処理により抽出されたレコードがなくなるまでＳ１７０３～Ｓ１７０６の処理を繰り返し（Ｓ１７０２／ＹＥＳ）、未選択のレコードがなくなると（Ｓ１７０２／ＮＯ）、Ｓ１７０６の処理により記憶された情報に基づいて図１６に示す取引一覧表示画面を表示するための画面情報を生成して、要求元のユーザ端末２に対して送信し（Ｓ１７０７）、処理を終了する。このように、取引情報処理部１０４が、取引量表示画面生成部として機能する。
　このような処理により、本システムによる取引一覧表示画面の画面情報の生成処理が完了し、図１６に示すような画面がユーザ端末２において表示される。図１６に示すような表示により、仕入れ量と販売量とを客観的に確認することが可能となる。なお、"販売終了"の項目はユーザによってチェックを追加することが可能なＧＵＩとなっている。このユーザが仕入れた商品をすべて販売し終えたと判断した場合にこの"販売終了"のチェックを更新することにより、図９において説明した商品名リストの生成処理においてリストから除外することができる。
　上述した通りユーザ端末２において"販売終了"のチェックが操作されると、ユーザ端末２からサービスサーバ１に対して、"販売終了"のチェック状態を更新する旨の要求が対象レコードの"取引ＩＤ"（Ｓ１７０３において選択した取引ＩＤ）と供に通知される。この通知を受けたサービスサーバ１においては、取引情報処理部１０４が、通知された"取引ＩＤ"に基づいて取引情報記憶部１０５からレコードを抽出し、抽出したレコードの"販売終了"のチェックを更新する。
　次に、本システムの機能のうち卸売市場における特殊な取引形態に対応した機能について説明する。一般的な商品取引においては、買い手側が仕入れ対象の商品を選択して購入意思を売り手に伝え、売り手が販売に同意することで取引が成立する。これに対して卸売市場においては、取引の上流側から下流側に対して、特定の商品の販売を依頼する場合がある。そのような場合に対応した機能（以降、「販売依頼機能」とする）について説明する。
　上述したような販売依頼機能による取引においても、商品を売る側の業者が図８（ａ）、（ｂ）に示すような画面において販売対象の商品の情報を入力することは同一である。ただし、入力すべき情報のうち"単価"の情報は空欄で入力される。その結果、買いデータ一覧表示画面においては、図１７に示すように"単価"が未定として表示されると供に、図中に斜線を付して示しているように、その取引が売り手側からの販売依頼による取引であることが客観的にわかるように強調表示される。
　そのような販売依頼取引の商品について、販売を依頼されて仕入れを行った下流側の業者が取引を行うことにより、他の通常の商品と同様に図１６において説明した取引一覧表示画面に表示される。図１９は、販売依頼取引の商品が表示される場合の取引一覧表示画面の例を示す図である。図１９に示すように、販売依頼取引の商品が含まれる取引一覧表示画面において、販売依頼取引の商品は図１８と同様に強調表示される。
　図１８、図１９に示すような強調表示は、ユーザ端末２の要求に応じてサービスサーバ１において取引情報処理部１０４が表示情報を生成する取引情報処理部１０４によって実現される。取引情報処理部１０４は買いデータ一覧表示画面や取引一覧表示画面の表示情報を生成する際、販売依頼取引に係るレコード、すなわち買い額が空欄状態のレコードについては、そのレコードが強調表示されるように表示情報を生成する。そのような表示は、例えば画面を構成するウェブソースのスタイルシートの設定により実現することが可能である。
　このような販売依頼取引については、買い側の業者と売り側の業者とが空欄となっている販売額（レコード上の"単価"）を話し合い、事後的に情報を入力することにより未定状態の取引を完了させる必要がある。図１８や図１９に示す画面で強調表示された販売依頼取引のレコードをタップやクリックなどで操作することにより、図２０に示すような買い額を事後的に指定するための画面（以降、「買い額事後指定画面」とする）が表示される。
　図２０に示すように、買い額時事後指定画面においては、"企業""商品""産地""買い量"等の対象の取引を示す情報と供に、"単価""合計金額""消費税率""税込金額"の入力欄が表示される。ユーザが図２０に示す画面において情報を入力した上で「決定」ボタンを操作することによりユーザ端末２の市場販売管理アプリ２００における操作受付部２０１が操作を認識し、情報通信部２０３がサービスサーバ１に対して情報の登録要求と供に入力された情報を送信する。
　情報の登録要求を受けたサービスサーバ１においては、要求処理部１０１が要求を受け付け、要求に含まれる情報に基づいて取引情報処理部１０４が取引情報記憶部１０５に記憶されている対象のレコードを更新する。このような処理により、販売依頼取引が完了する。
　以上説明したように、本実施形態に係るシステムにおいては、上流側から下流側に複数の業者間を商品が転々と流通していく市場取引において、それぞれの取引を１つのレコードとして記録すると供に、それぞれのレコードにおいて取引対象となる商品の１つ上流側の取引、すなわちその商品の仕入れに係る取引を示す情報である「親取引ＩＤ」が記録される。
　これにより市場においてシステム上に取引が記録される商品の流通過程を把握することが可能となり、それを利用することにより、図９～図１１において説明した商品リストの機能や、図１６において説明した取引一覧表示画面の機能等、現場の助けとなる機能を実現することが可能となる。
　このように"親取引ＩＤ"を介して商品の流通過程を把握する機能に鑑みて、上述した図８（ｂ）に示す画面において複数の個口で入力されてそれぞれ別のレコードとして取引情報に記録されるレコードには同一の取引ＩＤ"が指定される。仮に別々の"取引ＩＤ"を付与した場合、その商品を販売する際には、図１４に示す画面の集計のために、販売する商品がどの個口のものかを把握し、正しい"取引ＩＤ"を付与するように操作する必要がある。
　しかしながら、同一の"商品""産地""規格"の場合、後から見分けることは困難であるし、市場の現場において意識的に"取引ＩＤ"を理解して管理することも現実的ではない。従って、同一の"商品""産地""規格"の商品を複数個口仕入れた場合には、それらに同一の"取引ＩＤ"が付与されるように処理することで、図１４に示す画面の集計に際しては一括して集計され、データ上の不整合や混乱を防ぐことができる。
　尚、本システムの機能としては、上述した特徴的な機能の他、請求書や納品書の発行機能が含まれる。そのような機能は、図５に示すように本システムにおいて記憶される情報に基づいて実現可能である。例えば取引を月ごとに集計して請求書を発行する場合であれば、"買い手ＩＤ"が請求先の企業に一致し、且つ"取引日時"の年月が請求対象の月に一致するレコードを抽出することにより容易に請求書を生成することが可能である。
　そのような請求書の生成については、ユーザ端末２においてユーザがＧＵＩを操作して請求先の企業や年月を指定して請求書の生成操作を行うと、ユーザ端末２において操作受付部２０１が操作内容を受け付け、情報通信部２０３がサービスサーバ１に請求書の生成要求を送信する。ユーザ端末２からの要求を受けたサービスサーバ１においては要求処理部１０１が要求を受け付けて取引情報処理部１０４に情報を受け渡す。
　要求処理部１０１から情報を渡された取引情報処理部１０４は、指定された情報に基づいて取引情報記憶部１０５に記憶されている情報を抽出し、集計やリスト化を行って請求書を表示するための表示情報を生成する。取引情報処理部１０４によって請求書の表示情報が生成されると、要求処理部１０１がその情報を要求元のユーザ端末２に送信する。これにより、ユーザ端末２において請求書が表示され、買い手ＩＤに基づいた請求先企業への送信や、プリントアウトによる紙としての出力が可能となる。
　また、本システムの動作においては、図９のＳ９０３や、図１７のＳ１７０１など、ユーザＩＤをキーとしてレコードを抽出する処理がある。これは、本システムを利用するためにログインしているユーザの取引情報のみが参照されることを示している。他方、本システムを利用するためのログインについては、ユーザＩＤによるログインの他、図４（ｂ）に示す企業ＩＤでのログインもある。
　そのような場合、それぞれの処理においては、その企業に所属しているすべてのユーザのユーザＩＤを対象としてレコードが抽出される。例えば、図１７のＳ１７０１においては、"買い手ＩＤ"がログイン中の"企業ＩＤ"であるレコードに加えて、図４（ａ）において説明したユーザ情報のうち"所属企業ＩＤ"がログイン中の"企業ＩＤ"に一致するレコードの"ユーザＩＤ"をすべて取得し、取得した全ての"ユーザＩＤ"が"買い手ＩＤ"に一致するレコードをも抽出する。これにより、企業ＩＤでログインしたユーザは、その企業に所属するすべてのユーザの取引を把握することが可能となる。このような企業ＩＤでのログインによる所属ユーザの取引情報を参照する機能は、以降の実施形態に置いても同様である。
実施の形態２．
　本実施形態においては、図１６において説明した取引一覧表示画面について、更に現場の実情を考慮して実装される機能について説明する。実施の形態１においては、図１６に示すように、買い量（ｋｇ）と売り量（ｋｇ）とを比較表示することが可能な例について説明した。仕入れたものを小分けに売っていく以上、売る際にユーザが正確に重量を図って売り、且つその重量を正確にシステムに入力していけば、仕入れたものを売り切った際に取引一覧表示画面に表示される"買い量（ｋｇ）"と"売り量（ｋｇ）"とは一致するはずである。
　しかしながら、現場において実際に売った量とシステムに入力した"売り量（ｋｇ）"とに微差があり、その微差が積み重なることによって最終的な集計におけるずれが大きくなることがあり得る。また、取引の現場においては、重量で仕入れたものを尾数、匹数で売る場合や、大型の魚を仕入れて切り分けた上で売り物になる部分のみを売る場合等、買う際の単位と売る際の単位とが異なり、"買い量"と"売り量"とを単純に比較することができない場合もあり得る。
　このように、"買い量"と"売り量"とを単純に比較することができないという事情の中で、トータルとしてあり得る程度の微差を横流しする等の巧妙な不正が現場で行われる場合がある。本実施形態においては、そのような問題に対応するシステムの機能について説明する。
　図２１は、本実施形態に係る取引一覧表示画面の例を示す図である。実施の形態１においては、図１６に示すように、買い量（ｋｇ）と売り量（ｋｇ）とを比較表示する態様を説明したが、本実施形態に係る取引一覧表示画面においては、図２１に示すように"売り量"の表示単位がそれぞれの商品の販売形態に応じた形式となっていると供に、それぞれの商品について、その取引において算出された歩留まり率と、その商品全体の歩留まり率の平均値を比較表示する"歩留率／平均"の項目が表示される。図２１に示す画面を表示するための情報は、図１６と同様に取引情報処理部１０４によって生成される。即ち、取引情報処理部１０４が歩留まり率算出部として機能する。
　図２１の例においては、例えば「海老」の場合、"売り量"としては実際に販売されたデータの"個数"が集計されて「３９（尾）」として表示されており、それに合わせて"買い量"としては"規格"の情報と"重量"の情報とから算出された想定の仕入れ尾数が「４０（尾）」として表示されている。そして、その数値から算出された歩留まり率が計算され、平均の歩留まり率と供に「９８（％）／１００（％）」として表示されている。
　このような「海老」の表示は、実際の取引の現場における販売単位が（円／尾）であった結果である。そのような場合、図１７のＳ１７０４において抽出されたレコードの"重量"がすべて空欄であり、"個数"にのみ数値が入力されている状態となる。そのため、比較表示する"買い量"としても"個数"であることが求められるため、図５において説明した"個数"のデータが選択される。
　ただし、商品によっては仕入れの際に"個数"が記録されない場合もありうる。例えば図５において説明したように、海老は仕入れ取引において重量で取引され、"規格"として所定重量あたりの尾数が記憶される。そのため図２１の例においては、"規格"の情報と"重量"の情報とから算出された想定の仕入れ尾数が「４０（尾）」として表示されている。
　また、「イワシ」の場合、"売り量"は「６（ｋｇ）＋３８（尾）」として"重量"と"個数"が集計されて表示されている。これは、実際の取引の現場において（円／尾）での販売と（円／ｋｇ）での販売とが混在する場合である。そのような場合、図１７のＳ１７０４において抽出されたレコードに"重量"が空欄であるものとそうでないものとが混在する。その場合、比較表示する"買い量"としては、"個数""重量"の両方が選択され、"個数"が空欄である場合に"規格"と"重量"から想定個数が算出されることも同様である。
　図２２は、図２１に示すようなそれぞれの商品ごとの表示形式のルールを示す図である。図２２に示すルールは取引情報処理部１０４が記憶している。このようなそれぞれの商品ごとの表示の選択は、図１７において説明した処理のうちＳ１７０５において実行される。Ｓ１７０４において販売データを抽出した取引情報処理部１０４は、図２２に示すルールに従って取引一覧表示画面の"買い量""売り量"の表示形式を選択する。
　また、本実施形態に係る取引情報処理部１０４はＳ１７０５において歩留率を計算する。図２１に示す「海老」や「マグロ」のような商品の場合には、"売り量"を"買い量"で割ることにより単純に算出される。他方、図２１に示す「イワシ」のように、"個数"と"重量"とが混在した商品の場合、取引情報処理部１０４はそれぞれの歩留まり率を算出して合算する。
　なお、本実施形態に係る取引情報記憶部１０５は、各商品および規格ごとに平均歩留まり率の情報（以降、「平均歩留まり率情報」とする）を記憶している。図２３は、本実施形態に係る平均歩留まり率情報の例を示す図である。図２３に示すように本実施形態に係る平均歩留まり率情報は、"商品"、"規格"、"平均歩留まり率"、"サンプル数"の情報を含む。即ち、ここでは取引情報記憶部１０５が平均歩留まり率記憶部として機能する。
　図２３に示す情報のうち、"平均歩留まり率"は、それまでにシステムにおいて算出された歩留まり率の平均値を示す情報である。これにより、本システムを介して取引される商品の歩留まり率の平均値が把握される。また、"サンプル数"は、その時点での"平均歩留まり率"の算出に用いられたデータ数を示す値である。
　本実施形態に係る取引情報処理部１０４はＳ１７０５において、処理中のレコード、即ちＳ１７０３において選択したレコードの"商品"および"規格"に一致するレコードを平均歩留まり率情報から抽出し、"平均歩留まり率"を取得する。そして、Ｓ１７０６において図２１に示すような内容を表示するための情報を記憶する。このような処理により、図２１に示すような取引一覧表示画面を表示するための画面情報が生成される。
　また、実施の形態１において説明したように、それぞれの商品をすべて販売し終えたユーザは、図２１に示す画面において"販売終了"のチェックを操作する。すると、実施の形態１において説明した取引情報記憶部１０５の"販売終了"の更新と供に、歩留まり率情報の更新が行われる。
　そのため、ユーザ端末２において"販売終了"のチェックが操作されると、ユーザ端末２からサービスサーバ１に対して、上述した情報と供に、Ｓ１７０５において算出された歩留まり率が通知される。この通知を受けたサービスサーバ１においては、取引情報処理部１０４は、上述した"販売終了"のチェック更新処理に加えて、歩留まり率情報の更新処理を行う。
　歩留まり率情報の更新処理において、取引情報処理部１０４は、まず通知された"取引ＩＤ"のレコードを取引情報記憶部１０５から抽出し、通知された歩留まり率を関連付けて記憶する。そのため、本実施形態に係る取引情報記憶部１０５は、図５に示す情報に加えて、歩留まり率の情報を含む。
　また、取引情報処理部１０４は、図２３に示す平均歩留まり率情報の更新処理を行う。平均歩留まり率情報の更新処理において取引情報処理部１０４は、通知された"取引ＩＤ"のレコードから"商品"および"規格"を取得し、それぞれが一致するレコードを図２３に示す平均歩留まり率情報から抽出する。そして、抽出したレコードの"サンプル数"をｎとして、以下の式（１）を用いて更新後の歩留まり率を算出して"平均歩留まり率"を更新すると供に"サンプル数"をインクリメントする。
Figure JPOXMLDOC01-appb-M000001
　このような処理により、取引情報記憶部１０５が記憶しているそれぞれの取引情報の歩留まり率、および図２３に示す平均歩留まり率の情報が更新される。ユーザは、図２１に示すような画面により、それぞれの商品についての歩留まり率と平均歩留まり率とを比較して確認することが可能となる。
　また、本実施形態に係るシステムにおいては、上述したようにそれぞれの取引について歩留まり率が記憶されるため、歩留まり率を時系列に確認することが可能となる。図２４は、本実施形態に係る歩留まり率の時系列表示画面（以降、「歩留まり率時系列表示画面」とする）の例を示す図である。
　図２４に示すように、歩留まり率時系列表示画面においては、縦軸を歩留まり率（％）、横軸を取引日時とした折れ線グラフにより、特定の"商品"および"規格"の組み合わせに合致するレコードの"歩留まり率"が時系列に表示される。また、図２３に示すように記憶されている平均歩留まり率が破線で表示される。
　図２４に示す画面は、サービスサーバ１によって生成された画面表示情報に基づいてユーザ端末２において表示される。サービスサーバ１は、ユーザ端末２からの要求に応じて図２４に示す画面を表示するための画面表示情報を生成する。ユーザ端末２からサービスサーバ１への要求には、図２４に示す歩留まり率時系列表示画面の表示情報の生成要求であることを示す情報の他、要求者であるユーザの"ユーザＩＤ"、"商品名"、"規格"の情報が含まれる。即ち、歩留まり率時系列表示画面の表示情報の要求に際し、ユーザは少なくとも"商品名"および"規格"を指定して要求の操作を行う。
　上記要求を受け付けたサービスサーバ１においては、取引情報処理部１０４が、通知された"ユーザＩＤ"が"買い手ＩＤ"に一致し、且つ通知された"商品名"、"規格"が一致するレコードを取引情報記憶部１０５から抽出する。取引情報処理部１０４は、そのようにして抽出されたレコードの"取引日時"および"歩留まり率"を参照し、図２４に示すようなグラフを表示するための情報を生成する。
　また、取引情報処理部１０４は、通知された"商品"および"規格"に基づいて平均歩留まり率情報を参照して一致するレコードを抽出し、対応する"商品"および"規格"の"平均歩留まり率"を取得する。これにより、図２４に示す破線を表示するための情報を生成する。
　図２４に示す画面により、ユーザは自身が仕入れた商品についての"歩留まり率"を"商品"および"規格"ごとに時系列に把握することが可能となる。図２４の例の場合、タイミングｔ１辺りを境に歩留まり率が低下しているのがわかる。これは一概に現場の不正が原因であるということはできないが、このような状況の把握により現場の管理に役立てることができる。
　以上説明したように、本実施形態に係るシステムによれば、商品を仕入れる際の単位と販売する際の単位とが異なる場合であっても、取引一覧表示画面において買い量と売り量とを比較表示することが可能となる。また、商品を仕入れる際の単位と販売する際の単位とが異なる場合における商品の取引結果を歩留まり率として管理することにより、現場で不正が行われた場合にそれを把握することが可能となる。
実施の形態３
　本実施形態においては、図９～図１１において説明した売りデータ登録画面における商品リストのリアルタイムな情報反映機能や図８（ａ）、（ｂ）における取引情報の登録に関する追加機能について説明する。通常の小売りの場合には店先に陳列されている商品を販売し、売買が成立したら商品を引き渡すため、買い手に対して確実に商品が引き渡される。対して、卸売市場の取引においては、売買契約のみを先に行って商品の受け渡しを事後的に行う場合がある。そのため、取引が成立した直後は現場に商品が残っている状態であり、売買契約ごとに確実に商品を引き当てておかなければ、仕入れ量以上に商品を販売してしまう可能性がある。
　そのような弊害を回避するため、本実施形態に係るシステムにおいては、図９において説明した商品リストの生成動作において商品の過販売を防止するための処理が行われる。図２５を参照して、本実施形態に係る商品リスト生成機能の詳細に付いて説明する。図２５は、図９のＳ９０４の処理の詳細を示すフローチャートである。
　実施の形態１においては、Ｓ９０３の処理により抽出されたレコードのすべてから情報を抽出し、Ｓ９０４においてリストを生成する場合を例として説明した。本実施形態に係るシステムにおいては、Ｓ９０３の処理により抽出されたレコードのうちリストに含めるものを取捨選択する。
　取引情報処理部１０４は、Ｓ９０３において抽出したレコードを順番に参照して処理を行う。そのため、まずは抽出されたデータのうち、まだ選択していないデータが残っているか確認する（Ｓ２５０１）。未選択データのまだある場合（Ｓ２５０１／ＹＥＳ）、取引情報処理部１０４は、未選択のデータのうち１つを選択し（Ｓ２５０２）、"販売終了"がチェック済みか否かを確認する（Ｓ２５０３）。
　Ｓ２５０３の確認の結果"販売終了"がチェック済みの場合（Ｓ２５０３／ＹＥＳ）、取引情報処理部１０４は選択中のレコードをリストから除外し（Ｓ２５０４）、Ｓ２５０１の処理を繰り返す。他方"販売終了"が未チェックの場合（Ｓ２５０３／ＮＯ）、次に取引情報処理部１０４は、選択中のレコードの"取引ＩＤ"を参照し、取引情報記憶部１０５が記憶しているデータのうち"親取引ＩＤ"が一致するレコードを抽出する（Ｓ２５０５）。
　Ｓ２５０５において抽出されたレコードは、Ｓ２５０２において選択したレコードの取引によって仕入れられた商品が販売された取引を示すレコードである。取引情報処理部１０４は、抽出したレコードの"個数"や"重量"を参照して集計することにより、販売量を集計する（Ｓ２５０６）。
　Ｓ２５０６の処理は、基本的には"重量"を合計する処理であるが、実施の形態２において説明したように、販売取引においては"重量"の情報が入力されない場合がある。従って、取引情報処理部１０４はＳ２５０６において、図２２において説明したようなルールに従って販売量の集計方式を適宜選択する。
　販売量を集計した取引情報処理部１０４は、Ｓ２５０２において選択したレコードに基づいて仕入れ量を確認し、Ｓ２５０６の集計結果と比較する（Ｓ２５０７）。仕入れ量の確認に際して取引情報処理部１０４は、基本的には"重量"を参照するが、Ｓ２５０７の集計結果に応じて"個数"を参照する場合や、"規格"と"重量"から算出される想定の個数を用いる。
　Ｓ２５０７の処理の結果、仕入れ量が販売量よりも多い場合（２５０７／ＹＥＳ）、対象レコードの商品はまだ在庫がある状態であり、リストに含めても問題ないものとしてＳ２５０１の処理を繰り返す。他方、販売量が仕入れ量に達している場合（２５０７／ＮＯ）、対象レコードの商品には販売可能な在庫がない状態であるため、取引情報処理部１０４は選択中レコードをリストから除外し（Ｓ２５０４）、Ｓ２５０１の処理を繰り返す。
　このように処理が繰り返された後、未選択レコードがなくなると（Ｓ２５０１／ＮＯ）、取引情報処理部１０４は、リストから除外したレコード以外のレコード、即ちまだ在庫があると判断したレコードのみで図９のＳ９０４と同様に商品リストを生成し（Ｓ２５０８）、処理を終了する。このような処理により、仕入れた商品の販売状況に応じて図８（ａ）、（ｂ）に示す商品の選択リストがタイムリーに生成されることとなり、すでに売り切った商品が誤って取引されてしまうことを防ぐことができる。
　なお、Ｓ２５０６の集計において"重量"が空欄のデータがある場合に図２２に示すようなルールに従って適宜集計を行う場合を例としているが、仕入れ時の単位と販売時の単位とが異なり、仕入れ量と販売量とを正確に比較することが難しいレコードについては、Ｓ２５０６、Ｓ２５０７の処理を省略し、無条件でリストに含めるようにしても良い。これにより、まだわずかでも在庫が残っているにも関わらずリストから除外されてしまうような事態を回避することができるとともに、Ｓ２５０３の処理により、"販売終了"がチェックされた場合にはリストから除外することが可能となる。
　次に、図８（ａ）、（ｂ）に示す画面において「起票」が操作され、ユーザ端末２からサービスサーバ１に対して取引情報の登録が要求された場合のチェック機能について説明する。図２５において説明したＳ２５０６およびＳ２５０７の処理により、データ上で対象の商品の在庫量を算出することが可能である。即ち、Ｓ２５０６において集計したー販売量を、仕入れ量から差し引いた値である。図８（ａ）、（ｂ）に示す画面の表示情報と供に、その値（以降、「在庫量情報」とする）をユーザ端末２に通知しておくことにより、図８（ａ）、（ｂ）に示す画面において入力される"重量"や"個数"に対してチェック機能を実現する事が可能となる。
　図９においては、商品リストの情報として"取引ＩＤ"、"商品コード"、"商品名"、"産地"、"規格"の情報が含まれる場合を例として説明したが、本実施形態に係るシステムにおいてはさらに上述した"在庫量情報"が含まれる。そして図８に示す画面で"商品名"が選択されると、その商品名に関連付けられている"在庫量情報"が参照され、"重量"に入力される情報と比較される。
　その結果、"重量"に入力された値が"在庫量情報"よりも大きければ、既に登録されている取引情報から集計される在庫量を超えている旨のアラートがユーザ端末２のＧＵＩ上に表示される。これにより、在庫量以上の取引を行おうとしていないかの確認をユーザに促すことができる。このような、入力された"重量"と"在庫量情報"との比較機能や、アラートの機能は、ユーザ端末２において動作する市場販売管理アプリ２００の操作受付部および表示処理部２０２によって実現される。
　以上説明したように、本実施形態によれば、図８（ａ）、（ｂ）に示す取引情報の入力画面において、誤った入力が行われないようにユーザを補助することができる。
　実施の形態４．
　本実施形態においては、図８（ａ）、（ｂ）に示す売りデータ登録画面における"買い手"欄の入力を補助する機能について説明する。本システムにおいては、図１２等において説明したように、取引情報の記録において買い手及び売り手がＩＤによって特定されることが特徴の一つである。従って、図８（ａ）、（ｂ）に示す売りデータ登録画面における情報登録に際しては"買い手"欄により商品を買う側のユーザが正確に指定される必要がある。
　そのため、"買い手"欄の入力はユーザの自由な入力を禁止し、サービスサーバ１の業者情報記憶部１０３において図４（ａ）、（ｂ）に示すように既にユーザ情報および企業情報に登録されている情報を選択肢として、選択式とすることが好ましい。しかしながら、ユーザ情報および企業情報の登録数の増加に伴って選択肢も増加することとなる。選択肢が膨大な数になるとユーザは膨大な数の選択肢から買い手を探す必要があり不便である。
　本実施形態はそのような問題に対応するものであり、市場において取引を行っている業者それぞれの店舗に買い手が来店したことを検知し、それぞれの店舗が売り手として取引情報を起票する際の"買い手"の選択肢として、来店が検知されたユーザを優先的に表示することにより"買い手"の選択を補助するものである。
　図２６は、本実施形態に係る来店検知機能を示す図である。各店舗には買い手であるユーザの端末を検知するための構成として、店舗通信機３が設置されている。即ち、店舗通信機３が入店認識部として機能する。図２６に示すように、本実施形態に係る店舗通信機３は、Ｂｌｕｅｔｏｏｔｈ機能およびネットワーク通信機能を有する小型の情報処理端末であり、図２において説明した構成に準ずるハードウェア構成を有する。また、店舗側のユーザが使用するユーザ端末２にソフトウェアをインストールすることによってユーザ端末２を店舗通信機３として機能させることもできる。
　店舗に来店するユーザのユーザ端末２は、図２７に示すように近距離通信アンテナ９０を有する以外は既に説明した実施形態と同様の構成であり、近距離通信アンテナ９０により店舗通信機３とＢｌｕｅｔｏｏｔｈ通信を行う。店舗通信機３はユーザ端末２とのＢｌｕｅｔｏｏｔｈ機能による近距離通信によりユーザ端末２が店舗に入店したことを認識し、ネットワークＡを介してサービスサーバ１に入店情報を送信する。
　図２８（ａ）、（ｂ）は、本実施形態に係るサービスサーバ１の業者情報記憶部１０３が記憶しているユーザ情報および企業情報の例を示す図である。図２８（ａ）、（ｂ）に示すように、本実施形態に係るユーザ情報および企業情報は、図４（ａ）、（ｂ）において説明した内容に加えて、"端末識別子"の情報を含む。この"端末識別子"は、ユーザ端末２を一意に識別可能な情報であり、且つ店舗通信機３がＢｌｕｅｔｏｏｔｈ通信を介してユーザ端末２から取得可能な情報であって、典型的にはＭＡＣ（Ｍｅｄｉａ　Ａｃｃｅｓｓ　Ｃｏｎｔｒｏｌ）アドレスが用いられる。
　本システムを利用するユーザが最初にシステムにサインアップする際、ユーザはウェブブラウザを介して図４（ａ）、（ｂ）に示すような情報をフォームに入力および送信することにより、サービスサーバ１において業者情報処理部１０２が業者情報記憶部１０３にその情報を登録するが、その情報のやり取りの過程でユーザが使用している端末のＭＡＣアドレスを取得することにより、図２８に示すように"端末識別子"が登録される。
　また、業者情報処理部１０２は、ユーザが本システムにログインを行うたびにその過程でユーザが使用している端末のＭＡＣアドレスを取得し、ログインしたユーザＩＤに関連付けられている"端末識別子"と比較する。その結果、両者が異なるものであれば、業者情報処理部１０２は、取得したＭＡＣアドレスを"端末識別子"として追加でログインしたユーザのユーザ情報または企業情報に関連付けて記憶させる。これにより、ユーザが複数の端末を使い分ける場合であっても、"端末識別子"に基づいてそのユーザを識別することが可能となる。
　また、１つの端末を複数のユーザが使う場合もあり得る。そのような場合、上述したようにログイン処理に際してログインされたユーザＩＤとログインに用いられた端末のＭＡＣアドレスとを関連付けることにより、異なる複数のユーザＩＤに対して同一の"端末識別子"が関連付けられる。
　図２９（ａ）、（ｂ）は、本実施形態に係る入店情報の例を示す図であり、図２９（ａ）は、店舗通信機３がサービスサーバ１に送信する情報、図２９（ｂ）は、サービスサーバ１において業者情報記憶部１０３が記憶している入店情報テーブルの１レコード分の内容を示す図である。即ち、ここでは業者情報記憶部１０３が入店管理情報記憶部として機能する。図２９（ａ）、（ｂ）に示す情報の処理について、図３０を参照して説明する。図３０は、本実施形態に係る入店検知処理を示すシーケンス図である。
　本システムが導入された市場において買い回るユーザは図２７において説明した機能を有するユーザ端末２を携帯し、且つ図２８（ａ）、（ｂ）において説明したように、そのユーザ端末２のＭＡＣアドレスが"端末識別子"としてサービスサーバ１の業者情報記憶部１０３に登録されている。市場に含まれるそれぞれの店舗に設置された店舗通信機３は常時Ｂｌｕｅｔｏｏｔｈ機能により端末の検知を行っており、ユーザ端末２が通信範囲内に入ると、Ｂｌｕｅｔｏｏｔｈ機能を介してユーザ端末２を検知すると供に、そのユーザ端末２のＭＡＣアドレスを端末識別子として取得する（Ｓ３００１）。
　なお、Ｂｌｕｅｔｏｏｔｈ機能の仕様によっては、Ｓ３００１の処理のために予め店舗通信機３とユーザ端末２との間でペアリングが必要となる場合がある。その場合、それぞれのユーザは頻繁に利用する店舗において店舗通信機３と自身のユーザ端末２とで予めペアリングしておくことにより、次回以降は特にペアリング操作を行うことなく、そのユーザ端末２を携帯して店舗を訪れるだけで自動的にＳ３００１の処理が実行される。
　ユーザ端末２から端末識別子を取得した店舗通信機３は、予め設定されているその店舗のユーザＩＤ若しくは企業ＩＤを"入店先ＩＤ"とし、取得した端末識別子を"入店者識別子"として、現在時刻と供にサービスサーバ１に送信する（Ｓ３００２）。この"入店先ＩＤ"が店舗識別子として用いられる。これにより図２９（ａ）の情報がサービスサーバ１に送信される。
　図２９（ａ）に示す情報を受信したサービスサーバ１においては、業者情報処理部１０２が、受信した"入店者識別子"に基づいて業者情報記憶部１０３に記憶されているユーザ情報および企業情報の"端末識別子"を検索する。そして、検索の結果抽出されたユーザ情報のユーザＩＤまたは企業情報の企業ＩＤを"入店者ＩＤ"として取得し、Ｓ３００２において受信した"入店先ＩＤ"および"入店日時"と供に入店情報テーブルとして業者情報記憶部１０３に記憶させる（Ｓ３００３）。これにより、図２９（ｂ）に示す情報がサービスサーバ１において記録される。
　図２９（ｂ）に示す情報により、誰が（"入店者ＩＤ"）、どこに（"入店先ＩＤ"）、いつ（"入店日時"）入店したかが明らかになる。このような情に基づいて、図８（ａ）、（ｂ）に示す売りデータ登録画面における情報登録に際して、「買い手」欄の選択肢リストを調整することが本実施形態に係る要旨である。
　そのため、本実施形態に係る業者情報処理部１０２は、図８（ａ）、（ｂ）に示す売りデータ登録画面が売り手側のユーザ端末２から要求された際に、売り手のユーザＩＤおよび入店情報テーブルに基づいて「買い手」欄の選択肢リストを生成する。図３１は、その処理を示すフローチャートである。
　実施の形態１の図９において説明したように、「売りデータ登録画面」の表示に際してはログイン処理が伴う。図３１においては既にログイン処理が行われた状態でユーザ端末２からサービスサーバ１に対して「売りデータ登録画面」の画面情報が要求された場合を示す。サービスサーバ１において要求処理部１０１が「売りデータ登録画面」の画面情報の要求をユーザ端末２から受信すると（Ｓ３１０１）、業者情報処理部１０２が、業者情報記憶部１０３に対して、「買い手」欄の選択肢リストを生成するためのクエリを実行する（Ｓ３１０２）。
　Ｓ３１０２において実行されるクエリは、まずユーザ情報から"ユーザＩＤ"および"担当者名"を抽出し、企業情報から"企業ＩＤ"および"企業名"を抽出し、"ユーザＩＤ"と"企業ＩＤ"、"担当者名"と"企業名"を連結して"ユーザ名／企業名"、"ユーザＩＤ／企業ＩＤ"を内容とするテーブル（以降、「ユーザ／企業連結テーブル」とする）を生成する。
　それとは別に、要求に際して通知されたユーザＩＤに基づき、入店情報テーブルの"入店先ＩＤ"を検索する。これにより、"入店先ＩＤ"が「売りデータ登録画面」要求元の店舗であるレコードが抽出される。そのようにして抽出されたレコードの"入店者ＩＤ"が"ユーザＩＤ／企業ＩＤ"に一致するユーザ／企業連結テーブルのレコードに対して、その"入店者ＩＤ"に関連付けられている"入店日時"を関連付ける。これにより、図３２に示すようなテーブル構成となる。
　そして、"入店日時"を対象として、図３２に示すように空欄は後回しとなるように降順で並び替える。これにより、「売りデータ登録画面」の要求元の店舗に新しく入店した順にユーザ／企業が並び替えられ、入店情報がないユーザ／企業は後回しとなる。業者情報処理部１０２は、このようなクエリの実行結果を「買い手」欄の選択肢リストとして生成し（Ｓ３１０３）、処理を終了する。なお、図３１に示す動作は「売りデータ登録画面」の画面情報の要求に際して実行される処理であり、「売りデータ登録画面」の画面情報の生成に際しては、実施の形態１において説明したように図９の処理も実行される。
　このようにして生成されたリストが選択肢として用いられることにより、図３３に示すように、「売りデータ登録画面」の「買い手」の選択肢は、対象の店舗に対して新しく入店した順に並び替えられて表示されることとなる。そのため、取引情報を登録する売り手側のユーザは、膨大な登録済みのユーザ／企業の中から対象の買い手を探すことなく、優先的に表示された入店中の買い手を簡単に選択することが可能となる。
　なお、上記実施形態においては、入店を検知するための仕組みとしてＢｌｕｅｔｏｏｔｈ機能を用いる場合を例として説明した。これは、一般的なスマートフォン等の携帯端末であれば当然に実装されている機能であり、容易に実現および普及させることができる点で有効であるが、これに限らず、例えばＮＦＣ（Ｎｅａｒ　Ｆｉｅｌｄ　Ｃｏｍｍｕｎｉｃａｔｉｏｎ）機能を用いても良い。これはＢｌｕｅｔｏｏｔｈ機能がＮＦＣ機能に置き換わるのみで、仕組みとして上記と大きな違いはなく実現可能である。
　その他、買い手であるユーザが市場の店舗に入店したことが検知され、その検知に応じて図２９（ｂ）に示すような情報がサービスサーバ１に記録される態様であれば、上記と同様の効果を得ることが可能である。例えば、端末に設けられたカメラでバーコードやＱＲコード（登録商標）等の画像コードを読み取る態様を用いることができる。
　この場合、それぞれの店舗にはその店舗のＩＤおよび入店通知のためのウェブアクセスを提供するＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）が符号化された画像コードが印刷されたステッカーや看板等が提示されている。店舗を訪れたユーザは自身のユーザ端末２に搭載されたカメラでそのコードを読み取ることにより、符号化されたＵＲＬにウェブアクセスする。このウェブアクセスは、その店舗への入店をサービスサーバ１に対して通知するためのウェブアクセス（以降、「入店通知ウェブアクセス」とする）であり、それぞれの店舗のユーザＩＤまたは企業ＩＤが供に通知される。典型的には、ＵＲＬの末尾においてそれぞれの店舗のユーザＩＤが「／？＝ｕｓｅｒ＊＊＊」という形でクエリパラメータとして指定された形式が用いられる。
　ユーザ端末２からの入店通知ウェブアクセスを受け付けたサービスサーバ１は、ユーザ端末２に対してログインを求めるために、ログイン画面をユーザ端末２に返す。そのログイン画面においてユーザがログイン操作を行うことによりサービスサーバ１に買い手であるユーザのユーザＩＤまたは企業ＩＤが通知され、図２９（ｂ）に示すような情報がサービスサーバ１に記録される。なお、ウェブブラウザのｃｏｏｋｉｅによりすでにユーザ端末２において本システムにログイン済みの場合には、この最後のログイン処理を省略してユーザ端末２からサービスサーバ１にログイン済みのユーザＩＤまたは企業ＩＤを通知することができる。
　また、画像コードを提示するのが買い手であるユーザのユーザ端末２側で、店舗側に設置された端末（以降、「入店管理端末」とする）に搭載されたカメラでそれを読み取る態様でも同様の効果を得ることが可能である。この場合、買い手であるユーザのユーザ端末２が提示する画像コードには、そのユーザのユーザＩＤまたは企業ＩＤが符号化されている。
　店舗に入店したユーザは、本システムのＧＵＩ機能として、ログイン済みである自身のユーザＩＤまたは企業ＩＤが符号化されたコードを画面に表示させる。このような機能は、ユーザ端末２からの要求に応じてサービスサーバ１の要求処理部１０１が画面情報を生成してユーザ端末２に返信することにより実現可能である。その他、サービスサーバ１との間での通信を伴うことなく、ユーザ端末２側にダウンロードされて動作するＪａｖａＳｃｒｉｐｔ等のプログラムの機能により実現することもできる。
　そのようにしてユーザ端末２に表示されたコードが入店管理端末に読み取られると、入店管理端末は読み取ったコードを復号して得られるユーザＩＤまたは企業ＩＤを、予め登録されているその店舗のユーザＩＤまたは企業ＩＤと供にサービスサーバ１に入店情報として通知する。これにより、図２９（ｂ）に示すような情報がサービスサーバ１に記録され、上記と同様の効果を得ることができる。
実施の形態５．
　実施の形態１～４においては、上流側の業者において既に仕入れが確定している商品の中から売るものが選択されて取引情報が入力される場合を例として説明した。他方、取引の実情として、上流側の業者において未だ仕入れが確定していない商品について下流側の業者から前もって取引の予約や販売希望を伝える、即ち注文する場合がある。
　このような場合、上流側の業者において仕入れが確定しない商品については取引情報記憶部１０５に取引情報が記憶されていないため、注文の内容を取引情報として記録したとしても、その商品の上流側における仕入れの取引を指定する"親取引ＩＤ"を指定することができない。本実施形態においてはそのような態様について説明する。
　図３４は、本実施形態に係る取引情報記憶部１０５に記憶されている取引情報の１レコード分の内容を示す図である。図３４に示すように、本実施形態に係る取引情報は、図５において説明した内容に加えて、"注文フラグ"および"注文元ＩＤ"の情報を含む。"注文フラグ"はその取引情報レコードが、注文情報であること、即ち下流側の業者から上流側の業者に対する商品のリクエストであることを示す識別子である。
　"注文元ＩＤ"は、実施の形態１において説明した"親取引ＩＤ"の逆であり、その取引情報レコードが注文情報である場合であり、且つ下流側の業者から受けた注文に基づいて更に上流側の業者に対して注文を出す注文情報である場合に、下流側の業者から受けた注文情報の取引情報レコードを指定する情報である。下流側の複数の業者から受けた同種および同規格の商品をまとめて上流側の業者に対して注文を出すことが多いため、図３４に示すように"注文元ＩＤ"は複数指定されることが一般的である。
　図３５は、本実施形態に係る注文情報の処理動作を示すシーケンス図である。図３５の例においては、小売店から仲買に商品が注文され、その注文に基づいて仲買から大卸に注文が出される場合について説明する。図３５に示すように、まずは小売店がユーザ端末２ｄを操作して注文情報を登録する。図３６は、本実施形態に係る注文データ登録画面の例を示す図である。
　図３６に示すように、注文データ登録画面は図８（ａ）、（ｂ）において説明した売りデータ登録画面と概ね同様の取引情報を入力するための入力欄を含むが、買い手側から売り手側に対しての販売要求であるという点で、買い手ではなく売り手を指定する点が大きく異なる。ユーザ端末２ｄに表示された図３６に示す画面において必要な情報が入力され、「起票」ボタンが操作されることにより、ユーザ端末２ｄからサービスサーバ１に対して注文情報の登録要求が送信される（Ｓ３５０１）。
　Ｓ３５０１の処理の結果、サービスサーバ１において取引情報処理部１０４により取引情報記憶部１０５に取引情報が記録される。即ち、取引情報処理部１０４が注文受付処理部として機能する。この際、図３６の画面の表示に際してログインしたユーザＩＤ若しくは企業ＩＤが"買い手ＩＤ"として登録されるとともに、"注文フラグ"がオンの状態で登録される。このような注文情報が取引情報記憶部１０５に記憶される際には、注文先の業者においてまだ在庫の引き当てがされていない状態であり、"親取引ＩＤ"は未定であるため、空欄のまま登録される。
　このように小売店による注文の情報が登録されると、その注文情報において注文先として指定された業者の注文データ一覧表示画面において、その注文情報が確認可能となる。図３７は、本実施形態に係る注文データ一覧表示画面を示す図である。図３７に示す画面は、注文情報において注文先として指定された業者である仲買業者のユーザ端末２ｃが、ユーザの操作に従ってサービスサーバ１に画面情報の要求およびログイン済みのユーザＩＤ若しくは企業ＩＤを送信することにより表示される（Ｓ３５０２）。
　注文データ一覧表示画面の要求を受け付けたサービスサーバ１においては、取引情報処理部１０４が、要求とともに通知されたユーザＩＤが"買い手ＩＤ"に一致し、且つ"注文フラグ"がオンであるデータを抽出し、図３７に示すようにそれぞれの"売り手ＩＤ"ごとにまとめて表示する画面情報を生成する。そのようにして生成された画面情報を要求処理部１０１が要求元のユーザ端末２ｃに送信する。
　このように注文を確認した仲買業者は、受注した注文に基づいて更に上流側の業者へ在庫確保のための注文を行う。その際、異なる複数の業者から同一の産地、規格で且つ同一の商品についての注文がある場合、まとめて注文を行うことができる。そのため、ユーザは図３７に示す画面において、更に上流側の業者へ出す注文の元となる注文のレコードをタップやクリック操作により選択する。選択されたレコードは色が反転表示されるなど、ＧＵＩ上で明示されるが、選択用のチェックボックスなどを設けても良い。
　このように元となる注文レコードが選択された状態で、図３７に示す「注文」ボタンがタップ等で操作されると、選択された注文レコードの"取引ＩＤ"が一次的に記録された状態で図３６に示す注文データ登録画面が表示される。この際、図３７に示す画面で選択された注文レコードの"商品名"、"産地"、"規格"が自動的にそれぞれの欄に入力されることにより、ユーザの利便性を向上することができる。
　このようにして表示された注文データ登録画面において、Ｓ３５０１と同様にユーザが情報を入力し「起票」ボタンをタップすることにより、ユーザ端末２ｃからサービスサーバ１に対して注文情報の登録要求が送信される（Ｓ３５０３）。Ｓ３５０３においては、ログインに用いられたユーザＩＤ若しくは企業ＩＤと供に、図３７に示す画面で選択された注文レコードの取引ＩＤがサービスサーバ１に通知される。
　Ｓ３５０３の処理の結果、サービスサーバ１において取引情報処理部１０４により取引情報記憶部１０５に取引情報が記録される。この際、図３６の画面の表示に際してログインしたユーザＩＤ若しくは企業ＩＤが"買い手ＩＤ"として登録されるとともに、"注文フラグ"がオンの状態で登録され、更にユーザ端末２ｃから通知された注文の元となる注文レコードの取引ＩＤが"注文元ＩＤ"として記録される。
　このようにして"注文元ＩＤ"が記録された場合、取引情報処理部１０４は、その"注文元ＩＤ"と一致する"取引ＩＤ"のレコードを抽出する。そのレコードは注文元のレコードであり、上述した通り"親取引ＩＤ"が空欄の状態である。取引情報処理部１０４は、そのようにして抽出したレコードの"親取引ＩＤ"に、新たに追加したレコードに付与された"取引ＩＤ"を書き込み、親取引ＩＤを更新する（Ｓ３５０４）。
　図３８は、Ｓ３５０１において登録された小売店から仲買への注文の取引情報（以降、「一次注文」とする）と、Ｓ３５０３において登録された仲買から大卸への注文の取引情報（以降、「二次注文」とする）との対応関係を示す図である。図３８に示すように、一次注文の「売り手ＩＤ」が二次注文の「買い手ＩＤ」と共通し、一次注文の「取引ＩＤ」が二次注文の「注文元ＩＤ」として指定される。また、一次注文の「注文元ＩＤ」は空欄である。
　そして、Ｓ３５０４の処理においては、二次注文が起票されて採番された「取引ＩＤ」が、一次注文の「親取引ＩＤ」として書き込まれる。これにより、下流側の業者から上流側の業者への注文による取引情報の入力機能においても、本システムの要旨の１つである取引情報の連結関係の記録を実現することができる。なお、「親取引ＩＤ」が登録されることにより、その取引情報は注文として処理されたとみなし、「注文フラグ」をオフとしても良い。これにより、図３７に示す画面には表示されなくなる。
　このように仲買業者による注文の情報が登録されると、その注文情報において注文先として指定された大卸業者の注文データ一覧表示画面において、その注文情報が確認可能となる。Ｓ３５０２と同様、注文情報において注文先として指定された業者である大卸業者のユーザ端末２ｂが、ユーザの操作に従ってサービスサーバ１に画面情報の要求およびログイン済みのユーザＩＤ若しくは企業ＩＤを送信することにより、図３７と同様に大卸業者のユーザ端末２ｂにおいて注文データ一覧表示画面が表示される（Ｓ３５０５）。
　本実施形態に係る注文機能は、小売店や飲食店が翌日以降に必要となる商品を前もって確保するために注文を行うことが前提である。これに対して、生産・仕入れ業者から大卸業者に入荷する商品の取引情報は前日に起票されていることが一般的である。従って、仲買から大卸業者に注文が行われたタイミングでは、生産・仕入れ業者から大卸業者への売りが確定し、取引情報記憶部１０５に取引情報が記憶されていることが一般的であり、原則として大卸業者において在庫の引当処理が可能である。
　大卸業者が図３７に示す注文データ一覧表示画面において在庫を引き当てる対象の注文を選択し、図中に示す「在庫引当」ボタンを操作すると、ユーザ端末２ｂからサービスサーバ１に対して在庫引当画面の要求が送信される。サービスサーバ１はその要求に応じて在庫引当画面を表示するための画面情報をユーザ端末２ｂに対して送信する。これにより、ユーザ端末２ｂにおいて在庫引当画面が表示され、大卸業者において在庫確認が行われる（Ｓ３５０６）。
　図３９は、本実施形態に係る在庫引当画面の例を示す図である。図３９に示すように、在庫引当画面においては、在庫引当画面の要求に際して図３７に示す画面で選択された注文情報が抽出されて表示されている。そして、その注文情報に対応する商品の一覧であって、自身（ここでは大卸業者）のユーザＩＤ若しくは企業ＩＤが"買い手ＩＤ"となっている取引情報の一覧が表示されている。
　図３９に示すような画面は、Ｓ３５０６においてサービスサーバ１がユーザ端末２ｂから受けた要求に応じて取引情報記憶部１０５から情報を抽出することにより実現される。このような画面において、大卸業者はユーザ端末２ｂを操作し、表示されている注文情報に対して引き当てる在庫を「対応在庫」として表示されている取引情報から選択し、「確定」ボタンをタップする。これにより、ユーザ端末２ｂからサービスサーバ１に対して在庫引当登録が要求される（Ｓ３５０７）。
　図４０は、Ｓ３５０７の在庫引当登録の要求においてユーザ端末２ｂからサービスサーバ１に対して送信される情報（以降、「在庫引当情報」とする）の例を示す図である。図４０に示すように、在庫引当情報には、図３９において「注文情報」の一覧に含まれる注文情報としての取引情報の取引ＩＤである"対象注文情報取引ＩＤ"と、その注文に対して在庫を引き当てる対象の取引情報の取引ＩＤである"在庫引当対象取引ＩＤ"とを含む。
　図４０に示す在庫引当情報を受信したサービスサーバ１においては、取引情報処理部１０４が、対象注文情報取引ＩＤによって指定される取引ＩＤの取引情報の「親取引ＩＤ」に、在庫引当対象取引ＩＤを書き込むことで親取引ＩＤを更新する（Ｓ３５０８）。これにより、注文機能において、小売店、仲買、大卸というように下流側から順に発信された注文に対して実際の在庫が引き当てられることとなり、注文処理が完結する。
　以上説明したように、本実施形態においては、図１に示すような生産・仕入れ、大卸、仲買、小売店・飲食店といった形で上流側から下流側に順々に取引が行われる市場を前提として"親取引ＩＤ"によって下流側の取引情報から上流側の取引ＩＤを指定する形で取引の流れが記録されるシステムにおいて、下流側から上流側の業者に対して注文を行う場合であっても、"親取引ＩＤ"による取引の流れの記録に対応することが可能となる。
　なお、上記実施形態においては、取引情報の成立タイミングの実情に鑑み、下流側からの注文に対して大卸業者の段階で在庫の引き当てが行われる場合を例として説明した。これは一例であり、在庫の引き当て処理は、在庫の確定と注文の日程との関係で可能なタイミングで行われるものであって、例えば仲買業者の段階で可能であれば、上述した在庫引当処理を仲買業者が行っても良い。
　また、図３９においては、対応在庫の一覧の抽出条件として、在庫を引き当てる業者（上記においては大卸業者）のユーザＩＤ若しくは企業ＩＤが"買い手ＩＤ"となっている取引情報であって、注文情報として選択された取引情報と"商品"が一致するものが抽出される場合を例として説明した。これは一例であり、実際には注文において指定された産地や規格に従って在庫を引き当てることとなるため、"産地"や"規格"も抽出条件としても良い。また、注文の日時に対して"取引日時"を条件としても良いし、"販売終了"のフラグが付されているレコードを除外するようにしても良い。
　また、上記実施形態においては、注文者によって入力された希望の金額がそのまま取引情報として確定する場合を例として説明したが、取引現場の実情として金額の確定には様々な場合がある。従って、上述した態様の他、注文を受けた側が金額を修正して確定する態様や、注文を受けた側によって修正された金額に対して注文を出した側の合意を必要とする態様などを採用しても良い。また、注文を出す側が金額に幅を持たせて注文情報を起票し、注文を受けた側がその範囲内で金額を決定する態様でも良い。
　１　サービスサーバ
　２、２ａ、２ｂ、２ｃ、２ｄ　ユーザ端末
　３　店舗通信機
　１０　ＣＰＵ
　２０　ＲＡＭ
　３０　ＲＯＭ
　４０　ＨＤＤ
　５０　Ｉ／Ｆ
　６０　ＬＣＤ
　７０　操作部
　８０　バス
　９０　近距離通信アンテナ
　１０１　要求処理部
　１０２　業者情報処理部
　１０３　業者情報記憶部
　１０４　取引情報処理部
　１０５　取引情報記憶部
　２００　市場販売管理アプリ
　２０１　操作受付部
　２０２　表示処理部
　２０３　情報通信部

Claims (14)

  1. 　市場における商品の取引に関する情報を管理する市場取引管理システムであって、
    　商品の取引に関する情報を記憶する取引情報記憶部と、
    　前記取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供部と、
    　前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理部とを含み、
    　前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする市場取引管理システム。
  2. 　前記商品の仕入れ量とその商品の販売量とを表示する取引量表示画面を表示するための情報を生成する取引量表示画面生成部を含み、
    　前記取引量表示画面生成部は、
    　前記取引量表示画面を表示するための情報の生成に際して、ユーザを識別するユーザ識別子を取得し、
    　前記取引情報記憶部に記憶されている情報のうち、取得した前記ユーザ識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
    　前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出することを特徴とする請求項１に記載の市場取引管理システム。
  3. 　抽出された前記仕入れ量および前記販売量の情報に基づき、商品の仕入れ量に対する販売量の割合である歩留まり率を算出する歩留まり率算出部を含むことを特徴とする請求項２に記載の市場取引管理システム。
  4. 　算出された前記歩留まり率を、前記取引内容に含まれる商品を示す情報ごとに集計して平均値を記憶する平均歩留まり率記憶部を含むことを特徴とする請求項３に記載の市場取引管理システム。
  5. 　前記取引量表示画面生成部は、
    　算出された前記歩留まり率と、前記歩留まり率の算出対象である商品に関して前記平均歩留まり率記憶部に記憶されている前記歩留まり率の平均値とを比較表示するように前記取引量表示画面を表示するための情報を生成することを特徴とする請求項４に記載の市場取引管理システム。
  6. 　前記入力画面情報提供部は、
    　前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から商品を示す情報を抽出し、
    　抽出した前記商品を示す情報が、前記情報入力画面において取引の対象とする商品の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする請求項１に記載の市場取引管理システム。
  7. 　前記入力画面情報提供部は、
    　前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容において販売を終了したことを示す識別子が付されている情報を抽出対象から除外することを特徴とする請求項６に記載の市場取引管理システム。
  8. 　前記入力画面情報提供部は、
    　前記取引情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記買い手識別子に関連付けられている前記取引内容から前記商品の仕入れ量を抽出し、
    　前記取引情報記憶部に記憶されている情報のうち、前記仕入れ量として抽出した取引内容に関連付けられている取引識別子と一致する前記親取引識別子に関連付けられている前記取引内容から前記商品の販売量を抽出し、
    　前記仕入れ量と前記販売量との比較結果に基づいて抽出対象から除外することを特徴とする請求項６に記載の市場取引管理システム。
  9. 　前記利用者が市場に属する店舗に入店したことを認識する入店認識部と、
    　前記入店認識部による認識結果として、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子とを関連付けて記憶する入店管理情報記憶部とを含み、
    　前記入力画面情報提供部は、
    　前記入店管理情報記憶部に記憶されている情報のうち、前記商品を販売する主体を示す識別子と一致する前記店舗識別子に関連付けられている前記入店者識別子を抽出し、
    　抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢としてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする請求項１に記載の市場取引管理システム。
  10. 　前記入店管理情報記憶部は、前記店舗を識別する店舗識別子と前記利用者を識別する入店者識別子に加えて、日時を関連付けて記憶し、
    　前記入力画面情報提供部は、
    　抽出した前記入店者識別子が示す利用者が、前記情報入力画面において商品を販売する相手の選択肢として前記日時の降順でソートされてユーザに提示されるように前記情報入力画面を表示するための情報を生成することを特徴とする請求項９に記載の市場取引管理システム。
  11. 　商品を売る側において仕入れの確定していない商品について、商品を買う側から商品の販売希望を受け付ける注文受け付け処理部を含み、
    　前記取引情報記憶処理部は、
    　前記販売希望に基づき、前記親取引識別子が空欄の状態で前記取引情報記憶部に新たに取引の情報を注文情報として記憶させ、
    　前記注文情報に対応する前記商品の仕入れのための取引の情報が前記取引情報記憶部に新たに記憶された場合に、前記新たに記憶された取引の情報を識別する識別子を、前記注文情報における親取引識別子として記録することを特徴とする請求項１に記載の市場取引管理システム。
  12. 　前記取引情報記憶処理部は、
    　前記注文情報に対する在庫の引き当てとして、前記取引情報記憶部に記憶されている情報のうち前記注文情報に対応する情報が指定された場合に、指定された前記取引情報記憶部に記憶されている情報を識別する識別子を、前記注文情報における親取引識別子として記録することを特徴とする請求項１１に記載の市場取引管理システム。
  13. 　市場における商品の取引に関する情報を管理する市場取引管理プログラムであって、
    　商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を表示するための情報を提供する入力画面情報提供処理と、
    　前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させる取引情報記憶処理とを電子機器に実行させるものであり、
    　前記取引情報記憶処理は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて前記取引情報記憶部に記憶させる処理であることを特徴とする市場取引管理プログラム。
  14. 　市場における商品の取引に関する情報を管理する市場取引管理方法であって、
    　商品の取引に関する情報を記憶する取引情報記憶部に記憶させるための情報の入力を受け付ける情報入力画面を電子機器に表示するための情報を提供し。
    　前記情報入力画面において入力された情報に基づき、前記取引情報記憶部に新たに取引の情報を記憶させ、
    　前記取引情報記憶部は、それぞれの取引ごとに、その取引を識別する取引識別子、商品の売り手を識別する売り手識別子、商品の買い手を識別する買い手識別子、取引の内容に関する情報である取引内容、取引対象の商品を売り手が仕入れた際の取引を識別する親取引識別子を関連付けて記憶していることを特徴とする市場取引管理方法。
PCT/JP2022/013325 2022-03-22 2022-03-22 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法 WO2023181140A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2022/013325 WO2023181140A1 (ja) 2022-03-22 2022-03-22 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法
JP2023553515A JP7383241B1 (ja) 2022-03-22 2022-03-22 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2022/013325 WO2023181140A1 (ja) 2022-03-22 2022-03-22 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法

Publications (1)

Publication Number Publication Date
WO2023181140A1 true WO2023181140A1 (ja) 2023-09-28

Family

ID=88100223

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/013325 WO2023181140A1 (ja) 2022-03-22 2022-03-22 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法

Country Status (2)

Country Link
JP (1) JP7383241B1 (ja)
WO (1) WO2023181140A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245160A (ja) * 2008-03-31 2009-10-22 Fujitsu Ltd 取引データ登録プログラム、取引データ監視プログラム、取引データ登録装置、取引データ監視装置および取引データ追跡システム
JP2012178147A (ja) * 2011-01-31 2012-09-13 Yoshimitsu Kagiwada 取引管理システムおよび取引管理プログラム
WO2014020711A1 (ja) * 2012-07-31 2014-02-06 株式会社キーソフト 取引管理システムおよび取引管理プログラム
JP2020525869A (ja) * 2018-05-29 2020-08-27 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ブロックチェーンベースの商品追跡方法および装置
JP2020170324A (ja) * 2019-04-03 2020-10-15 株式会社春香園 電子商取引プログラム
JP2021096569A (ja) * 2019-12-16 2021-06-24 株式会社三菱総合研究所 取引追跡システムおよび取引追跡プログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009245160A (ja) * 2008-03-31 2009-10-22 Fujitsu Ltd 取引データ登録プログラム、取引データ監視プログラム、取引データ登録装置、取引データ監視装置および取引データ追跡システム
JP2012178147A (ja) * 2011-01-31 2012-09-13 Yoshimitsu Kagiwada 取引管理システムおよび取引管理プログラム
WO2014020711A1 (ja) * 2012-07-31 2014-02-06 株式会社キーソフト 取引管理システムおよび取引管理プログラム
JP2020525869A (ja) * 2018-05-29 2020-08-27 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ ブロックチェーンベースの商品追跡方法および装置
JP2020170324A (ja) * 2019-04-03 2020-10-15 株式会社春香園 電子商取引プログラム
JP2021096569A (ja) * 2019-12-16 2021-06-24 株式会社三菱総合研究所 取引追跡システムおよび取引追跡プログラム

Also Published As

Publication number Publication date
JPWO2023181140A1 (ja) 2023-09-28
JP7383241B1 (ja) 2023-11-20

Similar Documents

Publication Publication Date Title
US9898713B1 (en) Methods systems and computer program products for monitoring inventory and prices
US8046269B2 (en) Auction based procurement system
KR100727425B1 (ko) 단체 주도 구매 중개형 전자 상거래 시스템 및 이에적용되는 쇼핑몰 운영 시스템
JP6118959B2 (ja) 取引管理システムおよび取引管理プログラム
US20110246326A1 (en) System and method for enabling marketing channels in an ip marketplace
WO2008042822A2 (en) Apparatuses, methods and systems for cross border procurement
US20150120486A1 (en) System and method to compile and compare prices across multiple suppliers
KR20150052929A (ko) 상품 이용 후기를 이용한 온라인 쇼핑몰에서의 마케팅 시스템 및 방법
US20150178768A1 (en) System and method for intermediating electronic commerce using offline transaction information
CN112561566A (zh) 一种跨境进口门店分销商城平台***
JP2018142382A (ja) 取引管理システムおよび取引管理プログラム
JP7383241B1 (ja) 市場取引管理システム、市場取引管理プログラムおよび市場取引管理方法
KR101979442B1 (ko) 기업 간 전자상거래를 위한 양방향 글로벌 b2b 사이트 구축방법
KR101046602B1 (ko) 사업자 간의 유통 절차 관리 시스템
WO2015194519A1 (ja) 販売価格算出装置および販売価格算出システム
KR100426388B1 (ko) 포스 시스템을 이용하여 전자 상거래를 수행하는 방법 및시스템
US11488219B2 (en) End-to-end food delivery ecosystem
KR102157456B1 (ko) 부동산 매물 정보제공 시스템 및 이를 이용한 부동산 중개방법
US20230325869A1 (en) Automated Product/Service Vending System and Method
JP7256652B2 (ja) Ｃｒｍシステム
KR100690280B1 (ko) 컴퓨터 네트워크를 이용한 그룹과의 전자상거래 제어 방법및 시스템
KR20060065974A (ko) 상품 조달/배송과 쇼핑몰 운영/마케팅/영업을 분리한 몰인몰 형태의 온라인 마켓플레이스의 운영 방법
JP2002140568A (ja) 産業車両の販売方法とそれに用いる販売システム
KR101683227B1 (ko) 물품 거래를 중개하는 방법
KR20240076058A (ko) 실시간 농산물 시세를 반영한 공영 도매시장 pos 플랫폼 시스템

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2023553515

Country of ref document: JP

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

Ref document number: 22933286

Country of ref document: EP

Kind code of ref document: A1