You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 19, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 19, 2026. It is now read-only.
[Extensibility Request][NL][Report][99001046]["Calculate Work Center Calendar"] Publisher request for consolidated calendar entry creation #30433
When consolidated work center calendar entries are generated in report 99001046 "Calculate Work Center Calendar", there is currently no event that allows modifying the generated Calendar Entry before it is inserted.
We have a scenario where information from the source machine center calendar entry must be transferred to the consolidated work center calendar entry. Specifically, we need to preserve the Work Shift Code from the source entry.
The current implementation clears the Work Shift Code and does not expose an event that allows partners to adjust the generated record before insertion.
An event that exposes both the source Calendar Entry and the generated consolidated Calendar Entry would enable this scenario and similar scenarios where additional metadata must be copied or derived from the source entry.
Describe the request
We require a publisher that allows overriding the Work Shift Code with our own logic.
[IntegrationEvent(false, false)]
local procedure OnBeforeInsertConsolidatedCalendarEntry(
var SourceCalendarEntries: Record "Calendar Entry";
var ConsolidatedCalendarEntry: Record "Calendar Entry")
begin
end;
Calendar.SetFilter("Starting Time", '<=%1', LastTime);
Calendar.SetFilter("Ending Time", '>%1', LastTime);
if Calendar.Find('-') then begin
Calendar2 := TempCalendar;
Calendar2."Work Shift Code" := '';
Calendar2."Starting Time" := LastTime;
Calendar2.Validate("Ending Time", TempCalendar."Starting Time");
Calendar2.Validate("No.");
Calendar2.Capacity := 0;
repeat
Calendar2.Capacity := Calendar2.Capacity + (Calendar.Capacity - Calendar."Absence Capacity") *
Calendar.Efficiency / 100;
until Calendar.Next() = 0;
if Calendar2.Capacity <> 0 then begin
Calendar2.Validate(Capacity);
// modification begin -->
OnBeforeInsertConsolidatedCalendarEntry(Calendar, Calendar2);
// we would like to achieve:
// Calendar2."Work Shift Code" := Calendar."Work Shift Code";
// <-- modification end
Calendar2.Insert();
end;
end;
1. Justification
The event needs to be raised for each generated consolidated calendar entry because subscribers may need to transfer metadata from the source machine center calendar entry to the individual consolidated calendar entry that is about to be inserted.
Each consolidated interval results in a separate Calendar Entry record. Subscribers need the opportunity to adjust each generated record independently before it is inserted.
Subscribers are expected to modify fields on the generated consolidated Calendar Entry before it is inserted.
2. Behavoir
In our scenario we need to preserve the Work Shift Code from the source machine center calendar entry, but the event could also be used to transfer other metadata from the source entry to the generated consolidated entry.
The event is not intended to replace or bypass standard logic.
3. Expectations
Good point. The proposed SourceCalendarEntry parameter was only intended as an example.
Since a consolidated calendar entry may be derived from multiple source calendar entries, a single source record may not accurately represent the complete context.
To support advanced scenarios, it might be preferable to expose the filtered Calendar Entry record by reference (var) so that subscribers can inspect all contributing source entries and apply their own logic when populating the consolidated entry.
The SourceCalendarEntries parameter is expected to contain the same filtered view that was used to calculate the consolidated calendar entry. Subscribers can then iterate the contributing source records according to their own requirements.
I updated the request (moved publisher to better location and added VAR to the SourceCalendarEntries parameter.
Internal work item: AB#648439
Justification for event firing inside loops: Explain why the event must fire for each consolidated interval in the nested repeat..until loop.
Subscriber behavior: Describe what subscribers are expected to do when this event is raised.
Source record expectations: Clarify whether the source Calendar Entry parameter should be the current Calendar record, even though the consolidated entry capacity may be derived from multiple source entries.
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.
✅ Analysis complete - ready for further processing
Implementation:
Add a new integration event in report 99001046 "Calculate Work Center Calendar" immediately before Calendar2.Insert(); so extensions can inspect the filtered source Calendar Entry set and modify the generated consolidated Calendar Entry before it is inserted.
Location in OnAfterGetRecord() (before Calendar2.Insert();):
Event Publisher (add at the end of the codeunit with other events):
[IntegrationEvent(false, false)]
localprocedure OnWorkCenterOnAfterGetRecordOnBeforeInsertConsolidatedCalendarEntry(var SourceCalendarEntries: Record "Calendar Entry"; var ConsolidatedCalendarEntry: Record "Calendar Entry")beginend;
File:CalculateWorkCenterCalendar.Report.al
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.
The requested change has been implemented in microsoft/BCApps#10899, and the corresponding Azure Boards work item 648439 is resolved as fixed. Closing this issue as completed.
Activity
github-actions commentedon Aug 24, 2026
Hi lv-janpieter,
Thank you for your extensibility request. To help us process it efficiently, please update the issue to include the required information.
📚 Extensibility Guidelines
Missing Information:
repeat..untilloop.Calendar Entryparameter should be the currentCalendarrecord, even though the consolidated entry capacity may be derived from multiple source entries.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.lv-janpieter commentedon Aug 31, 2026
I updated the issue description to address all three questions:
The proposed publisher location was changed and is now raised once per generated consolidated calendar entry immediately before insert.
Please re-evaluate the request.
github-actions commentedon Aug 31, 2026
✅ Analysis complete - ready for further processing
Implementation:
Add a new integration event in report
99001046 "Calculate Work Center Calendar"immediately beforeCalendar2.Insert();so extensions can inspect the filtered sourceCalendar Entryset and modify the generated consolidatedCalendar Entrybefore it is inserted.Location in
OnAfterGetRecord()(beforeCalendar2.Insert();):Event Publisher (add at the end of the codeunit with other events):
File:
CalculateWorkCenterCalendar.Report.alNote
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.JesperSchulz commentedon Sep 3, 2026
The requested change has been implemented in microsoft/BCApps#10899, and the corresponding Azure Boards work item 648439 is resolved as fixed. Closing this issue as completed.
[29.x] Backporting extensibility requests - batch 1751 (#11338)