KR20230132747A - Computer-implemented systems and methods for artificial intelligence (ai)-based inbound plan generation - Google Patents

Abstract

The present disclosure relates to a method for AI-based inbound plan generation, performed by one or more processors, wherein the method provides nationwide distribution of products based on at least one of historical inventory data, supplier lead-time data, or supplier delivery cycle data. forecasting demand, and predicting national demand for the forecasted product and the associated competency type, where the competency type includes at least three different competency types, thereby determining the product demand capacity quantity associated with the fulfillment center; forecast, determine the inbound product constraint quantity, and calculate the difference between the forecast product demand capability quantity and the determined inbound product constraint quantity; and performing preprocessing planning by outputting excess product demand capacity quantities or remaining available product capacity quantities based on the calculated differences, and generating an inbound plan for the fulfillment center.

Description

COMPUTER-IMPLEMENTED SYSTEMS AND METHODS FOR ARTIFICIAL INTELLIGENCE (AI)-BASED INBOUND PLAN GENERATION}

This disclosure generally relates to computerized systems and methods for AI-based inbound plan generation. In particular, embodiments of the present disclosure relate to creative, non-traditional systems that involve using models to predict future inventory and available storage to generate inbound plans for fulfillment centers.

Fulfillment centers (FCs) encounter millions of products each day as they operate to fulfill consumer orders and enable carriers to pick up shipments as soon as the order is placed. Tasks for inventory management within a FC may include receiving merchandise from sellers, storing received merchandise for easy picking access, packaging items, confirming orders, and delivering packages. Currently, existing FCs and their systems for inventory management are configured to handle large volumes of incoming and outgoing goods, but when FCs receive more orders than they can handle, the FCs need storage space to receive all of those orders. A common problem arises because the product is not properly allocated, resulting in the product not being distributed properly across multiple FCs. For example, a seller associated with a FC may order large quantities of products from a supplier during peak seasons, but the FC may not have sufficient resources to receive the ordered products in a timely manner. This leads to a large backlog problem in FC by slowing down all receiving processes, which eventually accumulates into future problems. Backlog issues can lead to lost sales because they prevent sellers from distributing products and generating profits.

Traditional FC management systems typically allocate storage space manually based on received orders to alleviate such problems. However, these traditional systems do not effectively address the backlog problem because they only rely on data associated with an order when it is received. Moreover, these traditional systems may only rely on data associated with a single FC instead of multiple FCs, hindering optimization of FC storage allocation for incoming orders and reducing productivity.

Therefore, improved methods and systems for generating inbound plans to optimize storage allocation between FCs are needed.

Registered Patent Publication No. 10-2264625 (2021.06.14)

One aspect of the disclosure relates to a computer-generated system for AI-based inbound plan generation, the system including at least one processor and a memory storing instructions. At least one processor uses the model to predict available storage associated with the fulfillment center, calculate constraint capacity associated with the fulfillment center, predict demand capacity associated with the fulfillment center, predict available storage, compute Using the constraint capacity and the predicted demand capacity, determine an inbound constraint based on the predicted available storage and the calculated constraint capacity, and calculate the difference between the predicted demand capacity and the determined inbound constraint; and execute commands to perform preprocessing planning by outputting excess demand capacity or remaining available capacity based on the calculated differences, and generating an inbound plan for the fulfillment center based on the output of the performed preprocessing plan. It can be configured to do so.

Another aspect of the present disclosure relates to a computer-implemented method for AI-based inbound plan generation, the method comprising: using a model to predict available storage associated with a fulfillment center, calculate constraint capacity associated with the fulfillment center; predict the demand capacity associated with the fulfillment center, use the forecasted available storage, calculated constrained capacity, and predicted demand capacity; determine inbound constraints based on the forecasted available storage and calculated constrained capacity; and predict demand. Calculate the difference between capabilities and determined inbound constraints; and performing a pre-processing plan by outputting excess demand capacity or remaining available capacity based on the calculated difference, and generating an inbound plan for the fulfillment center based on the output of the performed pre-processing plan. .

Another aspect of the present disclosure relates to a computer-generated system for AI-based inbound plan generation, the system comprising at least one processor and a memory storing instructions. At least one processor uses the model to predict available storage associated with the fulfillment center, calculate constraint capacity associated with the fulfillment center, predict demand capacity associated with the fulfillment center, predict available storage, compute Using the constraint capacity and the predicted demand capacity, determine an inbound constraint based on the predicted available storage and the calculated constraint capacity, and calculate the difference between the predicted demand capacity and the determined inbound constraint; and perform pre-processing planning by outputting excess demand capacity or remaining available capacity based on the calculated differences, and based on the output of the performed pre-processing planning, generate an inbound plan for the fulfillment center and predict availability. Calculate the average absolute percentage error for storage and actual available storage; If we determine that the calculated average absolute percentage error is above a threshold, we select a new model to predict available storage; and may be configured to execute instructions to perform verification tests on the model, such as by creating a new inbound plan for the fulfillment center based on the new model.

Another aspect of the disclosure relates to a method for AI-based inbound plan generation, performed by one or more processors, the method based on at least one of historical inventory data, supplier lead-time data, or supplier delivery cycle data. Products associated with a fulfillment center by predicting national demand for a product and predicting national demand for a competency type associated with the forecasted national demand for the product, wherein the competency type includes at least three different competency types. predict the demand capacity quantity, determine the inbound product constraint quantity, and calculate the difference between the predicted product demand capability quantity and the determined inbound product constraint quantity; and performing preprocessing planning by outputting excess product demand capacity quantities or remaining available product capacity quantities based on the calculated differences, and generating an inbound plan for the fulfillment center.

Other systems, methods and computer-readable media are also discussed herein.

1A is a schematic block diagram illustrating an example embodiment of a network including computer systems for communications enabling delivery, transportation, and logistics operations, according to disclosed embodiments.
1B is a diagram illustrating a sample Search Result Page (SRP) containing one or more search results satisfying a search request according to interactive user interface elements, according to a disclosed embodiment.
1C is a diagram illustrating a sample of a Single Detail Page (SDP) containing a product and information about the product along with interactive user interface elements, according to a disclosed embodiment.
1D is a diagram illustrating a sample shopping cart page containing items in a virtual shopping cart according to interactive user interface elements, according to a disclosed embodiment.
1E is a diagram illustrating a sample of an order page including items according to purchase and delivery information from a virtual shopping cart, according to interactive user interface elements, according to a disclosed embodiment.
2 is a schematic diagram of an example fulfillment center configured to utilize the disclosed computer system, in accordance with the disclosed embodiments.
3 is an example network of devices and systems for AI-based inbound plan creation, according to disclosed embodiments.
4 illustrates an example sub-process for AI-based inbound plan creation, according to disclosed embodiments.
5 illustrates an example sub-process for AI-based inbound plan creation, according to disclosed embodiments.
6 illustrates an example sub-process for AI-based inbound plan creation, according to disclosed embodiments.
7 illustrates an example process for AI-based inbound plan creation, according to disclosed embodiments.

Next, it is described in detail with reference to the attached drawings. Where possible, the same reference numerals are used in the drawings to refer to the same or similar parts in the following description. Although some example embodiments are described herein, variations, adaptations, and other implementations are possible. For example, replacements, additions, or changes may be made to components and steps within the drawings, and example methods described herein may be modified by replacing, reordering, removing, or adding steps to the disclosed methods. Accordingly, the following detailed description is not limited to the disclosed embodiments and examples. Instead, the proper scope of the invention is defined by the claims.

Embodiments of the present disclosure relate to systems and methods configured for AI-based inbound plan creation. In some embodiments, the system can use the model to predict available storage capacity (ASC) associated with FC. In some embodiments, the system may utilize the model to predict ASC for a plurality of selected expected delivery dates (EDDs) (e.g., in a specific time period such as two weeks). In some embodiments, the system may use a model to predict ASC for multiple FCs. In some embodiments, the system may use the same or various combinations of different models to perform predictions.

In some embodiments, the system may use a model to predict ASC for a specific storage type. For example, storage types may include pallet and bin. In some embodiments, the system may use a model to predict ASC for a specific competency type. For example, competency types may include totable, non-totable, and grande. In some embodiments, the system supports combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type totable product). The model can be used to predict ASC for a type non-totable product or a pallet-type grande product.

In some embodiments, stock-keeping units (SKUs) may be categorized by final delivery method to the customer. In some embodiments, one or more product classes may correspond to different final delivery methods to customers. For example, certain SKUs, such as low-value, non-fragile SKUs, may be shipped in bags (i.e., “totables”). High-value or fragile SKUs may need to be shipped in boxes with different packaging (i.e., “non-totable”). Other SKUs may be shipped in bulk or in original packaging from the manufacturer or supplier (i.e., “grandes”). For example, a box of toilet paper may be classified as a grande because consumers may often purchase large quantities of toilet paper, and the box may be shipped from its destination to the consumer in the original packaging provided by the toilet paper manufacturer. Accordingly, some storage space at the destination may be tied to the SKU type, such that some storage space at the destination is allocated to totable items, non-totable items, and grande items. For example, grande items may be stored in an area with few obstacles that a forklift can maneuver through, and totable items may be stored on shelves.

