Configurer le Chart of Accounts

Bonne réponse : C, D

Pourquoi cette question existe — STU §2.1 — la question teste la compréhension du double point d'entrée pour la configuration GL : un point « métier » (Chart of Accounts) et un point « technique » (Database Configuration). Les distracteurs citent des applications de coût/budget réelles mais qui consomment les comptes GL sans en configurer la structure. En pratique, modifier la longueur d'un composant GL après le go-live impose de repasser par ces deux applications, jamais par Cost Management ou Budget Monitoring.

Le contexte théorique d'abord — Un GL Account est composé de segments (composants) dont le nombre et la longueur sont définis au niveau Organisation. Chart of Accounts permet de définir les comptes généraux et de configurer les règles autour des composants GL ; Database Configuration porte l'objet DMDEFGLCONFIGURE, qui gère la configuration et la longueur de la définition du general ledger au niveau base de données.

Ce que Maximo en fait — version opérationnelle — Dans Chart of Accounts, l'administrateur définit le masque GL (composants et séparateurs). Pour modifier la longueur d'un composant déjà utilisé, il doit passer par Database Configuration sur l'objet DMDEFGLCONFIGURE, puis relancer une configuration de base de données (Admin Mode requis).

Exemple chiffré — Un masque GL à 4 composants (ex. 6-3-4-2 caractères) totalisant 15 caractères peut être étendu à 18 caractères en modifiant un seul composant de 4 à 7, mais cette opération nécessite la reconfiguration de la base sur potentiellement plusieurs millions d'enregistrements transactionnels existants.

Analogie quotidienne — C'est comme changer le format d'un numéro de téléphone national : il faut à la fois mettre à jour la règle officielle (Chart of Accounts) et reconfigurer le système technique qui valide ce format (Database Configuration).

Pourquoi A est faux — Pattern D5 champ-frère : Configure Field Types évoque un concept de configuration générique mais n'est pas le nom d'une application Maximo réelle pour la structure GL.

Pourquoi B est faux — Pattern D6 mauvaise-app : Cost Management consomme les comptes GL pour la ventilation des coûts, mais n'est jamais le lieu où l'on modifie la structure des composants.

Pourquoi E est faux — Pattern D6 mauvaise-app : Budget Monitoring consomme également les comptes GL comme focal point, sans pouvoir modifier leur structure.

Bonne réponse : A, C

Pourquoi cette question existe — STU §2.1 — cette question vérifie la connaissance du cycle de vie d'un enregistrement Budget, dont la terminologie ne suit pas exactement celle des Work Orders. Les distracteurs proposent des codes plausibles dans l'esprit Maximo (WSTART, PAUSED, EXPIRD) mais qui ne sont pas des statuts réels du module Budget Monitoring. En pratique, confondre ces statuts bloque l'édition d'un budget cru encore modifiable.

Le contexte théorique d'abord — Un enregistrement Budget transite par un nombre restreint de statuts : il démarre en DRAFT (entièrement modifiable, y compris le montant budgété), passe par l'approbation jusqu'à APPR (Approved), puis se termine en CLOSED. Une fois en statut APPR, le budget ne peut transitionner que vers CLOSED — il n'existe pas de statut intermédiaire de pause ou d'expiration.

Ce que Maximo en fait — version opérationnelle — Dans Budget Monitoring, l'action Change Status propose les transitions valides du cycle de vie. Tant que le budget est en DRAFT, le champ Budgeted Amount reste éditable ; dès APPR, ce champ devient read-only, jusqu'à CLOSED qui clôture définitivement le suivi budgétaire.

Exemple chiffré — Un budget annuel de 500 000 $ passe en DRAFT à sa création, puis en APPR après validation par le contrôleur financier ; il reste en APPR pendant les 12 mois de l'année fiscale avant de passer en CLOSED, soit 1 seul cycle complet DRAFT → APPR → CLOSED par exercice.

Analogie quotidienne — C'est comme un devis de rénovation : en brouillon (DRAFT) on peut tout changer, une fois signé (APPR) le montant est figé, et une fois les travaux terminés et payés (CLOSED) le dossier est définitivement archivé.

Pourquoi B est faux — Pattern D2 inventé : « WSTART » ne figure dans aucune documentation IBM comme statut de Budget Monitoring.

Pourquoi D est faux — Pattern D2 inventé : « PAUSED » n'existe pas dans le cycle de vie d'un Budget ; il n'y a pas de statut intermédiaire de pause.

