Aller au contenu principal

Utilisateurs et autorisations

1 Introduction

Dans IDL.KONSIS.FORECAST, il est possible de restreindre les autorisations de chaque utilisateur à l'aide d'un concept d'autorisation. Les éléments de menu nécessaires sont décrits ci-dessous. La maintenance des informations mentionnées ici relève de l'administration du système et ne doit donc être autorisée que pour les utilisateurs disposant de droits d'administration. Dans la norme fournie par IDL.KONSIS.FORECAST, seuls les groupes d'utilisateurs IDLADMIN et IDLSYS disposent des droits de modification nécessaires.

2 Utilisateurs (USE)

Cette application prend en charge tous les utilisateurs qui sont généralement autorisés à travailler avec IDL.KONSIS.FORECAST. L'utilisateur doit être préalablement autorisé en tant qu'utilisateur de la base de données IDL.KONSIS.FORECAST ou en tant qu'utilisateur réseau par l'administrateur système.

Les rôles qu'un utilisateur est autorisé à exercer sont définis par le mappage d'un groupe d'utilisateurs d'autorisations de menu.

Par défaut, seul l'utilisateur IDLADMIN est défini lors de l'installation de IDL.KONSIS.FORECAST. Continuer utilisateurs doivent être définis par le client.

Pour cela, vous allez dans l'application de phrases isolées que vous

  • en cliquant sur l'étoile dans la barre d'outils, ou
  • en double-cliquant dans la table (vide)

Appelé.

Les modifications apportées à un utilisateur existant peuvent être effectuées par

  • Sélection de la ligne et clic sur l'icône du crayon dans le menu contextuel ou
  • Double-clic sur l'enregistrement correspondant

sont effectuées.

Les cellules suivantes doivent être remplies :

UTILISATEUR :
Nom de l'utilisateur utilisé dans le programme pour spécifier l'utilisateur de la modification.
Nom d'utilisateur de connexion (ID de connexion) :
Nom d'utilisateur pour la connexion dans IDL.KONSIS.FORECAST. L'ID de connexion peut être différent du nom, en particulier si le nom dépasse 8 chiffres.
Nom / Prénom / Téléphone / E-mail :
À des fins de documentation et de spécification ; ces informations ne sont pas utilisées dans IDL.KONSIS.FORECAST.
Langue :
La spécification dans cette cellule contrôle la désignation dans laquelle les objets spécifiques à l'application (par exemple, nom de compte). Contrairement à la langue de surface (pour les menus, les promos et les titres de la colonne), il est également possible d'indiquer des langues entretenues par le client.
Template :
Un utilisateur avec cet attribut n'a pas d'ID de connexion et ne peut pas être utilisé pour se connecter. Les utilisateurs de modèles et leur présélection des données à indiquer sont utilisés comme modèle pour créer automatiquement des utilisateurs dans IDL.KONSIS qui étaient précédemment créés uniquement dans Active Directory.
Groupe d'utilisateurs des droits de menu :
Spécifie un groupe d'utilisateurs qui définit les autorisations de menu (autorisations de fonction) pour l'utilisateur. Sans cette spécification, l'utilisateur peut se connecter, mais ne peut pas démarrer de fonctionnalité d'application.
Groupe d'utilisateurs pour les objets de données :
Spécifie un groupe d'utilisateurs qui régit l'autorisation d'accéder à des objets de données spécifiques. Cette spécification n'est fournie qu'avec la définition des autorisations d'objet (voir ci-dessous. ) et en spécifiant le contrôle d'autorisation approprié dans la présélection des données à indiquer spécifique à l'utilisateur (voir ci-dessous. ) effectif.
Nom d'utilisateur du type de données :
Pour les utilisateurs de l'interface IDL Datamart vers IDL.DESIGNER, un ID de connexion différent peut être spécifié ici si nécessaire.
VALIDE DÈS / VALIDE JUSQU´À :
La validité d'une connexion utilisateur peut être limitée dans le temps par des entrées dans ces cellules.
Type d'utilisateur de licence dans KONSIS :
Admin-User (A)=Fonctionnalité administrative uniquement ; Full-User (F)= Fonctionnalité complète ; Light-User (L)= comptes sociaux ; Viewer-User (V)=Affichage/Reporting
Licence Type d'utilisateur FORECAST :
Full-User (F)= Fonctionnalités complètes ; Light-User (L)= saisie/Reporting
Licence Type d'utilisateur XLSLINK :
Full-User (F)= Fonctionnalités complètes

