[Résolu] Export malencontreux

Bonjour la communauté Dolibarr,
Lors d’un export malencontreux de grand livre j’ai omis de décocher les 2 cases qui interdisent la modification ou la suppression des écritures exportées
Il y a sûrement un moyen de modifier ce paramètre directement dans la base de données en SQL ou par phpmyadmin
Quelqu’un connaît-t-il la table et le champ à modifier ?
Merci par avance

Bonjour,

il faut mettre à NULL les colonnes date_validated et date_export sur toute les lignes que vous sortie dans l’export dans la table llx_accounting_bookkeeping

Rapide, concis, efficace …
Merci @FHenry
Ne pourrait-on pas à l’avenir ne PAS cocher par défaut les 2 cases du popup avant export ?

Bonjour @jmmassion ,

la « normalité » veut qu’une fois exportée (vers un expert comptable), on ne touche plus aux écritures. Quitte à passer des OD après sur conseil du comptable, pour changer des écritures de comptes, ou autres corrections.

Le sujet a déjà été débattu sur le forum plusieurs fois, mais je ne sais plus ce qui a été décidé pour l’avenir. Peut être que ce changement interviendra quand la procédure de clôture d’exercice avancera ?

@aspangaro-Inovea @eldy vous pouvez nous (re-)éclairer svp ? :slight_smile:

@Arre j’entends bien, mais du coup c’est l’expert comptable qui a la version certifiée de la comptabilité, et c’est lui qui rendrait des comptes à l’administration fiscale
Alors pourquoi s’infliger des contraintes supplémentaires sur Dolibarr, qui ne sert qu’à mâcher le travail du cabinet ?
Et en plus, par défaut il verrouille les lignes exportées.
C’est de l’auto-flagellation ! :slight_smile:
Surtout qu’on peut toujours utiliser phpmyadmin
La seule manière d’avoir une instance Dolibarr certifiée serait de l’héberger sur un Cloud qui ne donnerait pas accès à la base de données avec des outils SQL

Hello,

Il y a une option pour ça : Probleme comptable cloture et à nouveau - #20 par aspangaro-Easya

la constante ACCOUNTING_DEFAULT_NOT_NOTIFIED_VALIDATION_DATE peut être activé à 1 dans Accueil > Configuration > Divers pour que la validation ne soit pas cochée par défaut.

1 « J'aime »

Merci @ksar
Je vais tester ça dès demain

@ksar
ah oui c’est vrai, c’est une constante qui avait été mise en place !

@jmmassion
c’est toi qui vois :slight_smile:

En effet, en v15, le blocage définitif peut maintenant se faire dans la fonction « Cloture » (on valide tous les enregistrements qui ne sont alors plus modifiables ni supprimables).
Mais on doit pouvoir aussi le faire durant l’export.
Toutefois la valeur par défaut qui était de tout bloquer au premier export (sans meme autoriser un test) provoque des situations bloquantes pour de nombreux utilisateurs alors qu’on voulait générer simplement un fichier.
J’ai corrigé pour inverser l’option par défaut de la fonction « Validé et exporter » (non coché par défaut) et aussi renommé en « Validé et vérrouiller ».
Cette « lethal feature » est donc corrigée et ne devient à nouveau lethal que si on utilise la fonction « cloture » mais, comme la c’est son but, ce n’est plus une « lethal feature » mais une « expected feature ».

Rem: Les options
ACCOUNTING_DEFAULT_NOT_NOTIFIED_VALIDATION_DATE
ACCOUNTING_DEFAULT_NOT_NOTIFIED_EXPORT_DATE
permettent de forcer toutefois la valeur positionné par défaut.

Hello,

Merci Laurent, je rajouterai des options graphiques dans le module comptabilité pour pouvoir régler par défaut.

Par contre, le « notified_export_date » aurait du rester dans sa position car c’est le mode par défaut depuis la v10… Les utilisateurs ont l’habitude, on leur donne le choix dans la v14 pour préparer à me débarrasser de l’export brouillon journaux qui sert mais ne respecte pas les formats d’export et n’est pas dispo partout.

Bonne journée,

Merci @eldy ,
En V14, il faut utiliser :
ACCOUNTING_DEFAULT_NOT_NOTIFIED_VALIDATION_DATE
ACCOUNTING_DEFAULT_NOT_NOTIFIED_EXPORT_DATE

Un grand merci à tous, vous êtes au top !
je peux maintenant exporter sereinement mes écritures
J’ai encore quelques soucis d’import que je développerai dans un futur post
L’objectif final étant d’avoir 2 instance Dolibarr, une en ligne et la seconde en local et de pouvoir mettre la version locale à jour une fois par mois sans pour autant exporter/importer toute la base de données

Bonjour,
J’utilise Dolibarr depuis environ 1 an pour la comptabilité de notre association. Ce forum m’a souvent été utile et je remercie tous les contributeurs.
J’ai aujourd’hui le même problème que « jmmassion » et la solution que vous apportez me permettrait de la corriger.
Malheureusement, je n’ai aucune idée de la façon de la mettre en pratique ! Comment puis-je accéder à la table dont vous parlez ?
Merci d’avance pour votre aide précieuse.

Bonsoir @PATCH
Cela dépend de votre infrastructure
Votre instance Dolibarr est-elle hébergée ou bien installée en local, ou bien encore installée sur un serveur privé ?
Il convient dans tous les cas de se ménager la possibilité d’un retour en arrière en effectuant une sauvegarde complète de la base de données Mysql

Bonjour,
L’instance est installée en local. Je l’ai mise à jour avec la version 15.0.0. Je fais des sauvegardes assez régulièrement, celle du 16 novembre 2021 a été faite avant mon export problématique. Les suivantes ont été faites après.

Dans ce cas, on doit pouvoir accéder à la base de données par le navigateur à l’adresse suivante :
http://localhost/phpmyadmin/

J’arrive à cet écran :

Je ne trouve pas d’accès aux tables.

Bonjour,
J’ai déjà essayé :

Ensuite j’ai tenté :
localhost/phpmyadmin/config.inc.php

Mais j’arrive sur une page blanche …