Ecritures FEC V1.2

Pour les questions concernant l'utilisation et le paramétrage d'une version pré-compilée de gestinux, téléchargée sur SourceForge.net
Donnez la version de gestinux et de votre système d'exploitation.

Utilisez uniquement le forum Développement si vous compilez vous-même.
Stéphane
Posts: 92
Joined: 13 Jan 2015, 07:53
Location: Périgord

Re: Ecritures FEC V1.2

Post by Stéphane »

Bonjour,
C'est bizarre car pour moi, les informations de lettrage ne figurent pas dans l'export, même avec la requête de Gastounet
:roll:

Edit du 07/12/15:
Le fichier issu de la requête de Gastounet fonctionne.
La cause de mon message était si le fichier d'export existait, Gestinux ne remplaçait pas le fichier (malgré un message correct d'export), par contre si une nouvelle dénomination pour un nouveau fichier est saisi : tout est ok
;)
tintinux
Site Admin
Posts: 169
Joined: 21 Jun 2012, 19:07
Location: Blois (France)
Contact:

Re: Ecritures FEC V1.2

Post by tintinux »

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...
Cordialement,

Tintinux
Patrice
Posts: 36
Joined: 18 Mar 2013, 14:26

Re: Ecritures FEC V1.2

Post by Patrice »

Bonjour Tintinux,
Je m'appuie sur le document suivant que j'essaie d'interpréter:
http://www.experts-comptables.fr/sites/ ... 2015_0.pdf

