As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Dados de configuração de planejamento
Esta seção lista todos os campos obrigatórios usados pelo Planejamento de Suprimentos e descreve como cada campo é usado. Para obter informações sobre os campos de dados necessários para o Planejamento de Suprimentos, consulte[Planejamento de suprimentos](entities-supply-planning.md).
**Topics**
+ [Produto](#product)
+ [Site](#site)
+ [Parceiro comercial](#trading-partners)
+ [Produto do fornecedor](#vendor-product)
+ [Prazo de entrega do fornecedor](#vendor-leadtime)
+ [Regra de fornecimento](#sourcing-rule)
+ [Política de inventário](#inventory-policy)
+ [Cronograma de fornecimento](#sourcing-schedule)
+ [Lista de materiais (BOM)](#product-bom)
+ [Processo de produção](#production-process)
+ [Parâmetros de planejamento de suprimentos](#production-process2)
+ [Dados transacionais](transactional.md)
## Produto
A entidade do produto define a lista de itens ou produtos que devem ser incluídos no planejamento. As solicitações de pedido de compra usam o *campo unit\$1cost* da entidade *Produto* para determinar o valor ou o valor do pedido. A entidade *Product* também contém o grupo de produtos correspondente a um produto específico, que é uma chave estrangeira em uma entidade *product\$1hierarchy*. Os grupos de produtos podem ser usados na configuração de políticas de inventário, cronogramas de fornecimento, prazos de entrega e assim por diante, no nível agregado.
## Site
A entidade *Site* define a lista de sites ou localizações que devem ser incluídas no planejamento. A entidade *Site* também contém Regiões correspondentes a um site específico, que é uma chave estrangeira para uma entidade Geográfica. As regiões podem ser usadas na configuração de políticas de inventário, cronogramas de fornecimento, prazos de entrega e assim por diante, no nível agregado.
## Parceiro comercial
A entidade *Trading\$1partner* define a lista de fornecedores. *tpartner\$1type* deve ser definido como *Fornecedor ao fazer o upload das informações do fornecedor*.
## Produto do fornecedor
Os produtos fornecidos por cada fornecedor são definidos na entidade *vendor\$1product*. Essa entidade também contém informações de custo específicas do fornecedor.
## Prazo de entrega do fornecedor
O lead time do fornecedor é o período entre fazer um pedido a um fornecedor e receber o pedido. Esses dados são definidos na *VendorMgmt*categoria sob a entidade de dados *vendor\$1lead\$1time*. O lead time do fornecedor segue a seguinte lógica de substituição:
+ O lead time do fornecedor no nível do produto substitui o lead time do fornecedor no nível do grupo de produtos.
+ O lead time do fornecedor no nível do site substitui o lead time do fornecedor no nível da região.
+ O lead time do fornecedor no nível da região substitui o lead time do fornecedor no nível da empresa.
Para procurar um registro, o Planejamento de Suprimentos usa os seguintes campos:
+ company\$1id
+ region\$1id
+ site\$1id
+ product\$1group\$1id
+ product\$1id
Veja a seguir um exemplo da lógica de substituição:
![\[Exemplo de lógica de substituição\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/override_logic.png)
Veja a seguir um exemplo de como o Planejamento de Suprimentos calcula o lead time do fornecedor:
![\[Cálculo do lead time do fornecedor\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/vendor_lead_time.png)
**A ordem de priorização é *produto > *grupo\$1produto** > *site* > *dest\$1geo (região)* > segmento de produto > empresa.**
## Regra de fornecimento
O Planejamento de Suprimentos gera um plano com base na topologia da rede da cadeia de suprimentos definida na entidade *sourcing\$1rules*.
Os tipos de regras de fornecimento compatíveis são transferência, compra e fabricação.
*As regras de fornecimento seguem a lógica de substituição product\$1id > *product\$1group\$1id* *> company\$1id*.*
**O Supply Planning recupera o lead time de transporte referenciando *transportation\$1lane\$1id e acessando transit\$1time em transportation\$1lane*.** Há duas etapas para recuperar o lead time de transferência.
1. *Encontre *transportation\$1lane\$1id em sourcing\$1rules*.* *Somente as regras de fornecimento que têm *to\$1site\$1id e *from\$1site\$1id* estão qualificadas para recuperar transfer\$1lead\$1time*.*
1. *Use *transportation\$1lane\$1id para pesquisar transportation\$1lane*.*
Quando houver vários registros com o mesmo *to\$1site\$1id e product\$1id* *(product\$1group\$1id**) na entidade sourcing\$1rule**, somente os registros com a maior prioridade* (o menor número) serão usados.
Exemplo de regras de fornecimento:
Com base na definição anterior, o Supply Planning seleciona a seguinte regra de fornecimento SR1: O laptop no local `TX0` é originado do site via. `IL0` `transportation_lane_9`
| sourcing\$1rule\$1id | product\$1id | product\$1group\$1id | sourcing\$1rule\$1type | from\$1site\$1id | to\$1site\$1id | prioridade\$1de fornecimento | transportation\$1lane\$1id |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SR1 | laptop | eletrônicos | transferência | IL0 | TX0 | 1 | transportation\$1lane\$19 |
| SR2 | laptop | eletrônicos | transferência | NJ1 | TX0 | 2 | transportation\$1lane\$121 |
| SR3 | laptop | eletrônicos | transferência | IL0 | TX0 | 1 | transportation\$1lane\$111 |
*Quando existirem vários registros com a mesma prioridade para a mesma combinação de *to\$1site\$1id, product\$1id (ou *product\$1group\$1id***), a quantidade de reposição será distribuída entre as opções de fornecimento disponíveis com base no campo sourcing\$1ratio*.* Observe que o fornecimento múltiplo atualmente só é suportado para o tipo de regra `buy` de fornecimento.
Exemplo de fornecimento múltiplo:
| sourcing\$1rule\$1id | product\$1id | product\$1group\$1id | sourcing\$1rule\$1type | tpartner\$1id | to\$1site\$1id | prioridade\$1de fornecimento | sourcing\$1ratio |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SR1 | laptop | eletrônicos | comprar | fornecedor1 | TX0 | 1 | 4 |
| SR2 | laptop | eletrônicos | comprar | fornecedor2 | TX0 | 1 | 6 |
Ambas as regras de fornecimento SR1 e SR2, são selecionadas, e a quantidade do pedido será alocada entre o Fornecedor 1 e o Fornecedor 2 em uma proporção de 4:6.
## Política de inventário
O Supply Planning pesquisa um registro no conjunto de dados usando os seguintes campos:
+ *ID do site*
+ *geodésico*
+ *identificação\$1empresa*
+ *id\$1de\$1produto*
+ *ID do grupo\$1produto*
+ *id\$1de\$1segmento*
O Planejamento de Suprimentos usa *ss\$1policy para determinar a política* de inventário. ***A lógica de substituição usa a seguinte prioridade: *product\$1id > product\$1group\$1id > *site\$1id** *> e dest\$1geo\$1id > segment\$1id > company\$1id*. *****
**Os valores *ss\$1policy* suportados são *abs\$1level, doc\$1dem**, doc\$1fcst* e sl.**
O exemplo a seguir exibe a lógica de prioridade de substituição.
![\[Substituir lógica\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/override1.png)
Veja a seguir um exemplo do valor *ss\$1policy* com base na lógica de substituição.
![\[Exemplo de lógica de passeio de substituição para o valor ss_policy\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/override2.png)
## Cronograma de fornecimento
**nota**
O cronograma de fornecimento é uma entidade opcional. Se essa entidade não for fornecida, o Planejamento de Suprimentos usa um processo de revisão contínua para gerar a *data\$1necessária* com base em quando os produtos são necessários.
O Supply Planning usa o cronograma de fornecimento para gerar planos de compra usando as seguintes etapas:
+ *Encontre *sourcing\$1schedule\$1id em sourcing\$1schedule*.*
+ *Encontre a programação *usando sourcing\$1schedule\$1id em sourcing\$1schedule\$1details*.*
*O Supply Planning pesquisa os seguintes campos em *sourcing\$1schedule\$1id em sourcing\$1schedule*.*
+ *to\$1site\$1id*
+ **tpartner\$1id ou from\$1site\$1id**
*Com base no caminho de fornecimento nas regras de fornecimento, o Planejamento de Suprimento determina se você deve usar *from\$1site\$1id ou tpartner\$1id*.* O Supply Planning lê o valor no campo *sourcing\$1schedule\$1id* para determinar a próxima etapa.
O Planejamento de Suprimentos lê os detalhes do cronograma em *sourcing\$1schedule\$1details* com os seguintes campos:
+ *sourcing\$1schedule\$1id*
+ *identificação\$1empresa*
+ *ID do grupo\$1produto*
+ *id\$1de\$1produto*
*sourcing\$1schedule\$1details segue a lógica de substituição, product\$1id > product\$1group\$1id* ***> company\$1id.***
Veja a seguir um exemplo da lógica de substituição em *sourcing\$1schedule\$1details*.
![\[Lógica de substituição do cronograma de fornecimento\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/sourcing_schedule2.png)
A seguir estão as programações selecionadas após a aplicação da lógica de substituição.
![\[Lógica de substituição do cronograma de fornecimento\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/sourcing_schedule3.png)
O cronograma real pode ser de uma linha a várias linhas, com base na complexidade do cronograma. Para o campo *week\$1of\$1month*, somente um número é permitido em cada linha. Durante várias semanas do mês, vários registros são necessários (veja o exemplo a seguir). Para o campo *day\$1of\$1week*, tanto o número inteiro quanto o nome do dia são permitidos (dom: 0, seg: 1, ter: 2, qua: 3, qui: 4, sex: 5, sáb: 6). Nos detalhes do cronograma de fornecimento, o planejamento semanal exige uma *semana\$1do\$1mês*. No planejamento diário, *week\$1of\$1month* pode estar vazio, o que significa toda semana. Veja os exemplos de a seguir.
![\[Lógica de substituição do cronograma de fornecimento\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/sourcing_schedule4.png)
*Observe que, para o planejamento semanal, *week\$1of\$1month é necessário se day\$1of\$1week* for fornecido.*
O exemplo a seguir mostra as datas que podem ser usadas para o planejamento diário.
| Data | Dia da semana | Semana do mês |
| --- | --- | --- |
| 01/08/2023 | NA | NA |
| 12/08/2023 | NA | N/D |
| NA | 2 | NA |
| NA | 5 | NA |
O exemplo a seguir pode ser usado para planejamento diário e semanal.
| Data | Dia da semana | Semana do mês |
| --- | --- | --- |
| 01/08/2023 | NA | NA |
| 12/08/2023 | NA | N/D |
| 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 |
## Lista de materiais (BOM)
A BOM do produto é usada nos Planos de Fabricação quando *sourcing\$1rule* está definido como Fabricação. Para obter informações sobre como ingerir a BOM do produto, consulte o documento de referência Cadeia de Suprimentos AWS da API.
## Processo de produção
*production\$1process\$1id é referenciado nas entidades sourcing\$1rule* **e product\$1bom.** Esses campos são usados para consumir informações de lead time para criar ou montar uma BOM.
## Parâmetros de planejamento de suprimentos
*Na entidade *supply\$1planning\$1parameters, o planner\$1name* *do planejador de suprimentos pode ser atribuído no nível product\$1id*.* O nome do planejador será exibido nas ordens planejadas geradas pelo mecanismo de planejamento de suprimentos.
# Dados transacionais
**Topics**
+ [Previsão](#forecast)
+ [Histórico de vendas ou demanda](#demand)
+ [Nível de inventário](#inventory-level)
+ [Pedidos recebidos](#in-flight-orders)
## Previsão
O Planejamento de Suprimentos usa duas fontes e tipos diferentes de previsão. Você pode usar os seguintes sistemas de origem para recuperar a fonte da previsão:
+ *Externo* — O Planejamento de Suprimentos usa os dados que estão sendo ingeridos na entidade de previsão do data lake.
+ *Planejamento de Demanda* — O Planejamento de Suprimento usa as previsões do Planejamento de Demanda.
+ *Nenhum* — O Planejamento de Suprimento usa os dados do histórico de vendas ou demanda da linha da ordem de saída.
O Planejamento de Suprimentos suporta dois tipos de previsão: determinística e estocástica. As previsões determinísticas contêm somente a média da previsão. As previsões estocásticas contêm P10/P50/P90, às vezes junto com a média. Quando a média não é fornecida com as previsões estocásticas, o Planejamento de Suprimento usa P50 (mediana) como média.
Cada registro de previsão tem quatro campos para representar a previsão de demanda:
+ média (dupla)
+ p10 (duplo)
+ p50 (também conhecido como mediana, duplo)
+ p90 (duplo)
Com base na política de inventário configurada, campos diferentes nessa entidade são obrigatórios. Para *sl*, p10/p50/90 é necessário; para *doc\$1fcst*, a política p50 ou mean é necessária. O Planejamento de Suprimentos usa p50 como uma aproximação da média e, para *doc\$1dem e *abs\$1level**, nenhum dos campos de previsão é obrigatório.
**Planejamento diário**
As previsões podem ser diferentes para o planejamento diário em comparação com o planejamento semanal. Aqui está um exemplo da exigência de previsão de planejamento diário e semanal.
![\[Planejamento diário\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/daily-planning.png)
**Planejamento semanal**
Você pode usar o exemplo de previsão de planejamento diário para planejamento semanal ou também pode usar o exemplo a seguir para planejamento semanal.
![\[Planejamento semanal\]](http://docs.aws.amazon.com/pt_br/aws-supply-chain/latest/userguide/images/weekly-planning.png)
## Histórico de vendas ou demanda
A política de inventário *doc\$1dem* exige um histórico de demanda para calcular a demanda média histórica. *O Planejamento de Suprimentos obtém o histórico de demanda da entidade *outbound\$1order\$1line* na categoria Outbound.* O Planejamento de Suprimentos usa os seguintes campos:
+ *ship\$1from\$1site\$1id* (string)
+ *ID do produto (sequência de caracteres*)
+ *actual\$1delivery\$1date (timestamp); quando estiver ausente, use promised\$1delivery\$1date* *(timestamp)*
Como parte do cálculo, o Supply Planning usa linhas históricas de pedidos de saída com datas de entrega nos últimos 30 dias. *O campo de destino usado para quantidade é *quantity\$1delivered*; quando ausente, use quantity\$1promised.* Se *quantity\$1promised* estiver ausente, *final\$1quantity\$1requested será usado*. Se tudo estiver faltando, então *0* será usado.
*Por exemplo, se você usar o Planejamento de Suprimentos para o produto “laptop” no site “TX0” em 1º de julho de 2023, o registro em *outbound\$1order\$1line em que product\$1id=laptop, TX0 *ship\$1from\$1site\$1id=** *e actual\$1delivery\$1date* é de 1º de junho de 2023 a 30 de junho de 2023.* O Planejamento de Suprimentos soma todos os registros e divide por 30 dias para obter a demanda diária.
## Nível de inventário
O planejamento de suprimentos requer um nível inicial de estoque para iniciar o processo de planejamento. O Supply Planning pesquisa o nível de estoque sob a *entidade de dados inv\$1level* da entidade. O Supply Planning procura um registro com os seguintes campos:
+ *id\$1de\$1produto*
+ *ID do site*
O Planejamento de Suprimentos usa *on\$1hand\$1inventory para determinar o nível* do estoque.
## Pedidos recebidos
O Supply Planning usa *inbound\$1order\$1line* para recuperar a quantidade do pedido em andamento. Se um pedido for entregue durante o horizonte de planejamento, a quantidade será considerada como parte do suprimento existente.
O Supply Planning procura um registro em *inbound\$1order\$1line* com os seguintes campos:
+ **order\$1receive\$1date; quando estiver ausente, use expected\$1delivery\$1date**
+ *id\$1de\$1produto*
+ *to\$1site\$1id*
A seguir estão os tipos de pedidos suportados: PO (Compra), TO (Transferência) e MO (Produção ou Fabricação).
O Planejamento de Suprimentos usa a *quantidade\$1recebida*; quando ausente, use *quantidade\$1confirmada e depois *quantidade\$1enviada** para determinar a quantidade no pedido.