# Volume lot calculation error

I use this function to calculate volume lots to be traded  :
```  double VolumeLots(double pMoney, double pSlp)
{
pMoney               = NormalizeDouble(pMoney,2); // Risked money value in account currency
double volstep       = SymbolInfoDouble(_Symbol,SYMBOL_VOLUME_STEP);
double tickPoint     = SymbolInfoDouble(_Symbol,SYMBOL_POINT);
double tickPerPoint  = tickSize/tickPoint;
double pointValue    = tickValue/tickPerPoint;
double riskLots      = pMoney/(pointValue*pSlp); // Risked lots calculation

if(riskLots < MinVol) // Check for minimum volume
{
riskLots = MinVol;
}

riskLots             = round(riskLots/volstep)*volstep; //rounding lots value
return riskLots;
}```

The function VolumeLots calculates the number of lots of a financial instrument to be traded based on a specified amount of money and a stop loss price. The input parameters are pMoney , which represents the amount of money that the trader is willing to risk, and pSlp , which represents the stop loss price.

The first line of the function normalizes the pMoney value to 2 decimal places. Then, various symbol information is retrieved using the SymbolInfoDouble function, including the trade tick size, volume step, trade tick value, and point value.

The riskLots variable is then calculated as the ratio of pMoney to the product of pointValue and pSlp . The minimum volume, represented by the MinVol variable, is checked and if riskLots is less than MinVol , riskLots is set to MinVol .

Finally, riskLots is rounded to the nearest value that is a multiple of the volstep using the round function, and the rounded value is returned as the output of the function.

When i use this fucntion in Forex markets it works with no problem, but when you switch it to Metals or Gold the value returned by the function is 10 times grater than what is should be. Somehow this has something to do with tick value and account base currency from what i found in other related topics but no solution was given to solve this issue for good.

If anyone has  a better way to calculate lots while bypassing this problem please feels free to share it, thanks.