Store management system and store management method
The store management system uses a cloud environment to manage delivery note data, enabling efficient creation of delivery notes and inventory management at store terminals during disruptions, addressing the limitations of centralized systems in distributed businesses.
Patent Information
- Application Number
- JP2022091149
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2022-06-03
- Publication Date
- 2024-12-24
- Estimated Expiration
- 2042-06-03
AI Technical Summary
In distributed business formats like wholesale and retail, store terminals often lack the necessary equipment and processing capacity to efficiently back up and create business documents such as delivery notes during disasters or failures, as they rely on central management servers that may become inaccessible.
A store management system utilizing a cloud environment to store and manage delivery note data, allowing terminals to identify delivery patterns, acquire necessary data, and create delivery notes independently during disruptions, reducing the burden on limited resources.
Enables store terminals to continue operations by creating delivery notes and managing inventory efficiently even when communication with central data centers is disrupted, minimizing resource and processing demands.
Smart Images

Figure 0007605791000001 
Figure 0007605791000002 
Figure 0007605791000003
Abstract
Description
[Technical field]
[0001] The present invention relates to a store management system and a store management method. [Background technology]
[0002] A system may be used in which information for each company is centrally managed by a central management server, and stores belonging to each company obtain the necessary information online from the central management server. In the event of a disaster or failure, communication between each store and the central management server may become difficult in such a system. For example, Patent Document 1 discloses a technology for continuing business operations even when a disaster or failure occurs.
[0003] The degenerate business support system of Patent Document 1 includes a server that executes business processing in response to requests from online terminals, and a backup server that can communicate with the server. The backup server groups business data for each business group to which the online terminals involved in the business processing belong, and outputs the grouped business data to a portable storage medium. In disaster areas, etc., offline terminals read out the grouped business data from the portable storage medium. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] JP 2011-028578 A Summary of the Invention [Problem to be solved by the invention]
[0005] In wholesale and retail businesses with stores distributed across various regions, the management terminals of each store may not hold the information necessary for accounting, and operations may be performed by obtaining the necessary information from a large central management server as needed. In addition, such companies need to back up the business data stored in the central management server in order to continue creating forms for customers as a minimum operation, even in the event of a disaster or failure.
[0006] However, in business formats such as wholesale and retail, the scale of facilities at each store and the processing power of terminals are often limited. Therefore, it is difficult for each store to back up all business data related to the creation of forms. Furthermore, even if a wide variety of large amounts of data were backed up, there was a problem that terminals with limited processing power could not efficiently create forms.
[0007] The degenerate business support system of Patent Document 1 is mainly targeted at financial institutions. For example, if communication between a terminal device of a branch located in a disaster area and a host computer of the head office is cut off, the system enables the terminal device of the branch to perform minimum processing offline. Patent Document 1 focuses on provisionally paying cash within the deposit balance, but a separate measure is required to ensure the minimum distribution of goods, etc. that should be purchased with that cash. In other words, a technology for continuously creating documents such as delivery notes that are essential for the distribution of goods, etc. has been desired. Therefore, the present invention aims to enable a store operating with limited facility resources to continue operations by using information necessary for creating documents even when communication with a data center that is accessed during normal times becomes difficult. [Means for solving the problem]
[0008] A store management system according to the present invention includes a store terminal installed in a store, and a management server including a cloud environment capable of communicating with the store terminal, the management server comprising: Identifying a pattern of the items to be delivered and the timing of delivery, identifying a past period based on the identified pattern, and identifying first delivery information required to generate an invoice for a specific date from delivery performance data for the identified past period; The store terminal includes: acquiring the first delivery information from the management server at a predetermined cycle, excluding data on items for which the number of days obtained by subtracting the same day of the previous month from the predetermined date, which is the disaster occurrence date, is not an integral multiple of the delivery cycle, from the identified first delivery information, and creating a delivery note for the predetermined date based on the first delivery information after the excluding; It is characterized by: Other means will be described in the description of the embodiment of the invention. Effect of the Invention
[0009] According to the present invention, a store operating with limited facility resources can continue operations by using the information necessary for creating reports even if communication with a data center that is normally accessed becomes difficult. [Brief description of the drawings]
[0010] [Figure 1] FIG. 1 is a diagram illustrating an example of the configuration of a store management system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating a configuration of a data center according to the present embodiment. [Diagram 3] FIG. 1 is a diagram illustrating a configuration of a cloud environment according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating a configuration of a store terminal according to the present embodiment. [Diagram 5] FIG. 11 is a diagram showing an example of data for creating a delivery note according to the embodiment; [Figure 6] 11 is a flowchart of a data transfer process from a data center to a cloud environment according to the present embodiment. [Figure 7] 11 is a flowchart of a data acquisition process from a cloud environment to a store terminal according to the present embodiment. [Figure 8] 13 is a flowchart of a delivery note, inventory list, and product detail information list output process according to the embodiment. [Figure 9] 13 is a flowchart (continued) of the delivery note, inventory list, and product detail information list output process according to the embodiment. [Figure 10] 10 shows details of the product inventory calculation process (step S1310 in FIG. 9). [Figure 11] FIG. 11 is a diagram illustrating an example of a login screen according to the embodiment. [Figure 12] FIG. 4 is a diagram showing an example of a menu screen according to the embodiment; [Figure 13]FIG. 13 is a diagram showing an example of a delivery note, inventory list, and product detail information list output screen according to the embodiment. [Figure 14] FIG. 2 is a diagram showing an example of a disaster delivery note according to the present embodiment. [Figure 15] FIG. 11 is a diagram showing an example of a product detail information list according to the embodiment. [Figure 16] FIG. 2 is a diagram showing an example of a disaster delivery table according to the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0011] FIG. 1 is a diagram showing an example of the configuration of a store management system 10 according to this embodiment. The store management system 10 comprises a store management device 100, a disaster response environment 200, and a client environment 300. The store management device 100 is a data center consisting of a group of servers that manages store operations. The disaster response environment 200 is a cloud environment consisting of a group of servers that download data in the event of a disaster. In the cloud environment 200, multiple servers are distributed, providing a redundant configuration in the event of a disaster or the like. The client environment 300 is a store terminal installed in a store that creates delivery notes in the event of a disaster.
[0012] The intranet 400 transfers the data file created by the data center 100 to the cloud environment 200. The Internet 500 transfers the data file held in the cloud environment 200 to the shop terminal 300.
[0013] That is, in this embodiment, the data center 100 is located in one place in principle and handles the operations of all stores in normal times. If the data center 100 stops due to a disaster, the cloud environment 200 temporarily takes over (backs up) the functions of the data center 100. The servers and other components that make up the cloud environment 200 are prepared in advance and distributed to various locations. The store terminals 300 are located in each of the multiple stores. In normal times, the store terminals 300 obtain data necessary for daily operations from the data center 100. In the event of a disaster, the store terminals 300 obtain the minimum data necessary to continue operations from the cloud environment 200.
[0014] In the event of a disaster as assumed in this embodiment, at least a part of the data center 100 will be shut down. The user company that operates the store management system 10 will then seek to ensure a minimum level of product distribution while reducing communication and processing burdens. Note that "goods" is a broader concept that includes both goods that are the subject of a transaction and tangible objects other than goods. An "invoice" is a printed matter or electronic data that lists information related to the movement of goods.
[0015] 2 is a diagram showing the configuration of a data center 100 according to this embodiment. The data center 100 constitutes a “management server.” The data center 100 includes a control unit 101, a storage unit 105, a timer 110, a memory 111, and a network interface unit 112.
[0016] The storage unit 105 is a data group that stores an authentication table 106, a delivery record table 107, authentication information data 108, and data 109 for creating a delivery note. The authentication table 106 holds information for logging in to the store management device 100 . The delivery record table 107 holds delivery record information registered in the store management device 100. The delivery record table 107 corresponds to "delivery record data" and is data from the past when no failures occurred in the store management device 10. The authentication information data 108 is authentication information used by the cloud environment 200 . The invoice creation data 109 is invoice information used by the store terminal 300. The invoice creation data 109 corresponds to "first delivery information."
[0017] The timer 110 is a controller having a time management function. The memory 111 is a controller that temporarily stores data. The network interface unit 112 is an interface unit for transferring data to the cloud environment 200 via the intranet 400 .
[0018] The control unit 101 is a controller group including an authentication information data forming function 102, a form data forming function 103, and a data transfer function 104. Note that the "XX function" in this embodiment is a program that is the subject of executing the processing of that function.
[0019] The authentication information data forming function 102 extracts only the authentication information (login ID, password) used by the cloud environment 200 from the authentication table 106, and creates authentication information data 108 as a result of the extraction.
[0020] The form data forming function 103 extracts data contents for each invoice from the delivery record table 107 that holds the delivery information of products for each customer, and creates, as the extraction result, data for creating an invoice 109. Here, the data for creating an invoice 109 is the source data for creating a disaster invoice 307 (FIG. 14) output from the store terminal 300.
[0021] The data 109 for creating a delivery note holds the store name, the name of the person in charge of delivery, the customer name, the delivery date, the product name, the number of items delivered, the product unit price, the detailed total, and the date before the delivery date was changed (details will be described later in FIG. 6). The data 109 for creating a delivery note also holds the delivery cycle and the number of items in stock, which are necessary for creating a product detailed information list 308 (FIG. 15) and a disaster shipment list 309 (FIG. 16).
[0022] The product details information list 308 lists the next scheduled delivery of products to be delivered to customers, the delivery cycle (next scheduled delivery date) for each product, and best-selling products. The disaster shipment list 309 lists the number of products to be shipped by each person in charge and a list of products that are out of stock.
[0023] The data transfer function 104 is activated at a time designated by a timer 110. The timer 110 activates the data transfer function at a predetermined time, for example, late at night every day. The data transfer function 104 transfers the authentication information data 108 created by the authentication information data forming function 102 and the delivery note creation data 109 created by the form data forming function 103 from the network interface unit 112 to the cloud environment 200 via the intranet 400.
[0024] 3 is a diagram showing the configuration of a cloud environment 200 according to this embodiment. The cloud environment 200, together with the data center 100, constitutes a "management server." In this embodiment, the cloud environment 200 is provided separately from the data center 100. However, the data center 100 and the cloud environment 200 may be configured to be stored as separate functional units in the same server.
[0025] The cloud environment 200 includes a control unit 201, a storage unit 206, a display unit 210, an input unit 211, a memory 212, a timer 213, a network interface unit (data center side) 214, and a network interface unit (store terminal side) 215.
[0026] The storage unit 206 is a data group that stores the authentication information data 108, the data for creating a delivery note 109, and an authentication information table 208. The authentication information data 108 and the data for creating a delivery note 109 here are the same as the authentication information data 108 and the data for creating a delivery note 109 in FIG. The authentication information table 208 is a data group that holds the authentication information used by the authentication function 204 .
[0027] The display unit 210 is a display or the like for the authentication function 204 to display the login screen 51 (FIG. 11). The input unit 211 is a keyboard, mouse, etc., with which the authentication function 204 accepts a shop login ID and a password. The memory 212 is a controller that temporarily stores data. The timer 213 is a controller having a time management function. The network interface unit (data center side) 214 is an interface unit for receiving data from the data center 100 side via the intranet 400. The network interface unit (shop terminal side) 215 is an interface unit for transferring data to the shop terminal 300 side via the Internet 500 .
[0028] The control unit 201 is a controller group including a data receiving function 202 , an authentication information data import function 203 , an authentication function 204 , and an invoice data download function 205 .
[0029] The data receiving function 202 receives the group of files (the authentication information data 108 and the data for creating an invoice 109 ) transferred from the data center (store management device) 100 , and stores them in the storage unit 206 . The authentication information data import function 203 registers the authentication information data 108 in an authentication information table 208 .
[0030] The authentication function 204 displays the login screen 51 (FIG. 11) on the display unit 210, and compares the store login ID and password entered in the input unit 211 with the store login ID and password registered in the authentication information table 208. The authentication function 204 allows the use of the invoice data download function 205 only when the comparison results in a match.
[0031] The invoice data download function 205 transfers the invoice creation data 109 of the store that the authentication function 204 has made available for downloading to the store terminal 300 via the network interface unit (store terminal side) 215. If the invoice creation data 109 of that store is subject to automatic downloading, the invoice data download function 205 automatically transfers the invoice creation data 109 of that store to the store terminal 300 at the time specified by the timer 213.
[0032] 4 is a diagram showing the configuration of a store terminal 300 according to this embodiment. The store terminal 300 includes a control unit 301, a storage unit 306, a display unit 312, an input unit 313, a memory 314, and a network interface unit 315.
[0033] The storage unit 306 is a data group that stores a disaster delivery note 307, a product detail information list 308, a disaster shipment list 309, a product inventory table 310, and data 109 for creating a delivery note.
[0034] The disaster delivery note 307 (FIG. 14) is a delivery note for each customer that is created from the delivery note creation data 109 in the event of a disaster, and lists the minimum items that should be delivered. The product detail information list 308 (FIG. 15) is a product information list for each customer and product created from the delivery note creation data 109 in the event of a disaster. The product detail information list 308 lists the product details listed on the disaster delivery note 307, as well as information on popular products (sales proposal products) that should be reminded to customers.
[0035] The disaster delivery list 309 (FIG. 16) is a delivery list for each delivery person created from the delivery note creation data 109. The product inventory table 310 is a data group that holds inventory information for each product. The product inventory table 310 holds the current product inventory quantity extracted from the delivery note creation data 109 as an initial value, and thereafter, the product inventory quantity is subtracted when the disaster shipment table 309 is output. The product inventory quantity is entered in the product detail information list 308. The invoice creation data 109 is the same as the invoice creation data 109 in FIG.
[0036] The display unit 312 is a display or the like on which the login function 302 displays the login screen 51 (FIG. 11). The input unit 313 is a keyboard, mouse, etc., with which the login function 302 accepts a store login ID and password. The memory 314 is a controller that temporarily stores data. The network interface unit 315 is an interface unit for receiving data from the cloud environment 200 via the Internet 500 .
[0037] The control unit 301 is a controller group including a login function 302 , an invoice output function 303 , a product detail information list output function 304 , and a disaster delivery list output function 305 .
[0038] The login function 302 displays the login screen 51 (FIG. 11) on the display unit 312, and checks the store login ID and password entered in the input unit 313 against the store login ID and password registered in the delivery note creation data 109. The login function 302 makes the delivery note output function 303, the product detail information list output function 304, and the disaster delivery list output function 305 available only when they match.
[0039] The delivery note output function 303 identifies a record (row) from the delivery note creation data 109 that corresponds to the delivery date that matches the delivery date used (described in detail below) set on the delivery note / shipping list / product detail information list output screen 71 (FIG. 13). The delivery note output function 303 obtains the store name, delivery person's name, customer name, delivery date, product name, delivery quantity, product price, detailed breakdown, and the date before the delivery date was changed from the identified record. The delivery note output function 303 creates a disaster delivery note 307 (FIG. 14) that holds the customer name (delivery destination), store name (issuer), delivery person's name, product name (delivery item), and the total amount thereof.
[0040] The product detail information list output function 304 identifies records from the delivery note creation data 109 that correspond to the delivery date that matches the delivery date set on the delivery note / shipping list / product detail information list output screen 71 (Fig. 13). From the identified records, the product detail information list output function 304 obtains the store name, delivery person's name, customer name, delivery date, product name, delivery quantity, product price, total details, date before the delivery date change, delivery cycle, and product inventory quantity. The product detail information list output function 304 creates a product detail information list 308 (Fig. 15) that lists the next scheduled delivery products, delivery cycle for each product, best-selling products, etc.
[0041] The disaster shipment list output function 305 identifies records from the delivery note creation data 109 that correspond to the delivery date that matches the delivery date set on the delivery note / shipment list / product detail information list output screen 71 (Fig. 13). From the identified record, the disaster shipment list output function 305 obtains the store name, delivery person's name, customer name, delivery date, product name, delivery quantity, product price, detailed list, date before the delivery date change, delivery cycle, and product inventory quantity. The disaster shipment list output function 305 creates a disaster shipment list 309 (Fig. 16) that lists the product shipment quantity and shortage list for each person in charge based on the product inventory quantity as of the delivery date.
[0042] 5 is a diagram showing an example of the invoice creation data 109 according to this embodiment. The invoice creation data 109 stores, in association with an invoice number 600, a store name 600, a delivery person's name 602, a customer name 603, a delivery date 604, a product name 604, a delivery quantity 606, a product price 607, a detailed total 608, a delivery cycle 609, a date before the delivery date change 610, and a product inventory quantity 611.
[0043] The delivery number 600 is a number assigned to each delivery note. The store name 601 is the name of the store (delivery source) that issued the invoice. The delivery person's name 602 is the name of the person who delivers the product. The customer name 603 is the name of the delivery destination to which the delivery note is to be sent. The delivery date 604 is the date on which the product is delivered. The product name 605 is the name of the product to be delivered.
[0044] Delivery quantity 606 is the number of items to be delivered. The product unit price 607 is the price per product to be delivered. The detailed total 608 is the amount obtained by multiplying the unit price 607 of the product by the number of items delivered 606 . The delivery cycle 609 is the cycle for delivering the product. The date before the delivery date change 610 is the date before the delivery date 604 is changed. If there is no change in the delivery date, this is blank. The product inventory quantity 611 is the inventory quantity of the product as of the output date.
[0045] FIG. 6 is a flowchart of a data transfer process from the data center 100 to the cloud environment 200 according to this embodiment.
[0046] In step S1101, the form data forming function 103 of the data center 100 sorts the delivery record table 107 by store.
[0047] In step S1102, the form data forming function 103 extracts products with purchase history from the delivery record table 107 sorted by store, and identifies a delivery timing pattern for each extracted product (identifies the items to be delivered and the delivery timing pattern). The form data forming function 103 may obtain a preset delivery cycle for each product as a method for identifying a pattern.
[0048] However, there may be cases where the delivery cycle setting value is not included in the delivery record table 107. In this case, in order to identify the pattern of the delivery timing, the form data forming function 103 may machine-learn an AI (artificial intelligence) model using the delivery record table 107 as learning data, and identify (estimate) the pattern of the delivery timing of each product based on the AI model.
[0049] Furthermore, when identifying the pattern of delivery timing, the form data forming function 103 refers to information indicating whether the delivery date has been changed irregularly, which is included in the delivery record table 107. The information indicating whether the delivery date has been changed irregularly may be information indicating that a previously scheduled delivery date has been changed, that an additional delivery has been made apart from the normal delivery cycle due to the occurrence of an irregular event, or the like.
[0050] Moreover, the information indicating whether the delivery date has been changed, which is included in the delivery record table 107, is also included in a predetermined form in the delivery note creation data 109. The predetermined form may be, for example, a format such as the date before the delivery date change 610 (FIG. 5).
[0051] Examples of patterns identified here are as follows: Product A-1 is delivered to store A once every two weeks, two units per delivery. Delivery is normally on a Friday, but if Friday falls on a public holiday, delivery will be on the following Thursday.
[0052] For example, when the delivered goods are consumables for office cleaning, such patterns are often clearly identified for each store and each product. In the store in the above example, employees receive cleaning supplies just before the weekend (Saturday and Sunday) every two weeks, and two part-time workers clean the store during those weekends.
[0053] In step S1103, the form data forming function 103 identifies, for each store, a required period for the invoice creation data 109 to be stored in the cloud environment 200, based on the pattern of the delivery timing of each product. For example, when the delivery cycle of a certain product is "once every two weeks," the form data forming function 103 looks back to the invoice record table 107 from two weeks ago and acquires that data. This allows data other than the minimum amount of data required to create a delivery note for a given date to be excluded from processing, thereby reducing the amount of data required.
[0054] For example, the form data forming function 103 may extract the delivery cycle for each product that has been delivered or is scheduled to be delivered in the store being analyzed, and then identify the "first delivery cycle" that is the delivery cycle of the product with the longest delivery cycle. Then, the form data forming function 103 may set the first delivery cycle as the required period for the delivery note creation data 109 to be stored in the cloud environment 200.
[0055] In step S1104, the form data forming function 103 generates encrypted invoice creation data 109 (first delivery information) based on the delivery record table 107 for the identified required period for each store.
[0056] In step S1105, the data transfer function 104 of the data center 100 transfers the authentication information data 108 and the invoice creation data 109 organized by store to the cloud environment 200 via the intranet 400 at the time specified by the timer 110. As described above, since only the data required to create an arbitrary date is stored in the cloud environment 200, it is possible to reduce the required facility and environmental resources and their processing capabilities.
[0057] In step S1106, the invoice data receiving function 202 of the cloud environment 200 stores the invoice creation data 109 in a predetermined location in the cloud environment 200, and stores the authentication information data 108 in the information table 208 of the cloud environment 200. Thereafter, the data transfer process ends.
[0058] 7 is a flowchart of data acquisition processing from the cloud environment 200 to the store terminal 300 according to this embodiment. Now, assume that the store terminal 300 instructs the cloud environment 200 to transmit the invoice creation data 109.
[0059] In step S1201, the invoice data download function 205 of the cloud environment 200 judges whether the invoice creation data 109 is subject to automatic download. If the result of the judgment is "subject" (step S1201 "YES"), the invoice data download function 205 transitions to step S1204, and if not (step S1201 "NO"), the invoice data download function 205 transitions to step S1202.
[0060] Here, automatic download refers to a function that automatically downloads the invoice creation data 109 to the store terminal 300 at a predetermined cycle without performing login authentication again. Once login authentication is completed and the invoice creation data 109 is downloaded to the store terminal 300, the invoice creation data 109 becomes the target of automatic download. If the invoice creation data 109 becomes the target of automatic download, the invoice data download function 205 can omit login authentication involving input of a store login ID and password, which reduces the burden on the user.
[0061] In step S1202, the authentication function 204 of the cloud environment 200 performs login authentication by checking the store login ID and password entered in the input unit 211 against the authentication information table 208. The store login ID and password are entered on the login screen 51 of FIG.
[0062] In step S1203, the authentication function 204 judges whether the authentication information is correctly entered. If the result of the collation in step S1202 is "match" (step S1203 "YES"), the authentication function 204 transitions to step S1204, and if not (step S1203 "NO"), the authentication function 204 transitions to step S1202.
[0063] In step S1204, the invoice data download function 205 compresses the invoice creation data 109 in the cloud environment 200 and transfers it to the store terminal 300 as a download file.
[0064] In step S1205, the invoice output function 303 of the store terminal 300 acquires the downloaded invoice creation data 109 and stores it in an arbitrary location of the store terminal 300. As a result, the store terminal 300 automatically acquires a minimum amount of invoice creation data 109 at a predetermined cycle, except for the first time, and holds it in the latest state. Then, the data acquisition process ends.
[0065] Figures 8, 9 and 10 are flowcharts of the delivery note / shipping list / product detail information list output process according to this embodiment. Figure 9 is a continuation of Figure 8. Figure 10 shows details of step S1310 in Figure 9. Before explaining the flowcharts, the disaster delivery note 307, product detail information list 308 and disaster shipping list 309 will be explained again, although some of them will overlap with those described above.
[0066] Disaster delivery note 307 in Fig. 14 holds only the minimum information required at the time of delivery to the customer, and the invoice creation data 109 on which it is based also has the minimum amount of data required, so that the required facility and environmental resources and their processing capabilities can be reduced. The date entered in the delivery date field 72 in Fig. 13 matches the delivery date on disaster delivery note 307 in Fig. 14. This date corresponds to the "specified date", and disaster delivery note 307 corresponds to the "delivery note on a specified date".
[0067] The product details information list 308 in Fig. 15 is supplementary information of products linked to the delivery destination customer. The product details information list 308 lists the delivery cycle (next scheduled delivery date) for each delivery product, the next scheduled delivery product, best-selling products, etc., and allows the system user (delivery note issuer) to propose products other than the scheduled delivery to the delivery destination, which leads to increased profits.
[0068] The disaster delivery list 309 in FIG. 16 indicates the number of products to be delivered and the number of products that are out of stock, etc., and enables the system user to reduce errors when delivering products to the delivery destination.
[0069] The operation based on the flowcharts of Figures 8 and 9 is as follows: Now, assume that the user presses the "Invoice / Shipping List Print" button 62 on the menu screen 61 (Figure 12) displayed on the display unit 312 of the store terminal 300. In step S1301, the invoice output function 303 of the store terminal 300 decompresses and decrypts the invoice creation data 109 stored in the store terminal 300.
[0070] In step S1302, the delivery note output function 303 displays the delivery date used by default. Specifically, first, the delivery note output function 303 displays the delivery note / shipping list / product detail information list output screen 71 (FIG. 13) on the display unit 312. The user inputs the delivery date (shipping date) in the delivery date field 72. A disaster occurs on this delivery date. The user may input the name of the delivery person in the delivery person name field 74, or the customer name in the customer name field 75. Furthermore, if the user wishes to output the disaster shipment table 309, he or she inputs a check mark in the disaster shipment table output field 77.
[0071] Secondly, the invoice output function 303 searches the invoice creation data 109 based on the input delivery date, displays a calendar for the month prior to the month in which the disaster occurred, and displays the date that is the same as the delivery date in the default display with emphasis. In the example of Fig. 13, the delivery date on which the disaster occurred is September 30th, and the same date in the previous month is August 30th. On August 30th, no disaster occurred, and the same product that should have been delivered on September 30th was delivered to the customer. The same date in the previous month is called the "used delivery date."
[0072] Thirdly, if the user wishes to change the delivery date displayed by default, the delivery note output function 303 accepts the change. Basically, the delivery date displayed by default becomes the delivery date on the disaster delivery note 307. However, the delivery note output function 303 assumes irregular cases and accepts changes to the delivery date displayed by default.
[0073] In step S1303, the invoice output function 303 determines whether the preview button 73 (FIG. 13) is pressed. If the preview button 73 is pressed (step S1303 "YES"), the invoice output function 303 transitions to step S1304, and if not (step S1303 "NO"), the invoice output function 303 transitions to step S1305.
[0074] In step S1304, the delivery note output function 303 extracts a record having a delivery date that matches the delivery date used from the delivery note creation data 109, and displays it on the display unit 312 in detailed format. The displayed record includes the store name, delivery person name, customer name, delivery date, product name, delivery quantity, product unit price, detailed total, date before the delivery date change, delivery cycle, and product inventory quantity. At this time, if the delivery person name 74 and customer name 75 have been entered on the delivery note / shipping list / product detailed information list output screen 71, the delivery note output function 303 displays only the parts of the record that match the delivery person name and customer name on the screen.
[0075] In step S1305, the invoice output function 303 determines whether the print button 76 (FIG. 13) is pressed. If the print button 76 is pressed (step S1305 "YES"), the invoice output function 303 transitions to step S1306, and if not (step S1305 "NO"), the invoice output function 303 waits until the print button 76 is pressed.
[0076] In step S1306, the delivery note output function 303 checks the delivery cycle. Specifically, first, the delivery note output function 303 acquires a record having a delivery date that matches the delivery date used from the delivery note creation data 109, and saves it in the memory 314. At that time, if the delivery person's name and customer name are entered on the delivery note / shipping list / product detail information list output screen 71, the delivery note output function 303 acquires and saves only the part of the record that matches the delivery person's name and customer name. The acquired and saved record includes the store name, delivery person's name, customer name, delivery date, product name, delivery quantity, product unit price, detailed total, date before delivery date change, delivery cycle, and product inventory quantity.
[0077] Secondly, the invoice output function 303 checks the delivery cycle for each product from the stored data.
[0078] In step S1307, the invoice output function 303 determines whether there is a product whose delivery date (invoice output date) minus the delivery date used (subtraction days) is not an integer multiple of the delivery cycle. If there is such a product (step S1307 "YES"), the invoice output function 303 transitions to step S1308, and if not (step S1307 "NO"), the invoice output function 303 transitions to step S1309.
[0079] When the number of days to be subtracted is an integer multiple of the delivery cycle for all products, such as an example where the number of days to be subtracted is four weeks (28 days) and the delivery cycle is once a week (7 days) or once every two weeks (14 days), the invoice output function 303 transitions to step S1309. On the other hand, when the number of days to be subtracted is not an integer multiple of the delivery cycle for at least one product, such as an example where the number of days to be subtracted is four weeks and the delivery cycle is once every three weeks (21 days), the invoice output function 303 transitions to step S1308.
[0080] In step S1308, the invoice output function 303 removes from the memory 314 the data for products whose number of days to be subtracted is determined to be not an integral multiple of the delivery cycle, from the invoice creation data 109 stored in the memory 314.
[0081] In step S1309, the invoice output function 303 removes from the memory 314, among the invoice creation data 109 stored in the memory 314, data in which the delivery cycle is blank (data other than that for periodical products).
[0082] In step S1310, the invoice output function 303 executes a product inventory calculation process. Details of the product inventory calculation process will be described later with reference to Fig. 10, but here it is assumed that the inventory quantity for each product is calculated as a result.
[0083] In step S1311, the disaster output table output function 305 of the store terminal 300 determines whether there are any products that will be out of stock. If there are such products (step S1311 "YES"), the disaster output table output function 305 transitions to step S1312, and if not (step S1311 "NO"), the disaster output table output function 305 transitions to step S1313.
[0084] In step S1312, the disaster delivery table output function 305 removes from the memory 314 the data of the product determined to be out of stock in step S1324 from the delivery note creation data 109 stored in the memory 314.
[0085] In step S1313, the delivery note output function 303 creates a disaster delivery note 307 based on the delivery note creation data 109 (data that has not been excluded) stored in the memory 314. The delivery note output function 303 prints the store name, the name of the person in charge of delivery, the customer name, and the delivery date on the disaster delivery note 307. At this time, the delivery note output function 303 may output (print or display on screen) the pattern identified in step S1102 (FIG. 6) for each type of product.
[0086] In step S1314, the delivery note output function 303 determines whether or not a check mark is present in the disaster shipment list output field 77. If a check mark is present (step S1314 "YES"), the delivery note output function 303 transitions to step S1315, and if not (step S1314 "NO"), the delivery note output function 303 transitions to step S1317.
[0087] In step S1315, disaster shipment table output function 305 creates (outputs) disaster shipment table 309 for products for which disaster delivery note 307 has been issued. Disaster shipment table output function 305 prints the store name, the name of the person in charge of delivery, and the shipment date (delivery date) on disaster shipment table 309. In addition, disaster shipment table output function 305 prints the product name and the number of products shipped (number of deliveries) for each product on disaster shipment table 309 for products other than those out of stock in step S1324 (FIG. 10).
[0088] In step S1316, the disaster delivery table output function 305 writes (outputs) a stock-out list in an arbitrary position of the disaster delivery table 309. The stock-out list 309 writes the product name and the shortage quantity for each product that is out of stock in step S1324 (FIG. 10).
[0089] In step S1317, the product detail information list output function 304 of the store terminal 300 creates (outputs) the product detail information list 308 (FIG. 15). The product detail information list output function 304 determines the best selling period for each product from the invoice creation data 109, and enters products whose delivery dates coincide with those periods in the product detail information list 308 as best-selling products.
[0090] At this time, the product detail information list output function 304 also obtains the current inventory quantity of best-selling products from the product inventory table 310 and lists them in a list. If a check mark is placed in the disaster shipment table output field 77, the disaster shipment table output function 305 also prints the best-selling products and their shipment quantities on the disaster shipment table 309 (the same applies in step S1318).
[0091] In step S1318, the product detail information list output function 304 identifies products for which the delivery cycle is blank (other than fixed-term contracts) and which have been delivered multiple times for each customer from the delivery note creation data 109, and prints these as best-selling products in the product detail information list 308. Thereafter, the delivery note / shipping list / product detail information list output process ends.
[0092] FIG. 10 shows details of the product inventory calculation process (step S1310 in FIG. 9). The product inventory calculation process is a process that compares the current inventory quantity for each product with the delivery quantity, and stores inventory information for each product in the product inventory table 310. The delivery note output function 303 calculates the inventory quantity of the product at the time of delivery using this product inventory quantity as a reference. The product inventory quantity at the time of delivery becomes the criterion for determining whether or not to write it on the disaster delivery note 307 (it is not written in the case of a shortage), and becomes the source data for writing the product inventory quantity in the product detail information list 308, and the product shipment quantity and shortage list in the disaster shipment table 309.
[0093] In step S1321, the invoice output function 303 acquires the product inventory quantity 611 from the invoice creation data 109 stored in the memory 314, and stores the acquired product inventory quantity 611 in the product inventory table 310 for each product.
[0094] In step S1322, the invoice output function 303 obtains the quantity of each item delivered from the invoice creation data 109 stored in the memory 314, subtracts the quantity of each item delivered from the quantity of items in stock in the product inventory table 310, and updates the value of the quantity of items in stock.
[0095] In step S1323, the invoice output function 303 determines whether or not there is a product for which the subtraction result in step S1322 is less than 0. If there is such a product (step S1323 "YES"), the invoice output function 303 transitions to step S1324, and if there is not such a product (step S1323 "NO"), ends the product inventory calculation process and transitions to S1311.
[0096] In step S1324, the invoice output function 303 stores the products for which the subtraction result in step S1322 is less than 0 as out-of-stock products in the memory 314. Thereafter, the product inventory quantity calculation process ends, and the process proceeds to S1311.
[0097] The store management system of this embodiment has the following advantages. (1) The store management system can create a current delivery note based on past delivery records. (2) The store management system enables the store terminal to automatically obtain the data necessary to create a delivery note at a predetermined interval. (3) The store management system can identify delivery timing patterns based on past examples. (4) The store management system can limit past delivery records to a required period. (5) The store management system can respond to irregular changes in delivery patterns.
[0098] (6) The store management system can confirm which products have actually been shipped out. (7) The store management system can prevent confusion from spreading in the event of a disaster by checking for shortages. (8) The store management system can output a delivery timing pattern for each product. (9) The store management system can help promote the products proposed for sale. (10) The store management system can create a delivery note for the current time of a disaster based on past delivery records in peacetime.
[0099] The examples are illustrative for explaining the present invention, and are omitted or simplified as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. The position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc., in order to facilitate understanding of the invention. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings.
[0100] As examples of various information, the various information may be described using expressions such as "table," "list," and "queue," but the various information may be expressed using data structures other than these. For example, various information such as "XX table," "XX list," and "XX queue" may be expressed as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are mutually interchangeable.
[0101] When there are multiple components having the same or similar functions, they may be described by using the same reference numerals with different subscripts, or when there is no need to distinguish between these multiple components, the subscripts may be omitted.
[0102] In the embodiments, a process performed by executing a program may be described. Here, a computer executes the program using a processor (e.g., CPU, GPU), and performs the process defined by the program while using a storage resource (e.g., memory) and an interface device (e.g., communication port). Therefore, the subject of the process performed by executing the program may be the processor. Similarly, the subject of the process performed by executing the program may be a controller, device, system, computer, or node having a processor. The subject of the process performed by executing the program may be a calculation unit, and may include a dedicated circuit that performs specific processing. Here, the dedicated circuit is, for example, an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), or a CPLD (Complex Programmable Logic Device).
[0103] The program may be installed in the computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. When the program source is a program distribution server, the program distribution server may include a processor and a storage resource that stores the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. In addition, in the embodiment, two or more programs may be realized as one program, and one program may be realized as two or more programs. [Explanation of symbols]
[0104] 10. Store Management System 100 Store management device (management server) 107 Delivery record table (delivery record data) 109 Data for creating delivery note (first delivery information) 200 Cloud environment (management server) 300 store terminals 310 Product inventory table (inventory information) 307 Disaster Delivery Note 308 Product Detail Information List 309 Disaster dispatch table
Claims
1. A store management system including a store terminal installed in a store and a management server including a cloud environment capable of communicating with the store terminal, The management server includes: Identify patterns of what items are being delivered and when they are being delivered; Identifying a past period based on the identified pattern; Identifying first delivery information necessary to generate an invoice for a specific date from the delivery performance data for the specified past period; The store terminal includes: acquiring the first delivery information from the management server at a predetermined period; data on items for which the number of days obtained by subtracting the same day of the previous month from the specified date, which is the disaster occurrence date, is not an integral multiple of the delivery cycle, is excluded from the specified first delivery information; creating an invoice for the specified date based on the first delivery information after the exclusion; A store management system characterized by the above.
2. The first delivery information is Contains information regarding changes to delivery schedules; The store management system according to claim 1 .
3. The store terminal includes: Stores inventory information of items, outputting an inventory list of goods based on the inventory information and the first delivery information; The store management system according to claim 2 .
4. The store terminal includes: outputting information indicating a shortage of an item based on the inventory information and the first delivery information; The store management system according to claim 3 .
5. The store terminal includes: outputting the pattern for each type of article; The store management system according to claim 4 .
6. The store terminal includes: outputting information indicating a sales proposal product separately from the delivery note based on the first delivery information; The store management system according to claim 5 .
7. The predetermined date is: The date on which a failure occurred in the store management system, The delivery record data is The data is from a past time when the store management system did not experience any problems. The store management system according to claim 6 .
8. A store management method executed by a store management system including a store terminal installed in a store and a management server including a cloud environment capable of communicating with the store terminal, The management server includes: Identify patterns of what items are being delivered and when they are being delivered; Identifying a past period based on the identified pattern; Identifying first delivery information necessary to generate an invoice for a specific date from the delivery performance data for the specified past period; The store terminal includes: acquiring the first delivery information from the management server at a predetermined period; data on items for which the number of days obtained by subtracting the same day of the previous month from the specified date, which is the disaster occurrence date, is not an integral multiple of the delivery cycle, is excluded from the specified first delivery information; creating an invoice for the specified date based on the first delivery information after the exclusion; A store management method comprising:
Citation Information
Patent Citations
System and method for promoting next order
JP2002123734A
Degeneration operation support system, degeneration operation support method, and backup server
JP2011028578A
