Intégration de boutique avec Atlantis ERP : flux, prérequis et contrôles

Nous connectons la boutique à Atlantis ERP selon un flux précis et l’interface disponible de l’installation. La documentation publiée fournit un point de départ concret : contenu de catalogue organisé et export XML. L’intégration doit distinguer code interne, code de publication, titre, catégories, caractéristiques, photos, traductions et prix.

La documentation Atlantis publiée fournit un point de départ concret : contenu de catalogue organisé et export XML. L’intégration doit distinguer code interne, code de publication, titre, catégories, caractéristiques, photos, traductions et prix. L’étude définit les champs relevant de l’ERP et ceux gérés par l’équipe éditoriale de la boutique. Avant de publier un fichier, nous vérifions son exhaustivité pour qu’un export échoué ne supprime pas le catalogue existant ou ne remplace pas des prix corrects.

Le manuel officiel décrit les données e-commerce des articles, notamment catégories, prix, photos, caractéristiques et traductions, ainsi que la création de fichiers XML. Il mentionne l’activation e-commerce dans les paramètres de société et l’organisation des tables correspondantes. Cette documentation publique est ancienne et ne prouve pas à elle seule l’existence d’une API REST moderne ou d’une saisie bidirectionnelle des commandes. Ces possibilités sont vérifiées dans l’installation réelle avant accord sur le projet.

Une entreprise de mobilier utilise un code de publication différent du code interne de stock. Le XML passe d’abord en préproduction pour vérifier catégories, images, poids et traductions disponibles. Une nouvelle description grecque ne doit pas effacer l’anglaise parce que le fichier ne l’inclut pas. Le prix de publication sélectionné et l’inclusion éventuelle de taxe sont contrôlés avant modification du catalogue. Un fichier incomplet reste non publié, avec rapport à l’opérateur et conservation de la dernière version valide.

Un scénario critique apparaît lorsqu’une interruption d’export produit un XML incomplet. Nous conservons une référence externe et l’identifiant de destination confirmé avant de répéter l’action. Nous distinguons échec d’accès, rejet métier et résultat incertain. L’opérateur doit pouvoir examiner l’enregistrement et rétablir la situation sans répéter les étapes terminées. Nous convenons des champs journalisés et du responsable des éléments en attente.

Nous contrôlons un fichier incomplet, une traduction sans image et le choix correct du prix de publication. Pour chaque cas, nous documentons données initiales attendues, enregistrement final et statut visible au client. Nous ajoutons un échec d’autorisation et une interruption de réponse. Nous répétons un événement déjà confirmé et vérifions que son effet métier ne change pas. Le procès-verbal d’acceptation définit l’équipe responsable et les preuves nécessaires pour résoudre un écart.

L’étude initiale confirme : version Atlantis et module e-commerce actif ; catégories et données fabricants organisées ; transmission contrôlée et schéma XML clair. Avant production, nous documentons la correspondance du flux Données e-commerce Atlantis → export XML → Contrôle du fichier → catalogue de préproduction → Vérification d’exhaustivité → publication. Nous attribuons renouvellement des accès, surveillance et corrections. Toute modification de configuration ou règle métier convenue déclenche un contrôle ciblé. Nous commençons par ce flux précis et ajoutons un autre canal après clarification de sa responsabilité et de ses scénarios d’acceptation.