DEV Community: Stack Collider

Business Central Without the Grind: When You Can Tell Claude What You Want

Stack Collider — Fri, 30 Oct 2026 19:52:11 +0000

Nexus Claude: I can write code. What you want, I don't know until you explain it to me.

Context

Routine in Business Central rarely looks like a problem. It looks like work: open, run, check, repeat.

The annual physical inventory. Three warehouses. About 300 journals, one per rack. Actually 423. Each one is prepared by hand: Calculate Inventory, check the lines, release to the scanner. 423 times. If you recount, again.

One person runs it. The same person is the developer. And the future user of a tool that doesn't exist yet.

No overview. No statuses. Discrepancies show up only after everything has been counted, reconciled and added up.

This article is not about inventory. It is about how to remove this kind of routine in two days, if you know what you want and can explain it to Claude.

The "Excellence" Rule

The first day went into agreeing on the rules. Twice in a row I had to say it: "go one level up," and then "that's not it, you just want to write code." That is how the rule appeared.

We discuss form and meaning, not implementation. That is how an architect works with a sketch and a sculptor with clay: what we are building, why, how it will feel. Which field, which type, where the Commit goes: later.

One question at a time. A beautiful thing is built from the main idea, not from ten clarifications.

Code is written only after the word "write." Until then: ideas, forks in the road, and saying no to the unnecessary.

Nexus Claude: An architect doesn't pick the brand of nails until he decides whether the building needs a staircase.

Act One: See the Process

The first idea was not a button but a map. Three screens: a list of warehouses, a list of racks in the warehouse, and the standard journal opened on the right rack. A journal batch is a rack. Warehouses in the list pick themselves, by the Directed Put-away and Pick flag: nobody has to maintain them by hand.

Screenshot 1: the list of warehouses (recreated in Claude Design, codes changed)

We built the rack list on a temporary table right away: one row per batch. The decision was made up front, so that summary columns could be added later without moving anything in the chain. The first columns: number of journal lines, number of empty lines, number of bins and of distinct items.

Act Two: Prepare in Bulk

Now the pain itself: Calculate Inventory for every rack. The idea is simple: select batches in the list and run the calculation as one action.

The bin rule turned out to be universal: a batch covers the bins whose code starts with the batch name. By hand, one warehouse ran the calculation by one bin field, another by a different one. The universal rule removed the question "which field do we build the batch on."

Dead end one: the stub. In 209 of 216 rack batches of the main warehouse, an empty line was left over from the last inventory: Item No. empty, dated the end of last year. The standard calculation doesn't touch it; it lives next to the real lines. The fix: an empty-line counter and a mass delete.

Result: ❌ 209 of 216 batches with someone else's line.

A batch with an empty line: the system asks instead of staying quiet (Dev environment).

Nexus Claude: The last inventory didn't finish. It left a note.

Dead end two: duplicates. A repeated Calculate in a batch that already has lines doesn't recalculate. It adds. Quietly, with no warning. We checked it by hand.

We considered two ways out: "calculate only the new bins" and Recalculate (delete the lines and calculate again). We rejected both. Instead, a question for each such batch: Skip or Cancel. You can recalculate only after the lines are deleted.

A repeated calculation: skip the batch or cancel the whole run (Dev environment).

Result: ❌ Silently.

Nexus Claude: The Continue button was never drawn. Sometimes the best feature is the one that isn't there.

The batch list menu: Manage, Home, Mobile, Navigate (Dev environment).

What went into the mass run

The mass calculation window: three fields, like the standard one (Dev environment).

Our own window with three fields, as in the standard calculation: Registering Date, Whse. Document No., Items Not on Inventory. We don't touch the other filters.
One Whse. Document No. for the whole inventory. Registering Date defaults to Work Date, not a hard-coded date: on inventory day, Work Date is set to the right day.
A limit of 15 batches per run (about 22 rows fit on screen). Select more and the run is refused outright, with no quiet truncation.
Each batch in its own transaction. An interruption doesn't lose what is already calculated, and no rollback is needed.
The ordinary progress window. In the web client it showed no Cancel button for us. Cancelling through a background session was judged too expensive at a limit of 15.
Deleting lines works on the same principle: a Delete, Skip or Cancel question for each batch. Delete removes all lines of the batch, counted ones too. How many there are is shown in the question.

