

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Planification des données de configuration
<a name="non-transactional"></a>

Cette section répertorie tous les champs obligatoires utilisés par Supply Planning et décrit comment chaque champ est utilisé. Pour plus d'informations sur les champs de données requis pour la planification des approvisionnements, voir[Planification des approvisionnements](entities-supply-planning.md). 

**Topics**
+ [Produit (langue française non garantie)](#product)
+ [Site](#site)
+ [Partenaire commercial](#trading-partners)
+ [Produit du fournisseur](#vendor-product)
+ [Délai de livraison du fournisseur](#vendor-leadtime)
+ [Règle d'approvisionnement](#sourcing-rule)
+ [Politique d'inventaire](#inventory-policy)
+ [Calendrier d'approvisionnement](#sourcing-schedule)
+ [Nomenclature (BOM)](#product-bom)
+ [Procédé de production](#production-process)
+ [Paramètres de planification des approvisionnements](#production-process2)
+ [Données transactionnelles](transactional.md)

## Produit (langue française non garantie)
<a name="product"></a>

L'entité produit définit la liste des articles ou produits qui doivent être inclus dans le planning. Les demandes de bon de commande utilisent *le champ unit\$1cost* de l'entité *Produit* pour déterminer la valeur ou le montant de la commande. L'entité *Product* contient également le groupe de produits correspondant à un produit spécifique, qui est une clé étrangère dans une entité *product\$1hierarchy*. Les groupes de produits peuvent être utilisés pour configurer les politiques d'inventaire, les calendriers d'approvisionnement, les délais, etc., au niveau agrégé. 

## Site
<a name="site"></a>

L'entité *Site* définit la liste des sites ou des emplacements qui doivent être inclus dans la planification. L'entité *Site* contient également les régions correspondant à un site spécifique, qui est une clé étrangère dans une entité géographique. Les régions peuvent être utilisées pour configurer les politiques d'inventaire, les calendriers d'approvisionnement, les délais, etc., au niveau agrégé.

## Partenaire commercial
<a name="trading-partners"></a>

L'entité *trading\$1partner* définit la liste des fournisseurs. *tpartner\$1type* doit être défini sur *Vendor lors du téléchargement des informations sur le fournisseur*.

## Produit du fournisseur
<a name="vendor-product"></a>

Les produits fournis par chaque fournisseur sont définis dans l'entité *vendor\$1product*. Cette entité contient également des informations sur les coûts spécifiques au fournisseur.

## Délai de livraison du fournisseur
<a name="vendor-leadtime"></a>

Le délai de livraison du fournisseur est le délai entre la passation d'une commande auprès d'un fournisseur et la réception de la commande. Ces données sont définies dans la *VendorMgmt*catégorie située sous l'entité de données *vendor\$1lead\$1time*. Le délai de livraison du fournisseur suit la logique de dérogation suivante :
+ Le délai fournisseur au niveau du produit remplace le délai fournisseur au niveau du groupe de produits.
+ Le délai de livraison du fournisseur au niveau du site remplace le délai du fournisseur au niveau de la région.
+ Le délai fournisseur au niveau de la région remplace le délai fournisseur au niveau de l'entreprise.

Pour rechercher un enregistrement, Supply Planning utilise les champs suivants :
+ company\$1id
+ identifiant\$1région
+ identifiant du site
+ ID du groupe\$1produit
+ product\$1id

Voici un exemple de logique de dérogation :

![\[Exemple de logique de remplacement\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/override_logic.png)


Voici un exemple de la façon dont la planification des approvisionnements calcule le délai de livraison des fournisseurs :

![\[Calcul du délai de livraison du fournisseur\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/vendor_lead_time.png)


**L'ordre de priorité est *produit* > *groupe de produits > *site* > dest\$1geo* *(région)* > segment de produit > entreprise.**

## Règle d'approvisionnement
<a name="sourcing-rule"></a>

La planification des approvisionnements génère un plan basé sur la topologie du réseau de chaîne d'approvisionnement définie sous l'entité *sourcing\$1rules*.

Les types de règles d'approvisionnement pris en charge sont le transfert, l'achat et la fabrication. 

*Les règles d'approvisionnement suivent la logique de *remplacement product\$1id* > *product\$1group\$1id > company\$1id*.*

**Supply Planning récupère le délai de transport en référençant *transportation\$1lane\$1id et en accédant à transit\$1time dans transportation\$1lane*.** Il existe deux étapes pour récupérer le délai de transfert.

1. *Trouvez *transportation\$1lane\$1id dans sourcing\$1rules*.* *Seules les règles d'approvisionnement comportant à la fois *to\$1site\$1id et from\$1site\$1id* *sont éligibles pour récupérer transfer\$1lead\$1time*.*

1. *Utilisez *transportation\$1lane\$1id pour rechercher transportation\$1lane.**

Lorsque plusieurs enregistrements ont les mêmes *to\$1site\$1id et *product\$1id (product\$1group\$1id***) dans l'entité *sourcing\$1rule**, seuls les enregistrements ayant la priorité la plus élevée (le plus petit nombre) seront utilisés.

Exemple de règles d'approvisionnement :

Sur la base de la définition précédente, Supply Planning sélectionne la règle d'approvisionnement suivante SR1 : L'ordinateur portable sur site `TX0` provient du site `IL0` via`transportation_lane_9`.


|  identifiant\$1rule\$1source  |  product\$1id  |  ID du groupe\$1produit  |  type\$1de\$1règle d'approvisionnement  |  from\$1site\$1id  |  to\$1site\$1id  |  priorité\$1d'approvisionnement  |  identifiant de voie de transport  | 
| --- | --- | --- | --- | --- | --- | --- | --- | 
|  SR1  |  ordinateur portable  |  électronique  |  transfert  |  IL0  |  TX0  |  1  |  transportation\$1lane\$19  | 
|  SR2  |  ordinateur portable  |  électronique  |  transfert  |  NJ1  |  TX0  |  2  |  transportation\$1lane\$121  | 
|  SR3  |  ordinateur portable  |  électronique  |  transfert  |  IL0  |  TX0  |  1  |  transportation\$1lane\$111  | 

*Lorsque plusieurs enregistrements ayant la même priorité existent pour la même combinaison de *to\$1site\$1id, product\$1id (ou **product\$1group\$1id***), la quantité récommandée sera répartie entre les options d'approvisionnement disponibles en fonction du champ sourcing\$1ratio.* Notez que l'approvisionnement multiple n'est actuellement pris en charge que pour le type de règle d'`buy`approvisionnement.

Exemple de multi-sourcing :


|  identifiant\$1rule\$1source  |  product\$1id  |  ID du groupe\$1produit  |  type\$1de\$1règle d'approvisionnement  |  tpartner\$1id  |  to\$1site\$1id  |  priorité\$1d'approvisionnement  |  ratio d'approvisionnement  | 
| --- | --- | --- | --- | --- | --- | --- | --- | 
|  SR1  |  ordinateur portable  |  électronique  |  acheter  |  fournisseur1  |  TX0  |  1  |  4  | 
|  SR2  |  ordinateur portable  |  électronique  |  acheter  |  fournisseur 2  |  TX0  |  1  |  6  | 

Les règles d'approvisionnement SR1 et SR2, sont sélectionnées, et la quantité commandée sera répartie entre le fournisseur 1 et le fournisseur 2 selon un ratio de 4:6.

## Politique d'inventaire
<a name="inventory-policy"></a>

Supply Planning recherche un enregistrement dans le jeu de données à l'aide des champs suivants :
+ *identifiant\$1site*
+ *géodésique*
+ *identifiant\$1entreprise*
+ *identifiant\$1produit*
+ *ID du groupe\$1produit*
+ *identifiant\$1segment*

La planification des approvisionnements utilise *ss\$1policy* pour déterminer la politique d'inventaire. ***La logique de remplacement utilise la priorité suivante : *product\$1id > product\$1group\$1id > site\$1id* *> et dest\$1geo\$1id > segment\$1id* *> company\$1id*. *****

**Les valeurs *ss\$1policy* prises en charge sont *abs\$1level, doc\$1dem**, doc\$1fcst* et sl.** 

L'exemple suivant montre la logique de priorité de remplacement.

![\[Remplacer la logique\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/override1.png)


Voici un exemple de la valeur *ss\$1policy* basée sur la logique de remplacement.

![\[Exemple de logique de remplacement pour la valeur ss_policy\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/override2.png)


## Calendrier d'approvisionnement
<a name="sourcing-schedule"></a>

**Note**  
Le calendrier d'approvisionnement est une entité facultative. Si cette entité n'est pas fournie, Supply Planning utilise un processus de révision continue pour générer *required\$1date* en fonction du moment où les produits sont nécessaires. 

La planification des approvisionnements utilise le calendrier d'approvisionnement pour générer des plans d'achat en suivant les étapes suivantes :
+ *Trouvez *sourcing\$1schedule\$1id dans sourcing\$1schedule*.*
+ *Trouvez le calendrier en *utilisant sourcing\$1schedule\$1id dans sourcing\$1schedule\$1details*.*

*Supply Planning recherche les champs suivants dans *sourcing\$1schedule\$1id sous sourcing\$1schedule*.*
+ *to\$1site\$1id*
+ **tpartner\$1id ou from\$1site\$1id**

*En fonction du chemin d'approvisionnement défini dans les règles d'approvisionnement, Supply Planning détermine s'il faut utiliser *from\$1site\$1id ou tpartner\$1id*.* Supply Planning lit la valeur du champ *sourcing\$1schedule\$1id* pour déterminer l'étape suivante.

Supply Planning lit les détails du calendrier sous *sourcing\$1schedule\$1details* avec les champs suivants :
+ *identifiant du planificateur\$1source*
+ *identifiant\$1entreprise*
+ *ID du groupe\$1produit*
+ *identifiant\$1produit*

*sourcing\$1schedule\$1details suit la logique de remplacement, product\$1id > product\$1group\$1id* ***> company\$1id.***

Voici un exemple de logique de remplacement dans *sourcing\$1schedule\$1details*.

![\[Logique de remplacement du calendrier d'approvisionnement\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/sourcing_schedule2.png)


Les programmes sélectionnés après application de la logique de dérogation sont les suivants.

![\[Logique de remplacement du calendrier d'approvisionnement\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/sourcing_schedule3.png)


Le calendrier réel peut aller d'une ligne à plusieurs lignes, en fonction de la complexité du calendrier. Pour le champ *week\$1of\$1month*, un seul chiffre est autorisé par ligne. Plusieurs semaines par mois, plusieurs enregistrements sont requis (voir l'exemple suivant). Pour le champ *day\$1of\$1week*, le nombre entier et le nom du jour sont autorisés (dimanche : 0, lundi : 1, mardi : 2, mercredi : 3, jeudi : 4, vendredi : 5, samedi : 6). Dans les détails du calendrier d'approvisionnement, la planification hebdomadaire nécessite *week\$1of\$1month*. Lors de la planification quotidienne, *week\$1of\$1month* peut être vide, c'est-à-dire chaque semaine. Voir les exemples suivantes.

![\[Logique de remplacement du calendrier d'approvisionnement\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/sourcing_schedule4.png)


*Notez que pour la planification hebdomadaire, *week\$1of\$1month est obligatoire si day\$1of\$1week* est fourni.*

L'exemple suivant montre les dates qui peuvent être utilisées pour la planification quotidienne.


| Date | Jour de la semaine | Semaine du mois | 
| --- | --- | --- | 
|  01/08/2023  |  NA  |  NA  | 
|  8/12/2023  |  NA  |  NA  | 
|  NA  |  2  |  NA  | 
|  NA  |  5  |  NA  | 

L'exemple suivant peut être utilisé pour la planification quotidienne et hebdomadaire.


| Date | Jour de la semaine | Semaine du mois | 
| --- | --- | --- | 
|  01/08/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   | 

## Nomenclature (BOM)
<a name="product-bom"></a>

La nomenclature des produits est utilisée dans les plans de fabrication lorsque *sourcing\$1rule* est défini sur Fabrication. Pour plus d'informations sur la façon d'ingérer la nomenclature des produits, consultez le document de référence de l' AWS Supply Chain API.

## Procédé de production
<a name="production-process"></a>

*production\$1process\$1id est référencé dans les entités sourcing\$1rule* **et product\$1bom.** Ces champs sont utilisés pour utiliser les informations relatives au délai de fabrication ou d'assemblage d'une nomenclature.

## Paramètres de planification des approvisionnements
<a name="production-process2"></a>

*Dans l'entité *supply\$1planning\$1parameters*, le *nom du planificateur d'approvisionnement peut être attribué au niveau product\$1id*.* Le nom du planificateur sera affiché sur les commandes planifiées générées par le moteur de planification des approvisionnements.

# Données transactionnelles
<a name="transactional"></a>

**Topics**
+ [Forecast](#forecast)
+ [Historique des ventes ou demande](#demand)
+ [Niveau d'inventaire](#inventory-level)
+ [Commandes entrantes](#in-flight-orders)

## Forecast
<a name="forecast"></a>

La planification des approvisionnements utilise deux sources et types de prévisions différents. Vous pouvez utiliser les systèmes sources suivants pour récupérer la source des prévisions :
+ *Externe* — La planification des approvisionnements utilise les données qui sont ingérées dans l'entité de prévision du lac de données.
+ *Planification de la demande* — La planification de l'approvisionnement utilise les prévisions de la planification de la demande.
+ *Aucune* : la planification des approvisionnements utilise les données de l'historique des ventes ou de la demande provenant de la ligne de commande sortante.

La planification des approvisionnements prend en charge deux types de prévisions : déterministes et stochastiques. Les prévisions déterministes contiennent uniquement la moyenne de la prévision. Les prévisions stochastiques contiennent les valeurs P10/P50/P90, parfois accompagnées d'une moyenne. Lorsque la moyenne n'est pas fournie avec les prévisions stochastiques, Supply Planning utilise P50 (médiane) comme moyenne.

Chaque enregistrement de prévision comporte quatre champs représentant la prévision de la demande :
+ moyen (double)
+ p10 (double)
+ p50 (également connu sous le nom de médiane, double)
+ p90 (double)

Selon la politique d'inventaire configurée, différents champs de cette entité sont obligatoires. Pour *sl*, p10/p50/90 est requis ; pour *doc\$1fcst*, la politique p50 ou mean est requise. La planification des approvisionnements utilise p50 comme approximation de la moyenne, et pour *doc\$1dem et *abs\$1level**, aucun des champs de prévision n'est obligatoire.

**Planification quotidienne**

Les prévisions peuvent être différentes pour la planification quotidienne par rapport à la planification hebdomadaire. Voici un exemple de l'exigence de planification quotidienne et hebdomadaire en matière de prévisions.

![\[Planification quotidienne\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/daily-planning.png)


**Planification hebdomadaire**

Vous pouvez utiliser l'exemple de prévision de planification quotidienne pour la planification hebdomadaire, ou vous pouvez également utiliser l'exemple suivant pour la planification hebdomadaire.

![\[Planification hebdomadaire\]](http://docs.aws.amazon.com/fr_fr/aws-supply-chain/latest/userguide/images/weekly-planning.png)


## Historique des ventes ou demande
<a name="demand"></a>

La politique d'inventaire *doc\$1dem* nécessite l'historique de la demande pour calculer la demande moyenne historique. *Supply Planning obtient l'historique de la demande à partir de l'entité *outbound\$1order\$1line* dans la catégorie Outbound.* La planification des approvisionnements utilise les champs suivants :
+ *ship\$1from\$1site\$1id (chaîne de caractères*)
+ *product\$1id (chaîne*)
+ *actual\$1delivery\$1date (horodatage) ; en cas d'absence, utilisez promised\$1delivery\$1date* *(timestamp)*

Dans le cadre du calcul, la planification des approvisionnements utilise l'historique des lignes de commandes sortantes dont les dates de livraison se situent au cours des 30 derniers jours. *Le champ cible utilisé pour la quantité est *quantity\$1delivered* ; s'il est absent, utilisez quantity\$1promised.* Si *quantity\$1promised* est manquant, alors *final\$1quantity\$1requested* sera utilisé. Si elles sont toutes manquantes, alors *0* sera utilisé.

*Par exemple, si vous utilisez la planification des approvisionnements pour le produit « ordinateur portable » sur le site « TX0 » le 1er juillet 2023, l'enregistrement dans *outbound\$1order\$1line où product\$1id=laptop, ship\$1from\$1site\$1id=* **et TX0 actual\$1delivery\$1date** date date date du 1er juin 2023 au 30 juin 2023.* La planification des approvisionnements ajoute tous les enregistrements et divise par 30 jours pour obtenir la demande quotidienne.

## Niveau d'inventaire
<a name="inventory-level"></a>

La planification des approvisionnements nécessite un niveau d'inventaire initial pour démarrer le processus de planification. Supply Planning recherche le niveau d'inventaire sous l'*entité de données entity inv\$1level*. Supply Planning recherche un enregistrement contenant les champs suivants : 
+ *identifiant\$1produit*
+ *identifiant\$1site*

La planification des approvisionnements utilise *on\$1hand\$1inventory pour déterminer le niveau d'inventaire*.

## Commandes entrantes
<a name="in-flight-orders"></a>

La planification des approvisionnements utilise *inbound\$1order\$1line* pour récupérer la quantité commandée en vol. Si une commande est livrée pendant l'horizon de planification, la quantité est considérée comme faisant partie de l'approvisionnement existant.

Supply Planning recherche un enregistrement sous *inbound\$1order\$1line* avec les champs suivants :
+ **order\$1receive\$1date ; en cas d'absence, utilisez expected\$1delivery\$1date**
+ *identifiant\$1produit*
+ *to\$1site\$1id*

Les types de commande pris en charge sont les suivants : PO (achat), TO (transfert) et MO (production ou fabrication).

La planification des approvisionnements utilise le paramètre *quantity\$1received* ; s'il est manquant, utilisez *quantity\$1confirmed puis *quantity\$1submitted** pour déterminer la quantité commandée.