[Extensibility] Manufacturing cost calculation - missing events for split Setup / Runtime cost in BC 28

[rickblommetjes]

Summary

Business Central blends Setup Cost and Runtime Cost into a single Direct Unit Cost on Work Centers / Machine Centers. For make-to-order manufacturers, this produces inaccurate per-unit costs when lot sizes vary, because setup cost is fixed per run while runtime cost scales with quantity.

We are implementing a Setup Cost vs. Runtime Cost split entirely via event subscribers (no base object modifications), but we have hit extensibility gaps in BC 28 that block a clean implementation.

---

Top-priority gaps (High severity)

1. Missing integration events in CalcRtngCostSKU ΓÇö ≡ƒö┤ High

The SKU-specific routing cost code path (CalcRtngCostSKU) has no integration events, so ISVs cannot inject split-cost logic for SKU-level calculations. The standard CalcRtngCost path has events, but the SKU variant is entirely opaque.

Ask: Add OnBefore / OnAfter (with IsHandled) integration events to CalcRtngCostSKU, mirroring what already exists in CalcRtngCost.

3. OnAfterCalcRtngLineCost does not expose DirUnitCost ΓÇö ≡ƒö┤ High

The event OnAfterCalcRtngLineCost fires but omits the DirUnitCost parameter. Subscribers must redundantly recalculate it, which is fragile and error-prone.

Ask: Add DirUnitCost (and ideally SetupCost / RunCost) as VAR parameters to OnAfterCalcRtngLineCost so subscribers can both read and override the value without re-deriving it.

---

Additional gaps (Medium / Low severity)

#	Gap	Severity
2	CalculateCostTime returns a single combined value; ISVs must call it twice and reverse-engineer setup vs. runtime portions	Medium
4	CalcProdOrderLineExpCost lacks OnBefore / IsHandled and per-line split support; no clean override point for expected cost calculation	Medium
5	Standard Cost Worksheet extensibility relies on indirect event subscriptions that could break silently	Low

---

Context

• AppSource ISV: Easystep2 BV (Easy Manufacturing extension)
• BC version: 28
• Implementation approach: 100% event subscribers, no base object modifications
• Use case: Make-to-order manufacturers needing accurate per-unit cost across varying lot sizes

These are all small, non-breaking additions (new parameters to existing events, new events on uncovered code paths). They follow the existing patterns already established in the manufacturing cost codeunits.

Thank you for considering this!
Internal work item: AB#636806

[AleksandricMarko]

Hi @rickblommetjes,

Thank you for your extensibility request. To help us process it efficiently, please update the issue to include the required information.

📚 Extensibility Guidelines

This issue contains multiple distinct request types:

• Event requests (gaps 1, 3, 4): New integration events and adding parameters to existing events
• Extensibility enhancements (gaps 2, 5): General design improvements without specific event/enum asks

Please create separate issues for each gap to ensure proper processing and tracking. Each issue should focus on a single change in a single procedure/codeunit.

Missing Information:

For new event requests with IsHandled (gaps 1, 4):

• Proposed code change: Exact code addition with 5-10 lines of surrounding context showing where the event fires
• Exact location: Codeunit name and number, procedure/trigger name
• Alternatives evaluated: Which existing events/patterns were tried and why they are insufficient
• Justification for IsHandled: Why a standard event (without bypass) isn't sufficient — specific technical reason with concrete business logic that must be skipped/replaced
• Performance considerations: Expected execution frequency and potential impact
• Data sensitivity review: Confirmation of no sensitive data exposure, or rationale if necessary
• Multi-extension interaction: Risks if multiple extensions subscribe, and conflict mitigation

For adding parameters to existing events (gap 3):

• Exact location: Codeunit name and number where OnAfterCalcRtngLineCost is declared

For extensibility enhancements (gaps 2, 5):

• Specific enhancement: Exact code changes or design modifications proposed
• Technical justification: Specific technical limitation and proposed solution

Please update the issue with the missing details. We'll automatically re-analyze once updated.

Note

Automatically generated by the Triage Agent — advisory only. An engineer will review before any action is taken.

Tip

Not accurate? Reply with /not-accurate (optional: add a short explanation). Your feedback improves future responses.

[rickblommetjes]

Aaah no go they are linked as one solution. So please keep them as one single solution so we can test and review the full flow

[AleksandricMarko]

Hi @rickblommetjes,
In that case you will get it in BC 29
As only new/updated events we ship in minor versions, other things in major.

[rickblommetjes]

No problem, as we should make sure we aligned during the process. We can help with this of cause