Welcome to Central Perspectives, a Business Central podcast from ITrators. I’m Emma, here with Alex. We’re AI hosts, and our scripts and voices are AI-generated. Today, three changes in Business Central 29 help unfinished work, corrections and report output find the right place. We’ll also look at a search change that is not as new as it might sound, and a useful way to send shipping information without waiting for the invoice. The question running through all of it is quite simple: what happens next, and who can actually use the result? Now, let’s get started.

• Update 29.0 for Business Central 2026 release wave 2
• Work with report inbox items through the API

First, a manufacturing change. Business Central 29 adds inventory picks and put-aways to the subcontracting process. Microsoft lists that enhancement as generally available. Subcontracting itself is older: a company can have another business carry out part of its production. But the unfinished product still has to get there and sometimes come back before it is finished. Alex, what does the new warehouse handling add to that physical journey?

• Update 29.0 for Business Central 2026 release wave 2
• Set up subcontracting

It brings the physical handling closer to the production process people are already recording. Think of a company making a metal assembly. It does the first operation itself, sends the partly finished assembly out for a specialist treatment, and then brings it back for the final operation. The person handling that movement needs something more useful than knowing a subcontract purchase exists. They need to know what is leaving, where it is going and what is coming back. These inventory activities give that handling a documented route. The important distinction is that the object being moved may still be work in progress, rather than a finished item in inventory.

• Update 29.0 for Business Central 2026 release wave 2
• Transfer WIP items between subcontractors

That last distinction is the part I want to hold on to. Someone can point at the assembly on a pallet. It is perfectly real. Yet we are saying it is not an ordinary stock movement. What does Business Central record instead, so that the person looking for it is not left with a philosophical answer?

• Transfer WIP items between subcontractors

The movement has its own work-in-progress entries. Transfer documents track the unfinished parent item and its location, but those movements do not create ordinary item ledger, value or warehouse entries. So the answer to where the assembly is lives in the subcontracting WIP records, not in a stock quantity that pretends production has finished. That matters because otherwise someone could read the absence of an ordinary inventory movement as an unrecorded delivery. Here, it can be the intended accounting boundary. The physical journey is recorded; it is simply not being treated as completed output.

• Transfer WIP items between subcontractors

Then the return from the specialist is not automatically the moment we gain finished stock. In our example, the company still has its own final operation to do. But change the example slightly: suppose the specialist performs the last operation. Same truck, same receiving desk, rather different result?

• Use inventory put-aways and picks for subcontracting

Yes, and that change is worth making explicit in the design. For the final operation, the put-away can post physical production output and capacity. An intermediate operation does not do that physical inventory posting. The warehouse action is therefore connected to where the operation sits in the routing, not merely to whether a pallet crossed the door. I would walk through both situations with the people responsible for production and receiving. If the receiving team expects every return to increase finished stock, the intermediate case will surprise them even when the system is behaving correctly.

• Use inventory put-aways and picks for subcontracting

And the feature name contains another potential trap. We have inventory picks and put-aways, and we also have warehouse picks and put-aways in Business Central. Those sound close enough to get shortened to the same thing in a meeting. Does this change make all of those documents available for unfinished work?

• Transfer WIP items between subcontractors

No. That is one meeting where keeping the full names is genuinely helpful. The WIP process supports inventory picks and put-aways, and warehouse shipment and receipt documents, but it does not create warehouse pick or warehouse put-away documents. Those are different handling processes, not interchangeable labels. A company using more detailed warehouse routines should compare the documented WIP route with its actual way of working. The useful new capability should not be sold to the receiving team as every familiar warehouse step, just applied to unfinished production.

• Transfer WIP items between subcontractors

Let’s stay with the receiving team. Our assembly goes out, spends a few days with the specialist, then comes home for that final operation. I would want to distinguish being on the road from being at the specialist. Is that where a transit location earns its place, rather than just being another code somebody has to maintain?

• Transfer WIP items between subcontractors

It does, and it also affects which return handling is supported. Routes with a transit location support warehouse handling in both directions. With direct shipment and receipt, the return route does not support inbound warehouse handling. And the separate Direct Transfer posting mode is not supported for WIP. So I would not pick the shortest-looking route solely to remove a posting step. Start with how the goods actually move and how the return must be received, then choose a supported route. Your receiving requirement can decide the setup before anyone worries about reducing clicks.

