Mandatory Field on sales order

kenl

Hello,

On Sales order form, I would like to force the user to input the "Request Delivery Date". How can I do it?

I try the following method but fail:
1) Go to Table, set the field property "NotBlank" = Yes.
This only work when I clear the content of the field. If I never go to that field, system will by pass the checking.

2) On Table, set checking in OnInsert() / OnModify()
This doesn't work since when we click F3 on sale header form, system will insert the record. If I put the checking there, system will throw error immediately.

Any idea? :-k

Dennis_Decoene

Maybe you could make a check function on the form and call that function from the onaftergetcurrrecord (test on xrec) and in the onquerycloseform?

I have not tested this and I don't think everything will be perfect but there really is no perfect way to do this in navision... :whistle:

Kowa

If you want to test it before posting put a TESTFIELD for this field in CU 81.

If you want to test it before the insert select "Delayed Insert" = YES in Sales Header Form Properties and use your second method.

kenl

Hello,

The "DelayedInsert" on the form doesn't work for Sales Order, since when I set DelayedInsert= Yes, system cannot get the Sales No. from Number series.

Finally I write a check function (TestField(...)) in Table SalesHeader. When they press the button Post, I will call the check function.

Maybe there is no "Perfect" solution for this case. Anyway, thank for all of you.

2tje

You can do this by programming code on the Form. In one of the form or field triggers. I don't have an example with me right now. But it could be something like checking the field before leaving for another field. Or check a field when activating another field.

kriki

If you want to test it before posting put a TESTFIELD for this field in CU 81.

Better to write the test in CU 80, because it is possible you don't use CU 81.
This is to block at the ultimate moment the posting.

For the rest:
You can put a message in the OnInsert and OnModify triggers of T36 (and maybe also of T37), to remind the user he has to fill in the field if he hasn't done it.

This is how I would do it. Remind the user he has to do something and block him if he hasn't done it before it is too late (=before posting).

Kowa

kriki wrote:

Better to write the test in CU 80, because it is possible you don't use CU 81.

I would not recommend that.
If it is a manual post, CU 81 is used. If it is a batch post, who is going to know the "Requested Delivery Date" if it wasn't filled in ? This will cause the whole batch to stop for a field of marginal importance.
Besides, CU 81 can be modified with a customers licence, CU 80 cannot.

The "DelayedInsert" on the form doesn't work for Sales Order, since when I set DelayedInsert= Yes, system cannot get the Sales No. from Number series.

The document no. can also be drawn in the OnValidate of the No. Field if you copy the code from the insert trigger, but it is necessary that the cursor is in this field for it to work. Might be worth a try.

kriki

If it is a manual post, CU 81 is used. If it is a batch post, who is going to know the "Requested Delivery Date" if it wasn't filled in ? This will cause the whole batch to stop for a field of marginal importance.

Don't worry, the whole batch will not block, because codeunit 80 is called as follows:

IF SalesPost.RUN("Sales Header") THEN BEGIN

This traps errors in the codeunit to avoid that the error blocks everything.

Besides, CU 81 can be modified with a customers licence, CU 80 cannot.

1) Normally customer-licenses don't allow changing of objects (except if they have some designer-granules.
2) And if they can, a reason the more to do it in C80. It is better to avoid that customers change objects. It only gives problems.

Kowa

I meant external batch imports from POS systems, not the internal post batch in Report 296. If you put a testfield in a posting routine for a field which is nice to have but not essential this often causes unnecessary problems over the years when new demands have to be met. I prefer to do these additional tests before the posting routine starts to keep this as universal as possible.

From my experience,if the customer has paid around 6000 EUR for the solution developer granule he usually wants to do something with it. If you then tell him to keep his hands off CU 81 or Report 296 even though he can modify these, you might leave him somewhat angry. CU 80/81 functions could also be one handled in a single codeunit, but the fundamental coding in CU 80 has to be kept clear of an end user modifications. That is one of the reasons for the existence of CU 81, if you put potential bugs in this one these will be somewhat less critical than the ones in CU 80 which can bring down the whole system.

kriki

From my experience,if the customer has paid around 6000 EUR for the solution developer granule he usually wants to do something with it.

Better say him he doesn't need to spend that much. And then even more to fix the bugs they put into it (See my signature). A lot of times it is cheaper to let us do all the programming.