Refaire la facture d'un ancien ERP dans Business Central avec une extension de rapport

Un distributeur québécois qui passait de son ancien ERP à Business Central voulait une chose côté documents : une facture qui ressemble à l'ancienne. La comptabilité de ses clients sait exactement où trouver le numéro de commande, les conditions et les taxes. Une nouvelle mise en page, c'est des appels et des paiements en retard pour rien.

Voici comment je l'ai construite, et les parties qui ont demandé plus de réflexion que prévu.

Étendre le rapport standard, pas le copier

Copier le rapport 1306 (Standard Sales - Invoice) et modifier la copie, c'est la voie rapide, et la copie arrête de recevoir les correctifs de Microsoft le jour où on la fait. Une extension de rapport garde le jeu de données et la logique du standard (lignes, taxes, totaux, escomptes), permet d'ajouter des colonnes et du code, et apporte sa propre mise en page :

reportextension 50450 "Sales Invoice Ext" extends "Standard Sales - Invoice"
{
    dataset
    {
        add(Header)
        {
            column(RequestedDeliveryDate; RequestedDeliveryDate) { }
            column(ShippingAgentName; ShippingAgentName) { }
            column(ConditionsText; ConditionsText) { }
            column(DocLanguage; DocLanguage) { }
        }
        modify(Header)
        {
            trigger OnAfterAfterGetRecord()
            begin
                // remplir les colonnes ajoutées pour cette facture
            end;
        }
    }

    rendering
    {
        layout(LegacyInvoice)
        {
            Type = RDLC;
            LayoutFile = './layouts/LegacyInvoice.rdlc';
            Caption = 'Invoice (legacy look)';
        }
    }
}

Combler les trous

Ce que l'ancienne facture montrait et que le jeu de données standard n'a pas :

• La date de livraison demandée. La facture reportée ne la contient pas. On la relit dans l'expédition reportée de la même commande (Sales Shipment Header filtré sur Order No.).
• Le nom du transporteur, tiré de la fiche Shipping Agent, plutôt que son code.
• Le numéro de TVQ, tiré de Company Information (le numéro de TPS est déjà dans le jeu de données standard), jamais tapé dans la mise en page.
• Les conditions au bas de la facture, en français et en anglais. Elles vivent dans Business Central comme un texte standard avec des textes étendus par langue et par période, que l'extension crée à l'installation. Changer une phrase, c'est un changement de données, pas un déploiement.

La langue du document, pas celle de l'utilisateur

Le piège : tout ce qu'on ajoute à un rapport sort naturellement dans la langue de la personne qui l'imprime. Le rapport standard passe ses propres libellés dans la langue du client ; tout ce que l'extension ajoute doit suivre la même règle. L'extension déduit la langue du document du Language Code de la facture, choisit le texte des conditions dans cette langue et passe la langue à la mise en page dans une colonne, pour que les libellés du RDLC suivent eux aussi. Un client anglophone reçoit une facture en anglais même quand c'est une commis francophone qui l'imprime.

Les détails RDLC qui la font ressembler à l'ancienne

• L'en-tête et le pied de page ne peuvent pas lire les champs du jeu de données en RDLC. La solution habituelle : mettre chaque valeur une fois dans une zone de texte cachée du corps, et la lire de l'en-tête ou du pied de page avec ReportItems!. Une seule copie par valeur, lue des deux côtés.
• Cacher les colonnes d'escompte quand aucune ligne n'en a, et laisser la description prendre toute la largeur. C'est une expression de visibilité sur les colonnes, pilotée par une valeur calculée une fois pour le document.
• Reprendre les formats et les tailles de l'ancienne facture : formats de date, décimales, polices. C'est ce que les utilisateurs remarquent en premier.

Word ou RDLC

J'ai montré les deux types de mise en page au client sur la même facture avant de construire. Une mise en page Word peut être modifiée par le client dans Word ; le RDLC donne un contrôle plus serré sur le placement, mais demande Report Builder ou Visual Studio. Ils ont choisi le RDLC. Mon conseil par défaut : Word quand le client veut faire de petits changements lui-même, RDLC quand la mise en page doit être exacte.

Deux notes pratiques sur les versions actuelles :

• Le statut des mises en page. Depuis 2026 release wave 1, les mises en page de rapport ont un statut (brouillon, en attente d'approbation, approuvée, retirée) et seules les mises en page approuvées s'impriment. Une mise en page importée à la main commence en brouillon.
• Report Builder ouvre un .rdlc exporté une fois renommé en .rdl.

La suite

La facture est d'habitude le premier document, pas le dernier : note de crédit, confirmation de commande, soumission, bon de livraison. Une fois la gestion de la langue, les textes étendus et les champs de la société en place, les suivants vont beaucoup plus vite.

Des documents à refaire pour un projet Business Central? Parlons-en.