Bonsoir à tous,

Pour ceux qui ont déjà basculé leur GFC sur MySql, avez vous eu des problèmes si vous aviez la Régie en monoposte et la compta Budg en réseau ?

Ici, on nous dit que ce n'est plus possible avec MySql d'avoir des installations différentes. Tout doit être en réseau !...

Merci d'avance pour vos réponses

En même temps, rien ne t'empêche d'installer en réseau sur un seul poste. Donc je ne vois pas trop où est le problème si ce n'est qu'il faille juste penser à faire l'install en réseau à chaque fois même si on n'a qu'un poste.

Actuellement nous avons le module Régie (en monoposte) dissocié du module Compta Bud (en réseau).

En cas de plantage de la Régie, c'était juste pour éviter en cas de restauration de la Régie de devoir remettre en concordance la compta bud avec la compta géné en cas de restauration avant le transfert d'écritures auto.

Qui est dans ce cas de figure et aurait fait la migration à MySQul ?

J'avoue que je ne comprends pas trop ce que tu veux dire.

Que tu sois en monoposte ou en réseau, le transfert d'écriture ne se fait que quand tu l'as décidé (par mail ou clé USB si tu n'es pas en réseau, pas un fichier sur le réseau dans le cas d'une install réseau).

Donc, si tu as fait un transfert d'écriture et que tu restaure avant, dans un cas comme dans l'autre, il faudra remettre en concordance les deux comptas.

Sauf que si les deux modules sont distincts tu ne restaures que la Régie et la compta Bud n'est pas impactée par cette restauration, donc pas de travail à rattraper sur ce module pour le mettre en concordance avec la compta géné

de l'importance des SVG
si on fait des svg régulièrement il n'y a pas de problème.
Si on fait une svg toutes les années bisextiles , il y a du boulot si tu réinstalles ta svg d'il y a deux ans...

Sans restaurer une sauvegarde d'il y a deux ans...
Il peut arriver qu'après un fin de journée suivie d'une fin de période, on mandate et fait des OR. Dans cet ordre.
Si le pb informatique s'est passé au moment de la validation de journée ou de la fin de période, il faudra bien restaurer à ce moment là.
(ex : Si on ne s'aperçoit du pb qu'après avoir réceptionné le Mandatement et les OR en compta géné, que le règlement soit fait)
Si les deux modules sont dans la même base, on restaure tout.
D'où l'avantage qu'il y avait à avoir les modules dans des bases différents, donc avec des installations différentes, une en monoposte et une en réseau.

La question initiale de ce post était :
- Est ce que des collègues ont déjà effectué une migration MySql avec des bases GFC une en réseau et une en monoposte sur le même ordinateur ?
Est ce que cela a fonctionné ?

Merci d'avance de la réponse

J'ai un réseau chez moi et la régie est également sur le dit réseau.
Donc j'ai migré mais pas dans la condition que tu décris
En tout cas ça marche hormis un bug sur la classe 5 des ER lors de la FE déjà signalé
Par contre je reviens sur les svg.
Je mandate svg
je fais des OR svg
je fais une régie SVG
...
on peut restaurer ensuite où on veut.
Par contre la restauration doit quand même répondre à un critère technique
On ne restaure pas pour corriger une erreur comptable (du style mauvaise écriture)
cela s'assimile vite à de la tricherie et pourrait donner des idées à des tordu(e)s
il vaut mieux passer les écritures en moins
sujet maintes fois abordé sur le forum.
les restaurations sont donc l'exception et l'écriture négative la règle...

Bozinchu a écrit:

...
Par contre je reviens sur les svg.
Je mandate svg
je fais des OR svg
je fais une régie SVG
...
on peut restaurer ensuite où on veut...

Je dois personnellement sauvegarder plus que de raison, mais qui peut le plus peut le moins...
Seulement quand on restaure on efface tout ce qui s'est passé depuis la sauvegarde sur tous les modules contenus dans la base GFC, d'où l'utilité d'avoir une Régie sortie de la base contenant la compta bud, mais c'est mon point de vue.

Bozinchu a écrit:

...
les restaurations sont donc l'exception et l'écriture négative la règle...

Entièrement d'accord.
La restauration ne doit être effectuée que quand on n'a pas le choix (pb informatique lors d'une validation d'opérations ou pb électrique qui planteraient les fichiers)
Pour une erreur de compta, on peut toujours annuler par des écritures négatives, des O Reversement ou annulation de recettes, même si cela n'est pas joli dans la compta.

