Discussion :

[gbrion]

Bonjour, voici mon problème du jour.
Lors de la création d'un enregistrement du fichier "Bon de livraison", je créé automatiquement un numéro pour le nouveau bon, de la manière suivante :
1- une requête détermine le numéro maximal utilisé dans les bons déjà enregistrés,
2- j'incrémente (+1) le numéro maximal trouvé.
Lors de la création d'un enregistrement du fichier "Facture", issu d'un bon, je sauvegarde le numéro de bon à l'origine de cette facture.

Le hic c'est quand l'utilisateur demande la suppression du bon à l'origine de la facture et si ce bon avait le numéro maximal, ce numéro est de nouveau "disponible" pour la création d'un nouveau bon. Or il y a une "trace" dans le fichier facture de l'ancien bon portant le même numéro.

Je cherche donc qu'à améliorer la création automatique du numéro de bon pour qu'à partir du numéro max trouvé par la requête, si ce numéro est répertoriée dans le fichier Facture, il incrémente d'autant jusqu'à ce qu'il trouve un numéro "libre".

Exemple : je créé un premier bon, n°1 et ensuite la facture n°1 tiré de ce bon. A la création de cette facture, je supprime le bon. Je créé un nouveau bon :
1- la requête me trouve rien comme numéro de bon, j'incrémente donc de 1.
2- je cherche dans le fichier facture si une facture est tirée d'un bon 1
3- si c'est le cas, j'incrémente à nouveau de 1. Etc.

Je sais qu'il faut que j'utilise une boucle pour lire les fichiers factures, mais je ne sais pas comment à la fois lire tous les enregistrements factures, incrémenter de 1 puis recommencer la lecture, incrémenter s'il le faut. Je connais le principe mais je n'arrive pas à "coder".

Merci de votre aide (et de votre patience pour le pavé mais j'essaie d'être clair).

PS : passer par un identifiant automatique pour le numéro de BL ne changerait pas mon problème.

[Jannus]

Fait une requête SQL avec MAX sur les N° de factures/de bons, compare et prend le plus élevé.

Cela dit, cette gestion est une hérésie comptable.
Un bon = un numéro = une facture
Même si la facture invalide le bon, on ne doit pas récupérer le numéro de bon libéré, sinon on n'a plus de concordance.

Ou, si on se fout de la concordance, on se fout aussi du numéro de facture et on prend le premier numéro de bon libre.

[nath-0-0]

mais savais tu que tu pouvais laisser le soin a hyperfile d'incrementer l'identifiant(numéro)?

Qu'utilises tu comme bdd?

sinon "logiquement" pour faire propre tu ne devrais pas laisser supprimer une ligne de ton fichier en l'occurence le bon de livraison si la clef primaire de celui ci est utilisé par une autre ligne, en l'occurence une facture!
hemm j'espere que tu me comprends je sais pas si je suis tres claire

[gbrion]

Cela dit, cette gestion est une hérésie comptable.
Un bon = un numéro = une facture
Même si la facture invalide le bon, on ne doit pas récupérer le numéro de bon libéré, sinon on n'a plus de concordance.

J'y avais pensé et c'est ce que je voulais faire au départ. Et puis l'avancée de mon programme faisant, je suis parti sur autre chose. Mais comme je m'apprête à une refonte importante, je vais adopter ce principe "comptable" : un bon = un numéro = une facture.

Fait une requête SQL avec MAX sur les N° de factures/de bons, compare et prend le plus élevé.

Principe "comptable" ou pas, il faut que je transforme ma requête et je ne crois pas qu'avec l'éditeur je puisse faire tout celà. Tu peux me filer un coup de main au niveau SQL parce que là je débute grave !!!

Merci d'avance.

[gbrion]

mais savais tu que tu pouvais laisser le soin a hyperfile d'incrementer l'identifiant(numéro)?

J'utilise déjà l'identifiant mais pas pour les BL et les factures. Mais mes soucis sont :
- désormais d'utiliser le même numéro pour un BL et la facture tirée de ce BL,
- en cas de suppression de BL, de vérifier si le numéro automatiquement donné ne fait pas référence à une facture sans bon,
- de permettre de créer des factures "libres" sans référence à un bon.
Je ne crois pas qu'un ID me le permettrait. Mais je me trompe peut-être.

