-
Notifications
You must be signed in to change notification settings - Fork 9.9k
fix(Job Card): apply precision to total time in minutes #50757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
erpnext/manufacturing/doctype/job_card/job_card.py (1)
248-281: Consider centralizing time-diff and rounding logic for all code pathsRight now,
time_in_mins/total_time_in_minsare computed and/or updated in several places (validate_time_logs,set_expected_and_actual_time,add_time_log,add_time_logs), and only this block applies explicit field-based precision. For long‑term maintainability and fully consistent rounding, consider extracting a small helper (e.g.,get_time_in_mins(from_time, to_time, precision)) and reusing it everywhere you derive or aggregate minutes, and optionally also applyingself.precision("total_time_in_mins")insideset_expected_and_actual_timewhen settingtotal_time_in_mins.
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
erpnext/manufacturing/doctype/job_card/job_card.py(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Patch Test
- GitHub Check: Python Unit Tests (2)
- GitHub Check: Python Unit Tests (4)
- GitHub Check: Python Unit Tests (1)
- GitHub Check: Python Unit Tests (3)
- GitHub Check: Summary
🔇 Additional comments (1)
erpnext/manufacturing/doctype/job_card/job_card.py (1)
270-281: Precision handling fortime_in_minsandtotal_time_in_minslooks correctUsing
flt(..., d.precision("time_in_mins"))for each row andflt(..., self.precision("total_time_in_mins"))for the aggregate will make stored values consistent with the field’s configured precision and should address rounding discrepancies without changing the existing control flow.
…th precision and only when changed
7d095e4 to
11e0590
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
erpnext/manufacturing/doctype/job_card/job_card.py (2)
657-675: Precision and conditional update logic looks good.The precision handling is correctly applied for both
completed_timeandcompleted_qty. The conditional update at lines 674-675 is a good optimization to avoid unnecessary writes.Minor inconsistency:
completed_qtyassignment at lines 667-670 doesn't have the same "only if changed" guard thatcompleted_timehas. Consider applying the same pattern for consistency if write avoidance is a goal.+ # Only update completed_qty if value actually changed + new_completed_qty = flt( + operation_deatils.completed_qty / len(set(operation_deatils.employee)), + self.precision("completed_qty", "sub_operations"), + ) + if flt(row.completed_qty) != new_completed_qty: + row.completed_qty = new_completed_qty - if operation_deatils.completed_qty: - row.completed_qty = flt( - operation_deatils.completed_qty / len(set(operation_deatils.employee)), - self.precision("completed_qty", "sub_operations"), - )
676-680: Conditional reset is correctly implemented forcompleted_time.Same minor inconsistency as above:
completed_qtyat line 680 doesn't have the conditional guard. For completeness, consider:row.status = "Pending" if flt(row.completed_time) != 0.0: row.completed_time = 0.0 - row.completed_qty = 0.0 + if flt(row.completed_qty) != 0.0: + row.completed_qty = 0.0
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
erpnext/manufacturing/doctype/job_card/job_card.py(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Patch Test
- GitHub Check: Python Unit Tests (1)
- GitHub Check: Python Unit Tests (3)
- GitHub Check: Python Unit Tests (4)
- GitHub Check: Python Unit Tests (2)
- GitHub Check: Summary
🔇 Additional comments (2)
erpnext/manufacturing/doctype/job_card/job_card.py (2)
271-273: LGTM!Correct application of precision to individual time log entries. Using
d.precision("time_in_mins")properly retrieves the field precision from the child table row.
280-280: LGTM!Good approach to apply precision after aggregation rather than rounding during each iteration, which avoids compounding rounding errors.
This pull request introduces improvements to the calculation and precision handling of time and quantity fields in the
Job Carddoctype, ensuring consistency and accuracy in manufacturing job tracking. The most important changes focus on using theflt()function for precision and updating values only when necessary.Precision and calculation improvements:
time_in_minsandtotal_time_in_minsin thevalidate_time_logsmethod to use theflt()function with field-specific precision, ensuring more accurate and consistent values.completed_timeandcompleted_qtyin theupdate_sub_operation_statusmethod to use theflt()function with the appropriate precision for each field, improving consistency for sub-operation tracking.Logic and update optimizations:
completed_timeonly if the value actually changed, preventing unnecessary writes and ensuring the field is only updated when needed.Screenshot of original issue: