Discussion :

[SeaWolf601]

Bonjour à tous,

voila j'ai un petit problème de "méthode" dirons nous.

je suis en train d'écrire un soft de compta et j'en arrive au stade ou il faut "lettréer" (rapprocher pour ceux qui ne connaissent pas les termes de compta) les écritures (enregistrements) entre elles.

exemple :
J'ai une facture sur le compte 401004 de 127.25 €, le soft vas aller chercher un paiement dans le même compte de la même somme et vas leur donner une référence commune. Bon jusque là pas de problème.
(il n'y a pas d'autre critère que le N° de compte et la somme).

Mon problème c'est quand j'ai plusieurs dépenses et UN seul paiement.

Coté paiement j'ai 127.25€ par exemple.
Et coté facture j'ai : 50 €
27.12 €
30.13 €
41.99 €
et 20 €

pour que l'écriture s'équilibre je dois sélectionner 50; 27.12; 30.13 et 20.
le 41.99 ne faisant pas partit du paiement.
Mon problème est comment dans une query/requête (parce que je ne vois pas comment faire autrement) lui faire trouver automatiquement la somme correspondante ?

Je n'ai pas la moindre idée de comment faire, quelqu'un a une idée ?

Version : Access 2002.

[Demco]

Quel information dans la table nous permet de savoir que les chiffres 50; 27.12; 30.13 et 20 composent le paiement qui nous intéresse ?
Tu as par une table Depense avec une clé étrangère vers la table Paiement ?

Il faut en fait trouver un critère permettant de différencier les dépenses d'un paiement particulier.

En espérant t'aider.

[SeaWolf601]

Helas non Demco, il n'y a aucun autre critére,sinon tu pense ça aurait été simple. Juste le N° de compte et je compare les "debit" au "credit".

[Demco]

Mais je ne vois même pas comment c'est faisable sans ce genre d'information.

Il faudrait que tu prennes toutes les dépenses : 50; 27.12; 30.13, 20 et 41.99 et que tu testes toutes les possibilités d'addition entre ces nombres pour trouver 127.25 € ?
C'est fiable à 5% et donc inenvisageable.

Il faudrait repenser la modélisation non ? Les dépenses ne devraient-elles pas être rattachées à une facture ?

[SeaWolf601]

Mais je ne vois même pas comment c'est faisable sans ce genre d'information.

Il faudrait que tu prennes toutes les dépenses : 50; 27.12; 30.13, 20 et 41.99 et que tu testes toutes les possibilités d'addition entre ces nombres pour trouver 127.25 € ?
C'est fiable à 5% et donc inenvisageable.

C'est ce que j'avais pensé.
5% ???? tu es généreux, car mon exemple est simple là j'ai UN paiement et 5 sommes, mais dans la saisie mensuelle je peux avoir 20 paiement et une centaine de somme à rapprocher.

Il faudrait repenser la modélisation non ? Les dépenses ne devraient-elles pas être rattachées à une facture ?

Ce serait bien oui, mais hélas les utilisateurs ne le font pas.
En tout cas merci, je vais voir si je trouve une solution, mais j'ai pas d'idée pour l'instant. Je venais un peu ici pour avoir une "muse".

[Gabout]

Bonjour,

Demco a raison : ne disposes-tu pas d'un champ Tiers (par exemple) qui te permettrait de limiter tes choix ?

[SeaWolf601]

Bonjour,

Demco a raison : ne disposes-tu pas d'un champ Tiers (par exemple) qui te permettrait de limiter tes choix ?

Hélas trois fois hélas NON !!!!
Par N° de compte il n'y a qu'UN fournisseur, mais ce fournisseur peut livrer, par exemple, des matières premières,2 à 3 fois par semaine.

exemple :

semaine 1 : 2 livraisons : 10,00€ & 12,50 €
semaine 2 : 3 livraisons : 10,00€, 9,00€ & 14,75 €
semaine 3 : 1 livraisons : 17,32 €
semaine 4 : 2 livraisons : 11€ & 12,5 €

Total du mois : 97,07 € (sauf erreur)... Seulement (oui sinon ce serait trop simple) le client à payé 73,57 € (semaine 1,2,3) donc dans ma colonne debit j'ai UNE somme 73.57 et c'est la le "tour de magie" à créer, il doit aller me pointer les sommes : 10,00€, 12,50€, 10,00€, 9,00€, 14,75€ et 17,32€.