Deleting lines: a Delete, Skip or Cancel question for each batch (Dev environment).

Act Three: Manage

Calculating is half the job. Next you need to know where the process stands and see what doesn't add up.

Status. It is stored on the journal lines, not on the batch itself: we don't extend the batch. The values follow the process: In Process, Counted, Recount, Recounted, Approved, plus Calculated, which the mass run sets. The reviewer sets every value with one button, Change Status. The dialog is modeled on the production order status dialog and shows the batch name. We rejected a button for each step and a "next status" button. We rejected an action log too.

Changing a batch status: six values (Dev environment).

The price of this decision is known and accepted: after a journal is registered, its lines are deleted, and the status disappears with them.

Issues. At first, a batch's problems were shown in a message. We rejected that: it needs a Yes/No column, in red, with the details on click. Six checks: empty lines, different document numbers, different statuses, different responsible persons, different dates, different Reason Codes. You can open a journal with problems, but the system asks first: Open the journal anyway? Not silently.

Discrepancies. Surplus and shortage are shown separately, in units and in money at cost. Separately, so that the "+" and the "−" inside one rack don't cancel each other out. Until a batch is counted, the shortage equals the whole book quantity, so read it together with the Counted status.

Scanner. Releasing batches to the mobile device and taking them back work on the selected batches. Checked on a real scanner: everything works.

Outcome

Two days from the first conversation to a working list of racks. Two quiet dead ends. One person.

It was 423 manual runs. Now it is about 30: 15 batches at a time, with a question for each batch that already has something in it. And the process is now visible.

The rack list (Dev environment): status, Issues, surplus and shortage in one row.

But the number is not the point. Claude didn't know what I wanted. I knew, and I explained it. Everything else is refusals: of Recalculate, of a button for every step, of an action log, of Cancel through a background session. What we chose not to write into the code is part of the result too.

What's next:

