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.

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 :

Les partenaires peuvent éventuellement fournir :

L'CreateBenefitApplicationAPI 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 :

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 utilisantGetBenefitApplication, à 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 :

L'association de ressources ne peut avoir lieu qu'avant la soumission. Une fois qu'une demande de prestations est soumise (le statut change deIN_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.

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 :

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 statutSUCCEEDED) avant de le soumettre. Si le traitement des fichiers échoue (statutFAILED), les partenaires doivent télécharger les versions corrigées.

Une fois la soumission réussie :

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 :

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.

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 :

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 :

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 :

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 :

Informations sur le statut :

Contenu de l'application :

Informations d'audit :

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 :

La réponse à la liste comprend des informations récapitulatives essentielles telles que :

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'ListBenefitApplicationsAPI 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 :