Champ 4 - date de comptabilisation (page 50 du pdf)
Une date de saisie est enregistrée automatiquement
:
S'IL S'AGIT BIEN de UpdateDate de la table Moves:
- cette date est modifiée par la date système lors d'une restauration : si je restaure à la maison aujourd'hui le fichier sql fait au boulot
j'ai toutes mes écritures (y compris celles des exercices clôturées) en date d'aujourd'hui (je parle de UpdateDate).
- Si le point ci-dessus peut être résolu , il suffirait de modifier la requête SQL du champ 4 : UpdateDate_format(m.MoveDate,'......) AS ......,

Champ 6 - date de validation ( page60 du pdf):
'Elle doit avoir lieu au plus tard lors de la liasse fiscale'
Je propose d'ajouter un champ ValidDate à la table Moves et de le renseigner avec la date de clôture,
je pense que cette solution ne va pas convenir à tout le monde car cela suppose de clôturer avant de faire la liasse fiscale
(ce que je fais car je pense ainsi assurer le caractère probant de ma compta).

CONTROLE DE LA STRUCTURE DU FEC:
pour faire le test j'ai ajouté (avec PhpMyAdmin) dans la table Moves deux champs date (je ne voulais pas toucher à UpdateDate)
- WDate pour la date d'écriture
- VDate pour la date de validation
ces deux champs je les ai renseignés avec des requêtes sql (avec les dates proposées ci-dessus)
puis j'ai passé le test proposé par l'administration qui m'a retourné 5 erreurs
Champ 4 --- Le champ doit être ECRITUREDATE et non DATE
Il manque 4 champs : COMPAUXNUM, COMPAUXLIB, MONTANTDEVISE, IDEVISE
Ces 4 champs doivent être vides si pas utilisés.
Le fichier généré par la requête ci-après a lui été validé:

Code: Select all

 SELECT
       j.Code AS 'JournalCode',
       j.Name AS 'JournalLib',
       @i:=@i+1 as 'EcritureNum',
       date_format(m.WDate, '%Y%m%d') AS 'ECRITUREDate',
       a.Account AS 'CompteNum',
       a.Name AS 'CompteLib',
       ' '  AS 'COMPAUXNUM',
       ' '  AS 'COMPAUXLIB',
       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',
       r.ReconciliationString AS 'EcritureLet',
       date_format(r.UpdateDate, '%Y%m%d %H:%i:%s') AS 'DateLet',
       date_format(m.VDate, '%Y%m%d ')   AS  'ValidDate' ,
       ' '  AS 'MONTANTDEVISE',
       ' '  AS 'IDEVISE'
    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
    LEFT JOIN Reconciliations r ON r.MoveLineId=ml.MoveLineId
    JOIN (SELECT @i:=0) cpt
    WHERE m.MoveDate BETWEEN :StartDate AND :EndDate ;
J'espère que ce pavé ne va pas vous décourager de continuer ...

A+
Patrice
tintinux
Site Admin
Posts: 169
Joined: 21 Jun 2012, 19:07
Location: Blois (France)
Contact:

Re: Ecritures FEC V1.2

Post by tintinux »

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.
Cordialement,

Tintinux
Patrice
Posts: 36
Joined: 18 Mar 2013, 14:26

Re: Ecritures FEC V1.2

Post by Patrice »

Merci Tintinux de répondre aussi rapidement,

Pour ValidDate cela me parait réglé avec l'utilisation de la date de clôture du journal associé.

Pour EcritureDate et MoveDate:
MoveDate est la date de la pièce enregistrée: elle correspond au champ 10 du fichier FEC 'PieceDate'
EcritureDate est la date à laquelle on enregistre la pièce et que vous mettez dans UpdateDate
cette date est bien modifiée si on modifie l'écriture un autre jour.
C'est cette date qu'il me semble devrait être dans le champ 4 du fichier FEC 'EcritureDate'
or cette date est modifiée si on transfert le fichier sql : on ne peut donc pas l'utiliser.

C'est à mon sens le seul problème qui reste.
La validation formelle étant acquise.

Bien à vous.
tintinux
Site Admin
Posts: 169
Joined: 21 Jun 2012, 19:07
Location: Blois (France)
Contact:

Re: Ecritures FEC V1.2

Post by tintinux »

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é.
Cordialement,

Tintinux
Patrice
Posts: 36
Joined: 18 Mar 2013, 14:26

Re: Ecritures FEC V1.2

Post by Patrice »

Merci Tintinux

En attendant de pouvoir utiliser m.UpdateDate sur la ligne 'ECRITUREDate',
le code qui va bien est:

Code: Select all

SELECT
       j.Code AS 'JournalCode',
       j.Name AS 'JournalLib',
       @i:=@i+1 as 'EcritureNum',
       date_format(m.MoveDate, '%Y%m%d') AS 'ECRITUREDate',
       a.Account AS 'CompteNum',
       a.Name AS 'CompteLib',
       ' '  AS 'COMPAUXNUM',
       ' '  AS 'COMPAUXLIB',
       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',
       r.ReconciliationString AS 'EcritureLet',
       date_format(r.UpdateDate, '%Y%m%d %H:%i:%s') AS 'DateLet',
       date_format(j.CloseDate, '%Y%m%d ')   AS  'ValidDate' ,
       ' '  AS 'MONTANTDEVISE',
       ' '  AS 'IDEVISE'
    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
    LEFT JOIN Reconciliations r ON r.MoveLineId=ml.MoveLineId
    JOIN (SELECT @i:=0) cpt
    WHERE m.MoveDate BETWEEN :StartDate AND :EndDate ;
Bien à vous.
tintinux
Site Admin
Posts: 169
Joined: 21 Jun 2012, 19:07
Location: Blois (France)
Contact:

Re: Ecritures FEC V1.2

Post by tintinux »

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 !
Attachments
EntryDate.sql
script créant un champ Moves.EntryDate modifiant les triggers pour qu'il soit tenu à jour automatiquement, sauf restauration d'une sauvegarde complète.
(1.67 KiB) Downloaded 713 times
Cordialement,

Tintinux
Patrice
Posts: 36
Joined: 18 Mar 2013, 14:26

Re: Ecritures FEC V1.2

Post by Patrice »

Bonjour Tintinux,

J'ai exécuter le script sans problème,
et fait une sauvegarde via phpmyadmin que j'ai pu transférer sur un autre PC en conservant EntryDate.
La requête FEC utilise désormais Entrydate.
Je pense passer la base sur un serveur Internet pour simplifier.

Merci de votre réactivité.

Bien à vous.
Stéphane
Posts: 92
Joined: 13 Jan 2015, 07:53
Location: Périgord

Re: Ecritures FEC V1.2

Post by Stéphane »

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