Tenir une comptabilité avec Access

1494 : Luca Pacioli publie à Venise la SUMMA DI ARITHMETICA, GEOMETRICA, PROPORTIONI ET PROPORTIONNALITA dont le Tractatus XI est considéré comme le premier ouvrage imprimé décrivant la comptabilité de manière cohérente et utile…

2013 : je vous propose une manière de faire sans vous expliquer les progrès depuis l'époque de Christophe Colomb. Retenez que les bases ont été fixées au Moyen Âge, mais que la technique et les normes progressent encore…

I-B-1. La saisie des faits est systématique▲

I-B-2. On se base sur des pièces justificatives▲

I-B-3. Division en exercices limités dans le temps▲

La saisie des faits à comptabiliser.

L'interprétation des faits en écritures comptables.

L'agrégation des mouvements pour construire les états comptables classiques.

Dans cette 1^re partie, nous traiterons les deux premiers points : constater un fait et le traduire en débits et crédits dans un système de comptes.

C'est l'ensemble des comptes qui fonctionnent dans une comptabilité.

Combien de comptes y a-t-il dans une comptabilité ?

Cela varie d'une entreprise à l'autre.

Cela varie d'une organisation comptable à l'autre.

En fait, cela dépend des ambitions que l'on a, lorsqu'on « tient » la comptabilité.

Veut-on un détail fin en permanence ou bien se contente-t-on d'un compte global que l'on ventilera, si le besoin s'en fait un jour sentir, en dehors de la comptabilité, « en extra-comptable » ?

Le législateur a toutefois fixé des limites en imposant un plan comptable minimum normalisé aux entreprises pour la publication(1) de leurs comptes.

En attendant une uniformisation européenne, la numérotation varie selon le pays.

Exemples :

Libellé	Belgique	France
Clients	40xxxx	41xxxx
Fournisseurs	44xxxx	40xxxx
Banque	55xxxx	51xxxx
Caisse	57xxxx	53xxxx

Pour notre exemple, les comptes sont articulés sur le schéma belge. Nous attirerons l'attention du lecteur chaque fois que cette particularité a une incidence dans l'application.

Les comptes doivent être suffisamment détaillés pour permettre l'enregistrement de toutes les opérations de l'entreprise.

Le plan comptable doit être conçu de telle sorte que les comptes publiés «  procèdent de » la balance des comptes (2) . En d'autres termes, chaque article des comptes publiés doit être construit en additionnant le solde des comptes détaillés.

Pour l'exemple, j'ai choisi d'articuler le plan comptable sur celui de la Belgique, décimalisé en six positions.

Dans notre cas :

• les recettes du restaurant et les diverses opérations de caisse : fEcrCai ;
• les opérations de banque : fEcrBan ;
• les factures des fournisseurs : fEcrAch ;
• les factures aux clients : fEcrFac ;
• les opérations diverses : fEcrDiv.

Cette division correspond à la pratique comptable qui consiste à classer les opérations par journaux spécialisés :

• des journaux de type « compte de trésorerie » : journal de caisse et journal de banque ;
• des journaux de type « facturier » : pour les factures d'achats et pour les factures des ventes ;
• un journal des opérations diverses pour tout le reste.

II-C-1. Chaque formulaire est conçu suivant un même gabarit▲

II-C-2. Conventions de nommage des formulaires « pères »▲

II-C-3. Un exemple concret▲

On se positionne à la fin du recordset pour pouvoir ensuite compter le nombre d'enregistrements. Une erreur 3021 sera levée s'il n'y a pas d'enregistrement. Cette erreur éventuelle est trappée et on passe à l'instruction suivante.

Espace occupé par l'en-tête du sous-formulaire.

Espace occupé par le pied du sous-formulaire.

Espace occupé par une ligne de détail du sous-formulaire. Cet espace sera multiplié par le nombre de lignes affichées ( + ).

Nombre d'enregistrements à afficher = nombre de lignes avec des données.

La propriété « Ajout autorisé » vaut -1 si elle est positionnée à Oui et 0 si positionnée à Non. Soustraire cette valeur revient à ajouter un espace détail vierge pour l'ajout éventuel.

De l'espace total disponible,

On soustrait celui réservé à l'en-tête et au pied pour connaître celui disponible pour les lignes de détail…

… que l'on divise par l'espace nécessaire à une ligne de détail.

Le résultat du calcul est transféré dans une variable de type « integer », elle serait donc éventuellement forcée à l'unité supérieure si la partie décimale du quotient dépasse 0,50. L'astuce pour ne conserver que la partie entière consiste à retrancher d'abord 0,50.

