Statistiques sur les commandes Prestashop

Objectif :

• Faire des rapprochements avec la comptabilité.
• Passer en compta un CA cohérent avec les stocks (concept de cutoff comptable)

Règles comptables :

• Le CA d’un mois doit correspondre aux factures émises un mois donné.
• Il faut que le stock en fin de période soit cohérent avec le chiffre d’affaire de la période.
• Le paiement ne joue pas sur le calcul du chiffre d’affaires (peut-être pas pour les auto entrepreneurs qui pratiquent une comptabilité sur les encaissements et qui ne tiennent pas de comptabilité au sens propre).

Chiffre d’affaire et paramétrage dans le statut des commandes de Prestashop.

Par défaut dans Prestashop, la facture est « créée » lorsque le paiement est accepté. Il peut-être préférable de considérer que c’est l’expédition qui crée la commande.

Sur chaque statut de commande il existe le paramètre « autoriser le client à voir et télécharger sa facture PDF ».  Si on décoche ce paramètre sur le statut « paiement accepté » la facture sera générée lorsque la commande atteindra le statut qui va bien ( « en cours de livraison » par exemple). Prestashop est bien au point sur ce coup là, la date de la facture de Prestashop est la date de l’expédition si on a choisi ce paramétrage.

Système de statistiques.

Pour faire mes statistiques et rapprochements,  j’utilise Microsoft Access, ODBC et une base MySQL installée en local.

J’ai expliqué plus ou moins pourquoi j’en suis arrivé à utiliser Access dans cet article sur l’export mensuel des commandes.

Requêtes préparatoires

• Dates des paiements : pour contourner le bug sur les statuts multiples, je sélectionne dans ps_order_history le minimum de la date pour le statut « paiement confirmé » par facture.
  

  SELECT ps_order_history.id_order, ps_order_history.id_order_state, Min(ps_order_history.date_add) AS DtPaiement
  FROM ps_order_history
  GROUP BY ps_order_history.id_order, ps_order_history.id_order_state
  HAVING (((ps_order_history.id_order_state)=2));

• Dates des expéditions : idem que ci dessus pour le statut « en cours de livraison ».

remarque : au lieu de scanner ps_order_history il y a aussi la table ps_orders qui contient, pour chaque commande une date de paiement et une date de livraison.

Requêtes de contrôle à passer chaque mois

• Est-ce que tous les articles de la base sont associés à la TVA qui leur correspond ?

Rapprochements

• Commandes payées non expédiées (utile pour le rapprochement de banque).

Synthèses

• Détail du CA du mois (pour synchroniser notre ERP)
• Détail des avoirs du mois

Annexe sur les tables de Prestashop

• ps_orders : champs intéressant : N° de commande, N° de facture, date de paiement, date d’expédition.
• ps_order_slip : avoirs. Pas de montant de l’avoir dans cette table. Il est à recalculer à partir des lignes + le port éventuellement (à vérifier).
• ps_order_slip_détail : lignes des avoirs. Font référence aux lignes des commandes.

Export mensuel des commandes

Pour une synchronisation mensuelle avec mon ERP et la comptabilité mon idée est de passer une seule commande et une seule facture par mois dans l’ERP pour régulariser les ventes du mois (les sorties étant faites au jour le jour.

Les données dont j’ai besoin :

• Article avec cumul par référence des quantité expédiées.
• Total des frais de port du mois (HT et TTC)
• Total du CA du mois (HT et TTC).
• la même chose pour les avoirs.

Une piste de solution : sortir les récap de pointage avec des requêtes sur la base mySQL.

Mon idée est de lancer chaque début de mois une requête SQL qui me rapatrie ces éléments. Cette requête SQL pourrait être incluse dans un petit programme PHP lancé automatiquement aux premières heures du premier jour de chaque mois.

Cette même idée est déjà évoquée par Legrenier dans cette discussion.

Comme lui, je ne suis pas très à l’aise avec toutes ces jointures SQL et pour m’aider je vais utiliser Access, ODBC et une installation locale de Mysql pour essayer de pondre les requêtes qui me conviennent. Voir sur ce sujet « comment utiliser Access pour écrire des requêtes SQL« .

Quelques trucs par rapport aux requêtes :

• Ne prendre que les lignes des commandes qui ont le statut ‘5’ (livré) dans l’historique => comment gérer le risque qu’une commande se retrouve avec 2 enregistrements de livraison (rien ne l’empêche dans le Back Office de Prestashop) ? pour cela le mieux est de faire d’abord un update de la table ‘ps_order_history’ avec un nouveau statut à créer (genre « passé en compta ») pour toutes les commandes livrées non passées en compta et de sélectionner ensuite les commandes passées en compta à une certaine date.
• J’abandonne cette piste pour passer à la suivante qui sera beaucoup plus simple pour moi.

Deuxième piste : extraire des données brutes et les traiter en local via Access

L’idée générale est ici d’extraire des données brutes des tables de Prestashop et de les traiter ensuite avec un outil en local (Microsoft Access dans mon cas).

Les traitements de contrôle réalisables :

• Vérifier que les factures dans Prestashop correspondent à des sorties dans l’ERP.
• Vérifier que les facturation Prestashop correspondent à des paiements.

Pour les extractions, plusieurs approches :

• Extraire juste les extraits des tables qui nous intéressent (Avantage : rapidité – incovénient : évolutivité, il manquera toujours un champ à l’usage).
• Extraire la totalité des tables « intéressantes » (Avantage : exhaustivité, évolutivité – inconvénient : montée en charge et temps de traitement)
• Travailler sur le dump de la base de donnée qui serait « remonté » en local (avantages : tout est possible, test de la sauvegarde mensuelle – inconvénient : procédure un peut trop complexe ?).