Discussion :

[chmouky]

Bonjour,

Je me suis lancé dans le développement d'un programme de rapprochement comptable sur Access et je me demande si je n'ai pas fait une erreur en choisissant cette solution.

Dans mon programme, je dois trouver les combinaisons possibles de factures qui pourraient matcher avec les montant de relevés bancaires.
1 montant relevé = X factures.

Je me suis lancé dans un algorithme sur VBA qui me retourne toutes les combinaisons possibles avec ces factures. Je fais ensuite une sélection sur l'égalité avec le montant du relevé. Je laisse ensuite l'utilisateur choisir les combinaisons de factures (il peut évidemment y en avoir plusieurs possibles).

Dans mon algorithme, qui repose sur la récursivité, tout est OK lorsque je suis à 10 factures environ... mais lorsque cela va au delà, le nombre de combinaisons explose et le logiciel est inexploitable (car temps réponse interminable).
Je me demande donc si Access est la solution.

Avez-vous un avis sur le problème rencontré ?
Est-ce qu'à votre avis, il y a une solution Access pour répondre à ce besoin ou bien je dois utiliser un langage de programmation plus performant...

Merci pour votre aide.

[nico84]

Bonjour,

VBA n'est pas un langage particulièrement lent, tout dépend de l'algorithme et au vu du problème on comprend bien que les combinaisons explosent avec le nombre de factures surtout si elles sont toutes envisagées !
Quelques pistes :
- le SQL d'access est lent s'il est en DAO : utiliser ADO et/ou une base de données non access pour déléguer les requêtes au serveur (particulièrement si on est en multiposte)
- faire une seule requete et tout le calcul en mémoire ou sur des tables locales
- si ce n'est pas le cas, commencer par identifier le tiers concerné et filtrer les factures de ce tiers


A titre d'exemple j'ai un calcul de besoins qui produit les demandes d'achat pour une entreprise en fonction des commandes en cours ou envisagé. Le temps d'exécution est de l'ordre de
- 15' en transact-sql sur le serveur
- 20' en VBA + ADO sur le serveur
- 40' en VBA + ADO sur un PC client en réseau ethernet

[Jean-Philippe André]

Salut,

j'ai eu un cas similaire à faire sous Excel, avec du lettrage à effectuer, pour un client en 2021. J'avais réussi avec l'aide d'un membre de DVP, à avoir des traitements très rapides sur des volumes de transactions jusque 25 éléments à lettrer.

Les cas avec plus d'éléments étaient plus longs.

La contrainte initiale est qu'on a l'identifiant du client, le reste passait plutôt bien.

Le fait d'utiliser VBA n'est pas nécessairement un bloquant.

J'ai essayé une piste avec du python, ca fonctionnait aussi, mais pour la maintenance, pas tip top.

[chmouky]

Bonjour,
Merci d'avoir pris le temps de me répondre.
La solution ADO n'a pas résolu le problème, le traitement n'est pas viable en l'état.
Mais j'ai réalisé une chose plutôt inquiétante, les combinaisons possibles pour 30 factures dépassent le milliard (sauf erreur de ma part)! C'est un nombre qui m'oblige à revoir la stratégie de rapprochement.
@jean-philippe : Est-ce que dans ton traitement, tu devais aussi lister toutes les combinaisons possibles avec les factures avant de faire le lettrage ?

Merci encore.

[Jean-Philippe André]

Salut,

en fait avant de faire toutes les combinaisons possibles, utilise plutôt une approches avec une fonction récursive pour générer tous les groupes de p valeurs prises parmi n valeurs de l'ensemble. C n, p


Pour réduire ton temps de traitement, il faut être capable de sortir le plus tôt possible d'une série de tests, lorsque par exemple aucune valeur de ton ensemble n'est négative, il n'est pas possible de faire une somme nulle.

J'ai retrouvé des bouts de codes, et le NB_MAX_LIGNES était de 18.

[chmouky]

Oui tu as raison.
Je vais trouver un moyen de proposer le rapprochement de ce qui est déjà évident, cela limitera les factures sélectionnables dans les combinaisons puisqu'elles seront déjà rapprochées.
Merci pour votre aide.