Exemple :

L'espace est insuffisant pour tout afficher.

On peut tout afficher.

Selon le cas, on affiche une barre de défilement verticale.

On fait voyager le sélecteur pour afficher toutes les dernières lignes. Y compris la ligne vierge pour l'ajout éventuel. Une erreur 2105 sera levée si la propriété « Ajout autorisé » est à Non. Cette erreur éventuelle est trappée et on passe à l'instruction suivante.

On se situe sur le dernier enregistrement et on remonte autant de fois que possible, c'est-à-dire iAffichables - 1 (pour le dernier déjà affiché) - 1 pour la ligne vierge éventuelle (rappelons que Forms(NomDuForm)(NomDuSF).Form.AllowAdditions vaut -1 ou 0 selon le cas).

La recette doit être ventilée en trois catégories selon leur sort fiscal :

• la partie « nourriture » subit 12 % de TVA ;
• la partie « boissons » subit 21 % de TVA ;
• les services traiteur subissent 6 % de TVA.

Chaque note de restaurant fait l'objet d'une souche TVA en double exemplaire dont l'original est remis au client.

Les doubles des fiches TVA vont constituer la pièce justificative de l'écriture comptable.

Si tous les clients payaient leur note en espèces, nous comptabiliserions un C.A. de 3210 € par exemple comme ceci (ventilé nourriture/boissons suivant le détail des bons de prise de commande) :

Les recettes sont comptabilisées dans des comptes transitoires selon leur taux de TVA. En fin de période on soldera ces comptes pour créditer les comptes de Produits « C.A. traiteur », « C.A. Boissons »… pour la partie hors TVA et « TVA à payer » pour la partie qui revient à l'État.

Mais certains clients ont payé avec une carte, disons 2789 €, l'écriture serait alors :

Après quelque temps, la banque nous créditera des 2789 €… enfin moins une commission et probablement en plusieurs fois… pas toujours facile pour contrôler ! Dans un article à venir, nous expliquerons comment s'organiser pour émarger les opérations en suspens.

Pour compléter notre cas d'école, imaginons que ce jour-là nous ayons reçu un acompte de 300 € pour la préparation d'un buffet froid pour l'amicale des Anciens qui en a profité pour nous vendre une carte de soutien à 20 €. Et enfin, nous avons versé 500 € à la banque.

À supposer qu'il nous restait 125 € hier, il doit maintenant y avoir 326 € dans la caisse.

En utilisant le formulaire fEncoCai, voici le résultat.

En cliquant successivement les boutons « Versement banque » et « Recette journalière », le schéma de comptabilisation s'affiche :

Les débits s'affichent en jaune, les crédits en bleu. Pour éviter les erreurs d'imputation, le côté inutile est désactivé.

L'utilisateur complète les données, il vient ceci :

Pour acter la carte de soutien et l'acompte reçu, l'utilisateur choisit « manuellement » les comptes à mouvementer :

Le formulaire affiche que d'après la comptabilité, il devrait y avoir 326,00 € en caisse.

Dans la caisse, il y a effectivement 325,20 € : on a probablement bien tout comptabilisé, mais on acte la différence : un clic sur « Différence trop peu » et finalement :

… la pendule compta est à l'heure !

Et voici les mouvements qui seront générés par la routine « Sub CreMvts » qui sera présentée plus loin dans l'article

N.B. Les débits sont signés « - », les crédits sont positifs.

V-B-1. La démarche pour généraliser▲

L'idée c'est :

- un formulaire « père » basé sur les enregistrements de tEcritures qui concernent les opérations de caisse ;

- un formulaire « fils » avec les enregistrements correspondants de tImputa.

Dans une première approche, nous aurions donc :

- la source de fEcrCai :

 

Sélectionnez

SELECT * FROM tEcritures WHERE EcOrigine="Cai" ORDER BY EcNumExtrait, EcDate;

N.B. Trié par numéro d'extrait (ici sans effet puisqu'égal à zéro) et par date pour la commodité d'utilisation.

- la source de fImputa :

 

Sélectionnez

SELECT * FROM tImputa;

et pour assurer la coordination des deux :

- la propriété « Champs fils » du conteneur : ImOrigine;EcFk ;

- la propriété « Champs pères » du conteneur : EcOrigine;EcPK.

Dans la requête source de fEcrCai, on sélectionne sur la base de « WHERE EcOrigine = "Cai" ». S'il s'était agi de fEcrBan, nous aurions eu « WHERE EcOrigine = "Ban" » et de même pour les autres fEcrXXX.

