La référence de AWS Partner Central l'API a été restructurée. Pour plus d'informations sur les opérations d'API prises en charge, consultez la référence des [AWS Partner Central API](https://docs.aws.amazon.com/partner-central/latest/APIReference/Welcome.html).
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.
# Utilisation des demandes de prestations
Une demande d'avantages modélise la demande d'un partenaire pour un avantage spécifique. Il saisit toutes les informations nécessaires pour évaluer et traiter la demande en fonction des conditions spécifiques aux prestations. Le cycle de vie des demandes d'avantages sociaux passe par plusieurs étapes, de la création du brouillon à l'approbation finale ou au rejet.
## Création de demandes de prestations
Les partenaires lancent le processus de demande d'avantages en créant une demande d'avantages à l'aide de l'action `CreateBenefitApplication` API. Au moment de sa création, l'application entre dans le `PENDING_SUBMISSION` statut, ce qui permet aux partenaires de préparer des informations complètes avant de les soumettre pour examen.
Lors de la création d'une demande de prestations, les partenaires doivent fournir :
+ **Identifiant du bénéfice** : ID ou ARN du bénéfice demandé
+ **Types d'exécution** - Comment le partenaire s'attend à bénéficier de l'avantage (`CREDITS``CASH`,`DISCOUNT`,`ACCESS`,`RECOGNITION`, ou`RESOURCE`)
+ **Détails de la demande de prestations** : document JSON contenant des informations spécifiques aux avantages, telles que définies par le schéma de demande de prestations
+ **Jeton client - Un jeton** d'idempuissance unique pour éviter les soumissions dupliquées
Les partenaires peuvent éventuellement fournir :
+ **Nom et description** : Human-readable identificateurs de l'application
+ **Contacts avec les partenaires** - Coordonnées de la personne chargée de gérer cette demande d'avantages (maximum 1 contact)
+ **Pièces jointes** - Documents justificatifs tels que les plans de projet, les SOW, les preuves des coûts ou les enquêtes de satisfaction client (maximum 10 fichiers)
+ **Ressources associées** - Liens vers des opportunités connexes ou des allocations d'avantages existantes (maximum 10 ressources)
+ **Balises** : Key-value paires pour l'organisation et le suivi des ressources (200 balises maximum)
L'`CreateBenefitApplication`API effectue une validation logicielle en vérifiant uniquement les types et modèles de champs de base. La validation complète de la logique métier a lieu lors de la soumission, ce qui permet aux partenaires de sauvegarder les demandes incomplètes et de les compléter ultérieurement.
**Meilleure pratique :** les partenaires doivent utiliser le schéma de demande d'avantages de `GetBenefit` pour comprendre exactement quelles informations sont requises avant de créer une demande. Cela réduit le risque d'échec de soumission en raison de données manquantes ou non valides.
## Mise à jour des demandes de prestations
Les partenaires peuvent modifier les ébauches de demandes d'avantages à l'aide de `UpdateBenefitApplication` l'action API. Cela permet aux partenaires d'affiner les informations, d'ajouter de la documentation ou de corriger les erreurs avant de les soumettre.
Lors de la mise à jour d'une demande de prestations, les partenaires doivent fournir :
+ **Identifiant** : ID ou ARN de la demande de prestations à mettre à jour
+ **Révision** - Le numéro de révision actuel pour un verrouillage optimiste
+ **Détails de la demande de prestations** - Le document JSON complet et mis à jour
Les partenaires doivent soumettre l'objet complet de la demande de prestations, même si seuls des champs spécifiques sont modifiés. La meilleure pratique consiste à récupérer d'abord les derniers détails de l'application en utilisant`GetBenefitApplication`, à modifier les champs nécessaires, puis à soumettre la charge utile complète mise à jour à`UpdateBenefitApplication`.
**Verrouillage optimiste :** le champ de révision garantit que les mises à jour ne sont appliquées que si l'application n'a pas changé depuis sa dernière récupération. Si la révision ne correspond pas à la valeur actuelle de la base de données, la mise à jour est rejetée avec une erreur de conflit. Cela empêche les partenaires de remplacer accidentellement les modifications apportées par d'autres processus ou systèmes.
Les mises à jour ne peuvent être effectuées que lorsque l'application est en `PENDING_SUBMISSION` état. Une fois soumises, les candidatures entrent dans le processus de révision et ne peuvent plus être mises à jour via cette API.
## Associer des ressources à des applications d'avantages
Les partenaires peuvent lier les demandes de prestations aux ressources connexes à l'aide de l'action `AssociateBenefitApplicationResource` API. Cela crée des liens précieux entre les avantages et le contexte commercial dans lequel ils sont utilisés.
Les types de ressources pris en charge incluent :
+ **OPPORTUNITÉ** - Associez la demande d'avantages à une opportunité client spécifique dans. Cela est particulièrement utile pour les avantages spécifiques à une opportunité, tels que le financement MAP ou les crédits POC liés aux engagements des clients.
+ **BENEFIT\_ALLOCATION** - Lien vers les allocations d'avantages existantes, permettant aux partenaires d'enchaîner les avantages ou de démontrer comment les avantages antérieurs sont exploités
L'association de ressources ne peut avoir lieu qu'avant la soumission. Une fois qu'une demande de prestations est soumise (le statut change de`IN_REVIEW`), aucune autre association n'est autorisée. Les partenaires peuvent associer jusqu'à 10 ressources à chaque demande d'avantages.
Pour dissocier une ressource, les partenaires utilisent l'action `DisassociateBenefitApplicationResource` API. Tout comme l'association, la dissociation ne peut se produire qu'en cas de `PENDING_SUBMISSION` statut.
**Important**
Les partenaires doivent disposer des autorisations appropriées pour accéder à la demande d'avantages et lire la ressource spécifique associée. L'API valide ces autorisations lors de l'opération d'association.
## Soumission de demandes de prestations
Lorsqu'une demande d'avantages est complète et prête à être AWS examinée, les partenaires la soumettent à l'aide de l'action `SubmitBenefitApplication` API. La soumission déclenche une transition d'état de `PENDING_SUBMISSION` à `IN_REVIEW` et lance le flux de travail d'approbation spécifique aux avantages.
Lors de la soumission, l'API effectue une validation complète, notamment :
+ **Validation des champs obligatoires** : garantit la présence de tous les champs obligatoires dans les détails de la demande de prestations
+ **Validation du format des champs** : vérifie que les valeurs des champs correspondent aux modèles et aux types de données attendus
+ **Validation des règles métier** : applique une logique métier et des contraintes spécifiques aux avantages
+ **Validation des ressources** : confirme que toutes les ressources associées sont valides et accessibles
+ **Validation des fichiers** : vérifie que le traitement de toutes les pièces jointes a été effectué avec succès
Si la validation échoue, l'API renvoie un ValidationException code d'erreur détaillé et des messages indiquant les champs à corriger. Les partenaires doivent résoudre ces problèmes en utilisant `UpdateBenefitApplication` avant de tenter à nouveau de soumettre une demande.
**Exigence de traitement des fichiers :** les demandes de prestations ne peuvent pas être soumises si les pièces jointes sont toujours en cours `PENDING` d'élaboration. Les partenaires doivent attendre la fin du traitement du fichier (changement de statut`SUCCEEDED`) avant de le soumettre. Si le traitement des fichiers échoue (statut`FAILED`), les partenaires doivent télécharger les versions corrigées.
Une fois la soumission réussie :
+ Le statut de la demande passe à `IN_REVIEW`
+ L'équipe du bénéficiaire est informée de la nouvelle soumission
+ Les partenaires ne peuvent plus modifier les détails des applications via les API de mise à jour standard
+ L'application entre dans un flux de travail d'approbation défini qui peut inclure les étapes d'approbation commerciale, d'approbation technique et d'approbation financière
Les partenaires peuvent suivre l'avancement des soumissions en récupérant la demande et en surveillant le champ Étape, qui indique l'étape d'approbation actuelle (par exemple, « Approbation commerciale », « Approbation technique », « Approbation financière »).
## Gestion des candidatures soumises
Une fois soumises, les partenaires disposent d'options limitées pour gérer les demandes de prestations, mais l'API fournit des actions spécifiques pour des scénarios courants.
### Rappel des demandes de prestations
Si un partenaire découvre une erreur ou doit apporter des modifications après la soumission, il peut rappeler l'application à l'aide de l'action `RecallBenefitApplication` API. Recall fait revenir l'application à son `PENDING_SUBMISSION` statut, autorisant les mises à jour et la soumission à nouveau.
Lors du rappel d'une candidature, les partenaires doivent fournir :
+ **Identifiant** : ID ou ARN de la demande de prestations à rappeler
+ **Motif** - Une explication facultative du rappel (maximum de 1 000 caractères)
Le champ Motif permet une meilleure traçabilité et aide àAWS comprendre les problèmes courants à l'origine des rappels, ce qui oriente les améliorations futures du processus de demande de prestations.
Après le rappel, les partenaires peuvent l'utiliser `UpdateBenefitApplication` pour apporter les modifications nécessaires, puis les soumettre à nouveau `SubmitBenefitApplication` lorsqu'ils sont prêts.
**Important**
Le rappel n'est généralement disponible qu'au cours des premières étapes de révision. Les demandes qui sont passées aux étapes d'approbation ultérieures ou qui ont été approuvées peuvent ne pas être éligibles au rappel.
### Modification des demandes de prestations
Pour les corrections mineures après la soumission, les partenaires peuvent utiliser l'action `AmendBenefitApplication` API pour mettre à jour des champs spécifiques sans rappeler l'intégralité de l'application. Cela est particulièrement utile lorsque AWS les réviseurs demandent des clarifications ou des corrections au cours du processus de révision.
Les modifications utilisent une Patch-style approche JSON dans laquelle les partenaires spécifient :
+ **Path** : expression JSONPath identifiant le champ à mettre à jour (par exemple,) `$.CreditDisbursementDetails.AwsAccountIdForCredits`
+ **Valeur** : nouvelle valeur du champ
+ **Opération** - L'opération à effectuer (actuellement seule `REPLACE` est prise en charge)
Les partenaires peuvent soumettre jusqu'à 10 modifications en un seul appel d'API. Chaque modification doit inclure un numéro de révision mis à jour pour un verrouillage optimal.
Les modifications doivent être utilisées pour des corrections mineures. En cas de modifications importantes, les partenaires doivent utiliser cette option `RecallBenefitApplication` pour remettre la demande à l'état de brouillon pour des mises à jour complètes.
### Annulation des demandes de prestations
Si un partenaire n'a plus besoin d'un avantage ou souhaite retirer sa candidature, il peut l'annuler à l'aide de l'action `CancelBenefitApplication` API. L'annulation fait passer la demande au `CANCELED` statut, mettant définitivement fin au processus de candidature.
Lors de l'annulation d'une candidature, les partenaires doivent fournir :
+ **Identifiant** : ID ou ARN de la demande de prestations à annuler
+ **Motif** - Une explication facultative de l'annulation (maximum de 1 000 caractères)
Une fois annulées, les applications ne peuvent pas être réactivées. Si le partenaire décide par la suite qu'il a besoin de cette prestation, il doit créer une nouvelle demande de prestation.
Les raisons courantes d'annulation sont les suivantes :
+ Une opportunité client a été perdue ou retardée
+ Les contraintes de capacité des partenaires ont changé
+ Les priorités commerciales ont changé
+ L'avantage n'est plus nécessaire aux fins prévues
## Afficher les détails de la demande de prestations
Les partenaires peuvent récupérer des informations complètes sur une demande d'avantages à l'aide de l'action `GetBenefitApplication` API. Cela fournit une vue complète de l'application, notamment :
**Métadonnées de l'application :**
+ Identifiant unique (ID) et nom de ressource Amazon (ARN)
+ Identifiant d'avantage associé
+ Nom et description de l'application
+ État actuel (`PENDING_SUBMISSION``IN_REVIEW`,`ACTION_REQUIRED`,`APPROVED`,`REJECTED`, ou`CANCELED`)
+ Étape de traitement en cours
**Informations sur le statut :**
+ Motif du statut : Human-readable explication du statut actuel
+ Codes de motif du statut - Codes structurés indiquant des problèmes ou des exigences spécifiques (par exemple, « Liste de contrôle incomplète », « Plan de projet manquant », « Design Win manquant »)
**Contenu de l'application :**
+ Document JSON complet sur les détails de la demande de prestations
+ Informations de contact du partenaire
+ Pièces jointes avec statut de traitement
+ Ressources associées (opportunités ou allocations)
+ Balises de ressources
**Informations d'audit :**
+ Horodatage de création
+ Horodatage de la dernière modification
+ Numéro de révision actuel
Les codes de motif du statut sont particulièrement utiles lorsqu'une demande est en cours `ACTION_REQUIRED` d'examen. Ces codes fournissent des conseils spécifiques et exploitables sur les points que les partenaires doivent aborder pour que la demande soit traitée.
## Liste des demandes de prestations
Les partenaires peuvent consulter toutes leurs demandes d'avantages à l'aide de l'action `ListBenefitApplications` API. Cela renvoie une liste paginée de résumés d'applications avec de puissantes fonctionnalités de filtrage.
Les partenaires peuvent filtrer les candidatures par :
+ **Programme** - Afficher les applications pour des programmes spécifiques (MAP, MDF, Sandbox, POC, etc.)
+ **Type d'expédition** - Filtrez par mode de livraison (`CREDITS``CASH`,`ACCESS`,, etc.)
+ **Identifiant des avantages** : consultez les demandes relatives à un avantage spécifique
+ **État** - Filtrer par statut de l'application (`PENDING_SUBMISSION``IN_REVIEW`,`APPROVED`,`REJECTED`,`CANCELED`)
+ **Étape** - Filtrer par étape d'approbation (approbation commerciale, approbation technique, approbation financière)
+ ARN de **ressources associées - Trouvez des** applications liées à des opportunités ou à des allocations spécifiques
La réponse à la liste comprend des informations récapitulatives essentielles telles que :
+ ID, ARN et nom de l'application
+ Numéro de prestation associé
+ Programmes et types d'expédition
+ État actuel et stade
+ Horodatages de création et de modification
+ Ressources associées
+ Numéro de révision actuel
+ Champs sélectionnés dans les détails de la demande de prestations (tels que définis par le titulaire des avantages)
Les partenaires peuvent configurer le tri des résultats à l'aide du paramètre Sort, avec des options permettant de trier par date de création, statut, programme ou identifiant d'avantage par ordre croissant ou décroissant.
**Création de tableaux de bord :** L'`ListBenefitApplications`API est conçue pour faciliter la création de tableaux de bord pour les partenaires. En filtrant et en triant les applications, les partenaires peuvent créer des vues telles que :
+ Demandes nécessitant une action (`ACTION_REQUIRED`statut)
+ Candidatures récemment soumises (triées par date de création, `IN_REVIEW` statut)
+ Demandes approuvées en attente d'attribution (`APPROVED`statut)
+ Candidatures par programme (filtrées par programmes spécifiques)