Les FlowFields de Business Central ne s'extraient pas : ils se reconstruisent

Vous branchez Business Central sur Power BI, vous rapatriez la table Customer, vous posez le champ Balance dans un visuel, et vous obtenez zéro partout. L'écran de l'ERP, lui, affiche des soldes parfaitement corrects.

Rien n'est cassé. Ce champ n'a simplement jamais existé sous forme de donnée.

Un FlowField est une formule, pas une colonne

Business Central, et Dynamics NAV avant lui, distingue deux natures de champs. Les champs normaux sont stockés : ils occupent de la place, ils sont sauvegardés, on peut les lire. Les FlowFields ne sont pas stockés du tout. Ce sont des définitions de calcul que le serveur exécute au moment où l'écran s'affiche.

Balance sur la table Customer est un FlowField. Sa définition dit, en substance : « fais la somme du champ Amount de la table Cust. Ledger Entry, pour toutes les lignes dont le Customer No. vaut celui de cette fiche ». Le calcul tourne à chaque ouverture de la fiche client.

Une extraction SQL ou une lecture d'API récupère ce qui est stocké. Comme rien n'est stocké, elle récupère la valeur par défaut du type : zéro pour un montant, vide pour un texte. Aucune erreur n'est levée, et c'est ce qui rend le piège coûteux : le rapport s'affiche, les totaux sont faux, et personne ne s'en rend compte avant que quelqu'un ne rapproche avec l'ERP.

Les FlowFields les plus souvent rencontrés

Sur nos projets, ce sont presque toujours les mêmes qui manquent :

| Table | Champ | Ce qu'il agrège en réalité | |---|---|---| | Customer | Balance, Balance (LCY) | Les écritures clients non lettrées | | Vendor | Balance, Balance (LCY) | Les écritures fournisseurs | | Item | Inventory | Les mouvements de stock | | Item | Qty. on Sales Order | Les lignes de commande non expédiées | | G/L Account | Balance at Date, Net Change | Les écritures comptables sur une période | | Job | Total Cost, Total Price | Les lignes de projet |

Le point commun saute aux yeux : chacun est la somme d'une table de mouvements. C'est exactement ce qu'un modèle en étoile sait faire nativement.

Reconstruire plutôt qu'extraire

La bonne nouvelle est que la reconstruction produit un résultat supérieur à l'original. Un FlowField rend une valeur, à l'instant présent, pour une fiche. Une mesure rend la même valeur, mais à n'importe quelle date, sur n'importe quel regroupement, et avec le détail derrière.

Le principe tient en trois étapes.

Un, importez la table de mouvements, pas la fiche. Pour les soldes clients, c'est Cust. Ledger Entry ou, mieux, Detailed Cust. Ledg. Entry qui porte le détail des lettrages. La table Customer reste utile comme dimension : elle porte le nom, le pays, le groupe comptable. Elle ne porte plus le solde.

Deux, écrivez la mesure. Pour un solde client, le calcul de base est une somme filtrée :

Solde client =
CALCULATE (
    SUM ( 'Detailed Cust. Ledg. Entry'[Amount (LCY)] ),
    'Detailed Cust. Ledg. Entry'[Entry Type] = 1   -- écriture initiale
)

Pour l'encours réel (ce que le client doit encore), il faut retirer les lettrages, ce qui revient à sommer toutes les natures d'écritures plutôt qu'à filtrer :

Encours client =
SUM ( 'Detailed Cust. Ledg. Entry'[Amount (LCY)] )

C'est contre-intuitif, et c'est pourtant la définition que Business Central applique : le solde est la somme algébrique de toutes les écritures détaillées, les règlements portant un montant négatif.

Trois, ajoutez la dimension temps. C'est le gain que le FlowField n'offrait pas. Avec une table de dates correctement reliée à Posting Date, la même mesure répond à « quel était l'encours au 31 décembre » :

Encours à date =
CALCULATE (
    [Encours client],
    FILTER (
        ALL ( 'Date' ),
        'Date'[Date] <= MAX ( 'Date'[Date] )
    )
)

Ce que la reconstruction rend possible

Une fois la mesure écrite, le solde cesse d'être un nombre figé sur une fiche : il devient une valeur qu'on peut regrouper, comparer et lire dans le temps.

Les mêmes chiffres, lus en une seconde

À gauche, il faut parcourir chaque ligne pour repérer le mois qui décroche. À droite, on le voit sans lire. C’est tout le travail d’un rapport bien conçu.

Comment vérifier que c'est juste

Une reconstruction se valide par rapprochement, jamais par relecture du code. Nous procédons toujours ainsi :

1. Ouvrez la liste des clients dans Business Central, colonne Balance (LCY) affichée, et exportez-la vers Excel.
2. Sortez la même liste depuis le modèle, avec la mesure, à la date du jour.
3. Comparez client par client, pas seulement le total. Deux erreurs de signe opposé se compensent parfaitement dans un total et se voient immédiatement en détail.

Les écarts qui subsistent viennent presque toujours de trois causes : des écritures dans une devise non convertie, un filtre de société oublié en environnement multi-sociétés, ou des écritures de régularisation portant un type que la mesure exclut.

Sur plusieurs instances, l'affaire se complique

Si vous consolidez plusieurs Business Central, chaque instance a ses propres numéros de client. Le client CLI-0042 de la société française et le C00042 de la société belge peuvent désigner la même entreprise, ou deux entreprises différentes.

La mesure fonctionnera dans les deux cas, mais le regroupement sera faux tant qu'une étape d'alignement des référentiels n'a pas tranché. C'est le sujet le plus sous-estimé au chiffrage d'un projet multi-instances, et nous lui avons consacré une page entière.

Sur ce volume, nous exportons d'ailleurs avec bc2adls plutôt que par l'API : l'export est incrémental, il écrit du Delta directement dans le lac, et il ne consomme pas les quotas d'appel de votre ERP.

Ce qu'il faut retenir

Un solde à zéro dans Power BI n'est pas un bug de connexion : c'est un champ qui n'a jamais été stocké. La reconstruction en mesures demande une demi-journée sur un périmètre simple, elle se valide par rapprochement ligne à ligne, et elle rend un modèle plus capable que l'écran d'origine, parce qu'il répond à n'importe quelle date et sur n'importe quel axe.