Best Of

Don't think of performance, because having incomplete transactions is a WAY bigger problem than having to wait half a second for a shipment to post. You can fix performance issues in other ways. Whether you run the triggers or not has nothing to do with whether you are in a standard or custom table.

OnValidate triggers are used for getting related data into other fields. The decision to validate or not is when you want to take care of those in your code yourself. For instance, you can validate a City field and that pulls in post code and such. If you are setting those fields yourself, there is no need for calling the validation trigger.

Same as Insert(true) or Modify(true). Those triggers do things and the only reason why you would NOT run them is when you are doing those things in your own code.

You'll get different opinions here though, I've had very heated discussions about this topic. Some ppl will vehemently say to NEVER run triggers, where I say you should absolutely run them as much as possible. For instance, validating the Quantity on the Sales Line will calculate amounts and discounts and such. If you don't validate, you will have to program that calculation yourself.

My approach is to first do a task manually, and then do it in code. Creating a new Sales Order for instance. You open the page with a blank record, and as soon as you leave the No field, it inserts the order with a new number from the number series. That's the first 4 lines in the code you posted. Validate the Customer and the Location pulls in all sorts of important information. That's just three more lines of code. In 6-7 lines of code, you have a complete sales order, all you need to do is add some lines. I don't see any reason why anyone would ever program all of that.

Here's a good tip: turn on the debugger and do things in BC. Step through the code to get a feel for what it does.

A simple rule, is that if you don't know if you should use the TRUE or not, then use TRUE. As you progress you will learn where you can leave it out.

In the case of Sales Header (and other documents), that OnInsert trigger calls the "No. Series" logic. That first INSERT(TRUE) above is used to assign the "No." value to the new record.

Disabling the user is the same as deleting him? Do i have a free slot on the license after that?

Yes, after you disable the old user, you can create the new user.

This is not what I'm saying Your custom fields should already be part of the "Item Journal Line" being used to create the "Value Entry". There should be no need to "get" the document. This fails because the posted documents have not yet been created.

Look at how the standard process flows field values from the documents to the ledgers. Use that as your guide. There should be events along that path you can use.

Hello @Shege.

The DLL is running in the server so you need also to copy it in the folder "C:\Program Files\Microsoft Dynamics NAV\100\Service\Add-ins".

Regards

HttpWebResponse := HttpWebRequest.GetResponse;
IF NOT HttpWebResponse.StatusCode.Equals( HttpStatuscode.InternalServerError) THEN
BEGIN
  StatusCodeInt := HttpWebResponse.StatusCode;
  StatusResultStr := STRSUBSTNO(' "httpstatus": { "code": "%1", "description": "%2" }}', StatusCodeInt, HttpWebResponse.StatusDescription);

  StreamReader := StreamReader.StreamReader(HttpWebResponse.GetResponseStream);
  JSONresultString := StreamReader.ReadToEnd;
END;

with these dotnet variables:

HttpWebResponse DotNet System.Net.HttpWebResponse.'System, Version=4.0.0.0
HttpStatuscode DotNet System.Net.HttpStatusCode.'System, Version=4.0.0.0
StreamReader DotNet System.IO.StreamReader.'mscorlib, Version=4.0.0.0
JSONresultString DonNet System.String.'mscorlib, Version=4.0.0.0

The value in the dotnet string can be stored in a blob using this:

TempBlob.WriteAsText( JSONresultString, TEXTENCODING::UTF8);
MessageLog."Response Message BLOB" := TempBlob.Blob;