disable of F3 function

vidyamhiremathvidyamhiremath Member Posts: 13
hi,
can we disable f3 function for a particular form?

Comments

  • chengalasettyvsraochengalasettyvsrao Member Posts: 711
    I think the answer is NO.

    Can i know why want to do this.?
  • lvanvugtlvanvugt Member Posts: 774
    If it's about disabling inserting a new record you can set the form property InsertAllowed to No.
    Luc van Vugt, fluxxus.nl
    Never stop learning
    Van Vugt's dynamiXs
    Dutch Dynamics Community
  • vidyamhiremathvidyamhiremath Member Posts: 13
    i want to disable f3 function for item card and Create a new function, to be accessed from the Function button on the Item card.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    i want to disable f3 function for item card and Create a new function, to be accessed from the Function button on the Item card.


    Don't do this. Train your users how to use Navision. If your users don;t like Navision they really should have bought a different product. Or maybe stayed with the product they had.
    David Singleton
  • BeliasBelias Member Posts: 2,998
    you shouldn't do this: as david said, train the users...if you train them you'll realize that you want to say them "everywere in navision, press F3 to insert a new record, F4 to delete it, F2 to edit a field (if you are allowed do it)"...well, what if you start to substitute these "global" shortcuts with other functions?users will get crazy!try with ctrl+f3 shortcut instead!
    -Mirko-
    "Never memorize what you can easily find in a book".....Or Mibuso
    My Blog
  • matttraxmatttrax Member Posts: 2,309
    There's a reason NAV is consistent across the system. As Belias said, F3 to insert, F4 to delete, F9 is statistics, etc. That way the users learn something once and it can be applied to multiple areas of the system. They don't go blindly into learning a new functional area because they have experience with another one.

    If you explain the business problem we may be able to provide an answer that is not "train the users", but that really is the most logical thing to do.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    matttrax wrote:
    There's a reason NAV is consistent across the system. As Belias said, F3 to insert, F4 to delete, F9 is statistics, etc. That way the users learn something once and it can be applied to multiple areas of the system. They don't go blindly into learning a new functional area because they have experience with another one.

    If you explain the business problem we may be able to provide an answer that is not "train the users", but that really is the most logical thing to do.


    In my experience when ever I see a developer doing something like this it generally starts with a conversation between a lazy functional consultant and the client. The conversation generally starts something like:

    Client; "our old system did it like this, here let me show you ...

    and the project goes down hill from there.

    I wrote a blog about this:

    http://dynamicsuser.net/blogs/singleton/archive/2009/10/30/the-most-powerful-tool-that-a-dynamics-nav-consultant-can-use.aspx
    David Singleton
  • matttraxmatttrax Member Posts: 2,309
    Client; "our old system did it like this, here let me show you ...

    It's true, if you wanted it to work like your old system you shouldn't have spend 6 figures on a new one.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    matttrax wrote:
    It's true, if you wanted it to work like your old system you shouldn't have spend 6 figures on a new one.

    One funny example, was a customer whose old system did not have order management. Basically SHIP INVOICE all in one hit, and it was substantially affecting their business, so order management especially partial shipments was a major driver in changing systems.

    Sometime after using the system the CEO says that the users need to link Shipments one to one to invoices and thus wanted a way to enforce invoice generation when a shipment was made.

    My reply was simply for him to think back to why he bought Navision.

    Rule #1 when implementing Navision NEVER under any circumstances look at the old system and how it works.
    Rule #2 if your old system was so great, why are you changing?
    David Singleton
  • DenSterDenSter Member Posts: 8,305
    While I agree that many customers (and some NAV partners allow them to) go down the path of making NAV look like their old system, and this is not recommended.

    On the other hand.... Say the old system provides 200 bits of functionality, NAV replaces 175 of those, renders 20 of them obsolete, provides them with 1000 new ones, but the customer really likes the remaining 5 features they are used to in the old system. Now they want to see if it's possible to incorporate those features into NAV. That doesn't mean they want to make NAV look like their old system.

    You can't always tell them "train your users", you have to give these features some serious consideration. It doesn't even mean that they are necessarily "system features" that are always evil. Many times they are simply "business processes" that the customer wants to have in their ERP system.

    Having said that.... disabling F3 is ridiculous :mrgreen:
  • matttraxmatttrax Member Posts: 2,309
    For better or worse, I always like to give the user the benefit of the doubt and let them explain why they think they need something.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    There are two issues here. One is the customer requesting functionality (a business need) that they had in their old system. The second is wanting Navision to perform in the same way as the old system. Of course we need tp provide functionality that fulfills a business need.

    But when the customers starts wanting to change the way things are done that is dangerous. In this specific case we all know that every possible case of creating an item card can be done with F3. The fact that the customer probably wants some pop up wizard to do it like the old system is not a business requirement. Even if it was, then you would create a new function, you would not modify F3.

    As Matt says always listen to the client, and propose proper solutions. But in this case it made it as far as the development stage, which means the partner was listening with closed eyes.
    David Singleton
  • David_SingletonDavid_Singleton Member Posts: 5,479
    My argument in fact is the partners that just say "Yes can do" to every request from the client with any thought of what it will cost that client, only thinking to keep them happy now and be able to send an invoice.
    David Singleton
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    Rule #1 when implementing Navision NEVER under any circumstances look at the old system and how it works.

    I'm not sure I can fully agree with that. In extreme situations like this yes, but not always.

    When defining the requirements for the new systems either at the quoting phase or analysis / design phase users will consistently forget to tell you about the features the old one already had, because everybody assumes the new system will as a master of course have them, because it's "better" and "better" means more, not less, huh? Nobody assumes anything the old one did well will be missing from NAV. And no amount of "analysis business processes" will tell you anything about such features, only a taking a direct look at the old one will.

    A good example I found on my second project in 2003 is editable texts (comments) on documents like an order confirmation or invoice. Nobody assumes the only standard option is to create a text-only line and thus have your comment in the most unappropriate place: in the lines section. People assume there must be some sort of a way to write proper header texts and footer texts onto a document because if the cheap old DOS software could do it they don't assume the expensive new Windows one cannot. So I ended up modifying the Sales Comment Line table, adding an Option column: Internal, Header, Footer, and modifying all document reports accordingly. No big deal but was a little bit awkward because it happened after go-live.

    This is partly what experience is all about, learning what questions to ask: do you need X, do you need Y etc. but nobody is born with 5+ years of implementation experience so the best thing one can do until one learns what the "standard", "typical" requirements are - which you are supposed to ask about if they forget to tell it themselves - is to take some hints from the old software.

    Not reinventing Insert of course...

    Another suggestion, and that's for the old experts like David Singleton: please be a bit more careful about the "just do it professionally etc. etc." stuff because you cannot know the situation in the guy asking a question is. It could very well be that it's a 2-person NSC with one salesguy and 20 years old IT guy as a consultant and developer, they are under extreme pressure from the company owner because they haven't sold anything for 9 months and they both are on the border of getting fired, they are under extreme pressure from the customer because the whole reason the customer chose such an unprofessional NSC is that they knew they will be willing to give in to pressure - not having many other choices - and customize anything and everything for free with a deadline of yesterday, and so on. And the 20 years old IT guy can't just quit because there isn't everywhere a shining job market for inexperienced people during an economic crisis. It can be a very painful situation to be in, I've been in situations like that when I was very young and had very little choices, and therefore would like to suggest to use a little bit of compassion regarding questions like that... sometimes people are in a truly, truly, truly difficult situation.
Sign In or Register to comment.