Payer les facturesLe processus "Traiter les dettes fournisseurs"Lorsqu'un organisme achète des biens et services à ses fournisseurs à crédit, il reçoit des factures qui constatent la dette ainsi contractée. Chaque facture doit être réglée à son échéance au fournisseur qui l'a émise. Voici schématiquement à quoi peut ressembler ce processus de réglement :
Cet article aborde l'aspect trésorerie, pas l'aspect comptable qui sera traité ultérieurement. La seule sortie considérée est donc le paiement effectif du fournisseur, et l'entrée la facture. La facture reçue est enregistrée, contrôlée (par rapport au bon de commande, aux tarifs négociés, ...) et son paiement est autorisé selon les règles en vigueur dans l'organisme. En pratique, chaque activité est un traitement par lot ("batch"), et a pour résultat de faire avancer les factures vers la "banette" suivante :
Le formulaire 'facture_fournisseur'Dans le cas le plus simple, l'ensemble du processus pourrait se gérer avec un unique formulaire associé à la facture. Le formulaire contient un champ date pour l'enregistrement¹ de chaque étape.
Chacune des activités présente en entrée un état de toutes les factures auquel est appliqué le filtre adéquat :
On utilise en fait un seul état sur lequel on définira plusieurs vues. Par commodité, il est utile de prévoir également un filtre sur le fournisseur pour l'activité "Payer" :
Le formulaire 'paiement_fournisseur'Généralement, les flux monétaires ne correspondent pas aux flux comptables, particulièrement avec les fournisseurs réguliers auxquels on règle plusieurs factures en un seul virement. Un second formulaire permettant le lettrage, c'est-à-dire la mise en correspondance des paiements (flux monétaire) avec les factures (flux comptable), est nécessaire.
Remarque : nous avons alors un double enregistrement¹ du paiement, le formulaire 'paiement_fournisseur' et le champ 'date_paiement' sur les formulaires 'facture_fournisseur'. Une bonne façon d'éviter des incohérences est de synchroniser le second sur le premier. Il suffit d'ajouter au formulaire 'facture_fournisseur' le programme suivant : report "paiements_fournisseurs" ref_facture fournisseur+"/"+numero où 'paiements_fournisseurs' (au pluriel) est le nom de l'état qui liste toutes les lignes des formulaires 'paiement_fournisseur'. Ainsi, le simple fait d'enregistrer le paiement (sortie de l'activité) met à jour les formulaires 'facture_fournisseur' qui sortent de la vue des factures à payer (entrée de l'activité). Remarque : l'information de la date de paiement pourrait être récupérée en une seule ligne, date_paiement := lookup "paiements_fournisseurs" ref_facture date_paiement fournisseur+"/"+numero mais la fonction 'lookup' ne s'exécute qu'à l'affichage du formulaire, tandis que la fonction 'report' permet la mise à jour automatique du formulaire (qui fonctionne alors sur le même principe de mise à jour qu'un état). Règlements partielsDans un monde idéal, l'activité "Payer" aurait en entrée la liste des factures "autorisées" et arrivées à échéance². Dans la vraie vie des entreprises, il arrive que des soucis de trésorerie amènent à renégocier certaines dettes, ce qui peut avoir pour conséquence le paiement de factures en plusieurs fois. Dans ce cas, il est nécessaire que la facture fournisseur "tienne la comptabilité"... Une possibilité est d'enrichir le formulaire 'facture_fournisseur' de deux champs :
Le programme devient alors : var Float r := 0 Le champ 'paiement' correspond au paiement effectivement réalisé, et doit être ajouté au formulaire 'paiement_fournisseur' :
Au niveau implémentation dans Storga, la page d'activité "Payer les fournisseurs" présenterait alors :
∴ ¹ Maîtriser les enregistrements ² Pour ne pas compliquer inutilement cet exemple, je n'ai pas fait figurer l'échéance dans les formulaires et les filtres. ∎ Article publié ou mis à jour le 2017-01-27 Catégories : organisation
Commentaires |