Parcours de l'équipe

C'est l'horizon standard de trésorerie : assez court pour être fiable, assez long pour laisser le temps de réagir. Au-delà, la projection devient fiction ; en deçà, vous découvrez le problème trop tard.

Il ouvre la note de calcul : quelles écritures ont composé ce chiffre. C'est la preuve de la valeur — aucun chiffre de cet écran n'a besoin d'être accepté sur parole.

Le tableau montre le solde calculé de chaque compte bancaire actif : le solde initial saisi dans la fiche plus les règlements liés à ce compte depuis. Les comptes de PLACEMENT et d'ÉPARGNE apparaissent marqués car leur argent ne sauve pas la journée — il entre dans la carte « Placé / bloqué », pas dans le disponible. Un compte venu de l'ERP par le connecteur est identifié comme miroir.

L'écran indique combien d'encaissements ont été décalés, et la note de calcul de chaque jour/semaine montre l'échéance d'origine à côté de la date probable (ex. : « éch. 10/09, +12j selon le comportement »). Celui qui paie en avance est décalé vers l'ARRIÈRE. Le profil est recalculé à chaque projection, donc un client qui a amélioré son comportement améliore la projection tout seul.

Quand il y a assez d'issues (5 ou plus en 4 semaines), l'écran affiche l'erreur moyenne du prévisionnel (WAPE : somme des écarts divisée par la somme des prévisions). C'est le tableau des scores public de la projection : si l'erreur moyenne est à 6 %, le chiffre que vous voyez mérite confiance ; si elle est à 40 %, la projection vous raconte une histoire — et il manque probablement des échéances réalistes ou il faut activer la date probable. Sans échantillon suffisant la carte n'apparaît pas, car une précision calculée sur 2 jours est un indicateur qui ment.

La trésorerie, c'est la date de paiement. Une pièce de septembre qui échoit en novembre entre en novembre. Ce qui est déjà échu et reste ouvert entre dans la première semaine — un retard ne disparaît pas de la trésorerie simplement parce que la date est passée.

Un placement à rachat futur ne sauve pas la semaine prochaine. Tout additionner dans un seul solde revient à déclarer une solvabilité avec de l'argent qu'on ne peut pas retirer — c'est pourquoi les deux lignes apparaissent séparément.

Quand le solde cumulé devient négatif, l'écran montre la semaine, la taille du trou et combien coûterait de le combler. Le coût estimé utilise le taux d'escompte ; il sert à comparer avec le coût d'agir maintenant — négocier un délai, avancer un encaissement, reporter un achat.

Cet écran est 100 % financier — soldes, pièces, trous de trésorerie — il est donc entièrement bloqué par la gouvernance « Voir les valeurs » : sans cette permission dans le profil, l'avis d'accès apparaît à la place du tableau. Il n'existe pas de version partielle sans chiffres, car une trésorerie projetée sans valeurs n'informe de rien. Si quelqu'un de l'équipe doit suivre la trésorerie, il faut que l'administrateur accorde « Voir les valeurs » au profil de cette personne.

Quelques fois par jour, le système reprojette la trésorerie et, si une semaine passe sous zéro alors qu'elle ne l'était pas avant, vous recevez l'alerte immédiatement — avec la date et la taille du trou. Une alerte qui n'arrive qu'à la clôture signale un problème déjà survenu. La même alerte ne se répète pas tant que la situation ne change pas.

