fix: fall back to nearest fiscal year when today is outside all fiscal years - #57951
fix: fall back to nearest fiscal year when today is outside all fiscal years#57951mihir-kandoi wants to merge 1 commit into
Conversation
…l years When the last defined Fiscal Year has ended and the next one was never created (e.g. the scheduler was down around year end, so auto-creation never ran), boot carried no current_fiscal_year and erpnext.utils.get_fiscal_year() returned an empty string for today's date with no server fallback. The standard Profit and Loss dashboard chart then ran the Profit and Loss Statement with empty fiscal year filters, and the thrown "Start Year and End Year are mandatory" error blocked the whole Accounting workspace. Budget Variance, Top Customers, Top Suppliers and the order trends charts fail the same way, and report fiscal year defaults come up empty. Boot now sends the nearest fiscal year (the latest one that has already started, else the earliest upcoming one) when none covers today, and the client helper uses the boot value whenever it is asked for today's fiscal year. Lookups for other dates keep the exact server round trip and still return nothing when the date is uncovered.
Confidence Score: 4/5The PR appears safe to merge, with only the non-blocking need to document the new public fiscal-year helper functions. The nearest-year loop matches the descending query order for both past and upcoming fiscal years, and no behavioral failure remains; the accepted concern is limited to missing documentation for the new public helpers. Files Needing Attention: erpnext/startup/boot.py Reviews (1): Last reviewed commit: "fix: fall back to nearest fiscal year wh..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| ) | ||
|
|
||
|
|
||
| def get_current_or_nearest_fiscal_year(): |
There was a problem hiding this comment.
The new public module-level helpers lack docstrings describing their non-obvious nearest-fiscal-year selection and return shape, increasing the maintenance cost and risk of incorrect reuse.
Context Used: Guidelines for reviewing Frappe Framework applicat... (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
1 participant
Fixes the Accounting workspace failing with "Start Year and End Year are mandatory" when today's date is not inside any active Fiscal Year — e.g. the last FY ended on 30 June and the next one was never created because the scheduler was down around year end, so
auto_create_fiscal_yearnever ran. Reported in https://discuss.frappe.io/t/164081 (v15.119.0).The standard Profit and Loss chart resolves its fiscal year filters through
erpnext.utils.get_fiscal_year()indynamic_filters_json. For today's date that helper only readsfrappe.boot.current_fiscal_year, and boot skips setting it when no Fiscal Year covers today. The helper then returns""(the server-call fallback is gated ondate != today), the chart runs the Profit and Loss Statement with emptyfrom_fiscal_year/to_fiscal_year, and the thrown error blocks the whole workspace. Budget Variance, Top Customers, Top Suppliers and the order trends charts fail the same way; fiscal year report defaults come up empty in the same state.(The forum post blames a "non-existent
erpnext.utils.get_fiscal_year" — that's the Python path;dynamic_filters_jsonis evaluated client side, where the helper exists but returned an empty string.)Changes:
erpnext.utils.get_fiscal_year: use the boot fiscal year whenever it is asked for today's fiscal year, even if today lies outside its dates. Exact lookups for other dates keep the existing server round trip and still return nothing when the date is uncovered.The fiscal-year number cards already guard against this exact absence with their own calendar-year fallback (
frappe.boot.current_fiscal_year || [...]); with boot now populated they show the nearest FY's range instead, consistent with the charts.develop has the same gap (
raise_on_missing=Falsein boot, same client-side guard) — I'll forward-port after review.