Currencies have an ISO-specified minimum unit size. For most currencies, including the RMB Yuan, it's 1/100; a few middle-eastern countries' currencies use 1/1000, a few, most notably the Japanese Yen, use 1/1. Precious metals use 1/1000000. GnuCash always uses the ISO-4217 specified smallest fraction as the denominator on currency amounts.

Commodities have no such specification so it's up to the user to specify the smallest fraction when creating them. GnuCash supports denominators up to 1,000,000,000.

Note that that's for amounts. Prices and exchange rates are carried internally at maximum precision, 2^63/2^63, and rounded for display only.

With that background, the decimal places setting in Preferences>General>Numbers is for the automatic decimal places option. It has no effect if that option is disabled. The decimal places spinbox should be disabled if the automatic decimal places option is.

We should probably remove the fraction setting from Account. Most calculations ignore it and retrieve the smallest fraction from the commodity.

Seem it is not a display issues only, the value is actually rounded up. For standard 2 decimal case, the balance sheet and profit and loss report also shown round up error. (For example, there is 2 currency and the value of the amount only shown 2 decimal after exchange , actually value show be 3 or 4 decimal place)

Yes, read what I wrote again: Currency amounts are always stored with the ISO-4217 specified fraction. It's not an error, it's by design: You can't have a fraction of a penny (or whatever 1/100th of a RMB Yuan is called).

Noted. Is it mean that there is no way to provide 3 or 4 decimal place and cannot get rid of the round up error of the report generation?

It means that you can't have fractions smaller than the ISO-4217 minimum in your book any more than you can in your pocket or in your bank account.

Is this about reports or transactions? In other words, do you have assets and income or expenses in multiple currencies and when you run your balance sheet and P&L (aka income statement) reports it doesn't balance or the balance sheet's change from the prior period doesn't match the net on the P&L? Or is it that your trial balance doesn't balance? Or is it that you have exchange transactions and your bank rounds one way and GnuCash the other?

(In reply to John Ralls from comment #5)
> It means that you can't have fractions smaller than the ISO-4217 minimum in
> your book any more than you can in your pocket or in your bank account.
> 
> Is this about reports or transactions? In other words, do you have assets
> and income or expenses in multiple currencies and when you run your balance
> sheet and P&L (aka income statement) reports it doesn't balance or the
> balance sheet's change from the prior period doesn't match the net on the
> P&L? Or is it that your trial balance doesn't balance? Or is it that you
> have exchange transactions and your bank rounds one way and GnuCash the
> other?

There are 2 currencies (HKD and CNY). Transaction for 2 years (2017 and 2018), I tried to generate the P&L and Balance sheet for both 2017 and 2018. However, the  net profit/loss from the P & L report is different from the equity gain/loss from the Balance sheet (0.01 different). Finally, I found that it is due to the round up of CNY/HKD exchange only up to 2 decimal place.

Two important rules for this situation:
1. Always enter the amount and let GnuCash calculate the price when entering an exchange in the Transfer dialog box. That puts you in control of the rounding.

2. Always use the "Average Cost" price source when running reports so that it uses those transaction prices instead of "market" rates (which are usually 90-day futures, not the actual rate you'd get from your bank on the day).

Are you accounting for trading gains and losses in the currency exchanges? Dunno which is your home currency, but say it's HKD. If you transfer 100 HKD to your CNY acccount at 1.12 and then later transfer it back at 1.13 you wind up with HKD 99.12. You need to book a trading loss of HKD 0.88 to keep your books in overall balance. You test that with the Trial Balance report; always use the "Average Cost" price source. 

Managing that gets a bit more complicated when there's non-currency stuff in the middle: Suppose that you used the 112 CNY to buy goods that you shipped back to Hong Kong to sell. In that case you must carefully track the actual cost in HKD of the goods on every purchase and sale. That gets into cost accounting, which is a bit outside of GnuCash's ability to handle directly; you'd have to track it in some other program, a spreadsheet would work as long as it doesn't get too complicated, and enter the net amounts into GnuCash. You should consider asking a Chartered Accountant to help you set it up.

(In reply to John Ralls from comment #7)
> Two important rules for this situation:
> 1. Always enter the amount and let GnuCash calculate the price when entering
> an exchange in the Transfer dialog box. That puts you in control of the
> rounding.
> 
> 2. Always use the "Average Cost" price source when running reports so that
> it uses those transaction prices instead of "market" rates (which are
> usually 90-day futures, not the actual rate you'd get from your bank on the
> day).
> 
> Are you accounting for trading gains and losses in the currency exchanges?
> Dunno which is your home currency, but say it's HKD. If you transfer 100 HKD
> to your CNY acccount at 1.12 and then later transfer it back at 1.13 you
> wind up with HKD 99.12. You need to book a trading loss of HKD 0.88 to keep
> your books in overall balance. You test that with the Trial Balance report;
> always use the "Average Cost" price source. 
> 
> Managing that gets a bit more complicated when there's non-currency stuff in
> the middle: Suppose that you used the 112 CNY to buy goods that you shipped
> back to Hong Kong to sell. In that case you must carefully track the actual
> cost in HKD of the goods on every purchase and sale. That gets into cost
> accounting, which is a bit outside of GnuCash's ability to handle directly;
> you'd have to track it in some other program, a spreadsheet would work as
> long as it doesn't get too complicated, and enter the net amounts into
> GnuCash. You should consider asking a Chartered Accountant to help you set
> it up.

For my case, HKD is the home currency and CNY is the foreign currency. When I generate report (Based on HKD). Report will show the CNY asset in HKD (say, HKD/CNY = 1.1). However, the P & L report and Balance is not matched. 
I am using the latest price source. I understand that the smallest unit of the  currency is just 2 decimal places and cannot get rid of the round up issues.
But it make the report cannot be used directly and have to post-process for adjustment. For example, the round up issues、the realized/unrealized gain (Not balance)、 export format (html ?) ...
Just some suggestion from user point of view. Hope than GNUCASH can become better and better.

Does the trial balance report balance? Be sure to use "Average Cost", it's guaranteed not to balance with any other price source.

(In reply to John Ralls from comment #9)
> Does the trial balance report balance? Be sure to use "Average Cost", it's
> guaranteed not to balance with any other price source.

Trial balance report is OK and balance.

OK, then the problem is either that one or both of the reports is rounding prematurely or that they're using different rounding policies. They should agree with each other, though there's no way to ensure that they round the same as your bank does.

@alex a short test book would be useful