In some embodiments, SKUs may be further categorized based on the speed at which the SKU is processed. For example, faster processing SKUs may be stored on pallets in the FC, while slower processing SKUs may not be stored on pallets but instead stored in bins. Therefore, the combination of storage type and capacity type can be bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type non-totable product, or pallet-type totable product. Type Grande may include products.

The system can use the predicted ASC, calculated constraint capacity, and predicted demand capacity to perform preprocessing planning. Based on the output of the performed preprocessing plan, the system can generate an inbound plan for FC. For example, when the forecasted demand capacity exceeds the determined minimum capacity (e.g., during a peak period), the system divides the excess demand capacity among one or more additional FCs based on the inbound plan created for each additional FC. It can be distributed. In some embodiments, the system may optimize the distribution of excess demand capacity based on the storage or capacity type of the additional FC. In some embodiments, the system may optimize any distribution of expected demand capacity (e.g., but not limited to cases of excess demand capacity) based on the priority associated with each SKU.

1A, a schematic block diagram 100 is shown illustrating an exemplary embodiment of a system including a computer system for communications enabling delivery, transportation and logistics operations. As shown in Figure 1A, system 100 may include a variety of systems, each of which may be connected to one another through one or more networks. Systems may be connected to each other via direct connections (e.g., using cables). The systems shown include a shipping authority technology (SAT) system 101, an external front-end system 103, an internal front-end system 105, a transportation system 107, and mobile devices 107A, 107B, and 107C. , seller portal (109), shipping and order tracking (SOT) system (111), fulfillment optimization (FO) system (113), fulfillment messaging gateway (FMG) ( 115), supply chain management (SCM) system 117, warehouse management system 119, mobile devices 119A, 119B, 119C (fulfillment center (FC) 200) shown), a third-party fulfillment system (121A, 121B, 121C), a fulfillment center authorization system (FC Auth) (123), and a labor management system (LMS) (125) ) includes.

In some embodiments, SAT system 101 may be implemented as a computer system that monitors order status and delivery status. For example, the SAT system 101 can determine whether an order has passed its Promised Delivery Date (PDD), initiate a new order, reship items in the undelivered order, and reship the items in the undelivered order. We may take appropriate action, including canceling undelivered orders and initiating contact with the ordering customer. SAT system 101 may also monitor other data, including outputs (such as the number of packages delivered during a particular period of time) and inputs (such as the number of empty cardboard boxes received for use in shipping). . The SAT system 101 also enables communication (e.g., using store-and-forward or other techniques) between devices such as external front-end systems 103 and FO systems 113. may operate as a gateway between different devices within system 100.

In some embodiments, external front-end system 103 may be implemented as a computer system that allows external users to interact with one or more systems within system 100. For example, in an embodiment where system 100 enables presentation of the system so that a user can place an order for an item, external front end system 103 may receive a search request, present an item page, and , can be implemented as a web server that requests payment information. For example, external front-end system 103 may be implemented as a computer or computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, external front-end system 103 receives and processes requests from external devices (e.g., mobile device 102A or computer 102B) and creates databases and other data storage devices based on these requests. It may execute custom web server software designed to obtain information from and provide responses to requests received based on the information obtained.

In some embodiments, external front-end system 103 may include one or more of a web caching system, a database, a search system, or a payment system. In one aspect, external front end system 103 may include one or more of these systems, while in another aspect external front end system 103 may include an interface coupled to one or more of these systems (e.g., server to servers, database-to-database, or other network connections).

The example set of steps represented by FIGS. 1B, 1C, 1D and 1E will help explain some of the operations of the external front end system 103. External front-end system 103 may receive information from systems or devices within system 100 for presentation and/or display. For example, the external front-end system 103 may display a Search Result Page (SRP) (e.g., Figure 1b), a Single Detail Page (SDP) (e.g., Figure 1c), One or more web pages may be hosted or provided, including a cart page (eg, Figure 1D), or an order page (eg, Figure 1E). A user device (e.g., using mobile device 102A or computer 102B) can request a search by going to external front end system 103 and entering information into a search box. External front-end system 103 may request information from one or more systems within system 100. For example, external front-end system 103 may request information that satisfies a search request from FO system 113. The external front end system 103 may also request and receive (from the FO system 113) a Promised Delivery Date or “PDD” for each product included in the search results. In some embodiments, a PDD is an estimate of when a package containing a product will arrive at a user's desired location if ordered within a certain period of time, for example, by the end of the day (11:59 PM), or an estimate of when the product will arrive at the user's desired location. (PDD is discussed further below in relation to the FO system 113).

External front-end system 103 may prepare an SRP (e.g., Figure 1B) based on the information. The SRP may include information that satisfies the search request. For example, this may include a photo of a product that satisfies the search request. The SRP may also include information about the respective price for each product, or enhanced delivery options for each product, PDD, weight, size, offer, discount, etc. The external front-end system 103 may transmit the SRP (e.g., over a network) to the requesting user device.

The user device may select a product from the SRP, for example by clicking or tapping a user interface, or using another input device to select a product represented in the SRP. The user device may make a request for information about the selected product and transmit it to the external front-end system 103. In response, external front end system 103 may request information regarding the selected product. For example, the information may include additional information beyond that presented for the product on each SRP. This may include, for example, expiration date, country of origin, weight, size, number of items in the package, handling instructions, or other information about the product. Information may also include recommendations for similar products (e.g., based on big data and/or machine learning analysis of customers who have purchased this product and at least one other product), answers to frequently asked questions, customer reviews, Can include manufacturer information, photos, etc.

The external front-end system 103 may prepare a Single Detail Page (SDP) (eg, FIG. 1C) based on the received product information. The SDP may also include other interactive elements such as “Buy Now” buttons, “Add to Cart” buttons, quantity fields, item photos, etc. The SDP may include a list of sellers offering products. This list can be ordered based on the price offered by each seller so that the seller who offers to sell the product at the lowest price is at the top of the list. This list may also be ordered based on seller ranking, such that the highest ranking seller is at the top of the list. Seller rankings may be created based on a plurality of factors, including, for example, the seller's past track record of meeting promised PPD. The external front-end system 103 may forward the SDP (e.g., over a network) to the requesting user device.

The requesting user device may receive an SDP listing product information. Upon receiving the SDP, the user device can interact with the SDP. For example, a user of the requesting user device may click or interact with the SDP's “Place in Cart” button. This will add the product to the shopping cart associated with the user. The user device may send this request to the external front end system 103 to add the product to the shopping cart.

External front end system 103 may generate a shopping cart page (e.g., Figure 1D). In some embodiments, the shopping cart page lists products the user has added to a virtual “shopping cart.” The user device may request the shopping cart page by clicking on or interacting with the icon of the SRP, SDP, or other page. In some embodiments, the shopping cart page displays all products that the user has added to the shopping cart, as well as the quantity of each product, the price per item for each product, the price of each product based on the quantity involved, information regarding the PDD, delivery method, shipping cost, User interface elements for modifying products in the shopping cart (for example, deleting or modifying the quantity), options for ordering other products or setting up regular deliveries of products, options for setting up interest payments, making purchases. You can list information about the products in the shopping cart, such as user interface elements to proceed. A user of a user device may click on or interact with a user interface element (e.g., a button that says “Buy Now”) to initiate a purchase of a product in a shopping cart. The user device can then transmit this request to the external front end system 103 to initiate the purchase.

