# Supply Planning Supply Planning AWS Supply Chain supports two types of supply plans to help you accurately plan inventory to meet demand. **Note** You can only choose one supply plan per AWS Supply Chain instance to configure in AWS Supply Chain. To create multiple supply plans, you can create a new AWS Supply Chain instance under the same AWS account. + Auto Replenishment + Manufacturing Plan **Topics** + [ # Auto Replenishment ](auto-replenishment.md) + [ # Manufacturing Plans ](manufacturing_plans.md) + [ # Planning configuration data ](non-transactional.md) # 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. # Manufacturing Plans Manufacturing Plans helps you to determine production, transfer, and material requirements for multiple levels of sub-assemblies and components in a bill of material (BOM). Manufacturing Plans uses finished goods forecasts, BOMs, sourcing rules, on-hand inventory, on-order inventory, and lead times to determine net material, transfer, and production requirements. Manufacturing Plans propagates finished goods forecasts through the BOMs and applies sourcing rules to determine production, transfer, and material requirements. You can use this capability if you have in-house manufacturing or use outsourced manufacturers to make finished products or sub-assemblies. You can input plans to your purchasing systems to help create purchase orders for components with suppliers, production planning systems for detailed production scheduling and performance, and labor and production capacity planning systems to manage mid- to long-term capacities. Material plans (also called component forecasts) can also be shared with your contract manufacturers or with component suppliers through N-Tier Visibility. By sharing or publishing the Material Plans, you can provide better demand signals to upstream suppliers so that they can plan their inventory to meet future demand. By using N-Tier Visibility, suppliers can provide commitments on component forecasts back to you. For information on N-Tier Visibility, see [N-Tier Visibility](partner.md). # Key inputs Manufacturing Plans depends on various inputs to make accurate and informed calculations for generating material, transfer, and production plans. Manufacturing Plans uses the same list of inputs as Auto Replenishment for inventory target calculation and net requirements determination for a product or site combination. For information on Auto Replenishment inputs, see [Key inputs](key-input.md). In addition, Manufacturing Plans also requires the following inputs: + **Bill of Material (BOM)** – The BOM data entity is used to capture relationships between finished goods and various sub-assemblies and components that are required to make the finished goods. BOMs can contain multiple levels of components under a finished good, including alternates. Alternate or substitute components can be modeled under the same parent by using the *alternate\$1group* field. AWS Supply Chain only supports priority-based alternates. Components with the lowest priority are selected by the planning process. Suppliers or vendors that supply components are not part of the BOM. This information is derived from sourcing rules and vendor management-related data entities. + **Production process** – This process is used to model the production step for manufacturing finished goods. The sourcing rule contains a reference to the production process that's used to support the *Manufacture* type of rule. AWS Supply Chain only supports a single step manufacturing process. The component requirement date is determined based on production lead time and setup time, as defined in the production process entity. Lead time is the offset from the finished goods demand date, which is used to determine the requirement date for components. For information on data fields required for Supply Planning, see [Supply Planning](entities-supply-planning.md). # Planning process Manufacturing Plans include material, transfer, and production plans. These plans are created based on the configured network topology for an item. The following illustration shows the steps involved in generating these plans. These steps are repeated for each product or site combination that is in the scope of a Manufacturing Plan. ![\[Manufacturing Plan process\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/manufacturing_plan_process.png) The steps and logic for Demand Processing, Inventory Target calculation, and Net Requirements calculation are common between Manufacturing Plans and Auto Replenishment. For more information, see [Planning process](planning-process.md) and [Inventory policies](inventory-policies.md). + **Production requirements** – For products with site combinations with sourcing rule type *Manufacture*, Supply Planning uses the production process referenced in the sourcing rule to calculate production requirements. Make type should be used for finished goods or sub-assemblies that go through a production process. Lead times and setup times from the *production\$1process* data entity, along with the BOM, is used to determine the material or component requirements. Supply Planning also applies the frozen horizon defined in the production process or the default setting to freeze supply during this time period and move all requirements to the first time period after the frozen time horizon. + **BOM explosion** – For products or sites with sourcing rules of type *Manufacture*, Supply Planning uses the BOM defined in the *product\$1bom* entity to determine production requirements for sub-assemblies and material requirements for component items. Supply Planning traverses the tree structure defined in the BOM for the finished good or sub-assembly item. If there are multiple components for a parent item with the same alternate group, Supply Planning prioritizes one of the component items that belong to the same alternate group. Component material requirements are calculated from the start date until the end date of the planning horizon, as defined in the planning settings. After component requirements are determined, Supply Planning applies Demand Processing and Target Inventory level calculation steps to determine net component requirements by considering inventory policy, lead times, and on-hand and on-order inventories. # Configuring Manufacturing Plans Configure Manufacturing Plans to generate material, transfer, and production requirements for components and finished good items. ## Using Supply Planning for the first time You can define how and when you want to plan your supply chain. 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. **Note** Make sure that the required data is ingested before configuring Manufacturing Plans. For information on the data fields required for Supply Planning, see [Supply Planning](entities-supply-planning.md). 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 **Manufacturing Plans**. 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 get to the **Supply Planning Set-up** page. 1. On the **Material Plan Changes** page, you can view all the material plans that deviated from the predefined supply plan. Under **Supply Insights**, you can search for a particular material plan in the **Search** box, by **Required Date** and **Insight Type**. You can also choose a particular material plan to view more details. 1. Choose **Get Started**. 1. On the **Supply Planning Set-up** page, there are four steps to configure Manufacturing Plans: + Name and Scope + Horizon and Schedule + Inputs + Output 1. On the **Name and Scope** page, under **Plan Name**, enter a name for your plan. Under **Supply Planning Scope**, select all the product groups and regions that must be included in the supply plan. **Note** If you do not see the Product Groups or Regions that you ingested through Supply Chain data lake, ingest the Product BOM through the API and make sure that all the other datasets, such as Product, ProductHierarchy, Site, Geography, and SourcingRule, are already ingested. 1. Choose **Continue**. 1. On the **Horizon and Schedule** page, 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 demand forecast for Supply Planning. + *Demand Planning* – Supply Planning will use the forecast information from the demand plan generated from *Demand Planning *. + *External* – Supply Planning with use the *Forecast* data entity to extract the demand forecasts for Supply Planning. + **Past days for average demand calculation in consumption-based planning** – For each product-site combination, Supply Planning looks at the past 30 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 ** – 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**– 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. On the **Output** page, you can do the following: + **Plan Outputs** – Select the type of supply plan that you want Supply Planning to generate. + **Plan Insights** – Set the deviation criteria to generate supply plan insights. 1. Choose **Finish**. 1. (Optional) Choose **Invite Partners** to invite suppliers into your supply plan. You can also choose **Skip for now** to return to Supply Planning. ## Plan overview You can view the overall manufacturing plan for your organization. 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 **Manufacturing Plan**. The **Manufacturing Plan** page appears. 1. Choose **Export** to download the *Material Plans*, *Production Plans*, or *Transfer Plans* to your Amazon S3 bucket. 1. Choose the **Plan Overview** tab. ![\[Manufacturing Plan overview\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/manufacturing_plan_overview.png) + **Plan Summary** – Displays the overall manufacturing plan. **Note** Plan Summary metrics will not be available for new users. You can view the Plan Summary metrics after the next supply planning cycle. + **Inventory On-hand** – Displays the current inventory on-hand in dollars. + **Open POs** – Displays the current open purchase orders and the required dollars. + **Suppliers** – Displays the total number of active suppliers. + **Purchase Requirements** – Displays the total quantity of end components required and their total cost. + **Plan Exceptions** – Displays exceptions for missing datasets or issues in any of the data entities. + **Supply Insights** – Supply Insights are only generated for all Material Plan changes end components when they satisfy the deviation percent change compared with the previous plan. You can select each insight to view it and take action it. You can use the **Search** box to search based on *Product Name* or *Site Name*, or you can search for specific supply insights by using the **Required Date Start** and **Required Date End**. ## Plan outputs You can view the overall manufacturing plan for your organization. 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 **Manufacturing Plans**. The **Manufacturing Plan** page appears. 1. Choose the **Plan Outputs** tab. Choose **Filters** to filter the list based on Products or Sites. ![\[Manufacturing Plan outputs\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/manufacturing_plan_outputs.png) + **Material Plan** – Displays the overall material plan for end components from the supply plan generated. + **Transfer Plan** – Displays the overall transfer plan for any materials or finished goods between sites from the supply plan generated. + **Production Plan** – Displays the overall production plan for finished goods from the supply plan generated. 1. Under **Material Plan** and **Material Requirements**, you can view the supply details for each item. 1. Under **Item**, choose the **Supply Plan Details** for the selected item. The **Supply Plan Details** page appears. ![\[Viewing the supply Plan details\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/supply_plan_details.png) The **Supply Plan Details** section displays item details and attributes. Choose **View all attributes** to view all the attributes of an item. Under **Supply Plan**, you can view the supply plan for the selected item. You can view the supply plan for a specific date range by using **Start Date** and **End Date**. + Demand Forecast – Displays the demand forecast or dependent demand related to an item or site. + Inventory – Displays the on-hand inventory level related to an item or site. + Open Order – Displays open order quantities based on the *expected\$1delivery\$1date* for an item or site. Supported order types are Purchase order, Transfer order, or Manufacturing order. + Inventory Target – Target inventory level calculated based on the inventory policy and order schedule. For more information, see [Inventory policies](inventory-policies.md). + Planned Supply – Displays the planned supply. + Total Supply – The sum of open orders and planned supply. + Projected Ending on Hand – The projected order ending on hand. Projected Ending On Hand (EOH) is calculated based on Demand, Supply, and Inventory. EOH(T0) = Inventory(T0) \$1 Open Orders(T0) \$1 Planned Supply(T0) - Demand Forecast(T0) EOH(T1) = EOH(T0) \$1 Open Orders(T1) \$1 Planned Supply(T1) - Demand Forecast(T1). 1. You can also view the overall Supply Planning for an item: + Material Plan – Displays the material plan related to an item or site. + Transfer Plan – Displays the transfer plan related to an item or site. + Production Plan – Displays the production plan related to an item or site. + Purchase Orders – Displays the input purchase orders used in generating the supply plan. + Transfer Orders – Displays the input transfer orders used in generating the supply plan. + Production Orders – Displays the input production orders used in generating the supply plan. ## Plan exceptions You can view the overall manufacturing exceptions for your organization. 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 **Manufacturing Plans**. The **Manufacturing Plans** page appears. 1. Choose the **Plan Exceptions** tab. You can use the **Filters** icon to filter exceptions based on Product and Site. Choose **View all** to view all the available filters. ## Importing product\$1bom data To import *product\$1bom* data using the AWS CLI, follow the procedure below: **Note** You can only use AWS CLI to import *product\$1bom* data into AWS Supply Chain. 1. Make a note of your instance ID where you want to import your *product\$1bom* data. Your *URI* format for your supply chain data bucket will be **"s3://aws-supply-chain-data-*INSTANCE\$1ID*/product\$1bom.csv"**. 1. Use the following command to upload your *product\$1bom* data to the Amazon S3 instance bucket. **aws s3 cp *Path To Local Product BOM CSV*\$1S3\$1BOM\$1URI** **"s3://aws-supply-chain-data-*INSTANCE\$1ID*/product\$1bom.csv"**. 1. Use the following command to invoke the *create bill of materials* import job. **aws supplychain create-bill-of-materials-import-job --instance-id \$1*INSTANCE\$1ID* --s3uri** **"s3://aws-supply-chain-data-*INSTANCE\$1ID*/product\$1bom.csv"** **Note** Make sure to use the same destination Amazon S3 URI that you used when uploading the CSV in step 2. 1. Make a note of the *job ID* returned. 1. Use the following command to view the imported result. **aws supplychain get-bill-of-materials-import-job --instance-id \$1*INSTANCE\$1ID* --job-id *job-id from step 4* ** For more information on AWS Supply Chain API see the [AWS Supply Chain API Reference](https://docs.aws.amazon.com/aws-supply-chain/latest/APIReference/API_CreateBillOfMaterialsImportJob.html). # Business workflow Supply Planning provides the following workflow to manage your manufacturing plans. ![\[Manufacturing Plan business workflow\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/manufacturing_business_workflow.png) + **Generate plan** – Supply Planning generates the manufacturing plan according to the configured schedule. The latest input data required to generate the plan is received from the AWS Supply Chain data lake. Supply Planning uses configuration data, transactional data, and plan settings to generate the manufacturing plan, which includes material, transfer, and production plans. The Manufacturing Plan is generated for the configured planning horizon in terms of the number of time periods. You can create plans with either daily or weekly details, and you can create them on a daily or weekly frequency. If multiple plans are created within the same planning cycle (daily or weekly), new plans will override the existing plans. Existing plans are versioned after a new plan is generated at the beginning of a new planning cycle (for example, a new week). + **Review plan exceptions** – Supply Planning generates plan exceptions for products or 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, and then they can rerun the plan to correct the issues and generate the supply plan for relevant product and site combinations. + **Review manufacturing plan** – Supply planners can review and manage material, transfer, and production plans by navigating to the **Plan Overview**, **Plan Outputs**, **Supply Plan Details**, and **Supply Demand Pegging ** tabs in the AWS Supply Chain web application. The Supply Planning module generates *Material Plan Change* insights for products and sites where the required quantity deviation exceeds the configured threshold, relative to the most recent plan. Planners can configure the display of detailed inputs, such as forecasts, inventory levels, orders, and other relevant data that contribute to the calculation of the plan's output. + The **Supply Plan Details** page offers a comprehensive timeline view, displaying key metrics such as forecast, inventory, open orders, and planned supply. This allows planners to assess and adjust plans as needed. + The **Supply Demand Pegging** page provides a detailed list of all pegging records that link supply orders to their corresponding demand orders. Each pegging record includes information about the supply order (for example, on-hand inventory, purchase orders, planned purchase orders, planned manufacture orders, and planned transfer orders), the demand order (for example, sales orders, forecasted demands, and planned order demands), the pegged quantity, and the associated end demand. This view enables users to analyze how specific supply quantities are allocated to fulfill various demand orders, and vice versa. Users can interact with the data by selecting any demand quantity to view all supply orders linked to it or selecting any supply quantity to see all demand orders tied to that supply. From this view, users can also navigate to the **End Demand Pegging** page by clicking the **End Demand Product** for a more consolidated overview of a specific end demand. + The **End Demand Pegging** page provides a comprehensive view of the entire pegging tree for a specific end demand, such as a sales order or forecast. It offers full visibility into all related supply and demand orders associated with the end demand, including planned transfer orders, planned manufacture orders, purchase orders, and intermediate demands. This view allows users to trace the entire supply chain flow, from the top-level demand to every linked supply and dependent demand orders, offering a clear insight into how supply orders are structured to meet customer or forecasted needs. These views help users efficiently manage and track supply and demand allocation across the supply chain. + **Planned order adjustments** – Users can manually update the order quantity, order-by date, and expected delivery date for system-generated planned orders, including Planned Purchase Orders, Planned Transfer Orders, and Planned Production Orders. After making updates, users can mark these orders as **Firmed** to ensure they are preserved during planning runs. To run the plan in ad-hoc mode, users can choose **Run Plan** located in the top-right corner of the page. When the plan runs, the system retains all Firmed planned orders, recalculates planning measures on the **Supply Plan Details** page, and reflects any changes in upstream sites or bill of material (BOM) components in the updated plan output. In addition to modifying existing planned orders, users can create new Planned Transfer Orders directly from the **Transfer Plan** page by selecting **Create New Transfer Order** from the **Action** menu. After the ad-hoc plan run is complete, the system automatically synchronizes the updated planning data with the `supply_plan` and `supply_demand_pegging` entities in the Data Lake. During the next scheduled planning run, the system will clear all previously Firmed planned orders and generate new ones based on the latest data inputs. + **Publish to outbound** – Supply plans are published to the outbound Amazon S3 connector at the configured time scheduled under *Plan Settings*. You can integrate these plans into your ERP, purchasing, or production planning systems for execution. + **Publish to N-Tier visibility** – Material plans can optionally be published to the suppliers through N-Tier visibility. Material plans are published to N-Tier visibility based on the schedule that's configured under *Plan Settings*. N-Tier visibility further publishes the material plan to onboarded suppliers based on collaboration settings. # Planning configuration data This section lists all the required fields used by Supply Planning and describes how each field is used. For information on data fields required for Supply Planning, see [Supply Planning](entities-supply-planning.md). **Topics** + [ ## Product ](#product) + [ ## Site ](#site) + [ ## Trading partner ](#trading-partners) + [ ## Vendor product ](#vendor-product) + [ ## Vendor lead time ](#vendor-leadtime) + [ ## Sourcing rule ](#sourcing-rule) + [ ## Inventory policy ](#inventory-policy) + [ ## Sourcing schedule ](#sourcing-schedule) + [ ## Bill of Material (BOM) ](#product-bom) + [ ## Production process ](#production-process) + [ ## Supply planning parameters ](#production-process2) + [ # Transactional data ](transactional.md) ## Product The product entity defines the list of items or products that must be included in the planning. The purchase order requests use *unit\$1cost field* from the *Product* entity to determine the order value or amount. The *Product* entity also contains the product group corresponding to a specific product, which is a foreign key into a *product\$1hierarchy* entity. Product groups can be used in configuring inventory policies, sourcing schedules, lead times, and so on, at the aggregate level. ## Site The *Site* entity defines the list of sites or locations that must be included in the planning. The *Site* entity also contains Regions corresponding to a specific site, which is a foreign key into a Geography entity. Regions can be used in configuring inventory policies, sourcing schedules, lead times, and so on, at the aggregate level. ## Trading partner The *Trading\$1partner* entity defines the list of suppliers. *tpartner\$1type* should be set to *Vendor* when uploading supplier information. ## Vendor product Products supplied by each supplier are defined in the *vendor\$1product* entity. This entity also contains vendor-specific cost information. ## Vendor lead time Vendor lead time is the time period between placing an order to a vendor and receiving the order. This data is defined in the *VendorMgmt* category under the *vendor\$1lead\$1time* data entity. Vendor lead time follows the following override logic: + Product level vendor lead time overrides product group level vendor lead time. + Site level vendor lead time overrides region level vendor lead time. + Region level vendor lead time overrides company level vendor lead time. To look for a record, Supply Planning uses the following fields: + company\$1id + region\$1id + site\$1id + product\$1group\$1id + product\$1id The following is an example of the override logic: ![\[Override logic example\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/override_logic.png) The following is an example of how Supply Planning calculates vendor lead time: ![\[Vendor lead time calculation\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/vendor_lead_time.png) Prioritization order is *product* > *product\$1group* > *site* > *dest\$1geo (region)* > *product segment* > *company*. ## Sourcing rule Supply Planning generates a plan based on the supply chain network topology defined under the *sourcing\$1rules* entity. The supported sourcing rule types are transfer, buy, and manufacture. Sourcing rules follow the *product\$1id* > *product\$1group\$1id* > *company\$1id* override logic. Supply Planning retrieves the transportation lead time by referencing *transportation\$1lane\$1id* and accessing *transit\$1time* in *transportation\$1lane*. There are two steps to retrieve the transfer lead time. 1. Find *transportation\$1lane\$1id* in *sourcing\$1rules*. Only the sourcing rules that have both *to\$1site\$1id* and *from\$1site\$1id* are eligible for retrieving *transfer\$1lead\$1time*. 1. Use *transportation\$1lane\$1id* to look up *transportation\$1lane*. When there are multiple records with the same *to\$1site\$1id* and *product\$1id* (*product\$1group\$1id*) in the *sourcing\$1rule* entity, only the records with the highest priority (the smallest number) will be used. Sourcing rules example: Based on the preceding definition, Supply Planning selects the following sourcing rule SR1: Laptop at site `TX0` is sourced from site `IL0` via `transportation_lane_9`. | sourcing\$1rule\$1id | product\$1id | product\$1group\$1id | sourcing\$1rule\$1type | from\$1site\$1id | to\$1site\$1id | sourcing\$1priority | transportation\$1lane\$1id | | --- | --- | --- | --- | --- | --- | --- | --- | | SR1 | laptop | electronics | transfer | IL0 | TX0 | 1 | transportation\$1lane\$19 | | SR2 | laptop | electronics | transfer | NJ1 | TX0 | 2 | transportation\$1lane\$121 | | SR3 | laptop | electronics | transfer | IL0 | TX0 | 1 | transportation\$1lane\$111 | When multiple records with the same priority exist for the same combination of *to\$1site\$1id*, *product\$1id* (or *product\$1group\$1id*), the reorder quantity will be distributed among the available sourcing options based on the *sourcing\$1ratio* field. Note that multiple sourcing is currently only supported for the `buy` sourcing rule type. Multi-sourcing example: | sourcing\$1rule\$1id | product\$1id | product\$1group\$1id | sourcing\$1rule\$1type | tpartner\$1id | to\$1site\$1id | sourcing\$1priority | sourcing\$1ratio | | --- | --- | --- | --- | --- | --- | --- | --- | | SR1 | laptop | electronics | buy | supplier1 | TX0 | 1 | 4 | | SR2 | laptop | electronics | buy | supplier2 | TX0 | 1 | 6 | Both sourcing rules, SR1 and SR2, are selected, and the order quantity will be allocated between Supplier 1 and Supplier 2 in a 4:6 ratio. ## Inventory policy Supply Planning searches for a record in the dataset by using the following fields: + *site\$1id* + *geodesic* + *company\$1id* + *product\$1id* + *product\$1group\$1id* + *segment\$1id* Supply Planning uses *ss\$1policy* to determine the inventory policy. The override logic uses the following priority: *product\$1id* > *product\$1group\$1id* > *site\$1id* > ** and *dest\$1geo\$1id* > *segment\$1id* > *company\$1id*. The supported *ss\$1policy* values are *abs\$1level*, *doc\$1dem*, *doc\$1fcst*, and *sl*. The following example displays the override priority logic. ![\[Override logic\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/override1.png) The following is an example of the *ss\$1policy* value based on the override logic. ![\[Override ride logic example for ss_policy value\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/override2.png) ## Sourcing schedule **Note** Sourcing schedule is an optional entity. If this entity is not provided, Supply Planning uses a continuous review process to generate *required\$1date* based on when products are needed. Supply Planning uses sourcing schedule to generate purchase plans by using the following steps: + Find *sourcing\$1schedule\$1id* in *sourcing\$1schedule*. + Find the schedule by *using sourcing\$1schedule\$1id* in *sourcing\$1schedule\$1details*. Supply Planning searches for the following fields in *sourcing\$1schedule\$1id* under *sourcing\$1schedule*. + *to\$1site\$1id* + *tpartner\$1id* or *from\$1site\$1id* Based on the sourcing path in sourcing rules, Supply Planning determines whether to use* from\$1site\$1id* or *tpartner\$1id*. Supply Planning reads the value in the *sourcing\$1schedule\$1id* field to determine the next step. Supply Planning reads the schedule details under *sourcing\$1schedule\$1details* with the following fields: + *sourcing\$1schedule\$1id* + *company\$1id* + *product\$1group\$1id* + *product\$1id* *sourcing\$1schedule\$1details* follows the override logic, *product\$1id* > *product\$1group\$1id* > *company\$1id*. The following is an example of the override logic in *sourcing\$1schedule\$1details*. ![\[Sourcing schedule override logic\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/sourcing_schedule2.png) The following are the selected schedules after applying the override logic. ![\[Sourcing schedule override logic\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/sourcing_schedule3.png) The actual schedule can be from one row to multiple rows, based on the complexity of the schedule. For the field *week\$1of\$1month*, only one number is allowed in each row. For multiple weeks of the month, multiple records are required (see the following example). For the field *day\$1of\$1week*, both integer and name of day are allowed (Sun: 0, Mon: 1, Tue: 2, Wed: 3, Thu: 4, Fri: 5, Sat: 6). In the sourcing schedule details, weekly planning requires *week\$1of\$1month*. While in daily planning, *week\$1of\$1month* can be empty, which means every week. See the following examples. ![\[Sourcing schedule override logic\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/sourcing_schedule4.png) Note that for weekly planning, *week\$1of\$1month* is required if *day\$1of\$1week* is provided. The following example shows the dates that can be used for daily planning. | Date | Day of the week | Week of the month | | --- | --- | --- | | 8/1/2023 | NA | NA | | 8/12/2023 | NA | NA | | NA | 2 | NA | | NA | 5 | NA | The following example can be used for both daily and weekly planning. | Date | Day of the week | Week of the month | | --- | --- | --- | | 8/1/2023 | NA | NA | | 8/12/2023 | NA | NA | | NA | 2 | 1 | | NA | 2 | 2 | | NA | 2 | 3 | | NA | 2 | 4 | | NA | 2 | 5 | | NA | 5 | 1 | | NA | 5 | 2 | | NA | 5 | 3 | | NA | 5 | 4 | | NA | 5 | 5 | ## Bill of Material (BOM) Product BOM is used in Manufacturing Plans when *sourcing\$1rule* is set to Manufacture. For information on how to ingest Product BOM, see the AWS Supply Chain API Reference document. ## Production process *production\$1process\$1id* is referenced in the *sourcing\$1rule* and *product\$1bom* entities. These fields are used to consume lead time information to make or assemble a BOM. ## Supply planning parameters In *supply\$1planning\$1parameters* entity, *planner\$1name* of the supply planner can be assigned at *product\$1id* level. Planner name will be displayed on the planned orders generated by the supply planning engine. # Transactional data **Topics** + [ ## Forecast ](#forecast) + [ ## Sales history or demand ](#demand) + [ ## Inventory level ](#inventory-level) + [ ## Inbound orders ](#in-flight-orders) ## Forecast Supply Planning uses two different sources and types of forecast. You can use the following source systems to retrieve forecast source: + *External* – Supply Planning uses the data that is being ingested into the data lake forecast entity. + *Demand Planning* – Supply Planning uses the forecasts from Demand Planning. + *None* – Supply Planning uses the sales or demand history data from the outbound order line. Supply Planning supports two types of forecast: deterministic and stochastic. Deterministic forecasts contain only the mean of the forecast. Stochastic forecasts contain P10/P50/P90, sometimes along with mean. When mean is not provided with stochastic forecasts, Supply Planning uses P50(median) as mean. Each forecast record has four fields to represent the demand forecast: + mean(double) + p10(double) + p50(also known as median, double) + p90(double) Based on the configured inventory policy, different fields in this entity are required. For *sl*, p10/p50/90 is required; for *doc\$1fcst*, policy p50 or mean is required. Supply Planning uses p50 as an approximation of the mean, and for *doc\$1dem* and *abs\$1level*, none of the forecast fields are required. **Daily planning** Forecasts may be different for daily planning compared to weekly planning. Here is an example of the daily and weekly planning forecast requirement. ![\[Daily planning\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/daily-planning.png) **Weekly planning** You can use the daily planning forecast example for weekly planning, or you can also use the following example for weekly planning. ![\[Weekly planning\]](http://docs.aws.amazon.com/aws-supply-chain/latest/userguide/images/weekly-planning.png) ## Sales history or demand Inventory policy *doc\$1dem* requires demand history to compute the historical average demand. Supply Planning gets the demand history from the *outbound\$1order\$1line* entity under the *Outbound* category. Supply Planning uses the following fields: + *ship\$1from\$1site\$1id*(string) + *product\$1id*(string) + *actual\$1delivery\$1date*(timestamp); when missing, use *promised\$1delivery\$1date*(timestamp) As part of the calculation, Supply Planning uses historical outbound order lines with delivery dates in the past 30 days. The target field used for quantity is *quantity\$1delivered*; when missing, use *quantity\$1promised*. If *quantity\$1promised* is missing, then *final\$1quantity\$1requested* will be used. If all are missing, then *0* will be used. For example, if you use Supply Planning for product “laptop” at site “TX0” on July 1, 2023, the record in *outbound\$1order\$1line* where *product\$1id=laptop*, *ship\$1from\$1site\$1id=TX0*, and *actual\$1delivery\$1date* is from June 1, 2023 to June 30, 2023. Supply Planning adds all the records and divides by 30 days to get the daily demand. ## Inventory level Supply Planning requires a beginning inventory level to start the planning process. Supply Planning searches for the inventory level under the *entity inv\$1level* data entity. Supply Planning searches for a record with the following fields: + *product\$1id* + *site\$1id* Supply Planning uses *on\$1hand\$1inventory* to determine the inventory level. ## Inbound orders Supply Planning uses *inbound\$1order\$1line* to retrieve the in-flight order quantity. If an order is delivered during the planning horizon, the quantity is considered as part of the existing supply. Supply Planning searches for a record under *inbound\$1order\$1line* with the following fields: + *order\$1receive\$1date*; when missing, use *expected\$1delivery\$1date* + *product\$1id* + *to\$1site\$1id* The following are the supported Order Types: PO (Purchase), TO (Transfer), and MO (Production or Manufacturing). Supply Planning uses the *quantity\$1received*; when missing, use *quantity\$1confirmed* then *quantity\$1submitted* to determine the on-order quantity.