• Transfer WIP items between subcontractors

That changes my first instinct. Fewer steps sounds attractive until the step you removed was the one the receiving team needed. What about a company that needs to identify each individual assembly while it is away? A location and a quantity will not answer which serial-numbered unit came back.

• Transfer WIP items between subcontractors

That requirement needs a separate look, because WIP transfer lines do not support serial or lot tracking. Nor do they provide reservations or planning supply and demand. The WIP movement record is useful, but it is not a replacement for every inventory control. Tracking of final production output is a different matter; we should not carry the WIP restriction across to everything produced. For your individually identified assembly, I would write down exactly where identity must be retained during the outside operation and establish how that requirement is met before adopting this route. A quantity arriving is not enough evidence for that particular need.

• Use inventory put-aways and picks for subcontracting
• Transfer WIP items between subcontractors

There is something else on that truck in some businesses: components the specialist will use while working on the assembly. We have been following the partly finished parent item. I would not want someone to hear the WIP limitations and assume they also describe every component sent to the subcontractor. Are those two movements doing different jobs in the system?

• Manage components in subcontracting

They are. The parent is the product progressing through production. Components are materials used in that production, and their supply has separate choices. The subcontractor can provide a component, the company can keep its own material at the subcontractor for consumption, or it can transfer components for a particular order. Those choices answer who provides the material and how it reaches the operation. WIP movement answers where the unfinished product is. The two can share a physical journey without becoming the same accounting process. So we must not apply “no WIP reservations” as a blanket statement about the company’s component supply.

• Transfer WIP items between subcontractors
• Manage components in subcontracting

That helps explain why a single “send to subcontractor” instruction can hide two questions. Has the unfinished assembly reached them, and do they have the materials needed to work on it? If the company keeps a supply of components at the specialist, there may be no reason to send a fresh box for each assembly. But somebody still has to make sure that supply does not run out.

• Manage components in subcontracting

Exactly. With company-owned consignment stock at the subcontractor, keeping it replenished remains the company’s responsibility. That is different from the vendor supplying the component and different from transferring the quantity for an individual order. For our assembly, I would make those two lines of responsibility visible: who confirms the unfinished product’s arrival, and who ensures the components are available. A receiving record for the assembly answers only the first question. This is why I would sketch the actual material flow before choosing the setup. Two boxes on the same pallet can represent two different responsibilities.

• Manage components in subcontracting

So there is a useful fit here without pretending it is a complete traceability system. Before we leave our assembly, what must already be in place? I would hate for someone to hear “new pick action” and expect a button that understands their subcontractor, routing and warehouse all by itself.

• Set up subcontracting

The Microsoft Subcontracting extension and the production setup matter. The subcontractor needs the appropriate vendor, work center and location relationships, and the routing must describe the outside operation correctly. There is assisted setup, but it is help with configuration, not proof that the company’s process is ready. I would take one ordinary journey and one awkward return through it before rollout. Also, open WIP transfer orders prevent finishing the production order. That gives the unfinished movements a consequence: someone must resolve them, rather than closing production and forgetting that part of the journey is still open.

• Transfer WIP items between subcontractors
• Set up subcontracting

That gives the production team a reason to look at the unfinished movements before closing. Where do they actually see them? I would want the check to be part of finishing the order, rather than a separate spreadsheet that happens to know where the assembly went. And if the record still shows something away, can cleanup simply clear it?

• Transfer WIP items between subcontractors

They can open the subcontracting WIP entries from the production order, and the routing lines show quantities at the subcontractor and in transit. That puts the question beside the work being finished. There is also optional WIP quantity cleanup when finishing production: it creates balancing adjustments for remaining quantities. I would use that only after establishing what happened physically. A balancing entry cannot tell you whether an assembly came home, was scrapped or still needs attention. The useful sequence is to account for the work, resolve the movement records and then finish with the appropriate adjustments. A zero balance should reflect an understood outcome.

• Transfer WIP items between subcontractors

That gives the improvement a very practical shape. The receiving team can work with the unfinished assembly, production can follow its whereabouts, and finishing the order has a proper physical check behind it. I would start with that shared journey: show both teams the same example and agree what each handoff means. The benefit is strongest when they can answer where the work is without reconstructing the trip from messages.