External front end system 103 may generate an order page (e.g., Figure 1E) in response to receiving a request to initiate a purchase. In some embodiments, the order page relists items from a shopping cart and requests entry of payment and shipping information. For example, an order page may contain information about the purchaser of items in a shopping cart (e.g., name, address, email address, phone number) and information about the recipient (e.g., name, address, phone number, delivery information). , user interface elements that request delivery information (e.g., delivery and/or pickup speed/method), payment information (e.g., credit card, bank transfer, check, saved credit), and cash receipt (e.g. may include a section requesting tax purposes, etc. External front-end system 103 may transmit an order page to the user device.

The user device may enter information into the order page and click or interact with user interface elements that transmit information to the external front-end system 103. From there, external front end system 103 transmits information to other systems within system 100 so that new orders can be created and processed with products in the shopping cart.

In some embodiments, external front-end system 103 may be further configured to enable sellers to send and receive information related to orders.

In some embodiments, internal front-end system 105 allows internal users (e.g., employees of an organization that owns, operates, or leases system 100) to interact with one or more systems within system 100. It can be implemented as a computer system. For example, in an embodiment where system 100 enables the presentation of a system that allows a user to place an order for an item, internal front end system 105 may provide diagnostic and statistical information about the order to the internal user. It may be implemented as a web server that allows you to view, modify item information, or review statistics about your order. For example, the internal front-end system 105 may be implemented as a computer or computers running software such as Apache HTTP Server, Microsoft Internet Information Services (IIS), NGINX, etc. In other embodiments, internal front-end system 105 may receive and process requests from systems or devices represented within system 100 (as well as other devices not shown) and, based on such requests, store databases and other data storage devices. It can obtain information from and (execute designed custom web server software) to provide responses to requests received based on the information obtained.

In some embodiments, internal front-end system 105 may include one or more of a web caching system, a database, a search system, a payment system, an analytics system, an order monitoring system, etc. In one aspect, internal front end system 105 may include one or more of these systems, while in another aspect internal front end system 105 may include an interface coupled to one or more of these systems (e.g., server to servers, database-to-database, or other network connections).

In some embodiments, transportation system 107 may be implemented as a computer system that enables communication between systems or devices within system 100 and mobile devices 107A-107C. In some embodiments, transportation system 107 may receive information from one or more mobile devices 107A-107C (eg, cell phones, smartphones, PDAs, etc.). For example, in some embodiments, mobile devices 107A-107C may include devices operated by delivery personnel. A delivery person, who may be full-time, temporary, or on a shift basis, may use the mobile devices 107A-107C to deliver packages containing products ordered by the user. For example, to deliver a package, a delivery person may receive a notification on a mobile device indicating which package to deliver and the location to deliver. Upon arrival at the delivery location, the delivery person can place the package (e.g., in the back of a truck or in the package's crate) and use a mobile device to collect data related to identifiers on the package (e.g., barcode, image, text string, etc.). RFID tags, etc.) can be scanned, captured, and delivered (e.g., by leaving it at the front door, leaving it with a security guard, or handing it off to the recipient). In some embodiments, a delivery person may use a mobile device to take photo(s) of the package and/or obtain a signature. The mobile device may transmit information to the transportation system 107, including information about the delivery, including, for example, time, date, GPS location, photo(s), an identifier associated with the delivery person, an identifier associated with the mobile device, etc. You can. Transportation system 107 may store this information in a database (not shown) for access by other systems within system 100. In some embodiments, transportation system 107 may use this information to prepare and transmit tracking data indicating the location of a particular package to another system.

In some embodiments, certain users may use one type of mobile device (e.g., a full-time employee may use a professional PDA with custom hardware such as a barcode scanner, stylus, and other devices) while other users may use different types of mobile devices (for example, temporary or shift workers may use off-the-shelf cell phones and/or smartphones).

In some embodiments, transportation system 107 may associate a user with each device. For example, transportation system 107 may identify a user (e.g., represented by a user identifier, employee identifier, or phone number) and a mobile device (e.g., an International Mobile Equipment Identity (IMEI), International Mobile Subscription Identifier (e.g., IMSI), phone number, Universal Unique Identifier (UUID), or Globally Unique Identifier (GUID)). The transportation system 107 may use these associations in connection with data received upon delivery to analyze the data stored in the database to determine, among other things, the location of the operator, the efficiency of the operator, or the speed of the operator.

In some embodiments, merchant portal 109 may be implemented as a computer system that allows merchants or other external entities to electronically communicate with one or more systems within system 100. For example, a seller may use the seller portal 109 to use a computer system (not shown) to upload or provide product information, order information, contact information, etc. for products they wish to sell through the system 100. there is.

In some embodiments, delivery and order tracking system 111 receives, stores, and stores information regarding the location of packages containing products ordered by a customer (e.g., a user using devices 102A-102B). It can be implemented as a forwarding computer system. In some embodiments, delivery and order tracking system 111 may request or store information from a web server (not shown) operated by a delivery company that delivers packages containing products ordered by customers.

In some embodiments, delivery and order tracking system 111 may request and store information from systems represented in system 100. For example, delivery and order tracking system 111 may request information from transportation system 107. As described above, transportation system 107 may include one or more mobile devices 107A-107C (e.g., a cell phone) associated with one or more of a user (e.g., delivery person) or vehicle (e.g., delivery truck). , smartphone, PDA, etc.). In some embodiments, delivery and order tracking system 111 also utilizes a warehouse management system (WMS) 119 to determine the location of individual products within a fulfillment center (e.g., fulfillment center 200). You can request information from. Delivery and order tracking system 111 requests data from one or more of transportation system 107 or WMS 119, processes it, and provides it to devices (e.g., user devices 102A, 102B) upon request. can do.

In some embodiments, fulfillment optimization (FO) system 113 receives information about customer orders from other systems (e.g., external front-end system 103 and/or delivery and order tracking system 111). It can be implemented as a computer system that stores. FO system 113 may also store information indicating where specific items are maintained or stored. For example, certain items may be stored in only one fulfillment center, while certain other items may be stored in multiple fulfillment centers. In another embodiment, a particular fulfillment center may be configured to store only a particular set of items (eg, fresh produce or frozen products). FO system 113 stores this information as well as related information (e.g., quantity, size, date of receipt, expiration date, etc.).

FO system 113 may also calculate a corresponding PDD (Promised Delivery Date) for each product. In some embodiments, a PDD may be based on one or more elements. For example, FO system 113 may determine historical demand for a product (e.g., how many customers have ordered the product over a certain period of time), predicted demand for the product (e.g., how many customers will be ordering the product in an upcoming period), ), network-wide historical demand, which indicates how many products have been ordered over a certain period of time, network-wide forecasted demand, which indicates how many products are expected to be ordered over the upcoming period, and storing each product. The PDD for a product may be calculated based on the number of one or more products stored in each fulfillment center 200, expected or current orders for that product, etc.

In some embodiments, FO system 113 periodically (e.g., hourly) determines the PDD for each product, retrieves it, or retrieves it from another system (e.g., external front-end system 103, SAT system (e.g., 101), and can be stored in a database for transmission to the delivery and order tracking system 111). In another embodiment, FO system 113 receives electronic requests from one or more systems (e.g., external front end system 103, SAT system 101, shipping and order tracking system 111) and responds to the requests. You can calculate PDD accordingly.

In some embodiments, fulfillment messaging gateway (FMG) 115 receives a request or response in one format or protocol from one or more systems within system 100, such as FO system 113, and converts it to a different format or protocol. A computer system that forwards the request or response in the converted format or protocol to another system, such as the WMS 119 or a third-party fulfillment system 121A, 121B, or 121C, and vice versa. It can be implemented.

In some embodiments, supply chain management (SCM) system 117 may be implemented as a computer system that performs predictive functions. For example, the SCM system 117 stores, for example, historical demand for a product, predicted demand for a product, network-wide historical demand, network-wide forecasted demand, at each fulfillment center 200. Based on the number of products, expected or current orders for each product, etc., the level of demand for a particular product can be predicted. In response to these predicted levels and quantities of each product through all fulfillment centers, the SCM system 117 generates one or more purchase orders to purchase and stock sufficient quantities to satisfy the predicted demand for a particular product. can do.

In some embodiments, warehouse management system (WMS) 119 may be implemented as a computer system that monitors workflow. For example, WMS 119 may receive event data representing individual events from individual devices (e.g., devices 107A-107C or 119A-119C). For example, WMS 119 may receive event data indicating the use of one of these devices to scan a package. As discussed below with respect to fulfillment center 200 and FIG. 2, during the fulfillment process, package identifiers (e.g., barcode or RFID tag data) are stored at a particular stage of the machine (e.g., automated or handheld). barcode scanner, RFID reader, high-speed camera, device such as tablet 119A, mobile device/PDA 119B, computer 119C, etc.). WMS 119 may store each event representing a scan or reading of a package identifier in a corresponding database (not shown) along with the package identifier, time, date, location, user identifier, or other information, and may store such information in another system. (For example, it can be provided to the delivery and order tracking system 111).

In some embodiments, WMS 119 may store information associating one or more devices (e.g., devices 107A-107C or 119A-119C) with one or more users associated with system 100. For example, in some situations, a user (such as a part-time or full-time employee) may be associated with a mobile device in that he or she owns the mobile device (e.g., the mobile device is a smartphone). In other situations, a user stores a mobile device temporarily (e.g., a user rents a mobile device at the beginning of the day, uses it for the day, and returns it at the end of the day). can be related to

In some embodiments, WMS 119 may maintain activity logs for each user associated with system 100. For example, WMS 119 may identify any assigned processes (e.g., unloading truck, picking up items from pickup area, rebin wall operations, packing items), user identifier, location ( (e.g., floor or area of fulfillment center 200), number of units moved through the system by personnel (e.g., number of items picked, number of items packed), devices (e.g. , may store information related to each employee, including identifiers associated with devices 119A-119C). In some embodiments, WMS 119 may receive check-in and check-out information from a timekeeping system, such as a timekeeping system operating on devices 119A-119C.

In some embodiments, third party fulfillment (3PL) systems 121A-121C represent computer systems associated with third party providers of logistics and products. For example, some products may be stored at fulfillment center 200 (as discussed below with respect to FIG. 2) while other products may be stored off-site or on demand. It can be produced accordingly and cannot otherwise be stored in the fulfillment center 200. 3PL systems 121A-121C may be configured to receive orders from FO system 113 (e.g., via FMG 115) and deliver products and/or services (e.g., delivery or delivery) directly to customers. installation) can be provided. In some implementations, one or more 3PL systems 121A-121C may be part of system 100, while in other implementations, one or more 3PL systems 121A-121C may be external to system 100 ( For example, owned or operated by a third party provider).

