Kriki’s Dynamics NAV blog

Gerdien started with asking MS to get an object range for the add on, then Erik took over and we got really technical. And once his add on was ready, Gerdien took over again to finish the administration part with MS.

 

1. Before development
   • Registered partner
   • Solution provider agreement (SPA)
   • MS Dynamics NAV addendum
   • And I missed the others…
2. Recommended
   • MBS  competency
   • ISV competency
   • Business plan (add-on)
3. Step 1: request form (fill in and send)
   • Add-on name
   • End user price
   • # of objects (+-)
   • Developer license no.
4. Step 2: MS checks and creates granules
   • A unique number range will be assigned. In general after some days.
5. What technical issues
   • Technical and functional design
   • Development guides
   • Release management
   • Support
6. Technical and functional design
   • How to define the functional requirements?
     • How it usually happens: you build it for a customer and then create add-on. Best is to rebuild it after some time.
     • How it “should” happen.
     • Try to limit features. It sells, but quality will go down.
   • Think about NAV license
   • Upgradeability: touch minimal number of default NAV objects
   • Think default NAV
     • Journals/ledger entries/posting routines
     • Form design (NAV 2009?)
     • Navigation
7. Development guidelines
   • Before coding
     • If international : develop in W1
     • Latest possible version
     • Start developing in the no. range assigned by Microsoft.
       • Mind the field numbers
   • Coding
     • Stick to the rules
       • English!
       • Tables:
         • Never change/delete keys - only add keys
         • Think of SQL server
       • Fields:
         • Don’t change field ID’s or names
         • Don’t change the length
         • Don’t re-use fields
       • Variables:
         • Use a consistent naming convention
       • Functions:
         • Self-explaining function names
         • Try to avoid global variables
     • Avoid using “WITH”
     • Avoid code on forms
     • Try to “bundle” separate pieces of functionality in functions
     • Never remove code, use slashes (avoid {}).  Well in NAV2009 it is a lot better to use // (Comments are coloured green!). Before I preferred the {} because the original line remained the same and comparing tools had it easier to find those. But now with NAV2009 and that green colour (Hey,NAV is going green!)
     • Always think about this:
       • Someone else is going to deploy and work in your codebase
       • You have to be able to easily upgrade to each release and service pack
     • Minimize changes on forms
     • Minimize changes on reports
     • (actually … Just minimize any changes)
     • Why document in code?
       • Readability
       • Upgradability
       • Mergeability
       • Maintainability
       • Mark where you start and end the code
       • Version list
       • Documentation section
   • Automations:
     • Make sure it meets the fxCop standards. Download fxCop and use it.
       • Memory leaks
       • Version
       • Naming conventions
       • Error handling.
   • NAV 2009?
     • 100% form transformation: Yes or No?
   • Testing
     • Monkey testing
     • Predefined scripts
     • Who?
       • Developer
       • Analyst
       • Customer
     • Performance test
     • Use early adopters for big releases
   • Version management
     • Versions, SP, hotfixes
       • 1.xx
       • x.1x
       • x.x1
     • Release object: modified/versions/date
   • Only implement released versions
   • Documentation
     • Correct US English
     • Reseller oriented
     • End user oriented
     • Release notes
     • Manuals
     • Online help
     • E-Learning
   • Roadmap
     • Communicate roadmap regularly
     • Receive feedback from partners and customers
     • Think about the strategy
   • Distribution
     • Localization
     • Translation
   • Support
     • All servicepacks and versions available for download
     • Forum, technical, functional
     • Whitepapers / Best practices
     • Obviously, (online) helpdesk
   • After development
     • Step 3: report used object numbers, list of countries
     • Step 4: receive notification (can take up to 2-3 weeks)
     • Changes / extensions : repeat step 3/4
     • Optional (but strongly recommended)
       • Dynamics ISV Software solutions test
         • DB test
         • Test procedures
         • Documentation
         • Uninstall procedure (WHAT!? Well, it is easy enough:take the original objects and put them back in the DB. Well an easier procedure-description is difficult).
       • Certified for Dynamics
         • Reference cases
     • Report add-on sales
       • MS provides report: licenses with your add-on configured
     • Marketing
       • Channel builder (partners)
       • Solution finder (Customers)

 

 

Well, if I am developing in a wrong way, at least I know I am not alone! I already follow all coding guidelines (except than the commenting with //, but I will consider it) Eric gave.

 

I have to admit that Eric has done better presentations (well, I only saw one other presentation of him: http://mibuso.com/blogs/kriki/2008/04/17/hardware-recomendations-to-make-installations-hum-by-eric-wouters/  and also his mike was not functioning well). I think that the not-developers could get bored by it, but being a developer, I was really interested.

Filed under: Add-on, DirectionsEMEA2009, NAVISION