Extension ecommerce / dolibarr

(DOCUMENT DE TRAVAIL… EN COURS!!!)

Un petit point sur l’extension ecommere pour dolibarr, basé sur la version de tiaris. Afin de réponse a mes besoin, j’ai re-developpé ma propre version. Enf effet, la version original n’ayant absolument pas les capacité dont j’avais besoin .

Petit recap des fonctionnalités nécessaires :

  • import des archives (6 ans +/- 15 000 Clients pour un site)
  • gestion lors de l’import de la clôture des commande, de la génération de BL , de la clôture (si payé) des factures
  • gestion des import produit et catégories
  • utilisation des attribut de produits venant de ecommerce , et non implémenté dans dolibarr (creation d’un produit par couple produit + attribut), avec un référence unique
  • création de numéro de commande, facture , client personnalisé, indiquant à la fois les ref de dolibarr, celle du site ecommerce , et l’id du site ecommerce (plusieurs site couplé avec 1 seul dolibarr)
  • traitement automatisé des imports , et recherche d’existant (un même client inscrit sur 2 sites ecommerce, un produit en vente sur 2 sites.. ), et si l’automatisation échoue, ajout d’une action manuelle permettant de terminer l’import apres un choix manuel
  • Gestion de correspondance de statuts ecommerce vs dolibarr et les variante de document. (commande + bon de livraison + facture + paiement )
  • UTilisation d’un module de module pour le tratiement specifique par type de moteur ecommrece, liée à dolibarr
  • Suivi du stock

Afin de faire tous ca, il à quand même fallu ce retorusser les manches, et attaquer fort. Le mdoule utlise des table ecom_ temporaire pour assurer la liaison entre le site ecom et dolibarr. Il à dabord fallut restructurer un peu les tables, et ajouter des contrainte unique afin de garantir coherance de l’ensemble.

Base de données

Pour toutes les tables de liaison entre ecom est dolibarr, j’ai ajouté quelques colonne, afin de traiter la gestion des echange entre l’ecom et dolibarr apres import. Ces collone assure aussi un etat de l’import.

Les colonnes event_xxx

Les 3 colonnes supplementaire ajouté

event_type int(2) NOT null comment ‘0: init / 1 import ,11 import ok, 12 import attente, 13 import apres association manuelle , 14 import not Ok / 2 export, 21 export ok, 22 export attente / 3 no touch ‘,
event_update datetime NOT null,
event_check int(1) NOT null default ‘0’ comment ‘ -9 error , -1 error reload / 0 default / 1 ok / 2 check and no touch ok/ 3 Abandon  ‘,

Pour toutes les table, j’ai ajouté des clek unique sur les coupe doli_id, ecom_id, site_id afin de garantir l’unicité des données, et bloqué les doublon eventuel en plus des control php.

Colonne event_type:

Cette colonne prend comme valeur uun entier, et precise le type d’evenement concerné

Colonne event_update:

Elle prend comme valeur la date et heur lors de l’enregsitrement. C’est cette colonne qui determinera le sens du flux entre dolibarr et l’ecommerce lors du prochain control. Si la date de mise a jour est plus recente que celle de l’ecommerce, dolibarr poussera les donnée vers le moteur d’ecommerece. Si par contre c’est celle de l’ecommerce qui est plus recente, dolibarr assura une mise a jour de sa version locale.

Colonne event_check:

Cette colonne qui prend comme valeur un entiers, precise dans quel etat c’est terminé le processus precendent, et permet de desactiver certaine ligne (comptabilisé et ne seront plus jamais modifié, facture classé).  En outre cette colonne determine si le processus entre dolibarr et ecommerce et montant ou descandant, elle est couplé àla colonne precedent.

Ex:

  • dernier mouvement de type import, et date ecom update identique ou plus ancienne que date sur table local >> aucune action
  • dernier mouvement type import et date ecom update plus recente , nouvel import (synhro)
  • dernier mouvement type export et date ecom update plus recente ,  nouvel import (synhro)
  • dernier mouvement type export et date ecom update identique ou plus ancienne que date sur table local >> aucune action

Les modules enfants de l’extension ecommerce

Le module enfants, prend en charge, l’affichage des champs d’import / export lors de la configuration, et le traitement des donnée lors de l’import ou l’export, afin d’assurer la transition.

Il doit être defini lors de l’ajout d’un site ecommerce dans dolibarr, et ne peut être modifié par la suite. Pour chaque changement de moteur d’ecommerce couplé a dolibarr, il peut être necessaire d’ajouter et ajusté ce module ;

