Rendre les factures non modifiables

  • Posts: 254
  • Thank you received: 7
2 weeks 6 days ago #369536

Bonjour,

Normalement, une fois qu'une facture a été émise elle ne devrait plus pouvoir être modifiée. Nous utilisons le plugin "attachinvoice" pour générer et envoyer une facture PDF à nos clients. Or depuis le back-office, il est tout à fait possible de modifier une commande, même confirmée. Sauf erreur, pour régénerer le pdf, il faut la repasser en "créée" puis de nouveau en "confirmée" (c'est le changement d'état qui déclenche la création de la facture). Toutes ces manipulations entraînent des distorsions possibles entre les factures pdf originelles envoyées en compta et celle (ou celles) envoyées aux clients suite à des "manips". Dans notre cas, ces manips sont parfois rendues nécessaires si le client se trompe de produit. D'un autre côté, il est souhaitable de pouvoir continuer à modifier des commandes qui ne sont pas encore confirmées.

Quelles sont vos préconisations en la matière ? Comment permettre à un administrateur de pouvoir modifier une commande sauf si elle est en statut "confirmée" ? Est-il possible de générer un avoir quand on annule une commande ? L'opérateur devrait pouvoir modifier une commande si pas encore confirmée (créée sans doute) mais aussi pouvoir annuler une commande confirmée.

La question se pose aussi encore plus crument dans la perspective de la facture électronique à venir.

Merci pour votre retour.

Cordialement,

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 84815
  • Thank you received: 13812
  • MODERATOR
2 weeks 5 days ago #369539

Bonjour,

Sauf erreur, pour régénerer le pdf, il faut la repasser en "créée" puis de nouveau en "confirmée" (c'est le changement d'état qui déclenche la création de la facture).

Actuellement, HikaShop génère la facture à chaque fois que quelqu'un appui sur le bouton pour récupérer la facture.
Donc, c'est toujours les données actuelles de la commande qui sont utilisées. Il n'est pas nécessaire de changer de statut.

Quelles sont vos préconisations en la matière ?

Difficile à dire. Cela dépend de la situation de chacun. Déjà, à la base HikaShop est un logiciel de vente en ligne, pas de facturation ou de comptabilité. Idéalement, ce que vous voulez faire, c'est faire une intégration avec votre système de comptabilité pour envoyer les informations de la commande à la confirmation, ensuite, faire générer la facture au logiciel de compta, et récupérer la facture sur le site pour la proposée dans le backend, les emails, le frontend, etc.
Les commandes ne sont pas modifiées sur le site, et si elles sont modifiées dans le logiciel de compta, il régénère une facture et la remplace sur le site.
Nous avons implémenté cela pour un client il y a 10 ans et cela fonctionne à merveille pour lui.

Comment permettre à un administrateur de pouvoir modifier une commande sauf si elle est en statut "confirmée" ?

Il n'y a actuellement pas d'option pour cela. Cela serait ajoutable assez facilement, mais je ne suis pas sûr que cela soit une solution idéale au problème. En effet, si vous avez un client qui vous demande de modifier une information dans son adresse après le paiement, la commande sera déjà confirmée, et vous ne pourrez alors pas la modifier.
Vous voulez sûrement pouvoir permettre la modification à tout moment mais bien noter qui fait quoi grâce à l'historique.

Est-il possible de générer un avoir quand on annule une commande ?

Dans HikaShop même, il n'y a pas de telle fonction. Cependant, avec le plugin PDF invoice ( www.hikashop.com/marketplace/product/18-plugin-pdf.html ), vous avez une option "credit note" (avoir en français) qui permet de générer des avoirs pour les commandes remboursées (après le paiement, donc quand la commande a été passée de confirmée à remboursée). Je ne pense pas qu'il y ai de raison de faire cela lorsque la commande passe de créée à annulée, vu que le paiement n'a pas encore été fait.

La question se pose aussi encore plus crument dans la perspective de la facture électronique à venir.

Tout à fait. Le système actuel est bancal car une mise en place propre est complexe.
Idéalement, je pense qu'il faudrait faire en sorte que si une commande avec un numéro de facture est modifiée, alors cela crée automatiquement une copie de la commande avec un nouveau numéro de facture, avec une colonne en plus "order_original_id" qui pointerait vers la commande originelle. Ensuite, le système rajouter les informations à la facture en tant que "facture rectificative" comme expliqué ici:
go.sellsy.com/blog/facture-rectificative

Please Log in or Create an account to join the conversation.

  • Posts: 254
  • Thank you received: 7
2 weeks 5 days ago #369546

Bonjour,

Merci pour cette réponse argumentée et complète.
Nous allons réfléchir de notre côté à la meilleure solution.