In some embodiments, fulfillment center authentication system (FC Auth) 123 may be implemented as a computer system with various functions. For example, in some embodiments, FC Auth 123 may operate as a single-sign on (SSO) service to one or more other systems within system 100. For example, FC Auth 123 causes a user to log in through the internal front-end system 105, determines that the user has similar permissions to access resources in the delivery and order tracking system 111, and both Allows users to access those privileges without requiring a second login process. In another embodiment, FC Auth 123 allows users (eg, employees) to associate themselves with specific tasks. For example, some employees may not have electronic devices (such as devices 119A-119C) and may instead move between jobs and areas within fulfillment center 200 during the day. FC Auth 123 can be configured to allow these employees to indicate what they are doing at different times and what zone they are in.

In some embodiments, labor management system (LMS) 125 may be implemented as a computer system that stores attendance and overtime information for employees (including full-time and part-time employees). For example, LMS 125 may receive information from FC Auth 123, WMS 119, devices 119A-119C, transportation system 107, and/or devices 107A-107C.

The specific configuration shown in Figure 1A is merely an example. For example, while Figure 1A shows the FC Auth system 123 coupled to the FO system 113, not all embodiments require this specific configuration. Indeed, in some embodiments, systems within system 100 may be connected to the Internet, an intranet, a wide-area network (WAN), a metropolitan-area network (MAN), a wireless network conforming to the IEEE 802.11a/b/g/n standard, or a leased network. They may be connected to each other through one or more public or private networks including lines. In some embodiments, one or more of the systems within system 100 may be implemented as one or more virtual servers implemented in a data center, server farm, etc.

Figure 2 shows fulfillment center 200. Fulfillment center 200 is an example of a physical location that stores items for delivery to customers upon ordering. Fulfillment center (FC) 200 may be divided into multiple zones, each of which is shown in FIG. 2 . In some embodiments, these “zones” can be thought of as virtual divisions between different stages of the process of receiving an item, storing an item, retrieving an item, and shipping an item. Accordingly, although “zones” are shown in FIG. 2, in some embodiments, other divisions of zones are possible, and zones in FIG. 2 may be omitted, duplicated, or modified.

Inbound zone 203 represents the area of FC 200 where items are received from sellers wishing to sell products using system 100 of FIG. 1A. For example, a seller may use truck 201 to deliver items 202A and 202B. Item 202A may represent a single item that is large enough to occupy its own shipping pallet, and item 202B may represent a set of items that are stacked together on the same pallet to save space.

Workers may receive items in inbound area 203 and optionally use a computer system (not shown) to check the items for damage and accuracy. For example, an operator may use a computer system to compare the quantity of items 202A and 202B to the ordered quantity of the items. If the quantities do not match, the worker may reject one or more of the items 202A and 202B. If the quantities match, the operator can transport the items (e.g., by dolly, handtruck, forklift, or by hand) to buffer area 205. Buffer area 205 may be a temporary storage area for items that are not currently needed in the pickup area, for example, because there are sufficient quantities of those items in the pickup area to meet anticipated demand. In some embodiments, forklift 206 operates to transport items around buffer zone 205 and between inbound zone 203 and drop zone 207. If items 202A, 202B are needed at the pickup area (e.g., due to predicted demand), the forklift may transport the items 202A, 202B to drop area 207.

Drop zone 207 may be an area of FC 200 where items are stored before being transported to pickup zone 209 . A worker assigned to a pick operation (“picker”) accesses items 202A, 202B in the pick area, scans the barcode for the pick area, and uses a mobile device (e.g., device 119B). You can scan barcodes related to items 202A and 202B. The picker can then take the item to the pickup area 209 (e.g., by placing it on a cart or transporting it).

Pickup area 209 may be an area of FC 200 where items 208 are stored in storage unit 210 . In some embodiments, storage unit 210 may include one or more of physical shelves, bookshelves, boxes, totes, refrigerators, freezers, cold storage, etc. In some embodiments, pickup area 209 may be organized into multiple floors. In some embodiments, workers or machines may pick up items in a variety of ways, including, for example, forklifts, elevators, conveyor belts, carts, hand trucks, carts, automated robots or devices, or manually. can be transported. For example, a picker may place items 202A, 202B on a hand truck or cart in drop zone 207 and take items 202A, 202B to pickup zone 209.

The picker may receive instructions to place (or “stow”) items in a specific spot in the pickup area 209, such as a specific space on the storage unit 210. For example, a picker may scan item 202A using a mobile device (e.g., device 119B). The device may indicate where item 202A should be loaded, for example, using aisles, shelves, and location indicating systems. The device may then have the picker scan the barcode at that location before loading item 202A at that location. The device may transmit (e.g., via a wireless network) data to a computer system, such as WMS 119 of FIG. 1A, indicating that item 202A was loaded at that location by a user using device 119B. .

Once the user places an order, the picker may receive instructions to device 119B to retrieve one or more items 208 from storage unit 210. The picker may retrieve the item 208, scan the barcode on the item 208, and place it on the transport device 214. In some embodiments, transport mechanism 214 is represented as a slide, but the transport mechanism may be implemented as one or more of a conveyor belt, elevator, cart, forklift, hand truck, cart, etc. Item 208 may then arrive at packing area 211.

Packing area 211 may be an area of FC 200 where items are received from pickup area 209 and packed into boxes or bags for final delivery to the customer. In packing area 211, workers assigned to receive items (“rebin workers”) will receive item 208 from pickup area 209 and determine which order it corresponds to. For example, a rebinning operator may use a device such as computer 119C to scan a barcode on item 208. Computer 119C may visually indicate which order an item 208 is associated with. This may include, for example, a space or “cell” on the wall 216 that corresponds to an order. Once an order is complete (e.g., because the cells contain all the items in the order), the rebinning operator can notify the packing operator (or "packer") that the order is complete. Packers can retrieve items from cells and place them into boxes or bags for shipping. Packers can then transport the boxes or bags to hub area 213, for example via forklift, cart, cart, hand truck, conveyor belt, by hand, or other methods.

Hub zone 213 may be an area of FC 200 that receives all boxes or bags (“packages”) from packing zone 211 . Workers and/or machines in hub area 213 can retrieve packages 218, determine which part of the delivery area each package is destined for, and route the packages to the appropriate camp area 215. For example, if the delivery area has two small sub-areas, the package will be sent to one of the two camp areas 215. In some embodiments, a worker or machine may scan the package (e.g., using one of devices 119A-119C) to determine its final destination. Sending a package to a camp area 215 may include, for example, determining which part of the geographic area the package is destined for (based on zip code) and determining the camp area 215 associated with that portion of the geographic area. You can.

In some embodiments, camp area 215 may include one or more buildings, one or more physical spaces, or one or more areas where packages are received from hub area 213 for sorting into routes and/or sub-routes. . In some embodiments, camp area 215 may be physically separate from FC 200 , while in other embodiments camp area 215 may form part of FC 200 .

Workers and/or machines in camp area 215 may, for example, compare destinations with existing routes and/or sub-routes, calculate workload for each route and/or sub-route, time of day, delivery It may be determined which route and/or sub-route the package 220 should be associated with based on the method, the cost to ship the package 220, the PDD associated with the items in the package 220, etc. In some embodiments, a worker or machine may scan the package (e.g., using one of devices 119A-119C) to determine its final destination. Once the package 220 is assigned to a particular route and/or sub-route, workers and/or machines can transport the package 220 to be delivered. In the exemplary Figure 2, camp area 215 includes trucks 222, cars 226, and delivery men 224A and 224B. In some embodiments, delivery person 224A may drive truck 222, where delivery person 224A is a full-time employee who delivers packages for FC 200, and the truck owns FC 200. , owned, leased, or operated by the same company that leases or operates it. In some embodiments, delivery person 224B may drive a car 226, where delivery person 224B is a “flex” or contingency worker who makes deliveries as needed (e.g., seasonally). am. Car 226 may be owned, leased, or operated by delivery person 224B.

3, an example network of devices and systems for AI-based inbound plan creation is shown. As shown in FIG. 3 , system 300 may include an inbound constraint capability system 330, an inbound demand forecasting system 340, and a preprocessing planning system 350, each of which uses a network 310. It is possible to communicate with the user device 320 associated with the user 320A. In some embodiments, inbound pharmaceutical capacity system 330, inbound demand forecasting system 340, and pretreatment planning system 350 are connected to other components of system 300 through direct connections, for example, using cables. You can communicate with. In some other embodiments, system 300 may be part of system 100 of FIG. 1A and connected to other components of system 100 via a network 310 or through a direct connection, for example, using cables. Can communicate. Inbound pharmaceutical capability system 330, inbound demand forecasting system 340, and preprocessing planning system 350 may each include a single computer or multiple computers that interoperate to perform one or more processes and functions associated with the disclosed examples. Each may be composed of a distributed computer system including: In other embodiments, the functionality associated with systems 330, 340, and 350 may be implemented by fewer systems than shown in FIG. 3.

