I have never been a fan of RDL reporting. The process and tools are not intuitive or enable me to build what I need. Lately, I have been thinking about a new way of doing this, and in this video, I demo a prototype I built over the weekend of a new report layout engine. Check it out:
In this video, Erik explores a provocative question: what if we could build report layouts in Business Central using HTML and CSS instead of relying on RDL, Word, or Excel? What started as a thought experiment after a roundtable discussion about reporting quickly turned into a weekend project — and the results are surprisingly compelling. Erik walks through the concept, demonstrates a working prototype, and invites feedback on whether this approach is genius, madness, or something in between.
The Current State of Reporting in Business Central
When it comes to report layouts in Business Central, we have several options — though Erik would argue none of them are particularly great:
- Excel layouts — These are data-driven. You get all your data dumped into an Excel sheet and then handle the layout yourself. Microsoft is currently pushing these hard.
- Word layouts — Great because anyone can use Word to create them. Not so great because there are many things you simply cannot do: conditional formatting, conditional sections, calculations, and other advanced features.
- RDL layouts — Based on SQL Server Reporting Services. Often the least popular choice. The tooling is stuck on Report Builder version 3, and Microsoft hasn’t created a new RDL report in years.
Erik notes that the original Navision actually had a great built-in reporting tool. When Microsoft transitioned to the RoleTailored client, SSRS/RDL became the standard — but it’s a very detached process, and development on it has essentially stalled.
The Spark of an Idea
At a roundtable discussion about the future of reporting, many people expressed the desire for something better than RDL — a tool that could do everything Word can’t (conditional formatting, conditional sections, calculations). But Erik left that meeting thinking about a different approach entirely.
He had recently been experimenting with CSS Flexbox — the way web pages stack and rearrange content using flex containers. That got him thinking: what if we approached a report layout more like a web page? Everything is a box. Boxes are stacked together to form a page. CSS even has specific rules for print media. Could you build a report engine using HTML and render it right inside AL?
That idea kept bouncing around in his head until he decided to just try it out.
The “Flex Report” Prototype
Erik demonstrates what he’s calling “Flex Report” — a working prototype built over a weekend (literally between putting up Christmas lights and writing code). Here’s what it looks like in action:
Creating and Running a Layout
Erik has created a new layout for the Sales Invoice report. Running it produces an actual invoice displayed on screen — complete with a logo, header information, line items, and totals. It’s rendered as HTML, displayed directly in the browser.
The Template System
Each layout has a connected template. The template is simply an HTML document with two key parts:
- A style section containing a CSS stylesheet where the page is defined as a flex container that flows downward
- A body section that contains a placeholder (
%body%) where the rendered content gets injected
Learning the Report Structure
When you first set up a layout, you click “Learn Report.” This prints the report and analyzes the data set — figuring out what data elements exist, what columns are available, and what the structure looks like. After learning, you can use all the elements from the report’s data set in your layout.
Defining Sections
The layout is built from sections that map to the report’s data items. For each data item, you can define different section types:
- Header — Rendered once at the top of a data item group
- Normal — The regular repeating row/box for each record
- Transport Header / Transport Footer — For running totals when content overflows to a new page (e.g., “Total so far” at the bottom and “Total from previous page” at the top)
- Footer — For totals and summary sections
The indentation and positioning of these sections is determined automatically from the data set hierarchy.
Editing Sections
Each section can be edited using a WYSIWYG editor (CKEditor) or by switching to raw HTML. You can add fields from the data set using an “Add Column” function that shows all available fields along with sample data so you know exactly what each field contains.
Erik demonstrates making the item name bold, saving, and immediately seeing the result — the feedback loop is extremely fast.
How It All Maps to HTML
The section names (header, line, total) become CSS classes in the rendered output. Looking at the generated HTML, you can see clean div elements:
<div class="header"><div class="line"><div class="line"><div class="totals">
Because everything is just HTML and CSS, you get full control over styling. You can do pixel-perfect positioning if you want, or use relative positioning so the layout adapts to different widths — Erik demonstrates this by resizing the browser window and watching the invoice respond accordingly.
Under the Hood: The AL Implementation
The entire rendering engine is built in AL, running on a Docker container. Here are the key architectural points:
Intercepting Report Rendering
The solution hooks into the OnCustomDocumentMergerEx event on the Report Management codeunit. This allows intercepting the report printing process to take over rendering.
The Rendering Process
The rendering logic works as follows:
- Receive the data set from the report
- Loop through the data set
- For each data element, determine what needs to be rendered (headers, transport headers, normal sections, child sections)
- Handle page overflow calculations — the “page height” field on the layout is used to determine when transport headers/footers should be inserted
- Render footers
- The process is recursive — if there are sub-elements, it calls itself
- Everything gets aggregated as divs (boxes) stacked together in the flex container
- Finally, the sections are assembled into a complete HTML page
Surprisingly Small Codebase
The entire rendering codeunit is only about 543 lines of AL code — and that includes some commented-out Microsoft code that Erik used to figure out how the events worked.
Tooling
- Ace editor — Used for the HTML/template editing view
- CKEditor — Used for the WYSIWYG section editing
Current Limitations
Erik is very transparent about what doesn’t work yet:
- PDF generation — Currently the output is rendered on screen as HTML because pure AL cannot convert HTML to PDF. An external service would be needed to handle that conversion. There are JavaScript approaches, but Erik doesn’t consider those a good solution.
- Section editing workflow — Right now each section must be edited separately, which is tedious. Erik envisions a page where you can click on elements and switch between them fluidly, editing the entire layout in context.
- Lots of missing features — This is explicitly a proof of concept, not a finished product.
Live Editing Demo
To demonstrate the rapid iteration cycle, Erik notices the invoice is missing tax information. He edits the report on the fly:
- Inserts a row above the total for tax amount
- Uses “Add Column” to find and insert the
Total VAT Amountfield - Aligns it to the right
- Makes the total line bold
- Saves, exits, clicks “Test Report,” and prints
The tax amount appears immediately. The entire process takes seconds.
Conclusion
This “Flex Report” prototype demonstrates that building report layouts using HTML and CSS Flexbox inside Business Central is not only possible but potentially very powerful. The approach leverages ubiquitous web technologies that millions of developers already know, offers full control over styling and positioning, and provides an extremely fast feedback loop for layout changes. At just over 500 lines of AL code for the core engine, it’s also surprisingly lightweight.
Whether this grows into a full-fledged reporting tool, gets incorporated into something like the Simplica designer, or remains an interesting experiment is an open question. Erik built this as a weekend project to empty his head of an idea that wouldn’t go away — and the results are compelling enough to warrant serious discussion. Is it genius or madness? Perhaps a bit of both — and that’s often where the best ideas live.