Le bouton Semaine/Jour change la granularité du MÊME horizon : les deux modes lisent les mêmes pièces, la même récurrence et le même solde. La somme des jours d'une semaine donne exactement le total de cette semaine — un test automatisé fait échouer le build si les deux calculs divergent, justement parce que deux écrans répondant « combien j'ai » avec des chiffres différents est le genre de défaut que personne ne remarque. Utilisez JOUR pour décider cette semaine (quel jour l'argent manque, combien) et SEMAINE pour voir la tendance.

Si le compte n'a pas de solde initial dans sa fiche, le chiffre affiché n'est que la somme de ce qui a été saisi ici — cela ressemble à un solde, mais n'en est pas un. L'écran indique combien de comptes sont dans cette situation ; renseignez le solde initial (et sa date) dans la fiche du compte pour que la position concorde avec le relevé bancaire.

Configurez TESOURARIA.SALDO_MINIMO dans les paramètres de l'entreprise pour recevoir l'alerte jaune dès le premier jour où la projection passe sous votre plancher de trésorerie. Elle est volontairement différente de l'alerte rouge : la rouge dit que l'argent est épuisé et combien coûte le secours ; la jaune dit qu'il va s'épuiser et que vous avez encore un choix peu coûteux. Sans le paramètre, l'écran indique que l'alerte est désactivée.

Un même solde final peut signifier des avenirs très différents. Si la trésorerie croît parce que l'EXPLOITATION la génère, l'entreprise se finance elle-même ; si elle croît parce qu'un EMPRUNT est entré, le même chiffre cache une dette qui reviendra en échéances. Les trois cartes séparent cela sur tout l'horizon, avec la même classification que le tableau des flux de trésorerie réalisé — la nature qui est du financement là-bas est du financement ici, toujours. L'achat d'une machine relève de l'investissement ; les impôts restent en exploitation (en trésorerie, l'impôt relève de l'exploitation).

Le panneau « Interrogez la trésorerie » répond à des questions comme « quel jour la trésorerie se tend-elle en premier ? » ou « quelles sont les plus grosses sorties de l'horizon ? ». Chaque chiffre de la réponse vient du tableau lui-même — l'intelligence artificielle a interdiction de faire des calculs de son côté, justement pour ne jamais inventer une valeur plausible mais fausse. Si la question demande une donnée que le tableau n'a pas, la réponse le dit au lieu d'estimer. Et si l'IA est indisponible, rien n'est perdu : les chiffres de l'écran restent valables sans elle.

Une question hypothétique (« et si je place 200 000 pendant 90 jours ? ») ne reçoit pas de devinette : le copilote oriente vers la création du levier correspondant dans l'écran Scénarios (placement, change, crédit, révision de prix ou mouvement), où le moteur calcule l'effet réel, mois par mois. C'est la même règle dans toute la Simulation : la machine saisit et calcule, la décision vous appartient.

Le bouton Échéance/Date probable change la date des ENCAISSEMENTS : en mode probable, chaque créance est décalée du retard typique de ce client — la MÉDIANE des retards de ses règlements sur les 12 derniers mois. Un client qui paie l'échéance du 10 tous les 22 apparaît le 22, là où l'argent arrive réellement. Un client avec moins de 3 règlements n'a pas de profil et reste à l'échéance — la plateforme préfère l'échéance brute à un comportement inventé à partir d'un échantillon qui ne prouve rien. Les décaissements ne se décalent jamais : payer à temps (ou non) est votre décision, pas une prévision.

Chaque jour, la plateforme fige le prévisionnel des encaissements et décaissements du jour et, le lendemain, le compare à ce qui a réellement été réglé. Quand l'écart dépasse les DEUX seuils (TESOURARIA.VARIANCIA_PCT et TESOURARIA.VARIANCIA_VALOR), le dirigeant reçoit la notification avec l'explication — y compris qui était à échéance ce jour-là et n'a pas payé, par nom et par montant. Un jour calme (rien de prévu, rien de réalisé) n'est ni une réussite ni un écart : c'est un jour calme, et il ne déclenche pas d'alarme.

La projection se réécrit chaque fois que quelqu'un ouvre l'écran — c'est pourquoi la question « que projetions-nous en juillet ? » n'avait pas de réponse. Une fois par période, la plateforme garde la PHOTO du prévisionnel (toute seule, dans le cycle quotidien), et le tableau affiche chaque photo à côté de ce qui s'est réellement passé dans le mois. Le bouton « Clôturer la période et faire glisser l'horizon » le fait immédiatement, et il est idempotent : cliquer deux fois ne duplique pas la photo et ne réécrit pas l'issue.

La photo garde le solde projeté à la fin de l'horizon de 13 semaines à ce moment-là ; le « réalisé » est le net que le mois a réellement produit (encaissements moins décaissements réglés). Ce sont des lectures proches mais non identiques par construction — la comparaison sert à voir la TENDANCE de votre erreur, pas à concorder au centime près.

Échéance montre le contrat ; Date probable déplace chaque encaissement à la date habituelle du client ; Probable × chance fait de même et multiplie le montant par la chance que le client paie dans les 60 jours après l’échéance. Un client avec moins de 3 titres échus depuis plus de 60 jours garde le montant total. Une promesse de paiement n’est jamais pondérée.

Cela arrive quand les pièces n'ont pas encore été générées. La projection complète avec la récurrence des contrats en vigueur, mais seulement là où il n'existe pas de pièce — pour ne pas compter deux fois. Si l'horizon paraît trop vide, il y a probablement des contrats sans montant mensuel renseigné.

La classification vient du groupe comptable de la nature financière de la pièce. Une pièce dont le groupe n'a pas été renseigné entre en exploitation — ce qui est le défaut du tableau des flux — au lieu d'être exclue du calcul. Si votre flux de financement paraît plus faible qu'il ne devrait, vérifiez le groupe comptable des natures d'emprunt dans Référentiels › Natures financières.