As shown in FIG. 3 , inbound constraint capability system 330 may include a processor 332 , memory 334 , and database 336 . Inbound demand forecasting system 340 may include a processor 342, memory 344, and database 346. Preprocessing planning system 350 may include a processor 352, memory 354, and database 356. The processor 332, 342 or 352 may include one or more known processing devices, such as a microprocessor of the Pentium ^™ family manufactured by Intel ^™ or the Turion ^™ family manufactured by AMD ^™ . Processor 332, 342, or 352 may constitute a multi-core or single-core processor that executes parallel processes simultaneously. For example, the processor 332, 342, or 352 may execute and control multiple processes simultaneously using a logical processor. The processor 332, 342 or 352 may implement virtual machine technology or other known technologies to provide the ability to execute, control, run, manipulate, store, etc. multiple software processes, applications, programs, etc. In another example, processors 332, 342, or 352 are configured to provide parallel processing capabilities to allow inbound constraint capability system 330, inbound demand forecasting system 340, and preprocessing planning system 350 to execute multiple processes concurrently. It may include a configured multi-core processor device. Those skilled in the art will understand that other types of processor devices may be implemented that provide the capabilities disclosed herein.

Memory 334, 344 or 354 may store one or more operating systems that, when executed by processor 332, 342 or 352, respectively, perform known operating system functions. By way of example, the operating system may include Microsoft Windows, Unix, Linux, Android, Mac OS, iOS, or other types of operating systems. Accordingly, examples of the disclosed subject matter can operate and function with computer systems running any type of operating system. Memory 334, 344, or 354 may be a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible computer-readable medium.

Database 336, 346, or 356 may include, for example, an Oracle ^TM database, a Sybase ^TM database, or another relational database, or a non-relational database, such as Hadoop ^TM Sequence File, HBase ^TM, or Cassandra ^TM . . Database 336, 346, or 356 may include a computing component (e.g., a database management system, a database) configured to receive and process requests for data stored in memory devices of the database(s) and provide data from the database(s). server, etc.). Database 336, 346, or 356 may include a NoSQL database such as HBase, MongoDB ^™ , or Cassandra ^™ . Alternatively, databases 336, 346, or 356 may include relational databases such as Oracle, MySQL, and Microsoft SQL Server. In some embodiments, database 336, 346, or 356 may take the form of a server, general purpose computer, mainframe computer, or any combination of these components.

Databases 336, 346, or 356 may store data that can be used by processors 332, 342, or 352, respectively, to perform methods and processes associated with the disclosed examples. Databases 336, 346, or 356 may be located within inbound constraint capability system 330, inbound demand forecasting system 340, or preprocessing planning system 350, respectively, as shown in FIG. 3, or they may be located in inbound It may be within a storage device located external to the pharmaceutical capacity system 330, the inbound demand forecasting system 340, or the preprocessing planning system 350. Data stored at 332, 342 or 352 may include any appropriate data associated with the FC (e.g., inventory data, product data, product order data, historical expected delivery date, estimated delivery date, historical actual delivery date, actual delivery date, current and historical inventory data, predicted available storage capacity, actual available storage capacity, model data, storage types, capacity types, FC profiles, historical and actual demand data, generated inbound plans, validation data, SKU data, etc.) .

User device 320 may be a tablet, mobile device, computer, etc. User device 320 may include a display. Displays may include, for example, liquid crystal displays (LCDs), light-emitting diode screens (LEDs), organic light-emitting diode screens (OLEDs), touch screens and other known display devices. A display can show various information to the user. For example, it may display options for creating an inbound plan, the inbound plan created, data associated with the inbound plan creation, FC data, etc. User device 320 may include one or more input/output (I/O) devices. I/O devices may include one or more devices that enable user device 320 to transmit and receive information from user 320A or other devices. I/O devices may include various input/output devices, cameras, microphones, keyboards, mouse-type devices, gesture sensors, motion sensors, physical buttons, voice input, etc. The I/O device may also be used to control the inbound constraint capability system 330, the inbound demand forecasting system 340, or the preprocessing planning system 350, for example, by establishing a wired or wireless connection between the user device 320 and the network 310. ) may include one or more communication modules (not shown) for transmitting and receiving information from.

In some embodiments, user 320A may be an internal user (e.g., an employee of an organization that owns, operates, or leases system 100 or 300). Internal front-end system 105 may be implemented as a computer system that allows user 320A to interact with system 300 using user device 320. For example, in an embodiment, the system 100 or 300 enables a presentation that allows a user to display options for creating an inbound plan, the created inbound plan, data associated with the inbound plan creation, FC data, etc. .

In some embodiments, inbound constraint capability system 330 may use the model to predict available storage capability (ASC) associated with FC (e.g., quantity of product, percentage of total capability, etc.). For example, current and historical inventory data (e.g., ending inventory data, inbound data, outbound data, etc.) for each FC can be used to predict the ASC associated with the FC. In some embodiments, system 330 can predict ASC by predicting outbound quantities of products. For example, system 330 can use the model to predict the outbound quantity of a product for a selected expected delivery date (EDD) using the following formula:

Outbound Quantity of Product (EDD)

= Ending stock of product (EDD - 1)

- Ending stock of products (EDD)

+ Inbound Quantity of Product (EDD)

Here, “EDD - 1” represents the day before EDD. In other words, the outbound quantity of the product for the selected EDD can be calculated by subtracting the ending inventory of the product in the EDD from the ending inventory of the product one day before the EDD and adding the inbound quantity of the product in the EDD.

System 330 may use the model to calculate ending inventory of products in the EDD using the following formula:

Ending stock of products (EDD)

= Ending stock of product (EDD - 1)

+ Inbound inventory of products (EDD) - Outbound inventory of products (EDD)

That is, the system 330 may calculate the ending inventory of the product of the EDD by adding the ending inventory of the product the day before the EDD to the inbound inventory of the product of the EDD and subtracting the outbound inventory of the product of the EDD.

In some embodiments, system 330 may use the model to predict ASC for a plurality of selected EDDs (e.g., over a specific period of time, such as two weeks). In some embodiments, system 330 may use a model to predict ASC for multiple FCs. In some embodiments, system 330 may use the same or various combinations of different models to perform predictions. In some embodiments, one or more models may predict ASC based on inventory in one or more FCs or cube availability in one or more FCs (e.g., 1,000 m ³ , space for 3,000 units, etc.).

In some embodiments, system 330 may use a model to predict ASC for a particular storage type. For example, storage types may include pallet and bin. In some embodiments, system 330 may use a model to predict ASC for a specific competency type. For example, competency types may include totable, non-totable, and grande. Totable competency types can place products in a tote, while non-totable competency types cannot place products in a tote. Grande competency types can fall somewhere between totable and non-totable, and there are cases where products can be placed in totes. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the model can be used to predict ASC for pallet-type non-totable products or pallet-type grande products).

In some embodiments, system 330 may calculate constraint capabilities associated with FC. For example, system 330 may calculate constraint capacity (e.g., quantity of product, percentage of total capacity, etc.) based on inbound infrastructure capacity associated with the FC. For example, inbound infrastructure capabilities include staffing at the FC, staffing for each station at the FC, drivers at the FC, forklift operators at the FC, number of products that can be received based on available staffing at the FC, etc. (For example, the constrained capacity of a FC can be calculated based on the fact that there are 100 stations in the FC, but only 80 workers can work in the FC). In some embodiments, pharmaceutical capabilities may relate to stock-keeping units (SKUs).

In some embodiments, system 330 may calculate constraint capabilities for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 330 may calculate constraint capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the constraint capacity can be calculated for pallet-type non-totable products or pallet-type grande products).

In some embodiments, SKUs may be sorted by final delivery method to the customer. For example, certain SKUs, such as low-value, non-fragile SKUs, may be shipped in bags (i.e., “totables”). High-value or fragile SKUs may need to be shipped in boxes with different packaging (i.e., “non-totable”). Other SKUs may be shipped in bulk or in original packaging from the manufacturer or supplier (i.e., “grandes”). For example, a box of toilet paper may be classified as a grande because consumers often purchase large quantities of toilet paper, and the box may be shipped from its destination to the consumer in the original packaging provided by the toilet paper manufacturer. there is. Accordingly, some storage space at the destination may be tied to the SKU type, such as some storage space at the destination is allocated to total items, non-totable items, and grande items. For example, grande items may be stored in an area with few obstacles that a forklift can maneuver through, and totable items may be stored on shelves.

In some embodiments, SKUs may be further categorized based on the speed at which the SKU is processed. For example, faster processing SKUs may be stored on pallets in the FC, while slower processing SKUs may not be stored on pallets but instead stored in bins. Therefore, the combination of storage type and capacity type can be bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type non-totable product, or pallet-type totable product. Type Grande may include products.

In some embodiments, system 330 may determine an inbound constraint for one or more FCs by determining the minimum between the calculated ASC and the calculated constraint capabilities of the FC. In some embodiments, system 330 may calculate the ASC and constraint capabilities of each FC and determine the inbound constraint for each day within the period. For example, system 330 may determine inbound constraints for one or more FCs for each day of the week. System 330 may calculate the average daily inbound constraints by dividing the total inbound constraints for the week by the number of days in the week. System 330 can create an inbound plan that accounts for variation within a time period by calculating average daily inbound constraints, thereby creating a more robust inbound plan.

