# Auto Replenishment You can use the Auto Replenishment feature to determine the amount of inventory to hold and when to order more inventory by automating inventory management. Auto Replenishment streamlines the inventory management process by monitoring inventory, forecasted demand, and automatically reordering items based on configured inventory policy, ordering schedules, minimum order quantities, and vendor lead times. You can use Auto Replenishment to generate purchase order requests that can be imported into your ERP or purchasing systems to create purchase orders (POs) for your suppliers. # Key inputs Auto Replenishment relies on the following inputs to make accurate and informed calculations for inventory replenishment: + **Demand** – Demand data is the fundamental input for replenishment calculations. This data helps AWS Supply Chain understand the demand either in terms of past sales or future forecasts to be able to determine inventory requirements for future time buckets. You can provide demand forecasts or past sales history as an input for demand data. If demand forecasts are not available, you can provide sales history, and AWS Supply Chain will use historical consumption rate for replenishment calculations. + **Inventory** – Auto Replenishment uses on-hand inventory and on-order inventory as an input for replenishment calculations. On-hand inventory is the available inventory at locations that can be used to fulfill demands. On-order inventory is the open purchase or transfer orders that are inbound to the stocking location. Demand will be calculated from on-hand and on-order inventory to determine net supply requirements. + **Lead time** – Lead time is the time it takes for an order to be placed and the items to be received. Lead time helps AWS Supply Chain determine how far in advance it must place orders. For items that are ordered or procured from suppliers, lead time will refer to supplier/vendor lead time, which is the time it takes for a supplier to fulfill an order and deliver the goods. Any time required for internal order processing, quality checks, or handling should be included as part of the lead time. For items or products that are transferred from an enterprise’s internal locations, such as distribution centers or fulfillment centers, lead time will refer to transportation time, which is the time required for transportation and delivery from a source location to a destination location. + **Sourcing rules** – You can use sourcing rules to model supply chain network topology. Use sourcing rules to define relationships between different levels of locations (for example, regional DC to central DC) or relationships between suppliers and their sites. These relationships can be modeled at a product group or region level, or at a product or site level. + **Sourcing schedules** – Use Auto Replenishment to regularly monitor and replenish items with every run, or configure predefined schedules for items to be replenished. Use a sourcing schedule to define ordering schedules based on suppliers or shipping schedules, and on transportation schedules. You can define a sourcing schedule to replenish items multiple times a week, once a week, or during specific weeks of the month. + **Inventory policy** – Inventory policy is a key input to determine the target inventory level that is used to drive replenishment requirements. You can configure inventory policy at the most detailed product level, site level, or at an aggregate level such as product group, product segment, site, or region. Auto Replenishment supports absolute inventory level, days of cover, and service level inventory policies. You can define the target value for the configured inventory policy, and AWS Supply Chain uses the target value to determine the target inventory level. For more information on data fields required for supply planning, see [Supply Planning](entities-supply-planning.md). # Planning process Replenishment requirements are calculated based on the configured network topology for an item. The following is a sample network topology that we use to describe various calculations involved in generating replenishment orders. ![\[Supply planning process\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/Supply_planning_process.png) Auto Replenishment generates transfer requirements from spoke nodes to hub nodes (for example, regional DCs to the central DC), and it generates purchase requirements from hub nodes to suppliers (for example, central DC to suppliers). The following steps are involved in generating replenishment orders. These steps are repeated for each product and site combination that is in scope for replenishment planning. Requirements from downstream nodes are propagated upstream based on sourcing rules information, and the process repeats at the upstream node until it reaches the root node for that item. ![\[Supply planning process procedure\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/Supply_planning_process_procedure.png) + **Demand processing** – AWS Supply Chain prepares the historical demand or forecast data based on the replenishment plan configuration. Demand or forecasts are processed at the level of product, site, day, or week based on the replenishment plan configuration settings. Sales history or forecast data are aggregated at the product and site level if they are provided at a more detailed level, such as product, site, customer or product, site, channel. Similarly, day to week aggregation occurs if a replenishment plan is configured at the week level. In the preceding example, demand is taken from spoke nodes, which are regional DCs, and it is aggregated at the product, site, and day/week level. If consumption or demand based inventory policy is used, the last 30 days of demand (sales history) is used to calculate average consumption. + **Target inventory level** – Use the demand or forecasts along with the configured inventory policy to determine target inventory level for a specific time period. Auto Replenishment supports two different replenishment models. + Forecast-driven replenishment + Consumption-based replenishment AWS Supply Chain generates inventory targets based on the forecast. These inventory targets are determined based on lead time and sourcing schedules to ensure inventory levels account for the variability in demand and supply lead times. + **Transfer or purchase requirements** – AWS Supply Chain nets demand in each period from the supply (on-hand \$1 on-order inventory) to project inventory into future time. AWS Supply Chain maintains the projected inventory levels at the same level as the target inventory level calculated in the previous step. The difference between projected inventory level and target inventory level is the net supply requirement or reorder quantity (RoQ). AWS Supply Chain applies minimum order quantity, or it orders multiples to generate the final transfer requirements or purchase requirement (POR). AWS Supply Chain uses the transfer or vendor lead time to determine the order by date. The default for lot size is 1.0, and the minimum order quantity is 0. **Calculation logic** ``` rounding=f(RoQ,MOQ,Lot_Size) =Lot_Size×Max(RoQ,MOQ) ``` The preceding formula describes the rounding logic in Auto Replenishment. AWS Supply Chain first compares the reorder quantity RoQ and minimum order quantity MOQ, gets the final order proposal, and then multiplies by the lot size factor for the actual quantity. The lot size is configured in the sourcing rules entity with the field *qty\$1multiple*. + **Requirement propagation** – For spoke nodes, AWS Supply Chain uses sourcing rules to look up parent nodes and propagate transfer requirements to the upstream node. AWS Supply Chain offsets the required delivery date by transfer lead time to determine the required date at the parent node. AWS Supply Chain only supports single sourcing. When this step is completed for all child or spoke nodes under a hub node, AWS Supply Chain repeats the previous steps on the hub node. This process is repeated until it reaches the root node in an item’s topology. Auto Replenishment only shows purchase order requests for vendor-facing sites. There are two kinds of vendor-facing sites: + Vendor-facing sites that supply other sites + Vendor-facing sites that don't supply other sites ![\[Supply Planning process\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/Supply_planning_process_procedure2.png) For vendor facing-sites that supply other sites, the reorder quantity is the reorder quantity from its child sites, plus the independent reorder quantity from its own demand. For vendor-facing sites that don't supply other sites, the reorder quantity is computed based on the demand forecast of the site. The independent reorder quantity for vendor-facing sites follows the same logic in the reorder quantity computation. The dependent demand is the summation of all the child sites. If the days of coverage is 7, the RoQ is the summation of the quantity of all orders in the covered period. The following example shows a scenario in the planning horizon where there is only one order for each site, and it explains the computation. ![\[Supply Planning process example\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/Supply_planning_example.png) # Inventory policies Auto Replenishment supports three different inventory policies. Each policy computes a plan based on a different algorithm, and each policy requires different inputs. **Topics** + [ # Absolute inventory level ](absolute-inventory-level.md) + [ # Days of Cover ](doc-forecast.md) + [ # Service level ](service-level.md) # Absolute inventory level If you use *absolute quantities* to manage your inventory levels, you can use this policy setting to calculate target inventory level and RoQ. The absolute inventory level policy uses the configured target inventory level instead of computed inventory level (position). The target inventory level is the value of *target\$1inventory\$1qty *. ## Inputs and defaults The absolute inventory level policy requires forecast, lead time, and configuration for absolute inventory level policy, as shown in the following table. | Data required | Entity | Field | Value | Notes | | --- | --- | --- | --- | --- | | Inventory policy | inventory\$1policy | ss\$1policy | abs\$1level | NA> | | Inventory policy | inventory\$1policy | target\$1inventory\$1qty | Inventory level quantity | NA> | | Forecast | forecast | NA | NA | Mean or forecast quantities.> | | Lead time | transportation\$1lane | NA | NA | Lead time from a source location to a destination. | | Lead time | vendor\$1lead\$1time | NA | NA | Lead time from a vendor to a destination location. | *target\$1inventory\$1qty* from *inventory\$1policy* data entity used at the target inventory level ## Calculating reorder quantity The inputs for the reorder quantity (RoQ) calculation is the target inventory level and the current inventory level. If the inventory level record is missing, AWS Supply Chain generates a plan exception to review. ## Calculation logic ![\[Calculation logic for absolute inventory level\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/AbsoluteInventoryLevel.png) The reorder quantity is the difference between the target inventory level and the current inventory level. If the current inventory level is higher than the target inventory level, the reorder quantity is 0. The goal of absolute policy is to make sure that on each review date there is enough on-hand inventory to match the desired inventory level. The inner max function computes the extra demand before the target review date (the first review date after delivery). The covering period starts from the expected deliver date and ends with the target review date. If the current on-hand inventory or delivery date is able to cover demand for a specific period, the reorder quantity is 0. The max function determines if you must order extra. The outer max function computes the deficit of inventory and determines whether an order should be placed. The reorder quantity calculation for sites that supply to other sites is calculated according to the logic explained in the Days of Cover (DOC) inventory policy. # Days of Cover If you use Days of Cover (DoC) to manage your inventory levels, then this would be an appropriate policy setting to drive the calculation of target inventory levels and RoQ. DoC inventory policy uses the configured days of coverage. This policy doesn’t consider sourcing schedule (vendor review calendar) or vendor lead times to compute DOC. DOC is based on the *target\$1doc\$1limit* field in the *inventory\$1policy* data entity. Note that, for weekly planning, *target\$1doc\$1limit* still uses unit of day. A coverage of 2 weeks translates to 14 days. DoC policy can be used with forecast (*doc\$1fcst*) or demand (*doc\$1dem*). The difference between *doc\$1fcst* and *doc\$1dem* is the forecast source. *doc\$1fcst* is based on forecast, while *doc\$1dem* is based on the demand history in *outbound\$1order\$1line*. The forecast based days of coverage uses P50 of forecast, while the demand based planning uses the last 30 days of demand history to calculate average consumption rate. ## Inputs and defaults Target inventory level or Target inventory position (TIP) is the desired inventory position or level on a given date. Inventory position includes inventory on hand, in-transit, or on-order, while the inventory level is only the inventory on-hand. Inventory position is used for service level (sl) inventory policy, and inventory level is used for *doc\$1fcst*, *doc\$1dem*, and *abs\$1level* inventory policies. DOC policy requires forecast, lead time, and configuration for inventory policy. For *doc\$1fcst* policy, you must provide the following information: | Data required 1 | Entity | Field | Value | Notes | | --- | --- | --- | --- | --- | | Inventory policy | inventory\$1policy | ss\$1policy | doc\$1fcst | NA> | | Inventory policy | inventory\$1policy | target\$1doc\$1limit | Number of days | NA> | | Forecast | forecast | NA | NA | Mean or forecast quantities.> | | Lead time | transportation\$1lane | NA | NA | Lead time from a source location to a destination. | | Lead time | vendor\$1lead\$1time | NA | NA | Lead time from a vendor to a destination location. | For inventory policy based on days of coverage, the days to cover is the *target\$1doc\$1limit* value. ## Calculation logic for DOC\$1fcst policy ![\[Calculation logic for DOC_fcst policy\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/doc_fcst.png) ## Calculation Logic for doc\$1dem policy ![\[Calculation logic for doc_dem policy\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/doc_dem.png) The goal of days of coverage policy is to make sure on each review date that there is enough on-hand inventory to cover the configured days of coverage. The first part of the formula computes the days of coverage from the next review date until the end of days of coverage configured. The total covering period is *DOCP,S*​ for product *P* and site *S*. The second part of the formula computes the extra demand before the target review date (the first review date after delivery). The covering period starts from the expected deliver date and ends with the target review date. If the current on-hand inventory on the delivery date is able to cover demand of this period, the system reorders 0. The max function determines whether we must order extra. ## Calculating reorder quantity The input for the reorder quantity calculation is the target inventory level and the current inventory level. If the inventory level record is missing, the system generates plan exceptions for you to review. ![\[Calculation of reorder quantity\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/roq_calculation.png) The reorder quantity of product *P*, site *S*, and date *D* is the difference between the target inventory level and the current inventory level. If the current inventory level is higher than the target inventory level, the reorder quantity is 0. # Service level If you use in-stock percentage to manage your inventory levels, you can use this policy setting to drive the calculation of target inventory level and replenishment. ## Inputs and defaults For *sl* policy, Supply Planning requires the following fields. If these fields are empty, the default value is set to *null*, and the application throws an exception. | Data required | Entity | Field | Value | Notes | | --- | --- | --- | --- | --- | | Inventory policy | inventory\$1policy | ss\$1policy | sl | Service level is abbreviated as *sl*.> | | Inventory policy | inventory\$1policy | target\$1sl | percentage value | For example, 0.8> | | Forecast | forecast | NA | NA | Mean or forecast quantities.> | | Lead time | transportation\$1lane | NA | NA | Lead time from a source location to a destination. | | Lead time | vendor\$1lead\$1time | NA | NA | Lead time from a vendor to a destination location. | | Sourcing schedule or Vendor schedule | sourcing\$1schedule and sourcing\$1schedule\$1details | NA | NA | Defines the calendar or days during which vendors accept orders. | ## Calculating target inventory level Target Inventory Position (TIP) is used for service level (sl) inventory policy. TIP represents the desired inventory position on a given date. TIP includes on-hand and on-order inventory. The inputs required for service-level policy are forecast, lead time, sourcing schedule (plus sourcing schedule details), and configuration for service level. ![\[Calculation of Target Inventory Level\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/targetinventorylevel.png) TIP is based on forecast distribution. Supply Planning applies the critical ratio (CR or service\$1level) to forecast distribution, computes the demand, and sums up on days to cover. The available method to apply the critical ratio (service level) to forecast distribution is listed in the following. First, Supply Planning applies a CR to distribution in forecast (P10/P50/P90) by using linear interpolate. ![\[Applying a CR to distribution at forecast level\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/service_level.png) Supply Planning uses P10 for target\$1sl=0.1, P50 for target\$1sl=0.5, and P90 for target\$1sl=0.9. For a percentile that doesn’t exist in the forecast entity, Supply Planning uses a linear interpolate approach. Supply Planning computes other percentiles of demand forecast based on P10/P50/P90. Here are formulas for computing P40 (target\$1sl=0.4) and P75 (target\$1sl=0.75): P40=50−1040−10​×(P50−P10)\$1P10 P75=90−5075−50​×(P90−P50)\$1P50 When Supply Planning gets demand, the demand is summed up to use arbitrary summation by days to cover. Days to cover starts from the upcoming deliver date until the deliver date after the upcoming deliver date. ![\[Demand summary to use by days to cover\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/service_level_example.png) As shown in the previous figure, the yellow period is the days to cover. The beginning of the days to cover does not start from the first day of the planning horizon. The reason is that Supply Planning doesn’t order for days that cannot be covered. Supply Planning assumes that all lost sales are not recoverable. R1: the first review date based on the sourcing schedule. R2: the second review date based on the sourcing schedule. LT\$1R1: the lead time for putting order on R1. LT\$1R2: the lead time for putting order on R2. R\$1R1: the review period based on sourcing schedule. RD\$1R1: the first review date after R1, equaled to R1\$1R\$1R1. DD\$1R1: the deliver date if submit order is on R1; DD\$1R1 = R1 \$1 LT\$1R1. DD\$1R2: the deliver date if submit order is on R2; DD\$1R2 = R2 \$1 LT\$1R2. The following example shows the TIP computation. ![\[TIP calculation level\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/tip_calculation.png) ## Calculating reorder quantity The inputs for the *sl* reorder quantity calculation are the target inventory level and the current inventory level. Supply Planning throws an exception if the inventory level record is missing. ![\[Reorder calculation logic\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/reorder.png) The reorder quantity is the difference between the target inventory position and the current inventory level. If the current inventory position is higher than the target inventory position, then the reorder quantity is set to 0. # Configuring Auto Replenishment By using Auto Replenishment, you can view the amount of inventory to hold and when to order more inventory by automating inventory management. **Topics** + [ ## Using Supply Planning for the first time ](#supply-planning-firsttime) + [ ## Overview ](#sp_overview) + [ ## Purchase order requests ](#purchase_order_requests) + [ ## Plan exceptions ](#exceptions) + [ ## Supply planning settings ](#supply-planning-settings) ## Using Supply Planning for the first time You can define how and when you want to plan your supply chain. **Note** When you log in to Supply Planning for the first time, you can view the onboarding pages that highlight its key features. This helps you to get familiar with the Supply Planning capabilities. 1. In the left navigation pane on the AWS Supply Chain dashboard, choose **Supply Planning**. The **Supply Planning** page appears. 1. Choose **Get Started**. 1. On the **Choose your plan** page, select **Auto Replenishment**. 1. Choose **Get Started**. 1. On the **Supply Planning** page, choose **Next**. You can read through the description to understand what Supply Planning offers, or you can choose **Next** to the **Supply Planning Setup** page. 1. On the **Supply Planning Setup** page, there are four steps to configure Supply Planning: + **Name and Scope** – Enter the name of the supply plan, and select the products and regions to be included in the supply plan. + **Horizon and Schedule** – Define the time frame for Supply Planning to generate plan schedules. + **Inputs** – Define how you want Supply Planning to use process demand forecasts. + **Output** – Choose the Supply Planning output to publish to your Amazon S3 connector. You can also use material deviation percentage for material plans. 1. Under **Horizon and Schedule**, you can do the following: + **Planning Horizon** – You can set the planning period by defining the following: + **Start day of the week** – You can define your weekly supply planning. For example, if your **Start day of the week** is Monday, and today is July 3, then the supply planning period will be from July 3 to 9. + **Time Bucketization** – Define the time details. Daily and Weekly options are supported. + **Time Horizon** – Define the planning time horizon. The supported range is from 1 to 90 days, or from 1 to 104 weeks. + **Plan Schedule** – Define when your supply plans must be executed. + **Planning Frequency** – Define how frequently you want to execute the supply plan. + **Start Time** – Define when to start planning on a scheduled day. + **Release Times** – Define the time Supply Planning releases the approved purchase orders into the ERP system. + **Demand and Forecast** – Define the source for demand forecasts. + **Demand Planning** – Supply Planning will use the published forecasts from *Demand Planning *. + **External** – Supply Planning with use the demand forecasts ingested into the *Forecast* data entity in data lake. + **Past days for average demand calculation in consumption-based planning** – For product, site combinations with inventory policy set as *doc\$1dem*, Supply Planning looks at the past days of sales history from the *OutboundOrderLine* data entity to determine the average daily demand. You can choose between 30, 60, 90, 180, 270, or 365 days and Supply Planning will consider the corresponding number of days of historical sales data when generating the average. + **Forecast Netting ** – Independent demand includes both actual customer orders and forecasted demand. Forecast Netting offers four different methods to manage and conslidate these demand measures. By combining actual customer needs with forecast data effectively, businesses can better manage inventory levels and improve operational processes. Selecting the appropriate netting method helps align supply with demand, reducing inefficiencies and enhancing customer satisfaction. + **Do not change forecasted demand ** Do not change forecasted demand – Rely solely on forecasted demand to drive supply planning, discregarding actual customer orders. + **Replace forecasted demand with actual orders if higher than forecast** – If both forecasted demand and actual customer orders fall within the same time bucket, use the higher of the two values. + **Add actual orders to forecasted demand**Add actual orders to forecasted demand – If both forecasted demand and actual customer orders fall within the same time bucket, add the two values toghether. + **Enable demand time fence and forecast consumption** – Forecasted demand within the demand time fence is ignored. Ourside the time fence, forecasted demand is adjusted by substrating actual order quantity within the forecast consumption window. To use this option, users should also specify the demand time fence days, forecast consumption backward days, and forecast consumption forward days. + **Demand Time Fence Days** –The number of days between the current date and the demand time fence date. All forecasts on or before the demand time fence date will be ignored by the planning engine. + **Forecast Consumption Backward Days** –The number of days that the planning engine will go backward to find a matching forecast entry to consume starting from the due date of the sales order. + **Forecast Consumption Forward Days**– The number of days that the planning engine will go forward to find a matching forecast entry to consume starting from the due date of the sales order. + **Carry over unmet demand (backorders) in your planning?** – Select **Yes** to carry over the orders that are not fulfilled in the current time period to the next time period. + **Supply** – Define your supply related inputs. + **Past Due Orders** – When an order in the *InboundOrderLine* data entity is not delivered and the expected delivery date is before the execution date, by default, Supply Planning ignores this order. However, you can configure the number of past due days to be considered for inbound inventory to reorder stock. For example, if you set the *Past Due Orders* for 7 days and if an order was expected 4 days ago, the item will still be considered for inbound inventory. 1. Choose **Continue**. 1. Choose **Finish**. ## Overview You can view the overall supply plan for your organization, as shown in the following example page. ![\[Supply Planning Overview\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/supply_planning_overview.png) + **Supply Network** – Under supply network, you can view the current products, sites, and suppliers in the current supply plan. + **Inventory and Orders** – Displays the total inventory across sites, including inventory on-hand and the inventory that is currently on-order with the suppliers. + **Purchase Plan** – Displays the system-generated purchase order requests to replenish inventory at sites. + **Need Approval** – Supply Planning uses the approval criteria you set under **Settings** to flag purchase order requests for approval. + **Scheduled for Release** – Approved or auto-approved purchase order requests scheduled to be released to outbound connectors at the time you scheduled under **Settings**. + **Plan to Purchase Order Conversion** – Purchase order requests converted to POs in your ERP or purchasing systems. To calculate the accurate metrics, Purchase Order data coming from your source system must carry the reference back to the Purchase Order Request ID published to the outbound. This metric helps planners identify purchase order requests that are not converted to POs and take corrective actions. + **Purchase Order Automation Percentage** – Percentage of Purchase Order Requests that are auto-approved and released to outbound without user overrides to order quantity. + **Supply Insights** – You can view all the purchase orders that are currently in-progress or awaiting approval. You can choose each insight to view and take action on. For more information, see [Plan exceptions](#exceptions). You can download the supply plan report, which includes the inputs, intermediate calculations, and outputs for an auto-replenishment plan to your local computer. 1. On the Supply Planning **Overview** page, choose **Export**. The **Export Supply Plan** window appears. 1. Choose **Download**. ## Purchase order requests You can view current purchase order request details and status. 1. You can use the **Filters** option to filter your purchase orders according to your search criteria. Your can search purchase orders based on vendors, products, sites, order value, order quantity, and requested delivery date. 1. Choose **Apply** to apply your filter criteria to the current purchase orders, and choose **Save filter group** to save the search filter. ![\[Supply Planning purchase order requests\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/supply_planning_purchase_order.png) 1. Under **Order Quantity**, choose **Edit** to view and update the quantity. You can update the quantity based on the following inputs: + **On-Hand** – Inventory currently in-stock. + **On-Order** – Total product quantity of released purchase orders in the selected site. + **Reorder Quantity** – The product quantity required to meet the inventory. + **Required** – Reorder quantity required to meet the inventory and fulfill the forecast. + **Minimum** – Minimum order quantity defined under *VendorProduct.min\$1order\$1unit* in the dataset. Supply Planning rounds the number to meet the minimum quantity. + **Suggested** – Final reorder quantity after adjustment. + **Days of Cover** – Number of days to replenish. 1. Choose **Update** to update the quantity request. 1. Under **Product**, choose the product to view the planned demand for the product. ![\[Supply Planning edits\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/Edit_SP.png) 1. Under **Planned Demand**, select the site to view the replenishment plan. 1. The **Replenishment Plan** tab appears. **Note** The **Replenishment Plan** page will appear empty. Make sure to select the product and site to view the demand forecast. 1. Choose **Change Product/Site**. The **Choose a product and site combination** page appears. 1. Under **Product**, enter the product. 1. Under **Site**, enter the site. 1. Choose **Apply**. 1. Under **Enter order quantity**, you can update the suggested **Order Quantity**. 1. Choose **Update and Approve**. 1. Under **Actions**, choose **Approve** to approve a purchase order. 1. You can also use the **Show** dropdown to filter your purchase orders based on status and release time. ## Plan exceptions You can view the list of product-site combinations that could not be planned. The **Exception Type** column displays the root cause of the exemption. You can provide the missing information, such as inventory policy-related attributes or lead times through data connectors, or you can upload the updated dataset in Amazon S3. Under **Product**, you can choose multiple exceptions to delete or choose the **Product** header to delete all exceptions. Once selected, from the **Actions** drop-down, choose **Delete Exception(s)**. ## Supply planning settings You can define how and when you want to plan and execute purchase orders. 1. In the left navigation pane on the AWS Supply Chain dashboard, choose the **Settings** icon. Choose **Enterprise and Configuration**, and then choose **Supply Planning**. The **Plan Settings** page appears. 1. Follow the steps in [Using Supply Planning for the first time](#supply-planning-firsttime) to edit the Supply Planning configuration settings. 1. Under **Reset Plan**, choose **Reset Plan** to delete the existing plan and start a new supply plan. **Note** Only an administrator can reset a supply plan. The **Reset entire plan** page appears. 1. Choose **Yes, reset the plan** to delete the current supply plan and all the existing purchase orders requests. 1. Choose **Save**. # Business workflow Auto Replenishment provides the following workflow for you to manage your inventory replenishment process. ![\[Auto replenishment workflow to manage your inventory replenishment\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/business_workflow.png) + Generate replenishment plan – Supply Planning generates the replenishment plan according to the configured schedule. Recent input data required to generate replenishment plans is retrieved from the AWS Supply Chain data lake. Supply Planning uses configuration data, transactional data, and plan settings to generate the replenishment plan that includes purchase order requests. + Review plan exceptions – Supply Planning generates *Plan Exceptions* for products and site combinations that do not have either required configuration data (lead time, sourcing schedule, and so on) or required transactional data, such as on-hand inventory. Planners can review exceptions and provide required data before the next planning cycle in order to correct the issues and generate the replenishment plan. + Review and approve purchase order requests – Generated purchase order requests are either auto-approved or flagged for manual approval, depending on the configured approval criteria in the plan settings. Planners can review, override, or approve purchase order requests by using AWS Supply Chain. + Users can manually update the order quantity, order-by date, and expected delivery date for system-generated purchase order requests. Once updated, users can mark these orders as Firmed and rerun the plan in ad-hoc mode by choosing Run Plan in the top-right corner of the page. When the plan runs, the system preserves Firmed purchase order requests and recalculates all planning measures on the Replenishment Plan page. It then automatically synchronizes the updated planning data with the supply\$1plan entity in the Data Lake. The next scheduled plan run will clear Firmed purchase order requests and generate new ones based on current data. + Publish to outbound – Approved (auto or manual) purchase order requests are published to the outbound Amazon S3 at the configured schedule in Plan Settings. You can integrate these purchase order requests to your ERP or purchasing systems for execution. Purchase order requests that get converted to purchase orders are ingested back to the AWS Supply Chain data lake by using inbound connectors. AWS Supply Chain expects these purchase orders to carry the reference to the original purchase order request. This reference helps in tracking the conversion of purchase order requests to purchase orders.