Messages aux développeurs de GFC

Alors là.
Jusqu'à 2012:
Réception des écritures mandat d'opérations régies d'avances: Débit classe 6XXX et Crédit 4723X.
D'où une discordance, sommation comptes classe 6 (en débit!) et compte 4012 en crédit...différence des opérations mandats régies avances...
Aussi, pour parfaite égalité et avant de valider la journée, rectifier l'écriture D/6XXXX ET C/4012, puis D/4012 et C/ 4723X...

Et là c'est nickel, compris!

Ah, un oubli, cumul des dépenses(classe 6) et comptes 4012, 4662, et tout ce qui concerne les payes...421....

J'ai compris.
Comme je n'utilise pas le module régie d'avances, je ne rencontre pas le problème. Je passe bien par le 4012 en compte de liaison et 4723 en compte de paiement, et l'égalité cumul 6/cumul 4 est bien présente. Mais merci pour l'explication.
Ca ne donne pas très envie de se mettre à GFC régie pour les trois francs euros six sous centimes concernés.

Winnie a écrit:

J'ai compris.

Moi j'ai bien rigolé : à c't'heure, je ne peux guère faire mieux. Je garde cette Olrikquerie pour la faire lire à des copains profanes quand ils me poseront des questions sur le boulot.

Pour les développeurs:

Serait il possible de mettre le code d'imputation (6011, 6067, 6068....) dès l'engagement afin de gagner du temps lors du passage du mandat: là on ne peut mettre que le service , le domaine,le code activité et le montant...C'est dommage de s'arrêter là...

A vot' bon coeur

FARPI a écrit:

Pour les développeurs: Serait il possible de mettre le code d'imputation (6011, 6067, 6068....) dès l'engagement afin de gagner du temps lors du passage du mandat: là on ne peut mettre que le service , le domaine,le code activité et le montant...C'est dommage de s'arrêter là...

Tout à fait d'accord avec toi Farpi.

Dans l'utilitaire de vérification périodique (égalités croisées inter classes), crédit 701+703 = débit 4122, or dans M9-6 crédit 701-703-7066-7068-708. = débit 4122, donc anomalie mais non bloquante. A revoir?

Tu as mouvementé l'ensemble des comptes de classe 7 concernés par le4122 ?

J'ai mouvementé seulement le 7083 (locations diverses) et en aucun cas le 701 ou 703.

FARPI a écrit:

Pour les développeurs:

Serait il possible de mettre le code d'imputation (6011, 6067, 6068....) dès l'engagement afin de gagner du temps lors du passage du mandat: là on ne peut mettre que le service , le domaine,le code activité et le montant...C'est dommage de s'arrêter là...

A vot' bon coeur

Oui, enfin bon, c'est le principe même de la réforme RCBC: seuls les domaines et activités sont obligatoires en dépenses, le compte n'est renseigné qu'au moment de la liquidation. Alors, les développeurs, ils ont fait ce qui est demandé pour le coup..

pour les développeurs

Lors d'un liquidation, on peut éclater une facture sur 2 domaines ou 2 activités mais pas sur 2 comptes (6064 et 6068 par exemple). Je ne suis pas sûr que l'achat d'une imprimante pour l'édition des bons de commande alimentaires soit du même ordre que l'achat des consommables associés.

En attendant la MAJ 1 de GFC 2013, je voulais savoir si certains d'entre vous ont réussi à réceptionner correctement le fichier de daos régisseur (menues dépenses) en compta bud ou si comme de nombreux collègues vous avez eu un message d'erreur qui a empêché la réception du fichier et le traitement de ces dépenses en mandatement.

Heureusement une reprise de transfert est possible via le module historique transferts dans la régie et ceci après installation de la mise à jour.

Mais peut-être que certains n'ont pas eu ce problème...?

Merci d'avance pour vos retours d'expériences.