In some embodiments, inbound demand forecasting system 340 may use financial or inventory data to predict demand capacity associated with FC. For example, system 340 may predict national demand for products for a selected EDD. In some embodiments, system 340 may predict nationwide demand for products for multiple EDDs within a time period. System 340 can predict nationwide demand using historical inventory data, supplier lead-time data, supplier delivery cycle data, etc. In some embodiments, national demand data may relate to SKUs. In some embodiments, demand capacity may be the expected capacity needed to store a number of predicted demand products. System 340 may predict demand capacity by predicting outbound goals for products based on financial or inventory data and predicting inbound inventory needed to meet the outbound goals. System 340 can predict demand capacity by maximizing storage among one or more FCs that can receive the inbound inventory needed to meet outbound goals. In some embodiments, system 340 may calculate average daily demand capacity by dividing the total demand capacity for a period of time (e.g., two weeks) by the number of days in the week (e.g., 14 days). System 340 can create an inbound plan that accounts for variation within a time period by calculating average daily demand capacity, thereby creating a more robust inbound plan.

In some embodiments, system 340 can predict demand capacity for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 340 may calculate demand capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 340 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , it is possible to predict demand capacity for pallet-type non-totable products or pallet-type grande products).

In some embodiments, SKUs may be sorted by final delivery method to the customer. For example, certain SKUs, such as low-value, non-fragile SKUs, may be shipped in bags (i.e., “totables”). High-value or fragile SKUs may need to be shipped in boxes with different packaging (i.e., “non-totable”). Other SKUs may be shipped in bulk or in original packaging from the manufacturer or supplier (i.e., “grandes”). For example, a box of toilet paper may be classified as a grande because consumers may often purchase large quantities of toilet paper, and the box may be shipped from its destination to the consumer in the original packaging provided by the toilet paper manufacturer. Accordingly, some storage space at the destination may be tied to the SKU type, such as some storage space at the destination is allocated to total items, non-totable items, and grande items. For example, grande items may be stored in an area with few obstacles that a forklift can maneuver through, and totable items may be stored on shelves.

In some embodiments, SKUs may be further categorized based on the speed at which the SKU is processed. For example, faster processing SKUs may be stored on pallets in the FC, while slower processing SKUs may not be stored on pallets but instead stored in bins. Therefore, the combination of storage type and capacity type can be bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type non-totable product, or pallet-type totable product. Type Grande may include products.

In some embodiments, preprocessing planning system 350 may utilize the predicted ASC from system 330, the constraint capacity calculated from system 330, and the demand capacity forecast from system 340 to perform preprocessing planning. there is. For example, system 350 may support a storage type, a capability type, or a combination of a storage type and a capability type (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, The pretreatment plan can be carried out by selecting a pallet-type totable product, a pallet-type non-totable product or a pallet-type grande product. For selection, system 350 may retrieve the determined inbound constraints from system 330. System 350 may determine whether the determined inbound constraint is less than or equal to predicted demand capacity.

If the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is negative, system 350 may output excess demand capacity. If the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is positive, system 350 can output the remaining available capacity. Based on the output of the performed preprocessing plan, system 300 may generate an inbound plan for one or more FCs. For example, if the determined inbound constraint exceeds the predicted demand capacity, system 300 may generate an inbound plan since one or more FCs may store the predicted demand capacity. In some embodiments, the generated inbound plan is a bin-type totable product, a bin-type non-totable product, a bin-type grande product, a pallet-type totable product, a pallet-type non-totable product, or a pallet-type totable product. Type Grande may include capacity allocation for at least one of the products, where the predicted demand capacity may be fully allocated or distributed among different capacity storage types.

In some embodiments, when forecasted demand capacity exceeds determined inbound constraints (e.g., during a peak period), system 350 may route between one or more additional FCs based on the inbound plan generated for each additional FC. Excess demand capacity can be distributed. For example, system 300 may be configured to support storage or capacity types of additional FCs (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, The distribution of excess demand capacity can be optimized based on pallet-type non-totable products or pallet-type grande products, etc. In some embodiments, system 300 may optimize any distribution of expected demand capacity (e.g., but not limited to cases of excess demand capacity) based on the priority associated with each SKU.

In some embodiments, one or more systems or components of system 300 may perform various simulations by adjusting one or more variables discussed above. System 300 may generate an inbound plan for one or more FCs based on optimization such that demand capacity that can be stored in the FC is maximized (e.g., available storage capacity in one or more FCs is maximized).

In some embodiments, system 300 may perform verification testing on one or more generated inbound plans (e.g., after creating an inbound plan, after each simulation of an inbound plan, etc.). For example, system 300 may perform validation testing on a model used to predict ASC by calculating the average absolute percentage error for predicted ASC and actual ASC. Upon determining that the calculated average absolute percentage error is above a threshold (e.g., 20%), system 300 selects a new model to predict ASC and generates a new inbound plan for FC based on the new model. can do.

For example, system 300 can calculate mean absolute percentage error (MAPE) using the following formula:

where n can be the number of EDDs (e.g., within a period), t can be an EDD, A _t can be the actual ASC, and F _t can be the predicted (or forecasted) ASC. .

In some embodiments, system 300 may calculate the symmetric mean absolute percentage error (SMAPE) using the following formula:

where n may be the number of EDDs (e.g., within a period), t may be an EDD, A _t may be the actual ASC, and F _t may be the predicted (or predicted) ASC.

In some embodiments, system 300 may perform validation testing by calculating the model's tracking signal (TS) using the following formula:

where n can be the number of EDDs (e.g., within a period), t can be an EDD, A _t can be the actual ASC, F _t can be the predicted (or predicted) ASC, and MAD can be It may be the mean absolute deviation. System 300 can calculate MAD using the following formula:

In some embodiments, if TS is outside a certain range (e.g., -4 to 4), system 300 selects a new model to predict ASC and creates a new inbound plan for FC based on the new model. can be created.

Referring to Figure 4, a process 400 for AI-based inbound plan creation is shown. In some embodiments, system 330 may perform several of the steps described herein, but other implementations are possible. For example, any of the systems and components described and illustrated herein (e.g., system 100, system 340, system 350, etc.) can perform steps described in this disclosure.

At step 401, system 330 may determine whether the selected EDD is before the current date. Then, if YES, system 330 may iterate by one day until the selected EDD is on or after the current date. Then, if NO, system 330 may proceed to step 403.

At step 403, system 330 may calculate the ASC for the selected EDD. For example, system 330 can use the model to predict ASC associated with FC. For example, system 330 may use current and historical inventory data (e.g., ending inventory data, inbound data, outbound data, etc.) for each FC to predict the ASC associated with the FC. In some embodiments, system 330 may predict ASC (e.g., quantity of product, percentage of total capacity, etc.) by predicting outbound quantities of product. For example, system 330 can use the model to predict the outbound quantity of a product for a selected expected delivery date (EDD) using the following formula:

Outbound quantity of product (EDD)

= Ending stock of product (EDD-1)

- Ending stock of products (EDD)

+ Inbound Quantity of Product (EDD)

At step 405, system 330 can determine whether the EDD is the last date within the period. Then, if no, system 330 can return to step 401 and repeat the process described above. Then, if yes, system 330 may proceed to step 407. That is, in some embodiments, system 330 may use the model to predict ASC for a plurality of selected EDDs in a specific time period (e.g., two weeks). In some embodiments, one or more models may predict ASC based on inventory in one or more FCs or cube availability in one or more FCs (e.g., 1,000 m ³ , space for 3,000 units, etc.).

In some embodiments, system 330 may use a model to predict ASC for a particular storage type. For example, storage types can include pallets and bins. In some embodiments, system 330 may use a model to predict ASC for a specific competency type. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the model can be used to predict ASC for pallet-type non-totable products or pallet-type grande products).

In some embodiments, SKUs may be sorted by final delivery method to the customer. For example, certain SKUs, such as low-value, non-fragile SKUs, may be shipped in bags (i.e., “totables”). High-value or fragile SKUs may need to be shipped in boxes with different packaging (i.e., “non-totable”). Other SKUs may be shipped in bulk or in original packaging from the manufacturer or supplier (i.e., “grandes”). For example, a box of toilet paper may be classified as a grande because consumers may often purchase large quantities of toilet paper, and the box may be shipped from its destination to the consumer in the original packaging provided by the toilet paper manufacturer. Accordingly, some storage space at the destination may be tied to the SKU type, such as some storage space at the destination is allocated to total items, non-totable items, and grande items. For example, grande items may be stored in an area with few obstacles that a forklift can maneuver through, and totable items may be stored on shelves.

In some embodiments, SKUs may be further categorized based on the speed at which the SKU is processed. For example, faster processing SKUs may be stored on pallets in the FC, while slower processing SKUs may not be stored on pallets but instead stored in bins. Therefore, the combination of storage type and capacity type can be bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type non-totable product, or pallet-type totable product. Type Grande may include products.

At step 407, system 330 can determine whether the selected EDD is before the current date. Then, if yes, system 330 may iterate by one day until the selected EDD is on or after the current date. Then, if no, system 330 may proceed to step 409.

At step 409, system 330 may calculate constraint capabilities associated with FC. For example, system 330 may calculate constraint capacity by multiplying constraint capacity (e.g., quantity of product, percentage of total capacity, etc.) for a period based on the inbound infrastructure capacity associated with the FC. For example, inbound infrastructure capabilities may include manpower at the FC, manpower for each station at the FC, drivers at the FC, forklift operators at the FC, number of products that can be received based on available manpower at the FC, etc. (For example, the constrained capacity of a FC can be calculated based on the fact that there are 100 stations in the FC, but only 80 workers can work in the FC). In some embodiments, pharmaceutical capabilities may relate to stock keeping units (SKUs).

In some embodiments, system 330 may calculate constraint capabilities for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 330 may calculate constraint capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. For example, system 330 may calculate constraint capabilities for each storage type and each constraint capability. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the constraint capacity can be calculated for pallet-type non-totable products or pallet-type grande products).

