Module de base
Lors du passage d’une version antérieure à la V5.0-00 vers une version postérieure ou égale à la V5.0-00, une mise à jour est effectuée sur trois tables particulièrement sensibles :
|
Mise en garde Avant de mettre à jour votre version ACE , nous vous invitons à lire ce qui suit. |
Nouvelle gestion des utilisateurs
Depuis la version ACE 5.0-00, un utilisateur possède un mot de passe unique pour l’ensemble des sociétés auxquelles il a accès au sein de la même instance physique.
Les utilisateurs sont toujours gérés au niveau de chaque société, les mots de passe dans la table UT_LOGIN indépendamment du code société.
Le champ "passe" de la table UT_UTI est supprimé et remplacé par le champ "password" de la tableUT_LOGIN.
-
Si le même utilisateur est présent dans plusieurs sociétés avec des mots de passe différents, on crée automatiquement cet utilisateur dans la table UT_LOGIN en y affectant le mot de passe associé au code société le plus petit (table UT_UTI).
-
La table UT_UTI est ensuite mise à jour (suppression du champ « passe »).
Exemple :
Œ Avant la mise à jour
Table UT_UTI
| Nom du champ | UTI | PASSE | CODSOC |
| Pascal | Focus | 1 | |
| Pascal | Commando | 2 | |
| Georges | Action | 1 |
Après mise à jour
Table UT_LOGIN
| Nom du champ | USERNAME | PASSWORD | UTI |
| Pascal | Focus | Pascal | |
| Georges | Action | Georges |
Table UT_UTI
| Nom du champ | UTI | CODSOC |
| Pascal | 1 | |
| Pascal | 2 | |
| Georges | 1 |
Ces évolutions de la gestion des utilisateurs ont été prises en compte au niveau des fonctions GBLV, GCAI et GTIE.
En effet, l’écran GBLV_PASSE est remplacé par l’écran RMCR_PASSE :
- Le champ « username » est ajouté dans les écrans GTIE_19 et GTIE_XCTC,
- Le champ « password » est ajouté dans les écrans GTIE_19, GTIE_XCTC et GCAI_4.
Il vous faut par conséquent mettre à jour les écrans paramétrés GTIE_19, GTIE_XCTC et GCAI_4.
Nouvelle gestion des sociétés
Depuis la version ACE 5.0-00, il ne peut y avoir de doublons dans la table les sociétés.
L’index est en effet unique sur le champ "soc" de la table UT_SOC.
Règle de mise à jour de la table UT_SOC
Si des sociétés (SOC) sont présentes plusieurs fois dans la tableUT_SOC, on récupère les enregistrements du code société (CODSOC) le plus petit.
Exemple :
Œ Avant la mise à jour (table UT_SOC)
| Nom du champ | SOC | CODSOC |
| 1 | 1 | |
| 2 | 1 | |
| 1 | 1000 | |
| 1000 | 1000 |
Après mise à jour (table UT_SOC)
| Nom du champ | SOC | CODSOC |
| 1 | 1 | |
| 2 | 1 | |
| 1000 | 1000 |
Outils de contrôle disponibles sur le site support
Afin de préparer la migration, sans devoir faire l’installation d’ACE V5.0-00, il est possible de simuler les modifications qui seront apportées par ces nouvelles gestions des sociétés et des utilisateurs, à l'aide d'outils accessibles sur le site du Support ACE.
Ces outils sont fournis sous la forme de scripts SQL regroupés dans une archive nommée « check_uti_soc_v500 » et accessible dans la rubrique « Documentation »
à Documentations Techniques
à Notices Thématiques
à Installation
à V5.0-00
Principe
L'exécution de ces scripts SQL sur la base avant migration permet de visualiser quelles seront les modifications apportées à la gestion des sociétés et des utilisateurs.
Les scripts SQL sont à déclencher après s’être connecté à la base sur le compte Oracle propriétaire des tables ACE (SOCx).
-
la situation actuelle,
-
la situation future,
-
les différences.
Présentation des scripts
-
check_soc_V500.sql
Affiche les évolutions prévues sur la gestion des sociétés.
-
check_uti_V500.sql
Affiche les évolutions prévues sur la gestion des utilisateurs
-
check_V500_txt.sql
Déclenche les 2 premiers scripts et génère dans le répertoire courant des fichiers de compte-rendu au format texte :
o check_soc_V500.txt
o check_uti_V500.txt
-
check_V500_html.sql
Déclenche les 2 premiers scripts et génère dans le répertoire courant des fichiers de compte-rendu au format HTML (à partir d’Oracle 8i) :
o check_soc_V500.xml
o check_uti_V500.xml
UTILISATION : multi entites
Pré-requis pour le passage en version 5.0-00 ou ACE 1.0 : utilisation du mode multi-entités.
Partage de la table UT_SOC
Pour les versions antérieures à la V5.0-00, il était conseillé de partager la table des sociétés.
|
|
Depuis la version 5.0-00, le partage de la table UT_SOC, pour toutes les sociétés logiques d'une même instance physique, devient un impératif de fonctionnement. |
Une instance physique par environnement
Dans le cas plus général d’une instance physique par environnement, il est conseillé d’utiliser la société de référence (codsoc) pour renseigner l’ensemble des sociétés.
Exemple de fichier « Generix.ini » :
[Global]
Societe de Reference=1
[Societes]
societe_1=1
societe_2=1
Un environnement avec deux instances physiques
Dans le cas d’un environnement avec deux instances physiques, la société de référence devra être renseignée avec l’ensemble des sociétés.
Pour chaque instance physique, les sociétés devront être renseignées dans une société (codsoc) qui sera utilisée comme partage pour l’ensemble des sociétés de l’instance physique.
Exemple de fichier « Generix.ini » :
[Global]
Societe de Reference=1
[Societes]
societe_1=1
societe_2=1
...
societe_1000=1000
societe_1001=1000
[Tables_2]
ut_soc=1
...
[Tables_1001]
ut_soc=1000
Partage des autres tables
Nombre de copies sur les impressions
A partir de la version 5.0-00, le nombre de copies est géré dans le fichier « modif_tty_print.exe ».
L'impression par ACE envoie un nouveau paramètre vers ce fichier :
· nombre_copies,
Le fichier « modif_tty_print » présent dans les versions antérieures à la V5.0-00 doit nécessairement être modifié pour bénéficier de cette évolution.
ACE fournit systématiquement, dans le répertoire des exécutables « exe », un nouveau fichier ayant valeur de modèle.
Calcul de la DLC d’un lot
Quand on crée un lot d'un produit via l'écran RMCR_OSTG, la Date Limite de Consommation (DLC) du lot déterminée en fonction de sa date de fabrication et de sa durée de vie, est désormais calculée de la manière suivante (exemple) :
- Date de fabrication : 01/05/2004,
- Durée de vie : 30 jours,
Alors la DLC est : 30/05/2004. En effet, entre le 01/05 et le 30/05, il y a 30 jours.
Le comportement précédent (version 4.4-00 et versions antérieures) calculait une DLC + 1 jour (le 31/05/2004 dans notre exemple).
Pour conserver cet ancien comportement, il suffit d’utiliser le nouveau paramètre DURVIE.
Mode mono société avec un code société égal à 0
Ce chapitre ne concerne que les clients utilisant auparavant le mode mono société avec un code société égal à 0.
Pré-requis pour le passage en version 5.0-00 ou ACE 1.0 : utilisation du mode multi-entités.
Le code société ne peut pas être égal à 0, il est donc nécessaire d'affecter un code société à l'ensemble des tables.
|
|
Attention Les opérations suivantes ne doivent être réalisées que si vous passez d’une version antérieure à la V5.0-00 vers une version postérieure ou égale à la V5.0-00. |
· Sauvegarder chaque société Physique (compte Oracle).
· Modifier le code société (champ « codsoc ») dans l'ensemble des tables ACE.
· Après avoir pris garde de vérifier dans chaque société physique que le nouveau code société n'est pas utilisé.
Pour chaque société physique, lancer la requête SQL de mise à jour du codsoc = 0:
@sql_o/update_codsoc.sql n (n = numéro du nouveau code société)
· Modification du fichier Generix.ini :
Positionner le mode société à « Oui ».
[Global]
Mode Multisociete=OUI
Vérifier le rattachement des sociétés
[Societes]
societe_1=1
· Spécifiques clients : points de contrôle indispensables
Vérifier et éventuellement modifier :
- les triggers et procédures stockées,
- les requêtes SQL,
- les vues.
Adapter les éventuels spécifiques client utilisant le MCD d’ACE.
|
Trucs et astuces
|
