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.
Fonction | Nom de la fonction | Eléments de clé |
GESCDA | Destinations comptables | COD+LEG |
GESGTE | Types de pièces | TYP+LEG |
GESJOU | Journaux comptables | JOU+LEG |
GESTDA | Escomptes/Agios | DEP+LEG |
GESTFB | Fichiers bancaires | COD+BAN+RECTYP+ORDNUM+LEG+NUM |
GESTPT | Conditions de paiement | PTE+LEG+PTELIN |
GESTPV | Types facture fournisseur | PIVTYP+LEG |
GESTSV | Types facture client | SIVTYP+LEG |
GESTPY | Transactions saisie règlements | PAYTYP+LEG |
GESTRE | Types de retours | SRHTYP+LEG (Nouveau en V7) |
GESTSD | Types de livraisons | SDHTYP+LEG (Nouveau en V7) |
GESTSO | Types de commandes | SOHTYP+LEG |
GESTVC | Détermination taxes | COD+LEG |
GESTVT | Taux de taxes | VAT+LEG |
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.
Numéro de la table diverse en V6 | Nom de la table | Nouvelle table | Eléments de clé | Nouvelle fonction | Nom de la nouvelle fonction |
1 | Régimes de taxes tiers | TABVACBPR | VACBPR+LEG | GESTVB | Régime de taxe du tiers |
2 | Niveaux de taxes articles | TABVACITM | VACITM+LEG | GESTVI | Niveau de taxe |
3 | Modes de réglement | TABPAM | PAM+LEG | GESTAM | Modes de règlement |
6 | Nature transaction DEB | TABEECNAT | EECNAT+LEG | GESTEC | Nature transaction |
15 | Régimes statistiques DEB | TABEECSCH | EECSCH+LEG | GESTSC | Régime statistique |
304 | Code édition | TABCODEDT | CODEDT+LEG | GESTED | Code édition |
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*.