Bien cordialement,

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 84815
  • Thank you received: 13812
  • MODERATOR
2 weeks 5 days ago #369550

Merci. N'hésitez pas à revenir vers nous.
Nous sommes actuellement en réflexion pour implémenter une solution pérenne. Le dernier paragraphe de mon précédent message présente là où nous en sommes sur cette réflexion mais c'est potentiellement amené à évoluer avant que nous procédions à l'implémentation, notamment avec les retours de notre comptable avec qui nous sommes en relation pour l'e-facture.

Please Log in or Create an account to join the conversation.

  • Posts: 254
  • Thank you received: 7
1 day 22 hours ago #369747

Bonjour,

Je reprends le fil de cette discussion après échanges internes et avec les experts comptables.

Dans un premier temps, la solution idéale à nos yeux serait l'existence d'un statut "validé" qui empêcherait toute modification d'une commande par qui que ce soit (via le back-office, je sais bien qu'on peut modifier en base ! :-) ).
Le processus normal d'hikashop resterait inchangé y compris l'interface de modification du statut dans la vue en liste ou dans le détail d'une commande. On peut "forcer" une commande de "créée" à "confirmée" ou de "confirmée" à "annulée" etc...
Sauf que si on choisit "validé", on aurait un popup prévenant l'utilisateur qu'une fois validée une commande ne peut plus être modifiée. y compris son statut. Plus rien du tout. Un peu comme dans un logiciel de facturation. Tant qu'une facture est en "brouillon" ou en "proforma" on peut la modifier. Mais quand on clique sur le bouton "valider", on a un message nous prévenant que c'est "irrémédiable". Pour changer, il faudra faire un avoir puis refacturer correctement.

L'idée derrière ce mécanisme serait de temporiser le moment où une commande hikashop passerait de "confirmée" à "validée". Disons par exemple qu'après un mois, une commande confirmée peut être validée. Il n'y aura plus de modifs ou d'annulation. Cela nous permettrait de n'exporter en compta que les factures validées sur une période donnée tout en conservant la souplesse de gestion des commandes dans les jours suivant celle-ci.

On passerait par l'action en masse pour valider, par exemple le 10 novembre, toutes les commandes confirmées du mois de septembre. Cela permet de transférer en compta, certes avec un mois de retard, que des factures dont on est sûr qu'elles ne "bougeront" plus. Ni en compta, ni dans Hikashop.

Pensez-vous pouvoir implémenter une solution de ce type ? Si oui sous quelle échéance approximative ?

Sinon, en attendant un mécanisme "officiel", l'autre solution pour nous serait d'interdire toute modification du statut d'une commande dans la vue en liste quand cette commande est "confirmée". Il faudrait aussi invalider tous les boutons d'édition de la commande dans la vue détaillée dans ce cas. Il me semble que c'est assez simple à faire en override des vues concernées ? On regarde le statut, si c'est "confirmed", on n'affiche pas tous les liens d'édition/modification/ajout/etc... Quels seraient les pièges de cette solution pour vous ? Cela vous semble-t-il faisable à "moindre effort" ?

Merci pour votre retour.

Laurent

Please Log in or Create an account to join the conversation.

  • Posts: 84815
  • Thank you received: 13812
  • MODERATOR
1 day 15 hours ago #369751

Bonjour,

C'est en effet une idée intéressante. Plus simple pour nous de mettre en oeuvre un blocage des modifications via un statut spécial.
Nous allons voir pour implémenter cela.

L'échéance serait de quelques mois, car nous avons d'autres choses déjà sur le feu.

A court terme, ce que vous pourriez faire, c'est de changer le "order_type" des commandes validées. Ainsi, elles n'apparaitraient plus dans HikaShop, mais elles seraient toujours en base de données. Mais bon, les clients perdraient aussi leur accès aux commandes dans leur historique.

Sinon, oui, il faudra mettre en place des overrides de vue. C'est faisable. Le piège, c'est que même si vous cachez un bouton, l'URL de l'action du bouton est quand même appelable directement. Donc, une personne mal intentionnée, et avec les connaissances nécessaires, pourrait quand même modifier les commandes.

Please Log in or Create an account to join the conversation.

  • Posts: 254
  • Thank you received: 7
1 day 13 hours ago #369754

Bonsoir,

Merci pour le retour. On surveillera les nouveauté d'Hikashop ! :-)
En attendant, je vais essayer d'implémenter l'override pour "cacher" les possibilités d'édition. Les personnes qui ont accès au backend ne sont, en principe, pas mal-intentionnées. Cela ne présente donc pas un gros risque pour nous.

Laurent

The following user(s) said Thank You: nicolas

Please Log in or Create an account to join the conversation.

Time to create page: 0.066 seconds
Powered by Kunena Forum