Pour ceux qui se poserais la question, en se demandant si c'est possible,
un célèbre programme de comptabilité fait ce genre de choses (je sais pas si j'ai le droit de le citer). ça commence par "C" et fini par "iel".

[Graffito]

Bonjour,

Le forum Algorithme eut été plus approprié!

En pratique, il faut considérer toutes les combinaisons de factures qui peuvent correspondre à un encaissement.
Les combinaisons s'obtiennent assez simplement par recursion:

• Au départ, une combinaison de 0 facture de montant 0.
• A partir des combinaisons de n factures, on déduit et ajoute toutes les combinaisons possibles avec n+1 factures
• Les combinaisons possibles au niveau n+1 remplissent les 2 conditions : la n+1 ième facture entrant dans la combinaison ne doit partie des n premières de la combinaisons et le total ne doit pas dépasser le montant de l'encaissement.

Quand n a atteint le nombre de factures traitées, il n'y a plus qu'à vérifier si il existe une ou plusieurs combinaison dont le total est égal à l'encaissement.

[SeaWolf601]

Bonjour,

Le forum Algorithme eut été plus approprié!...

Je ne l'avais pas mis ici... Sacrés modo qui déplacent les messages
Je te rassure je ne l'avais pas mis dans "Algorithme" non plus... y a un forum Algorithme au moins ?

Bon revenons à nos moutons... je pense avoir compris ce que tu as dit...
MAIS... Je le code comment en SQL moi ça ?
Parce que la autant me demander les prochains N° gagnant du loto, j'ai plus de chances d'arriver à te les fournir.

[pied9]

le destinataire des paiements peut-il permettre de regrouper les factures?

[SeaWolf601]

le destinataire des paiements (le fournisseur) est tjs le même puisqu'il n'y a qu'un N° de compte par fournisseurs.

[Simplifi]

hello
comme mon boulot est de faire des bases Access, j'ai réalisé ma compta moi même
pour le lettrage, je commence par attribuer une lettre (en suivant, ce qui fait que j'ai une petite fonction pour AA, AB,,,,AZ,BA,BB.....)
ensuite j'attribue ce lettrage en automatique au paiement et à la vérification
dans 90% des cas, il n'y a rien d'autre à faire, une facture, un paiement, une vérif
dans les cas de règlement partiel, j'ai d'abord utilisé un index de paiement qui permet que la clef de la table paiement soit double (N°facture + index) et dans ce cas, j'attribue plusieurs fois le lettrage de la facture

même solution pour un paiement vérifié en sur plusieurs relevés bancaire (cas des tickets d'autoroute regroupés)

Il ne reste que les cas tout à fait bizarres (les plus courants sont des factures groupées dans un règlement) que je suis contraint de lettrer à la main. Il reste vrai qu'on peut trouver tous les cas de figures:
1 facture, 1 paiement
1 facture, n paiements
n factures, 1 paiement
n factures réparties sur n paiements

et pour boucler le système, il ne reste qu'à sortir la liste des lettrages non équilibrés par une requête

Dans ton cas, où le lettrage n'aurait pas été fait à l'avance, tu dois pouvoir retrouver le lien entre une facture et ses différents règlements
de plus une facture est peut être bien constituée de lignes qui, elles sont insécables
et enfin, si c'et toi qui écrit le soft, tu devrais prévoir un lien entre devis-commande-bordereau-de-livraison-facture-vérification (moi j'appelle ça un fil)

Sinon, avec du lettrage à l'aveuglette, tu risque d'avoir énormément de problème, surtout avec les sommes répétitives par ex 50 = 25 + 25
ou 50 = 20 + 20 + 10 ou encore 50 = 10 + 10 + 10 + 10 + 10

Bon courage

[vodiem]

salut à tous,

SeaWolf601, je ne vois pas de solutions évidentes en sql
car en plus du choix parmi parfois des multiples combinaisons satisfaisantes, il faudrait lors du lettrage, qui se fait par enregistrement, affecter une lettre en fonction de la précédente: ce qui est très délicat en sql.

une solution plus réaliste serait une procédure qui affecterait le lettrage.
il faut réaliser les combinaisons comme le suggère Graffito et pour limiter la casse qu'anticipe Simplifi il faudrait y inclure le facteur temps: un règlement ne peut être effectué (théoriquement) avant sa date de facture, voir même le délai d'encaissement.
ce qui n'empêchera pas d'éviter les erreurs mais diminuera le risque.
ce que je redoute le plus dans tout cela c'est que tu n'es jamais à l'abri d'une erreur de saisie ou d'une erreur de sur le montant qui au mieux retarde le lettrage et au pire ne le permettra pas.

si tu ne sais pas comment faire cela, préviens nous.
ps: si tu me donnes les prochains numéros du loto en échange je suis pas contre.