fix: utiliser array_column() plutot que array_map + reset (il y a un polyfill array_column en SPIP 3.2)

fix: ne pas se faire tromper par un mode de livraison deja choisi pour decider si une commande necessite une livraison ou non

fix: la fonction fixer_livraison_commande() vérifie qu'une livraison est bien nécessaire et sinon elle enleve les modes de livraison eventuellement deja choisi et n'a rien d'autre à faire

feat: 2 spip-cli pour générer un nouveau CSV des modes de livraison à partir de ceux en base et reimporter pour mettre à jour les tarifs de ceux qui sont en base
Refs: #12

Refs: #12

feat: permettre de passer un tableau de details au lieu d'un id_commande, qui doit contenir une cle id_detail

feat: un filtre |panier_estimer_cout_livraison pour estimer le cout de livraison d'un panier (fix #13)

fix: dans le calcul des modes de livraison lister les details de commande concernés par chaque mode pour pouvoir générer les bordereaulivraisons à partir des infos en base

fix: noter les date_envoi et date_livre sur les bordereaulivraisons lors de leur changement de statut

fix: lors de la distribution des modes de livraison d'une commande on génère les bons de livraison associés à chaque mode de livraison

fix: prendre en compte le statut envoye ou retourne d'un bordereaulivraison et repercuter sur la commande

fix: affinage des transitions de statut sur les BL, avec possibilite de revenir en arrière en cas de fausse manip

feat: permettre de définir un seuil de commande pour des frais de port gratuits et permettre de passer une reduction a la fonction fixer_livraison_commande() pour gerer le cas de ces frais de port gratuits

fix: un objet sans champ 'immateriel' est forcement un objet immateriel qu'on ignore pour la livraison

Refs: #15

fix: definir une fonction objet_livraison_necessaire() que l'on utilise partout où l'on a besoin de savoir, plutot que de répéter des tests identiques au risque de se tromper et d'incohérence.
Du coup on enrichi le test pour résoudre #15:
- si l'objet a un champ 'immateriel', alors son caractère livrable dépend de la valeur de ce champ
- sinon, on regarde si il a des cactéristiques de poids et volume, et dans ce cas il nécessite bien d'être livré
- sinon, on regarde si il a une fonction mesure() et dans ce cas il nécessite bien d'être livré
- sinon c'est un objet qui ne nécessite pas de livraison
Par défaut, un objet sans poids ni volume ni champ immatériel ne nécessite donc pas de livraison

refactor: le 3ème arguments de fixer_livraison_commande() est un array `$options` qui permet d'indiquer une reduction eventuelle sur les frais de livraison

tcharlss a rédigé mars 20, 2020 et cerdic a validé mai 02, 2023

Premier jet d'un nouveau formulaire à utiliser en alternative de adresser_commande : il ne fait que proposer le choix du mode de livraison, sans s'occuper de l'édition des adresses. On est censés avoir défini l'adresse de livraison en amont, de la façon dont on veut : soit enregistrée dans la commande, soit via le plugin coordonnées, etc. Pour l'instant on doit passer le pays et le code postal en paramètre, pour la suite réflechir à une façon générique de récupérer l'adresse de livraison de la commande quelle que soit la méthode choisie.

tcharlss a rédigé mars 24, 2020 et cerdic a validé mai 02, 2023

Mutualiser le résumé d'un mode de livraison entre les 2 formulaires + le nouveau param de fixer_lirvaison_commande est optionnel

tcharlss a rédigé mars 24, 2020 et cerdic a validé mai 02, 2023

Utiliser la nouvelle API commandes_client pour obtenir toutes les infos nécessaires à la livraison/facturation.
- Tout doit venir de cette API, quelque soit la source primaire.
- Symétriquement, on renseigne l'API via le pipeline commandes_infos_client quand les infos de livraison/facturation ont été figées en dur dans la table des commandes (ne fera rien si on utilise pas ces champs parce que uniquement le plugin coordonnees par exemple)
- On utilise l'API client aussi pour rempli la facturation DSP2 de Bank (mais du coup il me semble que cette partie devrait migrer vers le plugin commandes)

(Pas de changement de version du nécessite pour l'instant puisque cette API est aussi dans une PR)

refactor: mutualiser la recherhe pays+cp dans une fonction livraison_commande_choisir_cp_pays() qui prend id_commande et options en argument

fix: toujours vérifier la saisie utilisateur qui peut etre innatendue, malveillante, ou plus cohérente avec les infos en base si l'utilisateur a attendu longtemps avant de choisir son mode de livraison

Merge PR 'Formulaire de choix de mode de livraison et adaptation à l'API infos_client de commandes' (#18) from issue_4_refactor into master

Reviewed-on: https://git.spip.net/spip-contrib-extensions/livraison/pulls/18


Reviewed-by: rastapopoulos <rastapopoulos@noreply.git.spip.net>
Reviewed-by: tcharlss <tcharlss@noreply.git.spip.net>

Refs: #4

build: mise à jour des necessite, car le plugin ne fonctionnera pas correctement avec un vieux plugin commandes (et on prends la même valeur que ce dernier pour le plugin saisies)

fix: si on renseigne le nom/societe de facturation dans la commande, ça joue aussi, certains sites ne renseignant QUE la facturation si adresses identiques (vu que c'est celle qui contient le no de tva)

Refs: #19

fix: éviter un warning lors du passage dans le pipeline post_edition lorsque `$flux['args']['action']` n'est pas défini...

...cf. spip/spip#6049.

Fix: #20

Refs: #21

Refs: #12

fix: un détail de commande peut très bien être "arbitraire", ie. n'avoir ni `objet` ni `id_objet` (#23)

Refs: #23