after_relationship_add - Order Process

Hi everyone.

I have written a logichook on "after_relationship_add". What this does is calculates the split % of the added item. For example I have 1 Opportunity for £100, I have 10 Revenue Line Items linked, so the split on each item is 10%.

If I add an 11th item, the split should become 9.09%. However when checking the "count" of related records, it seems to differ on whether I've added an existing Revenue Line Item or an Existing One.

If I add the item, running the code returns the correct amount, if I create a new one, it shows one too few (The new record is missing).

The code example is:

$link = "ccs_clientcostsplit_revenuelineitems";
if ($bean->load_relationship($link)) {
//Fetch related record IDs
$linkedSplits = $bean->$link->get();
$splitPercent = 100 / (count($linkedSplits)); 
foreach($linkedSplits as $split)
{
	$linkedSplitBean = BeanFactory::retrieveBean("CCS_ClientCostSplit",$split, array('disable_row_level_security' => true));
	$linkedSplitBean->percent_split = $splitPercent;
	$linkedSplitBean->save();
}

I'm doing this on an after_relationship_add module hook, but it seems to differ. I've tried checking if $bean->id is there, but it seems the record is created but not linked on the point of after_relationship_add.

Any help at all would be great.

Thanks,

Daniel

Parents Reply Children
  • It is an option but, being pragmatic, it "could" lead to a performance degradation once the formula must be configured at the RLI layer, so for each RLI it must count how many RLIs are associated to a given Opportunity and then it must divide the values.

    Anyway, it would affect only the last added RLI, unless it is configured on the Opportuniy an Integer number which calculate how many RLIs it has and the formula at the RLI level will calculate over this field.

    Anyway it will redo the calculation for each RLI which may lead to a performance degradation.

    I agree with you that we must consider OOTB techniques, but there are situation where they may not be the best approach given all the variables behind.

    André Lopes
    Lampada Global
    Skype: andre.lampada