Exigences DSP
Exigences fonctionnelles
ID | Type | Exigence |
|---|---|---|
1 | Obligatoire | Les transactions du concessionnaire doivent être envoyées chaque jour. Optionnellement, les transactions n'ont pas besoin d'être mises à jour lorsque le concessionnaire est fermé. ❗ Aucune action manuelle de la part du concessionnaire ne doit être requise pour que les données soient envoyées. La transmission doit être entièrement automatique ❗ |
2 | Obligatoire | Lorsqu'un concessionnaire consent au partage de données, toutes les données disponibles des 4 dernières années doivent être envoyées. Si le concessionnaire refuse le consentement au partage de données, la transmission des données historiques doit cesser. Exigences en matière de données historiques :
|
3 | Obligatoire | Votre DMS doit être capable de renvoyer des transactions pour une plage de dates spécifique. Cette fonction est manuelle ; la demande ne sera pas envoyée par le biais d'une API. |
4 | Obligatoire | Votre DMS doit avoir un processus automatisé pour renvoyer la demande jusqu'à ce qu'un accusé de réception soit reçu. |
5 | Obligatoire | Exigence supprimée. |
6 | Obligatoire | Les propriétés optionnelles doivent être incluses dans votre charge utile si l'information est disponible dans votre DMS. |
Activités de certification
Cette section présente toutes les activités de certification et validations qui doivent être complétées pour certifier l'API.
Assurance Qualité
Les tests énumérés dans le tableau ci-dessous doivent être complétés avec succès dans l'environnement de test avant de pouvoir commencer la phase pilote des concessionnaires.
Un aspect important de la phase de test est de vérifier que les transactions reçues par l'API des Transactions de Vente au Détail correspondent aux transactions dans votre DMS.
Vous devez fournir à l'équipe DCP les transactions envoyées à partir des données sources pour réaliser cette validation. Vous pouvez :
- Fournir un rapport.
- Fournir les factures clients.
- Fournir un fichier Excel ou CVS.
- Afficher les transactions à l'écran dans votre DMS lors d'une session en direct.
- Autres moyens approuvés par l'équipe DCP.
Si la validation est effectuée lors d'une session en direct :
❗ ❗ Vous devez préparer ET envoyer les transactions avant la session en direct ❗ ❗
Lors de la session en direct, le numéro de transaction est utilisé pour trouver les données dans le backend de BRP et valider les données reçues en les comparant avec les informations affichées dans votre DMS.
Encore une fois, l'objectif est de vérifier que les transactions reçues via l'API des Transactions de Vente au Détail correspondent aux transactions dans votre DMS.
ID | Test | Résultat attendu |
|---|---|---|
1 | Avant la session en direct, envoyez différentes transactions, au moins 5 de chaque type de transaction :
Les données pour chaque transaction doivent être différentes ! | Les données sont envoyées et reçues via l'API. REMARQUE Le scénario pour le test 4. Ventes d'unités avec réparation et pièces inclut un client achetant une unité et installant des accessoires. |
2 | Créer une transaction de vente d'unité avec des transactions de réparation et de pièces en utilisant des pièces et des unités non-BRP. | Vérifiez que les transactions n'ont pas été ENVOYÉES via l'API. |
3 | DLors de la session en direct, montrez chaque transaction à l'écran. | Les données reçues via l'API correspondent à la facture affichée à l'écran. |
4 | Envoyez les transactions des 3 dernières semaines. | L'API reçoit les données. |
5 | Tester la nouvelle tentative :
| Vérifiez que les transactions sont envoyées lorsque l'API est temporairement indisponible. |
6 | Pour valider les données et le processus, envoyez les données de production au environnement de test pendant 1 semaine. | Les données sont envoyées et reçues via l'API quotidiennement pendant 1 semaine. |
7 | Comparer les factures du DMS avec les données reçues via l'API. | DCP sélectionne 3 à 5 factures dans les données reçues, qui sont affichées dans le DMS. Le DMS trouve une facture pour chacun de ces types de transaction :
Le DMS envoie les factures, et l'équipe DCP valide les données reçues. |
8 | Cas de test de validation | Tous les cas de test énumérés dans le Cas de test de validation la section ci-dessous sont soit réussis, soit non applicables. |
Pilote de concessionnaire
Le tableau ci-dessous décrit les paramètres du pilote de concessionnaire et leurs validations correspondantes.
Paramètre | Valeur |
|---|---|
Environnement | Production |
Nombre de concessionnaires | 1 à 3 |
Durée | 2 à 4 semaines. BRP et vous vous mettrez d'accord sur une durée basée sur la fréquence des ventes des concessionnaires sélectionnés. |
Validation 1 | Votre DMS doit fournir des données historiques pour chaque concessionnaire sélectionné pour le pilote des concessionnaires, comme requis par exigence 2. |
Validation 2 | Vous activez la transmission des données de vente au détail pour chaque concessionnaire dans le pilote. Vous devez utiliser des données de production et les envoyer depuis un environnement de production. |
Validation 3 | BRP surveille l'API RTD pour confirmer le transfert de données et s'assurer qu'aucune erreur n'est rencontrée. BRP valide la qualité des données reçues. Par exemple, BRP vérifie qu'aucune pièce non-BRP n'est envoyée. |
Validation 4 | Vous devez fournir le nombre de transactions de chaque type envoyées via l'API à la fin du pilote. Le nombre de transactions envoyées doit correspondre au nombre de transactions reçues par le BRP. |
Validation 5 | Tous les cas de test énumérés dans le Cas de test de validation la section ci-dessous sont soit réussis, soit non applicables. |
Cas de test de validation
Le tableau ci-dessous décrit tous les cas de test effectués sur les données des transactions de détail pendant les phases de Test et de Pilote de Concessionnaire. Les tests sont effectués sur les données reçues au cours des 5 à 10 derniers jours.
❗ Lorsqu'un test échoue, cela peut être un problème dans votre DMS, ou l'échec peut être causé par la façon dont le concessionnaire utilise votre DMS.
Dans ce dernier cas, le test est marqué comme "non applicable".
Test # | Nom du test | Description du test | Résultats Attendus |
|---|---|---|---|
0 | Nombre de transactions par jour | Vérifiez qu'il y a des transactions téléchargées quotidiennement pendant la période de test. | Compte > 0 |
1 | Utilisation des transactions | Vérifiez qu'il y a des transactions | Compter > 0 |
2 | Utilisation des consommateurs | Vérifiez qu'il y a des objets Consumer | Compter > 0 |
3 | Utilisation des pièces | Vérifiez qu'il y a des objets Parts | Compte > 0 |
4 | Coûts supplémentaires des pièces Utilisation | Vérifiez qu'il y a des objets de coûts supplémentaires de pièces | Compte > 0 |
5 | Utilisation des unités | Vérifiez qu'il y a des objets Units | Compte > 0 |
6 | Utilisation des unités Coûts supplémentaires | Vérifiez qu'il y a des objets de Coûts Additionnels des Unités | Compte > 0 |
7 | Utilisation de la reprise | Vérifiez qu'il y a des objets Trade Ins | Compter > 0 |
8 | Utilisation des emplois | Vérifiez qu'il y a des objets Jobs | Compte > 0 |
9 | Emplois Ajouter. Coûts Utilisation | Vérifiez qu'il y a des objets de Coûts Additionnels de Jobs | Compter > 0 |
10 | Utilisation des cartes de temps | Vérifiez qu'il y a des objets de carte de temps | Compte > 0 |
11 | Pas de UUID en double | Vérifiez que les UUID de transaction sont uniques et non dupliqués. | Le compte est 0 |
12 | Mises à jour des transactions | Vérifiez que certaines transactions ont été mises à jour. Cela peut ne pas s'appliquer à tous les DMS ; certains peuvent ne pas autoriser les mises à jour d'une transaction. | Compte > 0 |
13 | Dates de transaction | Vérifiez s'il y a des transactions avec une DATE_DE_FERMETURE_DE_TRANSACTION après la DATE_D'OUVERTURE_DE_TRANSACTION et avant la DATE_DE_TÉLÉVERSEMENT. | Le compte est 0 |
14 | Durée de la transaction | Vérifiez le nombre de jours entre les dates d'ouverture et de fermeture de la transaction. En général, la transaction ne devrait pas rester ouverte pendant une période prolongée. Le test est ÉCHOUÉ si des transactions ouvertes depuis plus de 1000 jours sont trouvées. (Ceci est un nombre arbitraire de jours ; nous supposons qu'une transaction ne devrait pas être ouverte pendant plus d'un an.) | Durée <1000 jours |
15 | Sources de transaction | Vérifiez que les valeurs de source de transaction 'En magasin' et 'En ligne' sont utilisées. En ligne est une option ; le test est RÉUSSI même si En ligne n'est pas utilisé. | Compte > 0 |
16 | Transactions annulées | Vérifiez que certaines transactions ont le champ CANCEL_FLAG défini sur TRUE. | Compter > 0 |
17 | Ratio Client/Soi/Concessionnaire | Regardez la transaction RTD_CONSUMERS.RECIPIENT pour vérifier que toutes les valeurs sont utilisées (Client, Soi-même et Revendeur). | Compter > 0 |
18 | hash_consommateur <==> id_consommateur | Pour un revendeur donné, le RTD_CONSUMERS.CONSUMER_ID doit toujours être lié au même RTD_CONSUMERS.CONSUMER_HASH, car la valeur de RTD_CONSUMERS.CONSUMER_HASH est calculée en utilisant l'email et le numéro de téléphone du consommateur. Recherchez des transactions avec plus d'une correspondance entre CONSUMER_HASH et CONSUMER_ID. S'il y a plus d'un CONSUMER_HASH pour un CONSUMER_ID, cela peut être parce que le concessionnaire a plusieurs comptes consommateurs pour une personne dans son DMS. S'il y a plus d'un CONSUMER_ID pour un CONSUMER_HASH, l'erreur doit être examinée, car cela ne devrait pas se produire. | Le compte est 0 |
19 | Commandes spéciales | Vérifiez s'il y a des transactions de commandes spéciales. | Compte > 0 |
20 | Validation du prix total de la transaction des pièces | La valeur TOTAL_CUSTOMER_PRICE dans la transaction doit correspondre au total calculé. prix_total_client = prix_concessionnaire * qty + coût_additionnel Vérifiez s'il existe des enregistrements où la différence totale calculée avec le TOTAL_CUSTOMER_PRICE est supérieure à 0,1. | Le compte est 0 |
21 | Code produit NON-BRP-PARTS associé à la description | Vérifiez que tous les numéros de pièce NON-BRP-PARTS sont utilisés avec une description de pièce NON-BRP-PARTS. | Le compte est 0 |
22 | Transactions avec des NON-BRP-PARTS | Vérifiez s'il y a des transactions avec des PIÈCES NON-BRP. | Compter > 0 |
23 | Liens de numéro de travail associé | Vérifiez que toutes les valeurs RTD_PARTS.ASSOCIATED_JOB_NUMBER dans les transactions de pièces se trouvent dans au moins un RTD_JOBS.JOB_NUMBER. Il ne devrait y avoir aucun RTD_PARTS.ASSOCIATED_JOB_NUMBER non trouvé dans le RTD_JOBS.JOB_NUMBER. | Le compte est 0 |
24 | Les pièces NON-BRP existent avec une transaction UNIT ou JOB | Vérifiez que toutes les pièces NON-BRP-PARTS sont liées à des transactions d'unités ou de travaux. Les pièces non-BRP ne peuvent pas être dans une transaction de pièces par elles-mêmes, ces transactions ne doivent pas être envoyées. | Le compte est 0 |
25 | Coût supplémentaire avec le calcul du taux | Vérifiez que pour tous les coûts supplémentaires qui utilisent un tarif, le montant est correct. MONTANT_APPLICABLE * TAUX = MONTANT Comptez le nombre de coûts supplémentaires où la différence entre le montant de la charge utile et le montant calculé est supérieure à 1. | Le compte est 0 |
26 | Utilisation des identifiants de leads de vente | Vérifiez s'il existe des transactions avec une valeur SALES_LEAD_ID non trouvée dans les données de leads de vente de BRP. La valeur SALES_LEAD_ID devrait être l'ID de prospect de vente BRP, mais il n'est pas toujours disponible. | Le compte est 0 |
27 | Validation du prix de vente unitaire | La valeur TOTAL_CUSTOMER_PRICE dans la transaction doit correspondre au total calculé. prix_total_client = prix_concessionnaire + coût_additionnel - échanges
Vérifiez s'il existe des enregistrements où la différence totale calculée avec le TOTAL_CUSTOMER_PRICE est supérieure à 10. | Le compte est 0 |
28 | Tous les champs financés sont fournis lorsqu'ils sont utilisés | Vérifiez s'il existe des transactions où les trois champs financés ne sont pas tous fournis ou ne sont pas tous nuls. | Le compte est 0 |
29 | Prix de reprise positif | Vérifiez s'il existe des transactions d'unité où le coût de reprise est positif. | Le compte est 0 |
30 | Transactions de travail sous garantie trouvées | Vérifiez qu'il y a des transactions avec le drapeau IS_WARRANTY_JOB qui est VRAI | Compte > 0 |
31 | Pas de numéros de travail en double par transaction | Vérifiez s'il existe des transactions JOBS avec le même JOB_NUMBER. | Le compte est 0 |
32 | Le prix total pour le client est de 0 pour un travail de garantie | Test annulé. Le montant total du travail client est vérifié par le test 34 | Le compte est 0 |
33 | Validation du prix du travail | La valeur TOTAL_CUSTOMER_PRICE dans la transaction doit correspondre au total calculé. prix_total_client = SOMME(HEURES_DE_TRAVAIL_FACTURÉES * TAUX_DE_TRAVAIL) + coût_additionnel Vérifiez s'il existe des enregistrements où la différence totale calculée avec le TOTAL_CUSTOMER_PRICE est supérieure à 1. | Le compte est 0 |
34 | Max un objet NON-BRP PART par transaction | Vérifiez s'il y a des transactions utilisant plus d'une pièce NON-BRP-PARTS. La partie NON-BRP-PARTS est un objet agrégé de toutes les pièces non-BRP utilisées dans la transaction. | Le compte est 0 |
35 | Numéros de pièce BRP valides | Tous les numéros de pièce envoyés doivent être des numéros de pièce BRP valides, sauf la pièce NON-BRP-PARTS. Vérifiez s'il y a des transactions avec des numéros de pièces invalides. Le test échouera si le DMS permet au concessionnaire de créer des numéros de pièces clients et de les utiliser dans des transactions. | Le compte est 0 |
36 | VINs BRP valides | Vérifiez s'il y a des transactions UNITS avec un VIN invalide. | Le compte est 0 |
37 | Remise positive sur les coûts supplémentaires | Vérifiez s'il y a des transactions avec un coût supplémentaire de type REMISE et un montant positif. Un MONTANT DE COÛT SUPPLÉMENTAIRE DE REMISE devrait toujours être négatif. | Le compte est 0 |
38 | Combinaisons valides de types de transaction | Vérifiez si tous les types de combinaisons de transactions sont utilisés. Il existe plusieurs combinaisons de travaux, d'unités et de pièces que nous nous attendons à recevoir dans une transaction. TOUT, SEULS LES EMPLOIS, EMPLOIS ET PIÈCES, EMPLOIS ET UNITÉS, SEULEMENT DES PIÈCES, SEULEMENT DES UNITÉS, UNITÉS ET PIÈCES. Il se peut qu'il ne s'agisse pas d'une erreur si une combinaison est manquante ; cela peut être parce qu'aucune n'a encore été envoyée. | Le compte est 0 |
39 | Le champ de taux dans le coût supplémentaire | Le champ de taux des coûts supplémentaires ne peut être utilisé qu'en conjonction avec le champ de montant applicable. Vérifiez qu'il n'y a pas de transactions où l'un des champs est manquant ou vide. | Le compte est 0 |
40 | Ratio des unités utilisées | Vérifiez qu'il y a des transactions UNITS avec les valeurs UTILISÉES dans le champ CLASS_CODE. Nous ignorons la valeur DEMO car elle est moins courante. | Compte > 0 |
41 | Utilisation de la ville (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
42 | Utilisation du pays (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
43 | Utilisation de l'État ou de la province (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
44 | Pièces associées numéro de travail utilisation (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
45 | Prix de détail suggéré par le fabricant (MSRP) Utilisation (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
46 | Coût d'utilisation du revendeur de pièces (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
47 | Prix du revendeur de pièces Utilisation (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
48 | Utilisation du compteur kilométrique des unités (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
49 | Utilisation des unités par heure (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
50 | Utilisation de l'ID de piste de vente (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
51 | Utilisation du prix de détail suggéré par le fabricant (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
52 | Utilisation du montant financé (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
53 | Utilisation du taux financé (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
54 | Utilisation de terme financé (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
55 | Numéro de réclamation (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
56 | Numéro de série des emplois Utilisation (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
57 | Utilisation du compteur de kilomètres des emplois (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
58 | Heures d'utilisation des emplois (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
59 | Utilisation des fabricants d'emplois (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
60 | Utilisation du modèle de travail (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
61 | Utilisation des emplois par an (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
62 | Ajouter. Coûts Taux Utilisation (optionnel) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compter > 0 |
63 | Ajouter. Coûts applicables Montant d'utilisation (facultatif) | Vérifiez si le champ est utilisé au moins une fois. Puisque le champ est optionnel, le résultat est NA si le compte est 0. | Compte > 0 |
64 | Utilisation des types de coûts supplémentaires (facultatif) | Vérifiez si tous les types de coûts supplémentaires sont utilisés. . Impôt . Logistique . Remise . Autre | Compter > 0 |
65 | VIN unique pour les nouvelles unités | Le VIN dans une transaction UNITS utilisant la valeur CLASS_CODE NEW doit être unique. Vérifiez que le VIN exact n'est pas trouvé dans une autre transaction UNITS avec la valeur CLASS_CODE NEW. | Le compte est 0 |
66 | Aucune transaction avec seulement l'en-tête | Vérifiez qu'il n'y a pas de transactions avec seulement un en-tête et sans PARTS, JOBS ou UNITS. Cela peut se produire si le DMS envoie une transaction après avoir supprimé tous les éléments non-BRP, ne laissant rien derrière. | Le compte est 0 |
67 | Charges rejetées | Vérifiez qu'il n'y avait pas de charges utiles rejetées. Les charges utiles rejetées sont celles comportant des erreurs au niveau JSON, qui sont rejetées par l'API, et le DMS reçoit un code d'état 400. | Le compte est 0 |
68 | ID du consommateur de l'invité | Lorsqu'une vente de pièces est effectuée "en espèces", c'est-à-dire qu'il n'y a pas de compte consommateur, l'ID du consommateur est défini sur INVITÉ et le hachage est nul. | Compte > 0 |