Sage X3 : Pré et post-requis fonctionnels de migration d'un dossie

Localisation espagnole

Lors de la migration d'un dossier de législation espagnole, merci de contacter votre service client espagnol afin de connaître la procédure de migration dédiée.

Pré-requis au traitement de migration

On trouvera ci-dessous les pré-requis de migration d'un dossier. De façon générale, une première étape, qu'il est fortement conseillé de réaliser, est de vérifier la cohérence des données à migrer. En effet, sur un dossier qui a beaucoup de mouvements, et qui a parfois subi des étapes de maintenance, il est possible que certaines données ne soient pas parfaitement cohérentes (et ce d'autant plus que l'on peut avoir des développements spécifiques).

Cette opérationpermettra 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 à proprement parler, 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).

Post-requis au traitement de migration

Processus métier

Les processus utilisés en version 6 doivent être revalidés par la fonction Recodification processus (ARECOPRO). Cette validation permet de les conformer à la version 7.

La validation des processus doit se faire :

• après chaque validation de dossier,
• après chaque copie de processus d'un dossier à un autre.

Comptabilité

Pièces automatiques

De nouvelles pièces automatiques sont disponibles en version 7 et certaines pièces automatiques de la version 6 ont été modifiées. 
Vous devez donc lancer l’utilitaire de comparaison des pièces automatiques entre le dossier migré et le dossier Sage X3.

Intitulés longs et courts des données déclinées par législation

Certaines fonctions de paramétrage sont désormais déclinées par législation. A l’occasion de cette adaptation, les champs intitulés longs et courts ont été rendus obligatoires dans la langue de connexion de l’utilisateur. En cas de modification de la valeur d’un champ d’une telle donnée, si l’intitulé long ou court n’est pas présent dans la langue de connexion, il doit être complété.
Les fonctions concernées utilisées en finance sont les types de pièces (GESGTE), les journaux (GESJOU), les destinations comptables (GESCDA), les transactions de règlements (GESTPY), les codes éditions (GESTED), les modes de règlements (GESTAM), les fichiers bancaires (GESTFB), les codes taxes (GESTVT), les régimes de taxe (GESTVB), les codes escomptes/agios (GESTDA), les types de factures ventes et achats (GESTSV et GESTPV).

Groupe d’états

En version 7, les fonctions permettant de gérer les déclarations à des organismes fiscaux ou administratifs ont été regroupées dans un menu Déclarations et réorganisées par thème puis législation.
Les états associés à ces fonctions ont aussi été réorganisés en conséquence, leur groupe de rattachement (via le menu local 97) étant donc forcé pour correspondre à cette nouvelle structure.
Dans le cas où certaines particularités clients quant au groupe de rattachement doivent perdurer après migration, il conviendra de modifier le groupe d’états de l’état.

Champs indiquant un chemin de fichier

Le nouveau mode de gestion des volumes en V7 et l’utilisation d’un browser internet plutôt qu’un client lourd implique que les champs permettant d’indiquer un chemin de génération de fichier fonctionnent différemment. Sont concernés des valeurs paramètres d’une part, mais aussi des champs de certaines fonctions.
Pour ce qui est des paramètres contenant un chemin, ils sont désormais utilisés uniquement quand la destination est de type Serveur. Ils doivent de ce fait contenir un chemin relatif au volume sélectionné (ou simplement un volume), exprimé avec la syntaxe idoine.
Par exemple, le paramètre EXPCASPAY devra contenir [CASH] afin que les fichiers soient générés sous le volume CASH.
Ces paramètres doivent donc être mis à jour pour contenir les volumes ou chemins relatifs selon la nouvelle syntaxe.
Pour ce qui est du cas des champs de fonction, les fonctions ‘Paramétrage ENEREGY’ (GESNRY) et ‘Paramétrage ACCENTFIL’ (GESFAE) sont concernées. Ces deux fonctions contiennent une zone qui dans le cas d’une génération de type Serveur doit contenir un chemin relatif au volume sélectionné (ou simplement un volume).

Immobilisations

Types d'écritures

En version 7, le paramétrage des Types d'écritures comptables (GESTPE) a été modifié. Les types d'écritures ont été recodifiés en standard et il est désormais possible de saisir un type de pièce et un code journal par législation.
Il est donc conseillé de vérifier leur paramétrage.

Négoce

Législations

En version 7, la gestion de certaines fonctions intègre la notion de législation.

• Les fiches possédant un filtre sur la législation, disposent de ce code législation dans la nouvelle clé.
• Les fiches qui n’ont pas de filtre sur la législation ont un code vide pour la législation. Ces fiches sont alors considérées comme multi-législations.
• Les informations du groupe sont maintenues en tant que filtre.
• L'intitulé long et l'intitulé court sont conservés. Si dans certaines fiches ces intitulés sont vides, l’utilisateur doit saisir ces intitulés manuellement lors de leur mise à jour.

Ci-dessous, la liste des fonctions gérées par législation et la clé correspondante modifiée sur la table associée à l'objet.