Non le problème est global et la MAJ est prévue en semaine 9. D'ici là, on peux passer les dépenses en régie mais ne surtout pas les réceptionner en compta ordo. Il faut de toute manière respecter le rythme des 30 jours pour la régularisation de la caisse.

Racadoince a écrit:

Non le problème est global et la MAJ est prévue en semaine 9. D'ici là, on peux passer les dépenses en régie mais ne surtout pas les réceptionner en compta ordo.

Bon ça me rassure et vivement la mise à jour en S9.

Racadoince a écrit:

Il faut de toute manière respecter le rythme des 30 jours pour la régularisation de la caisse.

Bien sûr, qui ne le fait pas ?

Kaich a écrit:

pour les développeurs

Lors d'un liquidation, on peut éclater scinder une facture sur 2 domaines ou 2 activités mais pas sur 2 comptes (6064 et 6068 par exemple). Je ne suis pas sûr que l'achat d'une imprimante pour l'édition des bons de commande alimentaires soit du même ordre que l'achat des consommables associés.

je dirai même plus ; ne pas l'avoir rectifié dans la dernière mise à jour rend cette opportunité totalement inutile. Nous en restons donc au même point, une liquidation avec engagement pour un compte et une liquidation sans engagement pour l'autre partie de la facture...

Je rappelle que cette fonctionnalité n'existait pas dans l'ancienne mouture..
Ce n'est donc pas une régression (comme j'ai pu le lire parfois) mais une non-évolution.
C'était prévu mais les contraintes techniques ont empêché le truc.
Il était même prévu de pouvoir faire des approvisionnements avec multi imputations (sur la première version comptabud RCBC de juin 2012).
Techniquement il y avait un blocage et les développeurs ont préféré différer cette évolution pour ce concentrer sur de vrais problèmes (style DBM).
Mais normalement c'est prévu pour 2014 (au plus tôt)
Le travail sur 2014 est déjà lancé..

Si je peux parfaitement comprendre l'existence de soucis techniques et de priorités plus importantes que ce point-là (je songe aux problèmes rencontrés par les AG dans les tables de correspondance...), ce qui m'étonne c'est d'avoir créé et maintenu entre-ouverte la porte d'une évolution qui facilitait le travail tandis que la nouvelle mouture complexifiait les liquidations et de ne pas achever le travail. C'est comme si tu mettais sur le marché une voiture sans son moteur. Diffuser une version de GFC avec l'apparence d'une scission possible et simplement des liquidations, désolé, mais je n'en vois pas l'intérêt.
Vaut-il mieux "décevoir" ou donner l'impression que le produit n'est pas achevé ?

J'ai trouvé un truc bien pénible pour moi et très facile à corriger à la prochaine occasion : le bordereau des règlements effectués, qui liste les ordres de virement et accompagne le bordereau de transmission d'un fichier de SCT, ne comporte aucune date nulle part.

On ne peut donc identifier ces trucs que par le montant total, c'est vraiment léger en termes de sécurité et de facilité du contrôle !

Les règlements sont numérotés dans GFC. Pourquoi ce numéro n'est pas repris sur le bordereau, tout simplement ?

Winnie a écrit:

Les règlements sont numérotés dans GFC. Pourquoi ce numéro n'est pas repris sur le bordereau, tout simplement ?

Oui, la date et le numéro de règlement, ça serait parfait.

Reprendre tout simplement la référence de la remise (qui contient le n° de Reglt en derniers chiffres) et la date d'édition qui figurent sur le Bordereau de transmission sur les pages du Bordereau de règlement, ce serait super.

De l'ordre du détail, qui pourtant simplifie la vie, mais utile car plus protecteur : en saisie de liquidation, certes l'IBAN apparait, pour simplifier la manipulation, ne pourrait-on prévoir que le BIC soit aussi lisible, ce qui éviterait de devoir naviguer dans les détails du fournisseur pour le vérifier, d'autant que le BIC erroné est bloquant dans les paiements par le Trésor ?