Qu'utilises tu comme bdd?

Hyperfile. Du Windev, que du Windev. C'est déjà suffisant à se dépatouiller !!!

sinon "logiquement" pour faire propre tu ne devrais pas laisser supprimer une ligne de ton fichier en l'occurence le bon de livraison si la clef primaire de celui ci est utilisé par une autre ligne, en l'occurence une facture!
hemm j'espere que tu me comprends je sais pas si je suis tres claire

Il n'y a pas de clé primaire pour l'instant car ... je n'ai fais aucune relation dans l'analyse entre les fichiers BL et factures, pour être libre.

[gbrion]

Et si au lieu de supprimer les BL ou factures, ce qui légalement, n'est pas très sains, ou au lieu de faire une sorte de fichiers de sauvegarde des BL ou factures effacés, j'utilisais la fonction HRaye pour que ces documents ne soient plus consultables mais pas supprimés physiquement.

Qu'en penses-vous ? Et ce que cette fonction est pratique et fonctionnelle ? Je ne l'ai jamais utilisée.
Pour déterminer le numéro max d'un BL, est-ce que la requête prendra en compte ces enregistrements rayés ou pas ?

[Jannus]

Perso, j'opterais plutôt pour un champ "case à cocher"
Lors du traitement du document on coche la case et le doc n'est plus disponible. Au tri soit on l'affiche grisé ou on ne l'affiche pas.

Ta requête tu peux la manipuler dans l'éditeur de requête

[gbrion]

Pour la fonction HRaye, j'ai fait un essai mais cela ne va pas. Super pour le fait de "cacher" l'enregistrement et de pouvoir le "réactiver". Mais l'index de l'enregistrement est supprimé. Du coup, pour ma requête, cela ne va pas.

Perso, j'opterais plutôt pour un champ "case à cocher"
Lors du traitement du document on coche la case et le doc n'est plus disponible. Au tri soit on l'affiche grisé ou on ne l'affiche pas.

En fait pas de suppression physique mais une rubrique de plus dans le fichier (alimentée par la case à cocher). Et si la rubrique est sur vrai (ou 1, je ne sais plus pour la case à cocher), l'enregistrement est masqué dans les diverses listes. Soit automatiquement, soit via un tri. C'est cela ?

Ta requête tu peux la manipuler dans l'éditeur de requête

Je sais que je peux la manipuler via le code SQL, mais c'est le langage SQL que je connais aussi bien que ... les traditions religieuses des petites soeurs de la charité humaine !!!

[Jannus]

une rubrique de plus dans le fichier (alimentée par la case à cocher). Et si la rubrique est sur vrai (ou 1, je ne sais plus pour la case à cocher), l'enregistrement est masqué dans les diverses listes. Soit automatiquement, soit via un tri. C'est cela ?

Oui

Je sais que je peux la manipuler via le code SQL, mais c'est le langage SQL que je connais aussi bien que ... les traditions religieuses des petites soeurs de la charité humaine !!!

Et les ressources DVP ? --> http://sqlpro.developpez.com/cours/sqlaz/fonctions/

[gbrion]

Merci beaucoup, je n'avais pas vu ces ressources.
Et merci pour les conseils.

[gbrion]

Comme je dois refaire une GROSSE ( ) partie du logiciel, j'essaie de profiter de votre aide pour tout remettre à plat et bénéficier de vos conseils.

Côté légal :

Je me suis un peu renseigné grâce à Internet et notamment grâce au B.O.I. (Bulletion Officiel des Impôts) 13 L-1-06 N° 12 du 24 JANVIER 2006. Ce B.O.I. porte sur le contrôle des comptabilités informatisées. Il est effectivement interdit désormais toute altération (modification ou à plus forte raison suppression) de toute pièce finale (facture) mais aussi intermédiaire (devis, commande) SI LA FACTURE EST TRANSFEREE EN COMPTABILITE.

Par contre SI LA FACTURE N'EST PAS ENCORE TRANSFEREE EN COMPTABILITE, celle-ci est modifiable et supprimable. Par contre, les pièces intermédiaires (devis ou commande) ne peuvent être modifié ou supprimé que si la pièce précédente a été supprimée (la facture pour la commande, la commande pour le devis).