• Update 29.0 for Business Central 2026 release wave 2
• Transfer WIP items between subcontractors

Now, a different kind of unfinished business: a posted number that turns out to be wrong. Business Central 29 introduces a reversal action for sustainability ledger entries. This is about correcting recorded sustainability data, not another way of calculating emissions. And the source of the entry matters. Alex, why does a journal entry get a different correction route from an entry created by a purchase document?

• Update 29.0 for Business Central 2026 release wave 2
• Chart of sustainability accounts and ledger — reversal

Because the correction needs to respect the transaction that created the record. The new action can reverse eligible entries from a sustainability journal or a general journal. For a document-origin entry, the documented route is a corrective document instead, such as cancelling or correcting the purchase invoice or creating a corrective credit memo. Suppose someone posted the same journal measurement twice. Reversing the duplicate is a direct way to counter that entry. But if the problem is a purchase invoice, treating its sustainability entry as a free-standing journal error would ignore the document that still exists behind it.

• Chart of sustainability accounts and ledger — reversal

So I should ask where the number came from before asking which button will remove it. And “remove” is probably the wrong word there. If I reverse the duplicate journal measurement, does the original disappear from the ledger, or do we retain a visible record of the mistake?

• Chart of sustainability accounts and ledger — reversal

We retain it. Business Central creates a linked reversing entry with the opposite values. The original and the reversal remain connected, and the reversal records who made it. It also retains the original posting date and document number. That is useful when someone later asks why the total changed: there is a correction to follow, rather than a missing line to explain. It is still important to identify the right duplicate. The action supplies the reversal mechanism; it cannot decide which of two apparently similar measurements represents the real event.

• Chart of sustainability accounts and ledger — reversal

There is another reason a total might look wrong, though. The measurement could be correct, but the company now uses a different emissions factor. It would be tempting to reverse and assume the system recalculates with the latest setup. Does this action revisit the calculation, or does it counter what was actually posted?

It counters the recorded values. It does not recalculate the carbon equivalent or the carbon fee using today’s setup. That is exactly what you want for cancelling the effect of a particular entry: the reversal should offset that entry, not a newly calculated approximation of it. If the business needs a replacement based on corrected input or a revised factor, that is a further accounting decision and posting process. We should not hide that second decision inside the word reverse. Your example changes the question from “how do I remove a duplicate?” to “what corrected record should replace the original?”

• Chart of sustainability accounts and ledger — reversal

That is a distinction I would want visible in the work instruction. Otherwise the reassuring part—the original has been reversed—could conceal that nobody has posted the corrected information yet. What happens if the entry also has a financial side? Is reversing the sustainability entry enough to put both sets of records right?

No. This action reverses sustainability ledger entries only. It does not reverse general ledger entries, sustainability value entries or the source documents. The boundary also works the other way: reversing a general ledger transaction does not automatically reverse its sustainability entries. So the person correcting the mistake needs to know which records were affected. I would not turn that into a warning that every correction is complicated. A simple journal duplicate can still be simple. But where one event has financial and sustainability consequences, somebody needs to own the complete correction rather than assume one successful action did all of it.

• Chart of sustainability accounts and ledger — reversal

Let’s make that ownership practical. Someone selects several mistaken journal entries for reversal. I would rather discover an invalid account before half the selection is corrected and half is not. Does the action check the whole selection first?

Yes. The documented action validates all selected entries before performing any reversal. Already reversed entries are not eligible, and the account and dimensions must still be valid. The user also needs Sustainability–Edit or equivalent permission. So an invalid selection should send you back to understand the validation problem, not to assume a partial batch succeeded. For the account setup, this includes an appropriate unblocked direct-posting account and valid category and subcategory. Those details belong in the procedure, but the useful behavior is the all-selected-entries check before the reversal begins.

• Chart of sustainability accounts and ledger — reversal

My starting point would be the entry and what created it. Once we know that, the correction has a much clearer path: an eligible journal reversal here, a document correction there, and a separate decision where corrected information needs posting. The useful gain is being able to put the record right while leaving an explanation that the next person can follow. That is a good reason to revisit the correction procedure when adopting version 29.

• Update 29.0 for Business Central 2026 release wave 2
• Chart of sustainability accounts and ledger — reversal

