Bonjour Patrice,
Je viens de tester pour mon exercice en cours : tout est ok, le format FEC s’exporte correctement sans message d’erreur.
Je suis sous Windows 10 et Gestinux 1.2 stable.
Pour compléter, j’utilisais auparavant les version RC depuis la version 1.1stable2, et donc la base de données (MariaDB) se mettait à jour au fur et à mesure.

Pour info
@+

Bonjour,
Suite à mon premier message :
J’ai lettré un ( et un seul) client qui a acheté dans l’exercice en cours et dans l’exercice N-1 mais pas dans le N-2 :
résultat du fichier FEC :
sur l’exercice en cours ainsi que sur N-1 : il y a ses écritures et seulement ses écritures avec comme date de validation
des ’écritures la date d’aujourd’hui même pour N-1 clôturé
et sur le N-2 le même message ’ Aucune écriture pour les dates et la requête saisie’

D’où ma question à Stéphane :
Utilisez-vous le lettrage ?
Toutes les écritures sont-elles dans le fichier FEC ?

Merci d’avance.

Merci Stéphane pour votre réponse,
Cela va m’éviter de continuer à chercher.
Pour votre problème immédiat : vous pouvez toujours utiliser l’édition des journaux,
mais la sortie est en .pdf et il faudra donc ressaisir....
A+

Bonjour,
Avec la formule ci-dessous , j’ai bien toutes les écritures.
Reste le problème de la date de validation ?
Je pensais que la date de validation était la date à compter de laquelle il n’était plus possible
de modifier l’écriture, avec comme date de validation max la date où l’on dépose la liasse fiscale.
Moi de toute façon sur l’exercice en cours où sur les 2 exercices clôturés j’ai un champ vide.
Si quelqu’un a des explications, le suis preneur.

A+

SELECT
j.Code AS ’JournalCode’,
j.Name AS ’JournalLib’,
@i :=@i+1 as ’EcritureNum’,
date_format(m.MoveDate, ’%Y%m%d’) AS ’Date’,
a.Account AS ’CompteNum’,
a.Name AS ’CompteLib’,
m.Id AS ’PieceRef’,
date_format(m.MoveDate, ’%Y%m%d’) AS ’PieceDate’,
m.MoveText AS ’EcritureLib’,
CASE WHEN ml.Amount > 0 THEN ml.Amount ELSE NULL END AS ’Debit’,
CASE WHEN ml.Amount < 0 THEN -ml.Amount ELSE NULL END AS ’Credit’,
’ ’ AS ’EcritureLet’,
’ ’ AS ’DateLet’,
date_format(m.UpdateDate, ’%Y%m%d %H :%i :%s’) AS ’ValidDate’
FROM Moves m
JOIN Journals j ON j.Id=m.JournalId
JOIN MoveLines ml ON ml.MoveNumber=m.Id
JOIN Accounts a ON a.id=ml.AccountId
JOIN (SELECT @i :=0) cpt
WHERE m.MoveDate BETWEEN :StartDate AND :EndDate ;

Merci à ceux qui s’intéressent à ce sujet.
La requête ainsi corrigée permet d’afficher les informations de lettrage.
Cependant je ne pense pas qu’elle soit encore aboutie et ceci pour 2 raisons :
– la date d’écriture ne peux pas être la même que la date du document.
– la date de validation est obligatoire et elle n’existe dans cette dernière formulation
que pour les écritures lettrées.
Si j’arrive à sortir un fichier qui passe le test formel de la validation proposée par l’administration
je vous en fais part.

Patrice.

je ne pense pas qu’elle soit encore aboutie et ceci pour 2 raisons :
– la date d’écriture ne peux pas être la même que la date du document.
– la date de validation est obligatoire et elle n’existe dans cette dernière formulation

Bonjour Patrice,

Actuellement on ne saisit dans Gestinux qu’une date d’écriture, qui devrait être normalement la date du document (quand il y en a un).
Une date de saisie est aussi enregistrée automatiquement, mais il n’y a pas de date de validation distincte de la date de saisie, ni de procédure pour la générer.

Pour ma part, ces deux dates d’écriture et de saisie m’ont toujours suffit, y compris avec d’autres logiciels comptables avant Gestinux.

Une date de validation est retournée par Gestinux avec la requête FEC (le dernier champ ValidDate) et c’est la date de saisie.
Quelle serait selon vous, ou selon l’administration, une meilleure date de validation ? Comment et quand la saisir ?

