Bonjour,
Depuis notre passage en 7.0.2 nous rencontrons un problème très contraignant sur la partie comptabilité.
Nous sommes en v7.0.2, niveau 0 de fonctionnalités et un export compta configuré pour Quadratus QuadraCompta.
J’ai tout d’abord eu ce bug lors de la mise-à-jour : www.dolibarr.fr/forum/t/update-7-0-1-7-0-2/27481/1
J’ai ensuite rencontré ce problème www.dolibarr.fr/forum/t/bug-journaux-comptables/27485/1 et ai appliqué les deux corrections exposées sur github.
Dolibarr affiche maintenant correctement la liste des différents journaux.
Le second soucis qui, lui, est toujours présent.
J’ai des erreurs de ce type lors de la ventilation dans le grand livre des tous mes cinq journaux de banque et de mon journal de caisse.
Les journaux de vente et d’achat ne sont pas impactés.
Error Data too long for column 'doc_ref' at row 1
Try to insert a non balanced transaction in book for BankId 970 - Facture fournisseur SI1805-0650. Canceled. Surely a bug.
Error Data too long for column 'doc_ref' at row 1
Try to insert a non balanced transaction in book for BankId 877 - Facture FA1803-0029. Canceled. Surely a bug.
Error Data too long for column 'doc_ref' at row 1
Try to insert a non balanced transaction in book for BankId 898 - Facture fournisseur SI1804-0592. Canceled. Surely a bug.
ErrorTooManyErrorsProcessStopped (>5)
×
Certaines des opérations n'ont pu être journalisées. S'il n'y a pas d'autres messages, c'est probablement car elles sont déjà comptabilisées.
Un ticket reprenant toutes les informations a été déposé sur le github mais il ne semble pas intéresser grand monde ou du moins, je ne vois pas d’activité dessus.
==> https://github.com/Dolibarr/dolibarr/issues/8859
Est-ce un problème dont nous serions responsables ou est-ce bien un bug de cette révision de dolibarr ?
Bonjour,
Le problème est toujours présent sur la toute nouvelle v7.0.3 et ce après une installation propre.
Par installation propre j’entends installer la 7.0.3 en tant que nouvelle instance vierge puis restaurer le dossier ‹ documents › et restaurer la base de données.
Pas de soucis lors de l’installation de la 7.0.3 mais nous avons rencontré [url=www.dolibarr.fr/forum/t/update-7-0-1-7-0-2/27481/1 soucis[/url] lors de la restauration de la base 7.0.2 et sa mise à jour en 7.0.3
Néanmoins, le test d’intégrité de dolibarr ne remonte aucune erreur après la restauration.
Les modules externes, eux, n’ont pas encore été restaurés.
Bonjour Golgotron, 
pourrais tu me dire ce que contient « doc_ref » ? Apparemment la quantité de donnée est trop importante…
J’essaie de la localiser avec phpmyadmin
Bonsoir Patrice,
Merci tout d’abord de bien vouloir prendre le temps de me répondre ; tu es bien le seul pour le moment.
Le champs doc_ref fait partie de la table ‹ llx_accounting_bookkeeping › et contient la référence de la pièce en question.
Néanmoins je vois que cette référence prend plusieurs formes selon les cas. En voici quelques-uns :
- simple référence dolibarr pour une facture client ou facture fournisseur soit ceci : « FA1804-0123 » ou « SI1804-0123 »
- parfois on « Facture fournisseur SI1804-0123 » ou « Facture FA1804-0123 »
- parfois on a la référence propre du fournisseur suivie, entre parenthèses, de la numérotation dolibarr soit ceci « XXX-ref-facture-fournisseur-XXX (SI1804-0123) »
Si c’est bien cela, j’imagine que c’est la référence interne d’un fournisseur pour une de ses factures qui fait déborder le vase cela dit je ne parviens pas à trouver la fautive.
En effet, la première pièce de chaque journal de compte bancaire qui met en erreur le processus compte maximum 18 caractères.
Bonjour,
Il faudrait essayer d’augmenter la valeur de l’élément docref.
Par défaut, il est sur 300 caractères. (Déjà vérifier si c’est bien le cas sinon il faut augmenter cette valeur)
une simple requête sql
ALTER TABLE llx_accounting_bookkeeping MODIFY COLUMN doc_ref varchar(300);
C’est déjà bien d’avoir ces indications, on avance …
Merci pour la réponse de fond et la requête prête à être envoyée.
Apparemment ça fonctionne maintenant. J’attends le retour de mon expert comptable pour savoir si l’export du GL est « mangeable » de son côté
Je confirme que la requête SQL résous bien le soucis, merci encore.
SVP donner un reponse sur cette erreur est merci
