Pré et post-requis fonctionnels de migration d'un dossier en mise à jour 9.0.0 

La migration des données et des paramétrages contenus dans le dossier migré nécessite deux interventions : une intervention avant (pré-requis) et une intervention après (post-requis) le traitement de migration automatiquement réalisé lors de la première validation du dossier migré vers la mise à jour 9.0.0.

Pré-requis au traitement de migration

Vous trouverez ci-dessous les pré-requis de migration d'un dossier. De façon générale, la première étape fortement conseillée est de vérifier la cohérence des données à migrer. Sur un dossier sur lequel beaucoup de mouvements sont effectués, et qui a parfois subi des étapes de maintenance, il est possible que certaines données ne soient pas parfaitement cohérentes, surtout s'il y a des développements spécifiques.

Cette opération permet de détecter d'éventuels problèmes liés à des données qui risquent de provoquer des erreurs lors de la procédure de migration, obligeant à la relancer.

Il est aussi conseillé de purger un certain nombre de tables temporaires dont la migration peut être longue (par exemple la table des requêtes).

Comptabilité

Variable GEXEAN

À partir de la version V7.3, la variable globale GEXEAN n'est plus initialisée lors de la connexion de l’utilisateur dans le dossier.

Elle est désormais initialisée au niveau de la session de l’utilisateur lorsqu'il utilise pour la première fois une fonction qui requière l’emploi de cette variable (RECBAL, SIMULFINEX, etc.).

La variable globale GEXEAN a donc été supprimée du dictionnaire des variables (GESAGB).

Les développements spécifiques qui utilisent la variable globale GEXEAN doivent prévoir la déclaration et l’initialisation de cette variable si elle n’a pas encore été déclarée. Pour cela, vous devez appeler le sous-programme EXEAN : If dim(GEXEAN)<0 : Call EXEAN From GLOBCPT : Endif

Post-requis au traitement de migration

Comptabilité

Gestion des fichiers bancaires XML au format pain001.001.003

Pour bénéficier de cette fonctionnalité, recopiez les paramétrages suivants depuis le dossier X3 vers le dossier d'exploitation :

  • Fonction de paramétrage des fichiers bancaires (GESTFB) :
    Nouveau fichier livré : VIRINT03, fichier de virements ISO20022 au format pain001.001.003
  • Fonction de paramétrage des transactions de saisie de règlements (GESTPY) :
    Nouvelle transaction FVIRV 'Fourn - Vir internat variable' utilisant le fichier bancaire VIRINT03
  • Fonction de paramétrage des compteurs (GESANM) :
    Nouveau compteur VARFB utilisé dans le fichier bancaire VIRINT03
  • Fonction d'affectation des compteurs (GESTCA) :
    Affectation du compteur VAFB en ligne 19 du module Tiers
Gestion optionnel du BIC à partir du 1er février 2016

Pour bénéficier de cette fonctionnalité, recopiez les paramétrages suivants depuis le dossier X3 vers le dossier d'exploitation :

  • Fonction de paramétrage des fichiers bancaires (GESTFB) :
    Fichiers modifiés : SCT03 et SDD02
  • Fonction de paramétrage des modèles d'import (GESAOE) :
    Modèle modifié : MDT
Gestion de l'affacturage avec recours/sans recours