Puisque nous avons « normé » le nom des formulaires, nous pourrions généraliser en nous référant aux trois derniers caractères de leur nom soit quelque chose comme :

 

Sélectionnez

SELECT * FROM tEcritures WHERE EcOrigine= Right([Name],3)   ORDER BY EcNumExtrait, EcDate;

qui provoque ceci :

En fait, dans ce contexte, Access ne reconnaît pas [Name] comme représentant le nom du formulaire.

Rusons pour arriver à nos fins : nous allons construire la source du formulaire dans son événement « Sur chargement », comme ceci :

 

Sélectionnez

Private Sub Form_Load()
Dim sSql As String
sSql = "SELECT * FROM tEcritures WHERE EcOrigine='" & Right(Me.Name, 3) & "' ORDER BY EcNumFac, EcDate;"
Me.RecordSource = sSql
End Sub

Cette fois, Access ne réclame plus [Name], mais successivement :

C'est-à-dire ce que renseigne la propriété « Champs pères » du conteneur.

Qu'à cela ne tienne, ne définissons pas cette propriété a priori dans le formulaire et construisons-la aussi dans l'événement « Sur chargement » qui devient :

 

Sélectionnez

Private Sub Form_Load()
Dim sSql As String
sSql = "SELECT * FROM tEcritures WHERE EcOrigine='" & Right(Me.Name, 3) & "' ORDER BY EcNumFac, EcDate;"
Me.RecordSource = sSql
Me.ctnrsfImputa.LinkMasterFields = "EcOrigine;EcPK"
End Sub

Et cette fois, ça marche !

Donc, en résumé :

La valeur par défaut est « Droite([Nom];3) ». Les nouveaux enregistrements seront créés avec « Cai » comme valeur de EcOrigine.

N.B. Ce contrôle est non visible, car sans intérêt pour l'utilisateur.

La valeur par défaut est « Droite([Nom];3) ». Elle sert dans la routine AjoutImputa exposée plus loin dans cet article.

Dans ce formulaire de type « trésorerie » (fEcrCai et FEcrBan), nous voulons empêcher que l'utilisateur introduise plusieurs fois la même date de comptabilisation. Comme ce ne sera pas le cas dans les formulaires des autres types (facturiers et opérations diverses), nous ne pouvons pas imposer l'unicité de « EcDate » au niveau de la définition de la table tEcritures.

Nous allons donc imposer cette contrainte au niveau du formulaire fEcrCai (et fEcrBan), dans l'événement « Avant mise à jour » du contrôle txtEcDate.

Voici le code et son explication :

Deux blocs :

si l'utilisateur essaie de modifier la date d'un enregistrement existant et que cette modification entraîne une date en doublon ;

si lors d'un nouvel enregistrement, l'utilisateur tente d'introduire une date déjà présente ;

dans les deux cas, si la nouvelle date est déjà présente, on affiche un message ;

on rétablit la valeur initiale ;

on supprime l'enregistrement en cours de création et on positionne la variable globale bRejetDate pour court-circuiter le processus de l'événement « Sur activation ».

On calcule ici le solde de la veille, c'est-à-dire le solde de départ de la journée en cours d'enregistrement.

=nz(SomDom("MvtMt";"tMvts";"MvtCpte = Cpte(""Caisse"")   and MvtDate<#" & Format([txtEcDate];"mm/dd/yy") & "#");0)

Ce n'est autre que la somme des mouvements au compte « Caisse » qui ont une date antérieure à celle du jour considéré.

Remarquez la transformation du formatage à l'anglo-saxonne de la date.