At step 411, system 330 may determine whether the EDD is the last date within the period. Then, if no, system 330 can return to step 407 and repeat the process described above. That is, in some embodiments, system 330 may utilize the model to predict constraint capacity for a plurality of selected EDDs in a specific period of time (e.g., two weeks). Then, if yes, system 330 may proceed to step 413.

At step 413, system 330 may determine whether all FCs of a certain number of FCs (e.g., all FCs) have been through process 400. For example, in some embodiments, multiple FCs may need to go through process 400. Then, if no, system 330 can return to step 401 to repeat the process described above. Then, if yes, system 330 may complete process 400.

In some embodiments, system 330 may use a model to predict ASC for multiple FCs. In some embodiments, system 330 may use the same or various combinations of different models to perform predictions. In some embodiments, system 330 may calculate constraint capabilities for multiple FCs. In some embodiments, system 330 may determine an inbound constraint for one or more FCs by determining the minimum between the calculated ASC and the calculated constraint capabilities of the FC. In some embodiments, system 330 may calculate the ASC and constraint capacity of each FC and determine the inbound constraint for each day within a given period. For example, system 330 may determine inbound constraints for one or more FCs for each day of the week. System 330 may calculate the average daily inbound constraints by dividing the total inbound constraints for the week by the number of days in the week. System 330 can create an inbound plan that accounts for variation within a time period by calculating average daily inbound constraints, thereby creating a more robust inbound plan.

Referring to Figure 5, a process 500 for AI-based inbound plan creation is shown. In some embodiments, system 340 may perform several of the steps described herein, but other implementations are possible. For example, any of the systems and components described and illustrated herein (e.g., system 100, system 330, system 350, etc.) can perform steps described in this disclosure. .

At step 501 (e.g., after step 413 of FIG. 4), system 340 may predict regional (e.g., national) demand for products for the storage type or capability type for the selected EDD. In some embodiments, system 340 may predict nationwide demand for a storage type or capability type (e.g., a product associated with a storage or capability type) for a plurality of EDDs within a given period of time. System 340 can predict nationwide demand using historical inventory data, supplier lead-time data, supplier delivery cycle data, etc. In some embodiments, system 340 may use financial or inventory data to predict demand capacity associated with FC. In some embodiments, national demand data may relate to SKUs. In some embodiments, demand capacity may be the expected capacity needed to store a number of predicted demand products.

At step 503, system 340 can predict demand capacity by predicting outbound goals for products based on financial or inventory data and predicting inbound inventory needed to meet the outbound goals. System 340 can predict demand capacity by maximizing storage among one or more FCs that can receive the inbound inventory needed to meet outbound goals. In some embodiments, system 340 may calculate average daily demand capacity by dividing the total demand capacity for a period of time (e.g., two weeks) by the number of days in the week (e.g., 14 days). System 340 can create an inbound plan that accounts for variation within a time period by calculating average daily demand capacity, thereby creating a more robust inbound plan.

In some embodiments, system 340 can predict demand capacity for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 340 may calculate demand capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 340 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , it is possible to predict demand capacity for pallet-type non-totable products or pallet-type grande products).

In some embodiments, SKUs may be sorted by final delivery method to the customer. For example, certain SKUs, such as low-value, non-fragile SKUs, may be shipped in bags (i.e., “totables”). High-value or fragile SKUs may need to be shipped in boxes with different packaging (i.e., “non-totable”). Other SKUs may be shipped in bulk or in original packaging from the manufacturer or supplier (i.e., “grandes”). For example, a box of toilet paper may be classified as a grande because consumers may often purchase large quantities of toilet paper, and the box may be shipped from its destination to the consumer in the original packaging provided by the toilet paper manufacturer. Accordingly, some storage space at the destination may be tied to the SKU type, such as some storage space at the destination is allocated to total items, non-totable items, and grande items. For example, grande items may be stored in an area with few obstacles that a forklift can maneuver through, and totable items may be stored on shelves.

In some embodiments, SKUs may be further categorized based on the speed at which the SKU is processed. For example, faster processing SKUs may be stored on pallets in the FC, while slower processing SKUs may not be stored on pallets but instead stored in bins. Therefore, the combination of storage type and capacity type can be bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, pallet-type non-totable product, or pallet-type totable product. Type Grande may include products.

At step 505, system 340 may determine whether all FCs of a certain number of FCs (e.g., all FCs) have undergone process 500. For example, in some embodiments, multiple FCs may need to go through process 500. Then, if no, system 340 may return to step 501 to repeat the process described above. Then, if yes, system 340 may complete process 500.

Referring to Figure 6, a process 600 for AI-based inbound plan creation is shown. In some embodiments, system 350 may perform several of the steps described herein, but other implementations are possible. For example, any of the systems and components described and illustrated herein (e.g., system 100, system 330, system 350, etc.) can perform steps described in this disclosure. .

At step 601 (e.g., after step 413 in FIG. 4 and after step 505 in FIG. 5), system 350 selects the predicted ASC from system 330 (e.g., process 400) to perform a preprocessing plan. )), constraint capabilities calculated from system 330 (e.g., process 400), and demand capabilities predicted from system 340 (e.g., process 500). For example, system 350 may support a storage type, a capability type, or a combination of a storage type and a capability type (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, The pretreatment plan can be carried out by selecting a pallet-type totable product, a pallet-type non-totable product or a pallet-type grande product. For selection, system 350 may retrieve the determined inbound constraints from system 330.

At step 603, system 350 may determine whether the determined inbound constraint is less than or equal to the predicted demand capacity. If the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may proceed to step 605.

At step 605, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is negative, system 350 may determine that the calculated difference is excess demand capacity.

Returning to step 603, if the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may proceed to step 607.

At step 607, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is positive, system 350 may determine that the calculated difference is the remaining available capacity.

Based on the output of the performed preprocessing plan, system 300 may generate an inbound plan for one or more FCs. For example, if the determined inbound constraint exceeds the predicted demand capacity, system 300 may generate an inbound plan since one or more FCs may store the predicted demand capacity. In some embodiments, the generated inbound plan is a bin-type totable product, a bin-type non-totable product, a bin-type grande product, a pallet-type totable product, a pallet-type non-totable product, or a pallet-type totable product. May include a competency assignment for at least one of the Type Grande products. Forecast demand capacity can be fully allocated or distributed between different capacity storage types.

Referring to Figure 7, a process 700 for AI-based inbound plan creation is shown. Although in some embodiments components of system 300 (e.g., systems 330, 340, 350, etc.) may perform the various steps described herein, other implementations are possible. For example, any of the systems and components described and illustrated herein (e.g., system 100, etc.) can perform steps described in this disclosure.

At step 701, system 330 may use the model to predict the ASC associated with the FC (e.g., quantity of product, percentage of total capacity, etc.). For example, current and historical inventory data (e.g., ending inventory data, inbound data, outbound data, etc.) for each FC can be used to predict the ASC associated with the FC. In some embodiments, system 330 can predict ASC by predicting outbound quantities of products. For example, system 330 may use the model to predict outbound quantities of product for a selected EDD.

In some embodiments, system 330 may use the model to predict ASC for a plurality of selected EDDs (e.g., over a specific period of time, such as two weeks). In some embodiments, system 330 may use a model to predict ASC for multiple FCs. In some embodiments, system 330 may use the same or various combinations of different models to perform predictions. In some embodiments, one or more models may predict ASC based on inventory in one or more FCs or cube availability in one or more FCs (e.g., 1,000 m ³ , space for 3,000 units, etc.).

In some embodiments, system 330 may use the model to predict ASC for a particular storage type. For example, storage types can include pallets and bins. In some embodiments, system 330 may use a model to predict ASC for a particular storage type. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the model can be used to predict ASC for pallet-type non-totable products or pallet-type grande products).

