Bouton Réessayer d'Octopia Connector : ce qu'il fait pas à pas

La voie normale : la déclaration part toute seule à la validation de la livraison

Le bouton n'est pas le chemin habituel. Quand vous validez un bon de livraison avec le bouton standard d'Odoo, que le module étend, le module déclare à Octopia les colis de chaque commande Octopia liée à la commande client de cette livraison. Si la livraison ne provient pas d'une commande client, il ne déclare rien, et seules les commandes de la même société que la livraison sont prises en compte.

Pendant cette validation, le module ignore une commande dans deux cas : s'il existe déjà, pour cette commande et ce bon de livraison, une déclaration à l'état Déclaré (Declared), ou si la commande a un mode d'approvisionnement qui n'est pas celui du vendeur. Le reste est déclaré.

Réessayer (Retry) est l'exception : il sert pour une déclaration restée à l'état Erreur que vous voulez renvoyer à la main. Ce qui suit décrit le code de la version 20 d'Odoo.

Quand Réessayer apparaît

Le bouton se trouve sur l'écran Déclarations d'expédition (Shipment Declarations), accessible par Octopia › Commandes › Déclarations d'expédition (Octopia › Orders › Shipment Declarations). Si vous ne voyez pas la section Octopia, il vous manque le droit Utilisateur Octopia (Octopia User). Le bouton existe dans Odoo 17, 18, 19 et 20.

Il n'est visible que lorsque le champ État (State) vaut Erreur. Avec les valeurs par défaut, qui laissent État à Brouillon (Draft), il n'est pas visible. Les valeurs d'État sont Brouillon, Déclaré et Erreur.

Avant de cliquer

• Ouvrez Octopia › Commandes › Déclarations d'expédition et repérez la déclaration qui est à l'état Erreur.
• Ouvrez sa fiche et regardez Commande (Order) et Bon de livraison (Delivery Order) : ce sont les deux données avec lesquelles le bouton déclarera de nouveau l'expédition.
• Vérifiez que État est Erreur. La méthode n'agit que sur les déclarations dans cet état ; les autres restent telles quelles.
• Gardez à l'esprit que le bouton ne reprend pas les deux garde-fous de la validation (celui du « déjà déclaré » et celui du mode d'approvisionnement) : il exige seulement que la déclaration soit à l'état Erreur.

Au clic : ce que fait le module, dans l'ordre

Voici ce qui se passe en coulisses. Cela vous aide à savoir à quoi vous attendre à l'écran.

• Le module prend, pour chaque déclaration à l'état Erreur, sa Commande et son Bon de livraison et les utilise pour déclarer de nouveau l'expédition.
• Il crée une nouvelle déclaration avec les colis de cette commande et de cette livraison. La déclaration d'origine n'est pas encore modifiée.
• Il se connecte à la plateforme avec le compte de la commande et déclare l'expédition avec l'identifiant Octopia de la commande et les colis.
• Si la plateforme l'accepte, la nouvelle déclaration passe à Déclaré avec sa date d'expédition et la commande Octopia est marquée comme expédiée.
• Alors, et alors seulement, la déclaration d'origine passe elle aussi à Déclaré. Le bouton disparaît de sa fiche, car elle n'est plus à l'état Erreur.
• Si la plateforme renvoie une erreur, la nouvelle déclaration reste à l'état Erreur avec le texte de l'erreur et le détail fourni par l'API, et la déclaration d'origine reste à l'état Erreur.

Après le clic

• Ouvrez dans Déclarations d'expédition la fiche de la déclaration d'origine et celle de la nouvelle, et regardez leur État et leur Commande.
• Si la déclaration d'origine est à l'état Déclaré, la nouvelle tentative a réussi.
• Si elle est toujours à l'état Erreur, le bouton reste visible et vous pouvez cliquer de nouveau, mais cherchez d'abord pourquoi elle a échoué.
• Gardez en tête que chaque tentative échouée laisse une nouvelle déclaration à l'état Erreur, avec la même Commande sur sa fiche.

Quelles erreurs peuvent survenir

Le code prévoit un échec précis : que l'API de la plateforme renvoie une erreur lors de la déclaration de l'expédition. Dans ce cas, le module la récupère, l'enregistre dans la nouvelle déclaration et la laisse à l'état Erreur. Le texte enregistré est celui de l'erreur de l'API plus son détail, il varie donc selon ce que répond la plateforme.

Que faire : consultez l'erreur enregistrée dans la déclaration, corrigez ce qu'elle indique et cliquez de nouveau sur Réessayer. La connexion passe par FlexigoTech Cloud, qui surveille la synchronisation et prévient par e-mail en cas d'échec.

Comment FlexigoTech vous aide

Les autres actions du module s'expliquent selon le même schéma : Envoyer à Octopia et Importer. Le module est publié sur Odoo Apps pour 17, 18, 19 et 20 (consultez sa fiche), il est en paiement unique par version et nécessite l'abonnement à FlexigoTech Cloud (plan Connecteur : 49 €/mois ou 490 €/an, HT). Cette connexion conserve les identifiants chiffrés. Si vous mettez en place Odoo et souhaitez revoir le flux des livraisons, ou si vous avez besoin d'une intégration sur mesure, FlexigoTech déploie Odoo 17, 18, 19 et 20 et développe des connecteurs et des intégrations sur mesure.

À lire aussi

Vérifié dans le code du connecteur (version 20.0) et dans les sources citées

Sources

• Code du module : flexigobe_octopia_connector 20.0 (4848da6a): views/octopia_order_actions_views.xml
• Code du module : flexigobe_octopia_connector 20.0 (4848da6a): models/octopia_order_actions.py
• apps.odoo.com/apps/modules/20.0/flexigobe_octopia_connector
• flexigotech.com/en/services.html
• flexigotech.com/precios.html