Bémol pour la Régie : on ne peut pas régulariser une erreur de saisie de recettes après validation de la journée (d'où l'importance de bien vérifier la situation de la Régie avant de valider).

Merci pour ta réponse Bozinchu et tes précisions

MOA a écrit:

Il peut arriver qu'après un fin de journée suivie d'une fin de période, on mandate et fait des OR.

Personnellement, j'évite !

Bozinchu a écrit:

On ne restaure pas pour corriger une erreur comptable (du style mauvaise écriture)
cela s'assimile vite à de la tricherie et pourrait donner des idées à des tordu(e)s
il vaut mieux passer les écritures en moins
sujet maintes fois abordé sur le forum.
les restaurations sont donc l'exception et l'écriture négative la règle...

D'accord pour les écritures en moins, ORR et reversements.
Sauf qu'on ne peut pas annuler un ordre de paiement... Alors tu fais comment : t'envoie pas le règlement, tu repasses l'écriture de l'OP en moins, et tu renumérotes tous les OP suivants, ou bien tu restaures ? Moi j'ai choisi.

Je fais un certificat administratif précisant que l'ordre de paiement est erroné et n'a pas été suivi d'effet réel; jamais de restauration pour rectifier une erreur comptable.

surtout pour un OP qui n'a pas de trace en compta bud et qui peut s'assimiler à un paiement perso pour avoir des sous....
C'est l'écriture la plus simple pour détourner des sous.

salut,

de retour ce matin au bureau après 2 semaines de congés paternité, j'avais complètement coupé les ponts.

pas suivi ce qu'il faut faire avec GFC---MYSQL ? Que doit on faire sur GFC 2009 (suis en réseau) et cela doit il etre fait avant le 31.12 ? (suis une quiche en info).

désolé si je prends le train en marche, vous avez l'air d'avoir déjà fait tout ce qu'il y a à faire et ça m'inquiète un peu.

merci les amis et bonnes fêtes à tous.

en réseau c'est le service informatique du rectorat qui doit s'en occuper (ici tout du moins)
Il faut installer la base MySql dans un premier temps
Ensuite on migre la base 2009 de interbase vers MySql....
Après on attend 2010 et le CD de GFC 2010

Bozinchu a écrit:

en réseau c'est le service informatique du rectorat qui doit s'en occuper (ici tout du moins)
Il faut installer la base MySql dans un premier temps
Ensuite on migre la base 2009 de interbase vers MySql....
Après on attend 2010 et le CD de GFC 2010

Et on fait les sauvegardes de GFC 2009 sous le module Admin

Piège à éviter : il faut veiller à ne plus utiliser la procédure de sauvegarde d'avant MySql ; car en apparence, ça marche
Mais en réalité, rien n'est sauvegardé

Bonjour Sylvain

A propos de l'info du jour citée par Boz ici :

https://gestionnaires.actifforum.com/info-du-jour-f3/bascule-mysql-et-fqe-er-t12551.htm?highlight=mysql

Elle est d'importance

Mais tous les établissements ne sont pas dans ce cas : ici, aucun problème pour saisir les encaissements des ER.

Bozinchu a écrit:

Il faut installer la base MySql dans un premier temps
Ensuite on migre la base 2009 de interbase vers MySql....

et ça c'est le rectorat qui s'en occupe ? On fait une demande d'intervention ?

silvain a écrit:

et ça c'est le rectorat qui s'en occupe ? On fait une demande d'intervention ?

Chez nous, le service informatique du rectorat l'a fait sans la moindre intervention de notre part
Mais nous avions reçu au préalable une info à ce sujet sur la messagerie électronique

Durée de la manip : environ 10mn

Merci Barbule,
bon, j'ai fait une demande au service info du rectorat, apparemement c'est comme ça que ça se fait dans mon académie,
mais je doute que ce soit fait pendant les vacances, j'espère que ça ne posera pas de problème.

silvain a écrit:

... je doute que ce soit fait pendant les vacances, j'espère que ça ne posera pas de problème.

A mon avis non .
Ce qui importe , c'est que la migration précède la bascule vers 2010

Effectivement j'ai eu quelques collègues qui ne l'ont pas fait non plus, à priori effectivement pas de souci mais impérativemnt le faire faire avant la bascule,

merci Barbule

Bonne fin d'année à toi

Au plaisir de te lire à nouveau sur le forum

barbule a écrit:

Bonne fin d'année à toi

Au plaisir de te lire à nouveau sur le forum

à toi aussi