Si l'authentification n'est pas effectuée par le système d'exploitation (Windows, Active Directory) ou le système de base de données, mais par la base de données IDL.KONSIS (paramètre de l'utilitaire de configuration du serveur d'applications IDL.KONSIS.FORECAST), l'application utilisateurs (USE) affiche des champs d'entrée supplémentaires. Ils sont décrits dans la documentation « Mot de passe interne ».

3 Autorisations de menu (USEMEN)

3.1 Généralités

Cette vue d'ensemble affiche, par ordre alphabétique, tous les éléments de menu (applications) pour lesquels un groupe d'utilisateurs est autorisé. Pour chaque élément de menu, tous les droits d'action actuellement attribués sont affichés. Les actions suivantes sont distinguées : Afficher, Modifier, Coller, effacer et Copier.

IDL utilise la base de données de livraison ou les métadonnées des versions et mises à jour pour fournir des groupes d'utilisateurs standard qui peuvent être affectés aux utilisateurs. Ces groupes d'utilisateurs commencent tous par « IDL ». Par conséquent, les utilisateurs ne doivent pas créer de groupes d'utilisateurs dont la clé commence également par « IDL ». Les groupes d'utilisateurs suivants sont fournis :

IDLSYS :
Ce groupe d'utilisateurs est destiné aux administrateurs système qui n'exercent aucune fonction technique dans IDL Konsis. L'autorisation est limitée à la gestion des utilisateurs et de leurs droits, au démarrage de la conversion mise à jour et à l'activation de la journalisation des modifications.
IDLADMIN :
Ce groupe d'utilisateurs comprend presque tous les droits d'utilisateur et est donc un résumé des droits d'IDLSYS et IDLKON. Certaines applications bénéficient même de privilèges spéciaux qui permettent de contourner les restrictions du système. Ce groupe d'utilisateurs ne doit donc être utilisé que dans des cas exceptionnels.
IDLKON :
Ce groupe d'utilisateurs est réservé aux utilisateurs disposant d'une autorisation technique complète, ce qui signifie qu'il existe des droits pour toutes les applications professionnelles. Cependant, les privilèges et les droits du groupe d'utilisateurs IDLSYS sont absents du groupe d'utilisateurs IDLADMIN.
IDLKON1 :
Ce groupe d'utilisateurs autorise les utilisateurs à travailler sur le comptes consolidés et sur le plan individuel. Toutefois, le groupe IDLKON ne dispose pas des autorisations nécessaires pour modifier les données de base et de structure, à l'exception de la maintenance du périmètre de consolidation.
IDLEA :
Ce groupe d'utilisateurs autorise les utilisateurs à créer des comptes sociaux. Par rapport à IDLKON1, les droits sur le comptes consolidés font défaut. Toutefois, il existe des droits à cet effet pour certaines données permanentes, par exemple pour la maintenance des plans de compte ou de contrôle de société.
IDLEE :
Ce groupe d'utilisateurs prend en charge le principe du double regard pour les comptes sociaux. Un utilisateur de ce groupe peut uniquement afficher les données d'une opération unique, mais il ne peut pas les modifier. Les droits de modification ne s'appliquent qu'au blocage et au deblocage des données des états financiers individuels.
IDLVIEW :
Ce groupe d'utilisateurs s'adresse aux auditeurs et autres personnes similaires qui ont le droit de lire toutes les données, mais ne sont pas autorisés à les modifier. Le seul droit de modification concerne la présélection des données à indiquer spécifique à l'utilisateur (VORE).
IDLNOAUT, IDLMISWS, IDLIMPWS :
Ces groupes d'utilisateurs n'ont aucun droit dans IDL Konsis. Ils sont toutefois nécessaires pour les utilisateurs d'IDL.DESIGNER qui accèdent aux données ou aux fonctions d'IDL Konsis via des services Web. Le groupe d'utilisateurs IDLIMPWS peut exporter ces données vers IDL.DESIGNER après saisie des données dans IDL.DESIGNER en lançant les applications d'importation appropriées.

