Prix et paiements
HoopoTrack suit un travail du dépôt au retrait. Cette page traite du volet argent de ce même travail, et de rien d’autre : le prix, un devis que le client approuve, les acomptes et les paiements reçus à votre comptoir, le reste à payer jusqu’à ce que le travail affiche « Payé en totalité », la remise au client depuis le tableau, le comptage de la caisse en fin de journée, et une vue « Paiements » avec un export CSV pour votre comptable. Un atelier qui ne saisit jamais de prix voit l’application exactement comme avant.
Ce que c’est, et qui le voit
Les prix et les paiements font partie des forfaits payants, et la page des forfaits le dit sur une ligne à part : « Prix et paiements », qui affiche « Inclus » ou « Non inclus » sur chaque forfait. Sur un forfait qui ne l’inclut pas, le propriétaire voit une seule ligne sur chaque page de ticket, à la place qu’occuperait l’argent : « Les prix et les paiements font partie des forfaits payants. » avec « Voir les forfaits » à côté. Le personnel ne voit rien du tout, et rien n’apparaît sur le formulaire d’enregistrement, la liste des tickets, le tableau du comptoir ni la page de suivi.
Dans votre équipe, l’argent est une autorisation comme les autres. Le propriétaire l’a toujours. Un membre du personnel doit avoir « Gérer les paiements » coché sur son compte avant de pouvoir fixer un prix, envoyer un devis, ou enregistrer, annuler ou rembourser un paiement ; sans cette case, il voit qu’un travail a un reste à payer ou est payé en totalité, jamais combien, et aucun bouton lié à l’argent qu’il ne pourrait pas utiliser. Une seconde autorisation, plus petite, « Voir le reste à payer », se trouve en dessous : avec elle seule, un membre lit le chiffre, « Reste à payer 320 MAD », partout où la pastille apparaît, et toujours aucun prix, aucune ligne de devis, aucun paiement et rien qui enregistre. Équipe et clients décrit le comportement des deux cases sur le formulaire du personnel.
Chaque montant est écrit dans la devise de votre atelier, celle réglée sur votre profil d’atelier, avec son code après le chiffre : « 320 MAD », « 1 250,50 MAD », jamais un nombre nu. Les montants entiers perdent leurs décimales. Dès qu’un seul paiement a été enregistré, la devise ne peut plus être changée depuis les paramètres ; le champ dit « La devise ne peut plus changer une fois des paiements enregistrés. Contactez le support si nécessaire. » C’est cette règle qui empêche un rapport d’additionner deux devises.
L’argent ne bloque jamais le travail. Aucun champ d’argent n’est jamais obligatoire ; un ticket se crée, avance, se termine et se supprime sans aucun prix, et rien n’est retenu parce qu’un reste à payer n’est pas réglé. L’argent est un panneau latéral du travail, pas une étape : il n’ajoute jamais une étape de plus au « Étape 2 sur 6 » du client, n’apparaît jamais sur aucune des deux chronologies comme une étape à part, et ne change jamais la couleur de la pastille d’étape. Là où l’application a quelque chose à dire sur l’argent, elle le dit sous l’étape, pas à sa place.
Toute la fonction peut être coupée pour votre atelier depuis l’onglet Réglages de la page Paiements, et un atelier qui passe à un forfait sans elle se retrouve dans la même situation. Dans les deux cas, tout ce qu’il a enregistré est conservé : en lecture seule, toujours sur le ticket, toujours dans le CSV. Rien de nouveau ne peut être ajouté, un devis encore en attente du client est retiré, et les clients cessent de voir les montants. La réactiver, ou revenir à un forfait qui l’inclut, permet d’ajouter de nouveau ; un devis retiré le reste. La page du ticket dit de quel cas il s’agit en une ligne au-dessus des enregistrements. Fonction coupée : « Ces enregistrements sont conservés. Les prix et paiements sont désactivés pour votre atelier ; ils peuvent être réactivés dans Paiements › Réglages. » Forfait sans elle : « Ces enregistrements sont conservés. L’ajout de prix et de paiements est inclus dans les forfaits payants. »
Un prix et un acompte à l’enregistrement
Le formulaire d’enregistrement gagne une ligne repliée, « Prix (facultatif) », entre la personne assignée et la description. Fermée, elle ne coûte rien au chemin ordinaire. Ouverte, c’est un seul champ de montant dans votre devise. Ce chiffre unique est la façon dont la plupart des comptoirs font un devis, et le formulaire ne vous oblige pas à détailler : « Détailler » est un lien qui transforme le total en lignes (« Ajouter une ligne », chacune avec un libellé tel que « ex. Main-d’œuvre » et un montant), et « Une remise est une ligne avec un montant négatif. » dit comment s’écrit une remise. Le « Total » est additionné pour vous.
Sous le montant, « Accord du client au comptoir » commence décoché. L’accord est un acte du client, donc l’application ne l’enregistre jamais par défaut ; le cocher est une pression au même endroit, et cela fait du prix un devis accepté dès la première minute. Laissé décoché, le prix est enregistré comme un devis en brouillon, que vous pourrez envoyer pour approbation plus tard. Le client ne voit jamais un brouillon.
« Acompte versé maintenant » ouvre un montant et les pastilles de moyen de paiement, la même commande que vous retrouverez sous le nom « Enregistrer un paiement ». Un acompte est un paiement partiel : il compte dans le total, et il revient par Rembourser si le travail n’a pas lieu. Il est enregistré comme paiement dès que le ticket est enregistré, et le panneau « Ce ticket » à côté du formulaire gagne une ligne « Prix » et une ligne « Acompte » dès que vous les tapez.
Le reçu que vous remettez à l’enregistrement imprime l’acompte dans tous les cas, sous la forme « Acompte reçu 100 MAD · Espèces », parce que le client tient le reçu de cet argent. Il n’imprime le prix et le reste à payer que si le prix a été accepté ; un prix en brouillon n’imprime rien, car un reste à payer sur un chiffre que le client n’a jamais accepté est une réclamation plutôt qu’un enregistrement. La ligne n’est montrée qu’aux personnes qui gèrent les paiements ; le personnel sans cette autorisation voit le formulaire tel qu’il a toujours été.
Les montants se tapent comme votre clavier les écrit : les chiffres arabes orientaux et l’un ou l’autre séparateur décimal sont acceptés et lus correctement. Un montant qui a plus de décimales que votre devise est refusé avec un message plutôt qu’arrondi, si bien que ce qui est enregistré est toujours exactement ce qui a été tapé.
Les devis
Sur la page du ticket, l’argent tient dans une seule carte, « Prix et paiements », juste sous les détails du ticket dans la colonne latérale. Sa première ligne est la réponse que le comptoir attend : « Reste à payer 320 MAD », « Payé en totalité » ou « À rembourser 50 MAD », avec « Enregistrer un paiement » à côté. Viennent ensuite le prix accepté, marqué « Accepté », l’état du devis, ses lignes quand il en a, les « Paiements » et un « Historique ». Le même reste à payer se trouve aussi en pastille dans l’en-tête du ticket, à côté de la pastille d’étape ; sur un téléphone, où la carte est loin en bas de page, toucher la pastille vous y amène. Sur un ticket sans prix, la carte est un seul lien discret « Ajouter un prix » et rien d’autre : pas de chiffres vides, pas de tableau, pas de mention.
Un devis est l’une de six choses, et la carte dit laquelle : « Brouillon », « En attente du client » une fois envoyé, « Approuvé », « Refusé », « Remplacé par une version plus récente » ou « Retiré ». « En attente du client » est la formule que la liste des tickets et le tableau emploient déjà pour une étape ou une question restée sans réponse, si bien qu’un devis envoyé se signale par cette seule mention familière plutôt que d’en ajouter une seconde. À la différence d’une question, un devis envoyé ne retient pas le travail : vous pouvez continuer à faire avancer le ticket pendant que le client décide.
« Envoyer pour approbation » ouvre une fenêtre construite comme « Poser une question au client » : elle montre les lignes et le total exactement comme le client les verra, vous laisse choisir les canaux qui peuvent atteindre ce client, et envoie. Un devis sans lignes a besoin d’une ligne à lui avant de partir, « Ce que comprend le devis », parce qu’un client qui lit sur son téléphone n’était pas au comptoir pour l’entendre ; la fenêtre le dit : « Indiquez ce que comprend ce devis, pour que le client sache ce qu’il accepte. » Un prix accepté en personne n’a pas besoin de cette ligne. Décochez tous les canaux et le message est honnête : « Devis enregistré. Le client n’a pas été prévenu. Il figure sur sa page de suivi. » Sinon : « Le devis a été envoyé au client. » L’envoi n’est pas proposé sur un ticket terminé ni pour un client anonymisé, pour les mêmes raisons qu’une question ne l’est pas.
Une fois envoyé, un devis est figé : ses lignes, son total et sa ligne « Ce que comprend le devis » sont ce que le client approuve, et rien ne les réécrit ensuite. Le client répond depuis sa page de suivi, et la carte l’enregistre : « Approuvé par le client le 12 oct. 14:32 », ou « Refusé par le client le 12 oct. 09:10 » avec la note qu’il a éventuellement laissée, citée là où se trouve la réponse. Votre atelier reçoit un e-mail dès que l’une des deux réponses arrive. Un prix accepté au comptoir est enregistré avec un nom au lieu d’une réponse : « Accord au comptoir, enregistré par … », suivi de qui l’a coché et quand.
Si une étape qui demande l’approbation du client est ouverte au même moment, le client ne reçoit pas deux cartes pour une seule décision. La carte du devis porte la question de l’étape sous les lignes, et un seul « Approuver » ou « Refuser » est enregistré sur les deux, si bien que l’étape est libérée et le devis accepté par la même pression. La fenêtre d’envoi vous dit avant l’envoi que le client répondra aux deux ensemble.
Un changement de prix après l’accord du client est une nouvelle question, jamais une correction. « Modifier » sur un devis envoyé ou accepté crée une nouvelle version, montrée à vous pendant que vous la composez et au client pendant qu’il y répond, avec l’ancien chiffre à côté du nouveau : « Avant : 350 MAD, maintenant : 420 MAD ». Tant que cette version n’est pas envoyée et approuvée, ou acceptée au comptoir, le montant précédent tient : il reste marqué « Accepté », le nouveau se place à côté comme « Nouveau devis, pas encore accepté », et le reste à payer est calculé sur le montant accepté. Quiconque gère les paiements peut le faire, et seulement de cette façon ; personne ne modifie directement un devis accepté, le propriétaire compris. Une remise sur le prix, accordée au retrait, suit le même chemin, acceptée en personne.
L’« Historique » est la réponse à « vous aviez dit 350 » : une seule liste chronologique de chaque version du devis, paiement, annulation et remboursement, le plus ancien en bas, chacun avec qui et quand, et des lignes de version telles que « v2 · Approuvé · 420 MAD » et « v1 · Remplacé par une version plus récente · 350 MAD ». Il s’ouvre tout seul dès qu’il y a plus d’une version, pour que la réponse ne soit pas derrière une pression au moment précis où on en a besoin. Les paiements annulés dans les secondes qui suivent leur enregistrement se replient en une ligne discrète « 1 annulé » plutôt que de l’encombrer.
Le reste à payer est calculé, jamais tapé : le total accepté, moins les paiements, plus les remboursements, les lignes annulées mises à part. Aucun écran n’a de champ « reste à payer » ni « montant payé », et personne ne peut taper « Payé en totalité » ; la mention apparaît quand l’arithmétique le dit. Tant que rien n’est accepté, vous voyez un reste à payer sur le brouillon, sous l’intitulé « Sur un devis que le client n’a pas encore accepté », et le client ne voit aucun reste à payer. Quand un prix plus bas est accepté après que le montant complet a été payé, le reste à payer change de sens et affiche « À rembourser 50 MAD », dans le ton d’avertissement, avec « Rembourser » à côté.
Enregistrer un paiement
« Enregistrer un paiement » ouvre un volet qui monte du bas sur un téléphone et une fenêtre au milieu d’un grand écran. « Montant reçu » est prérempli avec le reste à payer, et le premier de vos moyens de paiement acceptés est déjà sélectionné, si bien que le cas courant tient en deux pressions : ouvrir, confirmer. Le bouton de confirmation porte le chiffre qu’il est sur le point d’enregistrer, « Enregistrer 320 MAD », pour qu’un montant mal tapé soit lu avant d’être gardé.
Les pastilles « Moyen de paiement » sont les moyens que votre atelier accepte, dans un ordre fixe avec « Espèces » en premier : « Espèces », « Carte », « Virement », « Paiement mobile » et « Autre », qui demande « De quoi s’agit-il ? » et exige une réponse. Lesquels des cinq apparaissent se règle dans « Paiements › Réglages » ; un atelier qui n’accepte qu’un moyen ne voit pas de pastilles, seulement son nom. L’ordre est fixe à dessein : le moyen décide de ce que la caisse doit contenir en fin de journée, et une « Carte » restée sélectionnée du client précédent ferait discrètement sortir un paiement en espèces du comptage.
Tapez moins que le reste à payer et le volet dit ce qui restera : « Il restera 120 MAD à payer. » Tapez plus et il avertit sans vous arrêter : « C’est plus que le reste à payer de 320 MAD. Les 30 MAD en trop apparaîtront à rembourser. » Un trop-perçu est rare mais réel ; la cause habituelle est la somme tendue par le client tapée à la place du prix, et c’est pourquoi le bouton répète le chiffre. Un champ vide désactive le bouton, avec « Indiquez le montant reçu. » en dessous.
Après confirmation, un message affiche « Paiement de 320 MAD enregistré. » avec deux boutons : « Annuler », pendant dix secondes, et « Imprimer le reçu ». Annuler ne supprime pas le paiement. La ligne reste dans l’historique, repliée dans « 1 annulé » avec la mention « Annulé juste après l’enregistrement », et elle est laissée hors de chaque total et du comptage de caisse. Un paiement supprimé pour de bon pourrait déjà figurer sur un reçu imprimé ou sur la page du client, alors l’enregistrement le garde et dit ce qui s’est passé. Annuler appartient à la personne qui a enregistré le paiement ; toute autre le corrige par le chemin plus lent décrit ensuite.
Après les dix secondes, un paiement se corrige au grand jour. « Annuler ce paiement », sur la ligne elle-même, demande « Pourquoi l’annuler ? » et exige une réponse ; la ligne est alors barrée, affiche « Annulé par … » avec le nom et la raison, et cesse de compter. Un paiement qu’une journée déjà clôturée a compté refuse cela : « Ce paiement fait partie d’une journée déjà clôturée. Enregistrez plutôt un remboursement : il ira dans la journée en cours. », avec « Enregistrer un remboursement » qui ouvre le formulaire de remboursement prérempli avec son montant et son moyen de paiement ; rouvrir cette clôture, ce qui revient au propriétaire, le rend de nouveau annulable. L’argent rendu est un « Remboursement » : une ligne à part avec un moyen et une note, qui ne modifie jamais le paiement d’origine et ne peut pas dépasser ce qui a été payé sur le ticket. Chaque ligne, quel que soit son type (« Acompte », « Paiement » ou « Remboursement »), porte « Enregistré par … » avec le nom et l’heure, et n’apparaît jamais sans. Rien ne se lit comme payé si une personne ne l’a pas enregistré.
« Imprimer le reçu » ouvre le « Reçu de paiement » en 80 mm dans un nouvel onglet : votre atelier, le numéro du ticket, la date à l’horloge de votre atelier, le « Montant », le « Moyen de paiement », « Enregistré le 14 oct. 17:38 » et, sous « Après ce paiement », le reste à payer. Le papier du client ne porte jamais le nom d’un membre du personnel. Imprimer ne met pas fin au délai d’annulation, mais un Annuler pressé une fois le reçu sorti demande d’abord : « Le reçu est déjà imprimé » et « Si vous annulez, ce paiement est annulé. Demandez au client de vous rendre le reçu. », avec « Annuler quand même » et « Le conserver ». Le reçu d’un paiement annulé, s’il est réimprimé, porte « ANNULÉ » en travers. Les reçus du ticket lui-même changent aussi ; Impression, sur la page Tickets, dit comment.
La plupart des paiements ont lieu quand le client revient, alors c’est là que le reste à payer attend. Faire passer un ticket à son étape de retrait n’affiche aucune invite : ce passage se fait à l’établi, le client n’est pas là, et c’est le message de retrait qui porte le reste à payer. La carte du ticket terminé commence alors par « Reste à payer 320 MAD » et « Enregistrer un paiement », au-dessus de l’évaluation. Remettre au client, et un passage vers une étape terminée qui suit celle du retrait (une étape « Récupéré » ou « Livré »), demandent au contraire d’abord confirmation chaque fois que le ticket n’est pas réglé : « Il reste 320 MAD à payer. », « 50 MAD à rembourser. », ou « Un devis attend encore une réponse. », chacune avec l’action correspondante à côté de « Remettre quand même » ; quelqu’un qui ne peut pas enregistrer un paiement ne voit aucun chiffre, seulement « Ce ticket n’est pas encore réglé. » L’invite n’est jamais montrée sur l’avancement en une pression du tableau du comptoir, pour un passage ordinaire.
Un membre du personnel sans « Gérer les paiements » lit la pastille sans chiffre et, à la place de la carte, une phrase : « Reste à payer. Une personne qui gère les paiements peut l’enregistrer. » Elle énonce le fait sans envoyer un employé seul au comptoir chercher un collègue qui n’existe peut-être pas. Avec « Voir le reste à payer », le chiffre revient sur la pastille, et rien d’autre.
Remettre au client depuis le tableau du comptoir
Le tableau du comptoir affiche désormais par défaut votre étape de retrait, comme colonne des tickets prêts, sur tous les forfaits. Une étape terminée qui la suit, et les tickets déjà remis, restent derrière « Inclure les tickets terminés ». Chaque carte de la colonne des tickets prêts porte une action principale là où les autres cartes portent l’avancement. Sur une carte sans rien à payer, c’est « Remettre au client », une pression avec l’Annuler habituel de quatre secondes du tableau. Sur une carte avec un reste à payer, c’est « Enregistrer le paiement et remettre », et la carte porte la pastille du reste à payer. La pastille n’apparaît que dans la colonne des tickets prêts, là où l’on remet un travail à un client ; les colonnes en cours n’en portent jamais, et une carte payée n’en porte pas.
Remettre au client veut dire l’une de deux choses, et l’application choisit la bonne pour votre flux de travail. Là où le flux a une étape terminée après celle du retrait, remettre est le passage vers cette étape, et les messages de cette étape partent comme pour tout passage. Là où il n’en a pas, ce qui est le cas de tous les modèles intégrés, le ticket reste sur son étape et est simplement marqué comme remis, et aucun message n’est envoyé. Dans les deux cas la carte quitte la colonne des tickets prêts, et le ticket terminé affiche « Remis au client le … » avec la date et le nom de la personne qui l’a remis. Les travaux terminés avant l’existence de cette fonction comptent comme remis depuis le jour de leur achèvement et affichent « Remis au client le 3 mars 16:40 », sans nom.
« Enregistrer le paiement et remettre » ouvre un volet intitulé « Remettre le ticket T-1042 » : le client, le ticket et le reste à payer en grands caractères, puis le même champ « Montant reçu » et les mêmes pastilles de moyen que « Enregistrer un paiement ». Son bouton principal porte le chiffre, « Enregistrer 320 MAD et remettre », et fait les deux en une seule requête. En dessous, « Enregistrer le paiement seulement » prend l’argent sans déplacer le travail, et « Remettre sans paiement » est un bouton texte avec son coût écrit dessous : « Le montant restera dû. » Remettre un travail impayé n’est jamais une pression à l’aveugle, et n’est jamais refusé non plus ; le ticket compte alors parmi ceux en attente de paiement.
Qui obtient quel bouton suit les deux autorisations. Quelqu’un qui a « Gérer les paiements » et « Mettre à jour les étapes » obtient le volet ci-dessus. Quelqu’un qui peut déplacer les tickets mais pas gérer les paiements obtient « Remettre au client », qui sur une carte avec un reste à payer ouvre le volet en lecture seule : « Reste à payer » (avec le chiffre s’il a « Voir le reste à payer »), la ligne « Reste à payer. Une personne qui gère les paiements peut l’enregistrer. », et une seule action, « Remettre sans paiement ». Quelqu’un qui gère les paiements mais ne peut pas déplacer les tickets obtient « Enregistrer un paiement », qui enregistre et ne déplace rien. Quelqu’un qui n’a ni l’une ni l’autre n’a aucun bouton, comme aujourd’hui.
L’action combinée est envoyée aussitôt, et son message affiche « Paiement de 320 MAD enregistré. Déplacement vers Récupéré. » avec la ligne que le tableau ajoute toujours sur ce qui partira, puis « Annuler » et « Imprimer le reçu », pendant dix secondes. Ces dix secondes sont honnêtes parce que les messages que la remise déclenche sont retenus sur le serveur pendant ce délai et partent quand il se ferme ; pendant le délai, rien n’a été envoyé. Annuler annule le paiement (la ligne reste, repliée dans « 1 annulé »), abandonne les messages retenus, et remet la carte dans la colonne des tickets prêts comme si elle n’avait jamais bougé : « Le paiement est annulé et le ticket T-1042 est revenu à l’étape Prêt à récupérer. » Là où la remise était un marquage sans déplacement, le message affiche « Paiement de 320 MAD enregistré. Remise du ticket T-1042 au client. » et il n’y a pas de ligne sur l’envoi, parce que rien n’est envoyé.
Deux cas limites valent d’être connus. Si « Imprimer le reçu » a été pressé, Annuler demande d’abord, avec « Le ticket revient à l’étape Prêt à récupérer. » ajouté à la question, parce que le client tient peut-être déjà le papier. Et si le serveur refuse l’annulation (la connexion a lâché, ou le délai s’est fermé en route), la carte ne revient pas : le message dit « Impossible d’annuler. Le paiement et la remise au client sont maintenus. Annulez le paiement depuis le ticket. » Une carte qui paraît annulée au-dessus d’un paiement qui tient serait ici le pire résultat. Après le délai, un paiement s’annule avec une raison depuis la carte du ticket, et le ticket se ramène en arrière comme n’importe quel ticket.
Une remise au client peut être annulée seule, plus tard, depuis la carte du ticket terminé : « Annuler la remise au client », à côté de la ligne « Remis au client », pour quiconque peut mettre à jour les étapes, sur tous les forfaits. Cela efface le marquage (ou ramène un ticket passé à une étape terminée ultérieure vers celle du retrait), remet le ticket dans la colonne des tickets prêts, et n’envoie rien au client dans les deux cas : personne n’apprend une seconde fois que le travail est prêt, et personne n’apprend que la remise a été annulée. Le paiement n’est pas touché. Si l’un a été enregistré dans la même remise, le bouton demande d’abord, « Le paiement reste enregistré. Annulez-le séparément si nécessaire. », et l’annuler reste l’acte propre de la carte, avec sa raison. Le message affiche « Remise au client annulée. Le ticket T-1042 est revenu à l’étape Prêt à récupérer. »
Ramener un ticket remis vers son étape de retrait par n’importe quel autre chemin efface aussi le marquage, et ce passage envoie les messages de l’étape de retrait comme tout passage, ce qui est la différence avec « Annuler la remise au client ». La remise précédente n’est effacée dans aucun des deux cas : l’historique des étapes du ticket la garde en une ligne sous l’étape où elle a eu lieu, « Remis au client le … · … · annulé par … » nommant qui l’a annulée, ou « Remis au client le … · … · annulé par le retour à l’étape Prêt à récupérer », si bien que quand un client dit « je l’ai déjà récupéré », la réponse est sur la page. Rien de tout cela n’atteint la page de suivi.
Le bandeau du haut du tableau gagne l’argent du jour, à l’horloge de votre atelier. Le propriétaire lit « Reçu aujourd’hui : 2 050 MAD », net des remboursements, espèces comprises. Le personnel, ceux qui gèrent les paiements compris, lit « Reçu aujourd’hui hors espèces : 800 MAD », et dans la fenêtre du bandeau une ligne par moyen autre que les espèces avec un montant, puis « Espèces : comptées à la clôture » à la place des espèces. Le total courant des espèces est tenu à l’écart du personnel à dessein, pour que le comptage de fin de journée veuille dire quelque chose ; il lui parvient par ce comptage. La fenêtre, intitulée « Paiements du jour », porte aussi « 3 tickets en attente de paiement », qui ouvre votre liste de tickets filtrée sur les travaux terminés avec un reste à payer, la dernière clôture, et « Clôturer la journée ». Un jour sans rien de reçu laisse le chiffre de côté plutôt que d’imprimer un zéro.
Clôturer la journée
« Clôturer la journée » répond à une question : les espèces dans la caisse sont-elles ce que l’application dit que vous avez reçu ? C’est pour quiconque gère les paiements, le propriétaire compris, puisque la personne qui enregistre les espèces est celle qui les compte. Rouvrir une journée clôturée revient au propriétaire seul. Il y a une caisse par atelier, et rien ne vous presse de la compter : un atelier qui ne clôture jamais une journée ne voit que le bouton.
La période n’est pas le jour calendaire. Elle court de la clôture précédente (ou du tout premier paiement) jusqu’à maintenant, et le volet le dit sur sa première ligne, « Depuis ven. 19:42 », si bien qu’un retrait tardif enregistré après le comptage de ce soir appartient au suivant plutôt que de manquer à celui-ci. Une seconde clôture le même soir est normale.
Le comptage est à l’aveugle. Le volet s’ouvre sur un seul champ, « Espèces comptées », et un seul bouton, « Comparer », et rien d’autre : avant que vous pressiez Comparer, le montant attendu n’est pas du tout envoyé à la page, pour que personne ne compte vers un chiffre déjà vu. Comparer envoie votre comptage, et le serveur répond par le verdict, en mots et jamais en nombre signé nu : « La caisse est juste », « Manque de 20 MAD » ou « Excédent de 20 MAD ». Le manque et l’excédent sont tous deux montrés dans le ton d’avertissement, parce qu’un excédent est aussi un écart. Le propriétaire, qui lit le total courant des espèces sur le tableau toute la journée, est la seule personne dont le comptage n’est pas à l’aveugle, et le volet est le même pour tout le monde pour que l’enregistrement ne dépende jamais de qui a compté.
Sous le verdict, quand la caisse n’est pas juste, vient « Qu’est-ce qui explique l’écart ? », et la journée ne peut pas être clôturée avant la réponse. Puis la somme, disposée en colonne que l’œil peut additionner : « Fond de caisse », plus « Espèces reçues », moins « Espèces remboursées », égale « Attendu en caisse ». Le fond de caisse est repris de la dernière clôture et peut être modifié ici ; une modification est enregistrée avec qui l’a faite, parce qu’elle déplace le chiffre attendu. « Fond de caisse laissé » prend par défaut le fond de caisse et devient le chiffre de départ de la période suivante ; plus que ce que vous avez compté est refusé avec « Plus que le montant compté. » Enfin, « Hors caisse » liste, pour information, les totaux carte, virement, paiement mobile et autre de la période, une ligne par moyen qui a un montant et aucune ligne à zéro, les remboursements affichés comme « Carte, remboursement ».
Vous pouvez recompter après Comparer. Le champ reste modifiable, et le verdict, la somme et la limite du fond de caisse laissé suivent le nouveau chiffre sans second Comparer ; la ligne sous le champ dit « Vous pouvez recompter. Le premier comptage reste enregistré avec la clôture. » La clôture enregistre les deux chiffres : le premier comptage, envoyé avec le premier Comparer et retenu sur le serveur dès cet instant, qui est le signal honnête, et le dernier, que l’écart, la note et le prochain fond de caisse utilisent. La vue Paiements imprime « Premier comptage 1 450 MAD » sous une clôture seulement quand les deux diffèrent.
Enregistrer crée un enregistrement qui n’est jamais modifié : qui a clôturé, quand, la période, chaque chiffre et la note. Le tableau affiche alors « Journée clôturée à 19:42 par … » avec le nom, et l’entrée reste pour la période suivante. Un paiement qu’une journée déjà clôturée a compté ne peut plus du tout être annulé : Enregistrer un paiement explique le refus et le remboursement vers lequel il renvoie. L’argent rendu à un client est un remboursement, et un remboursement est toujours dans l’arithmétique, et atterrit dans la journée ouverte au moment où il est enregistré.
Le propriétaire ne peut rouvrir que la dernière clôture, puisque rouvrir une plus ancienne redécouperait les périodes de toutes celles qui la suivent. « Rouvrir cette clôture » demande « Pourquoi la rouvrir ? » et dit ce qui suit : « Cette clôture reste dans la liste. La prochaine clôture couvrira de nouveau cette période. » Rouvrir n’écrase jamais : la première clôture reste dans la liste, barrée, avec « Rouverte par … » et la raison en dessous, et une nouvelle clôture suit. Si deux personnes clôturent en même temps, le second enregistrement est refusé avec une ligne « Journée clôturée à 19:42 par … » nommant qui l’a fait, et le volet se recharge avec cette clôture. Rien ici n’est silencieux.
Vous pouvez clôturer la journée à deux endroits. Le bouton se trouve dans le bandeau en haut du tableau et aussi dans le bloc « Aujourd’hui » de la page Paiements, pour les mêmes personnes. Sur un téléphone, la ligne d'argent du tableau a toujours un bouton « Clôturer la journée » pleine taille ; une fois la journée clôturée et qu'il ne reste plus d'espèces à compter, il devient une pastille « Clôturée à 19:42 » qui ouvre l'enregistrement. Si le comptage couvre une période commencée avant aujourd'hui, le volet le dit : « Aucune clôture depuis : ce comptage peut donc différer de “Reçu aujourd’hui”, qui part de minuit. » Il dit aussi quand des paiements ou remboursements en espèces sur des tickets supprimés ont été laissés de côté dans ce qu'il attend en caisse.
La vue Paiements et le CSV
« Paiements » apparaît dans la barre latérale, après Clients, dès le premier enregistrement d’argent de l’atelier, et seul le propriétaire peut l’ouvrir. Elle est disposée pour répondre d’abord à « qui me doit quoi » et ensuite à « la caisse est-elle juste ».
En haut, « En attente de paiement » : les travaux terminés avec un reste à payer, le plus ancien en premier, chacun avec le client, le montant, « Prêt à récupérer depuis le 12 oct. » et « Enregistrer un paiement » sur la ligne. Puis « Aujourd’hui » : le total par moyen, les espèces en premier, pour que la caisse puisse être comptée, et « Dernière clôture : ven. 19:42 · La caisse est juste ».
En dessous, un sélecteur de période à l’horloge de votre atelier (« Aujourd’hui », « Cette semaine », « Ce mois-ci », « Autre période »), et pour la période : « Par moyen de paiement », « Total encaissé net » (paiements moins remboursements, lignes annulées mises à part), « Reste dû sur les travaux terminés », « Acomptes sur les travaux en cours », la liste intitulée « Paiements de la période », où les annulations sont barrées et les remboursements listés avec qui les a faits, et les « Clôtures de journée » de la période avec leurs verdicts. Une période sans rien dit « Aucun paiement enregistré sur cette période. » Un atelier qui n’a jamais enregistré de paiement lit une phrase et aucun zéro : « Aucun paiement enregistré pour l’instant. Ils apparaissent ici dès que vous en enregistrez un sur un ticket. »
« Exporter en CSV » est le fichier du comptable, et la ligne en dessous dit ce qu’il contient : « Une ligne par paiement, remboursement et annulation de la période : date, ticket, client, moyen de paiement, montant et qui l’a enregistré. » Les lignes annulées sont incluses avec leur raison, les montants portent le code de la devise, et un moyen que vous avez cessé d’accepter depuis figure toujours sur les paiements enregistrés avec lui.
Ce que voit le client
Un devis à approuver est une question, alors il prend la place que les questions ont déjà sur la page de suivi : l’onglet du navigateur et le bandeau en haut affichent « Action requise », et la carte se place juste sous le bandeau, avant la chronologie. Elle est intitulée « Votre atelier vous a envoyé un devis », avec « Envoyé par » suivi du nom de votre atelier et de la date (l’atelier, jamais un membre du personnel), la ligne « En attente de votre accord avant de poursuivre les travaux. », les lignes et le total exactement comme vous les avez envoyés, ou la ligne « Ce que comprend le devis » pour un chiffre unique, et pour un prix modifié « Avant : 350 MAD, maintenant : 420 MAD » au-dessus. Les boutons sont « Approuver 420 MAD » et « Refuser », avec « Voulez-vous indiquer pourquoi à l’atelier ? (facultatif) ». L’un comme l’autre ouvre la même confirmation que la page emploie pour une question, « Approuver ce devis de 420 MAD ? », en citant les lignes, pour que personne n’accepte une phrase qu’il a cessé de lire.
Après une réponse, la carte se replie dans la liste des questions déjà traitées, sous la forme « Vous avez approuvé ce devis le 12 oct. » ou « Vous avez refusé ce devis. L’atelier reviendra vers vous. », les lignes étant gardées comme la trace, pour le client, de ce qu’il a accepté. La page se rafraîchit toute seule toutes les 30 secondes, et une réponse à un devis que vous avez retiré ou remplacé pendant que le client le lisait est refusée plutôt qu’enregistrée sur l’ancienne version : « L’atelier a modifié ce devis. Voici le nouveau. » Une fois le travail remis au client, le devis cesse d’être quelque chose à quoi répondre : la carte n’apparaît plus sur la page de suivi d’un ticket remis, et un ancien lien Approuver ou Refuser est refusé avec « Ce travail est déjà terminé : il n’est plus possible de répondre ici. Contactez l’atelier si besoin. » Rouvrir le ticket fait revenir la carte, et la possibilité d’y répondre.
Sous les questions et au-dessus de la chronologie, une ligne discrète résume l’argent : « Devis 420 MAD · Payé 100 MAD · Reste à payer 320 MAD ». Elle n’apparaît que si « Afficher les prix aux clients » est activé dans « Paiements › Réglages » et qu’un prix a été envoyé ou accepté. Tant que le devis est seulement envoyé, ou a été refusé, la ligne porte l’acompte et aucun reste à payer, « Devis 420 MAD · Déjà payé 100 MAD », parce qu’un reste à payer sur un chiffre que le client n’a jamais accepté est une réclamation. À zéro elle affiche « Payé en totalité. » et rien de plus. Quand le travail est prêt à récupérer, le reste à payer rejoint aussi le bandeau en haut, sous votre adresse : « Reste à payer au retrait : 320 MAD », qui est le moment où le client en a besoin. Sur un ticket protégé par code PIN, tout cela attend derrière le code, comme tout le reste de la page.
Rien sur la page ne demande au client de payer. Il n’y a pas de bouton de paiement, pas de logo de carte et rien qui prenne de l’argent : « Déjà payé » est l’enregistrement, par votre atelier, de ce qui a été reçu au comptoir, montré en retour au client. Un devis que vous envoyez lui est toujours montré, quoi que dise l’interrupteur « Afficher les prix aux clients » ; cet interrupteur gouverne ce qui apparaît sans que personne l’ait choisi : la ligne des paiements, le reste à payer dans le message de retrait, et les montants sur les reçus du client.
Les messages portent le chiffre mais jamais les lignes ; celles-ci sont sur la page. Envoyer un devis adresse au client l’e-mail « Votre devis pour le ticket T-1042 : 420 MAD » avec la ligne « Vous pouvez l’approuver ou le refuser sur la page de votre ticket. » et un bouton qui l’ouvre, et lui écrit sur WhatsApp là où cela l’atteint, par un modèle approuvé par Meta. Sur un ticket protégé par code PIN, aucun message ne porte de montant : l’objet est « Un devis pour le ticket T-1042 », parce qu’un objet d’e-mail ou un aperçu sur écran verrouillé contournerait le code. Le message de retrait gagne une ligne, « Reste à payer : 320 MAD. », seulement si les prix sont affichés aux clients, si le reste à payer est supérieur à zéro, si le montant a été accepté et si le ticket n’a pas de code PIN. Notifications décrit comment ces messages sont choisis et comment vous voyez s’ils sont arrivés.
Sur papier, le reçu de 80 mm du client et la moitié détachable de la feuille A4 impriment les lignes « Devis », « Payé » et « Reste à payer » aux deux mêmes conditions, les prix affichés aux clients et un montant accepté ou un paiement fait ; un prix en brouillon n’imprime rien. Le reçu de paiement est décrit sous Enregistrer un paiement. Anonymiser un client retire son identité comme toujours et garde les montants, qui sont la comptabilité de votre atelier plutôt que les données personnelles du client.
Ce qui est enregistré, et ce qui ne l’est pas
HoopoTrack enregistre les paiements ; il ne les encaisse pas, et il n’émet pas de factures. Chaque reçu imprimé qui porte un montant le dit en une ligne, et les documents fiscaux reste dans l’outil que vous utilisez déjà pour cela. Rien ici ne se connecte à un terminal de carte, à une banque ni à un service de paiement en ligne, et aucun client ne se voit jamais proposer un moyen de payer par HoopoTrack.
Les enregistrements ne sont jamais réécrits en silence. Une annulation et un remboursement sont des faits nouveaux ajoutés à l’historique, avec une raison et un nom ; le journal d’audit garde chaque changement d’argent avec qui l’a fait, et un changement de ce qui est montré au client est toujours attribué sur la ligne elle-même, pas seulement dans le journal. Supprimer un ticket qui a des paiements revient au propriétaire, et la fenêtre dit à combien ces paiements se montent et que la suppression les retire de vos totaux ; le ticket reste dans Tickets supprimés pendant le délai habituel, et le restaurer ramène ses paiements avec lui. Supprimé définitivement, un ticket n’emporte aucun de ses paiements : ils restent dans la vue Paiements et dans le CSV, libellés comme « T-1042 (supprimé) · Karim », et toute journée clôturée reste telle quelle.
La politique de confidentialité dit la même chose : les prix, paiements et moyens de paiement qu’un atelier enregistre sur ses tickets sont conservés pour la comptabilité de cet atelier, et HoopoTrack n’encaisse ni ne traite aucun paiement. Les outils d’administration de la plateforme n’affichent l’argent d’aucun atelier. L’équipe support de HoopoTrack ne le voit qu’en se connectant à votre compte, comme elle le fait pour vous aider à résoudre un problème ; elle ne peut pas l’exporter depuis ce compte, et tout ce qui est modifié ainsi est enregistré.