Paiements divers - bug lors de la ventilation

Bonsoir @aspangaro-Easya

Apparemment ce n’est toujours pas ça :thinking:
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-Easya

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 ? :thinking:

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 ? :thinking:

@Arre tu aurais une idée ? :slightly_smiling_face:

oui, j’ai une idée :

@aspangaro-Easya : tu as une idée ? :slight_smile:

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 :weary:

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 ? :cold_sweat:

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-Easya,

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 :yum:

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

Bonjour @aspangaro-Easya,

Parfait, j’ai testé, tout fonctionne.

Merci beaucoup.

1 « J'aime »

Bonjour,

Je rencontre le même problème d’erreur lors de la ventilation des paiements divers sans compte auxiliaire de renseigné. Je viens de passer à la version 11 et le problème est toujours présent.
J’ai aussi observé une chose étrange. Lorsque je relance l’inscription dans le grand livre (après les messages d’erreur), la ventilation s’effectue, mais avec des erreurs dans les comptes (ventilés au mauvais endroit).

Par exemple :

  • 2 écritures à inscrire au grand livre (sans compte auxiliaire), je lance l’opération, le message d’erreur apparaît.
  • je relance l’inscription, les écritures sont ventilées.
  • je consulte le grand livre, la 1ere écriture est bien ventilée, mais la seconde est ventilée dans le même compte que la 1ère (alors que le compte renseigné est différent)

Bizarre cette histoire…
Avez-vous une idée ???

Merci de votre aide

Bonne journée

Bonjour,

Même problème que fscf85 chez moi.

Je suis en V11.0.0.

(On peut modifier la ventilation à la main dans le grand livre en dépannage…)

Merci par avance !

Rebonjour à tous,

Je pense avoir résolu le problème des erreurs liées aux paiements divers lors de l’inscription du journal de trésorerie dans le grand livre :

a la ligne 666 du bankjournal.php j’ai modifié:

$bookkeeping->numero_compte = $tabpay[$obj->rowid][« account_various »];
en
$bookkeeping->numero_compte = $tabpay[$key][« account_various »];

Desormais, plus d’erreur lors de l’inscription, et les operations sont ventilées sur les bons comptes dans le GL.

Bonsoir,

Ne pas hésitez pas ouvrir une issue sur le github pour que la correction soit faite dans les prochaines version.

Merci pour votre solution.

Cordialement,
Gaëtan.

C’est noté :slight_smile:

Merci @kevimax je vais tester cette solution.
Bonne journée