Tables diverses

• Les tables diverses 1, 2, 3, 6, 15 et 304 sont migrées en nouveaux objets.
• Les tables qui possèdent un filtre sur la législation disposent de ce code législation dans la nouvelle clé.
• Les tables qui n’ont pas de filtre sur la législation ont un code vide pour la législation. Ces tables sont alors considérées comme multi-législations.
• Pour une ancienne table diverse qui a une information de groupe, cette information de groupe est maintenue dans le nouvel objet en tant que filtre. Toutes les autres informations standards de cette table diverse sont transférées dans la nouvelle table objet.
• Tous les champs non-standards ajoutés lors du paramétrage des tables diverses (A1, A2, N1, N2 fields) sont transférés dans la nouvelle table objet (ils ne seront pas affichés dans le nouvel objet).

Ci-dessous, le tableau de correspondance entre les tables diverses utilisées en V6 et les fonctions de gestion des objets en V7.

Types de livraison et types de retours

Le processus de migration doit attribuer :

• un type de livraison dans le champ SDHTYP pour toutes les livraisons existantes.
• un type de retour dans le champ SRHTYP pour tous les retours existants.
  Le type de livraison et le type de retour à utiliser proviennent du dossier de référence. Seuls ceux qui ont des législations prises en charge dans le dossier de destination et ceux qui ont une législation vide sont copiés à partir du dossier de référence.
  Le même processus s'applique pour les paramètres généraux suivants, avec leurs valeurs par législation: SDHTYPNOR, SDHTYPLND et SDHTYPCSO.
   Le client a la possibilité d'établir les données à deux niveaux différents en fonction de la façon dont la migration est réalisée :
• la migration est faite en même temps que la validation du dossier : la configuration doit être faite correctement dans le dossier de référence, avec les codes des types attendus (les tables des types et les paramètres généraux). Sinon, le système utilise les types par défaut livrés en standard.
• la migration est faite après la validation du dossier : la configuration doit être faite correctement dans le dossier de destination avec les codes des types attendus ( tables types et paramètres généraux). Sinon, le système utilise les types par défaut  qui ont été copiés depuis le dossier de référence.
• Lorsque les tables des types de livraisons et des types de retours sont remplies, et lorsque les paramètres généraux SDHTYP* sont définis,  le système alimente les livraisons et les retours selon les processus suivants. :
• pour chaque livraison :
• le système vérifie le paramètre général correspondant à la catégorie de livraison,
• si aucune valeur n’est définie, le système prend le premier type de livraison, dans l’ordre alphabétique, qui correspond à la législation de livraison et la catégorie de livraison,
• si aucune valeur n’est définie, le système prend le premier type de livraison, dans l’ordre alphabétique, qui a une législation vide et qui correspond à la catégorie de livraison,
• pour chaque retour :
• le système prend le premier type de retour, dans l’ordre alphabétique, qui correspond à la législation de retour et à la catégorie de retour,
• si aucune valeur n’est définie, le système prend le premier type de retour, dans l’ordre alphabétique, qui a une législation vide et qui correspond à la catégorie de retour.

Mass Mailing CRM

• Le paramètre WORDPATH (Utilisateurs/Paramètres/CRM/DEF/WORDPATH) n’existe plus, le mode de création des documents Microsoft Word ayant changé.
• La  table Etat mailing (OMMRPT) contient seulement les modèles d’états Crystal. Lors de la migration, le processus suivant est alors appliqué :
• toutes les fiches qui identifient des modèles Microsoft Word sont supprimées,
• le champ Type (TYPTPL) est supprimé,
• le champ Langue est rempli avec la langue du dossier par défaut,
• le champ Code état (MAGTPL) identifie maintenant la fiche ‘Code d’état’,
• un nouveau champ contient le nom de l’état Crystal. Ce champ non visible est rempli en même temps que le champ précédent,
• les champs Description courte et Description longue sont remplis avec le code de l’état,
• une nouvelle clé est créée avec le code de la langue : Code de la langue + Code d’état.
• La  table Publipostage xml (MAILXML) contient deux nouveaux champs : les champs Description courte et Description longue, avec le code XML de mass mailing.

Modèles d'import

• Le type de livraison est ajouté dans le modèle d'import SDHFL.
• De nouveaux modèles d'import, résultants de la création d'objets en remplacement des tables diverses, sont ajoutés : TAM (Modes de règlement), TEC (Nature transaction), TED (Code édition), TPV  (Types de facture fournisseur), TRE (Types de retours), TSC (Régime statistique), TSD (Types de livraisons), TSO (Types de commandes), TSV (Types facture vente), TVB (Régime de taxe tiers), TVI (Niveau de taxe).

Etats

• Les éléments liés au SDD sont ajoutés dans les états factures (SBONFAC*).
• Les éléments liés aux types de livraison et types de retour sont ajoutés dans les états BONLIV*, BONRETLIV, SDELIVERY*, SRETURN*.