Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Quick customization patterns
Miklos_Hollender
Member Posts: 1,598
After perusing the Wiki, my impression is that the Design Patterns community is very much add-on based, it is as about copying the patterns of the standard NAV, and this largely useful for add-ons. I think the needs for quick customizations are not served with them.
This is a problem, because these add-on patterns can be learned just by looking at the standard code, but nobody teaches people quick customization patterns.
So I do it now. Here is an example. Never do anything like that in an add-on, it it is not highly performant, it is not very much future proof, not useful for an add-on that will be used by a hundred users, but if you need to do a quick customization to make 1 user happy, this is the way.
In this example we fill a journal automatically. This is very often done. Very often when users complain boo hoo why cannot NAV do X automatically one good solution is that we make a button that fills a journal, they review and post it. This way it is not much manual work, yet they can spot errors much easier as if it was a 100% automatic solution. So it is good because it needs less testing than a solution that posts some things 100% automatically needs. So if you have 30 mins to solve a problem and cannot test it for days, because only 1 user is using it so it does not worth the cost, then just generate a journal, and let the user test it, check it, before posting it. A good example: generating some G/L bookings from Transfer Orders. Once a month. E.g. you need to book some Intra-Community VAT with them, which is a legal requirement in the EU if the Transfer Order crosses borders. You make a button (Action in the new lingo) that generates journal lines and they can review and post them. Very neat.
Here are the steps:
1) do it manually once and not only take note which fields you fill out but also in which order! If in an Item Journal you enter a cost or price and then another field and that field reset the price or cost, take note and change the order of entry!
2) In your code, do NOT do it like the standard or add-ons do (too much work), but emulate user behavior.
3) This means first fill out in the X Journal Line table primary key fields and insert it.
4) Then VALIDATE fields in the correct order you have tested, really make sure validating field X does not reset field Y you validated just before
5) Then use MODIFY(TRUE)
This is NOT a correct solution for an add-on because non-performant, and because if Microsoft changes the OnModify trigger it can break it. But it is excellent as a quick customization for 1-2 users because it emulates what the user does manually. So it is more or less guaranteed to work without investing a lot of effort.
If interested I can post more stuff like this. E.g. on documents, if it is not very important to print multiple invoices for example at one go, but only one by one, the reports can be made really simple. No need for Code.SetData.
This is a problem, because these add-on patterns can be learned just by looking at the standard code, but nobody teaches people quick customization patterns.
So I do it now. Here is an example. Never do anything like that in an add-on, it it is not highly performant, it is not very much future proof, not useful for an add-on that will be used by a hundred users, but if you need to do a quick customization to make 1 user happy, this is the way.
In this example we fill a journal automatically. This is very often done. Very often when users complain boo hoo why cannot NAV do X automatically one good solution is that we make a button that fills a journal, they review and post it. This way it is not much manual work, yet they can spot errors much easier as if it was a 100% automatic solution. So it is good because it needs less testing than a solution that posts some things 100% automatically needs. So if you have 30 mins to solve a problem and cannot test it for days, because only 1 user is using it so it does not worth the cost, then just generate a journal, and let the user test it, check it, before posting it. A good example: generating some G/L bookings from Transfer Orders. Once a month. E.g. you need to book some Intra-Community VAT with them, which is a legal requirement in the EU if the Transfer Order crosses borders. You make a button (Action in the new lingo) that generates journal lines and they can review and post them. Very neat.
Here are the steps:
1) do it manually once and not only take note which fields you fill out but also in which order! If in an Item Journal you enter a cost or price and then another field and that field reset the price or cost, take note and change the order of entry!
2) In your code, do NOT do it like the standard or add-ons do (too much work), but emulate user behavior.
3) This means first fill out in the X Journal Line table primary key fields and insert it.
4) Then VALIDATE fields in the correct order you have tested, really make sure validating field X does not reset field Y you validated just before
5) Then use MODIFY(TRUE)
This is NOT a correct solution for an add-on because non-performant, and because if Microsoft changes the OnModify trigger it can break it. But it is excellent as a quick customization for 1-2 users because it emulates what the user does manually. So it is more or less guaranteed to work without investing a lot of effort.
If interested I can post more stuff like this. E.g. on documents, if it is not very important to print multiple invoices for example at one go, but only one by one, the reports can be made really simple. No need for Code.SetData.
1
Comments
Thank you for you offer. I will gladly accept it.
Can you send me an email? I think you should still have it somewhere.
You are correct and we would love to publish the patterns on the wiki.