Currency Rate to primary exchange currency - number of digits [v 1.30]

Hi NC,

Would you be so kind to take in consideration adding at least 1 digit more to the 'Rate to primary exchange currency' field from Edit currency details screen ? When exchange rates have small differences even the 4th last significant digit counts :) .

And, all the places where currently the exchange rate is rounded to 2 digits for calculations to use at least 4 digits.

The reason I need this is because: the national bank of Romania uses 4 digits for the exchange rate to EUR and, taking 1 digit off from the 4, and then rounding everything multiple times to 2 digits causes significant price differences between the one that we edit in the variant details screen and the one that appears on the screen.

Thanks
Adi

Agree. It'll be fixed in the next release. If you don't want to wait you can execute the following script over your database:

ALTER TABLE [dbo].[Nop_Currency]
ALTER COLUMN [Rate] decimal(18, 4) NOT NULL
GO

IF EXISTS (
    SELECT *
    FROM dbo.sysobjects
    WHERE id = OBJECT_ID(N'[dbo].[Nop_CurrencyInsert]') AND OBJECTPROPERTY(id,N'IsProcedure') = 1)
BEGIN
  DROP PROCEDURE [dbo].[Nop_CurrencyInsert]
END
GO
CREATE PROCEDURE [dbo].[Nop_CurrencyInsert]
(
  @CurrencyID int = NULL output,
  @Name nvarchar(50),
  @CurrencyCode nvarchar(5),
  @Rate decimal (18, 4),
  @DisplayLocale nvarchar(50),
  @CustomFormatting nvarchar(50),
  @Published bit,
  @DisplayOrder int,
  @CreatedOn datetime,
  @UpdatedOn datetime
)
AS
BEGIN
  INSERT
  INTO [Nop_Currency]
  (
    [Name],
    CurrencyCode,
    Rate,
    DisplayLocale,
    CustomFormatting,
    Published,
    DisplayOrder,
    CreatedOn,
    UpdatedOn
  )
  VALUES
  (
    @Name,
    @CurrencyCode,
    @Rate,
    @DisplayLocale,
    @CustomFormatting,
    @Published,
    @DisplayOrder,
    @CreatedOn,
    @UpdatedOn
  )

  set @CurrencyID=@@identity
END
GO


IF EXISTS (
    SELECT *
    FROM dbo.sysobjects
    WHERE id = OBJECT_ID(N'[dbo].[Nop_CurrencyUpdate]') AND OBJECTPROPERTY(id,N'IsProcedure') = 1)
BEGIN
  DROP PROCEDURE [dbo].[Nop_CurrencyUpdate]
END
GO

CREATE PROCEDURE [dbo].[Nop_CurrencyUpdate]
(
  @CurrencyID int,
  @Name nvarchar(50),
  @CurrencyCode nvarchar(5),
  @Rate decimal (18, 4),
  @DisplayLocale nvarchar(50),
  @CustomFormatting nvarchar(50),
  @Published bit,
  @DisplayOrder int,
  @CreatedOn datetime,
  @UpdatedOn datetime
)
AS
BEGIN

  UPDATE [Nop_Currency]
  SET
    [Name]=@Name,
    CurrencyCode=@CurrencyCode,
    Rate=@Rate,
    DisplayLocale=@DisplayLocale,
    CustomFormatting=@CustomFormatting,
    Published=@Published,
    DisplayOrder=@DisplayOrder,
    CreatedOn=@CreatedOn,
    UpdatedOn=@UpdatedOn
  WHERE
    CurrencyID = @CurrencyID

END
GO

Thanks!
I'll use it as we plan to go live sooner than we expected having this solved :).

This issue still seems to be in version 1.40.

I think the main issue is caused by the roundings done when the prices are displayed (Math.Round(x,2)).
When dealing with currency exchange rates most of the companies use at least 6 digits after the floating point in order to avoid misscalculations.
Given the same situation: EUR set as primary store currency with an FX rate of 4.2766 RON and the shop's currency is RON, the roundings give messy results. This problem also appears for the transportation costs where the prices are in EUR (for example By Ground with .35702952 EUR/kg) and as soon as you have a few items in the basket the transport costs are incorrect.
I agree with the roundings but only at UI level not when the order totals and subtotals are transformed/calculated.
If I replace all Math.Round(x,2) with Math.Round(x, 4) I get almost correct results. But it's very unlikely for me to test and find all the required scenarios where this needs to be corrected...