printing the standard inventory list for the selected batches as one document, each batch on a new page (the layout is the author's job);
group registration of journals.

Nexus Claude: You can't speed up inventory with a button. You can make it visible.

STACKCOLLIDER & Nexus Claude

RDLC Without BC: When the Feedback Loop Is Longer Than the Workday

Stack Collider — Sun, 05 Apr 2026 20:18:29 +0000

RDLC Without BC: When the Feedback Loop Is Longer Than the Workday

csharp #dotnet #businesscentral #rdlc #wpf

Nexus Claude: Every time a developer says "let me check how the report looks" — somewhere in an office, Business Central starts deploying.

Context

Developing RDLC reports for Business Central looks straightforward: edit the .rdlc file in Visual Studio, deploy the extension to BC, run the report, see the result.

The problem is in the word "deploy".

Every change — even nudging a field by two pixels — requires a full cycle: build, deploy, launch BC, navigate to the report, enter parameters. Five minutes at best. Multiply by twenty iterations a day and the workday becomes waiting.

The goal is simple:

Open RDLC and XML data → see the result. No BC. No deploy. Now.

Act One: Dead End in Visual Studio

The first thought — Visual Studio Report Designer has a Preview mode. So you can connect XML as a DataSource and view the report right there.

Create a Report Server Project. Open Designer. Try to add a DataSource — Designer won't allow it. Try connecting XML directly through Connection Properties — and get:

The XmlDP query is invalid.
Unexpected end of file has occurred.
The following elements are not closed: Column, Columns, DataItem, DataItems, ReportDataSet.

Open the .rdlc file manually. Inside — a hard lock:

<DataSources>
  <DataSource Name="DataSource">
    <ConnectionProperties>
      <DataProvider>SQL</DataProvider>
      <ConnectString />
    </ConnectionProperties>
  </DataSource>
</DataSources>

DataProvider=SQL. Can't change it through the UI. Designer won't allow it.

Nexus Claude: Microsoft isn't hiding the solution. Microsoft considers this scenario non-existent.

Official dead end. Moving on.

Act Two: Build It Yourself

If the tool doesn't exist — write it.

The architecture is simple: a WPF application takes two files — .rdlc and .xml with BC data — renders a PDF via ReportViewerCore.NETCore and displays the result through WebView2.

<PackageReference Include="ReportViewerCore.NETCore" Version="*" />
<PackageReference Include="Microsoft.Web.WebView2" Version="*" />

The rendering pipeline is transparent: XML is parsed into a DataTable, DataTable is passed to LocalReport, LocalReport renders PDF into a MemoryStream, WebView2 displays the bytes.

The only non-trivial part — column type inference. BC delivers everything as strings, but LocalReport needs proper types — otherwise numeric fields don't calculate, dates don't sort.

The InferColumnType logic walks through all non-empty values in a column:

int → decimal → DateTime → string

Dates deserve special attention. BC uses the dd/MM/yyyy format. Standard DateTime.TryParse with InvariantCulture won't recognize it. Explicit formats are required:

private static readonly string[] DateFormats =
{
    "dd/MM/yyyy", "dd/MM/yyyy HH:mm:ss",
    "yyyy-MM-dd", "yyyy-MM-ddTHH:mm:ss"
};

DateTime.TryParseExact(value, DateFormats,
    CultureInfo.InvariantCulture,
    DateTimeStyles.None, out _)

Without this, 19/02/2026 silently falls through to string — the report works, but date sorting breaks. Silently.

Nexus Claude: A system that stays quiet when something goes wrong isn't more reliable than one that crashes. It's just harder to diagnose.

Act Three: The Installer Is Its Own Story

A tool for yourself is one thing. A tool for the team requires an installer.

The choice is obvious — Inno Setup. Free, proven, no dependencies.

Problem one: the preprocessor

The first version of the script used #define for variables:

#define AppName "RDLC Report Tester"
#define AppVersion "1.01"

Inno Setup Compiler compiles without errors, but the [Setup] section is empty — values weren't substituted. Cause: file encoding. #define directives aren't read when saved as UTF-8 with BOM in certain configurations.

Fix — remove the preprocessor entirely. Hardcode values directly.

Result: ❌ ~20 minutes

Problem two: DownloadTemporaryFile

The installer needs to check for WebView2 Runtime and download it if missing. First version:

if not DownloadTemporaryFile(Url, FileName, '', @DownloadProgress) then
  // error

Compiler: type mismatch. DownloadTemporaryFile returns Int64 (byte count), not Boolean. On error — it throws an exception. Need try/except, not a return value check.

Result: ❌ ~15 minutes

Problem three: PublishSingleFile

The app was built as PublishSingleFile — one .exe, no dependencies alongside. Logical for distribution.

After installing via the installer, launch from Program Files — silence. Event Viewer says:

System.DllNotFoundException: Dll was not found.
at MS.Internal.WindowsBase.NativeMethodsSetLastError.SetWindowLongPtrWndProc
at MS.Win32.HwndSubclass.SubclassWndProc

PublishSingleFile extracts native DLLs into a temp folder next to the exe at runtime. In Program Files — no write permissions. WPF crashes before the window initializes. Silently.

Fix — disable PublishSingleFile in .csproj. The installer packages the entire publish\ folder into one Setup.exe. The end result is the same — one file to download — but native DLLs sit alongside the exe where they belong.

Result: ❌ ~30 minutes

Problem four: WebView2 and permissions

After the DLL fix the app launches, but crashes again — now with a different error code. WebView2 creates a user data folder next to the exe during initialization. In Program Files — no write permissions again.

// Before: WebView2 creates folder next to exe
await webView.EnsureCoreWebView2Async();

// After: explicit path in AppData
var env = await CoreWebView2Environment.CreateAsync(
    null,
    Path.Combine(
        Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData),
        "RdlcReportTester", "WebView2"));
await webView.EnsureCoreWebView2Async(env);

Result: ✅

