Data migration

rhpnt

Hi,

would anybody please be so kind and explain to me in plain english what the EVALUATE piece of code is all about?

  Field.Type::Decimal:
    BEGIN
      IF NOT EVALUATE(Decimal, CONVERTSTR(Value, '.', COPYSTR(FORMAT(1.1),2,1))) THEN
        EXIT(STRSUBSTNO(Text010,Value));
      FldRef.VALUE := Decimal;
    END;

It's a simple CASE sentence in a function for standard data migration when creating a new company (CDU8611-EvaluateValue(VAR FldRef : FieldRef;Value : Text[250]) ErrorText : Text[250]). The thing is in the XML file from where the data is retrieved the "Value" is e.g. 1.844,56, but after this evaluation the "Decimal" variable shows 1,85556!? Why is the evaluation written that way and not simply: EVALUATE(Decimal,Value)? Right now all item decimal values over a 1.000,00 (in the xml file) get a wrong (1,0000) value. The values in the xml file were exported from a different company in the same db.

I'm not a freshman in NAV but have to admit I don't have a clou with this one...

P.S.: NAV5 + SQL Server 2008 R2

ssingla

I know I am not an expert in xml stuff but 2 things of importance to me are :
a) Isn't the value 1.844,56 abnormal i.e. a comman after the decimal place? I have never seen that.
b) NAV 2009 have changed it (You must have seen that) to what you are saying

Field.Type::Decimal:
    BEGIN
      IF NOT EVALUATE(Decimal, Value) THEN
        EXIT(STRSUBSTNO(Text010,Value));
      FldRef.VALUE := Decimal;
    END;

raveendran.s

ssingla wrote:

I know I am not an expert in xml stuff but 2 things of importance to me are :
a) Isn't the value 1.844,56 abnormal i.e. a comman after the decimal place? I have never seen that.
b) NAV 2009 have changed it (You must have seen that) to what you are saying

Field.Type::Decimal:
    BEGIN
      IF NOT EVALUATE(Decimal, Value) THEN
        EXIT(STRSUBSTNO(Text010,Value));
      FldRef.VALUE := Decimal;
    END;

It is the common way of numeric representation in Dutch Regions and few other places.

1.844,56 means 1,844.56

ssingla

raveendran.s wrote:

It is the common way of numeric representation in Dutch Regions and few other places.

1.844,56 means 1,844.56

Good to learn new thing :thumbsup: .

If this is true than Rhpnt it has to be a bug introduced and corrected by MS.

Sog

and the evaluate code comes from a topic here at mibuso.
to respond to your question.
The Evaluate function determines the local decimal seperator format(1.1) with 1 removed.
It then replaces the local decimal seperator in the value of the string being imported. so the evaluate will always be in NAV format. (decimal seperator ".")
However, since you import the thousand seperator also, your amounts over 1000 are incorrectly being evaluated because the thousand seperator matches the decimal seperator.

However, for export/import: readability in the file is NOT something that is required.
Get rid of those thousand seperators and let the code do its work.

rhpnt

Sog wrote:

However, for export/import: readability in the file is NOT something that is required.Get rid of those thousand seperators and let the code do its work.

This works but the funny thing is that the standard export function writes values with all the separators. This means that the export itself is writing data that the import doesn't understand. I compared the codeunit in question with that in the 2009 R2 and it turns out there have been some changes made (60+) and one of them is this:

  Field.Type::Decimal:
    BEGIN
      IF NOT EVALUATE(Decimal, Value) AND NOT EVALUATE(Decimal, Value, XMLFormat) THEN
        EXIT(STRSUBSTNO(Text010,Value));
      FldRef.VALUE := Decimal;
    END;

Thanks!