Comme je n'ai pas prévu (et ne prévois pas pour l'instant) d'export pour la compta, ce sera à l'utilisateur de savoir si la factue a été transférée ou pas en compta. Pour ce qui est d'être transmise au client, un avoir est obligatoire pour toute modification ou suppression d'une facture (je rajouter cela à mon programme plus tard).

Côté programmation :

Entre les obligations légales (comptables et/ou fiscales), l'aspect pratique du logiciel pour l'utilisateur (important aussi) et le fait que je dois par programmation parvenir à éviter les "trous" dans la numérotation des factures, j'en suis arrivé à ce résumé :

CONCLUSION :

- modification des BL :
• Permettre de modifier ou supprimer (masquer) les bons s’ils n’ont pas fait l’objet d’une facture,
• Interdire de modifier les bons s’ils ont fait l’objet d’une facture (même si celle-ci a été masquée).

- modification des FAC :
• Permettre de modifier entièrement les factures libres (qui n’ont pas été édité à partir d’un BL)
• Permettre de ne modifier que certaines rubriques des factures éditées depuis un BL (celle non présente dans le BL d'origine) :
• La date de la facture (en respectant la chronologie des pièces => OBLIGATOIRE),
• Le prix unitaire H.T. des produits (non présent dans le BL => je ne vois pas l'intérêt),
• La réduction acquise à la date de la facture,
• La date de règlement.
• Interdire la modification complète d’une facture éditée depuis un bon, l’utilisateur est obligé de supprimer (masquer) la facture puis le bon de livraison,
et de refaire l’intégralité du processus => info à l’utilisateur

- suppression (masquage) des BL et des FAC :
• Remplacer la suppression d’un BL ou d’une facture par un masquage de l'enregistrement dans les listes (caché, plus modifiable mais pas supprimé).
Pour la facture, conseiller et proposer une impression papier avant l’effacement.
• Le masquage d’une facture éditée depuis un bon entraînera automatiquement celle du bon.
• Créer un menu permettant de consulter (voir d’imprimer) les BL / Factures masqués.

Dites-moi ce que vous pensez de tout ce résumé.

Par contre, j'ai un dernier GROS soucis. La suppression d’un BL qui n’a pas donné lieu à une facture va entraîner un « trou » dans la numérotation des factures (puisque un BL = un numéro = une facture). Par exemple : je fais un BL n° 1 que je transforme en Facture n°1, je fais un BL n° 2 que je masque (pas de facture éditée avant, plus possible d’en éditer une après puisque masquée) puis un BL n°3 transformé en Facture n°3. Donc la Facture n°2 n'existera jamais.
Pour l'instant, je n'ai trouvé que deux solutions possibles mais BOF !!! :
• Soit à la suppression du bon créer une « fausse facture » vide
• Soit supprimer physiquement le BL pour pouvoir réutiliser le numéro pour un prochain BL (dans ce cas, comment faire pour retrouver et réutiliser le n° de BL : pas par la requête Max).

Merci encore de votre aide et de votre patience.

[Jannus]

avec cette question, on s'éloigne du cadre du forum avec cette question qui relève plus du binôme conception <-> cadre légal que du développement pur et simple, et encore moins de Windev.

Ceci posé, quelques remarques sur ton projet.
1- tu dis : "Si la facture n'est pas encore transférée en comptabilité"
Les termes légaux sont "validation de la comptabilité", CàD, "verrouillage" des opérations. (cf remarque (*) en fin de post)
Donc, les opérations comptables sont enregistrées tout au long de la période, généralement mois ou un trimestre, en association avec la période de déclaration TVA.
Les pièces comptables doivent être validées pour faire la déclaration TVA

2- "ce sera à l'utilisateur de savoir si la facture a été transférée ou pas en compta"
Non !!
C'est un point essentiel du logiciel qui doit effectuer la validation des pièces comptables et gérer l'impossibilité de retour en arrière après validation.
L'utilisateur n'a que la décision d'effectuer l'opération, mais il ne peut avoir aucun contrôle sur celle-ci

3- Date du règlement : ce n'est pas une notion comptable et cela ne figure sur la facture qu'à titre indicatif pour le débiteur.

4- TVA : la facture doit comporter les montants hors TVA + le taux de TVA (éventuellement par article s'il peut être différent) + le montant total HT + le montant de la TVA + le montant total TTC
(à vérifier sur le code comptable français, mais ce sont je pense des mesures européennes)

5- "Remplacer la suppression d’un BL ou d’une facture par un masquage de l'enregistrement dans les listes (caché, plus modifiable mais pas supprimé)"
Je ne pense pas que ce soit une bonne idée pour le BL
Cela ne peut pas être pour les factures

6- "Pour la facture, conseiller et proposer une impression papier avant l’effacement."
Non !
Une facture annulée DOIT être détruite.
Une facture annulée n'existe pas. En garder une trace écrite est une source de confusion et de problèmes.

Pour les points 5 & 6 :
Il faut dissocier le traitement des BL et des Factures.
La facture est une pièce comptable, pas le BL
Il n'y a à mon sens aucune obligation légale pour les BL, sauf si ceux-ci sont considérés comme Devis.
De toute façon, il ne doit pas y avoir de relation directe BL <-> Facture.
Ex. : on peut envisager de facturer plusieurs BL sur une seule Facture
Cela relève de la gestion d'entreprise du client
Par contre, la Facture doit répondre à des normes légales.

7- "Soit à la suppression du bon créer une « fausse facture » vide"
illégal et impossible à gérer
les N° des factures "validées" doivent se suivre
ce qui ne serait pas possible en gardant des factures "vierges"

8- Date et N° des BL
on s'en tape, ce ne sont pas des pièces légales

9- Date et N° des factures
Très important et doivent répondre aux obligations légales.
Notamment : les dates et les N° doivent se suivre

(*) Il faut ici envisager le traitement réel des factures.
La validation comptable est une chose, mais la réalité du traitement des pièces doit également être pris en considération.
Si l'on ne considère que la validation des factures, on peut envisager que les factures soient validées fin de mois alors qu'elles sont éditées au jour le jour.
Ce qui est évidemment impossible.
Si une facture émise le 5/6/07 n'est "validée" que le 30/06/07, on peut envisager de la modifier entre le 5 et le 30.
Mais cette facture ne peut être modifiée si elle a été comptabilisée par le client !
Il faut donc considérer que l'édition d'une facture (l'impression & l'expédition) consiste en une validation comptable !

Sinon, il pourrait y avoir discordance entre la comptabilité du fournisseur et celle du client. Le rêve pour l'inspection des impôts

En ce qui concerne la conservation des dates et N°, un simple fichier .ini par ex. suffit
Le seul "problème" éventuel est la suppression de plusieurs factures.
À mon sens, cela peut être résolu si la suppression des factures ne peut se faire :
1- qu'avant impression
2- que via un facturier (une table)
Il suffit de ré-attribuer les N° après la suppression
Il faut également prévoir un "Flag" impression, non gérable pas le client pour empêcher la suppression des factures éditées comme mentionné ci-dessus

Une dernière chose :
Tu ne parles ni de Bons de Retour, ni de Notes de Crédit ?

Cela dit, il y a encore beaucoup de choses à dire, mais :
- il faudrait en savoir beaucoup plus sur les réalités de l'entreprise concernée et sur la portée du travail demandé
- cela sort complètement du cadre de ce forum comme je l'ai dit en préambule

[gbrion]

Merci de tes conseils précieux. Plus encore sachant bien que mes questions portent plus sur le domaine de la conception que l'utilisation pure de Windev. Mais comme je travaille avec Windev et que je suis un totalement largué avec la refonte importante, obligatoire et en plus urgente de l'application sur laquelle je bosse, je poste ici. Et j'en profite encore pour te remercier personnellement Guardian car tu es toujours là !!!

J'aimerais pouvoir rebondir sur les remarques que tu m'as faites. Mais je comprendrais volontiers qu'en tant que modo tu ne puisses pas (faute de temps ou d'envie) ou que tu ne veuilles pas (mes demandes outrepassant le forum) continuer à me répondre sur ce topic. J'attends donc ton aval pour continuer.

Merci sincérement dans tous les cas.

PS : connais-tu un forum où je pourrais obtenir de l'aide pour mes problèmes de conception ? Car j'en ai d'autres : il faut que je refasse toute l'analyse pour la gestion du stock ET EN PLUS que j'implémente une gestion multi-stock. Avec mes soucis de facturation dont je parle ici, et sachant que je suis encore newbie dans la programmation et Windev, tu vois un peu la galère !!!

[Jannus]

Le meilleur conseil que je puisse te donner dans l'immédiat, c'est de regarder l'exemple Gestion Commerciale de Windev

[Christophe.LOGEL]

Bonjour,

Voici un petit code que j'ai réalisé qui vous sera à coup sur utile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
PROCEDURE Gbl_Calcul_Numero_Facture(_Date_Creation, _Format_Numero = "AAAAMMXXXXX", _Complement_Trou_Facture = Faux)
//***************************//
// Format_Numero est le format du numéro AAAA pour l'année, MM pour le mois, JJ pour le jour et XXXX pour le numéro
//***************************//
DateTemp est une Date
MaVue est une Source de Données
DateDebutMoisCreation est une Date
DateFinMoisCreation est une Date
NumeroFactureGenere est une chaîne = _Format_Numero
 
DateDebutMoisCreation = Gauche(_Date_Creation,6) + "01"
DateFinMoisCreation = DateDebutMoisCreation
DateFinMoisCreation..Jour = 1
DateFinMoisCreation..Mois += 1
DateFinMoisCreation..Jour -= 1
 
chAnnee est une chaîne = DateDebutMoisCreation..Année
chMois est une chaîne = NumériqueVersChaîne( DateDebutMoisCreation..Mois, "02d" )
chJour est une chaîne = NumériqueVersChaîne( DateDebutMoisCreation..Jour, "02d" )
eNumero est un entier = 0
eTailleNumero est un entier = ChaîneOccurrence(_Format_Numero,"X")
eTailleFormat est un entier = Taille(_Format_Numero)
chNumFactureAlpha est une chaîne = ""
Table_Numero_Trouve est un tableau dynamique de 0 entiers
i est un entier
bTrouve est un booléen
 
NumeroFactureGenere = Remplace( _Format_Numero, "AAAA", chAnnee)
NumeroFactureGenere = Remplace( NumeroFactureGenere, "MM", chMois)
NumeroFactureGenere = Remplace( NumeroFactureGenere, "JJ", chJour)
NumeroFactureGenere = Remplace( NumeroFactureGenere, Répète("X",eTailleNumero), "")
 
SI HCréeVue(MaVue,FACTURE,"*","","DATE_CREATION>='" + DateDebutMoisCreation + "' ET DATE_CREATION<='" + DateFinMoisCreation + "'") ALORS
	HLitPremier(MaVue)
	TANTQUE PAS HEnDehors(MaVue)
		eNumero = Max(eNumero, Val( Droite( Complète(MaVue.NUMALPHA, eTailleFormat," "), eTailleNumero ) )  )
		TableauAjoute(Table_Numero_Trouve, eNumero)
 
		HLitSuivant(MaVue)
	FIN
 
 
	HDétruitVue(MaVue)
FIN
 
SI PAS _Complement_Trou_Facture ALORS
	eNumero++
SINON
	bTrouve = Faux
	POUR i=1 A eNumero
		SI TableauCherche(Table_Numero_Trouve,tcLinéaire,i)=-1 ALORS
			bTrouve = Vrai
			eNumero = i
			SORTIR
		FIN
	FIN
 
	SI PAS bTrouve ALORS
		eNumero++
	FIN
FIN
 
chNumFactureAlpha = NumeroFactureGenere + NumériqueVersChaîne(eNumero,"0"+ eTailleNumero +"d")
 
RENVOYER chNumFactureAlpha

Bon dév,

[gbrion]

Bonjour,

Voici un petit code que j'ai réalisé qui vous sera à coup sur utile :

Merci bcp Christophe pour votre code. Mais peux-tu m'en dire plus sur ce code ? Il semblerait qu'il permette de pallier à de possibles "trous" dans la numérotation de facture. C'est çà ?

[Christophe.LOGEL]

Bonjour,

Oui il permet de pallier aux trous de facturation et en plus permet de paramétrer le format du numéro de facture généré.

Bon dév.,

[Jannus]

Je ne voudrais pas casser l'ambiance, mais cette procédure, si je l'ai bien comprise, ne me semble pas légale.
On ne peut "combler" les "trous" dans une suite de numéro.

Pour qu'un facturier soit accepté par l'administration fiscale, il ne peut permettre de manipulation des numéros. Les numéros doivent se suivre et l'incrémentation doit être automatique. Chaque facture éditée porte le numéro de la facture précédente +1.

Comme je l'ai dit précédemment, une facture éditée ne peut être supprimée.
Si une facture est incorrecte, elle doit faire l'objet d'une note de crédit.
Note de crédit interne si la facture n'a pas été expédiée chez le client.

[gbrion]

Je ne voudrais pas casser l'ambiance, mais cette procédure, si je l'ai bien comprise, ne me semble pas légale.
On ne peut "combler" les "trous" dans une suite de numéro.

Pour qu'un facturier soit accepté par l'administration fiscale, il ne peut permettre de manipulation des numéros. Les numéros doivent se suivre et l'incrémentation doit être automatique. Chaque facture éditée porte le numéro de la facture précédente +1.

Cher Guardian, tu ne casses pas l'ambiance car (en plus de ne pas être un garçon facile ),
1- moi la procédure, je l'ai comprise à 0,01%
2- effectivement la loi n'autorise pas ce genre de trous et de manip. dans la chronologie des numéros de pièces.

Comme je l'ai dit précédemment, une facture éditée ne peut être supprimée.
Si une facture est incorrecte, elle doit faire l'objet d'une note de crédit.
Note de crédit interne si la facture n'a pas été expédiée chez le client.

Par note de crédit tu entends surement un avoir sur la facture incorrecte. Histoire de refaire une nouvelle facture (en remplacement de la précédente non supprimée et non supprimable). Ca c'est dans le cas où la facture a été soit validée en compta ou transmise au client. (Tu as vu, j'ai bien lu tes posts !!!).
Dans le cas où elle n'a été ni expédiée chez le client ni saisie en compta, tu parles de note de crédit. Qézako ? Et dans ce cas là, je lis et vois tout et son contraire. Ex : j'ai sous les yeux un interview de la chef de projet de chez EBP (pas des inconnus en matière de logiciels de gestion quand même). Et elle parle ouvertement de la possibilité de suppression de facture (avant saisie comptable bien sûr). Et effectivement, le logiciel le permet (je l'ai testé moi même). Par contre, pas possible de modif ou suppression de la facture si c'est pas la dernière ni si celle-ci a été transférée en compta. Et du coup, le BL a l'origine de la facture n'est plus exploitable !!!

[Jannus]

Par note de crédit tu entends surement un avoir sur la facture incorrecte. Histoire de refaire une nouvelle facture (en remplacement de la précédente non supprimée et non supprimable). Ca c'est dans le cas où la facture a été soit validée en compta ou transmise au client. (Tu as vu, j'ai bien lu tes posts !!!).

On va dire ± oui
Sauf qu'il n'y a pas de relation formelle entre facture et note de crédit

Dans le cas où elle n'a été ni expédiée chez le client ni saisie en compta, tu parles de note de crédit.

Absolument pas !!! C'est tout le contraire.
Et comme dit ci-dessus, il n'y a pas de ralation directe entre facture et note de crédit

Une note de crédit est une pièce comptable comme une facture.
C'est en fait le pendant négatif de la facture.

Tu vends 3 PC, tu factures 3 PC.
Le client te rentre un PC, tu établis une note de crédit pour le PC retourné.
Alors que si les documents ont été établis après le retour, tu factureras 2 PC.

La note de crédit peut parfois être de facto une annulation de facture, mais sauf cas précis, il n'y a pas de relation entre ces pièces.
Pas plus qu'entre un chèque et un virement

j'ai sous les yeux un interview de la chef de projet de chez EBP (pas des inconnus en matière de logiciels de gestion quand même). Et elle parle ouvertement de la possibilité de suppression de facture (avant saisie comptable bien sûr). Et effectivement, le logiciel le permet (je l'ai testé moi même). Par contre, pas possible de modif ou suppression de la facture si c'est pas la dernière ni si celle-ci a été transférée en compta.

C'est tout à fait correct et correspond à ce que j'ai dit