Le flux en un coup d’œil
- Correspondance des SKU et variantes
- Contrôle du catalogue et de l’accès API
- Réception et enregistrement des événements
- Création de commande et mise à jour des statuts
Prérequis avant réalisation
- Partenariat marchand actif et accès adapté
- Catalogue complet avec identifiants stables
- Règles convenues de stock, annulation et retour
- Accès de test à la boutique et à l’ERP
En un coup d’œil
L’intégration Skroutz combine catalogue, actualisation des prix et stocks, réception des commandes et gestion des statuts. Sa stabilité exige une identité produit commune et une responsabilité claire pour chaque donnée. Connecter le catalogue ne signifie pas automatiser les commandes.
Catalogue et actualisation du stock sont distincts
Le XML sert au catalogue complet ; Products API actualise disponibilité, prix et quantité sans créer de produits. Nous définissons des codes stables et vérifions variantes, images et disponibilité avant publication. Un SKU modifié dans l’ERP nécessite une correspondance contrôlée pour éviter de considérer le même produit comme nouveau.
Les commandes exigent une réception fiable
Orders API et webhooks couvrent commandes et modifications. Un webhook peut être répété : nous enregistrons donc l’identifiant externe avant la création locale. La réponse à la plateforme doit être séparée du traitement ERP. L’opérateur voit réception, enregistrement et éventuelle action en attente.
Préparer les envois sans automatisations erronées
Imprimer un bordereau et préparer réellement le colis sont deux événements distincts. Les boutiques soumises au programme obligatoire Set as Ready doivent déclarer séparément leur préparation. Nous relions cette action à l’emballage métier, pas au simple téléchargement d’un fichier. Annulations et retours nécessitent aussi des règles de stock distinctes.
Exemple de stock partagé avec un magasin physique
Supposons cinq unités d’un produit vendu simultanément en ligne, en magasin et sur Skroutz. L’ERP conserve le stock commercial ; la passerelle publie le disponible après réservations. Une commande est enregistrée une seule fois avec son canal et actualise la quantité vendable. Si l’ERP tarde, elle reste en file avec attente visible. Cet exemple décrit une conception, pas le résultat d’un client précis.
Contrôle avant et après activation
Nous testons même événement livré deux fois, changement de prix, rupture et annulation d’une commande réservée. Un échec ERP ne doit pas perdre silencieusement la commande. La surveillance inclut dernière mise à jour réussie et écarts par code. L’activation progressive de produits choisis permet de valider les règles avant tout le catalogue.
Contrôles d’acceptation avant exploitation
- Une commande locale par code externe
- Échec visible et répétition sûre de mise à jour
- Libération correcte du stock après annulation
- Envoi déclaré prêt seulement après préparation du colis
DU GUIDE À LA PRATIQUE
Un plan concret pour votre plateforme.
Dites-nous où votre plateforme rencontre des difficultés et ce qui doit être amélioré. Notre équipe relie le diagnostic à des interventions précises sur le code, les performances et l’infrastructure.
Examinons votre plateforme