Here is a change that could remove a small but recurring handoff. Business Central 29 adds APIs for Report Inbox output. In plain language, another system can retrieve information about reports already in the inbox and obtain their generated content. The inbox itself is not new. The interesting part is making that completed output available programmatically. Alex, when is that more useful than just running a report again in the other system?

• Work with report inbox items through the API
• Get report inbox content through the API
• Share and export reports with the report inbox

When the thing you want is the report that Business Central already produced, rather than a new calculation of similar data. Suppose a company schedules an exceptions report and wants the resulting file in a shared review process. A person might otherwise open the inbox, find the output and move it elsewhere. The new APIs give an integration a way to retrieve that existing artifact. That is different from querying live records and rebuilding the report, and different again from asking Business Central to execute a report. The distinction matters when the people reviewing the result need the same output that was generated for that particular run.

• Get report inbox content through the API
• Share and export reports with the report inbox

I like removing the person whose unofficial job is “move the report before everyone else arrives.” But they may also be doing a quiet bit of judgment: checking that it is the right company, the right period and the right run. If we automate only the copying, we could make the wrong report arrive very efficiently. What can the integration actually inspect?

The items interface exposes metadata such as the company, report identity and name, creation time, output type, filename and read status. The content interface provides the generated content and information including its filename, type and size. Those help an integration identify and retrieve a file, but they do not remove the need to define which report run the business expects. Creation time tells us when the entry was created; it does not, by itself, prove which accounting period the numbers cover. So your quiet judgment needs to become an explicit selection rule, not disappear when the copying becomes automatic.

• Work with report inbox items through the API
• Get report inbox content through the API

Then I would make the expected output quite specific. Not “send us the newest spreadsheet,” but the agreed report for the agreed company and purpose. There is also a read flag in that metadata. It sounds tempting to use unread as a work queue and mark it read when the integration has collected it. Is that flag enough to tell us the handoff is finished?

• Work with report inbox items through the API

It is a state the API can update, not a complete delivery receipt. Setting it does not prove that a person read the report, that an archive saved it, or that an email reached someone. I would give the integration its own definition of completion. For an archive, that could mean the destination has actually accepted the intended file and the integration has recorded which inbox entry it handled. Only then would I consider updating the source status if that fits the workflow. That is a design recommendation, not a transaction guarantee supplied by the Report Inbox API.

• Work with report inbox items through the API

And if the file is saved but the status update fails, the next run might see it again. That seems like the sort of small interruption that turns a tidy demonstration into duplicate messages for everybody. I would prefer the second run to recognize completed work rather than make the audience our error detector.

That is the interruption I would include in a proposed test. Save the file, interrupt before the status step, then see whether the integration safely recognizes the same work. The endpoint gives access to the report; the integration still owns duplicate handling and recovery at its destination. I would also include the opposite case, where the expected file never appears. Retrieving an inbox entry cannot repair a report that did not run or did not produce output. Looking for the artifact first helps separate a production problem from a distribution problem, instead of sending both teams after the same vague “report missing” complaint.

• Get report inbox content through the API

There is a useful overview endpoint alongside the entry and content APIs. It reports inbox information by company, including entry counts, unread counts and the latest change. For someone supporting a handoff across several companies, that sounds like a better starting point than opening files at random. How much does that overview actually tell them about the missing report?

• Work with report inbox companies through the API

It gives them a company-level picture of the inbox: how many entries are there, how many are unread and when its information last changed. That can help narrow where to look. But a count of five does not identify the particular exceptions report the review team expects. The next step is still to inspect the relevant entries and obtain the intended content. I would use the overview to make support more focused, not as a substitute for selecting the report. It is rather like knowing there is post in the building: useful information, but you still need the right envelope.

• Work with report inbox items through the API
• Get report inbox content through the API
• Work with report inbox companies through the API

Before we build anything, though, does the inbox contain every report somebody has printed or downloaded? Because that is quite a different promise from scheduled output. A listener might reasonably think “Report Inbox API” means a history of all the reports people have produced.

It does not mean that. The existing inbox is for generated scheduled reports, not a complete history of earlier Print actions or reports downloaded from the Reports menu. Start by checking that the output you want is actually there. Also, the documented output types include PDF, Word, Excel and ZIP, but that does not mean every report can generate every format. The receiving system has to work with the output the report actually supplies. A new retrieval API is useful precisely because it can reuse that existing result; it is not a new universal report converter.

