Conversation
`_validate_fiscalyear_difference` truncates the incremented start year to `len(start_year)` before comparing it against the parsed end year. When the two year components have different widths -- `JRNL/2015-16/00001`, the common short-form fiscal-year notation -- that compares a four-digit year against a two-digit one, never matches, and the name stops being recognised as a year-range sequence. On an existing `JRNL/2015-16/` journal the next move in the following period is then numbered `JRNL/2015-16/00003` instead of rolling over to `JRNL/2016-17/00001`, and the next year produces a malformed `JRNL/2015-17/00001`. The inline expression this method was extracted from in 19.0 truncated to `len(year_end)`, which is the operand the result is compared against. Restore that operand. Symmetric formats (`2015-2016`, `15-16`) were unaffected, which is why only one of the twelve cases in `TestSequenceMixin.test_journal_sequence_format` fails. Introduced in c9103a6 (odoo#270582). Assisted-by: Claude Opus 5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One-operand fix in
account.sequence.mixin. Opened against the fork's20.0mirror for review before anything goes to
odoo/odoo.The bug
_validate_fiscalyear_differencecompares the incremented start year to theparsed end year, but truncates to the width of the start year:
For
JRNL/2015-16/that istruncate(2016, 4) == 16→2016 == 16→ False, sothe name is no longer classified as a year-range sequence. Formats where both
components are the same width (
2015-2016,15-16) still pass, which is why thebreakage is easy to miss.
The method was extracted from an inline expression in
c9103a6a10b8(odoo#270582, "annual sequence number when fiscal year > 12 months"). The
19.0 original truncated to
len(groupdict['year_end'])— the operand actuallybeing compared. This restores that.
User-visible effect
On a journal already numbering
JRNL/2015-16/00001:JRNL/2015-16/00002JRNL/2015-16/00002JRNL/2016-17/00001JRNL/2015-16/00003JRNL/2016-17/00002JRNL/2015-17/00001That third value is not a valid fiscal-year range at all.
Verification
Existing core coverage already catches it — no new test needed.
account:TestSequenceMixin.test_journal_sequence_formatfails on 20.0 at310a97e0and passes onodoo:19.0.TestSequenceMixin(25 tests): red before, green after.accountsuite (1139 tests):2 failedbefore →0 failedafter.The other pre-existing failure was
TestAccountMoveReconcile.test_reconcile_special_mexican_workflow_2, whichasserts on
line_idslist order and did not reproduce on rerun — unrelatedorder-nondeterminism, untouched here.
Run on an arm64 build of the
20.0branch (ubuntu:24.04 / Python 3.12 /PostgreSQL 16), since no
odoo:20.0image or 20.0 nightly exists yet.AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.