Fonctionnement

Ordre des imports , logique fonctionnelle

La gestion des import, et l’inter-dependance entre les données importés, impose une logique dans l’ordre des imports, Afin de préserver la coherance.

ex : les produit appartiennent à une categorie, les commande depende d’un client.

Aussi la logique d’import fonctionne comme suit:

  1. Parametres (1 fois, à la config)
  2. Clients et carnet d’adresse
  3. Categories
  4. Produits
  5. Commandes

Notez que la gestion via cron, impose cette logique. Mais lors d’un import contenant de gros volume d’archive (la boutique fonctionne depuis un certain temps déjà), il est important de n’initier les import de commande qu’une fois les synchro des autres données effectués

Specificités des categories

Les categories sont intement liées au produits. Toutefois, dolibarr intégrant ces propres categories, de même que chaque site connecté.

Aussi , pour chaque site, il est possible (et necessaire) de creer une categorie, et d’y associcé l’ensemble des categories creer pour le site courant.

Usage : Il est ensuite possible de creer la base du produits dans un second site, on lui precisant que celui ci appartient à une categorie d’un second site.

Les actions Différées (mécanisme de rattrapage)

Ces mécanismes de rattrapage assure la cohrerance du syteme est de sa gestion des données. En  effet, il peut être logique de synchroniser les stock pour un produit, sans pour autant modifié une adresse client plutot quand creer une nouvelle.

Lorsque le choix n’est pas possible de manière automatiser, une question reste en supsend afin que l’utilisateur l’ajuste manuellement (A terme, cet usage devrait permettre de choisir pour chaque type de data, le mode d’ajustement automatqiue possible , oui pour les stock et non pour la description).

Les action différées, sont les import ou export n’ayant pu être traiter automatqiuement. Elle necessite l’intervention humaine, et reste donc en attente. Elle peuvent concerner tous les type de données importées et sont souvent issue de l’incapacité de choisir , lorsque par exe, 2 contacts sotn presque identiques, mais avec quelques variances, ou lors de la detection de client en doublon.

Les class php , fonctionnement et usage

Cette extension contient plusieures class organisées comme suit:

  • les class Ecom_xxx , sont les class gerant la manipulation des données des table specifique à cet extension, et assurant la liaison entre le site ecommerce et dolibarr
  • Les class E_xxx , sont les class public, utilisé dans les pages, et assurant les process de manipulations de donnée, et qui ce charges des appels sur les class dolibarr, et sur les class d’exension
  • Les class ECS_xxx, sont des alias des class E_xxx, mais avec un singeltown, assurant une instanciation unique

Les class Ecom_xxx

A chacunes de ces class correspond une table dans la base de donnée nomme llx_ecom_xxx. Elle manipulent les données temporaire, et herite d’une class mêre, Ecom_Master. Ces class sont normalisé, et contiennent les methodes suivante:

  • create
  • fetch
  • update
  • UpdateCheck
  • delete

Les class E_xxx et ECS_xxx

Ces classes assurent la manipulation centralisé des données, les import et modification. Elle prennent en compte le site courant, et charge le module enfant pour ce type de site.

Les methodes public, l’ensmeble des class est orienté vers un type de donnée (client, carnet d’adresse, commande), mais peuvent être amené à manipuler les données d’autre type.

  • ActionDiffLoad
  • WsFetch
  • ecom2dolibarr convertion du retour de webservice en un object dolibarr
  • ImportAll import des nouveautées, et control recursif des donnée precendente
  • ImportOne import d’une ligne de donnée specifique
  • AdjustOne control et ou mise a niveau de donnée
  • CheckExactly control pour chercher une modification dans les synchro
  • findInSite (Obsolete)

Class ECS_xxx

Seul 2 class appartiennent à cette categorie, les class ECS_site, et ECS_log.

Ces class sotn appelé dans toutes les autre class de type E_xxx. Elle sont Obligatoire. Elle utilise le mecanisme de singeltown, aussi , pour obtenir l’occurence courante, il s’uffit d’utiliser la forme:

ECS_site::getInstance();

Class ECS_site

Cette class Assure le chargement de la configuration du site courant, Elle charge le connecteur du site, ainsi que sa configuration. Elle Assure aussi la liaison, pour les appel de methode  apparteant au connecteur, dans les synchronisation des clefs des données entre dolibarr et ecommerce.

Les commentaires sont fermés.