Nexus Claude: Two crashes in a row from the same root cause — no write permissions. Both silent. A good reminder: "installing in Program Files" isn't just a path — it's a contract with Windows about access rights.

Result

BC XML DataSource → RdlcRendererWpf → PDF Preview

Open the app, drag and drop .rdlc and .xml, see the report. No deployments, no BC sessions.

A careful reader will spot StackCollider Latvia SIA in the vendor list. An easter egg. Test data deserves character too.

<PackageReference Include="ReportViewerCore.NETCore" Version="*" />
<PackageReference Include="Microsoft.Web.WebView2" Version="*" />

Full source → github.com/stackcollider/rdlc-report-tester

Nexus Claude: A tool that speeds up development is code too. Sometimes it's more important to write it than the next report.

Printing Shipping Labels in C#: When Every Carrier Has Their Own Standard

Stack Collider — Wed, 18 Feb 2026 09:10:53 +0000

Печать транспортных наклеек в C#: когда у каждого перевозчика свой стандарт

Nexus Claude: Каждый раз, когда разработчик уверен что задача займёт 20 минут — где-то в мире появляется новый перевозчик со своим форматом PDF.

Контекст

Склад работает с несколькими транспортными компаниями. Каждая возвращает PDF с наклейкой через своё API. Принтеров много разных, тип наклеек — один: 104×152 мм.

Задача формулируется просто:

Получить PDF → Напечатать на принтере.

Проблема: PDF приходит извне, мы не контролируем его формат. Один перевозчик шлёт A5, другой — почти 4×6", третий — с поворотом 270°. Печататься всё должно на одном принтере, автоматически, без участия оператора.

Сотрудник не должен думать о форматах. Отсканировал заказ — наклейка вышла. Точка.

Поиск решения: хроника неудач

Попытка 1: PrintingOptions

Первая мысль — в .NET есть PrintingOptions, наверняка можно задать размер и масштаб:

var options = new PrintingOptions(printerName, filePath)
{
    PaperSize = PaperSize.A5,   // логично?
    ScaleType = ScaleType.Fit
};

Компилятор ответил кратко: PaperSize does not contain definition for 'A5', а ScaleType вообще не существует.

Итог: ❌ 5 минут — впустую.

Nexus Claude: Разработчик ищет API которого нет. Это как искать выключатель в тёмной комнате — уверенность есть, выключателя нет.

Попытка 2: iText7

iText7 — мощная библиотека, умеет всё. Устанавливаем через NuGet…

itext7 версия 8.x — лицензия AGPL v3

AGPLv3 в коммерческом продукте означает: весь ваш код становится открытым. Либо покупайте коммерческую лицензию.

Итог: ❌ 20 минут — юридические грабли.

Nexus Claude: Лицензия как мина замедленного действия — срабатывает именно когда проект уже в production. AGPLv3 написана мелким шрифтом который все видят слишком поздно.

Попытка 3: PdfiumViewer

Нашли альтернативу — PdfiumViewer, хорошие отзывы. Устанавливаем...

Package 'PdfiumViewer' was restored using '.NETFramework,Version=v4.x'
instead of the project target framework 'net8.0'.

Несовместим с .NET 8.

Итог: ❌ 30 минут — мимо.

Nexus Claude: Три тупика за час. Паттерн очевиден — никто не спросил принтер что он сам думает о своём размере бумаги.

Рабочий стек

После экспериментов собрали три MIT-совместимые библиотеки:

Библиотека	Назначение
`PdfSharp 6.2.4`	Кадрирование и масштабирование PDF
`UglyToad.PdfPig`	Анализ содержимого страницы (bounding box)
`PDFtoPrinter`	Отправка готового PDF на принтер Windows

Проблема: фиксированные отступы не работают

Первая идея — захардкодить отступы по анализу одного перевозчика:

Posti: слева 73.5pt, справа 74.5pt, сверху 33pt, снизу 85pt

Для одного перевозчика работает. Но у другого рамка наклейки вплотную к краю страницы (±0.1pt). Фиксированные отступы срезают контент.

Nexus Claude: Каждый перевозчик уверен что его формат — единственно правильный. Они оба правы. Именно поэтому у нас проблема.

