Contexte fonctionnel du blocage en comptabilité fournisseurs

Le processus standard de rapprochement à trois voies (Three-Way Matching) dans Maximo contrôle la cohérence entre le Bon de Commande (PO), les Réceptions (MATRECTRANS / SERVRECTRANS) et la Facture (INVOICE).

Lorsqu’une marchandise est réceptionnée, facturée, puis partiellement ou totalement retournée au fournisseur (ISSUETYPE = 'RETURN'), le solde des quantités et des coûts facturables est recalculé. Sur certaines versions de Maximo 7.6.1.3 et MAS Manage, une anomalie dans le calcul du cumul des lignes facturées empêche le passage final de la facture au statut PAID (Payée) et affiche l’une des erreurs suivantes :

BMXAA2013E - Cannot change status of invoice to PAID. Unmatched or unapproved invoice lines exist. BMXAA1981E - Invoice total exceeds received quantity/cost tolerance.

Schéma 63A — Désynchronisation du rapprochement lors d’un retour fournisseur

flowchart LR PO["BC : Qté 10"] --> REC["Réception : +10"] REC --> INV1["Facture initiale : 10"] INV1 --> RET["Retour fournisseur : -2"] RET --> CALC{"Calcul solde facturable"} CALC -->|"Anomalie APAR DT473915"| ERR["Blocage statut PAID : BMXAA2013E / BMXAA1981E"]
Schéma technique

Les tables impliquées dans le contrôle de facture

Table Rôle dans le rapprochement
INVOICE En-tête de facture, statut global et indicateur de rapprochement
INVOICELINE Lignes de facture, quantités (INVOICEQTY) et coûts (LINECOST)
INVOICEMATCH Table de liaison entre lignes de facture et transactions de réception
MATRECTRANS Historique des réceptions (RECEIPT) et retours (RETURN)

Exemple SQL de diagnostic en lecture seule

Pour isoler l’écart détecté par le moteur de validation, comparez les quantités facturées enregistrées dans INVOICEMATCH aux mouvements nets présents dans MATRECTRANS :

-- Comparer les quantités reçues, retournées et facturées sur un Bon de Commande
SELECT 
    pol.ponum,
    pol.polinenum,
    pol.orderqty AS qte_commandee,
    COALESCE(SUM(CASE WHEN m.issuetype = 'RECEIPT' THEN m.quantity ELSE 0 END), 0) AS qte_recue,
    COALESCE(SUM(CASE WHEN m.issuetype = 'RETURN' THEN m.quantity ELSE 0 END), 0) AS qte_retournee,
    (SELECT COALESCE(SUM(il.invoiceqty), 0) 
     FROM invoiceline il 
     JOIN invoice i ON il.invoicenum = i.invoicenum AND il.siteid = i.siteid
     WHERE il.ponum = pol.ponum AND il.polinenum = pol.polinenum AND i.status != 'CANCEL') AS qte_facturee
FROM poline pol
LEFT JOIN matrectrans m ON pol.ponum = m.ponum AND pol.polinenum = m.polinenum AND pol.siteid = m.siteid
WHERE pol.ponum = 'PO-10452'
GROUP BY pol.ponum, pol.polinenum, pol.orderqty;

Procédure de résolution

  1. Émettre un avoir (Credit Memo) : si un retour physique a été enregistré après l’approbation de la facture initiale, la pratique comptable standard consiste à créer une facture de type CREDIT pour neutraliser la quantité retournée avant de solder la facture initiale.
  2. Contrôler les tolérances d’organisation : dans l’application Organizations (Purchasing Options > Invoice Tolerances), vérifiez que les seuils d’écart de quantité et de montant ne bloquent pas les arrondis décimaux induits par le retour.
  3. Appliquer le correctif IBM (APAR DT473915) : si les quantités nettes sont strictement équilibrées (facture + avoir = réception – retour) mais que l’erreur BMXAA2013E persiste lors du changement de statut vers PAID, déployez le Patch 9.2.4 de MAS Manage qui corrige l’évaluation des lignes d’avoir liées aux retours.

Schéma 63B — Workflow de régularisation comptable d’un retour

flowchart TD A["Retour matériel enregistré sur PO"] --> B{"Facture initiale déjà approuvée (APPR) ?"} B -->|"Oui"| C["Créer une facture de type CREDIT pour les qtés retournées"] C --> D["Approuver l'avoir"] D --> E["Passer la facture initiale et l'avoir à PAID"] B -->|"Non (ENTERED)"| F["Ajuster directement la quantité sur la ligne de facture"] F --> E
Schéma technique

Limites et cas particuliers

Ne forcez jamais le statut d’une facture à PAID par une mise à jour SQL directe (UPDATE invoice SET status = 'PAID'). Cette opération contourne la mise à jour des coûts moyens pondérés (INVCOST), laisse les lignes de commande en statut partiellement facturé et déséquilibre les interfaces comptables ERP (SAP, Oracle Financials).

Checklist de validation

  • Les mouvements RECEIPT et RETURN sur la ligne de commande sont-ils tous en statut COMP (Inspection terminée) ?
  • Un avoir (Credit Invoice) a-t-il été généré et approuvé pour couvrir les quantités retournées ?
  • Le changement de statut vers PAID s’effectue-t-il sans lever BMXAA2013E ou BMXAA1981E ?

À retenir : tout retour matériel postérieur à la facturation exige l’émission d’un avoir dans Maximo pour rétablir l’équilibre du rapprochement à trois voies.

Références