Discussion :

[macanede]

pertes des données

Bonjour

mon problème , pertes des données même avec l'utilisation de HForceEcriture
mon application fonctionne en réseau un client qui as 4 postes réclame les
pertes des données mais par contre d'autre client qui ont un seul poste n ont pas
ce problème .
j utilise HFSqlSever et le client a même un serveur HP

d ou vient le problème, et comment le résoudre .

Merci en avance
maca nede

[tatayo]

Bonjour,
Sans vor le code, difficile de savoir ce qui ne va pas.
Mais quoi qu'il en soit, l'aide de Windev indique que hForceEcriture n'est disponible que pour les connections HHSQL et HFSQL Client/serveur.
Donc pas pour un accès à SQLServer.

Pourquoi passer pas cette fonction ? Pourquoi ne pas utiliser les fonctions "classiques" qui fonctionnent avec cette accès ?

Tatayo.

[Voroltinquo]

Bonjour,
En réseau mono-utilisateur, il est logique que ton 2° client n'ait pas de problème. HForceEcriture est dans la plupart des cas destiné à contourner un bloquage.
S'il est seul, aucun autre utilisateur ne bloque l'enregistrement.
Par ailleurs, dans quel contexte utilises-tu ton "forçage" ? Y a-t-il des transactions en cours ? etc ...

[tbc92]

Comme mes amis.
Un jour, tu avais un problème. Tu as utilisé hForceEcriture pour résoudre ce problème, mais j'ai beaucoup de doutes sur l'utilité de cette fonction. En ajoutant cette commande (hForceEcriture), tu as ajouté un problème.
Utilises-tu les transactions ? C'est un truc très standard dans les bases de données en général (HFSQL et autres bases de données).

[Voroltinquo]

En règle générale, les hIgnoreXXX, hForceXXX etc... sont à fuir comme la peste.
S'il y a un blocage, c'est qu'il y a une raison. On as toujours la possibilité de mettre l'enregistrement "en attente" (via une file par exemple) et de traîter les enregistrements à la fin du blocage.

[macanede]

merci beaucoup pour vos réponses,

j ai deja ce problemes de pertes des données
et dans des forumes j ai lu que HForceEcriture()
faite pour ce genre des problemes


j ai un exemple ici concernant le paiment des factures
Je rempli la table avec les factures non payé d'un client.
je mentionne le montant que le client veux payé
et dans la table, (colonne montant à réglé), on reglé les factures

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
 
TotalligneTable = TableOccurrence(TABLE_facture)
 
POUR i = 1 À TotalligneTable
 
	NrFacture = TABLE_facture.COL_NumFacture[i]	
	montant_deja_réglé = TABLE_facture.COL_DejaReglé[i] 
	montant_Avance = TABLE_facture.COL_Montant_Avance[i]
	montant_Reste = TABLE_facture.COL_Montant_Reste[i]
 
 
 
	SI montant_Avance > 0 ALORS // avance est différent de 0
 
	// ajouter réglement
	Reglements.NumDoc = NrFacture
	Reglements.NomClient = sai_client
	Reglements.Date = sai_date
	Reglements.MontantAvance = montant_Avance
        HAjoute(Reglements)
 
	// modifie la facture
	HLitRecherchePremier(factures, NumFacture, NrFacture)
	  SI HTrouve(factures) ALORS
	  factures.BLregle = Faux
	  actures.ToalReste = montant_Reste - montant_Avance
	  factures.TotalRegle = montant_deja_réglé + montant_Avance
	  HModifie(factures)
	FIN
 
	FIN	
 
FIN
 
//

dans mon logiciel je trouve que la facture est réglé ou il y a un avance ( factures.TotalRegle , actures.ToalReste ) mais dans
les détaille des règlements je ne trouve pas ces données
mais ça arrive dans quelque factures

NB : windev 24 avec HyperFilseSql serveur/client

merci

maca nede

[tatayo]

Tu devrais tester le retour des fonctions hModifie() et hAjoute(), tu auras peut-être un début de piste.
Ensuite tu devrais utiliser des transactions, car si la modification de la facture échoue, tu te retrouve avec un décalage entre les règlements et la facture.
Enfin tu as un problème d'accès concurrent: si 2 utilisateurs ont la même facture à l'écran, que va t'il se passer ?
Le premier va enregistrer ses valeurs, et le deuxième va passer ensuite et écraser la facture avec ses propres valeurs.

Je te propose une piste: à la lecture des données, tu notes la version de la facture avec hVersion().
Ensuite lors de l'enregistrement, tu commences par bloquer la ligne.
Si le blocage échoue, inutile d'aller plus loin.
Ensuite tu récupères de la base la version courant, et tu compares.
Si le numéro de version correspond, tout va bien, tu peux lancer la mise à jour. Il ne faut pas oublier de valider la transaction, et de débloquer l'enregistrement.
Dans le cas contraire, c'est que quelqu'un d'autre modifie ou a modifié l'enregistrement.
Donc tes données sont obsolètes, et tu ne peux plus les mettre à jour.