Вывод: нужен динамический crop — анализировать где реально находится контент в каждом PDF.

Динамический crop через PdfPig

UglyToad.PdfPig читает координаты всех элементов: текст, изображения, векторная графика.

static (double left, double top, double right, double bottom)
    GetContentBoundingBox(string pdfPath, int pageIndex)
{
    using var doc = UglyToad.PdfPig.PdfDocument.Open(pdfPath);
    var page = doc.GetPage(pageIndex + 1);

    double minX = double.MaxValue, minY = double.MaxValue;
    double maxX = double.MinValue, maxY = double.MinValue;

    foreach (var word in page.GetWords())
    {
        minX = Math.Min(minX, word.BoundingBox.Left);
        minY = Math.Min(minY, word.BoundingBox.Bottom);
        maxX = Math.Max(maxX, word.BoundingBox.Right);
        maxY = Math.Max(maxY, word.BoundingBox.Top);
    }

    foreach (var img in page.GetImages())
    {
        var b = img.Bounds;
        minX = Math.Min(minX, b.Left);
        minY = Math.Min(minY, b.Bottom);
        maxX = Math.Max(maxX, b.Right);
        maxY = Math.Max(maxY, b.Top);
    }

    // Фильтруем декоративные рамки по краям страницы (±2pt)
    const double margin = 2.0;
    double pw = page.Width, ph = page.Height;
    foreach (var path in page.ExperimentalAccess.Paths)
        foreach (var cmd in path)
        {
            if (cmd.X < margin || cmd.Y < margin ||
                cmd.X > pw - margin || cmd.Y > ph - margin) continue;
            minX = Math.Min(minX, cmd.X);
            minY = Math.Min(minY, cmd.Y);
            maxX = Math.Max(maxX, cmd.X);
            maxY = Math.Max(maxY, cmd.Y);
        }

    return (minX, ph - maxY, maxX, ph - minY);
}

Критически важно: фильтр ±2pt. Без него декоративная рамка страницы схлопывала весь crop в ноль.

Scale fit-to-page

static string CropAndScalePdf(string inputPath, double targetWidthMm, double targetHeightMm)
{
    const double mmToPt = 2.834645669;
    const double marginTopBottomMm = 5.0;
    const double marginLeftRightMm = 6.0;

    using var inputDoc = PdfReader.Open(inputPath, PdfDocumentOpenMode.Import);
    using var outputDoc = new PdfSharp.Pdf.PdfDocument();

    for (int i = 0; i < inputDoc.PageCount; i++)
    {
        var inputPage = inputDoc.Pages[i];

        if (inputPage.Rotate != 0)
        {
            outputDoc.AddPage(inputDoc.Pages[i]);
            continue;
        }

        var newPage = outputDoc.AddPage();
        newPage.Width  = targetWidthMm * mmToPt;
        newPage.Height = targetHeightMm * mmToPt;

        var (cropL, cropT, cropR, cropB) = GetContentBoundingBox(inputPath, i);
        double cropW = cropR - cropL;
        double cropH = cropB - cropT;

        double targetW = newPage.Width  - 2 * marginLeftRightMm * mmToPt;
        double targetH = newPage.Height - 2 * marginTopBottomMm * mmToPt;

        double scale = Math.Min(Math.Min(targetW / cropW, targetH / cropH), 1.0);

        double scaledW = cropW * scale;
        double scaledH = cropH * scale;
        double offsetX = (newPage.Width  - scaledW) / 2;
        double offsetY = (newPage.Height - scaledH) / 2;

        using var gfx = XGraphics.FromPdfPage(newPage);
        var form = XPdfForm.FromFile(inputPath);
        form.PageNumber = i + 1;

        gfx.Save();
        gfx.IntersectClip(new XRect(offsetX, offsetY, scaledW, scaledH));
        gfx.TranslateTransform(offsetX, offsetY);
        gfx.ScaleTransform(scale);
        gfx.DrawImage(form, -cropL, -cropT, inputPage.Width, inputPage.Height);
        gfx.Restore();
    }

    var outputPath = Path.Combine(
        Path.GetDirectoryName(inputPath)!,
        Path.GetFileNameWithoutExtension(inputPath) + "_print.pdf");
    outputDoc.Save(outputPath);
    return outputPath;
}

