> I realize that VFP [...] transform the Numeric type into currency type
> (4 decimals). The fact modifies the result.
> Is this normal?

Yes. Currency values have greater precision than 'normal' numbers - 64-bit fixed point (i.e. integer) for currency vs. 64-bit floating point with only 53 bits mantissa for the 'numeric' type - and so Fox coerces the float to currency before the multiplication.

However, as always with fixed point numbers you need to be wary of multiplication/division and scale the input values appropriately; otherwise you can lose arbitrary amounts of precision. In your case - i.e. absolute value of the factor less than 0.5, but not too small - you can simply divide by the reciprocal of the factor. Beware of Fox's constant merging, though, because it can defeat this scheme.

In the general case, i.e. without prior knowledge of the factors involved, your program needs to look at the input values and determine the appropriate scale factor. In C++ this can be elegantly done because you can get at the binary representation of the numbers but in pure VFP it can get messy.

Conversion of the currency value to float (numeric) during the multiplication is not recommendable because it loses precision twice during conversion. If you don't lose precision then your numbers were so small that 'currency' was the wrong choice of data type in the first place ...

test("m.y * m.n")
test("m.y * ntom(m.n)")
test("mton(m.y) * m.n")
test("m.y / ntom(1/m.n)")

procedure test (cExpression)
   local y, n, xResult
   y = $1068.0000
   n = 0.007380
   xResult = eval(m.cExpression)
   ? padr(m.cExpression, 20) + ":", vartype(m.xResult), $1 * m.xResult

*** result ***

m.y * m.n           : Y                7.9032
m.y * ntom(m.n)     : Y                7.9032
mton(m.y) * m.n     : N                7.8818
m.y / ntom(1/m.n)   : Y                7.8818