I’d like to hear about your opinion about this type of case.
Background: In general you would never have your local currency set up in the Currency table, this is instead set up in General Ledger Setup (LCY Code). On Sales documents you would only fill in Currency Code when a foreign currency is relevant.
We have a situation where our client wants to have a different kind of Invoice Rounding and Unit Amount Rounding precision, based on the Payment Method used on a Sales Invoice/Order.
One option would be to do quite a lot of modification to base objects to calculate Invoice Rounding differently from standard.
But a second option that I thought about, what if we use a different Currency Code the achieve this goal. In this currency (which at the same time would also be the local currency) with Exchange Rate set to 1, it would be possible to set a different Invoice Rounding method and precision.
The Payment methods we need a different rounding for are “cash sales” (should this be relevant) so a Balancing Account No. is setup.
Do you see any problems with kind of process? Any consequences that I haven’t thought about? Or is there any third option I have neglected to achieve a different amount & invoice rounding based on a payment method.
In some countries, it is actually common practice to set up the local currency as a foreign currency with a 1:1 exchange rate. Although there are issues that would affect performance, the time needed to get a currency record and divide 1/1 is trivial. To me it just seems "“un-Navision” but I have seen many installs where this is done (and been used for over a decade) and it works fine.
So adding say USD and then USD-CASH I don’t think will be a problem.
FYI the reason this is common in particular countries is where there are a large population of immigrant workers that can easily forget what the local currency is and accidentally get it wrong. So by having them enter the currency on every single invoice reduces user error.
Thanks David! I highly appreciate your input, and coming from someone with your experience I guess I’m safe to recommend this type of workaround for our situation.
Hi Jens,
You may end up making just as many “adjustments” to have LCY as a currency. Have seen it done, both as a result of an “accident” (a consultant who didn’t know what he was doing and also created DKK as a currency code) and like David says, some countries where this is “normal”.
My experience says that it starts giving problems as soon as the users forget to put in the LCY code. It really got messy. So you would need to back it up with code to prevent anything being posted without a currency code. And you need a function to populate currency code to all existing entries, to keep the system consistent.
As David says then this is really very “un-Navision”'is. Personally I would rather go with a customization, think that’s going to be safer.
The main reason they do this is so they can put a test field on Currency Code and thus the user is forced to make a conscious decision on currency every time.
Yes, need to support it with field validations, testfields or something. And in these days (with D365’s user focus), then I’ll rather default to the LCY code, than forcing users to select the LCY and tell them they are stupid, if they forget. [:)]
Hi Erik. What kind of mess do you mean could happen? I would not want to force currency code to be used for all transactions. But if our LCY Code is ‘EUR’ then normally Currency Code would be left blank on sales documents (=edfault LCY code). Only for some types sales document we would use a different Currency Code, the code could for example be “EUR_CASH” only to achieve a different kind of invoice and line amount rounding.