Tatayo.

[tbc92]

Comme Tatayo :

Code :

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

1
2
// Ceci devrait être interdit :
hmodifie(factures)

Code :

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

1
2
3
4
5
6
7
8
// Ceci devrait être obligatoire.
bo est un booleen
bo = hmodifie(factures)
si pas bo alors 
   erreur ( " Erreur Modification facture ", herreurInfo() )
   htransaction ( hAnnule)  // Syntaxe à vérifier.
   renvoyer faux
fin

Quand tout va bien, qu'on teste la bonne exécution de chaque instruction ou pas, on ne voit pas la différence.
Mais dès qu'on a un problème, c'est nécessaire de tester chaque instruction d'écriture (hModifie, hAjoute, hSupprime ) et même en toute rigueur les fonctions de lecture ...

Et si une écriture plante, on annule TOUTE la transaction ( l'écriture dans Facture, l'écriture dans Commande, etc etc ) et onavertit l'utilisateur.

[Voroltinquo]

Code :

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

1
2
// Ceci devrait être interdit :
hmodifie(factures)

Au niveau programmation j'approuve.
Au niveau comptable j'aouterai : Ceci devrait être interdit tout court.
Il est interdit de modifier une facture.
Dans le cas présent, il faut émettre une nouvelle facture qui fait référence à la précédente et indique le nouveau montant à régler.

Par ailleurs afin d'affiner le traitement des blocages, les n° d'erreur sont les suivants :

70100: BLOCAGE (FICHIER OU ENREGISTREMENT)
Le programme tente d'accéder à un fichier de données ou un enregistrement bloqué par un autre poste ou un autre programme.

74011: BASE DE DONNEES BLOQUEE
La base de données est bloquée.

75102 : Echec de la reconnexion
La reconnexion échoue car un fichier est bloqué.

75103 : Echec de la reconnexion
La reconnexion échoue car un fichier est bloqué en lecture et écriture.

[serendib]

Une facture, c'est une facture, un règlement c'est un règlement.
Il n'est donc pas nécessaire de modifier une facture pour
savoir si elle est réglée, partiellement, ou pas.
Il suffit de rechercher si elle a fait l'objet d'un règlement (fichier spécifique)
qui lui, contient l'identifiant de la facture.
En général on a un fichier détail des règlements et un fichier règlements.
En effet un règlement peut concerner plusieurs factures, et chaque facture peut être réglée
en plusieurs fois.
Modifier une facture dans ce cas, n'a aucune utilité.
C'est en tout cas ainsi que je procède depuis des lustres.

[macanede]

Bonjour et merci pour vos réaction et vos propositions

ici je change pas les données de la factures comme articles, date etc mais seulement montant payé pour cette facture, un champ inclue dans mes factures,
j ai une table fichier (factures) et dans cette table on vois nr facture, nom client, et aussi la somme de montant déjà réglé , pour avoir une vue simple de la somme réglé.




pour ta solution je doit utiliser un table mémoire que je rempli avec les factures et en même temps avec la sommes des règlements, que je vois qui il va prendre du temps .

deuxièmement le problème reste dans les règlements que je ne trouve pas pour certains factures. dans la table factures je vois la somme des avances mais pas
dans les détailles des règlement (fichier règlements), donc si je fait ta solutions je ne serai pas capable de savoir qu il y'a vraiment des avances pour ces factures.

je vais adapter les solutions proposé par les amis ,


merci et merci

maca nede

[macanede]

bonjour

ma dernière question

est ce que durant la boucle et l'ajout des règlements pour ces factures (disant factures nr f10, f45, f100)
un autre postes en mémé temps fait les règlements pour d'autre factures différentes de celle ci (ex f14, f20)
peut provoquer ce problème

même que je ne pense pas ça, car il y a la créations des centaines de BL par jour est en même temps et j ai pas ce problème dans les articles et ils sont des milliers.

maintenant pour l'ajout des règlement je le fait avec requette (HExécuteRequête)


merci


maca nede

[tatayo]

est ce que durant la boucle et l'ajout des règlements pour ces factures (disant factures nr f10, f45, f100)
un autre postes en mémé temps fait les règlements pour d'autre factures différentes de celle ci (ex f14, f20)
peut provoquer ce problème
maca nede

Oui, car dans le code que tu nous as montré tu ne testes pas si une ligne a été modifiée, tu enregistres toute la table.
Donc tout dépends de l'ordre dans lequel les données sont lues, modifiées et enregistrées.

Quoi qu'il en soit, tu tu ajoutes un règlement tu modifies de fait une facture, ce qui est interdit.
Tu dois à chaque fois créer une nouvelle facture.

Tatayo.

[frankgth]

Quoi qu'il en soit, tu ajoutes un règlement tu modifies de fait une facture, ce qui est interdit.
Tu dois à chaque fois créer une nouvelle facture.
Tatayo.

Tu es sûr de toi là ? Je ne vois pas en quoi l'enregistrement d'un règlement modifie une facture ?

