[raams95]

What this changes

Rendered statements no longer show a nonzero stock par value as zero. Apple's FY2023 parenthetical balance sheet showed its $0.00001 common par value as 0.00. Tesla's Q2 2024 one showed its $0.001 preferred par value as 0, and JPMorgan's FY2023 one showed its $1 preferred par value as 0. All three now display the filed value: 0.00001, 0.001 and 1.00.

There were two separate causes, both in edgar/xbrl/rendering.py:

• The per-share formatter rounds values under 10 to three decimal places and pads to two, so 0.00001 became 0.00. It now keeps any finer precision the fact was filed with: every digit of an exact (decimals="INF") value, or the filed decimals when that is above 3. Values filed at 3 decimals or fewer format exactly as before. Apple's EPS rows (6.16 / 6.13) are unchanged.
• us-gaap_PreferredStockParOrStatedValuePerShare wasn't in eps_concepts, so it went through the generic monetary formatter and picked up the statement's millions scale. It's now in the list next to CommonStockParOrStatedValuePerShare. Tesla's common par value, which was already in the list and already showed 0.001, is the control.

test_recognized_share_and_per_share_domains_remain_explicit in the #1470 test pins the per-share list, so I added the new concept to its expected tuple.

Fixes #1475

Verification

• Ground truth: the assertions use the repository's existing original-filing XBRL fixtures, so no new data or cassettes are involved:
  • Apple FY2023 10-K, accession 0000320193-23-000106 (tests/fixtures/xbrl/aapl/10k_2023). Facts f-196 and f-197 are CommonStockParOrStatedValuePerShare = 0.00001, decimals="INF", usdPerShare, at 2023-09-30 and 2022-09-24.
  • Tesla Q2 2024 10-Q, accession 0001628280-24-032662 (tests/fixtures/xbrl/tsla). Facts f-84 and f-85 are PreferredStockParOrStatedValuePerShare = 0.001, decimals="INF", at 2024-06-30 and 2023-12-31.
  • JPMorgan FY2023 10-K, accession 0000019617-24-000225 (tests/fixtures/xbrl/jpm/10k_2024). Facts f-286 and f-287 are PreferredStockParOrStatedValuePerShare = 1, decimals="INF". Before the fix it showed 0, next to the common par value's 1.00.
• Regression test for the bug is in tests/issues/regression/test_issue_1475_par_value_precision.py, and its docstring links the issue. It goes through statements.balance_sheet(parenthetical=True).render() with standard=False and standard=True, and it also checks the printed statement and Apple's EPS rows. Before the fix, 8 of its 12 cases fail (['0.00', '0.00'], ['0', '0'], and '0.237' for a dividend filed with 4 decimals). After the fix, all 12 pass.
• Changelog: changelog.d/1475.fixed.md. scripts/release/assemble_changelog.py --check accepts it.

I also ran the whole -m fast suite on this branch and on main (Windows, Python 3.12). Both runs fail the same set of tests, which is environment-specific (bs4 baselines, symlinks, console encoding). The only difference is the new test file.

6.0

• This PR adds a deprecation, a 6.0 warning, or a "removed in 6.0" note, and docs/upgrade/6.0.md says what users see now and what to do instead