Indépendamment de l'entrée du groupe d'utilisateurs des droits de menu, les différentes actions d'IDL Konsis vérifient également si cette action est également autorisée selon la classification de licence de l'utilisateur. Par exemple, il n'est pas possible d'accorder des droits de consolidation à un utilisateur classifié comme « utilisateur léger KONSIS » en affectant le groupe d'utilisateurs IDLKON.

L'autorisation 1 pour l'action <Afficher> est obligatoire au moins pour les groupes d'utilisateurs commençant par « IDL », car l'autorisation de menu doit inclure au moins le droit d'affichage ; elle peut également être égale à 0 pour les groupes d'utilisateurs personnalisés qui font référence à un groupe « IDL ». La spécification de l'autorisation pour les actions suivantes est facultative. Tous les attributs d'autorisation permettent d'entrer les informations suivantes :

  • 0 uniquement pour les groupes d'utilisateurs personnalisés avec référence : Retrait de l'autorisation accordée dans le groupe de référence
  • 1 Autorisation normale
  • 2 privilège
  • autorisation vide comme dans le groupe d'utilisateurs de référence

La différence entre l'autorisation spéciale et l'autorisation normale est définie par l'application. L'autorisation spéciale ne devrait être accordée que dans des cas exceptionnels et dûment justifiés, après consultation de votre conseiller IDL Konsis ou de la ligne d'assistance IDL.

<Copier> copie les lignes sélectionnées vers les clés modifiées. Il convient de distinguer les cas suivants :

  • Lors de la sélection d'un groupe d'utilisateurs unique, copier vers un autre groupe d'utilisateurs
  • Lors d'une sélection par un ID de menu unique Copier vers un autre ID de menu

Si vous spécifiez « L » dans la zone de sélection <CopierOpt>, les autorisations de modification, d'insertion, d'efface et de copie ne sont pas copiées.