Dans tout ce que j'ai lu, un règlement doit être encaissé à partir d'une facture. Si la facture n'a pas encore été établie à l'encaissement d'un règlement c'est un acompte et on doit faire une facture d'acompte qui sera déduite de la facture définitive. Du coup ça me parait incompatible avec ce que tu dis, donc si tu as d'autres infos je serais preneur.

Cordialement,

PS : Désolé de polluer un peu ce thread, pour ce qui est du problème d'origine, as-tu essayé avec de faire les ajouts/modifs en SQL plutôt qu'avec les hajoute et hmodifie ?

[Voroltinquo]

. Si la facture n'a pas encore été établie à l'encaissement d'un règlement c'est un acompte et on doit faire une facture d'acompte qui sera déduite de la facture définitive.

La facture n'a pas encore été établie donc l'acompte est une ligne qui apparaîtra lors de l'établissement de la facture. En aucune cas la facture n'est modifiée, pour la bonne est simple raison qu'elle n'a pas encore été établie.

[macanede]

Bonjour

question de créer une nouvelle facture a chaque avance de paiement me semble bizarre

disant une facture avec un montant de 10 000.00 euro

le client paie comme avance 1000 euro par chèque , après 15 jours il a payé 3000 euro après 2 mois 4000 euro après 3 mois 2000 euro
donc on doit créer chaque fois une nouvelle facture ?

on doit distingué entre lés règlements et la modification de la facture, lorsque on parle de la modification de la facture c est de changer le montant de la facture, la date ou nom client etc.

que-ce qu on fait pour la comptabilisé.
on ajoute les avances a notre initiale facture et pour la déclaration du TVA on déclare les montants selon la date de règlement, mais les données de la facture reste le même.

dans des cas on créé facture acompte, ici on crée une nouvelle facture, on change la date, le nr et on mentionne le numéro de la facture initiale le pourcentage % déjà payé, reste a payé

merci.

maca nede

[Voroltinquo]

Une facture est créée une fois pour toute. Elle correspond aux prestations, ventes, acomptes ou arrhes éventuels, avoirs et réduction.
Elle ne doit être ni modifiée, ni supprimée. La numérotation doit être continue.
Elle fait l'objet de 0 ou n réglements qui font chacun l'objet d'un reçu indiquant le reste dû.

[frankgth]

Une facture est créée une fois pour toute. Elle correspond aux prestations, ventes, acomptes ou arrhes éventuels, avoirs et réduction.
Elle ne doit être ni modifiée, ni supprimée. La numérotation doit être continue.
Elle fait l'objet de 0 ou n réglements qui font chacun l'objet d'un reçu indiquant le reste dû.

Ça ne me dit pas pourquoi tu dis que lorsque l'on fait un règlement on modifie la facture et on doit la refaire.
Pour moi le règlement est indépendant de la facture et doit être saisi après sans avoir à refaire la facture. Si un règlement est saisi avant c'est un acompte et il doit faire l'objet d'une facture d'acompte.
J'ai développé un logiciel de caisse qui a été certifié il y a quelques années et qui fonctionne comme ça donc j'aurais juste aimé savoir si c'était un changement de réglementation même si ça me parait bizarre.

[frankgth]

Bonjour

question de créer une nouvelle facture a chaque avance de paiement me semble bizarre

disant une facture avec un montant de 10 000.00 euro

le client paie comme avance 1000 euro par chèque , après 15 jours il a payé 3000 euro après 2 mois 4000 euro après 3 mois 2000 euro
donc on doit créer chaque fois une nouvelle facture ?

on doit distingué entre lés règlements et la modification de la facture, lorsque on parle de la modification de la facture c est de changer le montant de la facture, la date ou nom client etc.

que-ce qu on fait pour la comptabilisé.
on ajoute les avances a notre initiale facture et pour la déclaration du TVA on déclare les montants selon la date de règlement, mais les données de la facture reste le même.

dans des cas on créé facture acompte, ici on crée une nouvelle facture, on change la date, le nr et on mentionne le numéro de la facture initiale le pourcentage % déjà payé, reste a payé

merci.

maca nede

Pour résumer, si tu prends un acompte tu encaisses de la TVA que tu dois donc déclarer. Et pour pouvoir la déclarer tu dois faire une facture d'acompte. Donc dans ton cas effectivement tu devrais faire une facture d'acompte à chaque avance. Ensuite les factures d'acompte seront déduites du restant dû de la facture définitive. Plus de détails ici par exemple.
Après dans la pratique je pense que pas mal d'entreprises ne respectent pas la règle, mais c'est une autre histoire
Pour la comptabilisation je crois qu'il existe 2 méthodes mais je ne me souviens plus des détails, il faudrait voir avec un comptable.

[tbc92]

Il peut y avoir des règles spécifiques à tel ou tel pays. En particulier, en France, les règles on changé il y a 1 ou 2 ans, rajoutant pas mal de contraintes. Je pense donc qu'on doit répondre aux questions 'programmation' de macanede, mais ne pas trop diverger sur des questions de législation comptable.