La fonction nz() sert à remplacer par zéro la valeur nulle qui survient pour le 1^er jour (il n'y a alors pas de veille !).

Le calcul du solde du jour est lui, construit par addition algébrique du solde de la veille et la contrepartie des mouvements dans le formulaire « fils ».

=[txtSoldeveille]+[ctnrsfImputa]!txtTotalDebit-[ctnrsfImputa]!txtTotalCredit

Un clic sur l'un de ces boutons déclenche la création d'un schéma d'imputations. Voyez la description du fonctionnement au titre suivant.

Cependant, on ne peut pas se permettre d'attendre d'avoir en main l'extrait de la banque pour comptabiliser les faits. D'autant plus que depuis la banque en ligne, on ne demande plus à disposer d'un extrait papier journalier.

D'un autre côté, comptabiliser des montants rigoureusement symétriquesÀ un débit dans notre compte chez la banque correspond un crédit à ceux de la banque n'est pas toujours pratique non plus.
Quand la banque nous débite d'un montant global couvrant le paiement de plusieurs factures à un fournisseur, c'est bien plus commode d'avoir dans notre comptabilité le détail des paiements facture par facture pour faciliter la justification« Justifier le solde d'un compte », c'est reconstituer le solde du solde du compte de chaque fournisseur. Même raisonnement quand nos clients nous règlent plusieurs factures d'un coup.
Encore plus corsé : les montants que la banque nous bonifie pour les notes payées par cartes. La banque nous crédite d'un montant net de commissions d'encaissement et en regroupant parfois des journées différentes (les opérations du week-end par exemple). Cela complique la vérification avec les montants comptabilisés dans fEncoCai.
Dans ces trois cas, pour des raisons de visibilité dans notre comptabilité, nous nous organiserons pour comptabiliser dans notre formulaire fEncoBan des montants qui peuvent être facilement réconciliés avec ceux enregistrés dans les autres formulaires d'encodages (fEncoCai, fEncoAch…).

Dans un article à venir, nous expliquerons comment on peut organiser la justification des comptes « Virements internes » et « Paiements par cartes ».

Donc si l'extrait de la banque est la pièce justificative, les montants figurant à l'extrait et ceux apparaissant dans notre comptabilité seront de niveaux de détail différents. Par contre le solde du compte « Banque » dans nos livres sera le reflet exact du solde à l'extrait.

Le dernier extrait imprimé portait le N° 2 (daté par exemple du 10/1) :

Le solde précédent à la banque (14/1) était de 520,95 créditeur :

Nous sommes le 16/1 et nous consultons l'état de notre compte bancaire via Internet :

Et voici comment encoder ces opérations dans fEncoBan :

Le solde d'après notre formulaire correspond (au sens près) à celui de la banque : c'est un indice que nous avons reporté tous les montants.

Fort peu de différences entre fEcrCai et fEcrBan.

Dans notre exemple, c'est le seul cas où la colonne EcNumExtrait est exploitée. Ce N° constitue la référence à la pièce justificative (l'extrait délivré par la banque) et est utile en cas de recherche.
Sa valeur par défaut est :

=MaxDom("EcNumExtrait";"tEcritures";"EcOrigine='" & [txtEcOrigine] & "'")

Si nous comptabilisons au jour le jour sur la base de la consultation par Internet (l'extrait numéroté n'est donc pas encore en notre possession), nous aurons plusieurs enregistrements dans tEcritures avec le même N° d'extrait.
Pour prouver a posteriori que le solde de l'extrait correspond à notre comptabilité, il suffira d'afficher l'enregistrement avec la dernière date portant ce N° extrait.

Le calcul du solde de la veille :

=nz(SomDom("MvtMt";"tMvts";"MvtCpte = Cpte(""Banque"")   and MvtDate<#" & Format([txtEcDate];"mm/dd/yy") & "#");0)

Les factures reçues des fournisseurs sont numérotées dès leur réception. La numérotation doit être continue.

Dans l'exemple qui suit, on a choisi cette structure de numérotation :

AAAA-xxxx

où AAAA représente l'année comptable en cours et xxxx une suite qui commence à 0001.

