Tableau de bord/Chapter 2/1.2 — Configurer les Currencies et Exchange Rates
Chapter 2 · leçon 2 sur 3
La gestion des devises dans Maximo est une fonctionnalité fondamentale qui assure l'intégrité financière des opérations d'achat et de gestion des stocks. Elle repose sur une architecture centralisée qui permet de définir les devises, leurs taux de conversion et de les appliquer de manière cohérente à travers les différentes applications transactionnelles.
Cette architecture est cruciale pour les entreprises opérant dans un contexte international, où les transactions avec des fournisseurs ou des filiales peuvent impliquer diverses monnaies. Maximo garantit que toutes les valeurs sont correctement converties en devise de base de l'organisation pour les rapports et l'analyse financière.
Plusieurs applications Maximo collaborent pour une gestion complète des devises. Chacune a un rôle distinct, allant de la simple définition des codes à l'administration complexe des taux de change et à l'application aux transactions financières.
Comprendre la fonction spécifique de chaque application est essentiel pour configurer correctement le système et assurer l'exactitude des données financières, en particulier dans un environnement multi-devises.
| Application Maximo | Fonctionnalité principale | Niveau d'application | Impact sur les transactions |
|---|---|---|---|
Currency Codes | Définition et gestion des codes de devise (ex: EUR, USD, JPY). | Global | Prépare les devises pour utilisation dans le système. |
Organizations | Spécification de la devise de base pour chaque organisation. | Organisation | Détermine la devise de référence pour tous les calculs financiers internes. |
Exchange Rates | Configuration et administration des taux de change entre les devises pour des périodes définies. | Organisation | Permet la conversion des coûts des transactions étrangères en devise de base. |
Purchase Requisitions | Utilisation du champ `Currency` pour les demandes d'achat en devises étrangères. | Organisation/Site | Permet l'enregistrement des demandes d'achat avec leur devise spécifique. |
Purchase Orders | Utilisation du champ `Currency` pour les bons de commande en devises étrangères. | Organisation/Site | Permet l'enregistrement des bons de commande avec leur devise spécifique. |
Invoices | Utilisation du champ `Currency` pour les factures en devises étrangères. | Organisation/Site | Permet l'enregistrement des factures avec leur devise spécifique. |
Companies | Association d'une devise par défaut à un fournisseur ou une entreprise. | Organisation | Simplifie la saisie des devises pour les transactions récurrentes avec des entités spécifiques. |
La configuration des devises et des taux de change est une étape essentielle pour toute implémentation de Maximo, surtout dans un environnement commercial international. Elle garantit que les coûts sont correctement suivis et rapportés, quel que soit le pays d'origine de la transaction.
Une configuration précise évite les erreurs de calcul et assure la conformité avec les normes comptables. Le processus implique plusieurs étapes logiques, depuis la définition des devises jusqu'à l'établissement des taux de conversion.
Chaque organisation peut avoir sa propre devise de base, ce qui permet une grande flexibilité pour les entreprises avec des structures complexes ou des filiales dans différents pays. Les taux de change doivent être régulièrement mis à jour pour refléter les fluctuations du marché.
Par exemple, une entreprise basée en France (devise de base EUR) commande des pièces à un fournisseur américain. Lors de la création du `Purchase Order`, la devise est définie sur USD. Si le taux de change est de 1 EUR = 1.08 USD, un coût de 1000 USD sera automatiquement converti en 925.93 EUR pour les enregistrements internes et les rapports financiers.
Il est crucial de maintenir les taux de change à jour. Maximo permet de définir des périodes de validité pour chaque taux, assurant que le système utilise toujours le taux correct au moment de la transaction. Des processus automatisés via `Cron Task` peuvent être mis en place pour importer régulièrement les taux de change depuis des sources externes.
Le cycle de vie d'une transaction en devise étrangère dans Maximo illustre comment le système gère la conversion des coûts depuis la demande d'achat jusqu'à la facturation. Ce processus garantit la cohérence des données financières et la précision des rapports, même lorsque plusieurs devises sont impliquées.
Chaque étape du processus est conçue pour capturer la devise correcte et appliquer le taux de change approprié, assurant ainsi une visibilité complète sur les coûts réels en devise de base de l'organisation.
Le processus commence par la définition des devises et la configuration des taux de change. Ensuite, lorsqu'une `Purchase Requisition` est créée, la devise de la transaction est spécifiée. Cette information est ensuite reportée sur le `Purchase Order` correspondant. Au moment de l'enregistrement de la `Invoice`, Maximo utilise le taux de change actif pour la période concernée afin de convertir le montant en devise étrangère en devise de base de l'organisation.
Cette conversion est transparente pour l'utilisateur mais fondamentale pour la comptabilité et l'analyse financière. Elle permet aux responsables de suivre les dépenses et les budgets dans une devise unique, simplifiant ainsi la gestion financière globale.
Il est important de noter que les taux de change sont dynamiques. Maximo permet de gérer cette dynamique en associant des dates de validité aux taux, garantissant que le système applique toujours le taux correct au moment de la transaction, et non au moment de la configuration initiale.
Les utilisateurs peuvent oublier de mettre à jour les taux de change dans l'application `Exchange Rates` ou ne pas définir de taux pour toutes les paires de devises nécessaires. Lors de la création d'un `Purchase Order` ou d'une `Invoice` en devise étrangère, Maximo pourrait alors utiliser un taux incorrect ou ne pas pouvoir effectuer la conversion, entraînant des erreurs dans les calculs de coût en devise de base. L'examen peut présenter un scénario où une transaction est effectuée avec un taux de change non valide ou manquant.
Les candidats peuvent confondre la devise de base de l'organisation (définie dans `Organizations`) avec la devise de la transaction (spécifiée dans `Purchase Requisitions`, `Purchase Orders`, `Invoices`). La devise de base est la devise de référence interne de l'entreprise, tandis que la devise de transaction est celle utilisée avec le fournisseur. Maximo effectue toujours la conversion vers la devise de base pour les rapports internes, même si la transaction est enregistrée dans une autre devise. Un piège courant est de penser que le coût affiché dans une application transactionnelle est toujours le coût final pour l'entreprise sans conversion.
Tenter de supprimer un code de devise dans l'application `Currency Codes` sans vérifier ses dépendances peut entraîner des erreurs système. Si une devise est toujours utilisée dans des enregistrements historiques (par exemple, d'anciens `Purchase Orders` ou `Invoices`), ou si elle est définie comme devise de base pour une organisation, sa suppression directe sera bloquée ou causera des incohérences. L'examen pourrait poser une question sur les prérequis avant de supprimer une devise, testant la compréhension des dépendances de données.
Une erreur fréquente est de ne pas comprendre que la devise de base est définie au niveau de l'Organization, tandis que les codes de devise sont gérés globalement. Cela peut conduire à des tentatives de configuration incorrectes ou à des attentes erronées concernant l'héritage des devises. Les taux de change sont également spécifiques à l'Organization. L'examen peut présenter des scénarios où une devise est configurée à un niveau inapproprié, affectant sa disponibilité ou son comportement.
La devise de base d'une organisation est spécifiée dans l'application Organizations. C'est une configuration essentielle qui détermine la devise de référence pour tous les calculs et rapports financiers internes de cette organisation.
CertaviaPurchase Orders émis en devises étrangères ?
Lorsqu'un Purchase Order est émis en devise étrangère, Maximo utilise le taux de change actif défini dans l'application Exchange Rates pour la période concernée. Il calcule et enregistre le coût équivalent en devise de base de l'organisation pour les besoins de reporting et de comptabilité interne.
Currency pour les transactions d'achat ?
Les applications principales qui contiennent un champ Currency pour les transactions d'achat sont Purchase Requisitions, Purchase Orders, Invoices et Companies. Ce champ permet de spécifier la devise dans laquelle la transaction est effectuée.
Avant de supprimer un code de devise, il est impératif de vérifier qu'il n'est plus utilisé dans aucune transaction active ou historique, ni comme devise de base pour une organisation. La suppression d'une devise en cours d'utilisation peut entraîner des erreurs et des incohérences de données dans le système.
Maximo assure l'exactitude des taux de change en permettant de définir des périodes de validité (dates de début et de fin) pour chaque taux dans l'application Exchange Rates. Le système sélectionne automatiquement le taux approprié en fonction de la date de la transaction, garantissant ainsi la cohérence historique et future des conversions.
Oui, il est possible d'avoir plusieurs taux de change pour la même paire de devises dans Maximo. Cela est géré par la définition de périodes de validité distinctes pour chaque taux dans l'application Exchange Rates. Maximo utilise le taux dont la période de validité englobe la date de la transaction.
Bonne réponse : B
Pourquoi cette question existe — STU §2.2 — la question teste la compréhension de la gestion des taux de change dans Maximo Manage 9.x. Les taux de change sont essentiels pour les transactions internationales et doivent être correctement configurés par organisation. Les distracteurs montrent des erreurs typiques : confondre la monnaie de base avec les taux de change (D4), citer des applications non pertinentes (D7), ou ignorer la nécessité de l'application Exchange Rates (D9).
Le contexte théorique d'abord — Les taux de change sont utilisés pour convertir les montants entre différentes devises dans les transactions internationales. Dans Maximo, les devises sont définies dans l'application Currency Codes, tandis que les taux de change sont gérés dans l'application Exchange Rates. Ces taux sont spécifiques à chaque organisation et peuvent être définis pour des périodes spécifiques.
Ce que Maximo en fait — version opérationnelle — Pour configurer les taux de change, accédez à l'application Exchange Rates > Add New Rate > sélectionnez la devise source et la devise cible, puis définissez le taux de change et la période de validité. Les taux sont ensuite appliqués automatiquement dans les applications comme Purchase Orders et Invoices lors des transactions en devises étrangères.
Exemple chiffré — Organisation FRANCE : taux EUR/USD = 1.10 pour la période du 01/01/2024 au 31/12/2024. Organisation USA : taux USD/EUR = 0.91 pour la même période. Organisation UK : taux GBP/EUR = 1.17. Ces taux sont utilisés pour convertir les montants dans les transactions internationales.
Analogie quotidienne — C'est comme un tableau de change dans une banque : chaque devise a son taux de conversion, et ces taux sont mis à jour régulièrement pour refléter les fluctuations du marché.
Pourquoi A est faux — Pattern D4 demi-vérité : l'application Organizations permet de définir la monnaie de base, mais ne gère pas les taux de change.
Pourquoi C est faux — Pattern D7 inexistant : Chart of Accounts est une application de comptabilité, mais elle ne gère pas les taux de change.
Pourquoi D est faux — Pattern D9 quasi-synonyme : Financial Rate Book n'existe pas dans Maximo, c'est une confusion avec Exchange Rates.
Bonne réponse : C
Pourquoi cette question existe — STU §2.2 — cette question évalue la compréhension des mécanismes multi-devises dans Maximo, en particulier l'utilité des deux devises de base (Base Currency 1 et 2) au niveau Organisation. Les distracteurs ciblent les confusions courantes entre paramétrage par site (D5), automatisation UI (D2) et restrictions par rôle (D10). En contexte multinational, cette fonction est critique pour les reporting financiers consolidés.
Le contexte théorique d'abord — Les organisations multinationales doivent souvent gérer deux référentiels monétaires : une devise locale (pour les opérations courantes) et une devise de reporting (souvent USD/EUR). Maximo permet cela via deux champs dans ORGANIZATIONS : BASECURRENCY (devise 1) et BASECURRENCY2 (devise 2). Les taux de conversion historiques sont stockés dans EXCHANGERATES avec leurs dates d'application.
Ce que Maximo en fait — version opérationnelle — Dans Organizations app, onglet Financial : saisir EUR dans BASECURRENCY (devise locale) et USD dans BASECURRENCY2. Les transactions (ex: PO, INVOICE) calculent automatiquement les deux montants via EXCHANGERATES. Le taux actif est celui dont la date est ≤ date transaction.
Exemple chiffré — Organisation FRANCE : BASECURRENCY=EUR, BASECURRENCY2=USD. Le 15/01/2024, taux EUR/USD=1.12. Une facture de 10 000€ génère un montant reporting de 11 200$. Si le taux passe à 1.08 le 20/01, une nouvelle facture de 10 000€ = 10 800$.
Analogie quotidienne — Comme un compte bancaire offshore qui affiche simultanément le solde en devise locale et en dollars, avec conversion actualisée chaque jour.
Pourquoi A est faux — Pattern D5 champ-frère : la devise par site se configure dans SITES.CURRENCY, pas via les devises de base de l'org.
Pourquoi B est faux — Pattern D2 inventé : Maximo n'auto-adapte jamais l'affichage des devises selon la locale utilisateur.
Pourquoi D est faux — Pattern D10 procédure-plausible : les rôles n'ont aucun lien avec la sélection de devise, qui relève de la configuration organisationnelle.
Bonne réponse : B,C
Pourquoi cette question existe — STU §2.2 — cette question teste la compréhension de la gestion des taux de change dans Maximo Manage, un élément clé pour la gestion des coûts et des budgets dans un contexte multi-devises. Les distracteurs montrent les erreurs typiques : confondre la récupération des taux (D2), ignorer la configuration par organisation (D4), et inventer des comportements non supportés (D10). En pratique terrain, l'omission de la date effective est une erreur fréquente.
Le contexte théorique d'abord — Les taux de change dans Maximo sont définis dans l'application Currency et sont associés à une date effective. Maximo utilise le dernier taux actif à ou avant la date de la transaction pour les conversions. Les taux expirés restent dans la table EXCHANGERATE pour des raisons d'audit et de réévaluation historique.
Ce que Maximo en fait — version opérationnelle — Dans l'application Currency, ajouter un nouveau taux avec une date effective spécifique. Maximo sélectionne automatiquement le taux actif le plus récent à ou avant la date de la transaction. Les taux expirés sont conservés dans la table EXCHANGERATE pour permettre des réévaluations historiques et des audits.
Exemple chiffré — Un taux de change EUR/USD est défini le 01/01/2023 avec une valeur de 1.10. Le 15/01/2023, un nouveau taux est défini à 1.12. Une transaction du 10/01/2023 utilise le taux de 1.10, tandis qu'une transaction du 20/01/2023 utilise le taux de 1.12. Les deux taux restent dans la table pour audit.
Analogie quotidienne — C'est comme un calendrier de prix dans un supermarché : le prix actif est celui en vigueur à la date d'achat, mais les anciens prix restent dans les archives pour vérification.
Pourquoi A est faux — Pattern D2 Inventé : Maximo ne repull pas les taux à chaque sauvegarde de WO ; il utilise les taux déjà définis dans la table EXCHANGERATE.
Pourquoi D est faux — Pattern D4 Demi-vérité : Les taux peuvent être configurés par organisation via le champ ORGID dans la table EXCHANGERATE.
Pourquoi E est faux — Pattern D10 Procédure-plausible : Maximo n'utilise pas de triangulation par défaut ; il convertit directement entre les devises.
ORGID.Bonne réponse : A
Pourquoi cette question existe — STU §2.2 — cette question vérifie la compréhension du mécanisme de revalorisation des coûts en inventaire lors d'un changement de taux de change. L'enjeu terrain est crucial : éviter les écarts comptables tout en préservant l'historique des coûts. Le piège récurrent est de croire que Maximo recalcule automatiquement tous les stocks existants (D3) ou qu'une action manuelle globale existe (D2).
Le contexte théorique d'abord — Maximo gère deux types de coûts pour les items en stock : coût historique (valeur d'origine, conservée dans INVCOST.UNITCOST) et coût courant (calculé via le dernier taux de change dans CURRENCYEXCHANGE). La table INVBALANCES stocke les quantités physiques, tandis que INVCOST gère la valorisation monétaire par lot.
Ce que Maximo en fait — version opérationnelle — Dans Currency Exchange Rates, l'admin modifie le taux EUR/USD de 1.10 à 1.15. Les nouveaux reçus (via Receiving app) utilisent ce nouveau taux pour calculer leur UNITCOST. Pour revaloriser les stocks existants, l'admin doit lancer manuellement Adjust Inventory Costs en spécifiant les items concernés et le pourcentage d'ajustement.
Exemple chiffré — Stock initial : 500 unités à 110€ (taux 1.10). Nouveau taux : 1.15 → nouveaux reçus valorisés à 115€. Après 3 mois : 200 unités anciennes (110€) + 300 nouvelles (115€). L'ajustement manuel sur les 200 anciennes appliquerait +4.54% (1.15/1.10) pour aligner à 115€.
Analogie quotidienne — Comme un compte épargne en devises : les dépôts antérieurs gardent leur valeur historique, seuls les nouveaux versements bénéficient du taux du jour. Un relevé manuel est nécessaire pour recalculer l'ensemble.
Pourquoi B est faux — Pattern D2 Inventé : Aucune action "Reprice All Storerooms" n'existe dans l'application Inventory.
Pourquoi C est faux — Pattern D3 Inverse : Les POs ouverts restent valides avec leur taux contractuel, seul le matching invoice/receipt utilisera le nouveau taux.
Pourquoi D est faux — Pattern D7 Inexistant : Maximo ne recharge jamais le Chart-of-Accounts pour des ajustements de taux de change.
Bonne réponse : C
Pourquoi cette question existe — STU §2.2 — cette question teste la compréhension de la méthode de coût par défaut dans Maximo Manage pour les nouveaux ensembles d'articles. Les distracteurs montrent les erreurs typiques : confondre FIFO et LIFO (D3), ignorer la méthode de coût moyenne mobile (D4), et proposer une méthode non standard (D2). En pratique terrain, la méthode de coût moyenne mobile est essentielle pour une gestion précise des coûts d'inventaire.
Le contexte théorique d'abord — La méthode de coût moyenne mobile (Average Cost) calcule le coût moyen des articles en fonction des entrées et sorties d'inventaire. Cette méthode est particulièrement utile pour les articles dont le coût fluctue fréquemment. Elle diffère de FIFO (First In, First Out) et LIFO (Last In, First Out), qui suivent un ordre spécifique d'utilisation des articles. La méthode de coût standard pondéré (Weighted Standard Cost) n'est pas une méthode native de Maximo.
Ce que Maximo en fait — version opérationnelle — Dans l'application Item Master, lors de la création d'un nouvel article, le champ COSTMETHOD est automatiquement défini sur AVERAGE. Ce paramètre peut être modifié dans Admin Mode si nécessaire. Les coûts sont ensuite calculés automatiquement en fonction des transactions d'inventaire, en utilisant la formule : (Total Cost / Total Quantity).
Exemple chiffré — Un article avec 3 entrées d'inventaire : 100 unités à 10€, 200 unités à 12€, et 150 unités à 11€. Le coût moyen mobile est calculé comme suit : (100*10 + 200*12 + 150*11) / (100 + 200 + 150) = 11.22€. Après une sortie de 300 unités, le coût moyen reste à 11.22€ pour les 150 unités restantes.
Analogie quotidienne — C'est comme calculer le prix moyen d'un panier de courses : chaque nouvel achat modifie le prix moyen des articles déjà dans le panier, mais le prix moyen reste une référence stable pour décider des achats futurs.
Pourquoi A est faux — Pattern D3 inverse : FIFO est une méthode de coût valide, mais elle n'est pas la méthode par défaut dans Maximo.
Pourquoi B est faux — Pattern D2 inventé : LIFO n'est pas une méthode de coût supportée par défaut dans Maximo.
Pourquoi D est faux — Pattern D4 demi-vérité : Weighted Standard Cost est une méthode de coût plausible, mais elle n'est pas native de Maximo et nécessiterait une configuration complexe.
Bonne réponse : B
Pourquoi cette question existe — STU §2.2 — cette question vérifie la maîtrise de la configuration des taxes dans Maximo, un point critique pour les implémentations multi-fiscalités. Le piège courant est de chercher cette fonctionnalité dans des applications dédiées aux taxes (D6) plutôt que dans les options d'organisation. En pratique, 78% des erreurs de configuration fiscale proviennent d'un mauvais paramétrage de la hiérarchie de défaut.
Le contexte théorique d'abord — Maximo gère jusqu'à 5 types de taxes (Tax 1 à Tax 5) configurables par organisation. Chaque type (ex: TVA, GST) peut avoir plusieurs codes (ex: MA 5%, QC 9.975%) stockés dans TAXCODES. La hiérarchie de défaut détermine l'ordre d'application des codes fiscaux dans PR/PO/Invoice, avec priorité aux règles les plus spécifiques.
Ce que Maximo en fait — version opérationnelle — Dans Organizations app > sélectionner une organisation > More Actions > Purchasing Options > Tax Options. Activer les types nécessaires (ex: Tax 1=ON pour VAT, Tax 2=ON pour GST). Définir l'ordre de défaut (ex: 1. Item Master 2. Commodity Group 3. Site par défaut). Sauvegarder → les modifications s'appliquent immédiatement aux nouveaux documents.
Exemple chiffré — Organisation ACME : Tax 1 (VAT) activée avec 3 codes (STANDARD=20%, REDUCED=10%, ZERO=0%). Tax 2 (GST) activée avec 2 codes (QC=9.975%, ON=13%). Hiérarchie configurée pour tenter d'abord le code Item (75% des cas), puis Commodity (20%), enfin Site (5%).
Analogie quotidienne — Comme un péage autoroutier avec plusieurs voies (types de taxes) et tarifs (codes) différents. Le système choisit automatiquement la voie appropriée en fonction de votre véhicule (type d'achat).
Pourquoi A est faux — Pattern D7 Inexistant : Il n'existe pas d'application "Tax Codes" dans Maximo, les codes fiscaux sont gérés via Organizations.
Pourquoi C est faux — Pattern D6 Mauvaise-app : Chart of Accounts configure les comptes GL, pas les types/codes fiscaux ni leur hiérarchie.
Pourquoi D est faux — Pattern D5 Champ-frère : Item Master permet de définir un code taxe par item, mais ne configure pas les types ni la hiérarchie globale.
Bonne réponse : B
Pourquoi cette question existe — STU §2.2 — cette question vérifie la compréhension des niveaux de segmentation des données dans Maximo, spécifiquement pour les enregistrements de sociétés (Companies). Les erreurs courantes incluent la confusion entre Company Set et Organization (D3), ou l'oubli que les Companies sont uniques au niveau Company Set. En pratique, cette distinction est cruciale pour la gestion multi-sites et la configuration des fournisseurs.
Le contexte théorique d'abord — Dans Maximo, les données sont segmentées à plusieurs niveaux : Enterprise > Organization > Site > Company Set. Les enregistrements de sociétés (Companies) sont stockés au niveau Company Set et sont uniques à ce niveau. Un Company Set peut être partagé par plusieurs organisations, mais chaque société doit être unique dans son Company Set. Les tables concernées sont COMPANIES et COMPANYSET.
Ce que Maximo en fait — version opérationnelle — Dans l'application Companies, les enregistrements sont créés et gérés au niveau Company Set. Pour ajouter une société : naviguer vers Companies > New, saisir les détails (nom, adresse, etc.), puis sélectionner le Company Set approprié. La société doit d'abord exister dans le Company Set avant de pouvoir être associée à une organisation via Organization > Companies.
Exemple chiffré — Un déploiement Maximo avec 3 Company Sets (CS1, CS2, CS3) et 5 organisations : CS1 contient 12 sociétés, CS2 en contient 8, et CS3 en contient 15. L'organisation ORG1 (liée à CS1) a accès à 12 sociétés, tandis que ORG3 (liée à CS2) n'a accès qu'à 8.
Analogie quotidienne — Imaginez un immeuble avec plusieurs étages (organisations) et des ascenseurs (Company Sets). Chaque ascenseur dessert des étages spécifiques, mais les boutons à l'intérieur (sociétés) sont les mêmes pour tous les étages qu'il dessert.
Pourquoi A est faux — Organization est un niveau de segmentation différent, utilisé pour d'autres types de données (ex. Assets, Work Orders). Les Companies ne sont pas stockées à ce niveau. (Pattern D3 Inverse).
Pourquoi C est faux — Site est un niveau plus granulaire que Company Set, utilisé pour des données comme les Locations ou les Assets. Les Companies ne sont jamais stockées au niveau Site. (Pattern D5 Champ-frère).
Pourquoi D est faux — "System" n'est pas un niveau de segmentation reconnu dans Maximo pour les données métier. (Pattern D7 Inexistant).
Bonne réponse : A,B
Pourquoi cette question existe — STU §2.2 — cette question vérifie la compréhension des prérequis monétaires pour les transactions multi-devises dans Maximo. Les organisations doivent déclarer leurs devises de référence (1 ou 2 selon la configuration) pour permettre les conversions automatiques. Les distracteurs ciblent les confusions courantes entre devises transactionnelles et référentielles (D3), et les features optionnelles mal interprétées comme obligatoires (D4, D7).
Le contexte théorique d'abord — Une organisation Maximo doit définir au minimum une Base Currency (devise de reporting principal) dans ORGANIZATION.BASECURRENCY. Si l'option de double-reporting est activée (paramètre système), BASECURRENCY2 devient obligatoire pour les états financiers parallèles. Les autres champs monétaires sont soit calculés (taux de change), soit optionnels (mapping subsidiaire).
Ce que Maximo en fait — version opérationnelle — Dans Organizations > onglet Financial : Base Currency 1 = EUR (obligatoire), Base Currency 2 = USD (si paramètre DUALCURRENCY=1). Les champs Transaction Currency Default et FX Index sont laissés vides ou configurés ultérieurement selon les besoins métier.
Exemple chiffré — Organisation FRANCE : Base 1 = EUR (taux 1.0), Base 2 = USD (taux 1.12). Commande de 50 000 USD → convertie en 44 643 EUR (50k/1.12) pour le reporting local. Sans Base 2, seule la conversion EUR serait disponible.
Analogie quotidienne — Comme déclarer sa monnaie nationale et une devise de voyage dans un aéroport : sans cette déclaration, le change ne peut pas fonctionner. La seconde devise (dollar) est utile mais pas obligatoire sauf si vous voyagez souvent.
Pourquoi C est faux — Pattern D3 inverse : Transaction Currency Default est une commodité pour pré-remplir les devises, pas un prérequis système. (Pattern D3 Inverse)
Pourquoi D est faux — Pattern D7 inexistant : Foreign Exchange Index n'est pas un champ obligatoire de l'organisation, mais un objet technique optionnel pour les calculs avancés. (Pattern D7 Inexistant)
Pourquoi E est faux — Pattern D4 demi-vérité : Subsidiary Currency Mapping existe bien mais sert aux filiales, pas au cœur des transactions multi-devises. (Pattern D4 Demi-vérité)
Correct: A, B, C
Pourquoi A, B, C — 3 transactions génèrent auto GL postings : (1) Inventory Issue — WO material consumption, crédit storeroom source + débit WO/asset via resource codes × Org GL settings, (2) Invoice Approval — AP recognition, crédit AP + débit expense/asset selon PO, (3) Tool Usage — tool time charged, débit WO + crédit tool account. Tous dans table GLTRANS, consommables interface AP/GL externe.
Pourquoi D est faux — D5 inverted direction : Asset creation ne génère aucun posting GL — c'est la depreciation schedule qui produit les entries, pas la création initiale.
Why E wrong — D4 adjacent : workflow task completion = event process (routing/approval/signoff), aucun impact comptable direct.
Why F wrong — D3 wrong scope : Person records = HR/identity (nom, email, craft), aucun lien comptabilité.