Justin, in the RAD application sla.refresh.active on the panel set.expiration, the slaactive next breach field gets set under this condition
if
(not null(expiration.time in $L.sloresponse) and expiration.time in $L.sloresponse>$L.tod and current.status in $L.sloresponse=2) then if (nullsub(suspended in $L.sloresponse, false)=false) then (next.breach in $L.active=min(expiration.time in $L.sloresponse, nullsub(next.breach in $L.active, expiration.time in$L.sloresponse)))
to the min() of expiration time in sloresponse and the current next breach (if not null).
The expiration.time in sloresponse is set on the same panel:
if
(null(expiration.time in $L.sloresponse) and not (current.status in $L.sloresponse=5 or not breached in $L.sloresponse and suspended in $L.sloresponse)) then (expiration.time in $L.sloresponse=$L.expiration.date)
$L.expiration.date contains the value of:
[nullsub($L.nexttobreachstarttime, nullsub($L.laststarttime, $L.tod))] +
[$L.allowed.time - nullsub($L.nexttobreachduration, nullsub($L.laststartduration, $L.duration))]
or in simple terms, the expiration date of the sloresponse record is calculated (based on a working calendar) as
tod() or start of the next calculated breach PLUS the allowed time for responding to the issue MINUS the duration to the next known breach / duration to alert time. (If I interpreted it all right).
What I find is that the next.breach is only filled, when the schedule record for that breach is in the schedule file. Can you check if you have SLA breach schedule records?
