Case: RDLC rapport aanpassen zonder tooling vs. met MCP tooling

Klant: Peter Peters (Wopal B.V.) Datum: 23 maart 2026 Tags: rdlc, report-extension, mcp, layout-spec, extract, round-trip, 4ps, wopal

Situatie

Zes aanpassingen aan het inkooporder rapport van Wopal B.V.: ordernummer verplaatsen, kolommen toevoegen aan de inkoopregelentabel, en contactpersoon automatisch vullen op basis van aflevertype. De RDLC layout is 700KB XML, het rapport gebruikt een SetData/GetData patroon met 63+ indices om headervelden door te geven.

Fouten gemaakt zonder tooling

1. Verkeerd textbox verplaatst (grootste fout)

We moesten het ordernummer verplaatsen in de header. Door raw XML te greppen identificeerden we ReferenceText5 / PurchRcptHdrYourRef5 met GetData(1,1) als het ordernummer. Na deployen bleek dit de leveranciernaam te zijn (BuyFromAddr1). Het echte ordernummer was SalesHdrShpmtDt met GetData(16,1).

Impact: Hele debug-cyclus (deploy, test, onderzoek, revert, opnieuw zoeken, opnieuw deployen). Kostte ~30 minuten extra.

Met bc_extract_layout_spec: De declaratieve spec had direct getoond welk textbox welke binding heeft. Geen gokwerk nodig.

2. Dubbele contactpersoon niet gezien

Het rapport had twee textboxen met caption "Contactpersoon:" op verschillende hoogtes (3.13cm en 4.43cm), elk met een andere databinding. Bij greppen door 700KB XML was dit niet zichtbaar. Pas na testen rapporteerde de klant dubbele velden.

Impact: Extra test-fix cyclus.

Met bc_extract_layout_spec: Alle header textboxen met hun captions en bindings in een overzichtelijke lijst. Duplicaten direct zichtbaar.

3. Telefoon zichtbaar zonder contactpersoon

Het ShipToPhone veld bleef zichtbaar in de afleveradressectie ook als er geen contactpersoon was, wat een onbegrijpelijk telefoonnummer op het rapport opleverde.

Impact: Extra fix nodig.

Met layout spec: De relatie tussen velden in de spec maakt het makkelijker om visibility-afhankelijkheden te reviewen voordat je deployt.

4. RDLC te groot om te begrijpen

De 700KB XML vereiste meerdere subagent-rondes met grep, elk met 20-30 regels context. Het opbouwen van een mentaal model van het rapport kostte ~5 subagent-calls alleen al voor de initiële analyse.

Met bc_parse_rdlc / bc_extract_layout_spec: Eén call geeft de volledige structuur in compact, leesbaar formaat.

Wat wel goed ging dankzij tooling

FlowField detectie

De toolkit kon via de geparsede 4PS symbolen direct zien dat "Name Purchaser" en "Contact Person Name" FlowFields zijn. Hierdoor werd CalcFields meteen correct toegepast, wat normaal pas bij het testen als lege waarde zou opvallen.

Contact Person dataketen traceren

Toen de contactpersoon bij projectlocatie leeg bleek, kon de toolkit de volledige dataketen traceren: ProjectPrincipal."Contact Person No." (stored field, alleen gevuld via OnValidate) → CalcFormula van het FlowField → fallback via Customer."Primary Contact No.". Dit leidde tot een robuuste fallback-keten in de code.

Conclusie

De RDLC Layout Spec Round-Trip (bc_extract_layout_spec → wijzig spec → bc_generate_report_extension) had de grootste fout (verkeerd textbox) en de meeste extra debug-cycli voorkomen. De belangrijkste winst:

Geen gokwerk meer bij GetData indices: De spec toont exact welk textbox welke data toont
Structureel overzicht: Duplicaten, ontbrekende bindings, en logische inconsistenties zijn zichtbaar voor deployment
Round-trip generatie: In plaats van chirurgisch XML aanpassen (foutgevoelig bij 700KB) kun je de spec declaratief wijzigen en het RDLC laten regenereren

Dit is het sterkste bewijs tot nu toe dat de RDLC tooling direct tijdwinst oplevert bij klantcases.

Zoektermen

rdlc, layout-spec, extract, round-trip, verkeerd textbox, getdata, setdata, dubbele velden, 700kb xml, report extension, mcp server, wopal, inkooporder