Plantage en saisie des écritures

Soumis par Buen le ven 25/05/2018 - 15:22
Forums

Bonjour,

J'ai un plantage en saisie d'écriture : je veux faire un virement interne et quand je valide j'ai un crash de Laurux :
"This application has raised an unexpected
error and must abort.
Result is not available.
Tresor.Enrg_Ecr.1646"
Quand je reviens, je n'ai pas l'écriture sur ma banque, mais il y a une écriture lettrée ?!? sur le compte des virements internes.

Je suis sous 18.04LTS+Laurux3.68.2+Gambas 3.11.2, pas de problème sur un 2è PC sous 17.10+Laurux3.68.1+Gambas 3.10.

Bonjour,
Pour un virement interne :
Journal banque 1 D-58 C-512 pour un montant de x
Journal banque 2 D-512 C-58 pour un montant de x
Ça fonctionne.

Bonjour,
Même plantage avec une saisie d'encaissement de chèques :
"This application has raised an unexpected
error and must abort.

Result is not available.
Tresor.Enrg_Ecr.1646"

Que signifie "Tresor.Enrg_Ecr.1646" ?

Oui, j'ai fait une restauration à la suite du plantage.
Mon collègue qui travaille sur la même base ne rencontre pas de problème pour les même saisies d'écritures.
Il n'a pas fait la mise à jour de Laurux, c'est pour ça que je pense qu'il y a un problème avec la nouvelle version.

bonjour il y a probablement un bug introduit lors dans la 3.68.2 pour le calcul de la somme de control lors du lettrage des ecritures... ce que je ne comprend pas c'est pourquoi vous tombez dedans:

If Lettrable = 1 Then
rResult = Utils.db.Exec("SELECT * FROM " & Cbase.Table("TabMvt") & " WHERE numlot = &1 and compte = &2", numlotT, numcpt)
If rResult.Available Then
Utils.db.Exec("Update " & Cbase.Table("TabMvt") & " set lettree = &1 where numlot = &2 and compte = &3", 1, numlotT, numcpt)
Endif
** Bug la ligne ci-dessous devrait etre associé à la commande Utils.db.Exec dans le IF ci-dessus qui verifie que l'écriture existe... ce que je comprends pas c'est
pourquoi la recherche echoue **
Sha1Calc.CalcSha1(Cbase.Table("TabMvt"), rResult!numero)
Endif

globalement vous dévez veiller à conserver des versions identiques entre les postes.
si une version de correctif diffère (c'est votre cas 3.68.1 et 3.68.2 le risque est plutôt faible, la base de données est compatible mais l'interprétation des données peut etre différente). Entre version 3.67 et 3.68 la base de donnée est différentes...cela ne marche absoluement pas et n'est pas prévu dans le logiciel (bug et plantage base de donnée hautement probable).

ma recommandation est : ne pas faire de mise a jour des paquets et Laurux dans un environement de production tant qu'une phase d'évaluation n'a pas été pratiqué sur un environement de test isolé (machine virtuelle, ordinateur dédié). Une fois la phase d'évaluation finie il faut alors migrer (après sauvegarde via clonezilla par exemple) tous les postes en même temps.

Oui je comprends, c'est ce que nous faisons d'habitude, mais mon poste est passé à la 18.04LTS, qui a entraîné les problèmes de Gambas qui ont été résolus avec la 3.68.2.
Quand mon collègue a vu le bordel que c'était, il s'est abstenu de faire le passage à la 18.04 et tout le reste...
Dans le coup je fais la saisie des écritures sur son poste en attendant.

Je suis arrivé à tomber dedans, l'erreur se produit lorsque le numéro de lot est à blanc, si vous le renseignez à chaque saisie vous ne deviez plus avoir de problèmes.
Il va falloir trouver pourquoi certains numéro ne sont pas renseignés.

Bonjour,

Ça faisait quelques jours que je m'étais pas occupé de Laurux, me revoilà !

En fait en trésorerie, je ne saisis jamais de n° de lot, je met "1" en n° de document et je passe à la saisie du libellé.
Pour un virement interne (caisse vers compte bancaire) par exemple, il n'y a pas de document, c'est juste une saisie d'opération de trésorerie, donc je mets "1" sans valider pour éviter que Laurux ne râle et je passe au libellé.
Si c'est gênant, il faudrait que Laurux génère un n° de document auto en cas de non saisie de ces champs.