Dynamics Blogger

Multicurrency is one important area and understanding it’s treatment in Project Accounting module of Dynamics GP is essential for a successful PA Implementation. Multicurrency is assigned in Billing currency ID in PA Originating currency is assigned for the contract first for it to be assigned to all projects under the contract. Later, the same currency is rolled on to projects. Currency for the contract and the currency for any or all of the projects under the contract cannot be different. Example: If Currency for Contract A is USD, Currency for Project A1 under contract A cannot be assigned to CAD and instead uses USD. Change orders are not supported by Multicurrency. In other words, change order tracking will be disabled if an originating currency other than functional currency is used in Contract as well as Project. Profit Types of Billing Rate and None are the only profit types that can be used on Multicurrency billing proj...

I’m quite busy working on my new portal MSDynamicsWire.com in the past week that led to being slow in my blog writing and I hope my blog readers would excuse me for that. In this article I’d talk about a call that I received during this morning from one of my clients seeking a clarification on the maximum decimals allowed for exchange rate entry. Their query is what are the maximum decimals allowed in Dynamics GP while entering an exchange rate during transaction entry. Maximum decimals are critical especially for currency exchange houses or banking institutions where the foreign currency activity would be higher. A one decimal change would lead a huge variation in revaluation or realized gain/loss. The answer for the maximum decimals allowed for an exchange rate  in Dynamics GP  is 7 . Users have to be cautious in entering the decimals since any entry beyond 7 decimals would lead to a complete mess up of the exchange rate as you could see in the example above that a rate...

We get to see an Exchange Rate Entry window every time we try to post a transaction entry in Multicurrency, be it a General Entry or a Transaction in Sales or Purchasing series. This happens whenever a valid exchange rate could not be found in the Multicurrency Exchange Rate Maintenance for the selected currency Rate Type. In some cases, the Exchange rate for certain currencies doesn’t change frequently. In these cases, we can choose to avoid this Exchange Rate Entry window by inserting an exchange rate that stays unexpired as shown below. Adding to this we need to set the Exchange Table ID to search for Unlimited Unexpired Rates as well as assigning a Transaction rate Default to either “ previous Date ” or “ Next Date ”. Now, when we enter a transaction in Multicurrency, the system automatically assigns the recently available rate to the transaction by default until and unless we insert another new rate that would then become the new default. Remember that this setup ...

Whenever we set up an Account in Financial => Cards => Account, We’d go to Account Currencies window and assign the Multi currencies in case the account will have transactions originating in currencies other than Functional Currency. Besides assigning the Multi currencies here, it also involves to check whether we need those currencies to be revalued or not. If Yes, we need to mark the Revalue Account option and then choose to Post Results to Account or Financial Offset Account. Here, Results mean the the Realized gain / Loss or the Unrealized Gain / loss as the case may be, resulting out of Revaluation of Multi currencies in the Financial Routines ( Financial => Routines => Revaluation ) The basic difference between choosing Post results to an offset A/c and post results to Account is If you choose the Offset a/c, the revaluation results would be posted to a separate account that is defined as Financial Offset A/c in Posting Accounts setup ( Administration => Setup...