Changing a flowfield creates records in the underlying table

rsaritzky

Hi Everyone:

In Table 168, Job Budget Line, there is a field number 9 called "Quantity". This field is a flowfield, which Sums up some records from the Job Budget Entry trable. The Calcformula is:

Sum("Job Budget Entry".Quantity WHERE (Job No.=FIELD(Job No.),Phase Code=FIELD(Phase Code),Task Code=FIELD(Task Code),Step Code=FIELD(Step Code),No.=FIELD(No.),Type=FIELD(Type),Variant Code=FIELD(Variant Code),Date=FIELD(Date Filter)))

In the form that supports this table - form 212 (and also if you enter records directly into the table itself) - the user is allowed to modify the value of this "Quantity" field. When the field is modified, an additional "Net Change" record is AUTOMATICALLY added by the application into the Job Budget ENTRY table with a net "Quantity" value so that the flowfield calculates correctly - that is, is still the sum of the Job Budget Entry records". So, for example, if you start with 3 records in the JBE table that total a quantity of 30 (so you see 30 in the quantity field in the Job Budget Line table), and you change the 30 to a 25, a record with a quantity of -5 is automatically added to the JBE table.

There is a bunch of code that makes this happen - I can see it in the debugger. What I CANNOT see is how this code is called - there is no C/AL code in the Quantity.ONVALIDATE trigger (on the job budget line table) that causes the code to run. In fact, you can comment out ALL the code in that trigger and the code that creates the new Job Budget Entry record still runs.

So, my question is, where is the link to the code that creates this "net change" record in the Job Budget Entry table? Is it somehow an "automatic" feature of flowfields, that happens with no specific coding? Has anyone ever tried to figure this out?

Thx

Ron

rthsw

also this comment is allready stressed for a lot of bugs, in this case it is right. it is a feature of navision. in version 3.56 (the "blue one" this was quite better to understood, but in short it is this:

you should normaly set a flowfield to editable:not. if you DON't, the user can edit this field. if the user does, navision figures out the LAST field of the primary key. is it NOT a integer (or comparable), it stops with an error. but if it IS an integer, navision calcs the actual sum of the depending table (inluding all the filters transformed by the flowfield-calcformula like lcoationcode or stuff like this), calculates the difference, and inserts a new entry with all the fields filled out from the fitler of the calcformula, and a new (highest entry +1) last primary key field. this code is in the exe itself. the code you seen ist just some arround for lookup and stuff, but NOT for this feature. so feel fre to enjoy this, it is navision, and so it is fun.

rsaritzky

Thanks for the reply. Navision apparently only enables flowfields on forms that calculate "budgets", as this screen does (also the G/L budgets form). I guess they believe that as long as it is not a "real" transaction, it is OK to let Navision do this.

Ron

DenSter

well I don't think it was a conscious design to make this happen, rather a bug that turned into a feature . Normally you don't want users to be able to edit a flowfield, but if you study their behaviour and you can use that for your customer then of course go ahead and use it.