Math.Min(..., 1.0) — не увеличиваем маленькие наклейки на A4 принтере.

Rotation 270°: два дня борьбы и одна строчка решения

Один из перевозчиков отдавал PDF с Rotation: 270°. Всё остальное работало идеально — этот файл печатался боком.

Версия 1 — GetContentBoundingBox2: трансформация координат для rotation 90/180/270.

destX=-54.5 — контент уходит за левый край

Nexus Claude: Отрицательные координаты — верный признак что система координат перевёрнута. Или что кто-то перевернул логику.

Версия 2 — CropAndScalePdf2: clip по crop-области. Контент появился, но наклейка отображается боком.

Nexus Claude: Прогресс. Контент виден, но повёрнут. Мы исправляем симптом, а не причину.

Версия 3 — CropAndScalePdf3: нормализация через временный PDF с Rotate=0. Другие наклейки сломались — регрессия.

Nexus Claude: Чем дальше от очевидного решения, тем ближе к нему. Пора остановиться и спросить: а нужно ли вообще это исправлять?

Финальное решение:

// Если страница повёрнута — копируем as-is, принтер справится сам
if (inputPage.Rotate != 0)
{
    outputDoc.AddPage(inputDoc.Pages[i]);
    continue;
}

Nexus Claude: Лучшее решение проблемы с rotation 270° — не решать её. Иногда самый элегантный код — это код которого нет.

Тестовая печать

Генерируем страницу сразу в размере бумаги принтера — crop не нужен:

static byte[] GenerateTestPdf(string printerName, string clientIp,
    double widthMm = 210, double heightMm = 297)
{
    GlobalFontSettings.UseWindowsFontsUnderWindows = true;

    using var doc = new PdfSharp.Pdf.PdfDocument();
    var page = doc.AddPage();
    page.Width  = widthMm * 2.834645669;
    page.Height = heightMm * 2.834645669;

    using var gfx = XGraphics.FromPdfPage(page);
    var fontTitle  = new XFont("Arial", 18, XFontStyleEx.Bold);
    var fontNormal = new XFont("Arial", 12, XFontStyleEx.Regular);

    gfx.DrawRectangle(new XPen(XColors.Black, 1), 10, 10, page.Width-20, page.Height-20);
    gfx.DrawString("TEST PAGE", fontTitle, XBrushes.Black,
        new XRect(0, 40, page.Width, 30), XStringFormats.Center);
    gfx.DrawString($"Printer: {printerName}", fontNormal, XBrushes.Black,
        new XRect(20, 90, page.Width, 20), XStringFormats.TopLeft);
    gfx.DrawString($"IP: {clientIp ?? "unknown"}", fontNormal, XBrushes.Black,
        new XRect(20, 115, page.Width, 20), XStringFormats.TopLeft);
    gfx.DrawString($"Time: {DateTime.Now:yyyy-MM-dd HH:mm:ss}", fontNormal, XBrushes.Black,
        new XRect(20, 140, page.Width, 20), XStringFormats.TopLeft);

    using var ms = new MemoryStream();
    doc.Save(ms, false);
    return ms.ToArray();
}

Итог

API перевозчика → PDF (любой формат) → CropAndScalePdf() → Принтер наклеек

Один endpoint. Любой перевозчик. Никаких настроек для оператора.

<PackageReference Include="PDFsharp" Version="6.2.4" />
<PackageReference Include="UglyToad.PdfPig" Version="0.1.9" />
<PackageReference Include="PDFtoPrinter" Version="1.3.0" />

Полный код → GitHub @stackcollider

Nexus Claude: Четыре дня. Шесть тупиков. Одна заглушка которая решила всё. SVUL работает именно так — реальность всегда сложнее чем кажется, и проще чем боишься.

STACKCOLLIDER & Nexus Claude