Pré et post-requis fonctionnels de migration d'un dossier en mise à jour 8.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érationpermet 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é

Mise à jour du numéro définitif sur les pièces comptables 

Si l'utilitaire de mise à jour du numéro définitif sur les pièces comptables n'a pas été exécuté dans le dossier V6 ou V7 d'une société de législation française, il est fortement recommandé d’exécuter cet utilitaire avant d'entamer la procédure de migration.

En effet, une fois le dossier migré vers une mise à jour 8.0.0, cet utilitaire ne pourra plus être exécuté sur les pièces comptables générées avant la migration, alors que les nouvelles écritures comptabilisées après la migration bénéficieront de l'attribution automatique du numéro.

Il est aussi conseillé d'exécuter cet utilitaire avant la migration pour les sociétés de législation non française susceptibles d'utiliser ce numéro.

Post-requis au traitement de migration

Processus métier

Les processus utilisés en version 7 doivent être revalidés par la fonction Génération transactions (GENMSKTRT), et ce sur chaque dossier sur lequel les processus ont été installés ou copiés. Cette validation permet de conformer les processus à la mise à jour 8.0.0.

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

Nouvelle pièce automatique:

•  PYTXR : comptabilisation des règlements dans le cadre de la législation ANG (Angola).

Pièces automatiques modifiées :

• SIHI, SIHI2, SIHI3, PIHI, PIHI2, PIHI3, BPCIN et BPSIN : nouveau mode de gestion des escomptes, destiné à la législation belge (paramètre DEPMGTMOD-Mode gestion escompte = 5, mode de gestion 'Remise sur taxe (exonérée)/Global').
• BPCCO : renumérotation des lignes.
• FXHFS : disponible pour toutes les législations.
• STKRE : code comptable sur la ligne 9 pour la législation USA.

Vous devez donc lancer l’utilitaire de comparaison des pièces automatiques (CMPGAU) entre le dossier migré et le dossier Sage X3.

Modèles d'import

Dans le cadre de la législation belge, les modèles d’import suivants ont été ajoutés :

• DCLCUSBEL,
• DCLEECBEL,
• DCLVATBEL.

Immobilisations

Gestion des familles

En version 7, les familles sont gérées dans la table diverse 611 (Famille comptable), avec la notion d'immatriculable dans la colonne CAB (Code à barres) et d'immatriculable en automatique dans la colonne CAB auto.

En mise à jour 8.0.0, la familles sont gérées dans la table FASFAM (FAM, Familles immobilisation) et la notion de CAB auto n'est plus gérée.

L'utilisateur doit vérifier que les familles de la table diverse 611 ont été transformées par la migration et sont disponibles dans la fonction Familles immobilisation (GESFAM).

Négoce

Législations

La gestion de certaines fonctions intègre la notion de législation.

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.

Livraisons

Le champ État retour (RTNSTA) de la table Entête de livraison (SDELIVERY) est mis à jour pour les livraisons de catégorie 'Normale' ou 'Pour sous-traitance'. La valeur de ce champ est déterminée en fonction des retours existants pour ces livraisons.

Types de changement de stock et types de retour d'achat

Le processus de migration doit assigner:

• un type de changement de stock dans le champ Type changement stock (SGHTYP) pour tous les changements des stocks existants,
• un type de retour d'achat dans le champ Type retour (PNHTYP) pour tous les retours d'achat existants.

Le type de changement de stock et le type de retour d'achat à utiliser proviennent du dossier de référence. 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.

Le système remplit les changements de stock et les retours d'achat de la façon suivante:

• Pour chaque changement de stock :

1. Le système sélectionne le premier type de changement de stock, dans l'ordre alphabétique, qui correspond à la fois à la législation du changement de stock et au type de mouvement du changement de stock.

2. S'il ne trouve rien, le système sélectionne le premier type de changement de stock, dans l'ordre alphabétique, qui a une législation vide et qui correspond au type de mouvement du changement de stock.

• Pour chaque retour d'achat:

1. Le système sélectionne le premier type de retour d'achat, dans l'ordre alphabétique, qui correspond à la législation du retour d'achat.

2. S'il ne trouve rien, le système sélectionne le premier type de retour d'achat, dans l'ordre alphabétique, qui a une législation vide.

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 alimenté en même temps que le champ précédent,
• les champs Description courte et Description longue sont alimentés 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.

États

Les états SBONFAC* ont été modifiés pour intégrer l’affichage du taux d’escompte dans les cas de législation belge (lorsque le paramètre général DEPMGTMOD-Mode gestion escompte a pour valeur 5, soit 'Remise sur taxe (exonérée)/Global').