You should ask yourself is this a data layer requirement or a presentation layer requirement.
Does the data need to be only NN.NN or does the user need only see NN.NN and the number can be whatever is needed?
The difference is important because you can adjust the display with Specifying formats for fields containing numbers
and to set things at the data layer requires another technique entirely.
Thanks for your response.
I *think* it's a data layer requirement as this is part of a charge code, and it's split into two parts, one is a 7 digit number which relates to the department being charged and this second field relates to the specific task being performed. The task code is entered into our timesheet system as NN.NN so we want to ensure the user enters the data in the correct format (to ensure they have not mis-understood the data which is required here) so when it is reported on later, the correct billing can be applied.
Hope that explains things better?
I'd say you're actually dealing with text as this part of a charge code not a number that will be used for math. So, I think the below will do the trick.
- Change the field type to text
- Keep your Maximum length of 5 characters
- Change the validation calculation to:
IsEmpty ( Self ); 1; // If empty values aren't allowed, delete this line
Length ( Self ) ≠ 5; 0;
Middle ( Self; 3; 1 ) ≠ "."; 0;
Length ( Filter ( Left ( Self; 2 ); "0123456789" ) ) ≠ 2; 0;
Length ( Filter ( Right ( Self; 2 ); "0123456789" ) ) ≠ 2; 0;
Why not make a tasks table with primary key, task name, and task code and set it up as a value list so a user has to pick from a list of tasks?
That solves the data entry mistake problem and, if set up right, can ensure that the task code selected is always a valid, appropriate value.
This may be the best approach for your solution. Selecting is often better than typing for data entry.
Thanks for the suggestion, but there isn't a fixed list, they vary by department and business, so it would not be that simple, but will suggest it to the product owners and see if it's possible. Thanks.
That looks like it will do the trick, at least until we have decided if a list is feasible! Many thanks.