• Get report inbox content through the API
• Share and export reports with the report inbox

I can see two useful choices now. For a regular review pack, an integration could take over a repeated handoff with explicit selection and completion rules. For the occasional file, the inbox already offers sharing, including OneDrive. I would choose according to how often the handoff happens and what the recipient needs, rather than assume automation is always the more grown-up answer.

• Work with report inbox items through the API
• Get report inbox content through the API
• Share and export reports with the report inbox

Frequency and the recipient’s need are good starting points. For occasional sharing, remember that the OneDrive file is a separate copy: it does not create an inbox entry for the recipient, and expiry of the Business Central entry does not automatically remove that shared file. For a recurring integration, agree who may access the report and what happens to copies after retrieval. Authentication and the appropriate access still apply. With those responsibilities clear, the new API can make the regular handoff part of a dependable process while the simpler sharing route remains useful for the occasional request.

• Work with report inbox items through the API
• Share and export reports with the report inbox

You do not need an integration project to meet our next subject. You only need to search a list and wonder why the record you know exists is not appearing. Modern list search is an existing, production-ready preview, not a new Business Central 29 search engine. What has changed in the upgrade guidance is the deadline for mandatory use: Microsoft moved it from version 29 to version 30. That gives us a useful reason to understand its behavior now. Alex, what is different about the matching?

• Sort, search, and filter data in lists, reports, or XMLports
• Optional features that are now mandatory
• Enable optimized text search on table fields

Modern search works with words and word prefixes, and the words do not have to be in the same order. Imagine an eligible description field containing “blue office chair.” Searching for “chair blue” can still find it. That is convenient when you remember the important words but not how somebody arranged the description. It is not simply looking for any sequence of characters anywhere inside a field. That distinction can explain why a familiar shortcut stops giving the result somebody expects. The search has changed its matching rules, not necessarily lost the record.

• Sort, search, and filter data in lists, reports, or XMLports

The order flexibility is easy to appreciate. I might remember the color and the object, not the exact description. But take the word chair. If somebody has a habit of typing the last four letters, “hair,” because it was enough before, modern search is not going to interpret that as the start of chair?

• Sort, search, and filter data in lists, reports, or XMLports

Correct. “Hair” is not a prefix of “chair,” so that is not the match to expect. A word prefix starts at the beginning of the word. If order matters, quotation marks let you narrow the search to an exact phrase. Those are useful distinctions to show with the company’s own familiar descriptions. People do not need a lecture on search technology to adapt. They need to see why one term finds the item and another does not, especially where an old typing habit was relying on a fragment in the middle of a word.

• Sort, search, and filter data in lists, reports, or XMLports

I would also want to know whether the field I am looking at is even part of that search. If the number or reference is visible in a column, it is natural to assume typing it into the list search will find the row. Does visible mean searchable here?

Not automatically. Modern search uses columns that developers have designated for it. A field being shown on the page is not, by itself, evidence that it participates. That is particularly worth checking for custom fields that have become important to a company’s daily work. If a team always finds orders by its own reference field, include that field in the adoption discussion. Otherwise you could demonstrate modern search with a standard description, declare it successful, and miss the reference that the team actually uses throughout the day.

• Sort, search, and filter data in lists, reports, or XMLports

That makes the best demonstration rather less glamorous: ask someone what they normally type, and use that. Here is another everyday moment. A colleague changes the description, tells me the new wording, and I search immediately. If it does not appear, have we found a configuration problem?

Not necessarily. The search index is updated in the background, usually within seconds, so a very recent change can briefly lag behind. That does not prove a particular missing result is caused by indexing, but it gives you a sensible first distinction: was the data just changed, or has it been there for a while? Then consider whether the field is eligible and whether the search term follows the word-matching behavior. Microsoft also recommends trying legacy search when known data is not found. That comparison can help you investigate without immediately treating the record itself as missing.

• Sort, search, and filter data in lists, reports, or XMLports

I am glad you kept “can help investigate” in there. Finding the row another way tells us it exists; it does not tell us which setting is wrong. What if the modern-search option is not present at all? Someone may hear this discussion and conclude they are missing the feature because their environment has not reached version 29.

• Sort, search, and filter data in lists, reports, or XMLports

That would be the wrong conclusion from the missing option alone. This capability predates version 29. The feature may not be enabled, or that list may not have fields designated for modern search. When enabled, modern search becomes the default. So the useful check is the feature and the particular list, not just the version number. And we are talking about matching data in lists, not the separate Tell Me experience for finding pages and actions. Calling all of it “the new search” makes support conversations harder than they need to be.

• Sort, search, and filter data in lists, reports, or XMLports
• Enable optimized text search on table fields

The move to mandatory use in version 30 is therefore breathing room, not a reason to put the subject in a drawer. I would use it to gather a handful of real search habits: names, references and descriptions, including the awkward ones. Is that a more useful preparation than asking whether the new search is universally faster?

• Optional features that are now mandatory

Much more useful. A general speed claim does not tell the order desk whether its reference can be found. I would compare those representative searches on the lists the team actually uses, note which fields are involved, and explain any changed typing behavior. There are deeper administration choices, including indexing language; changing that triggers a background reindex across the environment and deserves its own planning. For the team, success is simpler: they can find their usual records and understand the few habits that need changing. That is a concrete result to aim for before version 30 makes the transition mandatory.

• Sort, search, and filter data in lists, reports, or XMLports
• Optional features that are now mandatory
• Configure text search language for multilingual environments

One smaller discovery to finish. Since April, in Business Central 28, posted sales shipments and return receipts have email actions, including Send by Email and Attach as PDF. This is not an October launch. It is worth noticing because the person who needs shipping information is not always the person who receives the invoice. Alex, where does that help in an ordinary day?

• Send posted sales shipments and return receipts by email
• Update 28.0 for Business Central 2026 release wave 1

Imagine a company has posted a shipment, and the customer’s receiving team needs the document to prepare for the goods. The finance team may invoice later or send the invoice to a different contact. Sending the posted shipment gives the operational conversation its own document and recipient. For a return, the posted return receipt can support the corresponding communication about what the company has received. You do not have to make invoice communication carry every message. The benefit is fairly modest, but it can remove the detour of exporting a document and composing an unrelated email just to send the same information.

• Send posted sales shipments and return receipts by email

That is exactly the sort of improvement that can be useful without needing a grand name. But I would not want it to quietly send a warehouse document to the accounts-payable mailbox simply because that is the customer’s usual email address. Does the new action decide the operational contact for us?

The recipient still needs choosing correctly. The standard document-email flow can use defaults or let the user review recipients and settings, and the email configuration and intended report layout need to be in place. I would check one actual document layout with the people receiving it: does it show the shipment information they need in a form they can use? Then agree the routine with the person sending it. A supported action, the right layout and a clear recipient can be enough to make that everyday communication easier.

• Send posted sales shipments and return receipts by email
• Send documents and emails

And having the action is not the same as sending automatically whenever a shipment is posted. I would keep that distinction very visible. Someone still needs to know whether the message was sent, failed, or remains a draft. Otherwise we have only moved the uncertainty from “where is the PDF?” to “did anyone receive it?”

• Send posted sales shipments and return receipts by email
• Send documents and emails

Yes. Check the email outcome rather than infer it from the document action. The outbox includes drafts and failed messages, while sent messages have their own view. Even a sent message is not proof that the intended person read it, and the shipment document is not proof of physical delivery to the customer. For a routine handoff, the practical arrangement can stay simple: agree which posted document to send, to whom, and who follows up if sending fails. The improvement is that Business Central now provides the relevant sending actions directly on those posted documents.

• Send posted sales shipments and return receipts by email
• Send documents and emails

That is a good place to leave it. We explored Business Central 29’s new inventory activities for subcontracting, its correction route for eligible sustainability entries and its access to completed report output. We also found that search behavior deserves a practical rehearsal before the version 30 transition, and that an older shipping-email improvement may already save a detour. The useful question is not just whether a feature exists, but whether its result reaches the right person in the right form. The direct sources and deeper details are in the episode notes. Thanks for listening to Central Perspectives from ITrators.

• Update 29.0 for Business Central 2026 release wave 2
• Work with report inbox items through the API
• Optional features that are now mandatory
• Send posted sales shipments and return receipts by email