Sharpening your .NET applications

En détail

Créer un pont entre un programme de facturation et un logiciel de comptabilité

Créer un pont entre un programme de facturation et un logiciel de comptabilité

Il y a longtemps déjà

Il me plaît d’évoquer ce sujet car il correspond à mes réels débuts dans le métier. A une époque où le concept « ERP » (logiciel intégré) n’était pas du tout répandu parmi les petites et moyennes entreprises, il était courant de recourir à différents programmes, dont notamment un pour la gestion commerciale (facturation, gestion des stocks, …) et un autre pour la comptabilité.

De nombreux utilisateurs se trouvaient alors dans l’embarras de devoir encoder à deux endroits différents les mêmes données, mais dans un contexte différent. Un client créé en gestion commerciale devait l’être aussi dans le logiciel comptable. Toute facture encodée dans le premier devait aussi être imputée en comptabilité, sous la forme d’une écriture comptable.

De nombreux intégrateurs avaient promis une liaison magique. Dans la réalité peu avaient réellement vu le jour ou n’apportaient pas la fiabilité attendue. C’est à cet endroit précis que j’ai fourni, à l’époque, de nombreux développements.

C’est un sujet sensible. Il en va notamment de la probité de la déclaration de TVA ou des comptes annuels qui seront établis en aval de tout ce processus.

Une bonne compréhension des règles

Transférer vers un logiciel comptable une facture de 100 EUR en régime national posera en général peu de difficulté. Mais les cas peuvent rapidement se corser : une facture d’achat avec escompte non déduit et TVA partiellement non récupérable se transforme rapidement en un vrai défi. Une bonne compréhension des mécanismes comptables et TVA s’impose. Une validation par les personnes en charge de la comptabilité dans ou pour l’entreprise permet de confirmer les schémas utilisés.

Sécuriser ces transferts

Ce type de développement ne s’envisage dès lors pas à la légère. Des règles de base s’imposent :

  • Éviter les ruptures de numérotation en comptabilité.
  • Ne pas créer de doublons de factures.
  • Ne plus permettre aucun changement dans les documents de la gestion commerciale qui ont été transférés en comptabilité.
  • S’assurer au préalable que le client ou le fournisseur a bien été injecté dans les données du programme comptable et, si nécessaire, mis à jour.
  • Mettre en place des verrous « multi-utilisateurs » afin que deux utilisateurs ne puissent pas transférer simultanément les mêmes données.

Et dans un vrai ERP

Bien entendu, dans un ERP les mêmes processus s’appliquent, mais de façon interne au logiciel. Ce qui permet d’aller plus loin :

  • Introduction en comptabilité des paiements de caisse perçus, avec lettrage automatique.
  • Possibilité de rassembler différentes écritures de façon automatisée : différents acomptes, paiement lors de l’enlèvement de la marchandise, solde sur facture, avec lettrage automatique.
  • Indication d’un statut « payé » sur une commande client en fonction d’un paiement identifié automatiquement dans la comptabilité.

La communication entre deux logiciels n'est finalement que le point de départ. Le véritable défi réside dans la traduction fidèle des règles comptables et fiscales en algorithmes.

Précédente Suivante
Tous les produits, technologies et noms de sociétés mentionnés sur ce site sont des marques déposées de leurs propriétaires respectifs. Les produits Microsoft cités (SQL Server, Windows, MAUI, Xamarin, .NET, Blazor, ...) sont des marques de Microsoft Corporation. Ubuntu est une marque déposée de Canonical Ltd.
An unhandled error has occurred. Reload 🗙

Rejoining the server...

Rejoin failed... trying again in seconds.

Failed to rejoin.
Please retry or reload the page.

The session has been paused by the server.

Failed to resume the session.
Please retry or reload the page.