Pour bénéficier de cette fonctionnalité, recopiez les paramétrages suivants depuis le dossier X3 vers le dossier d'exploitation :

  • Fonction de paramétrage des paramètres des variables (GESGVA) :
    Nouveaux paramètres : AMTNOTFCT, BPRFCT, DUDAMT, DUDLOC, LEDCUR, PAYCUR et VCRCUR
  • Fonction de paramétrage des variables de pièces automatiques (GESGVG) :
    Nouvelles variables : AMTFCTNREC et AMTNOTFCT
  • Fonction de paramétrage des pièces automatiques (GESGAU) :
    Nouvelles pièces automatiques : FCNOD, FCTN2, FCTOD, FCTQ2
    Pièces automatiques modifiées : FCTN et FCTQ
  • Fonction de paramétrage des groupes de pièces automatiques (GESGRA) :
    Nouveaux groupes : FCTN, FCTQ
  • Fonction de paramétrage des sections par défaut (GESCDE) :
    Nouveau code section par défaut : FCT (à adapter pour définir les règles d'initialisation du client)

De nouvelles lignes de codes comptables ont été livrées dans la fonction de paramétrage des lignes de codes comptables (GESCCL) (ligne 4 à ligne 11 pour les codes comptables de type « factor »). Vous devez alors prévoir d'adapter les codes comptables de type « factor » pour y mettre les nouveaux comptes à utiliser, selon le ou les plans de comptes du client.

Immobilisations

Bâtiments

Les bâtiments préalablement  gérés via la table diverse 604 sont dorénavant gérés via une classe X3.
L'utilisateur doit vérifier que les bâtiments ont été transformés par la migration et sont disponibles dans la représentation PHYBUI (Données de base > Tables immobilisations > Bâtiments).

Localisations

Les localisations préalablement  gérés via un objet classique sont dorénavant gérés via une classe X3.
À partir de la mise à jour 9, la localisation est obligatoirement associée à un site financier.
L'utilisateur doit vérifier que ses localisations ont été transformées par la migration et sont disponibles dans la représentation PHYLCT (Données de base > Tables Immobilisations > Localisations).

Eléments physiques

Les éléments physiques préalablement gérés via un objet classique sont dorénavant gérés via une classe X3.
L'utilisateur doit vérifier que les éléments physiques ont été transformés par la migration et sont disponibles dans la représentation PHYELT (Immobilisations > Gestion physique > Éléments physiques).

Plan de production

L'utilisateur doit vérifier que l’unité définie au niveau du paramètre DEFUOM - Unité par défaut (chapitre FAS, groupe FAS, niveau dossier) est présente au niveau de l’entête du plan production  (Immobilisations > Immobilisations > Plan de production).

Modèles d’import

Suite à la mise en oeuvre de la nouvelle gestion des éléments physiques et de l’inventaire en mise à jour 9, les modèles d’import associés sont supprimés par la migration.

Recodifications massives

Suite à la migration, des paramétrages de recodifications massives (optionnels) peuvent être supprimés à cause de clés erronées. L'utilisateur doit vérifier que ses paramètres de recodification, s'ils sont utilisés, sont disponibles (Immobilisations > Utilitaires > Recodifications massives).

Négoce

Type de devis

Le processus de migration doit assigner un type de devis dans le champ Type devis (SQHTYP) pour tous les devis existants.

À la création d’un dossier, les types de devis et les paramètres généraux suivants sont copiés depuis le dossier de référence :

  • SQHTYP – Type de devis (chapitre VEN, groupe QUO),
  • SOHTYPNOR - Type commande normale (chapitre VEN, groupe ORD),
  • SOHTYPINV- Type commande factur. directe (chapitre VEN, groupe ORD),
  • SOHTYPOPN - Type commande ouverte (chapitre VEN, groupe ORD).


Seuls les types qui ont une législation prise en charge dans le dossier de destination ou qui ont une législation vide sont copiés à partir du dossier de référence.

L’utilisateur peut paramétrer ces données à deux niveaux, selon le moment de la migration.

  • Si la migration est réalisée en même temps que la validation du dossier, le paramétrage doit être fait dans le dossier de référence, avec les codes des types attendus (la table des types de devis et les paramètres généraux). Sinon, le système utilisera les types par défaut livrés en standard.
  • Si la migration est réalisée après la validation du dossier, le paramétrage doit être fait dans le dossier de destination avec les codes des types attendus (la table des types de devis et les paramètres généraux). Sinon, le système utilisera les types par défaut copiés depuis le dossier de référence.

Lorsque la table des types de devis est alimentée et lorsque le paramètre général SQHTYP est paramétré, le système alimente les devis de la façon suivante :

1. Pour chaque devis, le système vérifie la valeur du paramètre général SQHTYP.
2. Si aucune valeur n’est définie pour ce paramètre, le système sélectionne le premier type de devis, dans l'ordre alphabétique, qui correspond à la législation du devis.
3. S'il ne trouve rien, le système sélectionne le premier type de devis, dans l'ordre alphabétique, qui a une législation vide.

Après la migration, ou si la migration est réalisée après la validation du dossier, les numéros de compteurs définis dans la fonction Affectation des compteurs (GESTCA) doivent être réattribués sur les bons types de devis, afin de préserver l’ordre des numéros de compteurs.

Initialisation des prix sur une commande de ventes inter-sociétés

Le processus de migration doit assigner une valeur dans la colonne Transfert prix, dans le tableau Flux automatiques dans la fonction Paramétrage inter-sociétés, pour chaque ligne de flux.

  • Si le document d’origine est une commande d’achat, la colonne Transfert prix est initialisée avec la valeur 'Non'.
  • Si le document d’origine est une facture de vente, la colonne Transfert prix est initialisée avec la valeur 'Oui'.

Règles de transfert des éléments de facturation du module Ventes

Dans la fonction Éléments de facturation (GESSFI), vous devez vérifier les valeurs des nouvelles lignes dans le tableau Règles de transfert.

Lors de la migration d’un dossier, les règles des nouvelles lignes dans la fonction Éléments de facturation sont basées sur les règles suivantes :

  • Pour les règles de transfert d’un retour sur un avoir, les règles sont les mêmes que celles utilisées pour les factures sur avoirs.
  • Pour les règles de transfert d’un contrat de service sur une facture, les règles utilisent les valeurs suivantes, dans un souci de cohérence avec les comportements des versions précédentes :
    • Règles d’éclatement : Toutes les factures (pour les éléments de facturation en montant ou pourcentage)
    • Règles de regroupement : Premier contrat de service
    • Regroupement : Oui

Si vous avez besoin de modifier ces règles, vous devez les modifier après la migration.


Déclaration d’échanges de biens (Intrastat)

Vous devez effectuer une extraction à vide après la migration vers une mise à jour 9.0.0. afin de marquer les anciens documents qui n’ont pas encore été extraits. Sinon, ils apparaitront lors d’une nouvelle extraction pour la déclaration d’échanges de biens.

Cette action concerne les dossiers dans lesquels la sous-traitance est gérée, car de nouveaux flux de sous-traitance sont automatiquement déclarés.