Pas de problème 
Tu veux des captures de quoi ?
de tout ce qui mène a ton pb :
pour essayer de le reproduire.
- au mieux ça mettra à jour un VRAI pb
- au pire … ça corrigera un pb de paramètrage chez toi
voila, j’ai ré effacé mon grand livre et recommencé ma ventilation…
Bonsoir,
Je comprends mieux ce qu’il se passe grâce aux données transmises par @goldotron. Tout fonctionne sauf qu’à cause du correctif pour intégrer la notion de compte auxiliaire depuis les paiements divers, un message non bloquant s’affiche pour dire que le compte auxiliaire n’a pas été renseigné mais il y a une sécurité, au delà de 5 messages, l’inscription en comptabilité s’arrête tout simplement d’où une intégration compliqué (du coup le mois par mois ou moins aide) pour les gros consommateurs de paiements divers. Je vais faire un nouveau correctif pour supprimer l’affichage du message, ça résolve ta notre problématique.
Par contre, je vois pas ce que vient faire le lettrage la dedans.
Bientôt de retour.
Bonne soirée et merci à tous pour les infos
Bonsoir @aspangaro-Inovea
Apparemment ce n’est toujours pas ça 
J’ai essayé de ventiler 3 écritures en même temps et même problème…
Merci pour l’essai, je regarde ça au plus vite, j’ai des indices
Bonjour @aspangaro-Inovea
Je viens aux nouvelles à savoir si tu as trouvé quelque chose…
Pour ma part, j’ai pris un peut de temps pour faire des tests.
Donc, en passant le nombre max d’erreurs à 100 tout s’inscrit sauf les erreurs. C’est bien les erreurs de compte qui font bloquer:
bookkeeping.class.php:
// Check parameters
if (($this->numero_compte == "") || $this->numero_compte == '-1' || $this->numero_compte == 'NotDefined')
{
$langs->loadLangs(array("errors"));
if (in_array($this->doc_type, array('bank', 'expense_report')))
{
$this->errors[]=$langs->trans('ErrorFieldAccountNotDefinedForBankLine', $this->fk_docdet, $this->doc_type);
C’est bien le « NotDefined » qui pose problème et nous fait sortir avec ces erreurs.
Quelqu’un à une idée ?
Et on affichent le « NotDefined » à cause de ca:
bankjournal.php:
if (! empty($tabcompany[$key]['code_compta']))
Alors…
On bloque parce que le compte auxiliaire et « NotDefined »…
En commentant cette condition ça fonctionne:
bankjournal.php 1169:
if (empty($accounttoshowsubledger) /*|| $accounttoshowsubledger == 'NotDefined'*/)
Maintenant, quelles sont les conséquences niveau compta ?
Pourquoi faut il obligatoirement un compte auxiliaire ?
@Arre tu aurais une idée ? 
Bonjour,
Je cherche un correctif « propre » sans commenter de code car sinon cela aura un impact sur le reste des opérations contenant un compte auxiliaire.
Je reviens dès que possible sur le sujet.
1 « J'aime »
Bonjour,
Je me sert des paiement divers pour enregistrer les paiements dont les montant ne sont pas soumis a TVA
Comme les frais bancaire sans tva, la poste …
du coup, je saisie la banque puis en compte comptable le compte comptable associé
un exemple en piece jointe
Faut il mettre un compte auxiliaire ? le fournisseur LAPOSTE par exemple ?
Si on met un compte auxiliaire, quelle influence en comptabilité ?
Si on n’en met pas, quelle influence il y a en comptabilité ?
Merci d’avance.
Eric
Bonjour,
Je relance le sujet, déjà pour savoir si le problème à été résolu, mais surtout parce que je pense avoir un autre problème du même type mais qui là, est extrêmement bloquant pour moi.
J’ai acheté le module « trésorerie » de open-DSI étant en BNC pour que ma comptable n’aie pas à « re-travailler » le grand livre lorsque je lui fourni. Bref, mon souci c’est que j’ai le même problème (impossible de transférer dans le grand livre certaines écriture). J’ai des erreurs comme quoi les entrées existent déjà mais après multiples versifications et tests ces écritures ne sont pas encore dans le grand livre et je ne décèle aucune differences entre une écriture qui passe et une qui passe pas.
J’en suis arrivé à vider toute les tables (facture fournisseur, TVA, charges spéciale, etc…) pour ne garder que les factures client à transfèrer et j’ai toujours le même résultat.
Je fais la ventilation sur un mois de seulement 4 écritures et seulement deux passent…
La table du grand livre vidée au préalable et après le transfert:
On voient bien que 939 et 146 n’existent pas dans fk_doc et fk_docdet…
Je penses que ces deux problèmes ont la même origine… Mais là vraiment je sèche 
J’ai vraiment besoin d’aide sur ce coup là.
Merci d’avance.
Je penses avoir trouvé le problème… Mais pas la solution.
A priori les erreurs arrivent lorsque qu’il y à plusieurs factures sur un seul paiement.
(Mes client font des « vagues » de paiement chaque mois et si il y a plusieurs factures dans le mois il font un seul virement de la totalité…)
Quelqu’un sait il comment je peux m’en sortir svp ? 
Bonjour,
Merci pour votre achat, on se penchera sur le bug dès lundi.
Le multipaiement sur une même facture ne devrait pas être en cause car nous avons très très bien testé ce point.
En attendant, on va commencer les questions car je pense que ça vient de là :
Au niveau des produits que vous vendez, avez vous des décimales assez importantes et potentiellement des quantités importantes sur les lignes qui posent problèmes ?
Si oui, nous sommes sur une problématique d’arrondi que je soupçonne depuis longtemps.
Pourriez vous éventuellement transmettre un dump de votre base à aspangaro AT open-dsi DOT fr
J’aimerai bien trouver une solution à cette satanée erreur !
Bon week end
1 « J'aime »
bonjour @aspangaro-Inovea,
non, non, c’est de la vente de service avec des prix rond. Par contre le problème est le même sur les factures fournisseur mais même chose, 2 décimales max.
J’ai modifié le module ( le nombre d’erreurs max) pour avoir toute les erreurs d’un coup sur trois ans et à chaque fois, c’est un paiement sur deux ou plusieurs factures. Je penses vraiment que le problème vient de là.
Comment vous envoyer un dump ? par MP ?
Merci d’avance.
edit : J’avais pas compris pour l’adresse 
Bonsoir,
@mdallosto, nous venons de publier une version corrective du module sur le dolistore et nous avons trouvé ce qui empêche l’inscription d’un règlement lorsque celui-ci couvre plusieurs factures.
Il faut soit appliquer le correctif suivant manuellement :
Soit copier les fichiers pour votre version depuis le dossier patch du module.
Au passage, pour le problème des alertes sur les paiements divers, même quand vous avez l’alerte, re-cliquez une deuxième fois sur l’inscription dans le grand livre, vous verrez, cela fonctionne très bien.
Et dernier point, pour ceux qui ne trouvent pas le bouton « supprimer des écritures » en bas à droite du grand livre, c’est en réalité un bug au niveau des droits, il suffit d’appliquer ce patch qui sera dans la v10.0.7 pour revoir votre bouton.
Excellente soirée