D’autre part, est-il réellement obligatoire d’avoir une date d’écriture distincte de la date du document ?
Je crois même qu’il y a beaucoup de cas où ces deux dates sont nécessairement identiques (ex : facture imputée le jour même de son émission).
En lisant les spécifications du format FEC je n’ai pas eu l’impression que c’était un problème, et je n’ai pas trouvé de définition exacte de chaque colonne...
Avez-vous connaissance de textes précis à ce sujet ?

Mais, bien entendu, on est tous intéressés par un test de validation formelle.
Ce sujet n’est pas clos...

Bonjour

Pour les 4 champs "manquants" il est facile de les ajouter, et aussi de changer le libellé, comme vous l’avez fait.

Pour le champ "ValidDate", il suffit alors de prendre la date de clôture du journal associé à l’écriture (j.CloseDate).
Il me semble que cela répond à la demande pour ce champ, à condition de s’assurer que tous les journaux sont clôturés.

Par contre je n’ai pas compris ce qu’il y a dans votre nouveau champ VDate et en quoi il diffère de MoveDate ?
Avec cette précision, et si personne ne l’a fait avant, je vous donnerai la nouvelle requête.

Bon d’accord.

Le champ UpdateDate est un champ "technique" qui existe dans toutes les tables et qui est mis à jour automatiquement par toute modification de la ligne correspondante, même par un autre logiciel que Gestinux, notamment une importation, ou une restauration de sauvegarde ou phpMyAdmin.

Si une date de saisie était stockée dans un autre champ, uniquement par Gestinux, je pense que cela ne serait pas très fiable.
Il peut exister des logiciels externes qui enregistrent des écritures sans passer par Gestinux, et on ne peut jamais être sûr qu’ils enregistrent la bonne date là où il faut.
Et aussi les importations de Gestinux doivent ou non mettre à jour cette date, cela dépend de leur fonction exacte.

Une solution serait de modifier le déclencheur (trigger) qui met à jour le champ UpdateDate, en faisant en sorte qu’il ne prenne l’heure système que si l’un des autres champs est différent.
Ainsi, dans le cas d’une restauration il garderait la valeur de la source.
Ça doit être possible, mais la difficulté est que Gestinux doit fonctionner aussi avec PostgreSql.

Dans un 1er temps je vais tâcher de vous fournir la requête qui change le déclencheur sous MySql.
Provisoirement, il faudra la passer sans réorganiser (vérifier) la base avec Gestinux 1.2 qui sinon remettra le déclencheur défini par cette version.
Ensuite dans la version suivante cela devrait être complètement intégré.

Bonjour Patrice (en particulier)

Attention, ça va être un peu technique...

J’ai fait un script qui modifie les déclencheurs (triggers) des tables qui enregistrent les écritures comptables et je pense l’intégrer à la prochaine version de Gestinux (1.4, publiée au printemps probablement).
Il ne touche pas au champ UpdateDate, mais ajoute et tient à jour automatiquement un champ EntryDate dans les entêtes d’écritures.
Ce champ sera automatiquement mis à jour si une écriture ou une ligne d’écriture est changée par Gestinux ou autre, SAUF en cas de restauration complète.
Une restauration complète est un script SQL qui insère explicitement le champ UpdateDate (ce que ne fait pas Gestinux).
Dans ce cas on restaurera la valeur exacte de UpdateDate (et de EntryDate) qui ne seront donc pas modifiées.
C’’est le champ EntryDate qu’il faudra utiliser dans la requête FEC pour avoir la "vraie" date de mise à jour.
On devrait même peut-être pouvoir améliorer encore en interdisant que cette date soit supérieure à la date de clôture du journal, mais ce sera pour plus tard...

Ce script est compatible avec une base Gestinux 1.2, mais un autre problème se pose dans cette version.
Elle n’exporte pas UpdateDate, ni les champs non créés par le logiciel comme EntryDate.
Donc, il n’y aura pas de restauration complète si on a créé l’export avec Gestinux.
Si vous passez le script, il faut aussi faire vos exports par un autre moyen. PhpMyAdmin, ou tout autre moyen équivalent.
La prochaine version de Gestinux exportera tous les champs présents dans la table, même non créés par lui.

Donc tout devrait être réglé dans la prochaine version de manière transparente, mais avec la version actuelle cela reste un peu compliqué...

Une solution plus simple serait évidemment de mettre votre base sur un serveur internet, pour éviter les sauvegardes et restaurations et y accéder de partout !

Bonjour,
Suite à tout cela, on utilise la requête d’origine ou le code modifié de Patrice pour l’export FEC1.2 ?
Merci 😀

Bonjour et merci Tintinux pour ces infos
😉

Bonjour Patrice,

Dans ce message j’ai indiqué comment importer un fichier au format FEC, c’est prévu dans Gestinux 1.2 (à un bug près, qu’on peut contourner).

Bien à toi
G.