Les autorisations de menu pour les groupes d'utilisateurs commençant par « IDL » sont gérées par IDL et mises à jour à chaque changement de version. Les autorisations pour les groupes d'utilisateurs définis par le client (dans l'application USEGRP, voir ci-dessous) doivent être maintenues par le client. Les nouveaux ID de menu qui peuvent être autorisés sont répertoriés dans la documentation de la mise à jour <Nouveau dans la mise à jour. La cartouche. .> spécifié. Les privilèges IDL peuvent servir de modèle.

3.2 Procédure simplifiée pour la maintenance de groupes d'utilisateurs spécifiques

Comme la maintenance des données dans l'application USEMEN peut s'avérer très fastidieuse, des groupes d'utilisateurs personnalisés peuvent accéder à un groupe d'utilisateurs IDL standard (par exemple : IDLKON, IDLEA), ce qui simplifie considérablement les soins. Ce mappage est effectué lors de la création du groupe d'utilisateurs dans l'application Groupes d'utilisateurs (USEGRP). Seuls les groupes d'utilisateurs IDL par défaut (en commençant par « IDL ») peuvent être mappés. Ce référencement commence par hériter toutes les autorisations de menu du groupe de référence du groupe d'autorisations individuel. Dans l'application USEMEN, seules les variations sont maintenues. Il peut s'agir à la fois de droits supplémentaires et de limitations. Les droits supplémentaires doivent être spécifiés par des jeux d'autorisations de menu supplémentaires spécifiant le niveau d'autorisation '1' ou '2'. Le niveau d'autorisation '0' peut être spécifié dans les jeux d'autorisations de menu pour définir des contraintes.

4 Autorisations de groupe d'utilisateurs (USEGRP)

Vous pouvez gérer les autorisations d'objet dans l'application Autorisations de groupe d'utilisateurs (USEGRP), qui permet à la fois de définir les groupes d'autorisations et d'accorder ou de révoquer des droits sur les différents objets racine à partir d'une application.

4.1 Créer un nouveau groupe d'utilisateurs

Cliquez sur l'icône en forme d'étoile pour accéder à un assistant (Wizard) afin de créer un nouveau groupe d'utilisateurs.

Les trois pages de l'assistant permettent d'effectuer les réglages suivants :

Page Désignation :

  • Groupe d'utilisateurs : identificateur alphanumérique à huit chiffres, saisissable
  • Désignation : désignation maximale de 70 chiffres
  • Texte court: texte court de 10 caractères maximum

Page Propriétés :

  • Groupe d'autorisations pour le menu : Pour accorder des autorisations à des applications (telles que ACCDEF, AGGDEF).
  • Groupe d'autorisations pour les données : Société Pour accorder des autorisations à des objets dans vos applications (par exemple, pour une application particulière ou plane comptable).
  • Groupe d'utilisateurs de référence : Les autorisations du groupe d'utilisateurs spécifié sont appliquées. Les autorisations non différentes ne s'affichent pas dans les applications BENNAME et USEOBJ pour un groupe d'utilisateurs avec un groupe d'utilisateurs de référence. Seules les différences sont répertoriées dans les applications.
  • Groupe Active Directory : L'attribut correspond aux droits internes sur les groupes Windows Active Directory. Cela permettra de satisfaire aux exigences de sécurité existantes. (Voir également chapitre 4.2. )

Page Désignations multilingues :

  • permet de gérer les désignations dans tous les langages activés, comme dans les autres applications racine.

4.2 Avis d'autorisation d'Active Directory pour IDL KONSIS FORECAST

L'authentification Active Directory (sans nom ni mot de passe) a été étendue par l'autorisation de groupes Active Directory. Les groupes AD peuvent être liés à des groupes d'autorisations dans IDL.KONSIS.FORECAST, ce qui permet un contrôle des droits utilisateur dans IDL.KONSIS.FORECAST dans Active Directory.

Cette entrée est personnalisée, ce qui signifie qu'elle n'est pas remplacée pour les groupes d'utilisateurs « IDL » lors du changement de version. L'utilisation correcte des minuscules et des majuscules doit être vérifiée.

Dans la configuration du serveur d'applications, il est possible de déterminer séparément si la vérification Active Directory est effectuée pour chaque alias de base de données. Lorsque cette vérification est activée, IDL.KONSIS.FORECAST détermine les groupes auxquels l'utilisateur appartient dans Active Directory lors de la connexion. Groupe d'utilisateurs pour les menus et les prévisions associé à l'utilisateur dans IDL.KONSIS.FORECAST. Les droits de l'objet doivent ensuite faire référence à l'un des groupes Active Directory auxquels l'utilisateur appartient. Sinon, la connexion sera refusée. Cela se produit même si aucun groupe Active Directory n'est associé au groupe d'autorisations de menu.

En outre, vous pouvez également faire en sorte qu'un nouvel utilisateur créé dans Active Directory soit automatiquement créé en tant qu'utilisateur dans IDL.KONSIS.FORECAST. Pour ce faire, il est nécessaire de créer dans IDL.KONSIS.FORECAST un modèle utilisateur avec les valeurs par défaut souhaitées dans la table des utilisateurs (application USE). Le nom et le prénom de l'utilisateur sont prédéfinis avec l'ID utilisateur.

Un attribut Template est ajouté à la table utilisateur (USE) pour identifier le modèle utilisateur. L'entrée de 'X' dans cet attribut identifie un jeu comme modèle utilisateur, qui ne peut pas être utilisé lui-même pour une connexion, mais uniquement comme modèle de copie. Bien qu'il puisse y avoir plusieurs modèles utilisateur, un seul est associé à un groupe Active Directory spécifique à la fois, de sorte que la découverte du modèle utilisateur à utiliser soit unique. Si le modèle d'utilisateur est détecté avec succès, il est utilisé comme modèle de copie pour le nouvel utilisateur. L'ID utilisateur IDL.KONSIS.FORECAST est dérivé de l'ID utilisateur Active Directory. Si l'authentification par l'utilisateur Active Directory lors de la création d'un nouvel utilisateur auprès de l'utilisateur Template ne spécifie pas de « groupe d'utilisateurs pour les objets de données », tous les groupes AD de l'utilisateur Active Directory recherchent exactement un groupe d'utilisateurs de données dans IDL.KONSIS qui contient ce groupe AD en tant que « groupe Active Directory ». Si aucun groupe d'utilisateurs IDL.KONSIS de ce type n'est trouvé, un message d'erreur s'affiche (Groupe d'utilisateurs de données introuvable). Si plusieurs groupes d'utilisateurs IDL.KONSIS de ce type sont trouvés, un message d'erreur s'affiche également (« Groupe d'utilisateurs de données non unique »).

4.3 Maintien des autorisations par groupe d'utilisateurs

Après avoir sélectionné un groupe d'autorisations pour les objets de données dans la table de tête, double-cliquez, cliquez avec le bouton droit de la souris et cliquez sur l'icône Ouvrir pour afficher les tables sous forme d'onglets par type d'objet pour lesquels des autorisations peuvent être accordées. Le titre de l'onglet affiche le nombre d'objets autorisés. La table de début disparaît automatiquement et la clé du groupe d'autorisations sélectionné apparaît dans la barre de navigation. Les objets pouvant être autorisés sont les suivants :

  • Groupe (KTK)
  • Sociétés (SOC)
  • Périodes (PER)
  • Type de données (DATTYP)
  • Plans de compte/contrôle de gestion (ACCDEF)
  • Plans de ligne (AGGDEF)
  • Inventaire liasse (RID)

En outre, si IDL.FORECAST est sous licence,

  • Scénarios
  • Nœuds/scénarios scénario
  • Règle de calcul modèles de la gamme

être autorisé en tant qu'objets.

Un autre onglet, Synthèse de toutes les autorisations d'objet, récapitule les objets autorisés, à l'exception des périodes et des objets IDL.FORECAST, et permet d'exporter ces informations.

Les tables par type d'objet affichent d'abord les objets autorisés, puis tous les objets non autorisés. Le menu contextuel (bouton droit de la souris) permet de déclencher les actions suivantes pour contrôler les autorisations :

  • Accorder une autorisation en lecture seule sur l'objet
  • Révoquer toutes les autorisations pour l'objet
  • Accorder toutes les autorisations pour l'objet

L'icône représentant un stylet dans le menu contextuel (bouton droit de la souris) permet de modifier une permission. L'assistant d'octroi de privilèges se compose de deux pages. La première page spécifie l'objet sélectionné et la seconde page permet d'exécuter les actions de chacun des objets de données

  • Affichage
  • Modifier
  • Coller
  • Effacer

être autorisé par la mise en place d’un crochet ou retiré par retrait du crochet.

Si IDL.FORECAST est sous licence, les scénarios disposent d'autorisations pour les actions

  • Affichage
  • Modifier
  • Effacer

et pour les modèles de calcul, l'action

  • Exécuter.

L'autorisation d'objet de copie est assurée par des vérifications des autorisations d'affichage des clés source et d'insertion des clés cible.

4.4 Exportation

Chaque zone est exportée à l'aide du bouton d'exportation de la barre de menus. La boîte de dialogue d'exportation vous permet de sélectionner la zone à exporter. Les volets Groupe d'utilisateurs, Autorisation d'objet et Autorisation de période sont disponibles. Sur le côté droit de la boîte de dialogue d'exportation vous devez sélectionner la zone désirée. Les sélections dans les tableaux sont prises en compte. Si des lignes sont sélectionnées dans une seule table, seules ces lignes sont exportées. Les tables non sélectionnées ne sont exportées (complètement) qu'en l'absence de sélection.

4.5 Attribution de privilèges à l'aide de l'Assistant

La navigation entre les pages de l'assistant s'effectue via les boutons <continuer>et <Précédent> en bas des pages de l'assistant ou via le répertoire de pages (barre de navigation) qui apparaît à gauche. Le répertoire de la page affiche une icône indiquant si les entrées d'une page sont correctes (crochet vert) ou erronées (panneau rouge). Le bouton <Terminé> apparaît sur chaque page. Toutefois, il est désactivé tant que l'enregistrement est incohérent ou incomplet. Si l'ensemble est correct, <Terminé> devient actif, quelle que soit la page en cours. Le bouton <continuer> n'est actif que si les informations de la page correspondante sont cohérentes et sans erreurs.

L'entrée de modification permet de savoir si une permission a déjà été attribuée à un objet.

Les droits sur les modèles de calcul peuvent également s'appliquer aux dossiers de l'application FOPLAN. Ces droits sont hérités des sous-dossiers et des modèles de calcul du dossier, sauf indication contraire aux niveaux inférieurs. Les droits hérités peuvent être modifiés individuellement.

Dans les applications intégrées telles que REPDEF, AGGDEF ou USEGRP, les autorisations d'insertion s'effacent uniquement à l'objet autorisé lui-même. Il suffit d'avoir l'autorisation de modifier pour insérer et effacer des données sur l'objet. Dans les applications RAPPLGN, AGGDEF, etc., les autorisations d'insertion et d'efface s'appliquent également aux objets associés (par exemple : Lignes de rapport d'un ID de liasse ou d'agrégations d'un plan de ligne).

4.6 Garantir l'efficacité des paramètres d'autorisation

Pour que les autorisations d'objet soient effectives pour un utilisateur, l'application USEADM (Préoccupation pour les utilisateurs protégés, voir ci-dessous ) fournit des commutateurs d'autorisation par utilisateur pour tous les types d'objet. Une fois que le commutateur est défini sur 2 ou 3, l'application vérifie si les autorisations d'objet appropriées sont disponibles pour modification.

5 Privilèges objet et période (USEOBJ, USEPER)

Pour afficher et tenir à jour les autorisations de données des groupes d'utilisateurs, il existe également, à titre provisoire, les applications Autorisations d'objet (USEOBJ) et Autorisations de période (USEPER) avec les applications de taux unitaires associées. Ces applications sont généralement similaires à l'application « Autorisations de menu » (USEMEN, voir ci-dessus. ) .

Par rapport à l'application USEGRP, USEOBJ et USEPER permettent d'afficher et de copier simultanément les autorisations de plusieurs groupes d'utilisateurs.

6 Présélection des données à indiquer (USEADM)

L'application USEADM complète la saisie des nouveaux utilisateurs qui ne peuvent travailler avec IDL.KONSIS.FORECAST que s'ils sont enregistrés ici.

Comme expliqué ci-dessus, l'accès à certains objets de données stockés dans l'application USEGRP par l'intermédiaire d'un groupe d'utilisateurs de données n'est effectif que si les paramètres correspondants sont stockés dans la présélection des données à indiquer de l'utilisateur concerné.

A cet effet, les champs de paramètres supplémentaires pour les champs clés groupe/sous-groupe société, ⎜, Période, type de données, Position et plan comptable ainsi que l'ID de liasse sont pertinents.

Les actions <régénérer les données> et <modifier les données> permettent d'accéder à l'application de taux unique (VORADMINE). Les options de saisie suivantes pour la protection contre les substitutions et les autorisations (dans les champs de saisie prévus à cet effet, après les objets pré-alloués) sont disponibles :

CléAutorisation
0 pour groupe société, 0, Période et type de donnéesEntrée uniquement lt. AVANT
0 pour l'ID plan d'agrégations, compte/plan analytique et liasseAucune modification autorisée
1Autoriser toutes les entrées et modifications
2Autorisation lt. APPLICATION USEGRP
3 pour les périodesComme 2 avec le droit supplémentaire de créer une nouvelle liasse unique pour les périodes clôturées
3 pour les plans de compte/contrôlePlan comptable groupe Comme 2 sans le droit de modifier le rattachement à l'e.
3 pour les sociétésComme 2, où seul l'plan analytique peut être modifié dans les données de base de la société

Si l'option de remplacement a la valeur 0, il est garanti que toutes les applications ne permettent pas d'entrer des entrées différentes selon le système PDV. Il s'agit d'éviter les saisies erronées sous un concept-clé incorrect pendant le traitement en cours. En revanche, l'option de substitution 1 permet une navigation rapide avec des clés variables.

Les cellules monnaie groupe et monnaie parallèle ne peuvent être définies et modifiées que par l'intermédiaire de l'application USEADM. Ils sont utilisés comme codes monétaires pour les nouvelles bases de données lorsqu'aucun groupe / sous-groupe n'est fourni. Pour ces cellules, ainsi que pour le groupe-plan comptable, un contrôle est effectué contre les inscriptions dans le groupe / sous-groupe ci-dessus.

Les autres champs d'entrée peuvent également être gérés par chaque utilisateur dans l'application présélection des données à indiquer par utilisateur (PDV).

Dans une application de maintenance de présélection des données à indiquer (PDV, USEADM), si la langue de l'utilisateur est modifiée, une personnalisation est automatiquement effectuée dans la table utilisateurs (USE).

6.1 Données de la première présélection des données à indiquer

Après l'installation initiale d'IDL.KONSIS.FORECAST, le tableau Avant ou USEADM n'a pas encore d'entrées, de nombreuses applications IDL Konsis ne peuvent donc pas être lancées en raison de l'absence de spécification d'autorisations. Le premier taux d'occupation préalable suppose toutefois qu'il existe déjà des premières données permanentes (par exemple : Société ♥, période, type de données) à l'entrée dans la présélection des données à indiquer. La mise en place de ces données permanentes est complexe en raison des différentes dépendances.

L'application « Données de première présélection des données à indiquer » (VORINITE) simplifie ce processus. Cette application est lancée en remplacement de l'application répétitive standard (VORADMINE) si vous souhaitez passer de l'aperçu USEADM à l'application répétitive associée et que vous ne disposez d'aucune entrée dans cette table.

Le masque affiché dans VORINITE contient des champs d'entrée pour toutes les données permanentes requises pour une première présélection des données à indiquer. Dans de nombreux cas, ces cellules ont déjà fait l'objet d'une proposition (par exemple : Groupe société = 'MONDE',☐ = '001'). Ceux-ci peuvent être maintenus ou modifiés selon les besoins. Il est également possible d'effacer ces données permanentes plus tard, une fois que les données réelles ont été conservées.

Le bouton <Insertion> crée les données permanentes ainsi définies et un jeu de pré-occupation pour l'utilisateur connecté, ce qui permet à toutes les applications d'IDL Konsis de démarrer facilement.

7 Enregistrement des modifications (LOG)

Le module Suivi des modifications est un module complémentaire payant que vous pouvez obtenir sur demande.

Pour documenter et analyser les changements apportés aux données décrites dans cette documentation, vous pouvez utiliser les tableaux suivants pour obtenir une vue d'ensemble :

  • UTILISATEUR : LOGUSE
  • PRÉSÉLECTION DES DONNÉES À INDIQUER : LOGPDV
  • Autorisations du menu : LOGUSEMEN
  • Autorisations de l'objet de données (masquer. périodes) : LOGUSEOBJ
  • Autorisations de la période : LOGUSEPER

Ces résumés affichent les jeux de journaux, permettent une sélection en fonction des attributs principaux (semblables à la vue d'ensemble des données maîtres) et en plus des demandes par type (insertion, modification, effacée) et par moment de modification. Ainsi, toutes les modifications peuvent être sélectionnées à partir d'un moment donné, ou encore l'état de la table originale à un moment donné.

Pour activer la journalisation, saisissez (ou sélectionnez dans la liste déroulante) le nom de la table dans l'application Contrôle de la journalisation des données maîtres (LOG) et sélectionnez l'action Activer la journalisation des données maîtres. Cette action copie l'état actuel de la table spécifiée dans la table de journal. L'activation ne doit pas connecter d'autres utilisateurs à la base de données. Toutes les modifications apportées à cette table sont ensuite consignées dans la table des journaux.

Lorsque vous modifiez la langue utilisateur dans l'application PDV ou USEADM, cette modification est également enregistrée comme modification dans la table USE, bien qu'aucune modification active n'ait été entrée dans cette table.

Cet article vous a-t-il été utile ?

We're sorry to hear that.