Dynamics GP (102)
Want to learn more about Dynamics GP, enroll in one of our WebSan University courses. Course are instructor lead, contain certification tests & all students receive a certification of completion.
Our next course in August 29th from 1 - 5 pm.
It's a Friday afternoon, 3pm, going into a long weekend. You are already going to hit traffic heading up to the cottage if you leave now, however it won't be as bad as in a couple of hours. You just finished a modified SOP Blank Invoice Form and would like to import it into your client's production environment. As you click the import button in Customization Maintenance, your heart starts to race as you cross your fingers and pray that the REPORTS.DIC file is not locked by any users....and you get the "Unable to open customizations dictionary" message. The afternoon sun will have to wait until tomorrow.
When importing customized reports through Customization Maintenance, users accessing the reporting dictionary will need to log out of Dynamics GP to have the report import successfully. This can be a pain and a scheduling nightmare for users and yourself alike. "There has to be a better way!" Well, luckily, there is. If you have access to the REPORTS.DIC file found in the "Microsoft Dynamics/GP/Data" directory, then you can import the modified report straight from this dictionary file using Report Writer (this is assuming that you developed the report in a test environment and would now like to push it through to production). To do this, follow the steps below:
Step 1: Copy the REPORTS.DIC file from your test environment to a local or network shared drive that is accessible from the production server.
Step 2: Log into the production environment with 'POWERUSER' access and launch Report Writer (Microsoft Dynamics GP menu >> Tools> Customize >> Report Writer).
Step 3: Click 'Report', then click the 'Import' button:
Step 4: It will ask you to browse to the path of the REPORTS.DIC file that contains the modified report you would like to upload. Click the ellipse (...) and select the reporting dictionary that you saved from the test environment.
Step 5: All modified reports from this dictionary file will be displayed in the left menu. Select the one you would like to import and click 'Insert'. If a modified version of that report already exists in the production environment, it will ask you if you would like to overwrite the existing report. Click the 'Import' button.
Step 7: Close Report Writer and if prompted to save, click 'Yes'. If this is a newly modified report, don't forget to set the ID in Alternate/Modified Forms and Reports in the Administration module.
That's it! No more waiting for all users to log out of the system. The next challenge is sneaking by your boss's office without him noticing.
If you find yourself always starting from scratch when creating custom VBA forms in Dynamics GP even though you've created other similar forms in the past, here's a little trick to save yourself some time:
1. Find a similar VBA form that you have already created and export that form to a package file using the Customization Maintenance window.
2. Browse to where you saved the package file and open the file in a text editor (such as Notepad).
3. Here you can do 2 key things that you can't do directly in Dynamics GP's VBE window. The first thing you can do is change the name of the form by simply doing a Find & Replace and changing the existing form name to the new name you want to use. The second thing you can do is change the Product ID. You'll notice that when you create a form in a standard Dynamics GP module, you can't use it in Project Accounting (or other add-on modules). By changing the Product ID at the top of the package file, you can make the form available in a different module. So if you originally created the form for the Customer Maintenance window (Product ID 0), simply change the Product ID to 258 to now make it available in Project Accounting.
4. Save your changes to the package file.
5. Import the package file back into GP and notice it imports into the Product you specified and with the new name that you specified.
6. Make any other changes you need to the Form
7. Take an extra long coffee break!
Once a project is finished, user should close out that project within Dynamics GP. This helps to avoid errant postings to the project & ensures accurate reporting.
To close a project within Microsoft Dynamics GP, first set the status of your project to Completed within the Project Maintenance window. Then, navigate to Project > Transactions > Project Closing to access the Project Closing window. Within this window, select the Contract Number that the completed project belongs to. All the completed projects for that contract should then appear in the listing below. To close a project, check the box under the Close column & select Process.
Users should note that even though a project is set to status of Completed, there may be additional transactions that may need to be completed prior to closing the project. If additional transactions are required, the box under the C* column will be blank. To obtain a listing of the transactions yet to be completed for a 'Completed' project, select the blue arrow beside the Project number field within the Project Closing window. This will open the Project Closing More info window wherein users are presented with a check list of all the tasks required prior to closing the project.
There are times when users may have completed check list items, but they do not display within GP as completed. If this occurs, it is good practice to run the PA Reconcile Utility. This utility will search through the GP transaction tables to verify what activities have truly been completed. To access this window, select Project > Utilities > PA Reconcile. Select a data set to reconcile and then click Process. The utility is fairly quick depending on the volume of data within your Dynamics GP environment.
Our clients will often have the need to attach supporting documentation to transactions within Dynamics GP. These might be for odd / correcting entries, entries required by auditors, or large dollar value entries. Further, it is good practice to attach supporting documentation for transactions if possible.
To attach supporting documentation to a transaction within GP, select the yellow paper icon beside the transaction number within the entry window for that transaction. This icon is also available within master data setup widows & essentially every other window within GP. Once within this window, select the paperclip icon at the bottom of the window (Note: Your system admin may have to enable this functionality to have this icon appear). This will open a new OLE Container window wherein one can select Edit > Insert New Object. From here, the process is as simple as selecting the file & clicking Attach within the note window.
WebSan has found this feature very helpful to our clients whenever they need to track down the supporting documentation for a transaction. As transactions move throughout there life-cycle in Dynamics GP, they will maintain the supporting documents attached to them, making audits a breeze.
Users should keep in mind that all banking transactions need to be processed through a Chequebook ID in order to display in that bank subledger & that one should NEVER post a general journal entry to a bank GL account. When we look at the Bank Transaction window, there is only a single Chequebook ID to allocate the transaction to. This is the account to which this transaction will apply. You will see in the lower portion of this window, you must explicitly state the other half of the GL portion of this entry. This should NOT be a bank GL account as a general journal entry to that bank GL will not affect that bank’s subledger.
A transfer of funds from one account to another should be completed through the Bank Transfer Entry window where possible. You will see on this window that there are two Chequebook IDs that must be identified. Thus, this transaction will affect two separate bank subledgers. One can only use this window wherein one of the account currencies is the functional currency (this is due to how GP treats the entries and is a restriction of the system). When you need to enter these types of transactions, you will have to enter TWO separate bank transactions. One will be an Increase Adjustment to the ‘to’ account, the other a Decrease Adjustment to the ‘from’ account while using a clearing account to flow the funds through.
You can probably guess that GP Sales Order Processing is used to enter, print and post sales orders. But did you know that you can also enter quotes, invoices, back orders and returns individually or in batches?
Are you aware that Sales Order Processing in Dynamics GP allows you to transfer sales documents from one type to another? For example, when goods or services are delivered to a customer, you can transfer the order to an invoice. The price the customer will pay and your cost will be calculated automatically.
Here are a couple of points you need to keep in mind, before transferring a document:
- Make sure there are actual quantities to transfer to an order, invoice, or back order
- Verify that the appropriate transfer options are marked for the type ID in sales setup
- Enter a batch ID for the document
- Approve the document, if required
For more information about Sales Order Processing in Dynamics GP, join our webinar on November 14 and learn how to cut lead times and speed up your transactions.
Doriana Kote, Marketing Assistant, WebSan Solutions Inc., a Channel Elite Awards Winner for 2013