Concrètement, lors de l'encodage le formulaire fEcrAch va attribuer le numéro (le dernier encodé + 1), on reproduit ce numéro sur la facture et on la classe… de manière à la retrouver facilement. Aucune règle n'est imposée pour ce classement (dans l'ordre des N°, par ordre alphabétique…).

La facture du fournisseur constitue la pièce justificative des données encodées dans fEcrAch.

Pour comptabiliser une facture d'achat, il faut :

- créditer le compte du fournisseur pour le montant total de la facture ;

- débiter le compte « TVA A RECUPERER » pour le montant de la TVA ;

- débiter une série de comptes souvent les mêmes pour ce fournisseur, par exemple : « MATIERES 1^res » pour l'un, « TELEPHONE » pour tel autre…

Pour faciliter le travail d'encodage, nous proposons que, pour les fournisseurs habituels, on complète la colonne « PCImputa » de la table tPlanComptable avec une chaîne de caractères qui respecte la même syntaxe que celle décrite plus haut pour les boutons de création de schéma de comptabilisation.

Ici, pas de restriction sur la date, contrairement au mécanisme décrit pour les formulaires d'encodage de type « Compte de trésorerie » (fEcrCai et fEcrBan).
tEcritures contiendra donc, pour l'origine « Ach » plusieurs enregistrements portant la même date.

Le numéro de séquence de la facture est attribué lors de la création de l'enregistrement voyez la valeur par défaut de ce contrôle :

Remarquez que ce N° de facture est systématiquement reporté comme valeur par défaut du contrôle « txtImLibelle » du sous-formulaire lors de l'événement « Sur activation » :

'Libelle par défaut = N° de facture
Me.ctnrsfImputa!txtImLibelle.DefaultValue = Me.txtEcNumFac

Ce qui entraine que tous les mouvements concernant l'enregistrement de cette facture auront son N° comme libellé.

Seuls les comptes de la plage réservée aux fournisseurs peuvent être choisis.

Voici la requête de la propriété « Contenu » du choix par nom de fournisseur :

SELECT PCIntitule, PCCpte FROM tPlanCompta WHERE PCCpte Between Cpte("Fournisseurs")+1 And Cpte("Fournisseurs")+999 ORDER BY PCIntitule;

Le choix du fournisseur déclenche le formatage du bouton btImputa (voir la description quelques lignes plus bas).

La date inscrite sur la facture du fournisseur n'est pas un élément obligatoire pour notre comptabilité. Cette donnée est utile si la facture n'a pas été payée au comptant : elle nous servira pour déterminer l'urgence du paiement (deuxième partie - à venir - de cet article).

Bouton btImputa.

VIII-B-1. Événement « Après mise à jour » du choix d'un fournisseur▲

On affecte le N° de facture à la propriété « Légende » du bouton.

Dans la propriété « Remarque », on inscrit :

- Me.ActiveControl c'est-à-dire le N° du compte fournisseur, suivi d'un C (pour crédit) et le point-virgule séparateur ;

- pour ajouter le N° du compte TVA à débiter, on appelle « Cpte("TVA A RECUPERER") » ceci pour éviter de coder le N° « en dur » ;

Si l'utilisateur a prévu pour ce fournisseur une chaîne d'imputation : on l'ajoute, précédée du point-virgule.

On rend le bouton btImputa visible.

On affecte le N° de facture au libellé de l'écriture.

Si la date n'a pas encore été saisie, on rappelle qu'elle est obligatoire.

Le restaurant qui nous sert d'exemple émet peu de factures. En général pour des firmes qui organisent un repas d'affaires ou pour fêter un événement avec des membres de leur personnel (fêtes patronales, départ à la retraite…).

On établit aussi une facture pour des services traiteur qui ne sont pas payés directement au comptoir.

Les factures émises sont numérotées de manière continue.

Dans l'exemple qui suit, on a choisi cette structure de numérotation :

AAAA-xxxx

où AAAA représente l'année comptable en cours et xxxx une suite qui commence à 0001.

Concrètement, lors de l'encodage le formulaire fEcrFac va attribuer le numéro suivant.

On pourrait greffer sur ce formulaire des fonctions permettant d'établir la facture, de l'imprimer et même de l'envoyer annexée à un e-mail. Ce n'est pas envisagé dans le cadre de cet article.

Ce formulaire n'appelle pas de commentaires dans la mesure où sa composition et son fonctionnement sont semblables à ceux de fEcrAch.

On enregistre ici toutes les opérations qui ne concernent ni un compte de trésorerie ni les factures.

Par exemple des écritures de régularisation : comme solder les comptes transitoires des recettes pour dégager les chiffres d'affaires hors TVA, comptabiliser les amortissements, les salaires à payer…

En fait, rien de particulier dans la mesure où tous les mécanismes mis en œuvre ont été décrits plus haut.

C'est la même routine, quel que soit le formulaire d'encodage qui l'appelle.

À chaque lecture d'un enregistrement et à sa fermeture, le formulaire appelle la routine et tous les mouvements qui concernent ce formulaire sont systématiquement recréés depuis le début de l'exercice comptable.

Ainsi, si a posteriori on constate une erreur d'encodage, il suffit de la corriger et une nouvelle génération des mouvements viendra remplacer celle qui était erronée.

Dans la pratique, ces corrections ne sont possibles que si elles restent sans conséquence pour la concordance avec les pièces officielles : factures des fournisseurs, extraits bancaires, carnets de souches TVA, déclarations officielles fiscales et sociales…

On détermine le code « Origine » : les trois dernières positions du nom du formulaire qui appelle la routine.

On supprime tous les mouvements dont l'origine correspond.

Exemple pour fEcrCai :

On recrée tous les débits pour ce formulaire.

Exemple pour fEcrCai :

De même pour les crédits :

On crée les contreparties au compte « Caisse » des imputations dans fEcrCai :

De même pour le compte « Banque » :