Calendrier de paiements en production : un découvert de 7 000 EUR vendredi est visible dès lundi

Entreprise fictive. Chaque action dans Bimp est une fonction réelle du produit.

Le calendrier de paiements en production montre un trou de trésorerie plusieurs jours à l’avance, dès que les commandes clients, les commandes fournisseurs et les salaires y figurent. Voici la société fictive « Volt Alim », à qui le calendrier a montré lundi un découvert de 7 000 EUR pour le vendredi, alors que le comptable ne le remarquait d’ordinaire que le jeudi.

Vendredi, l’entreprise doit verser les salaires et payer deux fournisseurs. L’argent est sur les comptes et couvre presque les paiements. Presque.

Pourquoi le directeur découvre-t-il le trou le jeudi ?

« Volt Alim » (société fictive) fabrique des blocs d’alimentation, 40 personnes. Elle achète ses composants à des fournisseurs avec délai de paiement, et plusieurs gros clients paient en retard. Les paiements vivent à trois endroits : les contrats fournisseurs, les commandes clients et le tableau du comptable.

Dans ce système, un solde négatif ne devient visible qu’après le rapprochement des relevés. Le jeudi, le comptable fait le point et va voir le directeur.

Vendredi, il faut payer 41 000 EUR de salaires, 26 000 EUR au premier fournisseur et 13 000 EUR au second. Au total 41 000 + 26 000 + 13 000 = 80 000 EUR. Les comptes contiennent 64 000 EUR (39 500 à la première banque et 24 500 à la seconde). Le client « Technomonde » doit payer 9 000 EUR. Cela donne 64 000 + 9 000 - 80 000 = -7 000 EUR.

Le directeur a quatre jours pour corriger cela. Mais il l’apprend un jour avant.

Comment construire le calendrier de paiements de la production à partir des documents existants ?

Il n’y a pas besoin de tenir un tableau de planification séparé dans Bimp. Le calendrier se compose des documents que l’entreprise crée de toute façon. Chaque étape ci-dessous a son aide.

Étape 1. Comptes bancaires et relevés. Dans le référentiel des comptes bancaires, on crée les comptes de la société (Bank accounts and cash desks). Dans l’onglet « Integration » de la fiche du compte, on choisit le prestataire et on colle le jeton généré dans l’espace de la banque (Client-bank). S’il n’y a pas d’échange automatique, on enregistre le relevé dans un fichier Excel (jusqu’à 30 jours) et on le charge dans Finance → Transactions → Client-bank avec la source « From file » (Importing a bank statement from a file).

Étape 2. Commandes clients. Dans la commande de « Technomonde » de 9 000 EUR, on coche « Add to payment calendar » dans le bloc « Payment » et on indique le délai de paiement et la date d’encaissement. Pour la commande de « Réseau Énergie » de 20 000 EUR, paiement le mercredi de la semaine suivante, on fait de même (Customer order).

Étape 3. Commandes fournisseurs. Dans les deux commandes de composants, on coche le même interrupteur. Le délai « Full » permet d’indiquer une seule date de paiement, « Partial » découpe le paiement en plusieurs dates. Pour le premier fournisseur 26 000 EUR vendredi, pour le second 13 000 EUR également vendredi (Supplier order).

Étape 4. Salaires. Dans le document « Salary accrual » (calcul des salaires), on coche « Add to payment calendar » dans le bloc « Payment » et on indique « Payment date » et « Payment amount » : 41 000 EUR vendredi (Salary accrual). Si le document n’a pas été créé à l’avance, on ajoute le paiement à la main dans le calendrier : ouvrir le jour, cliquer sur Add, choisir « Expenses », le tiers et le montant (Payment calendar).

Que voit le dirigeant dans le calendrier le lundi ?

Ouvrez Finance → Payment calendar. Les jours avec encaissements sont verts, ceux avec dépenses jaunes. Dans la cellule du vendredi, en bas, figure le solde de trésorerie, et quand les dépenses prévues sont plus élevées, un montant négatif « Gap » s’affiche à sa place.

Recalculons le vendredi comme le fait le calendrier.

Vérification : 64 000 + 9 000 = 73 000, et 41 000 + 26 000 + 13 000 = 80 000. La différence 73 000 - 80 000 = -7 000 EUR.

Un clic sur le jour ouvre tous les paiements de cette date, on voit donc de quels documents se compose le négatif. Les filtres « Income » et « Expenses » ne laissent à l’écran que le côté voulu.

Comment combler le trou tant qu’il reste quatre jours ?

Il y a deux voies. Dans les deux cas, le directeur vérifie dans le calendrier, sans attendre le jeudi.

