Open Forum

Expand all | Collapse all

Correct Way to Test a Form Change

  • 1.  Correct Way to Test a Form Change

    SILVER CONTRIBUTOR
    Posted 24 days ago
    I've never modified a form in GP, but would like to make a simple change to our Purchase Requisition Screen that would greatly help our end users.  My concern is corrupting the forms dictionaries that are currently being used.

    From what i've read I should create a separate shortcut for GP and have the target in the properties menu point at a different Set file.

    Does the "Start in" location need to change?

    Within the set file, what .dic files do i need to recreate and point to a different location to prevent changing things that other users are using?

    I am working on a terminal server with the reports and forms dictionaries being located in a shared location.

    dynamics launch

    ------------------------------
    Andy Berntson
    Fargo Public Schools
    Fargo ND
    ------------------------------


  • 2.  RE: Correct Way to Test a Form Change

    Posted 24 days ago
    You can always take entire GP Folder (C:\Program Files (x86)\Microsoft Dynamics\GP2016) as backup and start doing modifications on Requisition form. If in case of issues, you have backup to replace it back.
    If you really want to work with entirely different folder, you need to change Target and Start for the different folder GP icon.

    ------------------------------
    Vijayakumar Kenchugundu
    Microsoft Dynamics Applications Architect
    ARC (Airlines Reporting Corporation)
    Arlington VA
    ------------------------------



  • 3.  RE: Correct Way to Test a Form Change

    TOP CONTRIBUTOR
    Posted 21 days ago
    Actually, what you need to do is create a separate dictionary and .SET file for testing.  It's pretty easy to do: simply find your FORMS.dic file (or REPORTS.dic file) and make a copy, renaming it to something you want to use long-term.  Then create a copy of the dynamics.set file and rename it.

    Now, what you have to do is repoint the modified .SET file to point to the modified Forms/Reports dictionary.  The .SET file is separated into two parts: the top contains a list of all the modules and third party applications and the bottom are the directories to the dictionaries used by those modules.  Simply adjust the path to point to the modified Forms/Reports dictionary - the copy you just made.  You should be looking for a section which looks like this:

    ...
    Windows
    :C:Program Files (x86)/Microsoft Dynamics/GP2018/Dynamics.dic
    :C:Program Files (x86)/Microsoft Dynamics/GP2018/Data/FORMS.DIC
    :C:Program Files (x86)/Microsoft Dynamics/GP2018/Data/REPORTS.DIC
    ...

    Take care to match the path syntax, using forward slashes instead of backslashes.  I use modified reports on all my companies so that section of my .SET file looks like this (note that we use a shared drive for shared report dictionaries, making maintenance and admin easier):

    ...
    Windows
    :C:Program Files (x86)/Microsoft Dynamics/GP2018/Dynamics.dic
    :C:Program Files (x86)/Microsoft Dynamics/GP2018/Data/FORMS.DIC
    :R:GP2018/OCI/REPORTS.DIC
    ...

    Lastly, you'll need a shortcut that launches Dynamics and points to the modified .SET file.  To do this, make a copy of your Dynamics shortcut and modify the path (right-click on the icon and choose "Properties").  All you have to do is add the name of your modified .SET file to the end of the "Target" section (see example below).

    "C:\Program Files (x86)\Microsoft Dynamics\GP2018\Dynamics.exe" "OCI.SET"

    This assumes that the .SET file you created lives in the same directory as the Dynamics.exe file (on a common install these are in their own directory located at  C:\Program Files (x86)\Microsoft Dynamics\GP2018.

    If you set it up this way, you can make all your changes to your "modified" Forms/Reports dictionaries (which at this point noone but you will be using).  Once you are ready to go, all you have to do is copy the new .SET file and shortcut to the new user's computer and have them launch Dynamics using the new shortcut.  (This assumes that the new dictionaries are in a shared location.  If you put them on the user's PC, you'll need to copy that locally as well.)

    You're welcome to contact me directly if you have more questions.

    ------------------------------
    Blair Christensen
    Database Administrator
    Oppenheimer Companies, Inc.
    Boise ID
    ------------------------------



  • 4.  RE: Correct Way to Test a Form Change

    TOP CONTRIBUTOR
    Posted 21 days ago
    It's important to make backups of your forms and reports dictionaries before and after you make changes.  Just like database backups, you always want to have them current.

    ------------------------------
    Lou Spevack
    Systems Accountant | Dynamics Credentialed Professional
    American Council on Education
    Washington DC
    ------------------------------



  • 5.  RE: Correct Way to Test a Form Change

    GPUG ALL STAR
    Posted 21 days ago
    Hi @Andy Berntson,
    @Blair Christensen provided a well detailed way to proceed, though I'm going the opposite way when it comes to modify Forms & Reports..
    By default the custom dictionary files are stored on an network share (\\UNC\yourshare\REPORTS.DIC) where the users would access them.. I'd always keep a local copy of that dictionary on my local GP client and point my DYNAMICS.SET file to the local copy.. This way I can make all the changes I want and test them until I'm satisfied.
    As @Lou Spevack suggested, you take a backup of the reports before doing any changes, though some may simply tell you to copy the .DIC file, I prefer the Microsoft-way of doing it, which is from inside GP by going to the customization menu :  Main GP menu > Tools > Customize > Customization Maintenance
    From there you select all the customized objects and click on the Export button. Save the export into a .package file, which allows you later to re-import it in case you want to restart your customization.
    When you're done with your custom Reports or Forms, you can export them individually (no need to take all the ones that haven't changed) and put into a .package file.
    Then, when no one is in GP (outside of regular hours or during a maintenance window) you go to a GP client that points the DYNAMICS.SET file to the shared network dictionary and do the inverse operation by importing the .package file and voilà.. you're done.
    Don't forget to set the Alternate Modified Forms & Reports security to the users so they can actually access the customization.
    Hope this helps.
    ​​​

    ------------------------------
    Beat Bucher
    Business Analyst, Dynamics GP SME
    Montreal QC/Canada
    @GP_Beat http://www.gp-geek.com
    Montreal QC GPUG Chapter Leader
    MBS MVP (2015-2018)
    All-Star 2013
    ------------------------------



  • 6.  RE: Correct Way to Test a Form Change

    TOP CONTRIBUTOR
    Posted 20 days ago
    I'll just echo what @Lou Spevack said about making backups.  It's always a good idea to keep a backup, as the forms and reports modifier tools are not real great to work with and sometimes you have to revert back to your original and start over.  (If you are doing an upgrade, Microsoft suggests exporting all your modified forms and reports into package files as a backup.)

    As to the best method for distributing the modified forms and reports, that's going to be a judgment call.  If you have a small organization, it may not be a big deal to go to each user's workstation and do the import of the package file as suggested by @Beat Bucher.  Our organization is too spread out geographically for that to be feasible, so I use a shared drive for all our modified report dictionaries (one per company).  When it comes time to drop a modified report, I have to wait until everyone is out of that dictionary/company.  Then I rename the old dictionary (as a backup) and drop the new one in.  Alternatively, one can do the import of the package file as Beat suggests.  Then the next time your users log in they will get the new (and hopefully tested) versions.

    Having local dictionaries is more convenient for the user while having shared dictionaries is more convenient for the admins and makes sure everyone is using the same versions of everything all the time (which is important for our environment).  Pick the methodology which suits your business' needs.

    ------------------------------
    Blair Christensen
    Database Administrator
    Oppenheimer Companies, Inc.
    Boise ID
    ------------------------------



  • 7.  RE: Correct Way to Test a Form Change

    SILVER CONTRIBUTOR
    Posted 13 days ago
      |   view attached
    I am trying to add Vendor Name into our Poprequsition form.  I thought it would be a fairly simple process of dragging the Vendor Name from the Toolbox to the form, but apparently i'm missing something.  attached is a screenshot of what i'm seeing.


    ------------------------------
    Andy Berntson
    Fargo Public Schools
    Fargo ND
    ------------------------------



  • 8.  RE: Correct Way to Test a Form Change

    TOP CONTRIBUTOR
    Posted 12 days ago
    I will second @Beat Bucher's suggestions!​

    ------------------------------
    Jo deRuiter, MCP, DCP
    "That GP Red Head"
    AISLING DYNAMICS CONSULTING, LLC
    WEBSITE: https://aislingdynamics.com/
    BLOG: https://community.dynamics.com/gp/b/gplife
    770-906-4504 (Cell)

    ------------------------------