At step 703, system 330 may calculate constraint capacity (e.g., quantity of product, percentage of total capacity, etc.) associated with the FC. For example, system 330 may calculate constraint capabilities based on inbound infrastructure capabilities associated with the FC. For example, inbound infrastructure capabilities may include manpower at the FC, manpower for each station at the FC, drivers at the FC, forklift operators at the FC, number of products that can be received based on available manpower at the FC, etc. (For example, the constrained capacity of a FC can be calculated based on the fact that there are 100 stations in the FC, but only 80 workers can work in the FC). In some embodiments, pharmaceutical capabilities may relate to stock keeping units (SKUs).

In some embodiments, system 330 may calculate constraint capabilities for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 330 may calculate constraint capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 330 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , the constraint capacity can be calculated for pallet-type non-totable products or pallet-type grande products).

In some embodiments, system 330 may determine an inbound constraint for one or more FCs by determining the minimum between the calculated ASC and the calculated constraint capabilities of the FC. In some embodiments, system 330 may calculate the ASC and constraint capabilities of each FC and determine the inbound constraint for each day within the period. For example, system 330 may determine inbound constraints for one or more FCs for each day of the week. System 330 may calculate the average daily inbound constraints by dividing the total inbound constraints for the week by the number of days in the week. System 330 can create an inbound plan that accounts for variation within a time period by calculating average daily inbound constraints, thereby creating a more robust inbound plan.

At step 705, in some embodiments, inbound demand forecasting system 340 may use financial or inventory data to predict demand capacity associated with a FC. For example, system 340 may predict national demand for products for a selected EDD. In some embodiments, system 340 may predict regional (e.g., national) demand for products for multiple EDDs within a time period. System 340 can predict nationwide demand using historical inventory data, supplier lead-time data, supplier delivery cycle data, etc. In some embodiments, national demand data may relate to SKUs. In some embodiments, demand capacity may be the expected capacity needed to store a number of predicted demand products. System 340 may predict demand capacity by predicting outbound goals for products based on financial or inventory data and predicting inbound inventory needed to meet the outbound goals. System 340 can predict demand capacity by maximizing storage among one or more FCs that can receive the inbound inventory needed to meet outbound goals. In some embodiments, system 340 may calculate average daily demand capacity by dividing the total demand capacity for a period of time (e.g., two weeks) by the number of days in the week (e.g., 14 days). System 340 can create an inbound plan that accounts for variation within a time period by calculating average daily demand capacity, thereby creating a more robust inbound plan.

In some embodiments, system 340 can predict demand capacity for specific storage types. For example, storage types can include pallets and bins. In some embodiments, system 340 may calculate demand capabilities for specific capability types. For example, competency types may include totable, non-totable, and grande. In some embodiments, system 340 can support combinations of storage types and capability types (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product). , it is possible to predict demand capacity for pallet-type non-totable products or pallet-type grande products).

At step 707, preprocessing planning system 350 may use the predicted ASC from system 330, the constraint capacity calculated from system 330, and the demand capacity forecast from system 340 to perform the preprocessing planning. . For example, system 350 may support a storage type, a capability type, or a combination of a storage type and a capability type (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, The pretreatment plan can be carried out by selecting a pallet-type totable product, a pallet-type non-totable product or a pallet-type grande product. For selection, system 350 may retrieve the determined inbound constraints from system 330. System 350 may determine whether the determined inbound constraint is less than or equal to predicted demand capacity.

If the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is negative, system 350 may determine that the calculated difference is excess demand capacity. If the determined inbound constraint is less than or equal to the predicted demand capacity, system 350 may calculate the difference between the predicted demand capacity and the determined inbound constraint. Since the calculated difference is positive, system 350 may determine that the calculated difference is the remaining available capacity. Based on the output of the performed preprocessing plan, system 300 may generate an inbound plan for one or more FCs. For example, if the determined inbound constraint exceeds the predicted demand capacity, system 300 may generate an inbound plan since one or more FCs may store the predicted demand capacity. In some embodiments, the generated inbound plan is a bin-type totable product, a bin-type non-totable product, a bin-type grande product, a pallet-type totable product, a pallet-type non-totable product, or a pallet-type totable product. Type Grande may include capacity allocation for at least one of the products, where the predicted demand capacity may be fully allocated or distributed among different capacity storage types.

In some embodiments, when forecasted demand capacity exceeds determined inbound constraints (e.g., during a peak period), system 350 may route between one or more additional FCs based on the inbound plan generated for each additional FC. Excess demand capacity can be distributed. For example, system 300 may be configured to support storage or capacity types of additional FCs (e.g., bin-type totable product, bin-type non-totable product, bin-type grande product, pallet-type totable product, The distribution of excess demand capacity can be optimized based on pallet-type non-totable products or pallet-type grande products, etc. In some embodiments, system 300 may optimize any distribution of expected demand capacity (e.g., but not limited to cases of excess demand capacity) based on the priority associated with each SKU.

In some embodiments, one or more systems or components of system 300 may perform various simulations by adjusting one or more variables discussed above. System 300 may generate an inbound plan for one or more FCs based on optimization such that demand capacity that can be stored in the FC is maximized (e.g., available storage capacity in one or more FCs is maximized).

Although the disclosure has been shown and described with reference to specific embodiments thereof, it will be understood that the disclosure may be practiced in other environments without modification. The foregoing description has been presented for illustrative purposes. It is not exhaustive or limited to the precise forms or embodiments disclosed. Modifications and adjustments will be apparent to those skilled in the art from consideration of the description and practice of the disclosed embodiments. Additionally, although the forms of the disclosed embodiments have been described as being stored in memory, those skilled in the art will understand that these forms can be stored in a secondary storage device, such as a hard disk or CD ROM, or other form of RAM or ROM, USB media, or DVD. It will be understood that the information may be stored on other types of computer-readable media, such as, Blu-ray, or other optical drive media.

Computer programs based on the above description and disclosed methods are within the skill of a skilled developer. Several programs or program modules may be created using any technology known to those skilled in the art, or may be designed in connection with existing software. For example, a program section or program module can be defined as .NET Framework, .NET Compact Framework (and related languages, such as Visual Basic, C, etc.), Java, C++, Objective C, HTML, HTML/AJAX combination, XML, or Java applets. These can be designed within or by embedded HTML.

Moreover, although example embodiments have been described herein, as will be understood by those skilled in the art based on this disclosure, the scope of any or all embodiments is limited to equivalent elements, changes, omissions, and combinations (e.g., that span multiple embodiments). combination of forms), adjustments and/or modifications. Any limitations within the claims are to be broadly construed based on the language used within the claims, and are not intended to be limiting during the performance of the application or to the examples set forth herein. The examples are intended to be interpreted non-exclusively. Additionally, the steps of the disclosed method may be altered in any other way, including rearranging steps and/or inserting or deleting steps. Therefore, the description and examples are to be considered illustrative only, and the true scope and spirit is intended to be indicated by the following claims and their full equivalents.

Claims (10)

A method for AI-based inbound plan generation performed by one or more processors, the method comprising:
predict national demand for a product based on at least one of historical inventory data, supplier lead-time data, or supplier delivery cycle data;
predicting national demand for a competency type associated with the predicted national demand for the product, wherein the competency type includes at least three different competency types,
predict product demand capacity quantities associated with fulfillment centers;
Determine inbound product constraint quantities;
calculate a difference between the predicted product demand capacity quantity and the determined inbound product constraint quantity; and
By outputting an excess product demand capacity quantity or a remaining available product capacity quantity based on the calculated difference,
perform pretreatment planning; and
A method for AI-based inbound plan creation, including generating an inbound plan for the fulfillment center. In claim 1,
The AI-based method further comprising predicting available product storage quantity by predicting at least one of an outbound quantity of product to bin-type storage or an outbound quantity of product to pallet-type storage. How to create an inbound plan. The method of claim 2, wherein predicting the outbound quantity of the product for the bin-type storage or pallet-type storage comprises:
Calculate historical inventory quantities of products;
Calculate current stock quantities of products; and
A method for creating an AI-based inbound plan that includes calculating the current inbound inventory quantity of a product. The method of claim 3, wherein the current inventory quantity of the product is calculated based on a historical inventory quantity of the product, a current inbound inventory quantity of the product, and a current outbound inventory quantity of the product. The method of claim 1, wherein determining the inbound product constraint quantity is based on product constraint capability quantities comprising product constraint capability quantities associated with each of at least three product classes in the fulfillment center. . The method of claim 5, wherein the at least three product classes in the fulfillment center include a product class that can be shipped in a bag, a product class that can be shipped in a box, and a product class that can be shipped in original packaging. Methods for creating AI-powered inbound plans, including: The method of claim 1, wherein the product demand capacity quantity includes expected capacity quantities associated with a plurality of demand products. The method of claim 1, wherein if the calculated difference is a positive number, the excess product demand capacity quantity is output. The method of claim 1, wherein if the calculated difference is negative, the remaining available product capacity quantity is output. In a Cupputer-implemented system for outbound prediction, the system comprises:
memory to store instructions; and
10. A computer-implemented system for outbound prediction, comprising at least one processor configured to execute the instructions for performing the method of any one of claims 1-9.