Aide à la migration X.9->X.10

Articles et unités en X.

...

10

La création d’un article géré en stock sans unités n’est plus permise .

Il y aura donc un message bloquant à la validation si les unités n’ont pas été renseignées.

Pour éviter ce message , il y a possibilité de paramétrer une unité par défaut dans le dossier commerce & logistique.

...

Augmentation de la taille du champ contact

Pour permettre ultérieurement d’avoir des contacts multi tiers, le champ tiers dans la table des contacts est voué à disparaître.

Pour préparer les choses en amont, la taille du champ contact a été augmenté de 8 caractères à 30.

L’objectif étant de pouvoir faire une reprise du passé en stockant le code tiers (20 caractères) et le code contact (8 caractères) séparés par un tiret. C’est ce qui est fait Weavy aujourd’hui lors de l’import des contacts depuis Infinity, donc l’objectif était de pouvoir refaire pareil afin de ne pas créer de doublons.

Une nouvelle case à cocher “Gérer les codes contacts en automatique” a été créée dans le dossier C&L

...

Si cette nouvelle case est cochée, le CE3 de la table T2 (contact) vaut 1 lors de la création de nouveau code contact. Dans ce cas, il est impossible de faire une création d’un code contact existant déjà, quel que soit le tiers.

Si ce CE3 vaut 1, Weavy récupère le code contact tel quel, sans concaténer avec le code tiers, l’unicité étant déjà assurée.

Point d’attention : les codes contacts passant de 8 à 30, des modifications ont été apportées dans Divalto Processus afin de permettre de gérer cette nouvelle longueur. Il faudra modifier les processus existant qui utilisent un code libellé sur 8 ou 20 pour utiliser un libellé de 30 ou plus à la place

Pour les anciens code contacts, il existe un script de mise à jour : gt_27178.sql.

Attention :

• Si vous utilisez Divalto Weavy et Divalto Infinity, il est obligatoire de mettre à jour Divalto Weavy en version 5.7 minimum avant de cocher la gestion automatique des codes contacts ou de passer le script

• Ce script est fourni comme une aide à la migration, il n’est pas déclenché automatiquement par la migration vers une X.9. Il peut être lancé à la main pour permettre de modifier automatiquement les codes contacts existant vers la nouvelle numérotation. Point d’attention : le script n’est pas capable de faire la différence entre des dossiers comptables et de gestions commerciales : il ne traite que les dossiers GesCom ayant été coché comme passant en gestion automatique, mais en cas de gestion interagence, il modifie toutes les tables pour le dossier GesCom, indépendamment de la gestion de dossier comptable par établissement GesCom

Ce script peut être lancé indépendamment de la case à cocher.

Ce script permet de :

• créer une nouvelle entrée “pour historique” dans la nouvelle table des relations

• créer une nouvelle entrée dans la nouvelle table des relations contacts/tiers, utilisant le code “pour historique” par code contact + tiers (2 champs contacts, un qui contiendra le nouveau code après mise à jour, et un pour historique)

• Mettre à jour le champ contact dans la table des contacts et dans la tables des relations contacts/tiers, ainsi que le CE3 dans la table des contacts

• Mettre à jour le champ contact dans l’intégralité de la base de données, en utilisant la tables des relations contacts/tiers qui contient donc un champ avec le nouveau code et un champ avec l’ancien pour faire la jointure avec toutes les autres tables de l’ERP contenant un champ contact

Grille transporteur (T027) en x.10

Le champ POIB ( au format 8,3 ) est remplacer par le champ TRANCHE ( 12,3)
Un script de migration transfert le champ POIB vers le champs TRANCHE

Table SOC, nouvelle colonne ZONEPARAM en x.10 (ex ENTCODN)

La table SOC en X.9 comporte 974 colonnes, proche de la limite fixé par Microsoft pour un table SQL.

Les développements spécifiques dans USOC pouvais être dangereusement compromis par cette limites, notamment dans le cadre des surcharges multiples.

La solution technique qui a été adoptée est de transférer un ensemble de champs de SOC dans un nouveau champ ZONEPARAM assortie de leur non visibilité SQL.

les conséquence techniques sont :

• l’utilisation en langage SQL d’un champs masqué devra être adapté :

SOC.ENTCODN(1) à converti en SUBSTRING(Dossier.ZONEPARAM,1,1) .

Le tableau ENTCODN à volontairement été mis en début de ZONEPARAM pour garder une similitude entre l’indice et sa position en SUBSTRING

• L’utilisation de SOC.ENTCODN est toujours possible si la table SOC est public dans le RecordSql

  • Exemple :

...

• L’utilisation de SOC.ENTCODN est toujours possible en DIVA car la structure SOC est multi-niveau donc les sous niveau de ZONEPARAM sont visible et manipulable.

Le nombre de colonnes dans SOC grâce a cette manipulation est retombé à 346.

Accès aux champs de la ZONEPARAM via SQL:

• Accès à un champ “simple”

Par exemple si on veut accéder au champ InvImpPagCod

SUBSTRING(SOC.ZONEPARAM, Position_début_dico , 1)

En appliquant cette formule à notre exemple on obtient : SUBSTRING(SOC.ZONEPARAM, 535, 1)

...

• Accès à un champ dans un tableau

Par exemple si on veut accéder à l’indice n°5 du champ ConfEnr2

SUBSTRING(SOC.ZONEPARAM, (Position_début_dico + Indice souhaité - 1) , 1)

En appliquant cette formule à notre exemple on obtient :

SUBSTRING(SOC.ZONEPARAM, (514 + 5 - 1), 1) soit au final SUBSTRING(SOC.ZONEPARAM, 518, 1)

...