notice-type 29 - Result and "presetValue"

[elerik]

Hi devs,

with a notice type 29 there are many pre-selected options.
But also if customer (tester) fill only requested fields he will get many errors. Reason is simple. Many pre-selected fields (check image ) request another bunch of data which are not mandatory or conditional mandatory or something like that.

This is pretty confusing for any customer (testers in moment). Like a lot.
Many users are "lazy" and for speed it up they display only mandatory fields. Which makes troubles in cases that there are some requested values under the Result (or LOT/GLO) and are not visible.

You can see that field is not mandatory, not forbidden, simple pre-selected. But it created some additional requests to fill. So far my testers are not very happy with those values pre-filled.

So my question is. Is there any plan to expand this area ? add some conditional mandatory elements and so on ?

Regards

[rouschr]

Hello/Hallo,

I do not know about the implementation of this UI (your application?).
The presetValue is not as easy to use as it seems in the sense that setting it can depend on presence of other fields and there are special cases. As the documentation states there are special values like "_presetValue" : "{NOW}", the "_presetValue" comes from the fields.json file "presetValue" where you can find the associated conditions.
In SDK 1.9 (next SDK to come out) which has attributes information, some "presetValue" cases can be handled fairly easily: the attribute of an element should be filled if the element having the attribute is present.
For other cases it may rely on the presence of several other fields so you will have to evaluate the EFX conditions to decide if the field should actually exist and its presetValue should be set or not.

[elerik]

Hi,
so if your answer means that after v1.9 this group will have some conditions within field.json (like others for example BT-5071-Procedure
where are series of forbidden and mandatory conditions than it would be awesome.

[YvesJo]

Hi,
Indeed, conditional rules forbidding the use of BT-195 in the absence of the target field will be added in SDK 1.9.

[elerik]

Hi,
i have to say that thats a great news.
Than within same group (GR-Result) we have field "BT-13713-LotResult" (I found related topic "BT-13713-LotResult notice subtype 25")
forbidden condition is nice but unreachable (at least within my app because OPT-322-LotResult is hidden so auto-generated) but mandatory (like wrote in mentioned topic)

Lets compare it to some similar field which is "BT-5141-Procedure"
It is also mandatory (no conditions) with conditional forbidden. But this field is not mandatory during validation test
<xsd:element ref="cbc:IdentificationCode" minOccurs="0" maxOccurs="1"/> is possble to see that minOccurs = 0 that means its not so mandatory.
So i mark this as conditional field. With explanation that if its selected it can create some additional data requirements.
But in other handBT-13713-LotResult is required minOccurs = 1 that means always. So its fully mandatory.
Just to be clear. GR-Result has 1 mandatory field (visible) which is "BT-142-LotResult"
From a user perspective if i deselect all presetValues and check validation. Validation still cry. Than I connect it with LOT-1 (BT-13713-LotResult) and send validation again and validation is happy (we all know why). Problem for users is to figure out which field they have to fill or select. First validation return multiple options how to satisfy CVS server. Is it possible that this is a reason why its not fully required because its possible to achieve it in multiple-ways ?

If im right similar situation is again within BT-5141-Procedure. Where selecting this field open two possibilities (Check image story) and when user select one of them second is forbidden.

1. no selection. Fields around are forbidden (forbidden condition fulfilled)
   

2. selected value. Two new options for user which are required
   

3. selected region and last field become optional again and not necessary to fill.
   

Honestly this conditions are awesome feature from SDK and customers really like how it helps them to get through whole form successfully without and troubles (and minimum questions) if they fill some of those fields. With GR-Result they have troubles because they dont have this level of assistance (they are spoiled :D ). I believe that whole GR-Result deserve some attention and with couple of conditions it can be easy like with other Groups.

[YvesJo]

Hi,
Just for clarification, when a field has a forbidden & mandatory properties, and the forbidden one has a condition associated while the mandatory one does not, then the condition is shared by both, of course taking its negated expression for the mandatory property.
In such a case, the field becomes mandatory as soon as it is allowed (i.e. not forbidden)
It is only when the condition for the mandatory property is even more restrictive than the one for the forbidden one that the condition is explicitly specified. In that latest case, the field becomes only mandatory when it is first allowed (i.e. not forbidden) and the additional condition (associated to the mandatory property) is also verified.
Also, the rules are generally built based on an increased precision approach (BT-727 (World, EEA, Country wide) => BT-5141 (Country) => BT-5071 (NUTS) => BT-5131 (City) ...); knowing this may help get the highest benefit from the rules.

[elerik]

when a field has a forbidden & mandatory properties, and the forbidden one has a condition associated while the mandatory one does not, then the condition is shared by both, of course taking its negated expression for the mandatory property.

this is very interesting. I noticed that sometimes there are only conditions for forbidden fields. And mandatory is empty. (Exactly our topic "BT-13713-LotResult")

so you are saying that i can take forbidden condition and revert it and use it as mandatory ? That would be gamechanger.
Because suddenly this field become mandatory under GR-Result notice-type 29.
I accepted those field where any kind of condition is presented (forbidden or mandatory) as conditional. So i dont initially require them from user to fill. Because like i said for example BT-5141-Procedure is also only with forbidden condition but its not necessary to fill it by user to get valid form. So there are technically two identical situations (condition for forbidden, and mandatory for notice-type) But in one case user dont have to fill it and in other case user has to fill it.

[YvesJo]

That's correct. The notices types identifies the notice subtypes it applies to. The noticeTypes list could be shorter for mandatory than it is for forbiden, in which case it would only become mandatory for the common noticeTypes elements and be just optional (given the forbidden condition is not met) for the other ones.