Xavier courtemanche - bug de currection
Journal Général
Description du problème: les identifiants des factures sont données en odres d'apparitions des écritures dans le J.G. Le système detecte que la "bonne" écriture est la facture n. 188 puisque les comptes sont un match parfait avec ce que l'étudiant à écrit. Ce problème origine de l'erreur de l'étudiant (n'a pas écris le bon compte pour une écriture) et du fait que nous ne faisont pas multiples tentatives de trouvé la bonne facture associé à l'écriture.
Solution: Faire multiple tentatives d'associations.
Les montants ne sont pas bon aussi, ce qui peut être une autre cause du problème.
Description detaillé de la solution proposé
L'algo actuel se fait en une seul passe pour l'association des écritures avec factures (si la facture ne match pas parfaitement la facture indiqué par l'étudiant, prend la prochaine meilleur qui à un taux de match supérieur à 65%). Ce qui peut causé une double erreur puisqu'une écriture peut "voler" une bonne facture à une autre écriture
La solution que je propose afin de résoudre ce problème va comme suit (en pseudo code):
currentThreshold = 1
nextThreshold = 0
wantedExplanationBySectionUids = {}
listOfSectionUids = copyOf(tableData.sectionsIndex)
billUidRemainings = copyOf(billUids)
tant que listOfSectionUids est pas vide
for sectionUid of listOfSectionUids
for billUid of billUidRemainings (ce ne sera pas exactement représenté comme cela dans le code)
threshold = getMatchRate(sectionUid, billUid)
if (threshold == currentThreshold)
wantedExplanationBySectionUids[sectionUid] = billUid
listOfSectionUids.remove(sectionUids)
billUidRemainings.remove(billUid)
break billUidRemaining loop
nextThreshold = max(threshold, nextThreshold)
currentThreshold = nextThreshold
Ce pseudo-algorithme devrait réduire les cas d'erreurs.
Afin d'implémenté ce pseudo code une bonne partie du code restera parreil.
No Comments