Pourquoi E est faux — Pattern D2 inventé : « EXPIRD » n'est pas un statut Maximo standard ; les budgets se ferment via CLOSED, pas par expiration automatique.

Bonne réponse : A

Pourquoi cette question existe — STU §2.1 — cette question distingue le niveau où le montant budgété est réellement saisi (Budget Line) des autres fenêtres satellites du Budget Monitoring qui paramètrent la logique de suivi (Focal Points, Rules) sans jamais contenir de saisie de montant. En pratique, chercher le montant budgété dans Manage Rules ou Focal Points fait perdre un temps précieux en configuration.

Le contexte théorique d'abord — Le Budget Line est la fenêtre de détail (table window) sur laquelle reposent les 66 attributs de coût/heure/pourcentage du Budget Monitoring, répartis en estimé, engagé et réel pour la main d'œuvre, le matériel, les services et les outils. C'est dans cette fenêtre que les 12 champs de la colonne budget sont saisis manuellement ou calculés en totaux.

Ce que Maximo en fait — version opérationnelle — Dans Budget Monitoring, l'utilisateur ouvre un enregistrement Budget en statut DRAFT, descend dans la table window Budget Line, et saisit le montant budgété par ligne (par focal point, par période). Les Focal Point et Manage Rules servent uniquement à définir respectivement l'axe de suivi et les seuils d'alerte, jamais la saisie du montant lui-même.

Exemple chiffré — Un Budget Line pour le focal point « Site BEDFORD » peut porter un montant budgété de 120 000 $ pour le 1er trimestre, réparti en 80 000 $ de main d'œuvre et 40 000 $ de matériel, avant tout engagement réel.

Analogie quotidienne — C'est comme un tableau Excel de prévisionnel familial : la ligne « budget courses du mois » est là où l'on inscrit le montant prévu, alors que les règles de catégorisation (alimentaire, loisirs) ne sont que la structure autour, pas la saisie elle-même.

Pourquoi B est faux — Pattern D5 champ-frère : le Focal Point définit l'axe sur lequel le suivi budgétaire est organisé (site, asset, compte GL), pas le montant budgété lui-même.

Pourquoi C est faux — Pattern D6 mauvaise-app : Manage Rules configure les seuils et conditions d'alerte du contrôle budgétaire, sans champ de saisie de montant.

Pourquoi D est faux — Pattern D5 champ-frère : Conditional Expression Manager permet de visualiser/éditer les conditions des règles budgétaires, un outil de configuration distinct de la saisie du montant.

Bonne réponse : A, D

Pourquoi cette question existe — STU §2.1 — variante de reformulation (options réordonnées) de la question jumelle de cette leçon, testant la même paire d'applications de configuration GL : Chart of Accounts (niveau métier) et Database Configuration (niveau technique, objet DMDEFGLCONFIGURE), par opposition aux applications financières qui consomment les comptes GL sans en configurer la structure.

Le contexte théorique d'abord — Le masque GL (composants et longueurs) se configure dans Chart of Accounts au niveau métier, et toute modification de la longueur d'un composant déjà utilisé nécessite de passer par Database Configuration sur l'objet DMDEFGLCONFIGURE, avec relance d'une configuration de base de données.

Ce que Maximo en fait — version opérationnelle — Dans Chart of Accounts, définir les composants et séparateurs du masque GL. Pour modifier une longueur déjà en production, passer par Database Configuration sur DMDEFGLCONFIGURE, puis relancer la configuration de base (Admin Mode requis).

Exemple chiffré — Un masque GL à 4 composants totalisant 15 caractères peut être étendu à 18 caractères en modifiant un seul composant de 4 à 7, nécessitant une reconfiguration de base sur potentiellement plusieurs millions d'enregistrements existants.

Analogie quotidienne — C'est comme changer le format d'un numéro de téléphone national : il faut mettre à jour la règle officielle (Chart of Accounts) et reconfigurer le système technique qui valide ce format (Database Configuration).

Pourquoi B est faux — Pattern D6 mauvaise-app : Cost Management consomme les comptes GL pour la ventilation des coûts, sans pouvoir modifier leur structure.

Pourquoi C est faux — Pattern D5 champ-frère : Configure Field Types évoque un concept de configuration générique, pas une application réelle pour la structure GL.

Pourquoi E est faux — Pattern D6 mauvaise-app : Budget Monitoring consomme les comptes GL comme focal point, sans pouvoir modifier leur structure.