Submitted by Armando on 2014/08/03 20:16
Hello,
 
These have been plaguing column equations (both conditional and normal ones) for a long time.
I hope they can all be fixed without breaking other calculations as they make dealing with column equations a bit of a gamble.
 
I know I've described them all a while ago, but here's an updated description. I really tried my best to be as precise as possible and I believe everything I mention is important to really understand each problem.
 
If something isn't clear, please ask for details.
 
(The first one is the longest to explain. Other ones have much shorter descriptions)
 
 
1- When all subs are removed under an item or when an item is deleted and no other item meets the condition (in the case of conditional equations), the parent value is always deleted, regardless of other factors.
 
While I somewhat understand why IQ does that, deleting the parent value shouldn't be automatically performed (in the situation described above) , as it might erase values which have been put there:
 
     a- manually (so those are discrete, original and completely lost if they are deleted)
     b- by a row equation (yes, row equations shouldn't have priority... except when there's nothing to calculate in the column equation),
     c- or by an auto-assign equation (same justification as above). 
 
IMO, when an item is removed, IQ should check whether
 
     1- other sub-items meet the condition
     2- if the item to be removed meets the condition
     3-  "For row and hierarchy equations, treat "no values" as 0" is unchecked (in field management dialog/window)  
 
If none of these apply (#1 & #2, especially, and #3 when there are no values in other siblings) , IQ should most probably leave the parent value unchanged. Otherwise, yes, delete it (i.e. update the column equation)...
 
(In other words : while it's good that item deletion is treated as putting a field value to "0", that "0" shouldn't be always taken into account n a conditional equation since it might not always meet the condition.)
 
 
[Note that this also affects normal column equations ; However, contrarily to the other bugs, it's more of a problem for conditional equations since non conditional equations should always be updated -- there aren't any conditions! However, when the "For row and hierarchy equations, treat "no values" as 0" is unchecked, even normal column equations parents fields should be left alone, if there are no values to calculate... IMO] 
 
Careful, as this bug was probably created by trying to fix another one: hierarchy equations not triggered when child value deleted [partially fixed]
 
 
2-  When a subitem meeting a column equation's condition is moved from under the parent (i.e. moved away), the  calculation isn't updated (it stays unchanged, which shouldn't be).
[This is also a problem with normal column equations]
 
 
3- Related to #2 : when an item is moved under a parent (subject to a column equation), the calculation isn't updated.
[This is also a problem with normal column equations]
 
 
4- If items meeting the conditions of a column equation are pasted under a parent, the calculation isn't updated either
[This is also a problem with normal column equations]
 
 
5- It's impossible to manually recalc a column if there's a simultaneous column ROW equation : the total always = row equation result. (Shouldn't be. Column should always have priority over row -- well in 99.9% of cases... And taking into account what has been mentioned in bug #1).
[This is also a problem with normal column equations] 
(My guess is that this bug also happened when trying to fix another bug, a long time ago : [major] Problem with column/row equation -- please read-on   ...  So again... careful.) 
 
 
I've tested those many times, but if some user has the patience and courage to try/corroborate them all, I'd feel less lonely. 
 
[EDITED 2014-08-03  20:30:02 : added a few details, especially concerning "For row and hierarchy equations, treat "no values" as 0" in bug #1 ]

 
[EDIT ; 2015 04 11 - added parts from a post below]

There are 2 other situations where it could work better though, following my "recommendations"
 
The 2 main rules were :
 
1- Column equations should always have priority over row equations
2- Column equations shouldn't consider a "null" result as valid and supersede row equations results (hence emptying the field...). In these cases, Row equations should have priority and supersede the "null" result of the Column equations(i.e. :  if there are children with null values under a parent, the "null" result shouldn't supercede the row equation and erase it.)
 
First situation : using touch
 
These 2nd rule don't work when I  "touch" a Sub item field which = null,  involved in a column equation. The column equation supersedes the row equation, even if the result is null. IMO, that shouldn't be. But I'd be happy to hear other points of view.
 
 
Second situation (related to the first one)
 
erasing all SLIs values  (column equation =  null)  result in an unchanged parent value even if its row equation should show some result.
(i.e. : the row equation isn't recalculated and it should since there are no values for the column equation)
 
When all SLIs values from a field involved in a column equation are erased : the result of the column equation is null and the good thing is that the Parent's value isn't just changed to a null value. However, the row equation for that parent isn't recalculated following rule #2, even if it should.
 
 
Third situation (related to the previous one, probably)
 
Erasing all sub items (column equation =  null)  will delete (=null) the previous parent value, even if its row equation should show some result.
(i.e. : column equation = null and the row equation isn't recalculated... And it probably should )
 
 
Is that clear ?

Comments

Hi Armando,
 
Thanks for the detailed description. I'll bump these issues to the top of the list.
 
Pierre_Admin
 

Armando

2014/08/04 10:47

In reply to by Pierre_Admin

Thanks!
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Armando

2014/08/04 19:28

In reply to by Pierre_Admin

I'll quote a part of one of the 2 other thread mentioned above since it describes other important situations that should be taken into account while fixing the other bugs.
 
[quote=armando]
There are 2 other situations where it could work better though, following my "recommendations"
 
The 2 main rules were :
 
1- Column equations should always have priority over row equations
2- Column equations shouldn't consider a "null" result as valid and supersede row equations results (hence emptying the field...). In these cases, Row equations should have priority and supersede the "null" result of the Column equations(i.e. :  if there are children with null values under a parent, the "null" result shouldn't supercede the row equation and erase it.)
 
First situation : using touch
 
These 2nd rule don't work when I  "touch" a Sub item field which = null,  involved in a column equation. The column equation supersedes the row equation, even if the result is null. IMO, that shouldn't be. But I'd be happy to hear other points of view.
 
 
Second situation (related to the first one)
 
erasing all SLIs values  (column equation =  null)  result in an unchanged parent value even if its row equation should show some result.
(i.e. : the row equation isn't recalculated and it should since there are no values for the column equation)
 
When all SLIs values from a field involved in a column equation are erased : the result of the column equation is null and the good thing is that the Parent's value isn't just changed to a null value. However, the row equation for that parent isn't recalculated following rule #2, even if it should.
 
 
Third situation (related to the previous one, probably)
 
Erasing all sub items (column equation =  null)  will delete (=null) the previous parent value, even if its row equation should show some result.
(i.e. : column equation = null and the row equation isn't recalculated... And it probably should )
 
 
Is that clear ?
 
[/quote]
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Friendly reminder/bump to the top... for a fix to these 5 issues.
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Armando

2014/09/08 20:21

In reply to by Armando

Why do I think that those are damn important to fix ? Simply because these bugs endanger data integrity (when data can be (or is) affected by column/row equations, of course).
I really hope it can make it in V33, or at least 34. 
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Hi Pierre,
If fixes for those problems could be soon provided, it would be greatly appreciated.
Nobody else corroborated their existence, but I'm pretty comfident they exist...
Thanks!
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz

Bumping that up. It's tax time and it would be good if I could manage that without headaches this time!
Thanks!
 
-------------------------------------------------------
Windows 8.1
Sony Vaio S Series 13 (SVS131E21L)
Ram:8gb, CPU: Intel i5-3230M, 2.6ghz