Before Insert Business Rule not working as expected

SnowSB · ‎11-25-2023

Hi,

I am trying to populate the 'fiscal period' on Requested allocation based on start date and end date through before Insert/Update BR but it's not working. This BR is not running at all. Can someone please help me with this ?

Requested allocation record gets created when we submit resource plan.

Brad Bowman · ‎12-04-2023

This is likely related to the timezone offset pointed out below. To work with the other field formats, the script would look like this:

(function executeRule(current, previous /*null when async*/ ) {
	var AllocStartDate = new GlideDateTime(current.start_date)
	AllocStartDate = AllocStartDate.getDate().toString().replace("-","") + "T000000";
    var AllocEndDate = new GlideDateTime(current.end_date)
	AllocEndDate = AllocEndDate.getDate().toString().replace("-","") + "T235959";
    var fsp = new GlideRecord('fiscal_period');
    fsp.addEncodedQuery("start_date_time<=" + AllocStartDate + "^end_date_time>=" + AllocEndDate + "^fiscal_type=quarter");
    fsp.query();
	gs.addInfoMessage("Allocation Date Range " + AllocStartDate + ' - ' + AllocEndDate)
    if (fsp.next()) {
        current.u_fiscal_period = fsp.sys_id;
        gs.addInfoMessage("Inside if : " + current.number);
    } else {
        gs.addInfoMessage("Inside else : " + current.number + " : " + current.start_date + " : " + current.end_date);
        //gs.addErrorMessage("Due to allocation mismatch, could not populate fiscal period.");
    }
})(current, previous);

If this still isn't working for all fiscal periods in your environment, I'll check it out in your PDI and likely go back to the other date fields with a timezone offset, if that's the issue.

View solution in original post

SnowSB · ‎11-28-2023

@Brad Bowman I have re-created this in PDI, please let me know if you want to have a look.

Brad Bowman · ‎11-29-2023

Yes, I can take a look at your PDI as my test mock-up is not doing the same.

Brad Bowman · ‎11-29-2023

Upon further review, my instance was behaving the same way. The extra record is due to omitting the () in the next method. I also had to change the order of this Business Rule to something higher (1000) than the other so that it wouldn't run before the allocation record was created. Once it logged the correct allocation number inside the if next() it still wasn't updating the allocation record. Apparently .update() doesn't force an update if there are no changes, so short of a way to do that, a data change with an update then putting it back and another update are needed, so something like this:

(function executeRule(current, previous /*null when async*/) {
	var ra = new GlideRecord('requested_allocation');
    ra.addQuery('resource_plan', current.sys_id);
	ra.query();
	if (ra.next()) {
		var hrs = current.requested_hours;
		ra.requested_hours = hrs - 1;
		ra.update();
		ra.requested_hours = hrs;
		ra.update();
	}
})(current, previous);

SnowSB · ‎11-30-2023

Hi Brad,

I tried this solution and It is partially working. Below are some issues.

1. Fiscal Period is getting generated only for the last requested allocation for the resource plan. All other allocations are not populated with Fiscal period.

2. As we are updating requested_hours field through this BR, log is getting generated in the Response Plan Logs related list on the Response Plan. Log is saying "Requested Allocation from 2023-12-01 to 2023-12-31 is updated to hours."

Brad Bowman · ‎12-01-2023

I haven't used Resource Plans that much. If you are saying there is a possibility of more than one Requested Allocation automatically getting created when a Resource Plan is created, then change

 if (ra.next()) {

to

while (ra.next()) {

to force the updates on every Requested Allocation record that is linked to the newly-created Resource Plan.

On the second, we could try to find the BR that is generating that log and make it not do that, or change this BR to update a different field. A field that you're not using, or something that doesn't generate a log, like maybe fte, percent_capacity, man_days, or better yet set u_fiscal_period to a hard-coded sys_id, then you won't need the second update to revert it since the other BR will update it.