Tableau de bord/Chapter 5/1.3 — Réception, création PO et facturation
Chapter 5 · leçon 3 sur 3
CertaviaPurchase Orders pour générer un PO à partir des lignes d'une PR.Invoices pour importer les lignes d'un PO ou d'une réception dans une facture.Le processus d'approvisionnement dans Maximo Manage est une séquence structurée d'applications et d'actions, conçue pour optimiser la gestion des achats de biens et services. Il débute par une demande interne et se conclut par le paiement au fournisseur, en passant par des étapes de commande, de réception et de facturation. Cette architecture garantit une traçabilité complète et une conformité aux politiques d'achat de l'entreprise.
Chaque étape est gérée par une application dédiée, permettant une spécialisation des tâches et une meilleure maîtrise des données. L'intégration entre ces applications est fondamentale, car elle permet le transfert automatique d'informations et la validation croisée des données, réduisant ainsi les erreurs et les délais de traitement. La cohérence des données est assurée par des liens entre les enregistrements, tels que les numéros de PR, de PO et de facture.
| Application Maximo | Rôle principal | Actions clés | Impact sur le processus |
|---|---|---|---|
Purchase Requisitions | Création et approbation des demandes d'achat internes. | Créer PR, Approuver PR, Générer PO. | Initialise le besoin, consolide les demandes. |
Purchase Orders | Génération et gestion des bons de commande externes aux fournisseurs. | Copy PR Line Items to PO, Réviser PO, Approuver PO. | Formalise l'engagement d'achat, définit les termes. |
Receiving | Enregistrement de la réception physique des biens ou de la prestation des services. | Select Ordered Items, Select Ordered Services, Enregistrer réception. | Confirme la livraison, met à jour l'inventaire, permet la facturation. |
Invoices | Saisie et traitement des factures fournisseurs. | Copy PO Lines, Valider facture, Approuver facture. | Déclenche le processus de paiement, rapproche les coûts. |
La gestion opérationnelle de l'approvisionnement dans Maximo Manage est un processus séquentiel qui assure que les biens et services sont commandés, reçus et payés de manière efficace et conforme. Chaque étape est cruciale pour maintenir l'intégrité des données financières et d'inventaire.
Le processus débute souvent par une demande d'achat (PR) qui, une fois approuvée, est convertie en un ou plusieurs bons de commande (PO). Ces PO sont ensuite envoyés aux fournisseurs. À la réception des biens ou services, l'enregistrement précis dans Maximo est essentiel. Enfin, la facture du fournisseur est traitée, en la rapprochant des PO et réceptions correspondantes avant approbation pour paiement.
Purchase Requisitions, spécifiant les détails comme la quantité, la description, le site et l'organisation. Par exemple, une PR pour deux ordinateurs portables, un logiciel et des services de programmation (1000 heures chacun).Purchase Orders, l'action Copy PR Line Items to PO est utilisée pour transférer les lignes de la PR approuvée vers un nouveau PO. Plusieurs PO peuvent être créés à partir d'une seule PR si différents fournisseurs sont impliqués. Par exemple, un PO pour les ordinateurs, un autre pour le logiciel, et un troisième pour les services.Receiving est utilisée pour enregistrer la réception. L'utilisateur sélectionne le PO concerné, puis utilise les actions Select Ordered Items ou Select Ordered Services pour marquer les lignes comme reçues. Par exemple, la réception des deux ordinateurs et du logiciel.Invoices. L'action Copy PO Lines est utilisée pour importer les lignes du PO ou des réceptions correspondantes dans la facture. Cela permet de rapprocher la facture des commandes et des livraisons.ENTERED, APPROVED, PAID, suivent son cycle de vie.Le workflow de la facturation fournisseur est une étape critique du cycle d'approvisionnement, garantissant que les paiements sont effectués correctement et en temps voulu. Il implique plusieurs statuts de facture qui reflètent son avancement, de la création à l'approbation finale.
Ce processus assure la conformité financière et le rapprochement des dépenses avec les commandes et les réceptions. La capacité de Maximo à lier directement les factures aux bons de commande et aux enregistrements de réception est fondamentale pour l'audit et la gestion des coûts.
Un piège courant est de créer une facture dans l'application Invoices sans utiliser l'action Copy PO Lines pour lier les lignes de commande ou de réception. Cela peut entraîner des factures non rapprochées, des erreurs de paiement, et une difficulté à suivre les coûts réels par rapport aux commandes. Maximo est conçu pour l'intégration, et ignorer cette fonctionnalité brise la chaîne de traçabilité.
Lors de la réception d'articles ou de services, il est crucial de distinguer une réception partielle d'une réception complète. Si un PO de 100 unités est reçu en deux fois (50 puis 50), chaque réception doit être enregistrée séparément dans l'application Receiving. Ne pas le faire, ou enregistrer la totalité dès la première livraison partielle, peut fausser les niveaux d'inventaire et compliquer le rapprochement avec la facture finale qui pourrait arriver après la livraison complète.
Les unités de mesure (UoM) doivent être cohérentes tout au long du processus d'achat. Si un article est commandé en "paquets" mais reçu en "unités", ou si la facture utilise une UoM différente, cela peut entraîner des erreurs de quantité et de coût lors du rapprochement. Maximo permet de définir des UoM spécifiques, mais la vigilance est de mise lors de la saisie et de la vérification des données à chaque étape.
L'action clé est Copy PR Line Items to PO, disponible dans l'application Purchase Orders. Elle permet de transférer les détails des lignes de la PR vers un nouveau PO, assurant ainsi la continuité des informations.
Maximo utilise l'action Copy PO Lines dans l'application Invoices. Cette action permet d'importer les lignes d'un bon de commande (PO) ou d'une réception directement dans la facture, facilitant ainsi la vérification et le rapprochement des quantités et des coûts.
Les trois applications principales sont Purchase Requisitions (pour les demandes internes), Purchase Orders (pour les commandes externes aux fournisseurs), Receiving (pour l'enregistrement des livraisons) et Invoices (pour le traitement des factures fournisseurs).
Bonne réponse : B
Pourquoi cette question existe — STU §5.3 — la question distingue la tolérance de réception d'un service (Service Items) de celle d'un item physique (Item Master, cf. question bonus sur le sujet). Les distracteurs citent des applications réelles mais inadaptées au flux service. En pratique, confondre les deux empêche de paramétrer correctement la tolérance d'un Standard Service.
Le contexte théorique d'abord — Le pourcentage de tolérance de réception pour un Standard Service se configure dans l'application Service Items, l'équivalent fonctionnel de l'Item Master pour les services, qui ne sont pas physiquement stockés mais suivent un cycle d'achat/réception similaire.
Ce que Maximo en fait — version opérationnelle — Dans Service Items > sélectionner le Standard Service > champ Receipt Tolerance > définir le pourcentage applicable. À la réception du service via Receiving, Maximo applique cette tolérance pour valider l'écart entre quantité/montant commandé et reçu.
Exemple chiffré — Un Standard Service de maintenance préventive facturé en lot de 10 interventions avec une tolérance de 10% accepte une réception entre 9 et 11 interventions sans déclencher d'alerte.
Analogie quotidienne — C'est comme la marge d'erreur tolérée sur un forfait d'heures de prestation facturées : tant que l'écart reste dans la marge convenue, la facture est acceptée sans contestation.
Pourquoi A est faux — Pattern D5 champ-frère : Purchase Requisitions initie la demande, mais ne porte pas le paramétrage de tolérance du service lui-même.
Pourquoi C est faux — Pattern D9 quasi-synonyme : Item Master configure la tolérance des items physiques, pas celle des services.
Pourquoi D est faux — Pattern D6 mauvaise-app : Organizations porte des règles globales, pas le paramétrage fin de tolérance par service.
Bonne réponse : C
Pourquoi cette question existe — STU §5.3 — la question vérifie le code de statut exact (PENDREV) parmi des variantes plausibles mais inexistantes dans la nomenclature Maximo. En pratique, surveiller ce statut permet de suivre les factures en cours d'annulation comptable avant leur clôture définitive.
Le contexte théorique d'abord — Lorsqu'une action de type REVERSEINVOICE est déclenchée sur une facture (Invoice), celle-ci transite par le statut PENDREV (Pending Reversal), indiquant que la facture est en cours de processus de réversion comptable avant finalisation des écritures inverses.
Ce que Maximo en fait — version opérationnelle — Dans Invoices, sélectionner la facture à annuler > action Reverse Invoice > le statut passe à PENDREV pendant le traitement des écritures de réversion, puis se stabilise une fois le processus terminé.
Exemple chiffré — Sur 50 factures traitées dans le mois, 3 déclenchées en reversal transitent temporairement par PENDREV avant finalisation, contre 47 suivant le cycle normal Entered → Approved → Paid.
Analogie quotidienne — C'est comme le statut « remboursement en cours » sur une commande en ligne : la transaction d'origine n'est pas encore totalement annulée, le processus inverse est en cours.
Pourquoi A est faux — Pattern D2 inventé : « WAITREV » n'est pas un code de statut Maximo standard.
Pourquoi B est faux — Pattern D5 champ-frère : INPROG est un statut générique utilisé sur d'autres objets (ex. Work Order), pas le statut spécifique de réversion d'invoice.
Pourquoi D est faux — Pattern D9 quasi-synonyme : « REVERSING » décrit l'action en langage courant, mais n'est pas le code de statut officiel Maximo (qui est PENDREV).
Bonne réponse : C
Pourquoi cette question existe — STU §5.3 — la question vérifie le code exact de statut d'inspection (WASSET) appliqué une fois un rotating item inspecté et tracé comme actif, par opposition à des noms intuitifs mais inexacts. En pratique, ce statut signale que l'item est désormais aussi suivi dans Assets avec un numéro d'actif.
Le contexte théorique d'abord — Lors de la réception d'un rotating item dans Receiving, après inspection, le statut d'inspection bascule vers WASSET (« with asset »), indiquant que l'item est désormais également tracé dans l'application Assets avec un numéro d'actif dédié.
Ce que Maximo en fait — version opérationnelle — Dans Receiving > recevoir la ligne d'un rotating item > effectuer l'inspection > le statut d'inspection passe à WASSET > Maximo crée automatiquement l'enregistrement Asset correspondant, visible dans Assets.
Exemple chiffré — Sur une réception de 5 pompes rotatives, chacune inspectée individuellement bascule en statut WASSET, générant 5 nouveaux numéros d'actifs distincts, contre 0 création d'actif pour un item non-rotatif équivalent.
Analogie quotidienne — C'est comme immatriculer un véhicule neuf à la livraison : une fois la plaque posée (statut WASSET), le véhicule existe officiellement comme actif individuel traçable.
Pourquoi A est faux — Pattern D9 quasi-synonyme : « CREATEASSET » décrit l'action sous-jacente en langage intuitif, mais n'est pas le code de statut officiel (qui est WASSET).
Pourquoi B est faux — Pattern D5 champ-frère : PARTIAL décrit une réception incomplète en quantité, sans lien avec le statut d'inspection d'un rotating item.
Pourquoi D est faux — Pattern D9 quasi-synonyme : « INSPECTED » paraît logique mais n'est pas le code de statut réel utilisé par Maximo pour ce cas précis.