Now the interesting bit to me was the validation of the ItemStatisticsBuffer.“Budgeted Sales Amount” field. This field is a flow field and is the sum of the “Sales Amount” field on the “Item Budget Entry” table.
When the ItemStatisticsBuffer.“Budgeted Sales Amount” field was validated, it resulted in a record being inserted in the underlying table (the “Item Budget Entry” table).
I don’t recall coming across this behaviour before. I didn’t think you could validate a flowfield and never really thought twice about doing it.
Can anyone shed a little more light on this behaviour and what is necessary to make it work?
This is standard NAV behaviour, and has been part of Navision since the early DOS versions.
Basically what happens is that NAV looks at the current filters applied to the underlying source Table. It then looks at the sum of the records, and compares this to the number that you just entered. Now NAV creates a new Record in the source table, with a value that will then add up to the new total that you want. It then adds a new record.
For this to work, the Primary key of the source table must end in an integer.
This feature is mainly used for Budgets, in the Base App, but can I use it a lot for many other types of functions.
It actually is unusual, but not illegal. To validate a flowfield is just a way to execute some code put in the VALIDATE trigger. Why put it there is in the programmer’s mind - a place as good as any other.
What is really weird in this specifical case is that there is no code in the VALIDATE trigger of the “Budgeted Sales Amount”, actually there isn’t any code in the whole table. Funny.
In terms of the actual Validation, this is required if the filters do not give enough data to generate the entry. You can then add some code of your own to fill bits in.
I’m still missing something here with my understanding of this feature? If all that was required was that the base table had to have an integer as it’s last field in the PK then validating the Balance field on the customer record would result in a new entry in the detailed customer ledger entry table, which is obviously a bad idea.
Yes very SCARY powerful, and obviously something you should be extremely careful with. Do NOT do this on the balance field (or any other field that sums any ledger entry tables for that matter), because it will %$#@ up your financial system.
This feature is nothing new, I have been using this since the DOS days. (Though the validate wasn’t exactly there then). But in terms of dangerous, its not different from anything else you can do. Try this code:
GLEntry.Init;
GLEntry.Amount := 0.01;
GLEntry.INSERT;
Your database is not corrupt and unusable. This is why Application Builder is seperatd from Solution Designer. And why we have code units to call.
Hi David Scary because the difference between your example and the insert as a result of the validation on a flow field is that your code is explicit; the flow field insert happens in the background. I wouldn’t think it would be too hard to accidently validate a flow field with a value and then have a ledger entry inserted without your knowledge. Also scary because I’ve been working with Nav for 5 years and I’ve never seen this in the development documentation or twigged that it could happen. Another example of how much more there is to learn for me on this product and whenever I think I’ve got a handle on most things something like this harpoons my ego – thank heavens ! Shep
Nah don’t let it harpoon your ego. Just realize that there is always something else to learn. What is so great about these forums is that there is something you hadn’t thought of in some post every day. Why do you think we spend so much time in here? [:D]