# 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.