Première voie : reporter le paiement. Dans la commande du second fournisseur, on change la « Payment date » du vendredi au mercredi de la semaine suivante. Le fournisseur doit être d’accord, mais on peut négocier dès lundi, quatre jours avant le paiement. Vendredi, on obtient alors 64 000 + 9 000 - 41 000 - 26 000 = 6 000 EUR. Mercredi, 6 000 + 20 000 - 13 000 = 13 000 EUR, si « Réseau Énergie » paie les 20 000 EUR à temps. Il n’y a, par hypothèse, pas d’autres paiements ces jours-là.

Seconde voie : accélérer l’encaissement. Si « Réseau Énergie » paie 12 000 EUR avant vendredi, on obtient 64 000 + 9 000 + 12 000 - 80 000 = 5 000 EUR. C’est un appel au client au lieu d’une discussion avec le fournisseur. Le directeur tire du calendrier des chiffres précis : quel document, quel montant, quel jour. Avec ces chiffres, la discussion avec le client sur le paiement anticipé est courte, alors que celle avec le fournisseur sur le report serait plus longue.

Les deux voies peuvent se combiner. On reporte le plus petit paiement et on relance en plus l’encaissement, et le vendredi est couvert avec de la marge.

Comment le fait bancaire arrive-t-il dans le calendrier et le rapport ?

Quand « Technomonde » paie, l’opération arrive dans le relevé. On l’affecte avec le bouton « Income » : le système crée le document « Customer payment ». Après rattachement à la commande, le rond de la colonne « Alloc. » devient vert (Allocating bank statement transactions). Le paiement aux fournisseurs se crée à partir de la commande, et il solde la dette dans le calendrier (Supplier payment).

Vendredi matin, le rapport « Cash balance » à cette date montre le réel : 48 500 EUR à la première banque (39 500 + 9 000) et 24 500 EUR à la seconde, soit 73 000 EUR au total (Cash balance report). Le rapport ne prend que les soldes comptabilisés et ne tient pas compte des paiements prévus. C’est pourquoi il vaut mieux ouvrir côte à côte le calendrier et le rapport : le premier donne le plan des jours à venir, le second le montant réel sur les comptes.

Combien de temps prend la vérification hebdomadaire du calendrier ?

Chez Volt Alim, elle a été instaurée par une règle : chaque lundi, le directeur et le comptable regardent le calendrier sur deux semaines. Cela prend 15 à 20 minutes sur un seul écran. On active d’abord le filtre « Expenses » et on cherche les jours avec un trou. Puis on ouvre chacun de ces jours et on voit les documents qui le forment.

Si un jour ne contient qu’un seul gros paiement, on le reporte ou on accélère l’encaissement. Si les dépenses sont nombreuses et le trou petit, on regarde quels paiements ne sont pas critiques à la date prévue. Cette catégorie, dans la société fictive, se composait de fournisseurs avec des délais de 14 et 30 jours.

Le calendrier n’est honnête que dans la mesure où les documents sont complets. Une commande sans « Add to payment calendar » n’y apparaît pas. C’est pourquoi l’acheteur et le commercial cochent cette case dès la création de la commande, cela prend quelques secondes. Un paiement sans document, comme un loyer ou un impôt, s’ajoute à la main avec une saisie par mois.

Qu’est-ce que cela apporte ?

Le trou est visible quatre jours à l’avance au lieu d’un. C’est suffisant pour s’entendre avec le fournisseur ou relancer le client. Le jeudi, un tel accord n’aboutit presque jamais.

Chaque décision s’appuie sur un chiffre. Le directeur reporte 13 000 EUR au mercredi parce qu’il voit que 20 000 EUR arrivent le mercredi. Sans le calendrier, la même décision se prendrait à l’aveugle.

Les paiements sont au même endroit. Le calendrier se compose de documents que les commerciaux, les acheteurs et la comptabilité créent de toute façon dans leur travail, le tableau séparé du comptable devient donc inutile, et ses écarts avec la réalité disparaissent.

Sur la différence entre le résultat d’un rapport et l’argent sur le compte, lisez l’article Compte de résultat d’un fabricant : exemple commenté et mode de lecture. Les fonctions financières de Bimp sont réunies sur la page Finances.

Limites du scénario

Le calendrier de paiements ne montre que les paiements prévus issus de documents et saisis à la main. Il ne prévoit pas les ventes et ne construit pas de scénarios « et si ». Un paiement se reporte en changeant la date dans le document. Les salaires arrivent dans le calendrier par le bloc « Payment » du calcul ou par une saisie manuelle, et cette liste de sources est à vérifier sur votre version. Le rapport « Cash balance » ne montre que le réel. Les articles de l’aide sur lesquels reposent les étapes ont le statut « en cours de vérification », il vaut donc mieux comparer les noms des boutons avec votre version de Bimp. L’échange automatique avec les banques fonctionne pour les banques raccordées, pour les autres il reste l’import du relevé sous forme de fichier.

Bimp est un ERP cloud ukrainien pour les fabricants, et le calendrier s’y construit à partir des mêmes commandes que l’entreprise crée dans son travail quotidien.

Questions fréquentes