make fields not editable if line type = Item

Giancarlo

how can I accomplish the following.

in the Sales Order Subform
If Line Type = Item, Then 'Unit Price' and 'Unit Cost' fields editable property = No

My goal is to block people from changing the Unit Price and Unit Cost on the Items Sales Lines.
Each customer already receives a specific price as per their pricing Group.
However, I need to allow the user to enter a 'Unit Price' and 'Unit Cost' when the Sales line is a GL or Item Charge type.

How can I do this? do I need to code this on the form? or on the 'Unit Price' and 'Unit Cost' fields of the 'Sales Line Table'?
Any tips in the right direction are appreciated. Thanks in advance

xin

Do code at form
No. - OnAfterValidate()
CurrForm.SAVERECORD;

and then;

Unit Price - OnFormat(VAR Text : Text[1024];)
IF Type= Type::Item THEN
CurrForm."Unit Price".EDITABLE(FALSE);

Guess it might works.

DenSter

Actually, I'd like to take this a step further and have you really think about what you are doing. Personally I think putting validation code on any form is wrong, and this one might be one of those cases.

We're talking about making a field editable, which is a display property, so on the surface that would be programmed on the form. The requirement behind it though is open for interpretation though. If the requirement in your company is that under no circumstances should the unit price and cost ever be editable, then it is more than just a form display property. If this is required behavior throughout the system, then you need to consider that this should really be programmed as field validation on the table level.

If it is just for this one form, the sales order subform, then putting the code on the form could be sufficient. However, the Sales Line table is displayed on a whole bunch of forms (sales quote, sales invoice, sales credit memo, blanket orders, returns), and if you need this behavior on all of those, now you are looking at making the same change to all of those forms. Now imagine this requirement changing in the future, you would need to modify the same thing on all of those forms again. Imagine somewhere down the line there is a need for a new form for the Sales Line table, and the person developing that form doesn't know about this requirement, you will have a form on which you can change those fields anyway.

When field validation is on a table level (which is where it belongs in my opinion), it is taken care of throughout the system, regardless of which form the table is displayed on. Of course you'd have to think about something that's not a display property, and perhaps raise an error instead, but there are ways to determine whether the field is being changed on a form (look up CurrfieldNo).

DenSter

If you decide to put the code on the form, then the code in Xin's post is definitely wrong. You should be looking at the OnAfterGetCurrentRecord trigger, and make sure that you take care of EDITABLE for all Type values.

Savatage

We did something like this in the past.
We have added a boolean on the sales line that is filled based on the sales header..to determine if an order is an "internet order" or "regular order"
we didn't want the "unit price" editable on regular orders so we added..
OnAfterGetCurrentRecord()
CurrForm."Unit Price".EDITABLE("Internet Order");

which worked fine.
But if you drop in a second "Unit price" field onto the sales line that one stays editable regardless.
Probably based on the FieldID is what I came up with. :-k

But since you can do that it wasn't very useful and we got rid of it.

kriki

[Topic moved from 'NAV Tips & Tricks' forum to 'NAV/Navision Classic Client' forum]

matttrax

I'll encourage the same thing I always do.

Giancarlo wrote:

If Line Type = Item, Then 'Unit Price' and 'Unit Cost' fields editable property = No

Imagine you're a user. You can change the price and cost on other lines, but you can't on this. Why? Unless the user has been trained on it, and remembers that training, they have no idea. To them, something is wrong with the system.

A TESTFIELD command, or better yet another error message, that explicitly tells them what they are doing wrong and why they cannot do it, works much better in my opinion.